Comment by selridge
1 day ago
Here is what I said:
“ This shift is an analogous to how we took having to do computer arithmetic out of the hands of programmers in the 80s. There used to be a substantial part of programming that was just a computer arithmetic. Now, almost nobody does that. Nobody in this thread could build a full adder if their life depended on it or produce an accurate sin function.”
It is truly not my fault that you proceeded to lecture me for multiple posts just to reach the conclusion that I SET OUT FOR YOU: standardization of computer arithmetic is good and makes it so that someone doing math on a computer doesn’t need to become an expert on how the computer does math.
As I said when you first insinuated yourself: I don’t need your help to be an engineer or a developer, thank you. You persisted anyway and embarrassed yourself.
Lol, you still don't get it.
Standardization means you only need to become an expert in the standard. You still need to know the standard.
And to your point in the quoted part: I absolutely could, as could any of the people who I studied with (in this century).
When you add abstraction laters you do still need to understand how the underlying layers work in order to manage upper layers.
Look, I accept that I've posted more than I should about this. But it's only because you keep saying "nuh-uh". And when you start arguing in bad faith about what I've said, that should be called out.
Saying you disagree is fine, but becoming so flustered you respond dishonestly is not.
I have been saying that the shift with LLM’s is similar to the 1980s when we standardized computer arithmetic.
Prior to the standardization, you had to become an expert on how the computer did arithmetic in order to do something that require required arithmetic. This did not mean simply knowing an approximation for a function which you could program in a language. That is not enough as you point out that is 200 level stuff. If you wanted it to actually work on an actual machine, you would need to understand how the machine itself was actually going to undertake those operations. You had to have a numerical analyst around, or at least someone that had taken a couple of those courses.
Today you can tell me how simple it is to write a sine function, because when I press you for detail details, you can say things like well. It’ll just need to be to the standard or I’ll use a library.
In the 1970s that was not the case. Nothing about computer arithmetic was simple or unified or anything. Other than requiring an inordinate amount of attention paid to something that was not the object of interest. Lots of organizations that needed to get things done on computers had to hire people and train people to be experts in the arithmetic in a way that we do not have to anymore. Most people programming do not have to think about computer arithmetic in any significant fashion. If you compare this to the 1940s or the 1950s or the 1960s or the 1970s, the picture is very different. If you became a programmer in the 1960s about half of what you were learning was how to make the machine do arithmetic. Need to do a square root well you better write that function from scratch. Does it also need to be performant? Well, then you’re in trouble.
The amount of intellectual effort, devoted to training programmers of all stripes in computer arithmetic is much less than it was 50 years ago. The fact that it is possible at all for you to boast that you could write that sine approximation and know its bounds and trust those is due to the standardization effort.
I am saying, and I have been saying that we are entering into a similar era, where there are whole categories of concerns, which are local to the machine that most users are not going to have to deal with. Some of these things will have been very central to some people’s identities, like being able to brag about sine approximations. Training is going to change; capabilities are going to change; what it means to be an engineer is going to change.
I’m having fun with the change, personally.