Will Pyret ever be a full-fledged programming language?
Yes.
That doesn't mean it will ever become a prevalent vocational programming language.
"The shortest distance between two points is a straight line."
"The shortest path is not always the fastest."
People intuitively believe that they will acquire the skill of programming while they learn their first vocational programming language because they create a false equivalence to learning to communicate when they learn their first natural language when they grow up.
But with programming you'll likely have to learn multiple programming languages during your career — some of which exist in completely different paradigms.
From that perspective it's an advantage to start in a "sweet spot" and branch out from there. But there is no industrial programming language that exists in that "sweet spot" — that is where Pyret tries to position itself.
Beginner-friendly programming tips, tutorials, and resources. Follow us for the topics to kickstart your journey in the world of code. https://marinsborg.com
Thank you for this. I have never heard of it before.
I wrote in the previous post that programming concepts are not bounded to programming languages. And I explained logic using flowcharts.
I'll make research on this for sure.
Flow charts are about "flow of control" or as Rich Hickey would put it Place-Oriented Programming (statement-oriented) — "data-centric" programming tends to focus a lot more on "flow of data" (value-oriented; expression-oriented).
Both PLOP and VOP are valid but they are also quite different. In terms of learning progression, VOP seems to be easier to learn and the VOP -> PLOP transition seems to be (a lot) easier than PLOP -> VOP for a lot of people.
Michael Feathers
@mfeathers
OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts.
Beginner-friendly programming tips, tutorials, and resources. Follow us for the topics to kickstart your journey in the world of code. https://marinsborg.com
Nowadays you muck around with incomprehensible or nonexistent man pages for software you don't know who wrote. You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts. This is a fundamentally different job, and it needed a different course.
In terms of educational resources the competition for an audience is immense so why would students choose to work in a language that appears nowhere in the job postings or isn't the latest shiny object in the tech world?
Pyret is never going to be trendy.
Even with the anecdote I've already shared there'll likely never be conclusive evidence that Pyret is indeed a better choice for most people (there are always exceptions) — there are just too many variables that can't be controlled.
Both courses were taught by different instructors with different personalities, teaching styles and using different course designs.
Students are usually free to switch courses early in the term, so the representative attitude of any student choosing to take one course over the other could be very different.
Pyret was designed to be better for teaching/learning programming — but whether it's actually successful is anybody's guess and YMMV will never be eliminated.
Another aspect is that it's never been easier to start programming with something, so lots of people get exposed early in life in an unstructured way. This leads to situations where poeple resent having to learn another programming language that most employers don't recognize or will give them paid work for.
So really all that can be done is to raise awareness that Pyret exists and why it exists, so that people that are in this for the long haul can at least take it under consideration.
When I learned to program I learned FORTRAN, BASIC, APL and COBOL. Now APL was way out there, too much so, especially as it required a special keyboard (or just added another layer of hurt by using an ASCII keyboard — imagine entering a program by typing the number codes of unicode code points). In hindsight FORTRAN, BASIC, and COBOL weren't actually three different programming languages but just three different dialects of the same programming language. Then we got to Pascal in 2nd year; it was way nicer than the earlier ones but again — just another dialect. Had to work with some SQL precursor/competitor in 3rd year aside from x86 and 68000 assembly. Didn't get to C until 4th year for OS programming and image processing.
For an AI graduate course got to choose between LISP and Prolog; foolishly chose Prolog (yay! Pattern matching) — it seemed shinier at the time. Up to this point now it's been strictly structured programming. I had to teach myself C++ and Object-Oriented analysis/design/programming on the job. Essentially became an OO dogmatist especially in the face of people using C++ as a "better C" claiming OO status while continuing to program procedurally.
Learned C# for MCAD/MCSD.NET certification. Learned Java for SCP/SCBCD/SCWCD certification.
Tried to learn Ruby and ended up tossing Programming Ruby across the room (deepest apologies to the authors; the only other book I did that to is Information Modeling and Relational Databases; Chapter 3 is good but the book had the annoying habit of assuming knowledge early on that it would only impart later). So at this point if it wasn't using a C-style syntax it was going to be a problem for me.
So I decided that my "in a rut OO mindset" needed shaking up — and took on Clojure. It was ugly and utterly painful but ultimately worth it. Liberated of that imperative mindset I was able to move on to Elixir (this time the Ruby-style syntax did not slow me down one bit), Erlang, visit Haskell (as a tourist), OCaml.
Had a quick glance at Go (meh), Python (meh), PHP (meh).
Started two years ago with Rust and one year ago with TypeScript (though I still don't really consider that a language).
At this point it's a teaching language but
That doesn't mean it will ever become a prevalent vocational programming language.
People intuitively believe that they will acquire the skill of programming while they learn their first vocational programming language because they create a false equivalence to learning to communicate when they learn their first natural language when they grow up.
But with programming you'll likely have to learn multiple programming languages during your career — some of which exist in completely different paradigms.
From that perspective it's an advantage to start in a "sweet spot" and branch out from there. But there is no industrial programming language that exists in that "sweet spot" — that is where Pyret tries to position itself.
In terms of research:
While successful, the Scheme-syntax left some students behind which is ultimately why Pyret was developed from the ground up.
There are a number of videos with Shriram Krishnamurthi and Matthias Felleisen talking about their work available on the web.
Thank you for this. I have never heard of it before.
I wrote in the previous post that programming concepts are not bounded to programming languages. And I explained logic using flowcharts.
I'll make research on this for sure.
Flow charts are about "flow of control" or as Rich Hickey would put it Place-Oriented Programming (statement-oriented) — "data-centric" programming tends to focus a lot more on "flow of data" (value-oriented; expression-oriented).
Both PLOP and VOP are valid but they are also quite different. In terms of learning progression, VOP seems to be easier to learn and the VOP -> PLOP transition seems to be (a lot) easier than PLOP -> VOP for a lot of people.
I am glad you shared this with us. Would you maybe write some post to promote this language for beginners?
What is there to say beyond what is already stated on A Rationale for the Pyret Programming Language?
And whenever I broach the subject of learning "to program" before learning a "practical" programming language the response invariably ends with:
Peter Norvig: Teach Yourself Programming in Ten Years
Proactive transfer simply doesn't make a lot of sense to people.
In 2009 MIT's introductory programming course, 6.001, switched from Scheme to Python:
In terms of educational resources the competition for an audience is immense so why would students choose to work in a language that appears nowhere in the job postings or isn't the latest shiny object in the tech world?
Pyret is never going to be trendy.
Even with the anecdote I've already shared there'll likely never be conclusive evidence that Pyret is indeed a better choice for most people (there are always exceptions) — there are just too many variables that can't be controlled.
Pyret was designed to be better for teaching/learning programming — but whether it's actually successful is anybody's guess and YMMV will never be eliminated.
Another aspect is that it's never been easier to start programming with something, so lots of people get exposed early in life in an unstructured way. This leads to situations where poeple resent having to learn another programming language that most employers don't recognize or will give them paid work for.
So really all that can be done is to raise awareness that Pyret exists and why it exists, so that people that are in this for the long haul can at least take it under consideration.
When I learned to program I learned FORTRAN, BASIC, APL and COBOL. Now APL was way out there, too much so, especially as it required a special keyboard (or just added another layer of hurt by using an ASCII keyboard — imagine entering a program by typing the number codes of unicode code points). In hindsight FORTRAN, BASIC, and COBOL weren't actually three different programming languages but just three different dialects of the same programming language. Then we got to Pascal in 2nd year; it was way nicer than the earlier ones but again — just another dialect. Had to work with some SQL precursor/competitor in 3rd year aside from x86 and 68000 assembly. Didn't get to C until 4th year for OS programming and image processing.
For an AI graduate course got to choose between LISP and Prolog; foolishly chose Prolog (yay! Pattern matching) — it seemed shinier at the time. Up to this point now it's been strictly structured programming. I had to teach myself C++ and Object-Oriented analysis/design/programming on the job. Essentially became an OO dogmatist especially in the face of people using C++ as a "better C" claiming OO status while continuing to program procedurally.
Learned C# for MCAD/MCSD.NET certification. Learned Java for SCP/SCBCD/SCWCD certification.
Tried to learn Ruby and ended up tossing Programming Ruby across the room (deepest apologies to the authors; the only other book I did that to is Information Modeling and Relational Databases; Chapter 3 is good but the book had the annoying habit of assuming knowledge early on that it would only impart later). So at this point if it wasn't using a C-style syntax it was going to be a problem for me.
Learning JavaScript seemed like a good idea but JavaScript: The Definitive Guide, 5e somehow missed the mark for me, though I managed to regain some momentum with JavaScript: The Good Parts but felt somewhat thwarted by Functional Programming in JavaScript.
So I decided that my "in a rut OO mindset" needed shaking up — and took on Clojure. It was ugly and utterly painful but ultimately worth it. Liberated of that imperative mindset I was able to move on to Elixir (this time the Ruby-style syntax did not slow me down one bit), Erlang, visit Haskell (as a tourist), OCaml.
Had a quick glance at Go (meh), Python (meh), PHP (meh).
Started two years ago with Rust and one year ago with TypeScript (though I still don't really consider that a language).
It is from this perspective that if I was to start programming today I would hope that some mentor would strongly recommend that I have a very good look at A Data-Centric Introduction to Computing (Pyret) and How to Design Programs, 2e (Scheme).
But that's just my opinion.
FYI:
Bootstrap World (free) courses