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.

[–] Kaligalis@lemmy.world 8 points 10 hours ago (2 children)

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).

[–] MonkderVierte@lemmy.zip 1 points 39 minutes ago

the technical term there is brain fart

Or neuroactive substance. Like, drugs. And ADHD meds. And drugs.

[–] jjj@lemmy.blahaj.zone 5 points 7 hours ago (1 children)

strong typing

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:

Static vs dynamic
Implicit vs manifest

e.g.

Rust's is mostly static and sometimes optionally implicit
Haskell's is static and optionally implicit
Python's, Lua's, etc is dynamic and implicit
C's is static and manifest

[–] bss03@infosec.pub 2 points 4 hours ago (1 children)

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.

[–] jjj@lemmy.blahaj.zone 2 points 3 hours ago

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.

[–] zarkanian@sh.itjust.works 6 points 11 hours ago

All you've demonstrated with this comment is your lack of imagination.