I don’t know. Part of me agrees, but part of me thinks if the argument holds for Python and C, then surely it holds for C and Assembly, too. And I don’t think anyone really needs to be able to program Assembly to be a great programmer. But then, I’m not that great a programmer so I could well be wrong.
Also, and I say this as a non-Lisp-capable programmer, it seems to me that Lisp and C both teach you something about how computation works. C teaches you about how the machine works. Lisp seems to me to be more about how computation works in a more general sense. But then, I’m not a Lisp programmer so I could well be wrong.
Presumably you could also make the jump from ASM down to hardware, too.
If you haven’t coded up quicksort in transistors, you don’t really know computer science!
I built a computer from 5v TTL, implemented a compiler, and wrote a scheme in that compiler, and I have no idea about computer science
I suppose using C puts you on par with manual transmission drivers as far as knowing how the car works, and using assembly puts you on par with mechanics who can take the car apart and rebuild the motor.
Though I know plenty of mechanics who are terrible drivers, and I’m sure there are programmers who are great at assembly and extracting every nanosecond of performance out of an application but are terrible at big-picture design of complex applications. Analogies are hard.
Obviously there’s a point of diminishing returns, and there’s going to be disagreement about where that point is. I think it’s a question of how leaky the abstractions you’re building are, and given that criteria I think C is a reasonable sweet spot: translating between C and assembly is pretty straightforward.
I find it wonderfully amusing that the author got the notion of “overdrive” wrong. Maybe that stick practice wasn’t so helpful after all. Cognitive dissonance applies; if you’ve put a lot of effort into something, you’re inclined to think that thing must be valuable. Driving stick is not, in fact, a good investment of time, and neither is learning C. And I say that as someone who’s done both.
Driving stick is not, in fact, a good investment of time, and neither is learning C.
I disagree with this (also as someone who’s done both). That said, I disagree much more strongly with the author. Both C and driving a manual transmission are worth knowing, but they’re not so worth knowing that anyone should try to learn them without either interest or need.
Out of curiosity, what did the author get wrong about overdrive? I’ve never driven a car with overdrive, but Wikipedia’s explanation jibes with his. On the other hand, a torque converter won’t effectively transmit torque back to the engine, so you can’t really use the low settings in an automatic for engine braking.
There’s a note about a correction at the bottom of the post.
I find it wonderfully amusing that the author got the notion of “overdrive” wrong.
In what way? EDIT: Just saw your other post & the correction, but I’m going to leave my discourse on overdrive anyway ;-) This is what happens when I sleep on a post…
Overdrive is a slippery term: some people use it to mean “an overdrive unit attached to the transmission”, some insist that if your ratio isn’t less than 1:1 it’s not a true overdrive, and others will tell you that the “overdrive gear” is just a high gear whose ratio is less than the gear below.
Most people are tending to land on the last definition, and by it, the author is correct.
Driving stick is not, in fact, a good investment of time
As a dedicated stick driver, you’re almost absolutely correct.
We used to drive stick because we had no choice. Then we drove stick because automatic transmissions were less reliable than manual transmissions. Then we drove stick because they were less efficient than manual transmissions.
But today? Automatic transmissions are capable of processing much more data than a human, and can react far faster. Some people insist that ancillary benefits exist around manual transmissions (“you have to pay more attention to driving” is a popular refrain) but in reality the real reason to drive stick is because you like to hear the engine go vroom vroom when you shift down.
And holy hell, stick drivers don’t like to talk about the serious pain of someone stopping six inches behind you on an incline, or how your leg cramps up in stop and go traffic.
I’m not at all smart enough to proclaim that’s the case for programming languages as well. We are definitely getting there: for years people have said that GCC is able to beat hand-rolled assembly in most cases.
But if we aren’t there today, we will soon be at the point where the underlying computer architecture is abstracted away by something far smarter than us mortals, and we won’t have to deal with heap overflows or pointer arithmetic or any of those things that give us leg cramps.
I also do lots of manual-transmission driving on the street and the racetrack and I write C. When I have to drive somewhere on the street with a lot of traffic, I want an automatic transmission car. When I write a big database-driven web application or a quick-and-dirty script, I want something other than C.
I think learning how to drive a manual transmission is a useful skill, as is C and other low-level languages. I don’t think the author was saying all Python programmers should use C instead, just that they should learn C so when they write Python, they have some sense of what is happening under the hood (no pun intended). The same can probably be said for a lot of other high-level languages especially when so many programmers rely on pre-assembled packages and libraries that do everything for them. When those packages and libraries break or need slight changing, often those programmers quickly run out of skill.
It amuses me that we’ve got this paragraph:
I get the sense that Python-first programmers are missing out on a lot of the fun of programming
immediately followed by this one:
At times, you will want to punch the monitor and weep on your keyboard.
The absolute worst way to encourage people to learn to program is to start them off with a language that is known for frustrating learners to this degree.
In education there’s this concept of the zone of proximal development (ZPD for short). Essentially, knowledge of a field can be divided into three distinct zones for any given learner. There’s stuff that the learner already knows or is capable of doing on their own; stuff that the learner is capable of doing with guidance but not alone; and stuff that the learner simply can’t do yet at all. The second of these zones – stuff the learner can only do with guidance – is the ZPD, and it’s here that the learner is outside of their comfort zone but not so far outside as to be incapable of making useful progress.
Of all the people I know who’ve tried learning to program in any language, I’ve never once heard any of them complain that it wasn’t sufficiently challenging to hold their interest. On the contrary: learning to program involves learning a completely unfamiliar paradigm of interaction with the computer. Suddenly, instead of pointing and clicking on things, you’re writing code in files and struggling with the command line. Experienced programmers consistently underestimate the amount of culture shock this transition causes in and of itself.
When you pile onto this necessary culture shock the profound inaccessibility of a language like C, you’ve got a recipe for turning smart people off of programming forever. To give a beginner C is to plant in their head the idea that Real Programming involves wrestling with pointers and buffer overflows, completely disregarding the fact that a great many Real Programmers never even have to touch C in the course of their work. The beginner rushes headlong into C, discovers that writing even a totally unimpressive program (e.g. a number-guessing game on the command line) involves a huge amount of cognitive exertion, contrasts their own meager successes with the enormous scope of their favorite website or iPhone app, and concludes that they’re simply not cut out to do Real Programming.
If you want to encourage smart people to learn to program, then give them the tools and guidance they need to write something meaningful. Everyone wants to make video games and apps; hardly anyone starts out with a burning desire to learn how to hand-write the fundamental datastructures that eventually enable you to write useful programs a couple levels up the stack.
No one can possibly become a good programmer without first becoming a programmer. Leading with C is an excellent way to lose beginners before they even get that far.
I don’t know. I get it, I think, but I take issue with the notion of ‘extremely good software’. Extremely Good Software strikes me as an incredibly particular thing, which varies from project to project.
Sometimes the goal of a piece of software is to be fast, efficient, compact and portable. Here a lower level of abstraction over the system seems to be useful. Understanding of mechanisms much closer to the metal might serve us well here.
Sometimes the goal of a piece of software is to be manageable. We aim to reduce unnecessary complexity, abstract away the pieces of machinery that could, if we’re not careful, grind us up.
Sometimes the goal is just to be done. In this case we never aim for performance, or even necessarily correctness. When we’re learning this is a common goal.
When someone says extremely good, I wonder “for what?”
I definitely get the frustration with 100-liner API call hello worlds. For learners of a certain persuasion it feels like magic, and we want to demystify it. Others might want the carrot, to see things move, to see will made manifest.
I think every language has something to teach, and the one certain takeaway is that we can expand our quiver with the concepts central to each language. Assembly and C can teach us how the machine works, Lisp can teach us how to build composable abstractions that can be layered, to solve a problem. OO languages can teach us the value of decomposing a problem into concerns. Languages with fancy typing can teach us about the strengths of properties. And on and on and on.
Being a good C programmer may not make you any better at figuring out stuff that exists at a higher level of abstraction, and I’m skeptical that learning something higher up prevents effective learning of things lower in the stack.
I, at least, have confidence that driven learners will eat their vegetables, there are too many concepts to learn for a fertile mind to go fallow.
Agree heartily, both on the manual transmission and the Python. ;)