71–80 of 288 posts
Those "new" languages keep looking more and more like BASIC.
"""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…
"""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…
(with-test
(defn my-function [x y]
(+ x y))
(is (= 4 (my-function 2 2)))
(is (= 7 (my-function 3 4))))"""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…
That really caught my eye! Does anyone have any experience with workflows like this? Are tests next to code a pragmatic technique?
"""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…
However, the `where` tests play into the type-inference story for the language!
Python-like syntax with pattern matching and recursive ADTs!? What a great idea!
+1 This looks a lot like the language I've been dreaming about. I actually like the explicit `end` keyword to materialize the end of blocks. The lambda expression syntax, as illustrated by the filter/map/fold example, looks like Ruby blocks with a much simpler syntax. A couple of questions to the crew: Why advertise it as a teaching language ? As a working programmer this looks very appealing to me. Are there limitat…
As to why we're advertising it as a teaching language: Our group has a design sense of how to do this, and Pyret's success in the classroom is what we're able to study, measure, and focus on improving. That doesn't mean we won't be thinking about managing million-line codebases or getting great performance out of the runtime, but those concerns won't necessarily be the main guide of our design decisions. We may very well end up with something that's a superb general-purpose language, but I'm not yet willing to give folks that expectation, or do so at the expense of the learning experience. Make sense?
EDIT to add: One thing that the Racket community has very successfully done is separate teaching languages from the main Racket language. A probable future for Pyret is splitting it into teaching and professional versions. I'd love to hear feedback about what more you'd like to see in Pyret, with this split in mind.
The getting started guide (http://www.pyret.org/getting-started/) and tour (http://www.pyret.org/tour/) is the best reference for getting started right now. If you didn't see those then they probably need more prominent placement.
Earlier quoted context omitted.
Making tests part of language syntax is an interesting idea. Of course it's not equivalent, but Python doctest module at least allows you to keep tests close to the code. Here's Pyret example, ported to doctest: def sum(l): """ >>> sum([]) 0 >>> sum([1, 2, 3]) 6 """ return reduce(lambda x, y: x+y, l, 0) if __name__ == "__main__": import doctest; doctest.testmod()
> 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.
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".
"""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…
Sounds like Eiffel: http://en.wikipedia.org/wiki/Eiffel_(programming_language)#D...
"""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…
Racket has a very powerful contract system that you might want to out. It also has support for higher-order contracts on functions (contracts that have delayed checks instead of being just assertions) and they also have a typed version of Racket (Typed Racket) built using the contract system.
Earlier quoted context omitted.
D has something like this[1]. It might have come from a still-earlier language. [1] http://dlang.org/unittest.html
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.