Pyret looks like a there's a lot going on, based on the examples. It has implicit returns, special purpose syntax for data structures, iterators, assertions, refinements, etc. Having support for more stuff makes it less suitable as a teaching language, not more. Pyret looks like a has the good bits of Python plus a whole bunch of other cool stuff. But the language is pretty complex as a result. Cool? Yup! Good for te…
The grammar can be described with a single page in actual BNF. Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. Ruby is fundamentally impossible to describe with a BNF.
Pyret: A new programming language from the creators of Racket
211–220 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#212Earlier quoted context omitted.
Thanks for your comments! I have two responses: 1. You're right that exposing too much, too soon is a recipe for disaster. People can only fit so many new concepts in their head at once, and blasting them with refinement types from day one isn't a great idea. However, there's two things at work here: the role of the curriculum and the role of the language . Pyret is careful to allow a gradual transition to more and m…
Joe, any plans to push this out in Kathi's intro course at WPI?
Not our decision! Tell the WPI folks about it and why (if) they should consider using it.
Re: Pyret: A new programming language from the creators of Racket
#213Earlier quoted context omitted.
If you think parsing is the hard part, wait for the semantics. See, for instance, the Ruby examples on the Pyret home page.
I don't see any difficult semantics in those examples. The hard part of parsing Ruby is mostly trying to conform to MRI rather than to a formal grammar. In comparison the semantics are reasonably simple. It's hard to compile Ruby efficiently , though, but for reasons unrelated to those examples. (Incidentally I don't know if that scoping example is intentionally ignoring the fact that Ruby does support lexical scopin…
Yes, I spoke too loosely. What I meant to say is that you'll have hard time making Ruby fast. I assumed implicitly that the point of writing a compiler was to optimize performance, though maybe not.
Re: Pyret: A new programming language from the creators of Racket
#214Earlier quoted context omitted.
The language is in use in introductory courses, with a gradual introduction of these topics. It's no different from using any other modern programming language in education. Our goal is to eventually create language levels, pioneered by DrRacket, based on what we learn from observation. This is a research project in addition to a development one, where the research is into human factors.
Why replace Racket with Pyret? Is this purely to stop students from being able to complain about syntax or is there a deeper strategic reason behind this? Refinement types are nice. I really wish those were more common.
Your second paragraph answered your first paragraph (-:.
1. We have a different view of static typing than Racket.
2. We have a different view of the type language than Racket.
3. Long term, we are working on smoothly integrating testing, types, and specification [as a spectrum -- perhaps even as a cycle -- rather than as three different things]. Refinements are an instance of this. Another is our plan for how to do type inference.
4. I am also convinced that parenthetical syntax has real problems that I can't completely ignore. Of course, it doesn't hurt if it can get people to stop complaining. (It's not only students: the bigger opposition often comes from teachers. Unfortunately the teachers control the path to the students, so their views _really_ matter!)
Re: Pyret: A new programming language from the creators of Racket
#215Earlier quoted context omitted.
On the other hand, inline test does make it easier to write tests while writing the function. Besides many well-written programs already contains inline documentation (not comments) that can be a lot longer than the function they describes. Code folding in a IDE goes a long way to make this bearable.
> Code folding in a IDE goes a long way to make this bearable. Code folding in IDEs is an indication that we are doing it wrong -- that is, we human beings are programming computers "wrong." I'm not saying that code folding is a symptom. I'm saying that code folding shows how primitive our means of managing code is. It's as if the mesopotamians somehow invented computers, and because of tradition, all code has to be…
Code Bubbles were invented one floor above me (by another team in computer science at Brown University). So, we're not at all unaware of it. And yes, it's great stuff.
But we also had to make a conscious decision about IDEs, and we decided to be IDE agnostic -- IDEs should enhance the language but not be the only means of working with it, because programmers are really attached to their editors, and a language predicated on tearing people away from their editors will stuggle. Also, having been part of DrRacket from version 0.0, I know how long it takes to make one that's any good.
Re: Pyret: A new programming language from the creators of Racket
#216Earlier quoted context omitted.
I think that Python's doctests have shown this to be a greyer area than this. Not all tests can fit nicely next to function definitions, but a few well-chosen ones are both fantastic documentation and not too cluttery.
Doc tests are a poor solution precisely because they are difficult to edit. The solved a non-problem and made writing documentation AND tests more difficult. Instead of writing tests in strings, the documentation tool should have been modified to render that code _in_ the documentation.
Doc tests are butt-ugly in several ways. Code shouldn't be written in strings, and they take twice as much vertical space as they need (which is a problem because monitors are typically used much wider than they are tall).
Re: Pyret: A new programming language from the creators of Racket
#217Earlier quoted context omitted.
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…
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.
Re: Pyret: A new programming language from the creators of Racket
#218Earlier quoted context omitted.
It's actually widely used in Racket already. Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading). Hardly "failure"s. Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before? Assertions are not t…
Have you thought about adding some kind of QuickCheck-ish model where test cases can be randomly generated for various types?
Yes, of course, we've thought about it. Equally importantly, we have a "satisfies" keyword for stating checks about properties. (See the example on the Pyret home page.) We use test oracles extensively in teaching; see these two assignments: http://cs.brown.edu/courses/cs019/2012/assignments/sortacle , http://cs.brown.edu/courses/cs019/2012/assignments/oracle .
Re: Pyret: A new programming language from the creators of Racket
#219Earlier quoted context omitted.
This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.
They didn't say one way or the other whether the language was pure FP, but I don't think any of the examples featured mutuality
Pyret is not pure. We have mutation. But mutation has its own syntax different from regular binding. Variables (as opposed to identifiers) are preceded by "var", and variable mutation uses ":=". [Similarly for fields.] This it to make clear to all forms of readers -- programmers, compilers, IDEs -- when something is mutable.
Re: Pyret: A new programming language from the creators of Racket
#220Earlier quoted context omitted.
This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.
Given that Pyret is functional, there's a good chance there will be an emphasis on simple, pure functions. Beyond that, I'd agree completely. Doctests, for instance, are quite terrible when you can't fit all of the logic into one line, but then I think it's usually a sign of a well-designed function when it's good a good enough interface to get a few pithy doctests in.
Though Pyret is not pure, our emphasis is heavily on "functional first", even for objects. We believe state should be used carefully and for good reasons. HtDP (www.htdp.org) has two whole chapters on state at the end, giving design recipes for their use, and I'm revising some of these in PAPL (papl.cs.brown.edu/2013/).