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

261–270 of 288 posts

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

#261

Post by skrishnamurthi »

stcredzero wrote: post #248
skrishnamurthi wrote: post #215

Earlier quoted context omitted.

Code Bubbles were invented one floor above me (by another team in computer science at Brown University). So, we're not at all unaware of it. And yes, it's great stuff. But we also had to make a conscious decision about IDEs, and we decided to be IDE agnostic -- IDEs should enhance the language but not be the only means of working with it, because programmers are really attached to their editors, and a language predic…

Code Bubbles were invented one floor above me (by another team in computer science at Brown University). I wrote a significant fraction of a Smalltalk class browser. IDEs should enhance the language but not be the only means of working with it, because programmers are really attached to their editors, and a language predicated on tearing people away from their editors will struggle. So, basically you made the pragmat…

I've had this argument for twenty years. I had my a-ha moment in grad school when, after I'd put a fair bit of work into a build system and showed it around, my advisor asked me, "What is a file?" And then I was enlightened. So I can play this song back with fairly good fidelity.

If I could get a reliable, efficient, cross-platform, extensible, quickly-ported-to-new-platforms environment that gave me rich editing, I'd grab it. I don't know of such a platform. So we made the "pragmatic" decision, yes. That's because this isn't the problem we're trying to solve.

We are actually trying to innovate in the programming environment space, and have been running with that experiment for the past semester internally at Brown. At some point, after it's been knocked around a bit more, we'll make it public. So we're not avoiding the environment space. But this is not a battle we're seeking to pick in that space.

I wish you luck with it, and hope we can build on the work of people like you.

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

#262

Post by skrishnamurthi »

geofft wrote: post #259
skrishnamurthi wrote: post #253

Earlier quoted context omitted.

Scheme makes it difficult because it more quickly gets you to teaching difficult ideas . This is an issue about SICP that most people simply never grok. Most courses don't cover a third of the concepts (if that) of SICP in the same amount of time. That's the book, not the language (and the only "fault" of the language is that it lets the book get that far that soon).

Yeah, 6.001 never covered the bulk of what the book covers. Still, I think Scheme is sufficiently different from mainstream programming languages that it's... like teaching git to a crowd composed half of SVN power users and half of people who have never copied a folder to folder.old in their life. You're balancing teaching "oh, here's how Scheme's different" from "oh, here's how you should have thought about it all…

I completely agree. In fact, this sort of two-track approach is what universities like Brown, WPI, etc. now do. Using the same ("weird") language at both levels works fine so long as you separate the crowd. Otherwise, as you very astutely point out, the two groups are asking completely different questions and answering them clearly and consistently is absurdly hard. Too bad MIT didn't think of this (or, presumably, did and rejected it for whatever good reason, that somehow doesn't seem to be applying to other places like Brown).

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

#263

Post by gruseom »

skrishnamurthi wrote: post #250
gruseom wrote: post #246

Earlier quoted context omitted.

Can you say more about how multiple return is "very subtle and hard to make performant" and leads to getting burned? As far as I can tell the main advantage of multiple-return over literal objects is that callers who only care about the primary value can call the function the normal way, whereas if it's wrapped in an object they have to "pay" for it by explicitly extracting it. That's a nice-to-have but you seem to b…

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 example. Maybe some twisted aspect of Common Lisp...

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

#264

Post by jpolitz »

garysweaver wrote: post #187
skrishnamurthi wrote: post #179

Earlier quoted context omitted.

As you wish! We now have two Ruby examples on the home page. You may not call it love. <-:

Thanks, but may want to correct: method_as_fun = o.my-method which should be: method_as_fun = o.my_method and the examples themselves just look a little crazy, imo. Not crazy because of what you are trying to do, but in how you are trying to do it. What was the intent of calling a method that defines an argument without an argument? That's not a problem of the language; that's just an error in coding. There are all k…

Thanks for the feedback. I think I responded to another comment that gave very similar feedback as you, so I'm just going to link to it here:

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

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

#265

Post by skrishnamurthi »

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…

No doubt. Things with optional arguments, keyword arguments, all sorts of contraptions like that. That's why we've studiously avoided such things.

Still, there's an asymmetry, at least to our minds, between calls and returns, so the argument put forth for multiple values ("a function can take multiple arguments, why can't it return multiple answers?" -- made especially compelling in a CPS context, because returns turn into calls) doesn't quite play out in practice.

Ergo, no multiple return values.

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

#266

Post by skrishnamurthi »

fedvasu wrote: post #233

sounds like ML+contracts, but wait is it statically typed? Maybe not Racket folks hate types (with great dredd)

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. (-:

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

#267

Post by [deleted] »

skrishnamurthi wrote: post #236
colanderman wrote: post #224

Earlier quoted context omitted.

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.

[deleted]

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

#268

Post by fedvasu »

skrishnamurthi wrote: post #266
fedvasu wrote: post #233

sounds like ML+contracts, but wait is it statically typed? Maybe not Racket folks hate types (with great dredd)

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.

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

#269

Post by lysium »

skrishnamurthi wrote: post #156
clhodapp wrote: post #115

Earlier quoted context omitted.

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

I can't respond directly to e12e's comment ("Please don't use equal for assignment" -- https://news.ycombinator.com/item?id=6704229 ) so I'll slightly abuse responding by doing so at this level. We don't EVER use = for assignment. For us, = is binding. If you write fun f(x): y = x * x y = x + 2 x - y end Pyret will say I'm confused: y is defined twice and point to the two bindings. The goal here is to make the common…

Thank you for distinguishing bindings and assignments. Please consider `var y := x * x` for consistency (note the ':=').

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

#270

Post by samth »

skrishnamurthi wrote: post #249
ufo wrote: post #230

Earlier quoted context omitted.

Thanks, in a way the non-answer is more useful than a real answer for me :)

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.
Post reply on HN