I just bought it, and can’t wait to try it. Red Storm Rising[1] was easily one of my favourite games growing up. The combination of strategy on the war map and tactics during the encounters, weighing the pro/con of using sonar, and weaving around the thermocline was my happy place. Submarine sim games are truly a special niche, and I’m so excited to try this one out!
With the recent discussions around choreographic programming, and the flood of Show HN languages, this book might be of interest. Some of the languages are truly strange and unique. Transputers, concatenative stack programming, array programming, there's a lot of great stuff in here.
> For the person who only wants the notes, the sampler wins the job outright, completely. It will never play the wrong thing or at the wrong moment. For the person playing, it fails, because driving it costs more than playing, and it never touches the art at all.
This entire essay could be about AI adoption as well. Some programmers love to program, and while AI is great at producing the code, it doesn’t really viscerally appeal if one loves coding itself.
OP here. Yeah, you're not wrong. A lot of what IS driving AI code is that the writing code part isn't the intriguing aspect: it's designing, and the code generation is the grunt work that makes the design happen. And then you find out that most humans aren't that great at design: most programmers handwave their way through specifications, and thus the AIs do what they're told, and generate utter dreck, a lot like some of the "melody generators" do - they get handed very artificial constraints about what "good melodies" sound like, so they all sound very ordinary, because they STILL lack soul and replace inspiration with algorithm.
It's not. The latest-and-greatest models on $200/mo subscriptions routinely produce bloated code full of boilerplate. They are incapable of producing elegant, concise, readable, correct-by-design code - they literally can't do it, even with the smallest samples, and it gets much worse as the scale of the implementation increases. You can't will the capability into them through prompts. You probably could do so with fine-tuning or other techniques, but I suspect that would just make the variance higher - and the average code quality would be much lower than it already is.
The code generated by LLMs is passable, but never truly good. The same is true for LLM-generated designs and architectures, just even more so. They are trained on all the code out there, and the percentage of really good code is so vanishingly small that it's incredibly hard to replicate even for humans after a lifetime of learning. LLMs would need to reach a next level of capability to consistently recognize good code. Generating it consistently is out of the question for at least the next few generations of the AI.
Not all code has to, or needs to, be good. LLM-generated code is useful and helpful. It's an incredible time-saver for one-off scripts, and you can make an LLM implement and maintain parts of the program you need, but don't care to make good at the moment. LLMs are very efficient (if we ignore externalities) and easy-to-use code generators, which is huge in itself. However, they are not great or even good at generating code.
Last weekend, there was a post showcasing a Rust library with utility functions for writing parsers. It featured a simple line-by-line INI file parser. I decided to rewrite it in Python with PyParsing, a library I happen to know well. GPT-5.6-Sol High wrote the grammar that worked. It was tragically bloated, poorly factored, and multiple grammar problems were masked by parse actions. It worked, but it was decidedly bad code. I then rewrote the grammar by hand, getting it down to 1/3 of the length, eliminating all parse actions, and improving error messages in the process. I then spent 2 hours trying to convince the model to perform the same refactorings I did, but had to give up: no matter what I tried, the model couldn't get all the needed changes to coexist at the same time. When it got the terseness right, it inevitably ruined error handling. When it got the grammar right, it ruined the factoring. And so on.
Later on, I decided to make the model rewrite the PyParsing grammar in Smalltalk's PetitParser - a pretty close match in terms of capabilities. I gave the model my version of the grammar. I told it to translate that Python code. It still butchered more than half of it, doing "optimizations" (the model's words) that replaced a cached production with a literal + 3 message sends in 8 places in the (trivial!) grammar. I explained what I value in the original code, why those are important features to keep, and tried again. It still couldn't give me an idiomatic Smalltalk translation, though it did get significantly closer. I concluded that the model has a very limited understanding of how concepts I wanted can manifest in actual code and called it a day.
To give you an idea of the scale: excluding blank lines and imports, the grammar is exactly 10 lines of Python...
So no - LLMs are not good at generating code. They are just fast and convenient, and again - that's huge. But it's nowhere near a level where it can be steered to produce good code - much less being able to generate good code by default.
(I realize this post is a bit off topic and it's just an anecdote - but I've experienced this daily for the past half a year; I'm not basing my opinion on just that last attempt.)
Yeah, definitely on point. I use AI for code generation, but I ride herd on it quite a lot and I limit scope viciously and with hard rules about what the models are even allowed to generate. It's worked out pretty well, but it's hardly the "oh send a question get a full system back" that people try to pretend it is.
Probably made worse by the fact that _every_ VW brand car I’ve driven has read about 10% high on the speedometer. I think I’m going 100 kph, but timing using the km markers on the highway show I’m going about 90.
When I talked to the dealers, they said that the speedometers only have to be accurate +/- 10% according to the SAE specifications.
After DieselGate I assumed that the high reading was to game the fuel consumption game.
> When I talked to the dealers, they said that the speedometers only have to be accurate +/- 10% according to the SAE specifications.
I believe the requirement is only one way - they can read high by a certain % but they cannot read low. Which makes sense. But that means in reality they will usually read a little high.
A little nice thing the cars could do is automatically calibrate the speedometer from GPS when on a long stretch of a road. You would get the accuracy of GPS and the reliability of speedometer even when in city jungle, underground, during slow speed manoeuvres etc.
Ah, mine is quite precisely 10 years younger, and also European if that matters, sounds like yours might be Mexican if it's in the US unless I'm mistaken. I guess there is some tuning process at the end of fabrication/production, maybe just "wild luck" either way.
It all sounds great until someone writes nested list comprehensions. They are the recommended, idiomatic way to things most sane people would use ‘map’, ‘filter’, and ‘reduce’ chains, although chains are another thing python very much dislikes.
Do you do any tracking of resource consumption over the runtime of a job? We have many jobs that use the requested memory only for a portion of the runtime, and are otherwise compute bound. It would be nice to be able to learn the profiles through time of jobs and layer them to get better resource utilization.
This is actually a really cool feature of the platform. We ingest DCGM, CUPTI, and cgroups to give users granular telemetry of what exactly is going on in the hardware they allocated when running jobs on it.
We also have profiler that has single digit overhead to correlate stack frames with hardware metrics. What this means is not only will you be able to see if you job was compute bound or memory bound at time x, but also you will be able to correlate this to areas in your code [currently only supported in python - other languages coming soon :) ]
Would love to show you a demo of this live. Feel free to email me at ismaeel@expanse.org.uk
> Binary computers have two states: on and off. Every value, every decision, every process is either 1 or 0.
I’m not sure what this means. Computers are based on binary, but not everything is a single bit. Even if you wanted to use a ternary base the digit values would be 0, 1, and 2, not -1,0,1.
If anything this project is a testament to Claude’s ability to generate anything meaningful from the non-sensical requirements.
Also, you should probably want to remove the “hand-coded” claim.
The “programming is an act of externalizing a mental model” vs “a code review is reverse engineering the model, then verifying its reasoning” really hit home. Even before AI code reviews required a lot of mental effort for me. AI has made an already difficult process much more prevalent.
> the concept of getting a good grade on a test as a happier concept than kissing a girl for the first time.
Were the concepts weighted by response counts? I’d imagine a good grade is a happy concept for everyone, but kissing a girl for the first time might only be good for about 50% of people.
I suppose by this logic, if someone was pressured by their parents to get good grades and struggled, it’s possible that “getting a good grade” would have a negative connotation / emotions response for them.
This is amazing, such a nice presentation. It reminds me of the Neural Network Zoo [1], which was also a nice visualization of different architectures.
Thank you for this! I help teach a "CS enrichment course", and I'm having students play with Keras (with my own written scaffolding of course.) I'm struggling to find a resource to help me plan beyond "this is a perceptron/FFNN", and with my lack of experience (I'm a statistician) this is going to be extremely helpful.
[1] https://en.wikipedia.org/wiki/Red_Storm_Rising_(video_game)?...