101–110 of 288 posts
* ML-like syntax for algebraic datatypes and matching. ML got it right; it always seems a bit off when languages try to make ADTs look like some other syntactic construct
* the cyclic and graph declarations
* accessing datatype variants using an OO-like syntax. simply brilliant.
* non-significant whitespace. for all the pros and cons, autoindenting is something i hate to give up.
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…
"""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…
And as other people mentioned, you can always use the check statement out of band, too.
Earlier quoted context omitted.
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…
I feel that the argument for the need for multiline definitions here is a bit weak. You are already putting each definition on its own line, so the definitions are actually fairly close to how their actual usage will look. I feel that if you really need them to be all that long, you are already in weird-style territory, so it isn't such a bad idea to just say "deal with wide files". Overall, it improves ergonomics fo…
data Color = Red | BlackEarlier quoted context omitted.
My jaw dropped slightly to see someone suggest Lisp syntax would be a better starting place for beginners than Python's syntax. Is it just me or is that a fairly unorthodox point of view?
MIT used to teach intro to CS using Scheme, I thought. It's significantly simpler than Python.
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.
Everything is fixable in a new language (-:. Say more!
(I think about tests a lot: http://akkartik.name/post/tracing-tests)
Earlier quoted context omitted.
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…
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.
Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.
Earlier quoted context omitted.
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…
I am in favor of giving links between data a more prominent place in our storage systems. I envision a system where the data is mostly fine-grained trees, like sexprs, where hard-links between trees are first-class entities. But at the end of the day it's just an abstraction over a bunch of bytes.
Somehow, it looks a lot more like lua with a bunch of type-checks and tests added then like python. No named parameters, no generators, no comprehensions that I can see, no focus on iteration in general, no significant indentation, etc. Instead: "end" syntax, unified number type, all blocks produce new scopes (not just functions), local variables are explicit instead of default, etc.
The note about local variables is particularly important; we actively don't want Python's model of variables and scope.