Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyret: A new programming language from the creators of Racket

pyret.org

Post reply on HN
Print view View original

91–100 of 288 posts

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

#91

Post by sesm »

tbenst wrote: post #86

I took CS019 with Shriram a few years back and immediately guessed the authors based on paradigms like making testing a natural part of the language and the encouragement to use annotations. In the class, we were taught a design process for Racket that will work very well for Pyret: 1. Identify the data - create data definitions (You are gixen x and expected to produce y) 2. Write concrete examples of the data (This…

There is a book about this approach (http://htdp.org/), as well as a MOOC on Coursera (https://www.coursera.org/course/programdesign)

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

#92

Post by cwzwarich »

ek wrote: post #14
tinco wrote: post #6

Why 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 would encourage you to view the syntax as "Python, but repaired", for the following reasons: 1. Pyret comes out of Shriram's group's expertise with pinning down exactly what Python and other dynamic scripting languages do right, and (mostly) do wrong. Check out their recent paper Python: The Full Monty: A Tested Semantics for the Python Programming Language http://cs.brown.edu/~sk/Publications/Papers/Published/pmmw…

> Ruby is far and away not the originator of 'end' to end blocks -- this comes from Pascal and is in other languages that have nothing to do with Ruby, like Lua.

The use of 'end' comes from Algol, not Pascal.

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

#93

Post by jpolitz »

tinco wrote: post #6

Why 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…

You can actually use ";" as an alias for "end" in Pyret, so you could write:

    data BinTree: | leaf | node(value, left, right);
We use "end" or ";" in order to have unambiguous delimiters for the ends of syntactic forms and avoid needing to depend on whitespace (we added some discussion on pyret.org about our philosophy on indentation and why we don't want to depend on whitespace).

Making that leading pipe optional is a good idea. I made an issue for it, we'll think about if it'll break or confuse anything and add it if it doesn't:

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

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

#94

Post by timtadh »

ek wrote: post #14
tinco wrote: post #6

Why 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 would encourage you to view the syntax as "Python, but repaired", for the following reasons: 1. Pyret comes out of Shriram's group's expertise with pinning down exactly what Python and other dynamic scripting languages do right, and (mostly) do wrong. Check out their recent paper Python: The Full Monty: A Tested Semantics for the Python Programming Language http://cs.brown.edu/~sk/Publications/Papers/Published/pmmw…

Thanks for the link to that paper. Super interesting to see actual semantics for python come out. It would be nice if this leads to better tooling for analysis of the language. Currently, it is pretty hard to bootstrap anything for the language in comparison with what you can do for the JVM.

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

#95

Post by m_for_monkey »

sesm wrote: post #91
tbenst wrote: post #86

I took CS019 with Shriram a few years back and immediately guessed the authors based on paradigms like making testing a natural part of the language and the encouragement to use annotations. In the class, we were taught a design process for Racket that will work very well for Pyret: 1. Identify the data - create data definitions (You are gixen x and expected to produce y) 2. Write concrete examples of the data (This…

There is a book about this approach ( http://htdp.org/ ), as well as a MOOC on Coursera ( https://www.coursera.org/course/programdesign )

The second edition of How to Design Programs is not finished yet, but I recommend it anyway: http://www.ccs.neu.edu/home/matthias/HtDP2e/index.html

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

#96

Post by pseut »

stiff wrote: post #35
6ren wrote: post #16

Earlier quoted context omitted.

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…

It's also much less necessary with packages, where you can trivially change the order of most of the code is read.

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

#97

Post by qznc »

6ren wrote: post #16
terhechte wrote: post #3

"""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 you are both right. D even takes it to the next logical step: Present the unit tests as examples in the API documentation (like Doxygen,Javadoc). It means the API examples are kept in sync.

http://qznc.github.io/d-tut/testing.html

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

#98

Post by stcredzero »

driax wrote: post #41
6ren wrote: post #16

Earlier quoted context omitted.

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…

On the other hand, inline test does make it easier to write tests while writing the function. Besides many well-written programs already contains inline documentation (not comments) that can be a lot longer than the function they describes. Code folding in a IDE goes a long way to make this bearable.

> Code folding in a IDE goes a long way to make this bearable.

Code folding in IDEs is an indication that we are doing it wrong -- that is, we human beings are programming computers "wrong."

I'm not saying that code folding is a symptom. I'm saying that code folding shows how primitive our means of managing code is. It's as if the mesopotamians somehow invented computers, and because of tradition, all code has to be written as cuneiform on wet clay tablets, then fired in ovens before being read. At least text files in directories are digital, but they are as static and behavior-less as clay tablets, and all of the important relationships therein are expressed as implicit correspondences which programmers have to keep track of in their heads.

Code Bubbles is a beacon in the direction we should go.

https://www.youtube.com/watch?v=PsPX0nElJ0k

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

#100

Post by oahziur »

sesm wrote: post #91
tbenst wrote: post #86

I took CS019 with Shriram a few years back and immediately guessed the authors based on paradigms like making testing a natural part of the language and the encouragement to use annotations. In the class, we were taught a design process for Racket that will work very well for Pyret: 1. Identify the data - create data definitions (You are gixen x and expected to produce y) 2. Write concrete examples of the data (This…

There is a book about this approach ( http://htdp.org/ ), as well as a MOOC on Coursera ( https://www.coursera.org/course/programdesign )

htdp was my first programming book, and it is really helpful.
Post reply on HN