Tom ForsythIt is spooky how much @rygorous and I agree on so many many things. So in lieu of me making a video of my ramblings, watch his instead.
https://www.youtube.com/watch?v=UBhT7nbWpMg
https://www.youtube.com/watch?v=UBhT7nbWpMg
YouTube
Fabian talked some about how languages are fundamentally tools, and they're all flawed, and no one language will solve all problems. And I absolutely agree. Some people spend a lot of time creating new languages, and I'm just not sure it's productive.
I can't find it in the video, but there was a question about how far down the stack you need to know. I mean Fabian and I like to know all the way down to the metal. But that's because we're strange. Most people do not - it's absolutely not necessary to get stuff done.
But these two things are related - language choice, and how far down you need to know. Because I do think that whatever language you use, you should know the "next level down". When you're writing code, you should be able to fairly simply translate in your head to the language below it.
Marty Fouts@TomF I think that was generally true 25 years ago and I think it’s still true in some cases now, but for most programmers working on most software it just isn’t necessary anymore, and often isn’t even possible to do well.
Cheap computers and reasonable abstractions have made it largely unnecessary while complex architectures, sophisticated compilers and large libraries/frameworks have made it largely infeasible for most.
@MartyFouts You maybe misunderstood me - I am not (always) talking about assembly language. Check out the rest of the thread.
@TomF I read the rest of the thread before I replied. My reference to framework complexity was meant to address that my comment wasn’t just about assembly.
Modern systems, at every level from “what the compiler does” to “what the hardware does” are often too complex to justify the cost of understanding the next level down more than superficially, and sufficiently robust to not require that for most uses.
@MartyFouts OK, well you're entitled to your opinion. But I find it reasonable, practical, and extremely useful to do these things. Just writing code in a language and blindly assuming "the compiler will figure it all out" is, in my experience, in multiple languages, how you end up with slow ugly code.
@TomF Ironically, some of the slowest ugliest code I have had to debug is in compilers. 😉
But as Knuth pointed out long ago, the fastest way to slow code is premature optimization (but that’s far from the point of this discussion.)
@MartyFouts Well that's a whole other discussion, on which I and many others are perfectly comfortable with Knuth being wrong.
It is the act of thinking one level down, that ensures that people don't end up with a mad panic scramble to optimise inherently slow code at the end of the project.
@TomF Knuth wrong about the well documented perils of premature optimization? Un huh.
I think, perhaps, from your last sentence you don’t understand the nuances of Knuth’s point, which was mostly an expansion on Tony Hoare, anyway.
Knuth never argued to wait until the end to optimize, by the way.
And long experience tells me that concentrating one level down rarely works as well as concentrating on good abstraction before writing code.
@MartyFouts Come on - I've been doing this for 45 years now, at every level of abstraction from Python to VHDL. I don't patronise you, so maybe return the favour? We can have a discussion with differing opinions and viewpoints without getting shitty about it.
@TomF Your first few replies to me in the thread were assertions that I didn’t understand you.
You said something that suggests you don’t understand Knuth’s argument about optimization when you talked above panic optimization. How is pointing out that that’s not something Knuth argued “shitty” but claiming I didn’t understand you not?
I don’t question your depth of experience, only argue that it no longer applies as broadly as it did when you started.