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

101–110 of 138 posts

Re: The Pyret Programming Language

#101

Post by psykotic »

skrishnamurthi wrote: post #86
cabalamat wrote: post #31

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

A space-aware syntax can allow optional spacing around operators but make it an error if it does not respect the precedence hierarchy or is deemed inconsistent by other rules.

Re: The Pyret Programming Language

#103

Post by chakkepolja »

Ericson2314 wrote: post #27
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…

Yes not requiring spaces around infix operators is terrible even when there is no ambiguity. Frankly, everything about programs-as-text is terrible for beginners, but this softens the blow.

I disagree that programs-as-text is bad idea for beginers. Anyone with a bit of abstract thinking can understand program as text just like how they can understand a multi step mathematical operation.

Re: The Pyret Programming Language

#104

Post by chakkepolja »

mlazos wrote: post #75
gsliepen wrote: post #71

Earlier quoted context omitted.

C++17 added std::variant ( https://en.cppreference.com/w/cpp/utility/variant ) and other types so algebraic data types are now officially part of the standard. Of course, it's not as compact to write as in Pyret, especially since there's no pattern matching switch statement (yet).

they do have the godforsaken visit function which requires you to write the lambda syntax for each variant type, I end up writing chained if’s 99% of the time because it’s clearer.

There's another way using switch if I recall properly.

That said I don't like C++'s library additions just to stay modern. They are not expressive, increase build times, make debug builds slower and can fail compiler optimizers.

Re: The Pyret Programming Language

#105

Post by cormacrelf »

skrishnamurthi wrote: post #83
cormacrelf wrote: post #63

Earlier quoted context omitted.

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

Hey, thanks for the reply. The discussion has been centred on explaining why you have to type the spaces, but I never really cared about that -- my problem was with reading. That's my fault, the usual complaint about whitespace sensitivity is about having to type it, and this is different. I'm talking mixed kebab-idents and really any math operators in the same expression. Unrealistic example but: `(n-1 + n-2) / (n-1 - n-2)`. We may naturally differ on that through familiarity, but it really does get my brain stuck. It doesn't surprise me at all that the mechanics of adding spaces were so easy to learn, but I'm not totally convinced you would have received explicit feedback on readability from students who don't have much to compare to. On the flipside, if you don't get feedback on reading tricky numeric expressions, then they don't care, it doesn't come up for beginners as they're not optimising sqrt routines, and it doesn't matter to a language made for them. I think that's the end of the road.

On the binops, it may be that forcing whitespace around them is a good idea even for a language without kebab-idents, and perhaps the risk you took there was worth it to find that out. I could get around a world in which C's `a & b` and `&ptr` were completely incompatible. (I'm sure you could find a CVE or two for that one.) Heck, every code formatter out there does it. Compared to some suggestions around here and apparently back in 2013 as well to ditch BODMAS, the one bit of math that everyone on the planet learns in school, in favour of whitespace-sensitive precedence... goodness me. Give me forced spaces around binops any day.

Re: The Pyret Programming Language

#106

Post by trombonechamp »

odipar wrote: post #58
trombonechamp wrote: post #54

I love this. I think people often underestimate the value of dynamic runtime checks. For certain applications, e.g. many types of scientific/exploratory software, dynamic checks and static checkcs have nearly identical utility. But static checks can get really tricky to work with as a developer. I built a library for doing modular runtime verification in Python ( https://github.com/mwshinn/paranoidscientist ) and eva…

hey, I like your work on Paranoid Scientist. I've never come across hyper-properties: is this something you invented? Regarding hyper-properties: I assume they only work on immutable data values, otherwise it would be hard to manage historical objects so that they can be part of any of the predicates. I'm working on a similar project that you may find interesting: https://odipar.github.io/manikin/ . I may want to inc…

Glad you like Paranoid Scientist, and thanks for the link to your project!

Yes, you're right that it only works on immutable data types. At first I had implemented something which copies the object, but this used way too much ram and ended up being quite buggy with a lot of edge cases.

I didn't invent the term hyperproperties (sadly). If you do end up implementing hyperproperties in runtime checks, you'll definitely want to look into to doing a statistical approach. The key to making this work is reservoir sampling (https://en.wikipedia.org/wiki/Reservoir_sampling) - there are some more details of how I did this in the Paranoid Scientist paper (https://arxiv.org/abs/1909.00427).

Re: The Pyret Programming Language

#107

Post by cormacrelf »

scns wrote: post #68
cormacrelf wrote: post #63

Earlier quoted context omitted.

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…

That could be fixed by checking the identifier for valid operators and offer: "Did you mean a - b?"

It seems obvious now, but that's not low hanging fruit, and even when you think to do it, it's not easy to do. It took and is still taking real ingenuity and hard work from Rust folks to do. Their syntax trees are insane, they carry so much information around to make these kinds of messages possible. Every source of ambiguity in intent adds to the problem. Making binops work only with whitespace is an easy change to the parser; telling people as you look over their shoulder is also easy. Producing this error message when it is valid syntax and means something else is a different beast entirely. For a general purpose language I just wouldn't recommend it when you have an easy choice available to avoid the ambiguity in intent. It will save so much work if you aspire to have better errors.

Re: The Pyret Programming Language

#108

Post by Ericson2314 »

chakkepolja wrote: post #103
Ericson2314 wrote: post #27

Earlier quoted context omitted.

Yes not requiring spaces around infix operators is terrible even when there is no ambiguity. Frankly, everything about programs-as-text is terrible for beginners, but this softens the blow.

I disagree that programs-as-text is bad idea for beginers. Anyone with a bit of abstract thinking can understand program as text just like how they can understand a multi step mathematical operation.

I'm no expert on education, but having been a TA and helped out a few people since, I repeatedly see text getting in the way of everything else.

Beginners often find both the things you are saying some what hard.

First, note that there is reading vs editing. Perhaps in grade school people learn to parse large expressions (though I find that people generally are not prepared well, because grade school expressions are too small). But editing code and keeping track of what changes you made --- essential to debug your first programs --- is much more new to people who are used to just rewriting a few short algebra expresions with pencils. It's then, when the beginner is most mentally taxed, that the syntax errors creep in --- and further interrupt their thinking process.

Hopefully we can agree the second challenge is completely fundamental to the field, while the first however is just an artifact of the way things are implemented today. Well, based on the above scenario and others I repeated see the cognitive burden of the first interrupting the second, and so student waste effort and loose focus over "easy stupid text syntax", and therefore long delay mastery of trees, term rewriting and substitution in particular, etc.

Re: The Pyret Programming Language

#109

Post by still_grokking »

odipar wrote: post #58
trombonechamp wrote: post #54

I love this. I think people often underestimate the value of dynamic runtime checks. For certain applications, e.g. many types of scientific/exploratory software, dynamic checks and static checkcs have nearly identical utility. But static checks can get really tricky to work with as a developer. I built a library for doing modular runtime verification in Python ( https://github.com/mwshinn/paranoidscientist ) and eva…

hey, I like your work on Paranoid Scientist. I've never come across hyper-properties: is this something you invented? Regarding hyper-properties: I assume they only work on immutable data values, otherwise it would be hard to manage historical objects so that they can be part of any of the predicates. I'm working on a similar project that you may find interesting: https://odipar.github.io/manikin/ . I may want to inc…

> https://lamport.azurewebsites.net/pubs/hyper2.pdf

What the parent post talks about is not even close what is described in that PDF above.

"Proving" (or better verifying) stuff at runtime is trivial as it's only some asserts at the end.

Analyzing the properties of programs before you run them is in an entire different league OTOH.

Post reply on HN