Pyret: A new programming language from the creators of Racket • Hacker News Board

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

#121

Post by stcredzero » Sat, Nov 09, 2013, 9:33 PM UTC

aidenn0 wrote: post #107

stcredzero wrote: post #98

Earlier quoted context omitted.

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

I think you're completely backwards on this. Code folding in an IDE is an example of a way in which text files aren't necessarily static and behavior-less. I see no reason to move away from an underlying representation as text.

I see no reason to move away from an underlying representation as text.

A big reason is that otherwise people won't move away from the paradigm of static text files. The best they'll do is text files with little gimmicks attached to them.

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

#122

Post by mercurial » Sat, Nov 09, 2013, 9:39 PM UTC

amenod wrote: post #89

sparkie wrote: post #52

Earlier quoted context omitted.

My biggest gripe with these is the inability to name the tests. What exactly is a unittest block testing for? You need to rely on comments or read the test code where none exists. Doesn't seem like Pyret fixed that issue.

That's an advantage in my book... it is testing the unit (function in this case) and it is testing all the corner cases... do you have a name for each of them? Description through comments is much more suitable IMHO.

Corner cases? Tests test the behaviour of the function. Functions, depending on their complexity, have a range of behaviour. And yes, you should (usually) be able to come up with a name for it. As a bonus, you'll get immediately an idea of what broke upon test failure.

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

#123

Post by agumonkey » Sat, Nov 09, 2013, 9:42 PM UTC

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 )

Can't suggest these enough for any programming student.

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

#124

Post by mercurial » Sat, Nov 09, 2013, 9:44 PM UTC

skrishnamurthi wrote: post #77

laureny wrote: post #43

Earlier quoted context omitted.

> Making tests part of language syntax is an interesting idea. It's been tried many times before and it has always failed. A few reasons: - It clutters the code - If you need simple tests, asserts suffice - If you need more sophisticated tests, write functional tests, separately The approach offered by Pyret (along with similar ones, such as design by contract) are compromises that are the worst of both worlds.

It's actually widely used in Racket already. Yesterday a lead programmer at a major financial institution told me that he liked that style so much, he'd incorporated it into his company's OCaml system, and they use it in their production systems (lots of high-volume trading). Hardly "failure"s. Nevertheless, perhaps you could provide some pointers to the "many" projects that have tried it before? Assertions are not t…

This might work better for pure functions. I can't imagine it working very well for complex, stateful code which requires mocking and resetting the state between tests.

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

#125

Post by skrishnamurthi » Sat, Nov 09, 2013, 9:47 PM UTC

eliben wrote: post #23

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…

I'm not sure I like having tests in the same file with the code. In real code bases it's very common to just read the code, and cluttering that with huge swaths of unit-tests is counter-productive. That said, Pyret appears to be aimed at education so this may make more sense.

Then you can put your tests in a `check` block and move them elsewhere. You don't have to use `where` except when it makes sense.

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

#126

Post by skrishnamurthi » Sat, Nov 09, 2013, 9:47 PM UTC

gizmo wrote: 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 language is in use in introductory courses, with a gradual introduction of these topics. It's no different from using any other modern programming language in education.

Our goal is to eventually create language levels, pioneered by DrRacket, based on what we learn from observation. This is a research project in addition to a development one, where the research is into human factors.

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

#127

Post by geofft » Sat, Nov 09, 2013, 10:04 PM UTC

dagw wrote: post #105

f7t7ft7 wrote: post #25

Earlier quoted context omitted.

MIT used to teach intro to CS using Scheme, I thought. It's significantly simpler than Python.

How many people taking intro to CS at MIT do you think are beginners who have never programmed before?

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 too _different_ for the students who had, and served neither group very well.

The new (Python-based) classes handle this a little bit better, from what I hear.

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

#128

Post by skrishnamurthi » Sat, Nov 09, 2013, 10:31 PM UTC

sitkack wrote: post #90

skrishnamurthi wrote: post #80

Earlier quoted context omitted.

Everything is fixable in a new language (-:. Say more!

Could the tests be more declarative, defining properties over a space?

Absolutely! Pyret's test section has a "satisfies" keyword for property tests. E.g.:

  check:
    insert(a-value, a-balanced-tree) satisfies is-balanced
  end

or even

  check:
    tree-examples = [ ... ]
    values = [ ... ]
    for each2(t in tree-examples, v in values):
      insert(t, v) satisfies is-rbtree
    end
  end

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

#129

Post by skrishnamurthi » Sat, Nov 09, 2013, 10:32 PM UTC

pjmlp wrote: post #11

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…

Contracts?

Every time you write a refinement on a type, you're actually writing a contract. You can gracefully move between types and contracts this way, and also between thinking of them as checked assertions vs tested ones. The goal is to make this migration more and more seamless.

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

#130

Post by skrishnamurthi » Sat, Nov 09, 2013, 10:39 PM UTC

stass wrote: post #111

ek wrote: post #27

Earlier quoted context omitted.

Like it or not, universities have started to move away from teaching Scheme to introductory CS students. You may remember that much was made of MIT and Berkeley switching away from Scheme for Python. I think Pyret comes out of a precedent of Python as the new standard, so in that light, it's certainly an improvement.

That's because they stopped teaching CS, it's not that they replaced Scheme with Python in CS courses. How can you possible teach metacircular interpreters, constraint propagation languages, ambiguous computation and similar constructs using Python when you need to be able to easily define a completely different language semantics using language at hand? In that sense, Pyret will allow them to teach a bit more CS tha…

The textbook that accompanies Pyret (http://papl.cs.brown.edu/2013/) covers many of these topics: the second half of this book is a full-blown programming languages text (formerly a stand-alone book known to some as PLAI).

I fully agree that you can't cover these things well in Python, and most Python textbooks don't, because of the poverty of datatypes and the difficulty of creating new structured ones.

However, while I think SICP is the greatest computer science book ever written, it has its own share of blind spots (for a simple example, see [the lack of] types or pervasive specification and testing). So the above book takes a somewhat different take on these issues. But it hews closer to SICP than any Python book I've seen.