5 ms·

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

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 a language designed for CS education in the '90s, a descendant of Scheme with kebab case and prefix notation). The full list of authors of Pyret is lengthy, but includes a number of well-established researchers in the PL and CSed communities. 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. In any case, I trust their decisions better than those of someone who glanced at the website only long enough to inform a condescending (and highly superficial) comment on Hacker News.

Ericson2314 5y ago
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.
- chakkepolja 5y ago
  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.
  - Ericson2314 5y ago
    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.
    - chakkepolja 5y ago
      To be clear, I am no education expert either and it was my personal opinion. Maybe I have been around the people naturally good at math, and everyone found scratch clumsy and irritating than python. Python was pretty natural for them.
cabalamat 5y ago
> 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.
- scns 5y ago
  Beauty lies in the eye of the beholder, ie aesthetics are subjective. For me, using proximity instead of parentheses to signify grouping would raise an eyebrow. I'd make an exception for cases of base*exponent, i think Python has it?
  - cabalamat 5y ago
    > Beauty lies in the eye of the beholder, ie aesthetics are subjective. Then allow everyone to do things according to their own aesthetics.
    - verdagon 5y ago
      I personally appreciate when languages have a consistent style. I think on the whole it helps readability more than it hurts. We're enforcing whitespace around infix operators in Vale, and it's working pretty well. It's also enabling us to use <> for generics with no ambiguity =)
    - scns 5y ago
      Sure. In math education i learned to signify grouping with parens and in this case i would favour function/consistency over form/typing efficiency.
  - scns 5y ago
    Need to reply to myself for correction since it is to late to edit. It should say base*exponent. I think other languages use base^exponent, which would be fine with me too.
xpe 5y ago
> In any case, I trust their decisions better than those of someone who glanced at the website only long enough to inform a condescending (and highly superficial) comment on Hacker News. I didn't interpret it as condescending. > (and highly superficial) I didn't interpret it as highly superficial. Comments about the appearance (including whitespace, kebab-case, and infix operators) of a language are fair game, particularly if it is intended for teaching.
xpe 5y ago
> 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 a language designed for CS education in the '90s, a descendant of Scheme with kebab case and prefix notation). The full list of authors of Pyret is lengthy, but includes a number of well-established researchers in the PL and CSed communities. On one hand, this historical context is relevant. Thanks for sharing it. On the other hand, when this section is taken in context with with the following sentence... > 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. ...it looks the fallacy of appealing to authority. Many people like to debate the ideas and tradeoffs, not the credentials of people involved.
xpe 5y ago
> 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/3OI31eSOpAAJ https://groups.google.com/g/pyret-discuss/c/rPe7gYBLdPs/m/3O... Shiriam K. wrote in 2013: > I have tried just about every possible experiment to stay closer to Lisp, including even the one you have in Wart. None of them scaled well for me. Ultimately, also, I am totally unconvinced about the idea of having an identifier named e^ipi-1 for anything other than cute illustration purposes. Since surface* syntax is designed for humans, I think a compromise between expressiveness, readability, and predictability is a good way to go. (This is just one comment, I'm not saying that is captures the full thinking and discussion around these syntax decisions.)
- cormacrelf 5y ago
  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.0/MIT dual-licensed? Few such decisions have no downsides, and yet exceptions are rare. It takes a lot to make a choice for reasons other than your own familiarity. From the linked thread, they clearly agonized over this. Apparently they talked themselves down from the usual Lisp ultra-permissiveness on idents, so good on them -- but it was still explicitly a compromise between their comfort and the aims of the project. There is an obvious and very good reason why the number of languages that do this can be counted on one hand. The authors know that. It is a problem they decided to accept because it was the default for them, and they "just couldn't give up on how pleasing hyphens in identifiers are to the eye and the shift-finger", and then mitigated it via other whitespace changes. They were content when "Anecdotally, no one in our courses ha[d] complained". I disagree with it. I find it really hard to read. I guess I am used to other languages, but so is everyone who has dabbled in python, likely writing primarily numeric code for their stats/bio/physics courses. Consider me a student reporting it as a problem. Consider the 2013 thread a student reporting it as a problem as well. How about that? I'll finish with a quote from Krishnamurthi himself: "Saying 'add spaces around binops' is easy to learn, recognize, and implement." Does this not speak for itself? fun subtract(a, b): a-b end >>> The identifier a-b is unbound: definitions://:3:2-3:5 4 | a-b It is used but not previously defined. Edit: I dug up an old thread from the guy @estebank who makes all the amazing Rust error messages, responding to a paper of Krishnamurthi's that argues, true to form, that you shouldn't ever actually "Say 'add spaces around binops'" (https://twitter.com/ekuber/status/1140791186858266624 https://twitter.com/ekuber/status/1140791186858266624). The paper itself is an interesting read, particularly the interviews where beginners don't have the vocabulary to decipher error messages. But I think Esteban is right.

Ericson2314 5y ago

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.

chakkepolja 5y ago
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.
- Ericson2314 5y ago
  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.
  - chakkepolja 5y ago
    To be clear, I am no education expert either and it was my personal opinion. Maybe I have been around the people naturally good at math, and everyone found scratch clumsy and irritating than python. Python was pretty natural for them.

cabalamat 5y ago

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

scns 5y ago
Beauty lies in the eye of the beholder, ie aesthetics are subjective. For me, using proximity instead of parentheses to signify grouping would raise an eyebrow. I'd make an exception for cases of base*exponent, i think Python has it?
- cabalamat 5y ago
  > Beauty lies in the eye of the beholder, ie aesthetics are subjective. Then allow everyone to do things according to their own aesthetics.
  - verdagon 5y ago
    I personally appreciate when languages have a consistent style. I think on the whole it helps readability more than it hurts. We're enforcing whitespace around infix operators in Vale, and it's working pretty well. It's also enabling us to use <> for generics with no ambiguity =)
  - scns 5y ago
    Sure. In math education i learned to signify grouping with parens and in this case i would favour function/consistency over form/typing efficiency.
- scns 5y ago
  Need to reply to myself for correction since it is to late to edit. It should say base*exponent. I think other languages use base^exponent, which would be fine with me too.

xpe 5y ago

> In any case, I trust their decisions better than those of someone who glanced at the website only long enough to inform a condescending (and highly superficial) comment on Hacker News. I didn't interpret it as condescending. > (and highly superficial) I didn't interpret it as highly superficial. Comments about the appearance (including whitespace, kebab-case, and infix operators) of a language are fair game, particularly if it is intended for teaching.

xpe 5y ago

> 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 a language designed for CS education in the '90s, a descendant of Scheme with kebab case and prefix notation). The full list of authors of Pyret is lengthy, but includes a number of well-established researchers in the PL and CSed communities. On one hand, this historical context is relevant. Thanks for sharing it. On the other hand, when this section is taken in context with with the following sentence... > 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. ...it looks the fallacy of appealing to authority. Many people like to debate the ideas and tradeoffs, not the credentials of people involved.

xpe 5y ago

> 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/3OI31eSOpAAJ https://groups.google.com/g/pyret-discuss/c/rPe7gYBLdPs/m/3O... Shiriam K. wrote in 2013: > I have tried just about every possible experiment to stay closer to Lisp, including even the one you have in Wart. None of them scaled well for me. Ultimately, also, I am totally unconvinced about the idea of having an identifier named e^ipi-1 for anything other than cute illustration purposes. Since surface* syntax is designed for humans, I think a compromise between expressiveness, readability, and predictability is a good way to go. (This is just one comment, I'm not saying that is captures the full thinking and discussion around these syntax decisions.)

cormacrelf 5y ago
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.0/MIT dual-licensed? Few such decisions have no downsides, and yet exceptions are rare. It takes a lot to make a choice for reasons other than your own familiarity. From the linked thread, they clearly agonized over this. Apparently they talked themselves down from the usual Lisp ultra-permissiveness on idents, so good on them -- but it was still explicitly a compromise between their comfort and the aims of the project. There is an obvious and very good reason why the number of languages that do this can be counted on one hand. The authors know that. It is a problem they decided to accept because it was the default for them, and they "just couldn't give up on how pleasing hyphens in identifiers are to the eye and the shift-finger", and then mitigated it via other whitespace changes. They were content when "Anecdotally, no one in our courses ha[d] complained". I disagree with it. I find it really hard to read. I guess I am used to other languages, but so is everyone who has dabbled in python, likely writing primarily numeric code for their stats/bio/physics courses. Consider me a student reporting it as a problem. Consider the 2013 thread a student reporting it as a problem as well. How about that? I'll finish with a quote from Krishnamurthi himself: "Saying 'add spaces around binops' is easy to learn, recognize, and implement." Does this not speak for itself? fun subtract(a, b): a-b end >>> The identifier a-b is unbound: definitions://:3:2-3:5 4 | a-b It is used but not previously defined. Edit: I dug up an old thread from the guy @estebank who makes all the amazing Rust error messages, responding to a paper of Krishnamurthi's that argues, true to form, that you shouldn't ever actually "Say 'add spaces around binops'" (https://twitter.com/ekuber/status/1140791186858266624 https://twitter.com/ekuber/status/1140791186858266624). The paper itself is an interesting read, particularly the interviews where beginners don't have the vocabulary to decipher error messages. But I think Esteban is right.