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

Re: Pyret – A language exploring scripting and functional programming

#81

Post by jswrenn » Thu, Dec 15, 2016, 6:25 PM UTC

AstralStorm wrote: post #54

AstralStorm wrote: post #29

Unexplained important things: * concurrency, is there any nice built in syntax like Python async? Any kind of threading? Multiprocessing support? * error handling, how is it done? Where are exceptions? * standard and file io, string operations, serialisation? * no builtin higher math types (matrix etc.), is math done on decimal floating point numbers? * foreign functions, interfacing with other languages, embedding?

Also: * metaprogramming - templates, macros, generic programming?

Shhh! That's on the horizon!

One of the frustrations of using Racket—which is macros all-the-way-down—is debugging. When you see an error message or use a stepper-debugger, you want it to be in terms of the code you wrote; not in terms of the code generated by some complicated macro which was glued together by a sleep-deprived graduate student.

One of the graduate students here in the PLT group at Brown, justinpombrio, is working on resugaring—taking a sequence of evaluation steps in terms of a post-macro-expansed program, and presenting them back to the user in terms of the surface-syntax of the language. (More on this at his website, http://justinpombrio.net/) We're just starting to prod at implementing Pyret's existing syntactic sugar in this manner, which will be a first step to a proper macro system.

Re: Pyret – A language exploring scripting and functional programming

#82

Post by xapata » Thu, Dec 15, 2016, 6:25 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…

People mess up the other way as well, thinking "a-b" is a valid identifier in Python.

Re: Pyret – A language exploring scripting and functional programming

#83

Post by eastWestMath » Thu, Dec 15, 2016, 6:26 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"…

I've had some experiences where it really helped. My supervisor uses a teaching stack based VM for his compilers class - it is slow as all hell but very simple, easy to get running, and it gives very good debugging info. Similarly, I can see the value in a simplified graphics API that let's you focus on the basic theory, or a simplified language with Hoare logic for writing loop invariants in an algorithms class.

Re: Pyret – A language exploring scripting and functional programming

#84

Post by nercht12 » Thu, Dec 15, 2016, 6:26 PM UTC

lmm wrote: post #63

makmanalp wrote: post #13

Earlier quoted context omitted.

Annotations are optional. This is equally valid: fun square(n): n * n end Not that different after all! And I say this as a lover of python and significant whitespace, but not having it at first would be easier.

"def" is an abbreviation non-programmers are more likely to understand than "fun".

How dare you suggest non-programmers can't understand fun! XD (I'm only teasing of course.)

Re: Pyret – A language exploring scripting and functional programming

#85

Post by makmanalp » Thu, Dec 15, 2016, 6:26 PM UTC

lmm wrote: post #63

makmanalp wrote: post #13

Earlier quoted context omitted.

Annotations are optional. This is equally valid: fun square(n): n * n end Not that different after all! And I say this as a lover of python and significant whitespace, but not having it at first would be easier.

"def" is an abbreviation non-programmers are more likely to understand than "fun".

OK: opinion time. Some folks in this thread don't understand how pedagogy works.

When these people talk about easy-to-learn, they don't mean what a lot of people in this thread mean. Def / fun is such an easy thing that it's a non-issue. Anyone can learn programming language syntax pretty quickly.

It's the semantics that's hard. When you first start learning, the things that actually trip you up and that you can't just look up in a cheatsheet in two seconds are things like: Unexpected behavior, bad error messages, hidden rules, hidden complexity, complicated control flow, code that doesn't do much but must be there anyway, arcane things that you must do to make the compiler happy.

In that way, you don't have to assume that beginners are stupid. A lot of these things happen because languages are badly designed, or because they evolve to have too much cruft over time in an effort to be general purpose and catch up with the times. For learning, this just gets in the way. With better tools, learners can tackle much more complex concepts much quicker. Once those take place, you can introduce the arcane weirdness of other programming languages, and it makes a lot more sense.

Re: Pyret – A language exploring scripting and functional programming

#86

Post by jpolitz » Thu, Dec 15, 2016, 6:27 PM UTC

sergiotapia wrote: post #57

I really like the idea of tests right beside the code. I don't like how it's code though. Muddles what the actual implementation is a bit. Maybe with more usage the where statements start to blur and you don't notice them as much. I like Elixir's approach better where your test cases live as documentation examples in comment form, right above the function declaration. It's fantastic and free. Your mix test command ru…

Pedagogically, the nice thing about the examples/tests just being code for beginners is that they are... just code!

Once we've taught students about function calls and values, it's a small jump to write an example with "is" in the middle. The syntax errors, static errors about unbound identifiers, and dynamic behavior all act the same as everywhere else in the program, so it's less friction to write the first test.

For getting off the ground writing that first test, I've been really happy with what Pyret lets us do. There is more involved in getting better testing/reporting options as systems scale up (we have lots of test-only files for the compiler), but pedagogically, the testing block infrastructure has worked well.

Re: Pyret – A language exploring scripting and functional programming

#87

Post by eridius » Thu, Dec 15, 2016, 6:28 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…

Scheme and Racket are both LISPs, with very different syntax. Hyphens in identifiers aren't a hazard, because binary operators don't go between two other identifiers, and operators must be separated with spaces, e.g. subtraction looks like `(- 2 1)` instead of `2 - 1`. This means that using hyphens in identifiers is quite safe.

But Pyret is using more traditional syntax, where binary operators go between their operands, e.g. `2 - 1`, which means using hyphens in identifiers is a hazard as the parent comment describes.

Re: Pyret – A language exploring scripting and functional programming

#88

Post by steego » Thu, Dec 15, 2016, 6:30 PM UTC

phkahler wrote: post #34

What's the point? One would hope they start with a description of why this is better for education than something like Python. I just gave it a quick glance, and it looks like many other programming languages - a bunch of odd text gibberish. I don't think the problem dividing people into "gets it" and "doesn't get it" has anything to do with nuances in syntax or semantics.

Despite what the down voters think, I actually found this comment useful because I had the exact opposite reaction. I took a quick look at the examples, saw familiar syntax and features and quickly concluded it looks like a nice toy, but I'd probably never use it because there are way too many unknowns (Performance, runtime, buggy, etc. etc.).

I was actually a little flabbergasted when you said it looked like "odd text gibberish", but then I took another look at the the first example and saw it.

    data BinTree:
      | leaf
      | node(value, left, right)
    end

Unless I'm familiar with union types, what part of that code tells me this is a parameterized enum? Why should I assume we're even talking about data types?

I'm relatively flexible when it comes to syntax, but clearly syntax is a huge hurdle that almost always gets in the way of adoption. I understand Pyret isn't looking to be the next Python, but for an educational language I would argue it's not living up to Python's Principle of Least Surprise. It's great if you know Haskell, OCaml, Python and other languages, but it's not so great if you're an unsuspecting student who's sharpened your teeth on Java/Python.

I suspect most people could pick up the syntax pretty quickly, but I suspect most people still need some hand-holding on the first page. Most programmers still don't know what this short paragraph means:

    Pyret allows for concise, expressive, recursive data declarations. Type annotations 
    are optional and can be added incrementally, to serve a variety of pedagogic 
    styles and curricular needs.

Re: Pyret – A language exploring scripting and functional programming

#89

Post by qwertyuiop924 » Thu, Dec 15, 2016, 6:31 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"…

The idea is that the concepts of CS are universal, regardless of programming language. So instead of using a programming language that has been designed for real world use (carved with the footprints of a thousand language hackers, full of awkward inconsistencies, warts, and good-enough-for-nows), teach in a teaching language - a programming language that is very regular, with very simple semantics, not necessarily designed for speed.

However, this doesn't exclude it from being a Real Language. Scheme is both a very popular teaching language (perhaps the prototypical teaching language, being used in SICP), and has seen actual use, with a dedicated community around the various implementations of the language. For a teaching language, there are a lot of things built atop it. Like, say, this site (PG's Arc runs atop an old version of Racket, from back before Racket diverged quite so much from Scheme, and was still called Scheme).

Re: Pyret – A language exploring scripting and functional programming

#90

Post by nine_k » Thu, Dec 15, 2016, 6:35 PM UTC

good_gnu wrote: post #56

For me, this looks MUCH more like Haskell than Python and I think that this is symptomatic of an erroneous claim that some functional programming proponents seem to constantly make: That declarative, "mathy","deconstructive" programming is somehow easier to learn than imperative, "algorithmic", step-by-step constructive programming. In reality, most people in the world struggle with abstract mathematics and find it m…

Look at the examples.

Math is useful not because it's abstract, but because it's concise and descriptive.

Pattern matching is a much more natural way of thinking for a human than tracing the execution flow; did you ever write Basic on 8-bit computers?

It seems that Pyret is much closer to OCaml (there's a direct comparison in the examples), but with a less mathy syntax. It's also not statically typed. So it should feel much more like Scheme, or, well, Python: you can easily write imperative code, with explicit loops when you want to, etc. But it gives you the nicer data model, the one that combines the natural feel of "objects" and the conveniences of Hindley-Milner-ish types.