Once you accept Curry-Howard, untyped FP languages are hard to take seriously as a foundation for reliability. Curry-Howard changes the entire game. FP and strong types were clearly meant for each other.
Untyped FP languages can be productive, flexible, even elegant (I guess) but they are structurally incapable of expressing large classes of correctness claims that typed FP makes routine.
That doesn’t make them useless, just, you know. Inferior.
I'm impressed Torvalds managed to not know what he was referring to (the Twitter firings).
The missing context whenever this comes up is the fact that it was a surprise one off.
If developers have no idea they're going to be graded by lines of code at some random future date that's a much different situation than saying you're going to give bonuses away every month based on how many lines of code were written.
Everyone knows the second is bad, it'll be gamed massively. The first one could be useful though.
And yes doing it as a one off is still problematic and you can think of all kinds of exceptions, but if you think the organization is full of dead weight in general and overhired massively, a crude stack ranking by lines of code is a pretty good metric for figuring out which (e.g.) 50% is the bottom.
> a crude stack ranking by lines of code is a pretty good metric for figuring out which (e.g.) 50% is the bottom.
I can write you an efficient algorithm in 2 lines or an inefficient one in 50. The metric is about as useful as a doctor checking how often someone picked up a bottle to figure out how much they drink.
> I'm impressed Torvalds managed to not know what he was referring to (the Twitter firings).
I mean, naughty old Mr Car didn't _invent_ this nonsense; IBM was fairly notorious for it in the 80s, say. He's probably the most prominent recent example.
> The first one could be useful though.
How?
> a crude stack ranking by lines of code is a pretty good metric for figuring out which (e.g.) 50% is the bottom.
No. It's really not. For a start, you probably lose basically everyone very senior by that mechanism. But also you lose the troubleshooters.
Last April I asked Claude Sonnet 3.7 to solve AoC 2024 day 3 in x86-64 assembler and it one-shotted solutions for part 1 and 2(!)
It's true this was 4 months after AoC 2024 was out, so it may have been trained on the answer, but I think that's way too soon.
Day 3 in 2024 isn't a Math Olympiad tier problem or anything but it seems novel enough, and my prior experience with LLMs were that they were absolutely atrocious at assembler.
> I wonder how long the open-source ecosystem will be able to resist this wave. The burden of reviewing AI-generated PRs is already not sustainable for maintainers, and the number of real open-source contributors is decreasing.
I think the burden is on AI fanbois to ship amazing tools in novel projects before they ask projects with reputations to risk it all on their hype.
To deliver a kernel of truth wrapped in a big bale of sarcasm: you're thinking of it all wrong! The maintainers are supposed to also use AI tools to review the PRs. That's much more sustainable and would allow them to merge 13,000 line PRs several times a day, instead of taking weeks/months to discuss every little feature.
The difference here of course is in how impressed you are by AI tools. The OCaml maintainers are not (and rightly so, IMO), whereas the PR submitter thinks they're so totally awesome and leaving tons of productivity on the table because they're scared of progress or insecure about their jobs or whatever.
Maybe OCaml could advance rapidly if they just YOLO merged big ambitious AI generated PRs (after doing AI code reviews) but that would be a high risk move. They have a reputation for being mature, high quality, and (insanely) reasonable. They would torch it very quickly if people knew this was happening and I think most people here would say the results would be predictably bad.
But lets take the submitter's argument at face value. If AI is so awesome, then we should be able to ship code in new projects unhampered by gatekeepers who insist on keeping slow humans in the loop. Or, to paraphrase other AI skeptics, where's all of the shovelware? How come all of these AI fanbois can only think about laundering their contributions through mature projects instead of cranking out amazing new stuff?
Where's my OCaml compiler 100% re-written in Rust that only depends on the Linux kernel ABI? Should cost a few hundred bucks in Claude credits at most?
To be clear, the submitter has gotten the point and said he was taking his scraps and going to make his own sausage (some Lisp thing). The outcome of that project should be very informative.
My attitude about software is that it expresses ideas that cannot be owned. Attempting to assert ownership is undesirable and impossible.
So, although colorForth is infinitely valuable, I place it in the Public Domain to make it freely available to anyone for any purpose. There is plenty of money to be made by porting code, programming applications and teaching.
I am having a fine time using colorForth. I won't spend much time promoting it. This site is my attempt to gauge the market. I will rigidly control the version I use."
But when you go to the downloads you see this:
"Download
You can download colorForth thanks to UltraTechnology.
Downloads are still available. But note that COLOR.COM can only run under DOS - not Windows. As you can see above, it's 9 years old and I no longer know how to run it. The current version is available at GreenArrays
This is the exact version I'm using, limited only in the amount of source code provided. It's a 63KB .COM program. You're welcome to use it as you please. But it's a powerful tool, so please be careful."
Android, userspace is Java, and what is exposed on the NDK is a tiny portion, as it is only meant for games and implementing native methods for better performance beyond what JIT/AOT do, or bindings to existing libraries.
About 80% of the OS APIs are behind JNI calls, when using the NDK.
iOS, iPadOS, watchOS, the large majority of userspace APIs is based on Objective-C, or Swift, bare bones C is only available for the POSIX leftovers.
You need to call the Objective-C runtime APIs for anything useful as an app that Apple would approve.
For the Plan 9 geeks, Inferno, OS APIs are exposed via Limbo.
For folks that still find mainframes and micros cool, IBM i, IBM z/OS, Unisys ClearPath MCP, Unisys OS 2200.
For retrogaming folks, most 8 and 16 bit home computers.
Or even one. I know there are operating systems in use that are not written in C, but the major ones are written in C. And anyways, it's not just the OS. There's a pile of C code. Fil-C is a fantastic idea. I think Fil is going to make it good enough to use in production, and I badly want to use it in production.
Untyped FP languages can be productive, flexible, even elegant (I guess) but they are structurally incapable of expressing large classes of correctness claims that typed FP makes routine.
That doesn’t make them useless, just, you know. Inferior.
reply