791–800 of 918 posts
Earlier quoted context omitted.
Yes that's why most of the excited folks are VCs and software engineers who made their wealth already
What's more interesting is how the big names in our industry, the ones who already made their money as you say, have turned quickly since the end of 2025. I think even the most old school names can see that the writing is on the wall now.
Earlier quoted context omitted.
It depends on your threat model. Mine includes the compiler vendors abandoning the project and me needing to make my own implementation. Obviously unlikely, and someone else would likely step in for all the major languages, but I'm not convinced Go adds enough over C to give away that control. As long as I have a stack of esp32s and a working C compiler, no one can take away my ability to make useful programs, includ…
For embedded that probably works. For large C programs you're going to be just as stuck as you are with Go.
Earlier quoted context omitted.
but isn't this like a lot of other CS-related "gradient descent"? when someone invents a new scheduling algorithm or a new concurrent data structure, it's usually based on hunches and empirical results (benchmarks) too. nobody sits down and mathematically proves their new linux scheduler is optimal before shipping it. they test it against representative workloads and see if there is uplift. we understand transformer…
No. Algorithm analysis is much more sophisticated and well defined than that. Most algorithms are deterministic, and it is relatively straightforward to identify complexity, O(). Even nondeterministic algorithms we can evaluate asymptotic performance under different categories of input. We know a lot about how an algorithm will perform under a wide variety of input distributions regardless of determinism. In the case…
Earlier quoted context omitted.
I haven't heard this perspective. I'm kind of surprised the LLMs can't generate coherent frontend framework-ized code, if that's the implication.
Both of you are right. They can generate the code quite well, but well-considered UX is another thing entirely.
LLMs are only a threat if you see your job as a code monkey. In that case you're likely already obsoleted by outsourced staff who can do your job much cheaper. If you see your job as a "thinking about what code to write (or not)" monkey, then you're safe. I expect most seniors and above to be in this position, and LLMs are absolutely not replacing you here - they can augment you in certain situations. The perks of a…
Nevermind coding where is the llm for legal stuff? Why are all these programmers working on automating their job away instead of those bloodsucking lawyers who charge hundreds of eur per h.
It also doesn't help that some people in this role believe that the SWE career is a sinking ship which creates an incentive to climb over others and profit before it tanks (i.e. build AI tools, automate it and profit). This is the typical "It isn't AI, but the person who automates your job using AI that replaces you".
Earlier quoted context omitted.
> Maybe it comes down to the definition of "toil". For sure. I idealize a future where people can spend more time doing things they want to do, whatever those avocations might be. Freedom from servitude. I guess some kind of Star Trek / The Culture hybrid dream. The world we have is so far from that imaginary ideal. Implicit in that ideal would be elimination of inequality, and I'm certain there are massive forces th…
And not just the definition, but the assumption that a specific toil is necessarily universal. I've had more than one conversation that started with someone else saying "using the LLM saves me soooo much time typing, think of how much time typing you'd save by using an LLM". But when I examine my processes and where I'm spending my time, typing isn't even on my list, so this claim is talking right past me and I can't…
Vigorous agreement. I think more deeply about problems when I put my hands on them-- be that typing code, hand writing notes, etc
Likewise some "toil" is very pleasurable to me-- washing dishes, shoveling snow, cleaning. It's definitely personal and not at all universal.
Earlier quoted context omitted.
That’s some epic goal post shifting going on there!! We’re talking about software algorithms. Chemical and biomedical engineering are entirely different fields. As are psychology, gardening, and morris dancing
I said all technologies
Earlier quoted context omitted.
Except it's not. Traditional algorithms are well understood because they're deterministic formulas. We know what the output is if we know the input. The surprises that happen with traditional algorithms are when they're applied in non-traditional scenarios as an experiment. Whereas with LLMs, we get surprised even when using them in an expected way. This is why so much research happens investigating how these models…
I don’t know what to tell you other than to say that the concept of determinism in engineering is extremely new Everything you said right now holds equally true for chemical engineering and biomedical engineering so like you need get some experience
That doesn't mean complex systems never behaved unexpectedly, but the engineering goal was explicit determinism wherever possible: predictable execution, bounded failure modes, reproducible debugging. That tradition carried through operating systems, compilers, finance software, avionics, etc.
What is newer is our comfort with probabilistic or emergent systems, especially in AI/ML. LLMs are deterministic mathematically, but in practice they behave probabilistically from a user perspective, which makes them feel different from classical algorithms.
So I'd frame it less as "determinism is new" and more as "we're now building more systems where strict determinism isn't always the primary goal."
Going back to the original point, getting educated on LLMs will help you demystify some of the non-determinism but as I mentioned in a previous comment, even the people who literally built the LLMs get surprised by the behavior of their own software.
Earlier quoted context omitted.
The golden age for me is any period where you have the fully documented systems. Hardware that ships with documentation about what instructions it supports. With example code. Like my 8-bit micros did. And software that’s open and can be modified. Instead what we have is: - AI which are little black boxes and beyond our ability to fully reason. - perpetual subscription services for the same software we used to “own”.…
> perpetual subscription services for the same software we used to “own”. In another thread, people were looking for things to build. If there's a subscription service that you think shouldn't be a subscription (because they're not actually doing anything new for that subscription), disrupt the fuck out of it. Rent seekers about to lose their shirts. I pay for eg Spotify because there's new music that has to happen,…
But application software that is, or should be, running locally, I agree. Charge for upgrades, by all accounts, but not for the privilege of continued use of an old, unmaintained version.