More generally, companies trying to ‘enrich themselves’ are generally trying to provide a product for which there will be demand, either by consumers or other companies. That’s how the system works.
As much as I dislike the move towards javascript/typescript that’s devastating the marketshare of every other language out there (with the possible exception of python, C++ and Rust) I understand the motivation behind it. Having just one language that has a built-in universal GUI and can also do backends on remote servers is just too tempting in this era of mass-connectivity.
I’ve seen, to my amazement, companies and defense organizations switch from large C# codebases to JS. At some point it just becomes a function of how many JS programmers are available and the reduced costs that this implies.
One of the things I have recently been struggling with is trying to figure out whether OCaml is worth teaching/learning, especially when only the luckiest few will get to use it on a day to day basis.
A few years ago, the answer was easier - OCaml was one of the easiest ways to see Algebraic Data Types (ADTs). If you were a Java programmer, you had Scala, but OCaml was there for everyone else. ADTs are definitely worth learning about, without ADTs you will either reinvent them using enums or you will write really puke inducing code. But now we have Rust and TypeScript, for Android/iOS we have Kotlin/Swift. These seem to be more worthwhile to learn in terms of being able to tell an employer that you know them, and they have the side benefit of teaching you about ADTs.
IMO, when choosing which language to teach, whether your students will be using that language in industry one day should only be a minor consideration. IMO, teaching a programming language is all about teaching certain ways of thinking / abstractions — that’s what sticks, and what is hard to come by later in industry.
Once you understand the underlying ideas, learning a new language with a different syntax is a matter of routine. It’s about the way you think, not about the syntax you use to express those thoughts.
That said, I’m talking with the biased perspective of someone with a theory background and a PhD in PL.
To give some depth: when I started at Google I had never programmed in C++, and only once programmed in C during my undergrad. Three weeks later, I was considered a “C++ wizard” by some of my colleagues.
Should I have learner C++ in university? Oh God no, it would have been a terrible waste of time, and it would have taken far longer than learning it later in industey.
I agree completely. And ADTs used to be one “way of thinking” you could teach using OCaml, but there are lots of other languages that we can use to teach that way of thinking now.
First, @smolkaj is right, and I agree with everything they say. I thought I should add: there is value in a language designed for pedagogy. I learned to program in Pascal, and until I’d spent a good bit of time getting good at that, I was a shit C programmer. But once I got to be pretty good at writing Pascal, I could switch to C and write it effortlessly. Scheme served that role in many places. And I think that OCaml can do the same.
I think it’s a mistake to teach students only the languages that are commercially viable at that time: the set of such languages will change over time, and teaching them how to think abstractly outside of the particular language of interest, will improve the chances that they can adapt to changes. Just in my professional career, we went from:
[1995] C/C++ (and saying “garbage collection” would get you laughed out of the building – and I’m talking about IBM Research, not real industry (imagine how it’d be met out there))
[1996] Java
[2007] Ruby
[201?] Python
[201?] Node.js
and on and on. How are we supposed to teach students who will have a 40±year career? We can only teach them how to think independently of the particular language du jour.
Once you understand the underlying ideas, learning a new language with a different syntax is a matter of routine. It’s about the way you think, not about the syntax you use to express those thoughts.
I disagree. That’s the easy part of learning a language. The more important part from the industry point of view is the toolchain, figure out the runtime/memory issues. Your knowledge on the runtime won’t transfer too much in a new language.
The whole point of ReScript is to offer people an enjoyable language while stay in the mainstream toolchain so that they can use it in their daily work.
I think what @smolkaj is saying, and what I agree with, is that, sure details of toolchains and such are important. But they can and will change over time, and as you change jobs. For instance, it is well-known that at Google, C++ is … well, it’s really its own language, different from C++ elsewhere. Go to work at Google, and there is a massive toolchain you have to learn, in order to program C++ effectively. And this will be somewhat true at all workplaces, for all languages. And then there is the evolution of “what is the langage du jour today, eh?”
All of that, is what I would class as “a matter of routine”. If you have a 20-30-year career in programming (I wrote my first code for real money 35 years ago) you will see languages and toolchains come and go. The goal of educators is to teach you a or a few languages, sure. But more importantly, is to teach you how to think about programming, so you can apply that to whichever language you use today. And whichever language you must pick up tomorrow, for your new job.
Hopefully with webassembly gaining popularity we’ll also get the non-javascript languages to make a comeback. I don’t think the industry will turn away from the browser as the default GUI – that’s here to stay. But given the limits physics seems to impose on CPUs, once webassembly is fully operational, there will be serious benefits to being more efficient.
I think there’s far more to OCaml than just ADTs, in particular for teaching/learning.
On the programming in the small side, you should at least also cite the ease of recursion and closure manipulation, the availability of powerful type inference and the often overlooked intuitive model of computation provided by it having a simple operational semantics (Rust is very interesting but has none of these).
But OCaml is almost unique when programming in the large is considered, thanks to abstract types (the module system) and first class modules. I’m always surprised to see that a lot of people almost always ignore the topic of programming in the large when speaking of languages, while I would argue that it’s one of the most important topics (and one that shows that Rust’s zero-cost abstractions are nice, except that they are barely abstractions, as of now in any case).
Imho, the benefits of recursion and closure manipulation are better taught using Scheme or similar, or at least that’s what the institutions I have been involved with do.
I find that programming in the large is very difficult to teach in a class room setting, even though there is an entire field dedicated to it - Software Engineering. The benefits of engineering things one way vs the other are hard to grasp from toy examples even when considering a single langauge. And the weighing the pros/cons of programming in the large using features of different languages (e.g. modules vs type classes) is even harder.
I agree, but I also think syntax can be helpful to learning new concepts/ideas that you don’t already know well. Having good syntax for a concept makes it more likely that you will use that concept, not only when writing code, but even when thinking about it.
For example, even though I understand the concept of immutability quite well, and the difference between C’s const and Rust’s mut may seem mostly syntactic, it’s often enough to push me (and others) to use the 0-character syntax by default.
OCaml’s syntax for modules / module types also makes a huge difference when trying to express the same ideas in Haskell or Scala. (even before anyone mentions the word “functor”)
Many people think they understand the difference between a recursive and a non-recursive definition (and to a certain extent they do), but using a language that distinguishes between let and let rec gives you a much different understanding than if you only learn the concept from languages that don’t make that distinction.
I think in 20-30 years it will eventually collapse. If anything, JavaScript is worse than almost any language out there. While C# is far from perfect, at least it’s better designed. TypeScript might improve things a little but so far it’s the miniscule minority of the JS universe. Likely we will have to live with a bunch of legacy code of shoddy quality that nobody wants to dive in. Like with COBOL nowadays.
I can see the appeal also, but it still seems strange to me. If software is being implemented at a SaaS, rather than an IT department, then there will be back end engineers who have had exposure to multiple languages over their schooling and career, so people can change with some limited effort. Right now, people might aspire to using serverless functions serving graphql requests (I have no direct experience with graphql) speaking to a database, with a SPA front end. I haven’t seen any convincing argument for using hybrid client and server rendering for a SaaS application, so I expect the only sharing between front end and back end to be model types and data serialization and deserialization, and the front end to be a typical client rendered SPA. If the ecosystems for java (scala, clojure), go, python, and node provide about the same functionality, I don’t see why the architects are choosing node over the other options. Seems like scala or go would be preferrable… If the architect is building something slightly more complex, and they have some ability to fill in ecosystem gaps in house, then ocaml and haskell seem like natural options.
Another way to approach this topic is: if you were launching a new software project like Figma, would you target a browser? If you are targeting a browser, then what would you share between back end and front end, and how would that steer which ecosystems that you would consider using?