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

81–90 of 288 posts

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

#81

Post by jpolitz »

gizmo wrote: 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…

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 more complex features. Annotations are not necessary on day 1, and neither are iterators. We write untyped, recursive-descent functions on lists in the beginning, and build up to types and the pleasant terseness of "for" loops. If Pyret required introducing these concepts to write any programs, that would indeed be a problem, but we've put thought into the dependencies between curricular concepts and the needed language constructs to mitigate exactly this concern.

2. I think that some of the features you listed are actually a huge necessity in early programming, particularly special purpose syntax for data structures. Teaching the definition and implementation of a balanced binary tree to folks without language experience in Python or Java requires a huge amount of boilerplate explanation. You need to describe classes, fields, and constructors just to do the equivalent of Pyret's "data". The alternative (at least in Python) is to encode everything in lists and dictionaries, but hopefully in 2013 we've moved beyond writing all our data structures that way :-)

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

#82

Post by tokenrove »

jashkenas wrote: post #57
stiff wrote: post #35

Earlier quoted context omitted.

I don't think the story of literate programming can be of any help predicting how well this idea here can work out. Literate programming is not "embedding documentation". The main idea was to separate the order in which the code is read from the order in which the compiler sees it, and it embeds the code in the documentation, not vice versa. It was a very idiosyncratic thing, hard to imagine a team of programmers in…

That's not the "main idea". Originally, it was a part of the suggested way to accomplish the goal ... but the main idea is this: > Let us change our traditional attitude to the construction of programs: > Instead of imagining that our main task is to instruct a computer what > to do, let us concentrate rather on explaining to human beings what we > want a computer to do. > — Knuth If your program can be read more as…

Right, but it's important to emphasize what stiff was talking about, that the structure of the narrative needs to be oriented towards the human instead of the machine, because so many people don't bother to do this and decide that literate programming just means having LaTeX or docbook comments in your code. That total inversion (the code is in the documentation, not the documentation is in the code) is important. (That said, I admit that most modern languages are so much more flexible compared to C or Pascal with regards the ordering of code.)

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

#83

Post by dragonwriter »

gizmo wrote: 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…

I don't see why a complex language can't be good for teaching if its designed in such a way that the complexity is optional, and you can use a focussed subset for pedagogical purposes (especially when the language supports using different focussed subsets depending on the specific focus of pedagogy.)

I mean, even if you look at how language like Scheme/Racket, or Python, or pretty much any other language is used in teaching, you don't usually use the whole thing in any one teaching context.

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

#84

Post by jpolitz »

klrr wrote: 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 "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.

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

#85

Post by tokenrove »

PhineasRex wrote: post #20
gizmo wrote: 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…

By that logic, assembly is the best language to learn programming. Presumably it is easier to learn about concepts with a language that has them.

Actually, there's a (devil's advocate) argument for teaching assembly first. After all, TAOCP is all assembly for good reason. Many programmers who never learn any assembly language lack a kind of procedural literacy, as well as a mechanical sympathy, which are a big part of the craft of programming.

But, as you state, there are a lot of higher-level programming concepts you can't effectively learn in assembler (one imagines a bizarrely circuitous route around learning to build compilers in assembly (via Forth perhaps) in order to teach lexical scoping or similar).

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

#86

Post by tbenst »

I took CS019 with Shriram a few years back and immediately guessed the authors based on paradigms like making testing a natural part of the language and the encouragement to use annotations. In the class, we were taught a design process for Racket that will work very well for Pyret:

1. Identify the data - create data definitions (You are gixen x and expected to produce y)

2. Write concrete examples of the data (This is hard and takes time)

3. Write contract, purpose, header for functions (contract and header are annotations in Pyret, purpose should be a commented statement)

4. Write concrete examples of the function (This is hard and takes time. This means test cases!)

5. Write the template (This may only apply to recursion in Racket, but the idea is if you're dealing with a cons, you always have the same structure of checking if a cons? or empty? and must recur)

6. Fill in the template (ie, complete the function)

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

#87

Post by amenod »

tel wrote: post #36
6ren wrote: post #16

Earlier quoted context omitted.

It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…

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.

Thank you! I never had any idea this kind of things exists in python... I can already see some code that would benefit from this (it would be insane to put it everywhere of course).

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

#88

Post by sitkack »

tel wrote: post #36
6ren wrote: post #16

Earlier quoted context omitted.

It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…

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.

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

#89

Post by amenod »

sparkie wrote: post #52
jacques_chester wrote: post #5

Earlier quoted context omitted.

D has something like this[1]. It might have come from a still-earlier language. [1] http://dlang.org/unittest.html

My biggest gripe with these is the inability to name the tests. What exactly is a unittest block testing for? You need to rely on comments or read the test code where none exists. Doesn't seem like Pyret fixed that issue.

That's an advantage in my book... it is testing the unit (function in this case) and it is testing all the corner cases... do you have a name for each of them? Description through comments is much more suitable IMHO.

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

#90

Post by sitkack »

skrishnamurthi wrote: post #80
sparkie wrote: post #52

Earlier quoted context omitted.

My biggest gripe with these is the inability to name the tests. What exactly is a unittest block testing for? You need to rely on comments or read the test code where none exists. Doesn't seem like Pyret fixed that issue.

Everything is fixable in a new language (-:. Say more!

Could the tests be more declarative, defining properties over a space?
Post reply on HN