The Joel on Software Discussion Group (CLOSED)

Before I start off this topic I would like to refer you to two comments on Joel's article in "Language Log", a blog used by various of the leading linguists in the US.

The original article http://itre.cis.upenn.edu/~myl/languagelog/archives/002736.html#more
comes from Mark Liberman, who is a Professor of Linguistics in the Department of Computer and Information Science at Penn State. He springs to the defense of his faculty, but also gives an interesting take on the comparison Joel makes between Latin and Scheme.

A second article,
http://itre.cis.upenn.edu/~myl/languagelog/archives/002738.html#more partially contradicting the first appeared within a few hours from Bill Poser, Adjunct Professor of Linguistics at the University of British Columbia. This article apparently corrects both Joel and a source at Penn that Liberman mentioned with regard to the differences between pointers and references, but it's general point is that:

"Mark's discussion of Joel Spolsky's rant about young programmers who haven't learned C and Scheme provides a probable example of a real effect of language on the way we think, though one that is not usually considered part of the Sapir-Whorf effect."

The Sapir-Whorff hypothesis is the theory, now denied by all trained in linguistics and most untrained, that one's thoughts are constrained by the limits of one's mother tongue.You know the idea: that French philosophers are more logical/unimaginative because in French you have join nouns with prepostions to make a noun phrase and thus define their relationship, whereas in German you can just glue them  toghether; that Saudis can't see snow the same way Eskimos can because they don't have the mythical fifty/five-hundred different words for snow (and even if the Eskimo words for snow weren't a hoax, there is still the question of why, with all the words for sand there presumably are in Arabic, the town Saudi still manages to bog his car down at the side of the road).

However the Sapir-Whorff hypothesis is given considerable credence when talking about computer languages. There is a general belief that the choice of programming language affects the way programmers, and even more newbie programmers think. This view is expressed by Dijkstra in his famous comments:

    "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
    The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence."

McConnell in the proof version of Code Complete, version 2, Chapter 4, actually refers directly to Sapir-Whorff (and indeed is under the mistaken impression that it is a legitimate linguistic theory. He claims that programming languages "determine how you express your thoughts, and might even determine what thoughts you can express."

NOw I agree with Poser -- and Confucius :) -- that "If names be not correct, language is not in accordance with the truth of things." There is nothing more frustrating than to be arguing with somebody who attaches a different meaning to a concept such as "evolution" or "civilization" or "ethnicity" than you do. However I am sceptical that Sapir-Whorf has any more validity in the progamming world than the real one.Apart from anything else there would have to be an alarming number of mentally-mutilated programmers around if the popularity of BASIC in the 70s and 80s is anything to go by.

Comments would be appreciated.

> determine how you express your thoughts

How can you argue with this? My ruby code solves problems differently than prolog or erlang or java or C. My expression is very different. How I can solve problems is different. That implies my thinking is different. It doesn't mean I can't think anything else, but it means what I think is a covnersation between my mind, tools, and the problem.

Many of the people who I've seen in the last two days defending Java as a teaching language seem to be displaying a pretty strong ignorance of just what is being left out by not teaching these concepts in C and Scheme.

Yes, when I said pointers, I meant pointers. References (as implemented in Java) are easier than pointers. In particular I meant pointer arithmetic, knowing when to dereference, knowing how to declare things, pointers to pointers and how they relate to arrays, and a whole bunch of confusing things that just don't exist in Java (making Java a better implementation language). Agreed that these are bad programming features that the compiler should take care of for you. They just happen to correlate well with programming aptitude.

And when I said recursion I meant recursion, but I also meant programming by wishful thinking, which you can do in Java, and programming using functions as first class types, real first class types, not some ugly functor hack. So that means understanding the concept of "map" and writing code like (map (lambda (x) (* x x)) '(1 2 3)) which simply can't be expressed in Java at all, making Java a worse implementation language.

Java does NOT expect you to define your own container data structures, it expects you to think in terms of iterators and the visitor pattern rather than map.

Worse, the clutter of class and member definitions, "return" statements, int vs. Integer, and the need to do some I/O to see your results means that students get completely distracted by a bevy of language features that aren't what the professor is trying to teach.

I think the best way to see this is to watch Abelson & Sussman's lecture 1b, in which Prof. Sussman takes about 5 minutes to teach big O notation, introduce the concepts of efficiency in time and space, and teaches students to thing about the "shape" of the computation in a way which is amazingly elegant and clean in Scheme syntax but would be completely cluttered and impossible to demonstrate in a working Java program. I apologize that my linking to the video lectures at http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/ seems to have completely overwhelmed that server, but it's worth waiting for.

One thing all the responses I've seem to my article has taught me: Paul Graham was right. Programmers who know only a hypothetical VB/Java-like language just don't really understand the language features they've never seen. They don't miss what they've never seen: code and data using the same s-expression syntax, truly extensible languages, easy list and tree literals, and on and on.

If you can't wait for the video look at 1.2.1 here:

http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-11.html#%_sec_1.2

The 2738 article places words in Joel's mouth that he never said and then readily debunks them. Not a good argument.

Joel:

What convinced you to take another look at functional programming languages?  Don't take this the wrong way, but it seemed like you didn't care for them before a few months ago--it was frustrating to watch you belittel FP before and now come out swinging for them.  What are your thoughts on the current state of functional programming languages?

I'm curious as you have pretty far-reaching potential, and it seems that the functional style has been picking up steam lately.

Setec,

My understanding is that Joel does not agree that Scheme is a useful production language, but he thinks it is a great teaching language.

Thank you. Right.

It's very frustrating. People want me to be "pro" or "con" certain things; they need it to be black and white. They can't listen to the arguments I'm actually making.

A long time ago I hypothesized that the cause of back button not working in an early version of Yahoo! Stores was because the pages of the wizard were implemented as if they were subroutines, using a feature of Lisp that Paul Graham advertised somewhere as a benefit. So now all of a sudden I'm anti-Paul Graham and anti-Lisp and anti-FP.

And now I say that Java is a bad teaching language, taking care to emphasize that this makes it an easy to use implementation language, and people go on and on about how I'm dissing Java.

Perhaps the most important point here is that people are taught languages at all. Languages are not important when it comes to teaching, they are important when it comes to actual implementation.

Students should be taught concepts, using whichever language or technology is most fit to convey that knowledge. The point of CS should not be to teach students to write implementations, it should be to teach them to understand computing, which is a much wider area. Sure, they should have practical tasks of writing various implementations, but just as one aspect of the curriculum.

So, I agree with Joel that the (apparent) trend to stick to (a simplified version of) a single language/technology for teaching CS is nonsense. It should not be expected that the students learn *everything* of something, they should get an understanding about the basiscs/fundamentals of a lot of *somethings*.

I think, as the first linked artilce in the OP points out, that we need to separate the language from the concept.  The concept of pointers, and the concept of recursion both lend themselves to powerful manipulations of data with minimal coding.  They also require a certain level of mental gymnastics to understand in the first place.  It seems to me that our discussion has been caught up in that programming languages which we use to implement real-world or education problems.  Java vs. C vs. Scheme is a programming language debate, but pointers vs. no pointers (and recursion vs. no recursion) is a conceptual debate. 

Conceptually, I would be disappointed if we were not teaching the students in universities to know pointers and recursion.  I understand that to some level certain languages can obfuscate the existence of pointers and lessen the extent of recursion.  That shouldn't mean that people shouldn't learn about them.  Knowing what goes on behind the scenes can be important for debugging what is happening on the stage. 

Can you remember (or imagine) the difficult of programming before you knew pointers, or recursion?  I remember learning Java before I had any computer science training.  I remember that a lot of the mysticism associated with programming was taken away when I learned more about the underneath implementation.  I remember *wanting* to know how it worked (however misguided that might have been! :)).  Programmers should be/are inherently curious about how things work.  If you aren't then how are you going to construct better and better things (things in this case being programs)?

The measure of an implementation is not constrained by lack of knowledge of basic fundamentals. However, innovation and one's ability to adapt to a changing environment is best served with great knowlege of the fundamentals.

This is apparent beyond computer science. For example, you can file court petitions without understanding the fundamentals of law. You can lead a world class computer company like IBM without a MIT degree in computer science.

So everything boils down to the team building at hand. Do you need an innovator or implementor? To bash either one outright, or their learning environments, really makes no sense. However, I think Joel has shown that the innovator may not have been a great implementor in the Yahoo Store case. Surprising? No. For example a nurse(implementor) might draw your blood with less sticks, than a doctor.

I disagree with Berislav. We learn by doing. Without a teaching language, how do we "do" programming-learning?

One thing about the education system that I would change is that at the beginning of the first course, the instructor informs the class that this is a teaching language, specially designed to help teach important concepts, and the students will switch to real-world languages at a certain point.

A well-designed teaching language plays an important role, imho.

"...how do we "do" programming-learning..."

I don't think most CS tracks are trying to teach programming.  They are trying to teach the theory of computation.  Since it's often easiest to express the concepts in a programming language, they have to suitably equip the students much like Physics students have to learn a lot of math, even though they aren't in the business of doing math.  The language of mathematics gives them a means to express, analyze, and otherwise manipulate the concepts in a concrete way.  Similarly, the programming language allows the CS students to express and manipulate the concepts they are learning.

>> Are you a Junior in college who can rip through a recursive algorithm in seconds, or implement linked-list manipulation functions using pointers as fast as you can write on the whiteboard? Check out our summer internships in New York City! Applications are due February 1st.

That was what that irked some of us. Not pointers and functional programming in college per se. FC preferring pointers and functional programming for what is at it's core database driven application.

I see it like thos: students of linguistics learn theory of languages, not a single language. It would even be counter-productive to say, for example, let's teach our students German and then explain all its features and that's it. Or, even, as some curricula seem to do: let's teach our students a *simplified* subset of German...

While German is a fine language, it has far from all features that are encountered in human communication. Learning German we'll know nothing of peculiar sounds of Bushman languages and other features available in other languages.

So instead, students are taught *concepts*, strengthened by examples in various languages, and possibly a few languages that incorporate some more interesting of the features learned (I had a choice of Arabic, Hungarian and Old Slavic).

Learning CS is similar -- so students should learn concepts like pointers, recursion, relational normalization, even patterns, and then a few languages that will enable them to see some (but not necessarily all) of the taught concepts in practice.

Is Sapir-Whorf *wholly* discredited?

Maybe the mother tongue doesn't control how you think, but languages definately do. I spent some time in another country, and speaking that language changes how I think. Some things can be expressed more easily, some are more difficult, but as a relative beginner the largest change was that it *stopped* my thoughts--not because the language couldn't express it, but because I didn't know how to do so, so my mind would spend so much time figuring out out that it's get lost. I can only imagine what a wilidly different language would do.

Same with programming languages, as others have pointed out in this thread. As a beginner, you get stuck. Even as an expert, you'll think differently, and some problems become trivial to solve while others become so difficult it's not worth solving at all.