My university started the introductory course (for all majors, courses were common for the first 2 years) with scheme and most student seemed to understand it fairly well. We still had the 20% that were extremely fast because of having programming experience before (but learning scheme was a nice change compared to what they used to do) but the numbers of students completely lost seemed rather small.

So I think scheme is a very good choice for an introductory course...

Ruby is very nice (I'm mainly programming in it nowadays) but I'm not sure it's such a good choice for beginners, there are a lot of small details that could trip up beginners I think (block vs procs vs lambda vs method(:name_of_method), the eigenclass...)

The problem with Scheme is that it's very difficult to learn in a vacuum. You can do all sorts of interesting things with it, but if people can't use it to do real work then they quickly lose interest (I'm not talking about CS types who are interested in computing anyway, but others who would fine programming a useful skill in their "real" jobs). From that POV the best teaching language is something like VBA, awful tho' it is, because it gets people from zero to "look what I did!" very quickly. Or MATLAB or some other language that's looked down on by purists.

At the risk of sounding like a broken record, I must say that Python fits the bill.

I confess I know little of Python, so wasn't confident enough to list it.

From what I know, the Python mantra seems to be 'one way to do something', which I suppose would be less confusing for first timers.

Well, I think Python has one obvious preferred way of doing things, but then tends to let you do it anyway you want. Which I guess is a part of the whole "Python supports multiple programming paradigms (primarily object oriented, imperative, and functional)" thing. Not that I know that much about Python either but it is my preferred language.

Because of crippled lambdas, Python never felt to me like it really supported functional programming.

You can experiment with some functional ideas in Python, though -- once you're familiar with basic Python, exploring the stuff you can do using higher-order functions is likely to be quite educational, with the caveat that (in that language) recursion will blow up on you when it gets too deeply nested.

So, while it doesn't really support FP fully, it's probably sufficient for basic FP from a pedagogical standpoint. (I also think it's one of the better candidates for a first programming language overall.)

I have read email list anecdotes of Smalltalkers who introduced their kids to Smalltalk as a first programming language. In the majority of cases, their kids liked Smalltalk and their reactions to subsequent languages are, "Why are they so complicated? They don't do anything more than the simpler one."

Smalltalk as it exists today has about 8 terminals & nonterminals in its grammar. Python has something like 30. Ruby has something over a hundred, but for an intro to programming, you can just ignore most of the grammar and use a subset which makes it very close to Python in simplicity.

Smalltalk was specifically designed to be usable by children.

I think the problem with those languages is they're too different for a starting course. Scheme is obviously very powerful, but its syntax is wildly different than most popular programming languages used today. As for Ruby, don't even get me started. There's practically no syntax at all; merely reading it agitates me.

I think, in the beginning, people are most likely to understand concepts like Objects (Circle, Square, etc.) and how they relate to other stuff since it's so based off how we normally think. Also, since Java is statically typed, I think it makes things appear to contain less "voodoo". Then again, I could be completely wrong; I had been programming in other languages for years before taking my first Java course in college and only attended the class when there was a test.

Ruby has quite a bit of syntax (parens, methods on objects, blocks, etc), whereas scheme has almost none (parens, special forms like lambda, #t, '()).

Of course both have less obtrusive syntax than Java, which requires the famous

  public static void main...

just to get started. That is the kind of stuff that I think confuses true beginners. They look at that stuff and think "holy crap memorize these voodoo incantations" and never really leave that mindset once they get there. Even if they eventually learn what static means, they will always treat it as such.

I think once they get the hang of programming in something, it's easy to build up from there. I just think it causes people to focus on the wrong thing (syntax rather than semantics) when they are first starting out.

One of the things that complicates Scheme for many beginners is the prefix notation for arithmetic and such.

It's just not a concept most Freshmen are acquainted with.

I dunno--I started community college with an HP-48 instead of a TI calculator, and reverse polish notation wasn't a problem at all once the friend who'd convinced me to get one explained how the stack was like the way you do arithmetic on paper.

>>Also, since Java is statically typed, I think it makes >>things appear to contain less "voodoo".

No way. It's better to learn other programming concepts without the distraction of having to maintain types. Duck typing makes a lot more sense to new people, in my experience. Most of the popular languages with non programmers (PHP, VB, JavaScript) fit this mold.

Forth, Factor, and Io are languages that come to mind that have "no syntax". Ruby is certainly at the "more syntax" end of the spectrum.

    puts(("foo #{bar} %s %s" % [bat, baz]) * 2.+(0b0010))

There are a huge number of syntax rules in that line.

I count 23 in a PEG language without repetition. Here's an expanded version of your fragment that runs successfully:

    # from http://news.ycombinator.com/item?id=404609
    bar = 3
    bat = 4
    baz = 5
    puts(("foo #{bar} %s %s" % [bat, baz]) * 2.+(0b0010))

And here's a grammar for the subset of Ruby it uses:

    this <- 'A parsing expression grammar for a tiny subset of Ruby.'.
    copyright <- 'Written by Kragen Javier Sitaker 2008; in the public domain.'.

    program  <- _ expr program / .
    noninfix <- inparens / call / constant / quasiquoted / list / name.
    expr     <- infix / noninfix.
    inparens <- '('_ expr ')'_.

    call <- name '('_ commalist ')'_ / constant '.'_ methodname '('_ commalist ')'_.

    constant <- '0b' bits / digits.
    bits     <- bit bits / bit _.
    bit      <- '0' / '1'.
    digits   <- digit digits / digit _.
    digit    <- bit / '2' / '3' / '4' / '5' / '6' / '7' / '8' / '9'.

    quasiquoted   <- '"' qqcontents '"'_.
    qqcontents    <- !'#{' !'"' char qqcontents / interpolation qqcontents / .
    interpolation <- '#{' expr '}'.

    list      <- '['_ commalist ']'_.
    commalist <- expr ','_ commalist / expr / .

    infix <- noninfix '%'_ expr / noninfix '*'_ expr / noninfix '='_ expr.

    _  <- sp _ / .
    sp <- ' ' / '\n' / comment.

    comment      <- '#' commentchars '\n'.
    commentchars <- !'\n' char commentchars / .

    namechar <- 'b' / 'a' / 'r' / 't' / 'z' / 'p' / 'u' / 's'.
    name     <- namechar name / namechar _.

    methodname <- '+'_ / name.

I have tested it (in http://github.com/kragen/peg-bootstrap/tree/master/peg.md) and it seems to work for that fragment, although I haven't examined the parse tree to see if it's right. (Obviously the definition of namechar is wrong, and there's no $end token separating statements, and you can't call methods on things that aren't constants or self, etc.)

Start with digital logic and machine architecture, work your way up.

That is how my school taught me, but I don't think this is really an option for non-majors.

I remember checking out a first-year CS textbook from a library, back when I was in HS. It described one-bit adders and other hardware and then prescribed a lab assignment that required stuff I couldn't buy at a computer store.

Later, I signed up for a CS course at a college, and their textbook was just a glorified Visual Basic tutorial, because at the time, all the companies were looking for Visual Basic programmers.

Now, companies are looking for Java programmers, so the schools have switched over to that. Never mind that programming languages have a long history of turning out to be short-term fads (COBOL and Pascal before Java), and the real skill is in understanding the logic underneath the language.

I don't think syntax is the problem the problem is getting people to understand that programming is about changing what's going on in memory. In math when you solve (X + 7) = 15 the value of X does not change but when you say X = 7 the value of X changes.

IMO, the only thing which would help most into students "get coding" is using an inline debugger to step though their code and understand what's happening. Because people don't get the idea that software is a dynamic thing once you run it.

ruby syntax can be a little confusing. e.g. you can usually leave out parenthesis, but not always, and sometimes you get warnings but it works anyway.

Well with any language you have to teach a little bit of convention to go along with the rules, and the convention on when to use parens in ruby is mostly standardized from the code I see.

But yeah, I'm sure there has to be a better language for learning out there, I just don't personally know it. I originally learned with C++, and I remember the terror that were pointers at first. When I had a class that taught me Scheme, I remember thinking: "hey, I could write this code on paper without even testing it out if I wanted", which was the polar opposite of my C++ experience.