Pyret – A language exploring scripting and functional programming • Hacker News Board

Re: Pyret – A language exploring scripting and functional programming

#111

Post by jhbadger » Thu, Dec 15, 2016, 7:11 PM UTC

nnq wrote: post #96

natec425 wrote: post #61

Earlier quoted context omitted.

Do you have any measurable (preferably peer-reviewed) evidence that suggests imperative programming is inherently easier? That sounds like a challenging claim to make.

> a challenging claim to make ...or more like the obvious intuition and wisdom of 99% of working software developers. The intuition is not backed up by any peer-reviewed evidence but by the real world fact that most production code ends up written in C++, Java, C#, JavaScript, PHP, Python,Ruby etc. and not Haskell, OCaml, F#, Clojure etc. Since they made the first stone tools and cave drawings, humans have always def…

Based on ancient literature and holy texts, people from early cultures seemed to be obsessed with their lineage, stating "I am X son of Y, who was son of Z" etc. Do you think they thought about it in terms of procedures for determining lineages or just definitions of relationships? The latter would be easier to model in languages like Prolog rather than C++ or Java.

Re: Pyret – A language exploring scripting and functional programming

#112

Post by CodeMage » Thu, Dec 15, 2016, 7:13 PM UTC

samcal wrote: post #105

simplify wrote: post #95

Earlier quoted context omitted.

The problem is overblown. It's not going to cause any deep, hard-to-debug errors. If you accidentally type `a-b`, you'll get an error message that says "a-b is not defined". Fix it and you're done.

While I agree that the problem is not a very big deal, I think that you might be surprised how difficult understanding compiler errors can be for newcomers.

I regard that as a valuable teaching moment: "This, kids, is a great example of what you'll have to deal with all the time. Computers are not smart and neither are compilers. Forget a semicolon or some whitespace, and it's your job to clean up the mess after your compiler shits its bed."

Re: Pyret – A language exploring scripting and functional programming

#113

Post by jpolitz » Thu, Dec 15, 2016, 7:24 PM UTC

gfodor wrote: post #52

I've never understood the idea of a 'teaching' programming language. (Modulo examples like Logo and Scratch, which offer much more than a language as part of a wider teaching/computing system.) You spend all this time ramping up on a language, toolchain, library, etc, that you will eventually be unable to leverage beyond a certain point since it is not one used by everyday programmers. The delta in "quality learning"…

This paper (http://cs.brown.edu/~sk/Publications/Papers/Published/fffkf-...) linked from "Why Pyret" (http://www.pyret.org/pyret-code/) is a long answer to "why teaching languages."

It may also be useful to know that Pyret exists as part of a larger project and community. We're using Pyret to develop curricula for Bootstrap (http://www.bootstrapworld.org/), which integrates computing curricula into existing middle and high school classes, like math and physics.

Part of the idea is to integrate computing into these settings to reach students who may not self-select for computing.

A lot of Pyret's design, like a dead simple animation framework (https://www.pyret.org/docs/latest/reactors.html#%28part._to-...) and interfacing with real spreadsheets (https://github.com/brownplt/pyret-lang/wiki/TM028-Pyret-and-...), supports these low-friction uses of computing in these curricula.

Having these features and concepts baked into the language, supported by the IDE, and easily accessible goes a long way to building something that a non-CS teacher can pick up and use in an existing class.

Re: Pyret – A language exploring scripting and functional programming

#114

Post by dom0 » Thu, Dec 15, 2016, 7:32 PM UTC

jswrenn wrote: post #104

gfodor wrote: post #52

I've never understood the idea of a 'teaching' programming language. (Modulo examples like Logo and Scratch, which offer much more than a language as part of a wider teaching/computing system.) You spend all this time ramping up on a language, toolchain, library, etc, that you will eventually be unable to leverage beyond a certain point since it is not one used by everyday programmers. The delta in "quality learning"…

Languages such as C, Java, Python, and Rust are usually designed by experienced programmers in industry, for experienced programmers in industry. Pyret, on the other hand, is designed by computer science educators, for computer science education. This does not preclude Pyret from being a useful language for general-purpose programming; it just means that language design decisions are driven foremost by pedagogy. For…

> Languages such as C, Java, Python, and Rust are usually designed by experienced programmers in industry, for experienced programmers in industry. Pyret, on the other hand, is designed by computer science educators, for computer science education.

Honestly, looking at the examples on the Pyret main page makes me think that this isn't a good approach at all. I have been in software engineering for many years now and worked with quite some languages, yet I find the code practically in-understandable and the language looks very complex. So likely someone who "learned" using this language will have a lot of trouble actually working with real languages, assuming that he actually managed to learn this language as his first, which is rather unlikely I believe.

I was also involved in CS education - in first semester programming courses. And the language is really the last problem there (C was used, I think the dept. is moving to Python for that course though). Especially eg. Python is a good language overall and is already widely used in CS education.

In short, I don't see why the world needs this, and I actually think that using it would be actively harmful.

Re: Pyret – A language exploring scripting and functional programming

#115

Post by spacemanmatt » Thu, Dec 15, 2016, 7:35 PM UTC

jswrenn wrote: post #20

danso wrote: post #14

Example from the OP: fun to-celsius(f): (f - 32) * (5 / 9) end What's the justification for allowing the use of hyphens/dashes in reference names, when underscores would seemingly provide the same purpose? One of the most common problems I notice in newbie code is inconsistency in using whitespace, e.g. `a-b` vs `a - b`, though in that situation, for Python and virtually every other language I've used, those both res…

Pyret inherits hyphens-in-identifiers from Scheme/Racket. One of Pyret's largest users, Bootstrap [1], has long-used a dialect of Scheme, and has recently introduced a curriculum that uses Pyret. For these users, "virtually every other language" allows for hyphens in identifiers. Scheme mitigates the spacing issue with s-expressions. Pyret attempts to mitigate it by enforcing that operators should be separated from t…

I don't recall having real trouble with category errors like this as a beginner. Do you think that is a serious problem?

Re: Pyret – A language exploring scripting and functional programming

#116

Post by yoz-y » Thu, Dec 15, 2016, 7:37 PM UTC

danso wrote: post #27

cglouch wrote: post #22

Earlier quoted context omitted.

Well as dumb as it sounds, one reason to allow hyphens instead of requiring underscores is that the former takes one keystroke to type, whereas the latter takes two. This is kind of nice when dealing with longer function names. It's also worth noting that pyret requires spaces between all math operators, not just subtraction. In other words, 3+4 is not valid; you would need to type 3 + 4. So at least it's internally…

Not dumb at all...it's just that assuming that we spend more time re-reading code than we do in the initial writing of it, saving the keystroke from hyphen-to-understroke seems like premature optimization :). Good to know that Pyret requires spacing between the other operators. That does help a lot, and an argument could be made that it forces folks to not do `a-b` when they mean `a - b`.

Personally I find that hyphen-separated identifiers are more readable than when they have underscores. When dabbling in perl6 I got accustomed to then very quickly. And forcing people to put spaces around binary operators is definitely a plus.

Re: Pyret – A language exploring scripting and functional programming

#117

Post by skrishnamurthi » Thu, Dec 15, 2016, 7:37 PM UTC

cglouch wrote: post #22

danso wrote: post #14

Example from the OP: fun to-celsius(f): (f - 32) * (5 / 9) end What's the justification for allowing the use of hyphens/dashes in reference names, when underscores would seemingly provide the same purpose? One of the most common problems I notice in newbie code is inconsistency in using whitespace, e.g. `a-b` vs `a - b`, though in that situation, for Python and virtually every other language I've used, those both res…

Well as dumb as it sounds, one reason to allow hyphens instead of requiring underscores is that the former takes one keystroke to type, whereas the latter takes two. This is kind of nice when dealing with longer function names. It's also worth noting that pyret requires spaces between all math operators, not just subtraction. In other words, 3+4 is not valid; you would need to type 3 + 4. So at least it's internally…

It's not dumb at all. It's one of the things we had in mind when we designed the syntax!

Re: Pyret – A language exploring scripting and functional programming

#118

Post by macintux » Thu, Dec 15, 2016, 7:39 PM UTC

steego wrote: post #98

davexunit wrote: post #38

Earlier quoted context omitted.

Can we stop assuming that only the syntaxes we are accustomed to are the only "readable" options?

Whether some is readable is always going to be subject to who's reading it. That's simply how readable/non-readable work. Now you can learn to read new languages (human or machine), but I suspect someone who knows a romance language will find other romance languages for more readable than Chinese. Romance languages share words, alphabets, and many syntactic features. You can draw from an existing body of knowledge an…

However, when you apply your "I know these programming languages and their syntax" bias to evaluating the readability of a teaching language, you're rather missing the point.

Re: Pyret – A language exploring scripting and functional programming

#119

Post by skrishnamurthi » Thu, Dec 15, 2016, 7:39 PM UTC

danso wrote: post #14

Example from the OP: fun to-celsius(f): (f - 32) * (5 / 9) end What's the justification for allowing the use of hyphens/dashes in reference names, when underscores would seemingly provide the same purpose? One of the most common problems I notice in newbie code is inconsistency in using whitespace, e.g. `a-b` vs `a - b`, though in that situation, for Python and virtually every other language I've used, those both res…

If you're used to the syntax of identifiers from Lispy languages, you'll love the hyphens in the names (what some people call kabob-case). Because the syntax requires spaces between operators, there is no ambiguity. We have had several hundreds of Pyret programmers and there has literally never been any confusion about the syntax: in fact, people didn't even _notice_ they were using `-` in two different ways until it was pointed out to them. Empirical data rocks!

Re: Pyret – A language exploring scripting and functional programming

#120

Post by skrishnamurthi » Thu, Dec 15, 2016, 7:40 PM UTC

samcal wrote: post #105

simplify wrote: post #95

Earlier quoted context omitted.

The problem is overblown. It's not going to cause any deep, hard-to-debug errors. If you accidentally type `a-b`, you'll get an error message that says "a-b is not defined". Fix it and you're done.

While I agree that the problem is not a very big deal, I think that you might be surprised how difficult understanding compiler errors can be for newcomers.

The Pyret design team has done perhaps the most in-depth research into error messages of anyone [e.g.: http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-me..., http://cs.brown.edu/~sk/Publications/Papers/Published/mfk-mi...]. We're deeply aware of the effect of error messages. This isn't a problem.