3 ms·

+1 This looks a lot like the language I've been dreaming about. I actually like the explicit `end` keyword to materialize the end of blocks. The lambda express

+1 This looks a lot like the language I've been dreaming about. I actually like the explicit `end` keyword to materialize the end of blocks. The lambda expression syntax, as illustrated by the filter/map/fold example, looks like Ruby blocks with a much simpler syntax. A couple of questions to the crew: Why advertise it as a teaching language ? As a working programmer this looks very appealing to me. Are there limitations that don't make it a good language for practical programming (other than the fact that it's not ready yet, of course)? Are you planning to provide a tutorial more approachable than the language reference?

tel 13y ago
It's not my language, so I can't really talk to those questions. I think it's fair to say that the Racket group has always been focused on teaching languages not to exclude "production languages" but instead because it's of their personal interest and lets them focus on certain aspects of the language to exclusion of others. They don't need to build performant standard libraries---they need to cleanly introduce good programming concepts.
mageofmath 13y ago
It still has some performance issues that I say would make it hard to put into an industry environment. I think the teaching language part is in reference to Captain Teach, an IDE++ that the developers are using in the classes to support code review, automatic backups, and more. Pyret is being designed with the goal of encouraging good code, with tests being an integral part of every function, and clear differentiation between mutation and simple let bindings. I would teach this language just for those features, so my students would see how easy it is to get lost in spooky action at a distance, or in debugging the wrong portion of your code.
ricw 13y ago
I'd disagree with the "end" keyword. You could add more whitespace, which our brains naturally deal with very well, or you add more "cruft" which we have to actively think about. In typography white space is what makes good layout work. And here we're going back to replacing white space with a word. So from those perspectives I think the "end" keyword is a regression. Having said that, it's the first language that I prefer from a typographical perspective to python. So very well done on everything else.
- skrishnamurthi 13y ago
  We tried very hard to do without an ending delimiter. But it boils down to a simple matter: either make whitespace significant or make the grammar hugely (and perhaps irredeemably) ambiguous. Our position on whitespace is: - it's very important for readability - it should not be semantic - it should be possible for a program to reindent your code That is, if I copy-and-paste code from email or a Web page, my environment should be able to "move it into place". Significant whitespace means that that's no longer possible. Therefore, we want whitespace to be a context-sensitive check that is layered atop the language. You could even see turning this off for code that is machine-generated, sent over a wire, etc. We are looking at actual usage patterns before we decide on the precise rules of indentation. To this end, we needed some way of indicating that a block had ended. Ergo "end" and its alias, preferred for one-liners, ";". Let me add one more argument in favor of an ending keyword: quality error messages. The more complex the grammar and hence the parsing job, the much more likely parse errors will be very complex. What we've learned over a few years of doing user-study research into error messages is that ultimately there is a complex algorithm running underneath and the more we can minimize surprise the better, because the user (especially the beginning programmer) simply has no mental model for what that algorithm is doing.
jpolitz 13y ago
Thanks for the questions! As to why we're advertising it as a teaching language: Our group has a design sense of how to do this, and Pyret's success in the classroom is what we're able to study, measure, and focus on improving. That doesn't mean we won't be thinking about managing million-line codebases or getting great performance out of the runtime, but those concerns won't necessarily be the main guide of our design decisions. We may very well end up with something that's a superb general-purpose language, but I'm not yet willing to give folks that expectation, or do so at the expense of the learning experience. Make sense? EDIT to add: One thing that the Racket community has very successfully done is separate teaching languages from the main Racket language. A probable future for Pyret is splitting it into teaching and professional versions. I'd love to hear feedback about what more you'd like to see in Pyret, with this split in mind. The getting started guide (http://www.pyret.org/getting-started/ http://www.pyret.org/getting-started/) and tour (http://www.pyret.org/tour/ http://www.pyret.org/tour/) is the best reference for getting started right now. If you didn't see those then they probably need more prominent placement.
jpolitz 13y ago
There's another response to this that I didn't mention. Shriram is writing a textbook that includes all the material for our advanced intro course and our programming languages course. There's a lot of good examples here: http://papl.cs.brown.edu/2013/ http://papl.cs.brown.edu/2013/
rdtsc 13y ago
Did you know about Elixir? It has a Ruby like syntax, pattern matching, functional, has macros so can build DSLs with it. Also most importantly, runs on BEAM VM (Erlang's VM). http://elixir-lang.org/ http://elixir-lang.org/

tel 13y ago

It's not my language, so I can't really talk to those questions. I think it's fair to say that the Racket group has always been focused on teaching languages not to exclude "production languages" but instead because it's of their personal interest and lets them focus on certain aspects of the language to exclusion of others. They don't need to build performant standard libraries---they need to cleanly introduce good programming concepts.

mageofmath 13y ago

It still has some performance issues that I say would make it hard to put into an industry environment. I think the teaching language part is in reference to Captain Teach, an IDE++ that the developers are using in the classes to support code review, automatic backups, and more. Pyret is being designed with the goal of encouraging good code, with tests being an integral part of every function, and clear differentiation between mutation and simple let bindings. I would teach this language just for those features, so my students would see how easy it is to get lost in spooky action at a distance, or in debugging the wrong portion of your code.

ricw 13y ago

I'd disagree with the "end" keyword. You could add more whitespace, which our brains naturally deal with very well, or you add more "cruft" which we have to actively think about. In typography white space is what makes good layout work. And here we're going back to replacing white space with a word. So from those perspectives I think the "end" keyword is a regression. Having said that, it's the first language that I prefer from a typographical perspective to python. So very well done on everything else.

skrishnamurthi 13y ago
We tried very hard to do without an ending delimiter. But it boils down to a simple matter: either make whitespace significant or make the grammar hugely (and perhaps irredeemably) ambiguous. Our position on whitespace is: - it's very important for readability - it should not be semantic - it should be possible for a program to reindent your code That is, if I copy-and-paste code from email or a Web page, my environment should be able to "move it into place". Significant whitespace means that that's no longer possible. Therefore, we want whitespace to be a context-sensitive check that is layered atop the language. You could even see turning this off for code that is machine-generated, sent over a wire, etc. We are looking at actual usage patterns before we decide on the precise rules of indentation. To this end, we needed some way of indicating that a block had ended. Ergo "end" and its alias, preferred for one-liners, ";". Let me add one more argument in favor of an ending keyword: quality error messages. The more complex the grammar and hence the parsing job, the much more likely parse errors will be very complex. What we've learned over a few years of doing user-study research into error messages is that ultimately there is a complex algorithm running underneath and the more we can minimize surprise the better, because the user (especially the beginning programmer) simply has no mental model for what that algorithm is doing.

jpolitz 13y ago

Thanks for the questions! As to why we're advertising it as a teaching language: Our group has a design sense of how to do this, and Pyret's success in the classroom is what we're able to study, measure, and focus on improving. That doesn't mean we won't be thinking about managing million-line codebases or getting great performance out of the runtime, but those concerns won't necessarily be the main guide of our design decisions. We may very well end up with something that's a superb general-purpose language, but I'm not yet willing to give folks that expectation, or do so at the expense of the learning experience. Make sense? EDIT to add: One thing that the Racket community has very successfully done is separate teaching languages from the main Racket language. A probable future for Pyret is splitting it into teaching and professional versions. I'd love to hear feedback about what more you'd like to see in Pyret, with this split in mind. The getting started guide (http://www.pyret.org/getting-started/ http://www.pyret.org/getting-started/) and tour (http://www.pyret.org/tour/ http://www.pyret.org/tour/) is the best reference for getting started right now. If you didn't see those then they probably need more prominent placement.

jpolitz 13y ago

There's another response to this that I didn't mention. Shriram is writing a textbook that includes all the material for our advanced intro course and our programming languages course. There's a lot of good examples here: http://papl.cs.brown.edu/2013/ http://papl.cs.brown.edu/2013/

rdtsc 13y ago

Did you know about Elixir? It has a Ruby like syntax, pattern matching, functional, has macros so can build DSLs with it. Also most importantly, runs on BEAM VM (Erlang's VM). http://elixir-lang.org/ http://elixir-lang.org/