I’ve been developing a language for a few years, and even with incomplete semantics and a simple one page example LLMs don’t have much trouble writing it.
I think the language/syntax has an impact, but the tooling around it will be most important for LLMs, in the same way it is for humans.
I'd agree. I've spent the last month running an experiment, having an LLM being up a self-hosted compiler. It has no problem writing complex code in a never before seen language with severe constraints[immutable, no naked recursion, recursion schemes].
The biggest challenges are maintaining non-functional requirements, specifically CPU and memory effenciency.
I bake all my own bread, mostly due to food allergies but also because there is nothing better than a fresh loaf of bread just out of the oven.
My experience and conclusion was largely the same as the author. I found the brevity of many recipes frustrating, which led me to study the details of bread making.
The type of four, how much yeast, salt and water. How the water amount varies for so many reasons in a home kitchen.
Making 4 loafs a fortnight gives plenty of opportunity for iteration and learning. And over time I was able to develop a good understanding of dough hydration and how that affects the end product, and how it can make kneading and handling the dough easier or harder. There is a sweet spot.
This also led me to adding oil to a dough. Which acts to keep the gluten chains from getting too long and chewy, thus making the dough short.
It’s also how you make a great pizza dough.
From there I started experimenting with different flours, because I had to if I wanted bread. Running low on bread flour I added semolina, and also made a pure semolina loaf.
The main thing I’ve learned is there is a lot of leeway in the recipes that still produces tasty food. I’ve made some incredible and some woeful loafs that all taste great.
I still prefer specific recipes in metric, but I find more and more I’m reading into what the ratio of ingredients is doing and why.
For those who don’t know (which seems to be the entire comment section at the moment), the new show is/was not a remake, they intended to follow on from the existing series.
I was pretty optimistic after watching the announcement [0] that this would be a decent show.
Here’s hoping they’ve developed it enough that they can shop it around.
Joseph Mallozzi says it's not, and he was involved with the new series development. I suppose Amazon is making enough from the concept that they aren't interested in selling it.
Possibly it continues to stream frequently enough to be considered a contributor to Prime Video? Not sure if you can stream it other places, but if so, those fees would be continued revenue that might disappear if the reaction to a new show is poor.
All of those are from the same continuity. (The show was not to be a remake/reboot, but also was not to be like, another season of one of the existing shows. I do wish they would just figure out how to finish Stargate: Universe... they even likely-purposefully left the plot/characters in a state where they could actually do the next season now, even after all this time, and even if some of the actors can't or won't be involved anymore.)
Until such a point where have agents not trained on human language or programming languages, I think something that’s also really good for people as well.
- one obvious way to do things
- locality of reasoning, no spooky action at a distance
- tests as a first class feature of the language
- a quality standard library / reliable dependency ecosystem
- can compile, type check, lint, run tests, in a single command
- can reliably mock everything, either with effects or something else, such that again we maintain locality of reasoning
The old saying that a complex system that works is made up of simple systems that work applies.
A language where you can get the small systems working, tested, and then built upon.
Because all of these things with towards minimising the context needed to iterate, and reducing the feedback loop of iteration.
I thought the same, but when Berkeley Mono got ligatures I gave them a go and never turned them off.
I think the truth is that any good monospace font is designed with an awareness of the grid those characters are laid out in. The rhythm and stability of that grid is a feature of monospace fonts. It lets us line up text, draw shapes and so on.
You would think not having the underlying characters visible would be an issue, but ligatures are just symbols like any other. In a short time you learn to read them, like you would any contracted word.
It is probably a bit easier to start from a language you are familiar with. That image intentionally is a mismatch of random arrows and operators that don't necessarily align to the semantics of real code.
I think that's one of the things Fira Code's Readme [1] does a better job at than Berkeley Mono's page. The top big image breaks down the ligatures in high level categories or the programming language they are most associated with, side by side the version with a ligature. Further down the Readme you can several real examples from programming languages with the ligatures called out, giving you the context clues of what it looks like in a language you may be already familiar with.
Spatial Audio for music is interesting and when properly mixed for it a song can be great. But I’m not going out of my way to find those songs.
When it absolutely excels is movies and TV, the immersion is spectacular.
I’m holding out for an example of Spatial Audio/Dolby Atmos where the immersion it can provide adds to the experience. Orchestral music is probably the best place to find that.
Would it make more sense to consider the response from the DB, like a response from any other system or user input, and take the parse don’t validate approach?
After all, the DB is another system, and its state can be different to what you expected.
At compile time we have a best guess. Unless there was a way to tell the DB what version of the schema we think it has, it could always be wrong.
The name should represent what the function does, it should indicate its purpose.
The distinction is useful even when it’s structurally identical to another function.
Two identical functions in different contexts or domains often diverge. When they’re not arbitrarily bound by the fact they have the same contents it’s easy to extend one and not the other.
During compilation, they could both end up using the same actual implementation (though I’m not sure if any compiler does this).
Test names are one of those things that are painful because it’s obvious to you as you write it, but there’s an extra hassle to switch gears in your head to describe what the contents of the test is doing.
It is really valuable when they are named well.
I’ve found this is where LLM can be quite useful, they’re pretty good at summarising.
Someday soon I think we’ll see a language server that checks if comments still match what they’re documenting. The same for tests being named accurately.
I've never seen this as a problem. If you're doing TDD and you have a scenario in mind, you describe that scenario in the name of the test.
If you're writing the test after then yeah, maybe it's hard, but that's one of the many reasons why it's probably better to write the test before and align it with the actual feature or bugfix you're intending to implement.
Maybe also why TDD is hard for me because I only truly start to think or visualize when I'm writing the actual code. I don't know if it's ADHD or what it is, but writing requirements, tests before hand, is just not my forte. It's like I only get dopamine from when I build something and everything else feels frustrating.
I used to be like that sometimes. Then I started realizing I'd get the function 90% complete and discover an edge case and have to start over in a way that could handle the edge case. Sometimes this could happen twice.
Documenting your requirements by writing the tests in advance is of course painful because it forces you to think more upfront about the edge cases in advance. But that's precisely why it saves time in the long run, because then it makes it a lot more likely you can write the function correctly from the start.
[0] https://github.com/open-telemetry/opentelemetry-lambda