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

71–80 of 138 posts

Re: The Pyret Programming Language

#71

Post by gsliepen »

scns wrote: post #35
bayesian_horse wrote: post #7

My criticism is that this language is very similar to Python and might very well confuse students who ultimately have to switch to Python or other languages.

Students switching from this to a "real world language" would be disappointed if it does not have Algebraic Data Types, pretty sure about this. Once you learned about them in SML, OCaml, Haskell or one of their descendants, which include Pyret, Elm, ReasonML/ReScript, Rust and Purescript, you feel lucky if you can use Kotlin and approximate them with sealed classes. We will see, maybe C++, Java and C# add them in the…

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

Re: The Pyret Programming Language

#72

Post by lizmat »

darrenf wrote: post #26
cormacrelf wrote: post #18

It seems pretty bad to have kebab-case identifiers in a language that also has an infix subtraction operator -. The only languages I know that allow kebab-case idents are lisps, where subtraction is (- prefix notation). From the examples: lam(actual): num-abs(actual - target) This is a new, even worse kind of "whitespace significance" than indentation. Is it a function called `num-abs` or a variable `num` minus `abs(…

Raku has kebab-case as well as infix subtraction. Sigils disambiguate when the operands are variables ($foo-$bar), and callables must be made explicit: sub foo-bar { 10 } sub bar-foo { 7 } say foo-bar-bar-foo; # Undeclared routine error say foo-bar()-bar-foo; # 3

Or just do:

    say foo-bar - bar-foo;
which would improve readability as well!

Re: The Pyret Programming Language

#73

Post by throw_m239339 »

Never heard about it before, it looks well done.

Very interesting language.

First a great point about the homepage: it goes directly to business, no marketing buzzwords, no stupid mascot, one glance at that page and any developer gets a very good idea of what that language does and doesn't.

Second yes, they are very interesting choices and functions.

However:

https://github.com/brownplt/pyret-lang

It's implemented in Javascript? This is a kind of no started for the kind of app I do, personally. But as a stand alone language which interpreter would be written in C/C++ and could be dropped into an existing native app, it would be interesting.

Re: The Pyret Programming Language

#74

Post by ilyash »

I have considered different constructs like "where:" to be placed in code blocks (such as function) when working on Next Generation Shell. I have decided against because these constructs will not be executed at runtime (when the function is called) and therefore I assume it will be at least somewhat confusing.

For tests, NGS has "TEST" keyword which can be placed at beginning of any line. The test is everything till end of that line. I typically place these below functions that they test.

Re: The Pyret Programming Language

#75

Post by mlazos »

gsliepen wrote: post #71
scns wrote: post #35

Earlier quoted context omitted.

Students switching from this to a "real world language" would be disappointed if it does not have Algebraic Data Types, pretty sure about this. Once you learned about them in SML, OCaml, Haskell or one of their descendants, which include Pyret, Elm, ReasonML/ReScript, Rust and Purescript, you feel lucky if you can use Kotlin and approximate them with sealed classes. We will see, maybe C++, Java and C# add them in the…

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.

Re: The Pyret Programming Language

#76

Post by Waterluvian »

piperswe wrote: post #60
bialpio wrote: post #56

Earlier quoted context omitted.

That's also pretty nice, although elevating those tests to be first-class-citizens makes more sense to me. My approach is that "code is truth, despite what the comment says", and docstrings feel too much like comments, but I haven't used Python professionally that much so I just may not be used to those.

I haven't used doctests in Python, but I have in Rust. It really helps that any code blocks in a docstring is a doctest by default, so they ensure that examples in your documentation stay evergreen. It's nice to know that if there's a code example in documentation, it will compile and run properly and hasn't been broken.

Practically speaking how useful are the Rust doctests?

I thought they looked like a genius idea but I don’t get how they work 95% of the time when examples don’t come with all the plumbing required to make valid state for a function to actually work on.

Re: The Pyret Programming Language

#77

Post by skrishnamurthi »

throw_m239339 wrote: post #73

Never heard about it before, it looks well done. Very interesting language. First a great point about the homepage: it goes directly to business, no marketing buzzwords, no stupid mascot, one glance at that page and any developer gets a very good idea of what that language does and doesn't. Second yes, they are very interesting choices and functions. However: https://github.com/brownplt/pyret-lang It's implemented in…

Well, actually, it's implemented in Pyret itself (-:.

But it currently compiles down to JavaScript. Our goal is to create an awesome language for certain educational settings, and many of our users (e.g., schools) are on restricted machines that can't install desktop software. The browser is the one platform they can easily access, and it also saves teachers from turning into sysadmins (to install, upgrade, etc.).

Hence our browser-based delivery. There is also a CLI. And in principle, someone could write a back-end that targets native code, etc. We don't have the resources to do that right now (but it's all Open Source).

Re: The Pyret Programming Language

#78

Post by skrishnamurthi »

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 interesting result that is also instructive. (Hint: it will produce neither true nor false.)

Re: The Pyret Programming Language

#79

Post by skrishnamurthi »

cabalamat wrote: post #9

Overall this looks quite nice. I like the way types can be defined but if they are not they can be anything. Are these types checked anywhere? I think they should be checked at compile-time wherever possible, and optionally at run time too (I say optionally as the checks might make it slow, so they could be checked in development but perhaps not in production).

They are indeed checked at compile-time if you use the optional type checker. It's not on by default because there are still a few odd corner-case bugs in it. But the Run button remembers which state you are in, so once you switch to using the type-checker, you'll always use it unless you stop using it.

What it should do is a decision that should be made by the individual curriculum/instructor.

Re: The Pyret Programming Language

#80

Post by skrishnamurthi »

agumonkey wrote: post #10
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.

it's a lisp descendant it has, most probably, a full numerical tower

Partial, not as full as Scheme.
Post reply on HN