231–239 of 239 posts
Earlier quoted context omitted.
[dead]
This comment comes from a bot account. One of the more clever ones I’ve seen that avoids some of the usual tells, but the comment history taken together exposes it. I hit the flag button on the comment and suggest others do too.
Earlier quoted context omitted.
[dead]
Thanks, Programming History Facts Bot I was not actually sure this one was a bot, despite LLM-isms and, sadly, being new. But you can look at the comment history and see.
Earlier quoted context omitted.
I don't think the better software part is playing out
you're thinking of the programs in low-level langs that survived their higher-level-lang competitors; if you plot the programs on your machine by age, how does the low quartile compare on reliability between programs written in each group
The C and assembly programs we still use are the ones that were good enough to last. The thousands that weren't are gone.
Nobody counts the programs that were never finished because the language made them too hard to write in the first place.
Earlier quoted context omitted.
Hmm, there's an in-progress rewrite of the TypeScript compiler in Go; is that what you mean? I don't think that's actually out yet, and more importantly, it doesn't change anything at runtime -- your code still runs in a JS engine (V8, JSC etc).
npm i -D @typescript/native-preview You can use it today.
Earlier quoted context omitted.
Ome advantage of python is that it is so slow that if you choose the wrong algorithm or data structure that soon gets obvious. And for complicated stuff this is exactly where I find the LLMs struggle. So I make a first version in Python, and only when I am happy with the results and the speed feels reasonable compared to the problem complexity, I ask Claude Code to port the critical parts to Rust.
The last part is really interesting. It feels like the whole world will soon become Python/JS because thats what LLMs are good at. Very few people will then take the pain of optimizing it
Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…
This is the difference between scripting and programming. If you use C++ as a scripting language you're gonna have a bad time.Of course a scripting language is faster for scripting! That doesn't mean you go full Graham and throw away real programming languages, it just means you aren't writing systems software. The usual strategy is to write a script then if it's slow see how you could design a program that would The…
Earlier quoted context omitted.
I think a lot of people (especially those who are only peripherally involved in development, like management) don't really consider performance regressions at all when thinking about how to get software to go faster. Meanwhile my experience has been that whenever there has been a performance issue severe enough to actually matter, it's often been the result of some kind of performance bug, not so much language, runti…
My experience has been that performance bugs show up in lots of places and I'm very lucky when it's just a bug. The far more painful performance issues are language and runtime limitations. But, of course, profiling is always step one.