An Overview of TUNIS: A UNIX Look-Alike Written in Concurrent Euclid (1982)
archive.org
archive.org
It seems like a huge over-reaction.
History says the Euclid approach was a huge over-reaction, but consider also the naive memcpy:
while(count--)
*dst++ = *src++;
You might consider no-aliasing imperative to have been an attempt to stake out a halfway position between "pointers are the goto of data structures" wild west full imperative, and "no mutation, even when unaliased" strict functional, disciplines.
Another example is the whole dynamic scripting language world considered as a reaction to the terrible static world of the 1990s. Yes, the 1990s were too static, no question, but that didn't mean we needed to turn all objects into hash tables, be able to dynamically re-write classes on both the class and the instance level, and just generally make everything, everywhere so dynamic that the language spends the majority of its runtime basically checking to see that nothing has dynamically changed since last time it did something.
The PL design world is learning and growing and I find it an interesting story over time. Unfortunately when proving out a theory takes a minimum of about 20 years from thousands of programmers it's a slow process.
(Also, while my comments above are certainly in some sense criticisms of the languages, I actually don't intend them as criticisms of the people involved. It is still an amazing achievement to move the state of the art ahead at all in such a harsh environment; I'm not angry that they didn't in one fell swoop fix all problems forever, even for decades not yet here.)
Maybe under the influence of Self and Smalltalk, which were doing interesting things with object behaviour composition using delegation and slots and all sorts of late-bound magic.
It definitely let people experiment. In JavaScript especially a thousand (inelegant) flowers bloomed and then some practices were codified into later revisions of the language and the door shut on that kind of experimentation.
I'm a big fan of static type systems generally. But I do think dynamic scripting languages have their place. In particular as prototyping/scripting languages embedded in larger more robust runtimes. e.g. the original goal of JavaScript (which has now become a full blown application development language).
AutoCAD had/has its lisp dialect. Emacs its own (ok it's more than just embedded scripting in that case). Many FPGA and HW eng tools use Tcl. Various games have Lua etc etc. This is a useful pattern potentially.
My thought isn't actually static/dynamic, but rather the amount of dynamicness. I suspect we could get 99%+ of the benefits of static languages at a fraction of the runtime cost if someone redid a dynamic language from scratch today to be dynamic only in selected ways. You pay a lot of runtime performance in Python to be able to do things like at any time edit a method three levels up the inheritance hierarchy, but you almost never actually do that sort of thing.
One idea I cite often is to have a declaration phase versus a runtime phase, because the vast, vast bulk of "dynamicness" is achieved at startup. A JIT could be really aggressive about a lot of optimizations if the language itself guaranteed that after a program (or a module, or a function, or whatever makes sense in the end) declares itself "done being dynamic" that there will be no more changes.
In fact I think there's a niche for a high-performance "mostly" dynamic language with threading built in from the beginning in the next 5-10 years. Static languages are getting most of the attention right now, and there's reasons for that, but I think there's a niche here that is not being well explored.
Personally I'm having a hard time using dynamically-typed languages right now because the amount of performance I'm throwing away almost makes me nauseous. That's a combination of the problem with being too dynamic, as I said, and multi-decade-old implementations not being able to be multithreaded very easily. I think a language that solved those two things could be very interesting.
Honestly I'm surprised after all these years that there hasn't been any success getting serious hardware support for the kinds of dynamic dispatch tables used in late bound languages. Like hardware accelerated string hash tables, etc.
I do like that the end of a block repeats the name, to ensure matching.
[1] https://www.cs.oswego.edu/~odendahl/coursework/csc443/notes/...
UNIX itself has turned out to be one, almost (BSDs and MacOSX excepted). SerenityOS might not!
Unix’s success story was about the interfaces, the APIs, not the original implementation of them - even though BSDs (and through them macOS) are direct descendants of the original implementation, I doubt much Bell Labs code actually survives. But the Unix API will likely outlive us all.
Had it been on sale with prices similar to VAX/VMS and others, it would been an history footnote most likely.
The XNU kernel is largely the same across its different variants (macOS/iOS/tvOS/watchOS/bridgeOS). The XNU kernel contains a massive chunk of BSD code (originally 4.3BSD, later updated with enhancements from FreeBSD), and most of that code will be there in all variants. The big area in which macOS has much more BSD code than iOS would be user space, since iOS is missing Unix command line tools present in macOS. (Although, you can install them if you jailbreak it, and I assume Apple's internal builds for their own developers would include many of them.)
He was also involved in the implementation of the Euclid programming language used for Tunis. It's remarkable that Euclid was originally designed by Butler Lampson at Xerox PARC, where also Smalltalk, Mesa and Cedar were invented.
Moreover, it was the first programming language where the implicit value of a pointer was the address contained by it and an explicit operator was used to access the pointed object (in the previous language with pointers, CPL, they behaved like the references of C++, i.e. their implicit value was the pointed object).
Unlike in C, where due to a design error the "*" indirection operator is a prefix operator, in Euler the indirection operator (which was a middle dot) was rightly a postfix operator (this was later inherited by Pascal).
Of course, Euler also had the "address of" operator ("@" in Euler, as a prefix operator), which is needed to assign values to pointers.
With ESPOL/NEWP probably being the first one with unsafe code blocks.
Not in the Algol family: Haskell
In the Algol (indeed Euclid) family: Turing
As yet vaporware(?): Noether
[0] generally, anyway: AWK is infamous; and I have some suspicions about CPL and MCPL ... once may be coincidence, but twice? Also, what about Popplestone's POP-n languages? ... and the "Wolfram Language" should be no surprise to anyone who's read the eponym's book.
Alice, Babbage, Curry, Dylan, Eiffel, FAUST, Gödel, Hume, Idris, Joule, Karel, Lua, Mercury, Nemmerle, Orwell, Python, Sather, Turing, WATFOR, Yorick, and Zeno to my understanding all named after people, groups of people, companies, gods, etc.
Then there are others besides Wolfram Language named after one or more contributors, like awk.
There are animals, plants, and gemstones - Zebra, Ant, Perl, the older Pearl, Ruby, Crystal, Elm, Oak, Maple (to represent Canadians, so kind of a two-fer), Emerald, Cobra, Mouse...
I don't know that anything is peculiar to the Modula family here.
Note the language itself is highly influenced by Modula-3 and ABC. ABC was a form of Basic not to many people remember these days that among its features had significant leading whitespace for statement grouping. So you can't blame/credit Guido entirely for that one.