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

111–120 of 288 posts

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

#111

Post by stass »

ek wrote: post #27
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 .

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 than possible using ordinary Python but still is in no way fit for something on the level of SICP.

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

#112

Post by kazagistar »

stcredzero wrote: post #98
driax wrote: post #41

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

While in some sense I agree with you, stuff like code bubbles is just a incremental step from folding. If you want better interfaces for your coding, you write bidirectional transformations between your representation and the text; the point being that the underlying representation does not particularly matter. Having underlying text, however, means you have a good fallback in case your tools do fail.

I would say the more potent point is that it should not matter at all if the tests are in the function or in a different directory: the IDE should be able to fold them in either way, and in some sense, IDEs already do have partial support for this.

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

#113

Post by kazagistar »

jpolitz wrote: post #110
kazagistar wrote: post #108

Somehow, it looks a lot more like lua with a bunch of type-checks and tests added then like python. No named parameters, no generators, no comprehensions that I can see, no focus on iteration in general, no significant indentation, etc. Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.

That's a useful comparison, thanks. While we were certainly inspired by Pythonic syntax, we have ended up somewhere slightly different. The note about local variables is particularly important; we actively don't want Python's model of variables and scope.

Note: this wasn't a criticism of your language: I rather prefer lua's way of doing numbers, co-routines, and even scoping to some degree. I was more criticizing your comparison.

The language itself looks pretty slick, and I am a sucker for gradual/optional typing. Do the type annotations result in performance/compiler optimization, as in Julia?

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

#114

Post by pygy_ »

kazagistar wrote: post #108

Somehow, it looks a lot more like lua with a bunch of type-checks and tests added then like python. No named parameters, no generators, no comprehensions that I can see, no focus on iteration in general, no significant indentation, etc. Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.

Indeed, but apparently, it doesn't have multiple return values, and I don't know if there is an equivalent to metamethods.

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

#115

Post by clhodapp »

lysium wrote: post #104
clhodapp wrote: post #48

Earlier quoted context omitted.

I feel that the argument for the need for multiline definitions here is a bit weak. You are already putting each definition on its own line, so the definitions are actually fairly close to how their actual usage will look. I feel that if you really need them to be all that long, you are already in weird-style territory, so it isn't such a bad idea to just say "deal with wide files". Overall, it improves ergonomics fo…

At the other end are definitions of which several fit on a single line: data Color = Red | Black

Lines really aren't much of a thing: they are a single keypress, which generates a newline character and some autogenerated indentation from your editor. There's no real difficulty in breaking things up across two lines versus typing any other extra character (this touches on another issue, which is that I am of the opinion that the concept of code brevity estimation by line count comparison is fundamentally flawed, as code with fewer wider lines is often just cumbersome to type as code with more narrower lines).

That said, please consider the following:

data Color = Red | Black

data Color { Red; Black }

data Color = Red | Black | Green

data Color { Red; Black; Green }

I think the brace + semicolon-newline style actually compares pretty favorably on single-line width (it wins out on line width to an increasing degree as the line gets longer, which is important). However, it is visually more complex, which matters a lot for shorter lines. For this reason, I think that allowing both syntaxes would be ideal. The pipe-based syntax could be encouraged for single lines (newline-termination would sidestep block-end inference issues), with the curly brace based syntax being encouraged for multi-line definitions. There is a slight disadvantage in that now a user would have to know both syntaxes, of course.

edit:

Of course, since Pyret's syntax requires that ADT parameters be specified in parentheses, you can actually omit the pipes in single-line mode, too, and opt to use space-juxtaposition.

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

#116

Post by jpolitz »

kazagistar wrote: post #113
jpolitz wrote: post #110

Earlier quoted context omitted.

That's a useful comparison, thanks. While we were certainly inspired by Pythonic syntax, we have ended up somewhere slightly different. The note about local variables is particularly important; we actively don't want Python's model of variables and scope.

Note: this wasn't a criticism of your language: I rather prefer lua's way of doing numbers, co-routines, and even scoping to some degree. I was more criticizing your comparison. The language itself looks pretty slick, and I am a sucker for gradual/optional typing. Do the type annotations result in performance/compiler optimization, as in Julia?

> Do the type annotations result in performance/compiler optimization, as in Julia?

We've been designing the static system with exactly this in mind. The current implementation doesn't do anything fancy yet, but that's just because we've been getting off the ground and focusing on ergonomics and curriculum first. Getting performance in return for types is absolutely where we're going.

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

#117

Post by jpolitz »

rhizome31 wrote: post #50
tel wrote: 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…

There's another response to this that I didn't mention. Shriram is writing a textbook that includes all the material for our advanced intro course and our programming languages course. There's a lot of good examples here:

http://papl.cs.brown.edu/2013/

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

#118

Post by stcredzero »

kazagistar wrote: post #112
stcredzero wrote: post #98

Earlier quoted context omitted.

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

While in some sense I agree with you, stuff like code bubbles is just a incremental step from folding. If you want better interfaces for your coding, you write bidirectional transformations between your representation and the text; the point being that the underlying representation does not particularly matter. Having underlying text, however, means you have a good fallback in case your tools do fail. I would say the…

> While in some sense I agree with you, stuff like code bubbles is just a incremental step from folding.

I said it was a "beacon in the direction we want to go," not a lighthouse at the destination!

> the point being that the underlying representation does not particularly matter. Having underlying text, however, means you have a good fallback in case your tools do fail.

Sure, do this, so long as the representation doesn't limit the objective capabilities of the environment and so long as it doesn't limit the ways tool makers think about code. Unfortunately, our current representations clearly do both.

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

#119

Post by lukeschlather »

amenod wrote: post #89
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.

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.

I really hate some things about the Rspec/Cucumber suite, but providing a way to output what the tests are testing as they run is a major advantage. I like being able to run my test suite and see "it does what it's supposed to do in this case" output.

At a glance, the Pyret default appears to be that tests run silently. How do I know the right tests were run?

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

#120

Post by stcredzero »

andrewflnr wrote: post #109
stcredzero wrote: post #98

Earlier quoted context omitted.

> 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 looks cool, but I don't see the connection with your point about clay tablets. Any digital data is, by itself, flat and behavior-less, whether it's in the form of traditional files or some specially-designed backing store for something like Code Bubbles. I don't see any point in really trying to hide that base reality. I am in favor of giving links between data a more prominent place in our storage syste…

> Any digital data is, by itself, flat and behavior-less, whether it's in the form of traditional files or some specially-designed backing store for something like Code Bubbles.

I know this is false. You can have a system where everything is an object and carries behavior around with it. We've had those for over 40 years.

> I am in favor of giving links between data a more prominent place in our storage systems.

A "more prominent place?" Isn't this a bit bass-ackwards? Aren't relationships in code where the primary value is?

Post reply on HN