http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-va...
One issue is that it's too regular: since open-paren means so many different things (start of a "defun", start of a function application, start of an argument list in a "defun", start of a syntactic form like "cond" or "if", start of a clause of "code", the list goes on), a typo can easily and drastically change the kind of error message you get.
More closely matching syntactic forms to the type of behavior the expression has will hopefully let us improve error messages and grokkability of the difference between concepts. We're collecting data about common syntax errors and actively asking what we can do better in syntax design based on what we observe about Pyret's use.
As someone who hasn't spent much of my time in Lisp world, most of my time when I come across some supposedly elegant implementation of an algorithm in Lisp, what my brain sees is impenetrable parenthesis soup. One incredible win of Python is the resemblance of the syntax to pseudocode, and how easy that has apparently been for new developers to absorb. I'm glad to see your team has taken that to heart for a language that's supposed to be pedagogical. And that is beautifully said about how a misplaced parenthesis can lead to all sorts of errors.
Error reporting, debugging, and documentation are in that "meta" tier of programming ergonomics that few people care to reason about, and yet they are oh so important to allowing actual human beings to learn programming languages and use them to produce rereadable and maintainable code.
Anyway, I was more curious if you'd done such a study because
a) It's a very concise and consistent syntax, and
b) with all the great work that appears to go into Pharo Smalltalk it would seem to be viable option (again).
And yes, I do mean for computer science (not "just" programming):
http://www.lukas-renggli.ch/blog/petitparser-1 http://www.squeaksource.com/OMeta/
(This in addition to the nice design of Smalltalk-80 - and no, of course it isn't perfect -- is any language)
What I meant is, since most people have stopped teaching with Smalltalk, it's really hard to do the kind of research I'm talking about! We had no trouble doing it for Racket because we were able to get lots of data and from it measure for statistical significance.
I can certainly understand why you wouldn't "just try Smalltalk on a class or two", though!
Lisp has the advantage that it really teaches the general semantics of programming languages, because it's syntax is just the syntax tree, and it basically only has one form, which is function application. There's some "special forms" built into the implementation of a lisp to make it useful, but those shouldn't be confused with syntax. In fact, the parenthesis and space between function and arguments shouldn't be considered the lisp syntax either - it's just one way to represent a tree structure in linear text.
I think the real issue is the confusion in teaching is between Computer Science and Computing as a vocation. Nobody teaches the former any more, because it's less useful in the real world. As a result, we have languages which try to make a distinction between "programmer" and "programming language implementer", where the programmer generally knows less about what he is doing because someone has imposed a specific, narrow set of ideas on him.
The simplicity of parens is widely regarded as a strength, but I believe it is also a weakness. There is too much regularity in the syntax, resulting in numerous errors. Programmers, especially beginning programmers, need more "guideposts" in their programs. Additionally, parsers also benefit from this when producing errors.
The developers of Pyret are drenched in Lisp syntax; we know it profoundly well. Pyret is a conscious attempt to fix what we regard as flaws with that syntax.
The course later moves into 3 other languages (OCaml, Scala, and Java) to try and get the beginners not focused on any particular language, though there is some debate on whether that effectively teaches the beginners any language particularly well.
Pyret would definitely be a candidate for replacing OCaml in that sequence as anything with better error messages would be very welcome.
However, I don't see any reason why Pyret needs to be the _second_ language. OCaml is brought in to introduce types (amongst other things) because Racket doesn't have them. Pyret eliminates that need.
There are other reasons, too. But this sounds like a debate we should be having in a hallway, not on the Web. (-:
The new (Python-based) classes handle this a little bit better, from what I hear.
At any rate, I went from being a staunch believer in the simplicity of Scheme's syntax to starting to think -- based on lots of observational data, and some preliminary studies (http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-va...) -- that it's too simple (a failure of the "everything should be made as simple as possible, but not simpler" maxim).
But MIT's decisions are their own, and potentially peculiar to their specific curricular needs. Pyret was not influenced by them. Brown is proud to teach Racket and does so very successfully. Not every university is a dedicated follower of fashion!
And, Pyret looks like a terrible beginner language! I like PltScheme, but I can't see how anyone would ever want to use that.
Still, I think Scheme is sufficiently different from mainstream programming languages that it's... like teaching git to a crowd composed half of SVN power users and half of people who have never copied a folder to folder.old in their life. You're balancing teaching "oh, here's how Scheme's different" from "oh, here's how you should have thought about it all along".
In particular I remember the OO system being pretty confusing at first, since my background, from high school, was C++. It makes a lot of sense that Scheme gets out of your way and lets you implement a nifty OO system using just closures, but to someone who expects a language to treat objects as first-class and lambdas not, you're inevitably going to be trying to learn the SICP OO system by comparison to the C++ or Java one.
All that said, I'm not blaming the language at all. I think the quickest fix would have been for MIT to offer either a placement exam or voluntary registration for two classes, one for students who were more-or-less new to programming and one for students with a strong background in something like C++ or Java. Both classes could have used SICP as a text and worked fine.
The simplicity of parens is widely regarded as a strength, but I believe it is also a weakness. There is too much regularity in the syntax, resulting in numerous errors. Programmers, especially beginning programmers, need more "guideposts" in their programs. Additionally, parsers also benefit from this when producing errors.
I fully agree that you can't cover these things well in Python, and most Python textbooks don't, because of the poverty of datatypes and the difficulty of creating new structured ones.
However, while I think SICP is the greatest computer science book ever written, it has its own share of blind spots (for a simple example, see [the lack of] types or pervasive specification and testing). So the above book takes a somewhat different take on these issues. But it hews closer to SICP than any Python book I've seen.
We never used Lisp based languages on our lectures, rather Caml Light (nowadays OCaml) and Prolog.