"Pyret has numbers, because we believe an 8GB machine should not limit students to using just 32 bits."
Java Pyret
// this is not true # this is true
((1 / 3) * 3) == 1 ((1 / 3) * 3) == 1
wat
How about ((1.0 / 3) * 3) == 1? Not sure what point they are trying to make here. Did somebody change the definition of "number" to mean "floating point type?"
In Pyret, (1 / 3) resolves to (1 / 3), not 0.3333333333333333 or some equivalent, like it does in many other languages. (0.3333333333333333 * 3) is 0.999999999999999, not 1.
That makes sense, but unfortunately the Pyret page says nothing to indicate that arithmetic is done in the rational field.
For the record, 1.0 compares equal to (1.0 / 3) * 3 in IEEE 754 32-bit floating point arithmetic. You may want to consider a more compelling example, ie
float x = 1.0;
for (int i = 0; i < 10; ++i) {
x += 1.0 / 10;
}
x == 1.0 // False
From what I'm reading, Pyret numbers are either exact rational numbers (which includes integers) or inexact floating point numbers (presumably, they're disambiguating this by whether or not you use a decimal point).
Available RAM (something 8GB plausibly could refer to, unlike address-space size) is arguably more relevant to the issue here (which is the desirability of not using fixed-width integers and floating point but instead preferring arbitrary-precision rational numbers as the default.)
Why are all "learning to program" languages these days duck typed / dynamically typed? Has it always been this way? Has SML, for example, been a first language of choice in Programming 101 in earlier decades?
Personal bias : I think there is a definite loss in not teaching about the power of static typing in a first language.
Beginners have very incomplete mental models of programming languages (if they didn't, they wouldn't be beginners...) I believe the experience of the PLT group, who have been teaching introductory programming for some 20 years and definitely understand type systems, is that static types can get in the way of learning. There are two reasons:
- Type errors for most type systems are very difficult to diagnose for beginners. They often aren't, for example, located on the actual error location in Hindley-Milner style type inference.
- Allowing students to run their code helps build a correct mental model. In particular it allows them to locate the errors in their code.
Note that Pyret does have a facility for dynamic checks that serves a similar purpose to static types.
In addition to @noelwelsh's reply, I want to add that we are very much working on a type system (we have a working internal prototype). We are also working on a very different kind of type inference, unlike Hindley-Milner. For us, it's important that the error story be as good as the "proper functioning" story, which is why we haven't released these. But it does mean that in the near future, people will be able to program in the typed language starting whenever they want, including from the very beginning. (And then we can do some experiments, too!)
the data declarations (remind me of scala's case classes) and
the "progressive" type annotation (which mimics the way i use cython + python)
(less appealing, and this is purely subjective of course, is your logo, which seems to have been inspired by malware or perhaps by labels required for toxic chemicals)
>...your logo, which seems to have been inspired by malware and perhaps labels required for industrial chemicals
Or maybe "pyret" is pronounced like "pirate" and the logo was inspired by the skull-and-crossbones pirate flag. I especially like how the crossbones look like the letter lambda.
How about ((1.0 / 3) * 3) == 1? Not sure what point they are trying to make here. Did somebody change the definition of "number" to mean "floating point type?"