How many of them can read x64 or ARM assembly emitted by their compilers?
How many of them will ever need to?
There's your answer.
It’s how I deeply understand what a RAM lookup vs having it already in a register means for optimization.
These are things you need to know if you want to work on high performance applications or in limited embedded systems.
So, yes, many of us need to and it’s important we keep teaching it to future students.
Me, too, but we should both understand what we're talking about: a hobby.
It's like teaching cursive to schoolkids. All well and good, but don't you dare complain about limited classroom time for instruction in other, more important subjects.
I built and deployed embedded systems robotics that protect water and oil pipeline infrastructure that costs billions of dollars if there is a failure.
That is not a hobby, that’s a career.
The tools I built just helped fix the fresh water access for my entire city of 2 million people. Explain to me what’s more important than people having access to water.
Humans put the tool in the pipe and analyse the data. This isn't newfangled shiny tech, it's old stuff designed and maintained from a decade ago.
There's no fancy AI, no magical automated robots. Just humans using EM tools to scan pipes.
This is a category error. LLMs are probabilistic. The ones run by an AI company over API, even more so.
Compilers are not.
Nobody cares. Deal with it and get over it.
>Nobody cares.
That is a different matter. And you are probably wrong here as well. Plenty of people care about a program doing exactly what they want. Nothing more, nothing less. If not every one would have been writing programs in Ruby (not that Ruby is non-deterministic) .
Get over that camperbob2
When I say that nobody cares about determinism, that's what I mean. Determinism is indeed important, but only at the delivery level. There are many routes to achieving it, none of which require you to write low-level code yourself. If you insist on doing that, you have a hobby, not a profession.
What exactly do you mean by this? Can you give an example..
My workflow used to be:
1. Draft rough spec
2. Write a bunch of C/C++ code
3. Test manually
1. Put some actual care into a detailed spec
2. Write equally detailed test harness spec
3. Hand both specs to clanker. Surf HN for a while
4. Review target code casually
5. Review test harness very carefully
6. Run test(s) manually (or, lately, get the clanker to do that too)
7. Iterate if necessary, going back to step 1, 2, or 3 as appropriate
The analogy I like to use is Harold Black's work in the 1930s, trying to convince the patent office and his peers that yes, negative feedback is a huge, huge F'ing deal, because it only takes a small amount to make a large improvement in linearity. Anytime you have something that is 95% as good as it needs to be, it will be good enough if you can wrap a loop around it.
Lol, you are in for a world of pain when you run out of prompts!
But you can always throw the entire program, and start from scratch...You have every behavior captured in tests, right?...right?
Not necessarily. I'm still learning how to do that, just like the rest of the industry will have to. TDD in the age of AI is a skill that will emerge from disciplined practice as well as a lot of trial-and-error.
As for digging in manually, right now I still have to keep a pretty close eye on the C code the clankers emit, but then I'm old enough to remember when we had to debug compiled C code by stepping through x86 opcodes in Turbo Debugger. That need went away, frankly sooner than I thought it would. I almost never need to look at x64 assembly anymore, and I can't sight-read ARM at all. The same thing will happen with what we call high-level languages today.
At some point last year I noticed that I was finding fewer bugs in AI-generated parts of the code than the AI was finding in my own, and that trend clearly isn't going to reverse itself. When the clanker screws something up, it's usually because I gave it flawed or incomplete instructions, not because it's incapable of doing the job right.
Not always, but usually.
Wait, how do you debug now? Do you mean because of LLM assistance?