Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

181–190 of 288 posts

Re: Pyret: A new programming language from the creators of Racket

#181
post #127

Earlier quoted context omitted.

Quite a few, actually, which is why the Scheme class ended up being awful in practice -- you'd get a bimodal distribution of students where some are already familiar with multiple languages (usually more mainstream than Lisp) and some aren't familiar with any, and the class, by necessity, targeted the trough right between those. So it was too fast for the students who never programmed before, and either too slow or t…

I've seen an MIT Scheme class video, and it was painfully slow and the guy seemed to explain everything in painstaking detail. I've heard about the bimodal distribution, which I believe I witnessed among fellow students when I was taking classes. But I'm having trouble seeing how Scheme made it any worse or how the class was too fast. And, Pyret looks like a terrible beginner language! I like PltScheme, but I can't s…

I don't know about this class in particular, but the speed of a course does matter. I guess programming is one of the harder courses to teach?

Re: Pyret: A new programming language from the creators of Racket

#183
post #29

Earlier quoted context omitted.

Lisp syntax is ( ) with a few special forms (def, if, cond etc.). This is really easy to understand and allows the user to go straight forward and learn about the semantics and general programming practice immediately.

That same regularity also means there are few guideposts as a student programs, and this makes it much harder to recover from mistakes. We've looked at a lot data on this (and have taught Racket at every level for decades).

If you need guideposts, use an editor with paredit support and rainbow delimiters. This makes Lisp feel far more intuitive and tree-like than normal.

Re: Pyret: A new programming language from the creators of Racket

#184

Earlier quoted context omitted.

One of my favorite things about tests is that they let me read a new codebase more interactively. If I don't understand why a function is built like this and not that I can rewrite it the new way, run the tests. Without names I'd know I broke something, but with a good name I'll often realize why that something matters in the big picture. (I think about tests a lot: http://akkartik.name/post/tracing-tests )

I understand your point. One thing I pushed for initially, dropped because we had bigger fish to fry, and will revisit later, is the idea that you should be able to name everything : not just tests but an individual variant in your data definition, lines of code, etc. And this should be intrinsic to the language. That said, I couldn't see what your post had to do with this concept; if I've missed something, please ex…

Thanks. My post wasn't about names, I was just looking for feedback. Which I got; thanks.

Re: Pyret: A new programming language from the creators of Racket

#185
The Ruby examples are unfair.

Ruby intentionally makes parenthesis optional. So `do_something` is `do_something()`.

For the first example,

  - method_as_fun = o.my-method
  - method_as_fun(5) # not reached
  + method_as_fun = o.method(:my_method)
  + method_as_fun.call(5) # or method_as_fun[5]
And for the lexical scope thing,

  def f(x)
    g = ->y {x + y}
    g[2]
  end
  f(2)
Or, explicitly use class variables,

  def f(x)
    @x = x
    def g(y); @x + y; end
    g(2)
  end
  f(2)

Re: Pyret: A new programming language from the creators of Racket

#186
post #7

Pyret looks like a there's a lot going on, based on the examples. It has implicit returns, special purpose syntax for data structures, iterators, assertions, refinements, etc. Having support for more stuff makes it less suitable as a teaching language, not more. Pyret looks like a has the good bits of Python plus a whole bunch of other cool stuff. But the language is pretty complex as a result. Cool? Yup! Good for te…

The grammar can be described with a single page in actual BNF. Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. Ruby is fundamentally impossible to describe with a BNF.

Re: Pyret: A new programming language from the creators of Racket

#187

> Most “scripting” languages don't support annotations for checking parameters and return values I coded in Java for many years and Ruby for the last several, the lack of explicit type checking in method signatures or via annotations built into Ruby has not gotten in the way enough where I felt I needed to add something to decorate methods to do some generic form of type checking in Ruby. When I really need to check…

As you wish! We now have two Ruby examples on the home page. You may not call it love. <-:

Thanks, but may want to correct:

method_as_fun = o.my-method

which should be:

method_as_fun = o.my_method

and the examples themselves just look a little crazy, imo. Not crazy because of what you are trying to do, but in how you are trying to do it. What was the intent of calling a method that defines an argument without an argument? That's not a problem of the language; that's just an error in coding. There are all kinds of things in Ruby to handle method definition. Arguments can have defaults. You can use splat and unsplat to handle unspecified arguments and composing arguments of various # on the fly. You can pass in blocks specifically (&something) or optionally (yield, etc.). Procs allow argument sillyness and returning the parent method by explicit return in the proc body, lambdas don't, etc. Ruby is a great language, and you should give it a college try for several months to get the hang of it.

By the same token, I have no clue what you are trying to do here:

def f(x); def g(y); x + y; end; g(2); end; f(2) # undefined local variable or method `x'

You can define methods on object instances, if that is what you are getting at (define_method/class_eval/etc.), and getting familiar with blocks, procs/lambdas might help. It isn't JavaScript, but I can't think of that much that I couldn't do in Ruby (barring high performance, compile-time type checking, etc.)

Re: Pyret: A new programming language from the creators of Racket

#188
post #172
post #157

Earlier quoted context omitted.

Really? The concept of a block that specifies a contract does not sound similar to the design by contract capabilities of Eiffel. Care to enlighten us why not? Perhaps you think I was referring to something other than the quote in the comment I replied to.

Eiffel contracts are relatively primitive compared to the more modern Racket and Pyret contracts. Eiffel contracts are basically limited to assertions and don't support contracts on higher order function arguments, refinements, etc. There is also the whole dynamic typing thing. Eiffel is still fully statically typed.

None of which changes what I wrote earlier.

In terms of my opinion of Racket/Pyret, though, there's been a number of Ruby projects to do similar stuff to this over the years, since it's trivial to add (just add a class method that redefines a method and wraps it in code to execute the contracts), and a lot of Ruby newbies try to find ways of adding back the restrictions they've lost when moving from statically typed languages.

Invariably they've ended up dying or not getting much interest, largely because a large part of the appeal of dynamic languages for a lot of people is that the code reads simple. In the Ruby world at least, aesthetics is a big deal. And putting the tests inline destroys that aesthetic and makes it harder to read the code.

Especially because tests tends to be trite and repetitive and contain a lot of stuff that is obvious to a human when you have the code right in front of you.

Especially when they go beyond documenting contracts that are intended to bind subclasses to an interface.

That code readability is important.

I have a prototype for my own Eiffel inspired language with DbC support, and my own experience with it was that as much as I love the idea, even Eiffel level contracts are bordering on being too verbose, for these reasons.

Pull them out into separate files, and they're a lot more acceptable, but then what is the difference from any other unit testing framework?

Re: Pyret: A new programming language from the creators of Racket

#189
post #7

Pyret looks like a there's a lot going on, based on the examples. It has implicit returns, special purpose syntax for data structures, iterators, assertions, refinements, etc. Having support for more stuff makes it less suitable as a teaching language, not more. Pyret looks like a has the good bits of Python plus a whole bunch of other cool stuff. But the language is pretty complex as a result. Cool? Yup! Good for te…

The grammar can be described with a single page in actual BNF. Thats AMAZING. The only languages have shorter grammars are core lisp/scheme. Ruby is fundamentally impossible to describe with a BNF.

> Thats AMAZING. The only languages have shorter grammars are core lisp/scheme.

It's nice, but I'm not sure I'd go with amazing. Most or all of Niklaus Wirth's languages have shorter grammars, for example. I'd imagine quite a few others do as well.

E.g. Oberon-2 has 33 EBNF productions: http://en.wikipedia.org/wiki/Oberon-2_(programming_language) - that fits fully on screen for me with my default font size...

Regarding Ruby, I agree. I'm working on a Ruby compiler, and "decoding" the MRI parser into something closer to optimal will still leave an awful mess no matter what you do. I love programming Ruby, but implementing it is hell (and one of the reasons I'm trying it...)

Re: Pyret: A new programming language from the creators of Racket

#190
post #67
post #28

Earlier quoted context omitted.

> Literate programming… didn't catch on I would argue literate programming is experiencing a renaissance, thanks to docco: https://github.com/jashkenas/docco

Not really, I never heard of docco and am yet to see a RFP for a node.js project from my employer's enterprise customers.

Chances are much higher that you've seen the output of Docco or one of the multitude of imitations for other languages.
Post reply on HN