This was another good episode, but I always get frustrated with the weird ontology of self-perceived low-level programmers who think the only "real" thing is assembly language as written in the 80s and distainfully dismiss high-level programming concepts as mere "abstractions"https://twitter.com/adamgordonbell/status/1366373423832838149 …
-
Show this thread
-
Replying to @sudo_lindenberg
Thanks for listening! I think I agree with you, and I found Casey's view a bit shocking at first. I think that shows that on some pendulum of 'concepts are first class' vs 'hardware is first class' teaching has drifted hard to one side and Casey is trying to push it back.
1 reply 0 retweets 3 likes -
Replying to @adamgordonbell
Yeah I sympathize with the approach in a lot of ways, and as a teaching principle it obviously is necessary, but it's easy to get carried away with it as well
1 reply 0 retweets 1 like -
Replying to @sudo_lindenberg @adamgordonbell
Although we did not get to this in the interview, what I would actually say is different than either of these. Concepts are actually critical, but the problem is that people are not evaluating them against the machine, so they have no idea which concepts work and which do not.
1 reply 0 retweets 8 likes -
This is why I use the term "first class" and "second class". The rules of the machine you program on are "first class" - they cannot be broken, and are true by default. Anything you put on top of that is second class - it is only true or valuable if you can demonstrate that.
1 reply 0 retweets 2 likes -
This is why we routinely have modern software that is literally thousands of times slower than the underlying machine is capable of. It is simply due to people using extraordinarily expensive combinations of second-class concepts they have not evaluated.
1 reply 0 retweets 3 likes -
The situation is especially difficult because some second-class concepts can safely be used in some circumstances, and not in others, but most programmers today don't have the knowledge necessary to correctly make that decision.
1 reply 0 retweets 2 likes -
So the primary thing people like me are arguing for is that people need to learn things like assembly language, not because they need to write code in it, but because if they don't understand it, they don't really understand the high-level code either. They just think they do.
1 reply 0 retweets 5 likes -
In summary, we are saying programmers should learn how the machine works, and evaluate their higher-level constructs against the resulting machine behavior those constructs produce. Nobody is arguing that everything has to be hand-coded in asm. I certainly don't do that myself :)
2 replies 0 retweets 6 likes -
Replying to @cmuratori @sudo_lindenberg
I feel like a future long-form discussion is needed. I think the people who use the phrase "A sufficiently smart compiler" ... (which occasionally includes me) and people whose browser autocompletes g to 'http://godbolt.org ' need to talk more.
2 replies 0 retweets 2 likes
We could have an entire long-form discussion (argument?) just on the phrase "sufficiently smart compiler" :)
-
-
As a point of reference, the LLVM team still routinely ships horrific codegen bugs for plain C code (ex: https://youtu.be/R5tBY9Zyw6o?t=5879 …). The notion that somehow there will be compilers that are "smart" in the future doesn't really make much sense.
1 reply 0 retweets 2 likes -
If just plain C code is already too complicated to ensure good codegen, how can we possibly expect compilers to eventually be so smart as to do good codegen for dramatically more complicated constructs?
1 reply 0 retweets 3 likes - Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.