Alas, the focus is on optimizing job placement at graduation, so intellectually engaging choices are lower priority. We’re in a situation where CS departments are incentivized to spend every year that a student is in school optimizing their ability to produce BFS or DFS in Python within 15 minutes.
I'd be interested in seeing an analysis that traces the programming language paths built into university curricula and how those paths have tended to change over the years. The weakening of theory components is also of interest. My sense is that the trends are real, based on what I've noticed and conversations with instructors in higher education, but I don't have an empirical dataset to support it.
A decent theoretical model can be extrapolated from Goodhart's law. Graduates' performance on programming and leetcode-style interviews is a measure that many stakeholders care about, so it's a target for university departments that would lose value as a measure of educational quality. As a CS department optimizes its performance on that measure, elements of the curriculum are reprioritized. It becomes okay for the department to sacrifice educational quality in order to enhance performance on the measure. What doesn't go directly into the measure, such as experience outside of a core programming language intended for programming interviews, gets chipped away over the years through market pressures as universities' graduates compete for relative performance on the measure. This is a theoretical model, but to me it's convincing.
Well, it's up to the reader to follow the implications. But the industry does hold sway in the design of university curricula, sometimes to the disappointment of academics, and this is nothing new.
Also consider that MIT used the Scheme version of SICP as their introductory programming textbook for years, and it remains a classic, but nowadays MIT leans into Python for introductory programming courses.
Dijkstra was a great computer scientist who was also very generous with his expressions of dismay. You can find him expressing dismay over a great variety of topics not all of which have turned out to merit it in the long run.
This says nothing about whether or not this specific instance of dismay is warranted. All you've said is a man can't be right 100% of the time which I don't find very useful.
You have been voted down, but this is 100% truth. I’d been a professional software developer for 10 years and programming since a young child when I stumbled across the MIT Scheme open course (this was nearly 10 years ago now). Learning Scheme as an exercise dramatically improved me as a software developer, as it is the near perfect teaching language. The fundamentals of most computer science concepts are so clearly laid out, with no distractions. I wish I’d had the exposure at a younger age!
MIT Scheme is pretty much useless as a practical language, vastly less useful than Python. Python is infinitely more powerful to actually “make things”. But this is not the point of University!
The academic languages are powerful for learning, and it is a huge shame that they are being replaced with “professionally relevant” languages.
Real software engineering is a drudgery of stitching together other people's libraries and APIs, responding to the product team's "can't we just...?" queries, and alphabetizing your HTML properties. College doesn't prepare you for that. Shiny happy Schemeland doesn't prepare you for that. It's like the old joke about Bill Gates and the beta version of hell.
Not a fan of Python, but it isn't too bad pedagogically speaking. JS on the other hand... I hope WASM can one day kill it, leave it obsolete, and have it forcefully deprecated like Flash.
Can you explain what you find bad about js ?
I use typescript and I am honestly finding it awesome; and I am the type of person that coded in lisp for a long time.
We have lambdas, flexible structures, FP methods (map, filter, reduce...), can express recursion easily, we have ternary operators, array and object destructuring (const {a,b,...rest}=init()). We have a nice way to deal with asynchronicity. We have some kind of class system. And thanks to typescript we have a really great and expressive type system that's very cool and eases the job a lot.
Sadly true - I majored in math in college and had no plans of going into a programming-heavy job, so I was able to take fun “applied” CS classes like a “language grand tour” or physically based rendering, but skip core classes with those pressures like algorithms etc. entirely.
Ihave been using guile extensively for a couple of years. It has destroyed writing recursive functions in other languages for me. There are no stack overflows in guile, and a recursive function won't fail until you have used all a avilable memory. This lets you write very elegant functions in places where the state is a tree or a linear data structure. Doing the same in python means having to actually deal with state. It just feels so unnecessary and error prone.
I don’t know their motivations, but having the same code work fine on one JS engine / browser / browser version, but totally stack overflow on another seems like suboptimal to me. Explicit tail calls let you error out properly at the call site, Babel-style downcompile it to a loop of some sort, all that stuff.
This could be surprising, but the scenario already exists in production. In JavaScript's strict mode, Safari applies tail call optimization, but systems relying on V8 don't.
To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari.
the same discussion is going on with rust. it lets the compiler enforce that you're actually using a tail call, instead of silently optimizing it when it sees it and otherwise being silent.
Generally the people that care about tail calls write code that relies on them. It isn't just an optimisation. The code is broken (will cause a stack overflow) if TCO isn't applied. So you need to guarantee it.
If I try to trace through the risk profile of bringing TCO into software engineers’ toolkits, it seems that the fear would be of the software engineers growing recursion-happy and writing functions that overflow the stack by inadvertently not leveraging TCO, more than they write recursive functions today that overflow the stack given that V8 offers no possibility of TCO at all? It just doesn’t add up, V8 with TCO and no safety keyword would simply be better than V8 today with neither, so it would still be a strange basis for not delivering the feature.
I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.
It adds up to me. It only takes being bitten once to learn that tail calls aren't optimized, and then you stop using them for recursion (or almost entirely stop). You write a for loop and things work. The overall level of broken code is very low.
If it's inconsistent, then people write a lot more tail calls and a lot more sites break on a lot more devices.
This is the description of a workaround for dealing with tail recursion being broken in V8.
It doesn’t add up if V8 is withholding TCO under the guise that it would cause programmers to write stack overflow bugs unless a new proposed keyword for it gets added to the language. The truth currently is that V8 itself has a stack overflow bug in its omission of TCO, it wouldn’t be right to shift the responsibility for that to the JavaScript programmers. But you’re right, unfortunately the JavaScript programmers are the ones who have to deal with the consequences of V8’s spec non-compliance which causes the stack to overflow when it shouldn’t.
Yup! Hoot uses return_call and friends extensively. Chrome ships tail calls as of 119, Firefox will have them on by default in 4 days when 121 is released, and Safari will have them... at some point.
I don't have favorites, but Spritely is definitely an equal favorite for the projects we support at the Filecoin Foundation for the Decentralized Web. Others HNers may also be interested in include:
The demo is embedded in a iframe towards the bottom of the post. If you are using a browser that is Wasm GC and tail call capable, you'll see something that resembles the gif at the top of the post. If not, you'll see a message about needing to use a different browser.
I love this, I had this idea back in 2020, a lisp that compiles to WASM, and then can compile itself to WASM at run-time in the browser, or any WASM run-time, dogfeed itself. I'm not a compiler guru by any means, so its just one of many things on my bucket list.
The article is presenting a Scheme interpreter running in Scheme, compiled to WASM, not a Scheme compiler, but your idea is also cool. The WASM API apparently doesn't need a pre-made file as its input: you can pass raw bytes generated during runtime into the Module constructor, so it would be totally feasible.
Someone actually wrote a scheme back in 2017 https://github.com/google/schism so this isnt new.
Infact the whole idea of WASM is not new, 20 yrs back Sun had the same idea, embed compiled bytecode inside browser called applets, developed in JAVA. Even flash was a similar idea, though flash VM was riddled with security flaws. This failed to gain wider acceptance, now 20 yrs later we have a embedded bytecode compiler in the browser, but it may work this time.
I don't know why you've been downvoted, I've given you an upvote for linking to an interesting project (even if it's linked in some way to Google). I'd also like to link to the updated GH link: <https://github.com/schism-lang/schism>.
50 comments
[ 0.32 ms ] story [ 167 ms ] threadWhat's some evidence of this trend you can think of?
A decent theoretical model can be extrapolated from Goodhart's law. Graduates' performance on programming and leetcode-style interviews is a measure that many stakeholders care about, so it's a target for university departments that would lose value as a measure of educational quality. As a CS department optimizes its performance on that measure, elements of the curriculum are reprioritized. It becomes okay for the department to sacrifice educational quality in order to enhance performance on the measure. What doesn't go directly into the measure, such as experience outside of a core programming language intended for programming interviews, gets chipped away over the years through market pressures as universities' graduates compete for relative performance on the measure. This is a theoretical model, but to me it's convincing.
For example, back in 2001, Dijkstra expressed his dismay at Java replacing a different functional programming language, Haskell, in UT Austin's introductory programming course. https://www.cs.utexas.edu/users/EWD/transcriptions/OtherDocs...
Also consider that MIT used the Scheme version of SICP as their introductory programming textbook for years, and it remains a classic, but nowadays MIT leans into Python for introductory programming courses.
MIT Scheme is pretty much useless as a practical language, vastly less useful than Python. Python is infinitely more powerful to actually “make things”. But this is not the point of University!
The academic languages are powerful for learning, and it is a huge shame that they are being replaced with “professionally relevant” languages.
I see no problem with that. That's not what university should be about. They're not supposed to be software dev bootcamps for companies.
We have lambdas, flexible structures, FP methods (map, filter, reduce...), can express recursion easily, we have ternary operators, array and object destructuring (const {a,b,...rest}=init()). We have a nice way to deal with asynchronicity. We have some kind of class system. And thanks to typescript we have a really great and expressive type system that's very cool and eases the job a lot.
https://v8.dev/blog/wasm-tail-call
Update: The ticket for v8 to support JavaScript tail call optimization remains open but hasn’t been updated in a couple years. https://bugs.chromium.org/p/v8/issues/detail?id=4698
To illustrate, the following code causes a stack overflow for me in both Google Chrome and in Node.js, but runs without issue in Safari.
I personally had the opposite experience on this one. I had always been told that V8 was a highly efficient JavaScript engine, so I didn’t really worry about writing recursive functions to which I had assumed such a fundamental optimization would be applied. After all, TCO will take a recursive call that would have O(n) space complexity, where n is the recursion depth, and evaluate it in just O(1) — it didn’t seem possible that a highly optimized JavaScript engine would miss something so fundamental. I was both surprised and disappointed when I found out I wouldn’t be able to safely use recursion in JavaScript code that would run on Google Chrome, Android, or Node.js, unless I could guarantee a relatively small depth.
If it's inconsistent, then people write a lot more tail calls and a lot more sites break on a lot more devices.
It doesn’t add up if V8 is withholding TCO under the guise that it would cause programmers to write stack overflow bugs unless a new proposed keyword for it gets added to the language. The truth currently is that V8 itself has a stack overflow bug in its omission of TCO, it wouldn’t be right to shift the responsibility for that to the JavaScript programmers. But you’re right, unfortunately the JavaScript programmers are the ones who have to deal with the consequences of V8’s spec non-compliance which causes the stack to overflow when it shouldn’t.
* Internet Archive's Democracy's Library https://blog.archive.org/2022/10/19/announcing-democracys-li...
* Distributed Press https://distributed.press/
* Guardian Project https://guardianproject.info/
* MuckRack Document Cloud https://muckrack.com/
* Harvard Library Innovation Lab https://lil.law.harvard.edu/
* Human Rights Data Analysis Group https://hrdag.org/data-publication/
Longer list here: https://ffdweb.org/explore/#partners
The current form is too low-key since it looks like a screenshot.