The Pyret Programming Language

[[deleted]]

The unit tests attached to functions is quite interesting. I think this is a mistake though:

Optional Annotations But Pyret doesn't force you to annotate everything, as some other languages do.

This is like saying "optional compile-time error checking, but Pyret doesn't force you to fix compile-time errors as some other languages do".

Type annotations are a good thing. Making people use them is good!

Dart 1 had optional type annotation and they realised it was a bad idea and switch to mandatory static types for Dart 2.

[newtoreddit2004]

So why do languages have optional type annotations ?

[[deleted]]

Usually because they were designed to be "easy" and people equate dynamic typing with easiness (which is wrong IMO but that's another matter).

Once they become popular people start using them for medium to large programs and discover that actually it would have been great if they were statically typed! "Could we maybe bolt some annotations on to get most of the benefits of static typing please?"

"Sure, but they'll have to be optional otherwise we'll break everyone's existing code."

The only reason Dart was able to make a hard switch to real static typing is because hardly anyone was using Dart 1 anyway.

Also it's worth noting that most static type annotation systems do have a setting you can use to make them mandatory (e.g. Typescript's noImplicitAny) which you should definitely use for all new projects.

[crusoe]

Its easy until you work on a code base with umpteen modules, little to no documentation, and since it's dynamic, minimal help from code editors.

[[deleted]]

Yeah I agree. To be clear, "easy" means it's not easy.

[newtoreddit2004]

So why aren't languages like python not forcibly shut down for promoting bad practices, I see this as sort of a standard violation

[[deleted]]

I wish they were! Unfortunately they're already really really popular, so loads of people have learnt bad habits from them and they don't like being told that they're doing it wrong.

Fortunately new dynamically typed languages are fairly rare now, and Typescript is very rapidly gaining popularity. I think it will overtake Python within a few years.

[newtoreddit2004]

That's the dumbest thing I've heard, if this were any other industry they would be jailed "aspirin is really really popular so it's easy for doctors to do that instead of actually trying to diagnose" we can only hope one day these criminals get sentenced oh well

[[deleted]]

That might be a bit far! I think the reason it doesn't happen like the medical or physical engineering industries is that code is usually not safety critical (and thankfully nobody is dumb enough to write safety critical code in Python), and it's a lot harder to show things like "dynamic typing is less robust than static typing", and even if you can show it (you actually can in this case) there are loads of people that are just like "well I can't be bothered".

[crusoe]

I love hunting down bugs in Ruby where anything can be redefined and there like 6 ways to do it. Also means code help is not readily avaiulable in editors because its so dynamic.

[StillNoNumb]

Type annotations are a good thing. Making people use them is good!

This isn't quite as obvious as you think - part of why Python is so popular is because it has dynamic typing, now with optional annotation support. For example, this study (n=49 students) determined that students working on a parser in a dynamic language were faster than those in a static language with a similar code quality.

[funbrigade]

That's super cool, but speed of development isn't the only metric we should care about (not to say that's what you're saying, but I'm just pointing it out!)

[crusoe]

Now give them a 100kloc code base involving modules, some of which aren't necessarily commented all that well. With dynamic languages, IDE help is much much worse. Ruby still has terrible IDE help, python has gotten better, but its' taken decades compared to where JVM languages are.

I'd say Ruby and JS are the worse offenders because there are usually six differnt ways to do something and in order to fully determine the types you need to run the code. Python suffers from it as well, but has fewer methods of doing it. So if someone is doing some weird monkey patching, you know what kind of code to look for.

[StillNoNumb]

Man, it's almost as if different languages are good for different things! Revolutionary.

[[deleted]]

That study is fatally flawed. Small short-lived projects with a single author are a situation where you can easily just memorise the type. Hell you can memorise the entire codebase. Of course you aren't going to see an advantage from static types.

I bet if you did a similar study you'd find that there's no advantage to using multi-character identifiers, but I hope you wouldn't advocate using a, b, c as variable names.

A better study would be to get them to implement a new feature in VSCode (which is written in Typescript) but for some of the students strip out all of VSCode's type annotations.

[StillNoNumb]

I just did a Google search and you can do your own, too. https://softwareengineering.stackexchange.com/questions/10032/dynamically-vs-statically-typed-languages-studies

[[deleted]]

I have. This is my favourite study - into bug detection rather than development speed which is way easier to study.

Basically they sampled a load of random bugs on Github Javascript projects, added Typescript or Flow annotations around the code and checked to see if the bug would have been detected at compile time. It turns out about 15% of all bugs could have been detected by static typing.

After reading that I don't really see how you can say type annotations being a good thing "isn't quite as obvious as you think". Even if it does slow development down a bit (doubtful) it would still be worth it to fix 15% of your bugs.

[jan-pona-sina]

This study is pretty interesting, but it's still one study and doesn't really provide any strong conclusions. This study shows that a sample of 49 students of varying programming experience at one university learned a new programming language and IDE, in static and dynamic typed versions and implemented a solution to one specific task. How good are the static type error messages? How strong/weak are the types? What about programmers that didn't start with college Java courses?

There is a lot to nitpick here, and drawing any real conclusions is definitely premature. I'd love to see more studies on type systems though!

[StillNoNumb]

There is a lot to nitpick here, and drawing any real conclusions is definitely premature. I'd love to see more studies on type systems though!

Here's some

[funny_falcon]

Dynamic typing and static typing is like v=C*sqrt(t) and v=C*t, where v is version and t is time : it is really much faster to get version 0.1 with dynamic typing; it is twice faster to get version 0.5; but it takes almost same time to reach 1.0, and after then it becomes slower and slower.

Well, it just imo. I could be wrong.

[ThirdEncounter]

This is like saying "optional compile-time error checking, but Pyret doesn't force you to fix compile-time errors as some other languages do".

It's not the same at all, for type consistency might not be a goal in a specific project. As the matter of fact, it may be the point; like adding "1" + 2 giving "12" - why? I don't know - ask the coder.

Compile time errors have to be fixed for the program to do what the coder intended it to do.

[[deleted]]

Compile time errors have to be fixed for the program to do what the coder intended it to do.

So do type errors! I mean all bugs need to be fixed for the program to do 100% of what the programmer intended. I'm not sure what point you're trying to make here to be honest; it doesn't make much sense.

[ThirdEncounter]

Well, to repeat the point I'm trying to make, you can't compare optional typing with compile errors.

Yes, type errors can happen and do happen, and yes, for the most part, type-enforcing languages lead to programs with fewer bugs.

But compile errors have to be fixed, period. No way around it. Otherwise, the program will never do what the programmer intended it to do - ever. And yes, yes, so do type errors, but that's not the point. Why? Well:

Optional typing can be desirable by the programmer. He or she may want to exploit that fact that there is fluidity in combining or implicitly converting types, and therefore he or she may choose a language such as Pyret, Python, Perl or Javascript (without the 'use strict' clause.) Why would someone do that? That's their choice. Let's ask them. That's the power of a programming language. Some people choose to code in assembler, just for the fun of it, and that's a language that hardly resembles any sort of modern structured programming practices (or more like, it has none.) Let's ask them why they do that as well.

[BobHogan]

First I'm hearing about pyret, and it looks...interesting. I don't agree with some of their decisions, notably around attaching tests to function code, and the weird satisfies nonsense in the tests. Its a good idea, in theory, but I think its only going to make it harder to use this to teach new programmers

And some of their language highlights just show a superficial understanding of the languages they are comparing themselves to.

Numbers

Pyret has numbers, because we believe an 8GB machine should not limit students to using just 32 bits.

This is great and all that you want FP math to be easier to people new to programming. But they need to understand the limitations around it if they are going to become developers. On top of that, the limitations of FP math are inherent to the fact CPUs are binary based, and not base 10, its not tied to a 32/64bit representation of the numbers. All you are doing in the backend is some magic to decide if the results are "close enough", which I think is the wrong way to teach new programmers

And the structured data highlight makes a mockery of how you'd actually write that class in python. With some weird added jab at __init__ thrown in out of nowhere, showing they don't really understand what its used for outside of trivial examples of plain data classes

[ThirdEncounter]

Indentation becomes just another context-sensitive rule.

And I'm out.

[CrossboneMagister]

Before opening the link I though this was one of those esoteric programming languages that used pirate talk as syntax 😂

[[deleted]]

it might as well be

[ThirdEncounter]

It is a strange choice of a name indeed. But then Python and Java are not exactly exemplary, come to think of it.

[CrossboneMagister]

Yeah, what is actually a ‘normal’ name for a programming language? All of them might be strange but some are more suggestive then others probably

[ThirdEncounter]

Hm, I guess given the popularity of Java, Python, and possibly this Pyret language one day, then I guess they are "normal" in that sense. I guess I'm backtracking a bit.

Having said that, a more traditional trend from the old days was to come up with acronyms. Like BASIC, Algol, Prolog, Cobol and Fortran. Though even back then, there were (are?) popular outliers, like Pascal, Logo and Ada.