Pyret: A new programming language from the creators of Racket
231–240 of 288 posts
Re: Pyret: A new programming language from the creators of Racket
#232I can't find any documentation on the type system. In particular, I'm interested in how objects are typed (that they're both structurally typed and may be abstract is novel), and the capability of the type refinements. I loathe template-based OO due to the possibility of monkey-patching but the fact that objects are immutable looks like it might ease this. (Generating efficient code might still be difficult.) I don't…
The type system hasn't been published yet. We don't have monkey-patching. We've been burned too much by JavaScript and the like. Cyclic structures: think about trying to teach graph algorithms. Let's say you believe it's important to write tests. Many graph algorithms aren't inherently mutational. But you need mutation just to create examples of your data. The graph construct gets around this problem entirely, so mut…
OK, I'll buy this.
Re: Pyret: A new programming language from the creators of Racket
#233Re: Pyret: A new programming language from the creators of Racket
#234Earlier quoted context omitted.
Well, I'm guessing not that many are using Pyret as a first language (yet) either... (Actually, I think a few people are still using Squeak to teach kids programming, so that's not even true)? Anyway, I was more curious if you'd done such a study because a) It's a very concise and consistent syntax, and b) with all the great work that appears to go into Pharo Smalltalk it would seem to be viable option (again). And y…
Sorry, my point was not to get into a popularity pissing match. I do believe popularity and quality are largely unrelated. What I meant is, since most people have stopped teaching with Smalltalk, it's really hard to do the kind of research I'm talking about! We had no trouble doing it for Racket because we were able to get lots of data and from it measure for statistical significance.
I can certainly understand why you wouldn't "just try Smalltalk on a class or two", though!
Re: Pyret: A new programming language from the creators of Racket
#235Earlier quoted context omitted.
I realize it's a trade-off -- but I think having ";" as an alias for "end" (or vice-versa) is a pretty bad idea. I personally prefers python's indentation-for-blocks syntax, but I understand why you want semantics to be decoupled from indentation. But when using explicit end-markers, I'd prefer to match them to the start, maybe even introducing some verboseness, like: end-case, end-if etc -- maybe taking it further a…
I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word…
I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag? (you type case, the editor appends esac (but below the point you're typing)):
1: | #your cursor at |
2: case|
3: case:
| # you hit enter or something, ready to fill in
esac # editor has closed block/statement
I imagine typing-skills isn't much of an issue when editing/copying text -- as opposed to typing in new code?Re: Pyret: A new programming language from the creators of Racket
#236Earlier quoted context omitted.
Your second paragraph answered your first paragraph (-:. 1. We have a different view of static typing than Racket. 2. We have a different view of the type language than Racket. 3. Long term, we are working on smoothly integrating testing, types, and specification [as a spectrum -- perhaps even as a cycle -- rather than as three different things]. Refinements are an instance of this. Another is our plan for how to do…
I am also convinced that parenthetical syntax has real problems that I can't completely ignore. What brought you to this conclusion? Experience from Bootstrap (in which I found arithmetic and parenthesis counting to be the biggest stumbling blocks) or just personal reflection?
Re: Pyret: A new programming language from the creators of Racket
#237Earlier quoted context omitted.
Doc tests are a poor solution precisely because they are difficult to edit. The solved a non-problem and made writing documentation AND tests more difficult. Instead of writing tests in strings, the documentation tool should have been modified to render that code _in_ the documentation.
I agree with you in that managing real code in a place that gets less frequently executed is a bear, but I wanted to emphasize the value of having tests very near to the primary documentation for a function. That's a complete win, I feel.
def test_foo():
assert False, "test code for foo"
def foo(farb):
pass
Tests should absolutely be next to the code. The test should make it into the documentation. Code is documentation and should make it into the generated documentation, not the first thing you see but it should be there along with commit history, etc.Re: Pyret: A new programming language from the creators of Racket
#238Earlier quoted context omitted.
If you need guideposts, use an editor with paredit support and rainbow delimiters. This makes Lisp feel far more intuitive and tree-like than normal.
You seem to be under the impression I haven't programmed in Lispy languages. And our data are from students using DrRacket, which very much has paredit support. These are just inconvenient truths.
Re: Pyret: A new programming language from the creators of Racket
#239Earlier quoted context omitted.
I have wrestled with "uniform closing" vs "non-uniform closing" designs for ages. For those not clear on what I mean here's an example: Lispy syntaxes have a uniform close (it's always ")"), whereas XML syntaxes don't (you have to put the name of the opening tag in the closing token). So e12e is making an argument for XML-y over Lispy. However, choosing good words is really, really hard. If you pick a different word…
> Some of our target audiences are middle- and high-school students, some of whom have weak typing skills (we know from numerous workshops we run). Increasing even the raw number of characters is a real problem for them. I certainly understand this argument, and I generally favour simple syntax over smart tools -- but how much of a difference would this make in an editor/IDE that automatically inserts the closing-tag…
When editing/copying, it's not typing skills but editing skills, which are arguably subtler and even harder.
Re: Pyret: A new programming language from the creators of Racket
#240But please remove the minus sign from identifiers! I am concerned that people may abstain from Pyret for this simple reason. It is really annoying to embrace every operator with blanks. That should be an optional job for the IDE to increase readibility.
By the way, is there already a raco exe for Pyret?