Hacker News Reader

Right, since I have the exact opposite experience and I can find a logical explanation for it.

I learned to drive in an automatic transmission car. I was still in terror when first learning to drive that car. Later on I got a new car, and since manual transmissions where cheaper I got a manual one. I was again terrorized every time I had to stop and get into first gear again, or when I was stopped in a hill. I can only imagine the absolute nightmare I would have been trough if I had to learn both how to operate the stick shift AND the rest of the car and laws of the road at the same time. I actually think progressive learning was better for me.

Same with programming, I learned GW Basic as a kid doing games and what not. Then switched to Pascal, then C and then ASM. I can only imagine how motivating it would have been to 10year old me having to write pages and pages of ASM just to do the simplest thing. Instead learning a easy high level language helped me stay motivated and learn progressively getting into harder stuff little by little.

Indeed. For every anecdote about "starting with assembly and working up" there is another about "starting with scripting languages and working down".

You're right that this is all just posturing and anecdotes.

For every anecdote of a Python developer who doesn't have the slightest idea of memory management, i can bring out an anecdote about a C developer who learned Perl and wrote C in it because he didn't trust hashes and had no idea of how to capitalize on high level algorithms.

It's also important that programming is still very young. The entirety of the human race has only been programming for about 3 generations, and only now are the first programmers beginning to die of old age. It will be a long time before we actually have enough data on what works and what doesn't.

I think a better message to send to programmers is not "don't learn Python as your first language", but rather "don't think Python is the only game in town". People should never suggest that you should pigeonhole yourself into one language or one programming paradigm. I know many people who learned Python as their very first language and are currently proficient in languages like C and Haskell and Scala.

If you really care about cars, you should learn a stick shift. If you really care about programming and computing, you should learn C. But just because you learn an automatic first, to ease you into driving, doesn't necessarily mean you're any less likely to go and learn to drive a stick. If you're really interested in using and understanding cars, you'll realize automatic is not the end-all-be-all. The same is true for programming.

>It's also important that programming is still very young. The entirety of the human race has only been programming for about 3 generations, and only now are the first programmers beginning to die of old age.

I often think about this too. What languages will be the gold standards in 30 or 50 years from now? Or 100? Will people view Python and Ruby as many people view COBOL and Pascal today?

> I often think about this too. What languages will be the gold standards in 30 or 50 years from now? Or 100? Will people view Python and Ruby as many people view COBOL and Pascal today?

It's hard for me to believe that they will view Python and Ruby as charitably as we view COBOL and Pascal. Cobol is only 32 years older than Python (1959/1991) and Pascal only 25 years older than Ruby (1970/1995).

I imagine the gold standard programming language for the 2040s is either a twinkle in someone's eye or just invented.

"You're right that this is all just posturing and anecdotes."

Maybe in programming, but I think there are plenty of areas wherein this "manual transmission" learning curve should be practiced.

I hate to stomp all over this guys grave, but that air france pilot who responded to the STALL STALL STALL blaring in his face for two minutes by pulling up on the yoke as hard as he could ... perhaps that guy could have used some more "manual transmission" knowledge of the plane.

http://en.wikipedia.org/wiki/Air_France_Flight_447#Human_fac...

That was a much more complex situation, and fundamental knowledge about airplanes (that all of the pilots probably have plenty) wouldn't have helped anybody.

From that same link.

"this led to a perverse reversal that lasted nearly to the impact: each time Bonin happened to lower the nose, rendering the angle of attack marginally less severe, the stall warning sounded again—a negative reinforcement that may have locked him into his pattern of pitching up"

The author's micro-elitism about stick shift is one of those things that I, as a manual-driving Brit, find ridiculous. It's a skill we almost all learn here, not something special. Our (low) accident incidence is usually ascribed to drinking, visibility, or speeding; and speeding tends to be a result of someone thinking they're a better driver than they really are.

US driving is IME (Boston, SF) easier than UK driving because there is much more road space and larger parking spaces, lower and more frequently varying speed limits, and less aggressive driving.

So that's my experience. Back to programming: we would do well to look at "countries" other than our own when talking about all programmers. What about embedded-land? The endless rolling plains of LOB internal applications? Stranger languages: J/APL? Labview?

I do drive a stick-shift car, and I've also driven (rental) automatic cars.

A stick-shift get you way much closer to the engine. A stick-shift driver can show it's emotions via the engine. stick-shift invites more aggressive driving. Your mental state "shows" thru your driving.

I learned on an automatic but quickly learned to drive my dad's car which had a a manual, and my first car, an air-cooled Beetle, was a stick. I also feel that driving a stick does make one an overall more aware driver. It's also why I'd never want a self-driving car.

Not quite following the stick/automatic and human/computer comparisons. I also drive a stick - and I definitely think it makes me a better driver - but I also think that a computer could do a better job than me. The computer could be tracking many more things - environmental conditions, 360-degree obstacle detection, etc. - than I could ever do myself.

But what it doesn't do, yet, is know that you're going to take that hill home, so let's leave it in 3rd gear for the time being. Or that you intend to accelerate out of that next curve at the edge of traction, so let's not upshift as we ease up on the gas.

Desired power is really a one-dimensional intent, manual and traditional automatic transmissions are both leaky abstractions one of which forces a two-dimensional input, and the other of which gives a choice between a 2D input with different characteristics and a 1D input that isn't continuous but instead behaves very differently in different input ranges. CVTs are less leaky than either.

Desired power is one of many intents, the others include torque, acceleration, grip, and comfort.

Wait, maybe I can understand not wanting to drive automatic, but fully self-driving cars let you actually do something entirely different with your time.

Aware of what, though? And for what purpose? Being aware of the engine is not the same as being aware of your surroundings and hazard perception. In fact you can watch this in learners; at a junction which demands lots of traffic observation they make errors in moving off, or (more dangerously) fluff a gearchange while driving along and then look down or spend a few seconds panicking and recovering during which they might miss something happening in front of the car.

The programming language equivalent is clearly memory management. Yes, you can make it more efficient if you do your own allocation - but you have to get it right every time, and C offers you very little help to do this. C++ offers more, and Rust holds out the prospect of getting it right provided you can understand and fix all the compile-time errors. If memory allocation isn't critical to what you're doing this is a distraction that consumes time and effort to no result.

I think the author's argument can be split into two generalizations:

(1) people who know C are better programmers

(2) people who learn Python first never learn C

I think (1) is generally true. I would be interested to hear someone explain why they think having low-level programming knowledge makes you a worse programmer than one without low-level knowledge.

I disagree with (2). I took a high school class on Java, they spent several years programming in Python and becoming relatively proficient. As the author described, I eventually hit the "hard dirt" where I started to having to worry about the OS, memory, etc. I then learned C and C++, operating system internals, high performance computing, GPU computing, etc and all of the low-level ideas that the author thinks that those who learn Python will never know.

However, both statements (1) and (2) are generalizations, and I've only shown that I violate (2). I believe (2) may actually hold for many people, and I agree with the author's idea that if people learned C first we would have fewer programmers but perhaps also better programmers. Of course, "better programmers" is very hard to define and depends a ton of the domain of tasks over which you're evaluating the programmer.

(1) people who know C are better programmers. I think (1) is generally true. I would be interested to hear someone explain why they think having low-level programming knowledge makes you a worse programmer than one without low-level knowledge.

This isn't related to the argument per se, but it's interesting to observe that website ninjas are making >$150k, whereas most low-level ninjas are making less. The reason is because most people want websites, and all of my SIMD knowledge becomes irrelevant in that case.

"Better programmer" is very hard to quantify. Whereas "makes more money, on average" is a solid metric.

I agree that it's hard to find low-level work with equivalent pay to web development/frontend/etc. I think this is a reason that the "learn to code" movement focuses on Javascript and Python rather than C.

From my limited experience, big companies (Google, Facebook, etc) are a good place to do low-level programming with good pay. Additionally, a lot of the programming in the financial industry (particularly high frequency trading) is very low-level work, and the pay is significantly better than the standard "Bay area web company".

I agree with you on (1). Knowing more is better than knowing less; this is almost tautological. Knowing C -- it doesn't matter whether it's your first language -- will make you a better programmer.

However, I disagree with the assertion from TFA that knowing C is somehow more "intelectually stimulating" than knowing Python. Specifically, I disagree with this:

> "I get the sense that Python-first programmers are missing out on a lot of the fun of programming. There’s a mistaken notion that programming is most enjoyable when you’re doing a diverse array of things using the smallest amount of code, leveraging client libraries and so forth. This is true for people trying to get something done to meet a deadline; but for people motivated by learning — and who aspire to be extremely good programmers — it’s actually more fun to create programs that do less work, but in a more intellectually stimulating way."

I find the above assertion ridiculous, and I know C better than Python. Learning programming with Python is more fun than learning with C. That's not to say C isn't fun; programming is fun as a whole. But Python is not for people "trying to meet deadlines", and it's way less puzzling and lets you get into the "interesting" part of your project faster, with fewer pitfalls and less boilerplate than C. That's the definition of "fun".

People who know C are better programmers. I would say that also people who know assembly language are better programmers. People who know a functional language are better programmers. People who know/have used a variety of languages are better programmers. Monoculture of any language or level of abstraction will limit programmer achievement.

Here's some data:

http://scholars.opb.msu.edu/pubDetail.asp?t=pm&id=7795212016...

When Michigan State University switched their first course from C++ to Python, the Python students did just as well on the 2nd C++ based course as those who took the first course in C++.

Here's the relevant raw data from that, but no individual scores or a distribution are provided:

    CS2 final exams in SS08
    Group       n   Mean   StdD
    Python     21    172     40
    not-Python 62    177     24

    CS2 programming projects in SS08
    Group       n   Mean   StdD
    Python     21    324     82
    not-Python 61    340     56

It really depends on their definition of "significant", but just from this data alone I see the not-Python group clearly beating the Python group on the two items here (and with lower variance.) There might be too much noise here to see a big correlation, but there's also the possibility of the data being "below the noise floor", so I would not draw too much conclusion from this.

According to the paper, that could be explained by the Python students having lower GPAs.

"In addition, multiple regression analysis showed that students' past performance (overall GPA) in the University predicted final grades, final exam scores, and programming project scores for the course, but there was no effect of the programming language feature: Python or non-Python."

"we need to fight back those instincts, because they are not based on data. Sure, they seem logical, and we can make eloquent parallels with stick shift driving, and we can all remember that one programmer who started as a Python programmer and totally sucked, so of course learning Python first doesn't make great programmers - but at the end of the day, we need data. It's all pseudo-science otherwise, and it's not any better reasoning than pop psychology."

I've interviewed (and worked with) a lot of programmers now, and I can definitively say that the best ones know how to program in C, and the worst ones do not. I'm guessing that Evan Miller has had similar levels of exposure to good programmers and bad programmers. I make no claims of causality, but the correlation is a damned strong hint.

Said another way: data actually is the plural of anecdote, for sufficiently large values of N.

I remember that understanding pointers requires a special mental effort, it changes your head, and then can be used to clearly separates programmers who can think in pointers and programmers who don't.

In this regard, "pointers" in CS can be analogous to "stick shift" in driving cars.

This remind me of this article of Joel on Software:

"All the kids who did great in high school writing pong games in BASIC for their Apple II would get to college, take CompSci 101, a data structures course, and when they hit the pointers business their brains would just totally explode, and the next thing you knew, they were majoring in Political Science because law school seemed like a better idea"

s/java/python

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...

I never understood this. Pointers just aren't that difficult if they're explained well.

It's not as strong a hint as you think. I've interviewed and worked with a fair number of programmers myself, and I can say equally definitively that the best ones know how to program in Lisp, and the worst ones do not.

All we see is that the programmer who is motivated to teach herself C or Lisp (or any other "difficult") is a better programmer than the programmer who is not. Which, on further reflection, is almost self-evident. Of course programmers who are motivated to keep learning and keep practicing become more skilled. But it doesn't make any special claim about the benefit of C in particular.

Coming at it from another angle, have you worked with a lot of electrical or computer engineers? C, in many cases, is the highest-level language they know. From personal experience, I can tell you that their code is no better (and in many cases, considerably worse) than code written people who've had experience with languages at the top of the abstraction hierarchy.

EDIT: And, of course, I scroll down to see that tptacek has already made this exact point, and more eloquently, to boot.

That is after the first language though. If you started in Basic or Python or Lua or whatever, it does not mean you cannot familiarize yourself with C and C++ later.

>It's kind of ironic how hackers, usually extremely data driven people, tend to fall into these fallacies just as easily as others as soon as it stops pertaining to engineering.

Much of the data I've seen has suggested that, of all the hard sciences, "engineering" is the one most fraught with magical thinking. It seems to be populated by people looking to shape the problems they face to the solutions they already know -- whether or not those solutions are the best that can be reasonably implemented.

It is the worst part of my experience transitioning from physics to software: everyone seems to go about citing their clever catch-phrases as fact.

In France, they drink.