Pyret: A new programming language from the creators of Racket • Hacker News Board

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

#271

Post by samth » Mon, Nov 11, 2013, 12:54 PM UTC

fedvasu wrote: post #268

skrishnamurthi wrote: post #266

Earlier quoted context omitted.

It's gradually typed. Everything has both a static and dynamic account. We have a prototype type checker and a pre-prototype type inferencer. If Racket people "hate types", you'd have a hard time explaining the existence of Typed Racket, or that some of the most cited research on types is by one of Racket's creators. But please, don't let facts get in the way. (-:

Sorry Professor, there is only one person behind typed-racket Sam, AFAIK. typed racket isn't very well supported or documented or even advertised by racket folks.

If you're unhappy with our documentation, please let us know what would be helpful -- we know it isn't perfect, but specific requests are always helpful.

As for whether other people in the racket community like typed racket, the answer is clearly yes. if you look at recent work on racket, much of it integrates with or its motivated by, typed racket.

And there are a number of us who work on it currently. Have a look at the list of authors in the documentation.

Sam, creator of Typed Racket

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

#272

Post by b6fan » Mon, Nov 11, 2013, 12:55 PM UTC

skrishnamurthi wrote: post #192

b6fan wrote: post #185

The Ruby examples are unfair. Ruby intentionally makes parenthesis optional. So `do_something` is `do_something()`. For the first example, - method_as_fun = o.my-method - method_as_fun(5) # not reached + method_as_fun = o.method(:my_method) + method_as_fun.call(5) # or method_as_fun[5] And for the lexical scope thing, def f(x) g = ->y {x + y} g[2] end f(2) Or, explicitly use class variables, def f(x) @x = x def g(y);…

If one has to rewrite code like this, you're making our point.

The Ruby way is:

  1. common (not all) things are simple / elegant.
  2. Advanced things are doable, usually require a slightly more complex syntax.

For example, Ruby allows one "block" (anonymous function) per method. Why not 2 or more blocks? Because Matz has studied common lisp (likely, maybe something else) standard library and noticed that in ~97% (maybe not exact number) cases, one anonymous function is enough. But you can use more anonymous functions using a different syntax.

And here is the same case. People call methods much more often than to get the method. Therefore Ruby makes it default to call the method, but not stop you from getting the method object. It's just unfair to say Ruby cannot do these things.

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

#273

Post by skrishnamurthi » Mon, Nov 11, 2013, 1:09 PM UTC

samth wrote: post #270

skrishnamurthi wrote: post #249

Earlier quoted context omitted.

I'll read between the lines and just say, "Send us a link to your paper when it's done" (-:. In fact, we'd really love it if gradual typing folks would tell us what set of primitives they miss in a language. They aren't constrained to what Racket or Python or whatever; there may be a primitive that makes sense that Pyret can add to enable space-efficient, semantically-meaningful contracting or gradual typing in the p…

As one of those gradual typing folks, I'm not sure what you mean by "primitives we miss". The things I'd want for space efficiency are things like a contract language with decidable 'and', and for regular efficiency, a compiler that is good at seeing through wrappers.

Well, there's a preliminary answer!

Though I'm not enamored of the Typed Racket style of wrapping everything at the boundary (even as I appreciate why it's there). Not even hypothetical: we actually began developing Pyret in TR but, with great sadness, ended up having to move it out because of the enormous performance hits.

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

#274

Post by skrishnamurthi » Mon, Nov 11, 2013, 1:13 PM UTC

gruseom wrote: post #263

skrishnamurthi wrote: post #250

Earlier quoted context omitted.

1. Designing a performant multiple return values mechanism is very subtle. For instance, see J. Michael Ashley, R. Kent Dybvig: An Efficient Implementation of Multiple Return Values in Scheme. LISP and Functional Programming 1994: 140-149. 2. Write me the identity function. (No, really. Stop. Try. Then read on.) . . . . . I hope you didn't say it's fun id(x): x; because if F returns multiple values and G consumes the…

I hope you didn't say it's fun id(x): x; Well, I did. :) That's an interesting example. My first reaction was that one might be able to construct a similar anomaly by abusing optional arguments, but perhaps not: optional arguments to F don't get magically passed on to G. Still, I feel like I've seen function-signature constructs that would break the identity function similarly to how multiple-return does in your exam…

PS: Fun exchange for me, too!

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

#275

Post by skrishnamurthi » Mon, Nov 11, 2013, 1:22 PM UTC

fedvasu wrote: post #268

skrishnamurthi wrote: post #266

Earlier quoted context omitted.

It's gradually typed. Everything has both a static and dynamic account. We have a prototype type checker and a pre-prototype type inferencer. If Racket people "hate types", you'd have a hard time explaining the existence of Typed Racket, or that some of the most cited research on types is by one of Racket's creators. But please, don't let facts get in the way. (-:

Sorry Professor, there is only one person behind typed-racket Sam, AFAIK. typed racket isn't very well supported or documented or even advertised by racket folks.

In short, things are in a state of development, with limited resources. It's a big jump from that to say that Racket folks "hate types".

If you look at the "Start Quickly" section of racket-lang.org, right there is an example of Typed Racket. Your claim that it's "not advertised" would make sense if they'd somehow hidden it from that list.

There are several people contributing to Typed Racket. See the different names on the papers.

The documentation could be better. Sam's gotten some flames from me about that. But all documentation for just about everything could be better. (I'm hardly one to throw stones.) It usually takes about 10 years for a project's documentation to reach a state of suitable quality -- so comparing against the documentation for Java or Python or even Racket is really not fair. It just takes a long time to get this material together.

If you like Typed Racket -- which I do encourage you to study more -- do send mail to the Racket list. It's very active, and by asking questions, not only do you learn, you help others learn, and you give Sam and the others cues as to what it is they should be adding to the documentation.

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

#276

Post by jpolitz » Mon, Nov 11, 2013, 2:02 PM UTC

b6fan wrote: post #272

skrishnamurthi wrote: post #192

Earlier quoted context omitted.

If one has to rewrite code like this, you're making our point.

The Ruby way is: 1. common (not all) things are simple / elegant. 2. Advanced things are doable, usually require a slightly more complex syntax. For example, Ruby allows one "block" (anonymous function) per method. Why not 2 or more blocks? Because Matz has studied common lisp (likely, maybe something else) standard library and noticed that in ~97% (maybe not exact number) cases, one anonymous function is enough. But…

Thanks for the feedback! There are tradeoffs here, and I appreciate that it's a little glib to say things are necessarily right or wrong. I took down the scope example for now, but in relation to the method example, I posted some thoughts about why I disagree on this post:

https://news.ycombinator.com/item?id=6708420

See if that helps clarify my position for you.

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

#277

Post by samth » Mon, Nov 11, 2013, 2:05 PM UTC

skrishnamurthi wrote: post #273

samth wrote: post #270

Earlier quoted context omitted.

As one of those gradual typing folks, I'm not sure what you mean by "primitives we miss". The things I'd want for space efficiency are things like a contract language with decidable 'and', and for regular efficiency, a compiler that is good at seeing through wrappers.

Well, there's a preliminary answer! Though I'm not enamored of the Typed Racket style of wrapping everything at the boundary (even as I appreciate why it's there). Not even hypothetical: we actually began developing Pyret in TR but, with great sadness, ended up having to move it out because of the enormous performance hits.

But neither of those is a "primitive". The first is a major restriction on contracts (and not a restriction Pyret enforces, AFAICT). The second isn't a language feature at all. How would having a new language help give me either of these?

And yes, soundness + interoperation + structural types = heavy performance cost. You can give up on one of those easily, but the combination can't be free.

But the best way to make TR programs not pay that cost is to not cross the boundary all the time, which it sounds like is what you were doing. Why was that necessary?

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

#278

Post by alex_muscar » Mon, Nov 11, 2013, 4:18 PM UTC

skrishnamurthi wrote: post #239

e12e wrote: post #235

Earlier quoted context omitted.

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

Your point about programmers having favourite editors (which I consider valid) contradicts the point you made about an important part of your audience being middle/high schoolers, which I don't think have such strong preferences towards one editor or another. It seems to me that you are making compromises to cater to the needs of an audience which is much broader than that you have identified for the language.

It would be a shame to compromise the design of an interesting language just because the target audience is not clearly defined.

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

#279

Post by tel » Mon, Nov 11, 2013, 6:45 PM UTC

sitkack wrote: post #237

tel wrote: post #165

Earlier quoted context omitted.

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.

If that ended up nicely formatted beneath the definition of `foo` in the documentation I would recommend it wholeheartedly. In practice it doesn't happen, sadly.

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

#280

Post by andrewflnr » Tue, Nov 12, 2013, 12:47 AM UTC

stcredzero wrote: post #120

andrewflnr wrote: post #109

Earlier quoted context omitted.

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

The behavior carried around by those objects is ultimately in the form of flat digital data, interpreted by other, more general programs, executed on a CPU. Behavior, when it comes down to it, is a property of silicon, not data. This might seem like a useless distinction, but I don't think it is. I like to keep track of what things are underneath the abstractions.