Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Pyret Programming Language

pyret.org

Post reply on HN
Print view View original

81–90 of 138 posts

Re: The Pyret Programming Language

#81

Post by skrishnamurthi »

teruakohatu wrote: post #3

I really like the in-function documentation and unit like testing in the where clause. > # this is true > ((1 / 3) * 3) == 1 This worries me. I know it is true mathamatically, but experience tells me trusting floats is a recipe for disaster. A approximate equal operator is safer. Floats are such a leaky abstraction it is in my opinion better students know this early on.

You should try it and see what it does when you force it to use floats. You may find it interesting in light of your "leaky abstraction" comment. Pyret is designed precisely to make that point clear.

Re: The Pyret Programming Language

#82

Post by skrishnamurthi »

Maksadbek wrote: post #55

The syntax is pretty much like Python and ruby: “end” to declare end of block statements and colon to start a block statement. But why to use “fun” to declare a function when “def” could be used. The same in other languages: function, func, fun, fn, etc.

Because `def` suggests there is only one kind of thing we're defining (functions), when we could be defining any number of things: functions, type aliases, algebraic datatypes, tests, etc. So we use `fun` for functions, and different keywords (e.g., `examples` for examples) for other things. You should really be questioning why `def` was used for functions.

Re: The Pyret Programming Language

#83

Post by skrishnamurthi »

cormacrelf wrote: post #63
xpe wrote: post #49

Earlier quoted context omitted.

> Knowing who they are, I would happily assume that they spent plenty of time debating this exact issue of mixing kebab case with infix subtraction, and either decided the benefits were worth the cost or else decided that the cost was practically nonexistent. We don't need to assume when we can search. I did a few minutes of searching and found the following: https://groups.google.com/g/pyret-discuss/c/rPe7gYBLdPs/m/…

It only makes more sense when you do look at the background, so thanks for the link. They're lisp folks. They use kebab-case. I completely get it. It may be the product of decades of research, but it is also the product of default choices and comfort for the people who wrote it. ALL programs have an element of this: I write Rust and you can tell without looking when some tool is written in it -- TOML config? Apache-2…

I understand where you're coming from. Feedback and engagement noted and appreciated.

But I stand by my remarks from 2013 in 2021. I've now had well over 1000 students go through Pyret (in addition to tens of thousands elsewhere). We've also spent hours and hours literally watching new learners work with the language. I can assure you that of the many, many, many issues that have percolated up to us, spaces-around-binops has literally not a single time been one. If anything, when people write that and we say "just put spaces around the `-`", the response is, "Oh, okay", and people move on.

So, we feel very good about this decision. And I, personally, actually really like how it makes code read.

Re: The Pyret Programming Language

#84

Post by skrishnamurthi »

cormacrelf wrote: post #22
nostrademons wrote: post #20

Earlier quoted context omitted.

Dylan had kebab-case idents and infix operators. It worked okay because you have to separate infix operators with a space anyway; omitting it is a syntax error. In practice I doubt this would trip me up because every coding standard I've worked with has mandated spaces around infix operators. I suppose it might be a lot more confusing if you're used to coding standards that allow you to omit them, but my understandin…

Maybe it would be okay with syntax highlighting and a careerful of code formatting muscle memory, but how would that fare in an educational context? > "Pyret is a programming language designed to serve as an outstanding choice for programming education"

It's been working great, actually.

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

Re: The Pyret Programming Language

#85

Post by skrishnamurthi »

xpe wrote: post #40
gigatexal wrote: post #24

I like the idea of the where clause to include tests.

I don't care for the name "where" since it makes me think that is is a place to define bindings, like Haskell. I would prefer a term like "expect" or "tests".

It doesn't read fluidly. We care a lot about how our programs are verbalized.

We were well aware of the Haskell use, but most of our users have not seen or even heard of Haskell before. So that's not a real problem here.

People who don't have Haskell experience find it utterly unsurprising that what follows `where` are the examples/tests. So I think your expectation is being set overly by your Haskell experience.

Re: The Pyret Programming Language

#86

Post by skrishnamurthi »

cabalamat wrote: post #31
DonaldPShimoda wrote: post #25

Earlier quoted context omitted.

Always requiring whitespace around infix operators is, in my opinion, easier to explain to people than "you can do whatever you want with the whitespace." It's consistent and regular. I don't think it's as much of an issue as you're making it out. Pyret is the result of decades of research in computer science education, helmed by Shriram Krishnamurthi, who was one of the original members of the Racket project (itself…

> Always requiring whitespace around infix operators is, in my opinion, easier to explain to people than "you can do whatever you want with the whitespace." It might be easier to explain, but it also makes the code look ugly. Consider the expressions: a := b + c*d if e > f-g then ... Here the * and - are more tighly bound than the + or >, and I'm using the whitespace to make that obvious.

But if you write instead

  a := b+c * d
you aren't going to get an error. You're just going to get awfully surprising behavior, because you may think you were expressing one precedence with the spaces but the language has its own mind and doesn't care.

In contrast, Pyret doesn't bind anything more tightly than anything else. You parenthesize to make your intent clear.

If your expression gets too large, you should consider breaking it down with names for the intermediates. That will improve its readability by others anyway.

Re: The Pyret Programming Language

#88

Post by dTal »

I was excited that Pyret, which I was previously familiar with as a Racket #lang, had evidently gained enough independence to warrant its own website that does not even mention Racket. What a vindication of the #lang system! Then I read this:

"Ultimately, Racket’s #lang facilities, though designed to create new languages—and a great prototyping ground for Pyret—proved to not be quite enough to support a language creation process of the scale of Pyret"

I find this rather sad. The PLT group, dogfooding their flagship product's unique selling point, was not able to achieve their goals and switched to Javascript. I hope that one day it may once again be a Racket #lang.

Re: The Pyret Programming Language

#89

Post by IshKebab »

skrishnamurthi wrote: post #78
eterevsky wrote: post #50

> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2

I've used rationals by default in Racket/Scheme for literally 3+ decades now. It's fine. Dart is trying to be an industrial-strength language. We're trying to create an awesome initial programming experience. To the beginner, those denominators are nowhere near as much of a problem as "numbers" that don't make sense. But we draw limits. Did you try the `sin(pi / 6)` example? You'll find that Pyret produces a rather i…

I'm a bit dubious that magic stuff like this really makes anything easier. It's like JavaScript's truthiness and type coersion. It's trying to be friendly and work most of the time, but in reality it is more complex because now you have to remember a whole set of rules about how exactly the magic behaves.

Re: The Pyret Programming Language

#90

Post by lifthrasiir »

eterevsky wrote: post #50

> # this is true > ((1 / 3) * 3) == 1 This is a slippery slope. Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially. Also, I seriously doubt you can make a language that will correctly resolve checks like this one: sin(pi / 6) == 1 / 2

> Early versions of Dart tried to use rational numbers by default, but then it was cancelled because denominator size can grow exponentially.

While I'm generally in favor of rational numbers as a default and believe that its "danger" is no different from that of big integers, there is some truth in this because Guido van Rossum of the Python fame has said the same thing [1]. It seems that you need some adjustments if you are already familiar to languages where rational numbers are not default.

[1] https://python-history.blogspot.com/2009/03/problem-with-int...

Post reply on HN