Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

Post reply on HN
Print view View original

161–170 of 288 posts

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

#161

Post by skrishnamurthi »

ricw wrote: post #68
rhizome31 wrote: post #50

Earlier quoted context omitted.

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

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…

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.

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

#162

Post by skrishnamurthi »

chongli wrote: post #46
andybak wrote: post #12

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

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.

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

#163

Post by skrishnamurthi »

klrr wrote: post #29
andybak wrote: post #12

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

Lisp syntax is ( ) 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).

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

#164

Post by lmm »

skrishnamurthi wrote: post #160
lmm wrote: post #151

Earlier quoted context omitted.

If you're looking for a more mature language that feels like that, I very much recommend scala.

Scala is statically typed through-and-through. Pyret is designed to always offer a dynamic account of the language. We do have a static type checker under development (it's all-but-ready to release), but it will always work over a language where type annotations are optional. We also have a radically different idea about type inference, which we are currently trying out. In short, Pyret and Scala are already quite di…

I'd be interested in seeing some more explicit examples of the differences, because I get a very scala-like vibe from all the examples in the article (I accept that dynamic vs static is a fundamental difference that doesn't really show up in syntax).

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

#165

Post by tel »

sitkack wrote: post #88
tel wrote: post #36

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

I agree with you in that managing real code in a place that gets less frequently executed is a bear, but I wanted to emphasize the value of having tests very near to the primary documentation for a function. That's a complete win, I feel.

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

#166

Post by skrishnamurthi »

pcmonk wrote: post #142

I wonder how well this integrates with Racket? I see that it's built with Racket, but I'd be curious if I could mix and match this with all my Racket code.

That is not an explicit design goal, because we feel that would be too restrictive -- we may even diverge semantically. We are in fact working on compilers for the language that don't involve going through Racket (though Racket is so awesome, it's not a given that this will be any better -- these are all just experiments in progress). But without Racket's #lang, which is absolutely a rock star language creation mechanism, Pyret probably wouldn't exist.

In short, though, sorry, we can't commit to helping you interop with your existing Racket code. But you're already in Racket, so life is probably as good as it's ever going to get. (-:

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

#168

Post by tel »

anaphor wrote: post #102
skrishnamurthi wrote: post #77

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

This exists in Haskell's doctest library

    -- | Documentation goes here
    --
    -- > 2 + 2 == 4
    -- True
    --
    -- prop> \lst -> reverse (reverse lst) == lst

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

#169

Post by tel »

mercurial wrote: post #124
skrishnamurthi wrote: post #77

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

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.

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

#170

Post by ufo »

skrishnamurthi wrote: post #79
ufo wrote: post #21

Earlier quoted context omitted.

Racket has a very powerful contract system that you might want to out. It also has support for higher-order contracts on functions (contracts that have delayed checks instead of being just assertions) and they also have a typed version of Racket (Typed Racket) built using the contract system.

Some of the Pyret designers are part of the Racket community, and know these ideas well. Where Pyret differs is that Racket has two different languages (for the purposes of this discussion), Racket and Typed Racket, and a program has to live in one or the other. Whereas Pyret takes a different "gradual" philosophy to type annotations, so a program doesn't have to move between the two languages.

I was just trying to point out that Pyret is not inventing the contract-checking and that Racket, the language Pyret owes a lot to, already has the contract system terhechte was looking for. Maybe I should have been more clear.

That said, I'm going to take the opportunity to ask a question: does Pyret's gradual typing cover parametric polymorphism and mutable data structures? Those usually are specially though to do in these fully gradual systems so I'm curious what you guys have done about that.

Post reply on HN