Hacker News new | comments | ask | show | jobs | submit login

This project seems really promising, but I got one concern. Lisp's syntax have been one of its strength for beginners. Easy to learn, easy to solve common errors. I don't see the point of having Python-like syntax really, the user could learn other syntax after they've understood programming.

Syntax is tricky and contentious, and our team members do love our Schemes. Members of the Pyret team have actually done some research on the issue of parenthetical expressions in introductory programming, and seen that parens aren't necessarily the best:


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.

I wish this could be upvoted so much more.

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.

Did you ever do any research/tests/courses with Smalltalk as the first language?

Nope. Virtually nobody uses Smalltalk as the first language any longer anyway, to the best of my knowledge.

Well, I'm guessing not that many are using Pyret as a first language (yet) either... (Actually, I think a few people are still using Squeak to teach kids programming, so that's not even true)?

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)

Sorry, my point was not to get into a popularity pissing match. I do believe popularity and quality are largely unrelated.

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.

No worries, I understood that. I just thought you were in a great position to actually preform such a study, if you were willing to run it on a group of students :-)

I can certainly understand why you wouldn't "just try Smalltalk on a class or two", though!

Yep, that's just not feasible. It would require me to first master Smalltalk, then find suitable textbook material, figure out how to adapt it to the material I'm teaching, etc. (Eg, where are the really good intermediate-level algorithms textbooks for Smalltalk?) The list goes on. So it's really just not feasible at all.

My jaw dropped slightly to see someone suggest Lisp syntax would be a better starting place for beginners than Python's syntax. Is it just me or is that a fairly unorthodox point of view?

I'd say the real trouble is teaching any syntax at all to beginners, because their first language really taints them for life. Most people will think of successive languages in terms of their first, until they learn many and are able to think more generally.

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.

I've programmed in and taught Lisp syntax for 24 years, much of it exclusively in that syntax. I've also extensively researched errors in parenthetical languages.

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.

I disagree about Lisp's syntax being "just the syntax tree", it is instead as you say a little later on, one specific way of writing linear strings of characters that correspond to syntax trees. Of course any other unambiguous grammar is also just one specific way of doing that. Lisp's syntax is not special because it somehow magically corresponds to parse trees where other syntaxes do not; rather in the case of Lisp the correspondence is simpler than for other languages. You make it sounds like Lisp does not need to be parsed, which is clearly false, it's just easier than most (but not all) other languages.

At Brown (the place this research is coming from) one of the main CS intro courses is taught in Racket. It's worked really well and people enjoy the simplicity in getting programs running quickly. People with previous programming experience have more trouble than true beginners at that point in the course.

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.

I am not a fan of that sequence of languages, and the fact that it seems to keep changing every so often shows that the course(pair) hasn't yet found a canonical, good answer.

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 key word is beginners. The people who have the most trouble with Lisp syntax are those already accustomed to other languages. Beginners pick it up with no trouble at all.

This claim has rarely been formally studied, and what data we do have does not entirely bear this out. I have taught Lisp syntax for 24 years, and it was my experience with doing so that led me to design Pyret.

Lisp syntax is (<operator> <args...>) with a few special forms (def, if, cond etc.). This is really easy to understand and allows the user to go straight forward and learn about the semantics and general programming practice immediately.

That same regularity also means there are few guideposts as a student programs, and this makes it much harder to recover from mistakes. We've looked at a lot data on this (and have taught Racket at every level for decades).

This reminds me a bit about a similar problem in Haskell. The syntax is very whitespacey so lots of things that would usually be syntax errors in other languages end up being interpreted as invalid function applications, leading to complex type-errors.

Absolutely. For instance, if you leave off an argument in a recursive call, Haskell will quietly think you meant to curry the called function, which can manifest itself as a type error in some entirely different place.

If you need guideposts, use an editor with paredit support and rainbow delimiters. This makes Lisp feel far more intuitive and tree-like than normal.

You seem to be under the impression I haven't programmed in Lispy languages. And our data are from students using DrRacket, which very much has paredit support. These are just inconvenient truths.

DrRacket is a very big language. How does it compare with using a much smaller language such as the Scheme used in SICP?

DrRacket is an IDE that supports many languages. The curricula that Shriram has used at Brown, and that others have used in many other places uses a sequence of smaller languages designed for teaching.

Our studies were on students using Beginning Student Language, the smallest of the languages built into DrRacket. It is much smaller than the Scheme used in SICP.

No that's fairly normal. It's the whole reason the scheme language, the second most popular lisp, was created. it's lost favor to python and java and c++ because those languages have more of a foothold outside of academia and might be more useful to students who only take a couple cs courses.

MIT used to teach intro to CS using Scheme, I thought. It's significantly simpler than Python.

How many people taking intro to CS at MIT do you think are beginners who have never programmed before?

Quite a few, actually, which is why the Scheme class ended up being awful in practice -- you'd get a bimodal distribution of students where some are already familiar with multiple languages (usually more mainstream than Lisp) and some aren't familiar with any, and the class, by necessity, targeted the trough right between those. So it was too fast for the students who never programmed before, and either too slow or too _different_ for the students who had, and served neither group very well.

The new (Python-based) classes handle this a little bit better, from what I hear.

The new course is so different in content from the old course that I don't think any pat comparison is meaningful.

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!

I've seen an MIT Scheme class video, and it was painfully slow and the guy seemed to explain everything in painstaking detail. I've heard about the bimodal distribution, which I believe I witnessed among fellow students when I was taking classes. But I'm having trouble seeing how Scheme made it any worse or how the class was too fast.

And, Pyret looks like a terrible beginner language! I like PltScheme, but I can't see how anyone would ever want to use that.

Scheme makes it worse, I think, because the way in which you usefully teach Scheme to someone who's never programmed before is different from the way you teach Scheme to someone who already knows C++ or Java or something pretty well.

Scheme makes it difficult because it more quickly gets you to teaching difficult ideas. This is an issue about SICP that most people simply never grok. Most courses don't cover a third of the concepts (if that) of SICP in the same amount of time. That's the book, not the language (and the only "fault" of the language is that it lets the book get that far that soon).

Yeah, 6.001 never covered the bulk of what the book covers.

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.

I completely agree. In fact, this sort of two-track approach is what universities like Brown, WPI, etc. now do. Using the same ("weird") language at both levels works fine so long as you separate the crowd. Otherwise, as you very astutely point out, the two groups are asking completely different questions and answering them clearly and consistently is absurdly hard. Too bad MIT didn't think of this (or, presumably, did and rejected it for whatever good reason, that somehow doesn't seem to be applying to other places like Brown).

I don't know about this class in particular, but the speed of a course does matter. I guess programming is one of the harder courses to teach?

I've programmed in and taught Lisp syntax for 24 years, much of it exclusively in that syntax. I've also extensively researched errors in parenthetical languages.

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.

Like it or not, universities have started to move away from teaching Scheme to introductory CS students. You may remember that much was made of MIT and Berkeley switching away from Scheme for Python. I think Pyret comes out of a precedent of Python as the new standard, so in that light, it's certainly an improvement.

That's because they stopped teaching CS, it's not that they replaced Scheme with Python in CS courses. How can you possible teach metacircular interpreters, constraint propagation languages, ambiguous computation and similar constructs using Python when you need to be able to easily define a completely different language semantics using language at hand? In that sense, Pyret will allow them to teach a bit more CS than possible using ordinary Python but still is in no way fit for something on the level of SICP.

The textbook that accompanies Pyret (http://papl.cs.brown.edu/2013/) covers many of these topics: the second half of this book is a full-blown programming languages text (formerly a stand-alone book known to some as PLAI).

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.

The university where I graduated from in 1999, still has lots of CS lectures, including lots of compiler design lectures.

We never used Lisp based languages on our lectures, rather Caml Light (nowadays OCaml) and Prolog.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact