Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

201–210 of 288 posts

Re: Pyret: A new programming language from the creators of Racket

#201
post #23

"""Pyret makes testing a natural part of the programming process. Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.""" Fantastic idea! I'll keep that in mind, should be fairly easy to extend Lisps or other AST-Macro enabled languages (Elixir, Julia, Python) with such a functionality. I really like that. It makes it easy to work on a function and cod…

I'm not sure I like having tests in the same file with the code. In real code bases it's very common to just read the code, and cluttering that with huge swaths of unit-tests is counter-productive. That said, Pyret appears to be aimed at education so this may make more sense.

This is bouncing against the perpetual "code as text" problem.

Put the tests and docs in with the code and you end up going into "scanning" mode. The actionable information density per character is lower.

Put the tests and docs outside the code and you (or that obnoxious guy who just changed > to >=) don't update the tests or the docs. In the worst case (cough functional web tests) people tend to disable the tests because it's too much work to get them to conform to the changes and everyone is on fire and babies are dying and this needs to be done in production now.

Re: Pyret: A new programming language from the creators of Racket

#202
post #155

Earlier quoted context omitted.

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)

Re: Pyret: A new programming language from the creators of Racket

#203
post #11

Earlier quoted context omitted.

Contracts?

Every time you write a refinement on a type, you're actually writing a contract. You can gracefully move between types and contracts this way, and also between thinking of them as checked assertions vs tested ones. The goal is to make this migration more and more seamless.

Yes, I although I have used a multitude of dynamic languages on my career I tend to lean on the static type languages with type inference side.

Re: Pyret: A new programming language from the creators of Racket

#204
post #127

Earlier quoted context omitted.

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 t…

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 s…

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.

Re: Pyret: A new programming language from the creators of Racket

#205
post #84
post #10

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: 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 "def…

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.

Re: Pyret: A new programming language from the creators of Racket

#206
post #2

Python-like syntax with pattern matching and recursive ADTs!? What a great idea!

+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 limitat…

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/

Re: Pyret: A new programming language from the creators of Racket

#207
post #111
post #27

Earlier quoted context omitted.

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 tha…

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.

Re: Pyret: A new programming language from the creators of Racket

#208
post #7

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.

> The only languages have shorter grammars are core lisp/scheme.

Smalltalk would like to have a word with you: http://chronos-st.blogspot.be/2007/12/smalltalk-in-one-page....

Re: Pyret: A new programming language from the creators of Racket

#209
post #198

Earlier 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…

> Incidentally I don't know if that scoping example is intentionally ignoring the fact that Ruby does support lexical scoping (EDIT: for blocks), or if it's lack of understanding of what what "def" is

I also don't think it is fair to say that ruby "failed to nail lexical scope in fundamental ways".

I like how it enables lexical scoping with blocks, instead of enabling it in, maybe, more common way with embedded functions. To me, the ruby way is more intuitive.

Also, 'breaking scope' with block (that acts as anonymous function) instead of defining new (embedded) function feels more explicit wrt real scoping intentions.

Re: Pyret: A new programming language from the creators of Racket

#210

Earlier quoted context omitted.

I think the colon isn't a mistake, it clearly delineates an indented block; I think it's a great marker that indented languages might want to standardize on. Perhaps syntax issue is that it has both a colon and an "end" marker? The former indicates indentation-based syntax, the latter is often used in white-space agnostic contexts. The result of using both is confusion.

But if indentation matters, and it's pressent, then why do you need the colon?

Well, the colon can be used without indentation if the block that follows is just a single line:

  def embiggen(x): return x * 2
  for i in range(10): print(embiggen(x))
Also, it just makes things read more naturally to us humans, I think.
Post reply on HN