Looks more like Ruby than Python, why the comparison to Python?
Pyret: A new programming language from the creators of Racket
31–40 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#32Why the superfluous syntax? I think remembering syntax like this is orthogonal to the goal of being easy to learn. The syntax is basically Ruby + Python + Haskell. Each of those languages has a lighter, more intuitive and memorable syntax. Why would the syntax be: data BinTree: | leaf | node(value, left, right) end Instead of just data BinTree = leaf | node(value, left, right) The whole colon thing in Python is a mis…
I think you mean that it's in opposition to their goal of being easy to learn, not that it's orthogonal, as that would mean "it doesn't interfere". Anyway, it seems to me that the only real difference between your code examples is that the second one lacks an ending designator and uses an equals-sign instead of a colon. However, in order to make the lack of an ending designator work, you need a more complex parser (i…
Newlines are not a fine separator; what if you have a definition that you intend to span multiple lines? In any case, the pipes go all the way back to EBNF, since what you are really doing when you specify an ADT is specifying a grammar of types.
I admit to also being a brace weenie; I would very much prefer if all the languages I had to use had them. However, Pyret exists in a tradition of many successful, braceless languages like Python, ML, and Lua.
Re: Pyret: A new programming language from the creators of Racket
#33> Python-inspired syntax for functions
> fun to-celsius(f):
> (f * (5 / 9)) - 32
> end
Wait a minute..
Re: Pyret: A new programming language from the creators of Racket
#34"""Pyret makes testing a natural part of the programming process. Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.""" Fantastic idea! I'll keep that in mind, should be fairly easy to extend Lisps or other AST-Macro enabled languages (Elixir, Julia, Python) with such a functionality. I really like that. It makes it easy to work on a function and cod…
Interesting. Could you propose such an extension by posting a code sample e.g. in scheme?
Sure. These are basically simple contracts. Contracts are implemented in Racket: http://docs.racket-lang.org/reference/contracts.html
Re: Pyret: A new programming language from the creators of Racket
#35"""Pyret makes testing a natural part of the programming process. Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.""" Fantastic idea! I'll keep that in mind, should be fairly easy to extend Lisps or other AST-Macro enabled languages (Elixir, Julia, Python) with such a functionality. I really like that. It makes it easy to work on a function and cod…
It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…
I don't think the story of literate programming can be of any help predicting how well this idea here can work out.
Literate programming is not "embedding documentation". The main idea was to separate the order in which the code is read from the order in which the compiler sees it, and it embeds the code in the documentation, not vice versa. It was a very idiosyncratic thing, hard to imagine a team of programmers in a typical current commercial setting, developing a nice LaTeX essay around the actual code of the next social network web-app. As the program grows larger it also gets harder and harder to maintain the "story" around it.
Re: Pyret: A new programming language from the creators of Racket
#36"""Pyret makes testing a natural part of the programming process. Functions can end in a where: clause that holds unit tests for the function. These assertions are checked dynamically.""" Fantastic idea! I'll keep that in mind, should be fairly easy to extend Lisps or other AST-Macro enabled languages (Elixir, Julia, Python) with such a functionality. I really like that. It makes it easy to work on a function and cod…
It clutters the code. Tests are a form of documentation, but too much in the code, like too many comments, obscures. Higher level unit tests (acceptance tests) can be quite long, especially if there's a lot of setup - unlike their example code. Literate programming tried embedded documentation, but didn't catch on (even with Knuth's backing). Embedding tests makes them easier to keep in sync, but tests are already ke…
I think that Python's doctests have shown this to be a greyer area than this. Not all tests can fit nicely next to function definitions, but a few well-chosen ones are both fantastic documentation and not too cluttery.
Re: Pyret: A new programming language from the creators of Racket
#37Pyret 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…
My understanding is that it's a relatively simple place to learn about how to manipulate data (as in algebraic data type style, FP data) and has all of the conveniences of syntax that allows someone to think fluently about that concept.
So it's syntactic complexity might be high, but it's conceptual complexity is rather low.
Re: Pyret: A new programming language from the creators of Racket
#38> 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 the type of an object sent into a method, it is typically a method that can handle different types, and in that case, I'll use respond_to?(...) to see that an object passed in as an argument responds to a method, use a case statement, is_a?(...), etc. but that is certainly not on every method- probably more like 1 in 20-30 methods.
Also, in the comparison section of the doc, OCaml and Python were represented, but not Ruby. As of late 2013, there are more jobs containing "Ruby" in the job description than "OCaml": http://www.indeed.com/jobtrends?q=ocaml%2C+ruby&l= So, imo it should give Ruby some love with a comparison.
Re: Pyret: A new programming language from the creators of Racket
#39it sounds great to blend Python and Lisp!
Re: Pyret: A new programming language from the creators of Racket
#40it sounds great to blend Python and Lisp!
Except it abandons most of the benefits of lisp.