Hacker News Reader

Comment by skrishnamurthi | Hacker News Reader

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 tests. This is a fundamental misunderstanding of the difference.

Pyret's `check` blocks exist to write complex tests, separate tests from definitions, or write tests that cross multiple functional units. So they offer the power of regular testing frameworks.

Thus, `where` is the bonus, not a "compromise".

View on HN

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.

They didn't say one way or the other whether the language was pure FP, but I don't think any of the examples featured mutuality

Pyret is not pure. We have mutation. But mutation has its own syntax different from regular binding. Variables (as opposed to identifiers) are preceded by "var", and variable mutation uses ":=". [Similarly for fields.] This it to make clear to all forms of readers -- programmers, compilers, IDEs -- when something is mutable.

Given that Pyret is functional, there's a good chance there will be an emphasis on simple, pure functions.

Beyond that, I'd agree completely. Doctests, for instance, are quite terrible when you can't fit all of the logic into one line, but then I think it's usually a sign of a well-designed function when it's good a good enough interface to get a few pithy doctests in.

Though Pyret is not pure, our emphasis is heavily on "functional first", even for objects. We believe state should be used carefully and for good reasons. HtDP (www.htdp.org) has two whole chapters on state at the end, giving design recipes for their use, and I'm revising some of these in PAPL (papl.cs.brown.edu/2013/).

This is why a test block is a block. Writing inline tests for stateful functions in Racket was a bit painful because it is so heavily expression-oriented. We want to make this feel more natural.

(Another virtue of test blocks: you can write little local helper functions. There's an example of this on the Pyret home page.)

Have you thought about adding some kind of QuickCheck-ish model where test cases can be randomly generated for various types?

This exists in Haskell's doctest library

    -- | Documentation goes here
    --
    -- > 2 + 2 == 4
    -- True
    --
    -- prop> \lst -> reverse (reverse lst) == lst

Yes, of course, we've thought about it. Equally importantly, we have a "satisfies" keyword for stating checks about properties. (See the example on the Pyret home page.) We use test oracles extensively in teaching; see these two assignments: http://cs.brown.edu/courses/cs019/2012/assignments/sortacle , http://cs.brown.edu/courses/cs019/2012/assignments/oracle .

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

Hmm...Jane Street?

Reply on news.ycombinator.com