this post was submitted on 23 Jun 2026
201 points (97.6% liked)
Programmer Humor
31948 readers
849 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It really does mystify me what anyone thinks they're accomplishing by creating a brand new programming language these days. Other than a purely academic exercise, of course.
Whatever features you want your language to have, there's probably already a language out there that's damn close to it. And if your ideal language is just like some existing language except for a few niggling details ... then there's no need to start from scratch -- just make a modified version of that language with a few little changes to make it act the way you want.
Programming languages are just about a solved problem now, IMO. I can't imagine any scenario where creating a new language from scratch would be better than tweaking an existing language ... or just using an existing language as-is.
I think there are programming paradigms that haven't even been discovered yet. Rock music was "discovered" centuries after baroque music, and composers back then would have thought baroque music is the ultimate musical genre, which could not have been improved upon.
I've been working on a programming language recently that sort of programs itself. It's hard to explain how it works, since I approached it from a mathematical direction, but for a domain and range defined with a set of correct input-output pairs, there are an infinite number of functions which correctly maps one input to its corresponding output. If we define f_1 as all functions which correctly map the first IO pair, f_2 as functions which correctly map the second IO pair... Etc etc until we reach f_N, then the set intersection of all f_1...f_N is the set off all functions which satisfy our requirements. From this set of known correct functions, we can sort them by speed or some other trait.
But the devil's in the details there. I won't go into how I get f_1...f_N, but I'm having fun thinking about it & designing it. It may even be useful some day.
Rust is pretty fresh and really innovated a lot with its actual safe-by-default approach in a non-managed language actually able to replace C and C++.
Most new languages aren't a Rust, but just a Python (yet another low-performance language assuming you don't actually need strong typing to realize later that actually, you do). But a Python is definitely easier to get started with than a Rust (or the footgun languages, it is able to replace). So there is definitely a use case for that too.
Go is a good case of a young system application language designed for simplicity.
And everyone creates a domain specific language once in a while. Those can make specific tasks a lot easier.
Programming languages don't really look like they are a solved problem. It seems like everything gravitates to Hindley Milner over time. But mainstream languages finally adopting null-checking at compile time by default and language features for parallel execution reaching the mainstream are recent enough that I think, there might still be a long way to go.
And obviously, you want AI to code in a language which is as much deterministically compile-time-checked as possible because of the hallucination problem (which btw, is also present in humans; the technical term there is brain fart). I expect that to be something which requires writing actual mathematical proofs like one does in Coq solely because AI doesn't try to kill you if you insist on it writing mathematical proofs for everything.
The scaling limit already is the humans who have to do the code review. So any language which makes more bugs more obvious before the code reaches the review stage is extremely valuable even if writing code in it is a real PITA for humans (as long as they can read it, it's fine).
Or neuroactive substance. Like, drugs. And ADHD meds. And drugs.
Grrrrrrr. (this term is ambiguous but still very popular for some reason https://en.wikipedia.org/wiki/Type_safety#Strong_and_weak_typing)
There are other well defined ways to describe a type system, such as:
e.g.
If you read the literature, particularly "Types and Programming Language", you'll find that "dynamic typing" isn't even considered typing. If you can have a type error at runtime you've defeated the reason to add a type system: to reduce runtime errors. The hope is that "well-typed programs don’t go wrong" tho there are some limits to what any type system can do (e.g. Rice's Theorem).
That said. Static v. Dynamic is much more precise than Strong v. Weak and should be preferred.
Implicit v. Manifest is less useful just because it's a broad spectrum, basically inculcating how much type inference is done and "how much" generally depends a lot the input program(s). Haskell does whole-program inference, tho GHC (the only Haskell compiler) has a number of syntactic forms that can't be inferred. Scala only does local inference. C doesn't infer types, though is gets close with how it treats functions with no-argument in the prototype and varargs stuff. C++ uses auto for some type inference, which is still somewhat manifest, but also mostly implicit.
I think weak typing is a good name for when there are invisible coercions, but that doesn't actually have much to do with proper types.
Anyway, great comment, If more people would use static/dynamic and explicit/implicit instead of strong/weak, there'd be less miscommunication.
Practically, dynamic typing is quite different from no typing, such as with the B programming language, although I agree that it often defeats certain benefits of type systems.
Agreed. I don't think it should be called typing; it's more tagging (yes, like tagged unions). But, I don't think I'll see that semantic shift in my lifetime.
Anyway, I prefer my types static and my functions curried, which is why I do PureScript, Idris, and Haskell for my personal projects.
All you've demonstrated with this comment is your lack of imagination.