Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

231–240 of 288 posts

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

#232

I can't find any documentation on the type system. In particular, I'm interested in how objects are typed (that they're both structurally typed and may be abstract is novel), and the capability of the type refinements. I loathe template-based OO due to the possibility of monkey-patching but the fact that objects are immutable looks like it might ease this. (Generating efficient code might still be difficult.) I don't…

The type system hasn't been published yet. We don't have monkey-patching. We've been burned too much by JavaScript and the like. Cyclic structures: think about trying to teach graph algorithms. Let's say you believe it's important to write tests. Many graph algorithms aren't inherently mutational. But you need mutation just to create examples of your data. The graph construct gets around this problem entirely, so mut…

But you need mutation just to create examples of your data.

OK, I'll buy this.

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

#234
post #202

Earlier quoted context omitted.

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

Sorry, my point was not to get into a popularity pissing match. I do believe popularity and quality are largely unrelated. What I meant is, since most people have stopped teaching with Smalltalk, it's really hard to do the kind of research I'm talking about! We had no trouble doing it for Racket because we were able to get lots of data and from it measure for statistical significance.

No worries, I understood that. I just thought you were in a great position to actually preform such a study, if you were willing to run it on a group of students :-)

I can certainly understand why you wouldn't "just try Smalltalk on a class or two", though!

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

#235
post #145

Earlier quoted context omitted.

I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further a…

I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word…

> Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them.

I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag? (you type case, the editor appends esac (but below the point you're typing)):

    1:   |   #your cursor at |

    2: case|
    
    3: case:
         |     # you hit enter or something, ready to fill in
       esac    # editor has closed block/statement
I imagine typing-skills isn't much of an issue when editing/copying text -- as opposed to typing in new code?

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

#236

Earlier quoted context omitted.

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…

I am also convinced that parenthetical syntax has real problems that I can't completely ignore. What brought you to this conclusion? Experience from Bootstrap (in which I found arithmetic and parenthesis counting to be the biggest stumbling blocks) or just personal reflection?

All of the above, plus the research that Guillaume Marceau, Kathi Fisler, and I did.

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

#237
post #165
post #88

Earlier quoted context omitted.

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.

Which it totally is! That is why all the functions I test are in pairs suitable for nose or py.test

    def test_foo():
        assert False, "test code for foo"

    def foo(farb):
        pass
Tests should absolutely be next to the code. The test should make it into the documentation. Code is documentation and should make it into the generated documentation, not the first thing you see but it should be there along with commit history, etc.

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

#238

Earlier quoted context omitted.

If you need guideposts, use an editor with paredit support and rainbow delimiters. This makes Lisp feel far more intuitive and tree-like than normal.

You seem to be under the impression I haven't programmed in Lispy languages. And our data are from students using DrRacket, which very much has paredit support. These are just inconvenient truths.

DrRacket is a very big language. How does it compare with using a much smaller language such as the Scheme used in SICP?

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

#239
post #235

Earlier quoted context omitted.

I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word…

> Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag…

An express design goal is to not bake in assumptions about an editor. Programmers really like their editing tools. I've lived through the waves from vi to Emacs to vim to Sublime Text to what-have-you. We'd really, really like to make the language pleasing to work with without depending on an editor (indeed, each of us seems -- perhaps by accident -- to be using a different editor for Pyret, which may be influencing our decision).

When editing/copying, it's not typing skills but editing skills, which are arguably subtler and even harder.

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

#240
Pyret looks very promising. Keep on the good work!

But please remove the minus sign from identifiers! I am concerned that people may abstain from Pyret for this simple reason. It is really annoying to embrace every operator with blanks. That should be an optional job for the IDE to increase readibility.

By the way, is there already a raco exe for Pyret?

Post reply on HN