Many new languages are still recycling ideas from the 1970's research labs. Outside affine types, all the praise for Rust's type system traces back to Standard ML from 1976. The heretic of doing systems programming in GC enabled programming languages (GC in the CS sense, including RC), goes back to research at Xerox PARC, DEC and ETHZ, late 1970's, early 1980's. Other things that we know, like dependent types, effect…
It seams like most things boil down to ideas from the 70's. The internet, distributed computing, AI, etc...
> most things boil down to ideas from the 70's
Rather from the sixties. E.g. OOP including dynamic dispatch, late binding, GC etc. appeared 1967 with Simula.
Programming languages are obsolete in the LLM era. What current generation AI has revealed is that English is actually the ultimate representation of computer programs and systems, which is both sufficiently terse and precise to economically describe the operation of arbitrarily complex programs. There is no reason to study programming languages in 2025, other than as a historical curiosity - the same way one may stu…
Good luck debugging and fixing the multitude of errors introduced by your LLM. ESPECIALLY if you're outputting some low-level assembler or machine code. At least when we have our AI outputting Java/Typescript/Python/etc, it's easy (for a programmer) to see where it's run afoul.
I have every confidence that even current generation state-of-the-art artificial intelligence will have far superior facilities at debugging and managing the complexity of even its own bare metal programming output than humans.
Why? Consider Gemini's recent performance at the International Collegiate Programming Contest [0], in which it solved a problem that no other human team was able to solve.
Wetware intelligence is itself obsolete, at least as concerns the domain of computing.
> Usability is similarly ill-defined and hard to measure. Human factors are very well studied and standardized, and there is a well-established discipline called "Human Factors Engineering", which also provides established test and evaluation methods. Human Factors research is considered solid and well-established because it has been built on rigorous experimental psychology and engineering principles developed over…
Apart from ADA, what are languages / stacks with most aspects of "Human Factors Engineering" considered?
Perl is one obvious one, as anyone will realize, if one has read some of Larry Wall's articles about his (and later the team's) motivations for the (syntax and semantics) design decisions they made about the language. For example, in his annual State of The Onion talks, he often discusses these points. They may not have used standards such as the gp comment mentions, but they definitely considered human factors a lot…
Perl presents a fascinating counterexample: Larry Wall, trained as a linguist, explicitly cared about human factors, but his linguistic philosophy produced a language that empirical tests show performs poorly on readability and learnability measures (see e.g. http://dx.doi.org/10.1145/2534973 or https://doi.org/10.1145/2089155.2089159 ).
Just like human dialects, across the same main language, :)
It seams like most things boil down to ideas from the 70's. The internet, distributed computing, AI, etc...
> most things boil down to ideas from the 70's Rather from the sixties. E.g. OOP including dynamic dispatch, late binding, GC etc. appeared 1967 with Simula.
Old languages died or are barely in use anymore. I think it is more interesting to see which languages are still used today and how popular these are. Because this is also tied to the human user/developer. For instance, I used BASIC when I was young - not as a professional but as a hobbyist. I liked it too. I wouldn't use BASIC today because it would be entirely useless and inefficient.
Depends pretty much on what BASIC compiler one is talking about.
But is that a problem of the language itself, or is it just a problem of available toolchains? E.g. if the gcc compiler collection would come with BASIC support and you just could type something like "gbasic -O3 foobar.bas -o foobar" to get a properly optimised executable out of your BASIC source code file then some may would still use BASIC today, I guess? I started with BASIC too. Also enjoyed BlitzBasic2 for a lon…
Realistically? No, not at all. The reason there are no toolchains for BASIC is because nobody uses BASIC (because it's not functional in our modern world), not the other way round.
Good luck debugging and fixing the multitude of errors introduced by your LLM. ESPECIALLY if you're outputting some low-level assembler or machine code. At least when we have our AI outputting Java/Typescript/Python/etc, it's easy (for a programmer) to see where it's run afoul.
I have every confidence that even current generation state-of-the-art artificial intelligence will have far superior facilities at debugging and managing the complexity of even its own bare metal programming output than humans. Why? Consider Gemini's recent performance at the International Collegiate Programming Contest [0], in which it solved a problem that no other human team was able to solve. Wetware intelligence…
> solved a problem that no other human team was able to solve.
> most things boil down to ideas from the 70's Rather from the sixties. E.g. OOP including dynamic dispatch, late binding, GC etc. appeared 1967 with Simula.
GC was a bit earlier. :)
Earlier than the sixties? All elements of OOP were known before 1967, but their combination, which we still use today under the title OOP, appeared in Simula 67 for the first time. I think the first appearance of a GC in literature was in 1960.
> Usability is similarly ill-defined and hard to measure. Human factors are very well studied and standardized, and there is a well-established discipline called "Human Factors Engineering", which also provides established test and evaluation methods. Human Factors research is considered solid and well-established because it has been built on rigorous experimental psychology and engineering principles developed over…
Honest question: given the relatively niche status of Ada compared to other systems programming languages, and similar diminished levels of popularity for other languages mentioned in this thread (Pascal, Perl), does this really prove that these principles are particularly effective for programming languages? I understand that this is a relatively small sample size, but I feel like that could be just as well used to argue that other factors might have been more important to the successes of languages designed like Ada than the more rigorous approach to human usability. It doesn't feel particularly obvious to me that we know these principles actually work well for programming languages but choose to ignore them rather than them not fitting the domain particularly well at all, or maybe something in between where we don't really know whether they apply well yet or not, and more attempts at using them might not actually be as successful as one might hope.