So why is it called "ur"?
Because most other languages descended from these early languages.
The seven programming ur-languages (2021)
131–140 of 326 posts
Re: The seven programming ur-languages (2021)
#132So why is it called "ur"?
That's the essence of the conversation here, isn't it?
Re: The seven programming ur-languages (2021)
#133I take issue with calling stack languages the inverse of Lisp. This isn't really the case since functions in stack languages are fixed arity, while Lisp functions are not. The inverse of RPN would be the fixed-arity prefix notation used by the REBOL family of languages.
Re: The seven programming ur-languages (2021)
#134Objective C is a good example of a Smalltalk derived language that was in heavy use for a while. Even though it's technically a superset of C, in actual use it's more like a message passing language.
It's really Smalltalk and C pasted together with hardly any mixing, like JSX=JS+HTML. I can't see how you could put it in either column, it's absolutely in both.
Re: The seven programming ur-languages (2021)
#135Earlier quoted context omitted.
SQL is on the same group as Prolog. In fact, it is a simpler and purer implementation of a constraint-solving language, so it is probably a better option for learning the group than Prolog. For the signal transformation ones, there are also the hardware definition languages on the same category as LabView and animation languages.
SQL has no recursion. I would argue that's a pretty fundamental aspect of Prolog, so I don't think SQL is a representative replacement.
Oh, it's certainly not a "type specimen". It does actually have recursion and matching-like behavior, but those are convoluted and not really used, so it is not very suitable for general programming.
But lacking those general features makes it an even purer "learning example" of the group.
Re: The seven programming ur-languages (2021)
#136Earlier quoted context omitted.
> Listing Self rather than Smalltalk as the basis of OO languages is also a bit odd. That was my first reaction too. I also agree that Simula deserves a mention here. AFAICT more languages derived from that model than from Smalltalk or Self directly, and I'm pretty sure the authors of later languages such as C++ have acknowledged as much.
The author's notion of OO is intentionally narrow. I don't know about Simula, but C++ is still reasonably close to Algol, compared to what Smalltalk and Self bring to the table (the author also mentions programming environments vs. text files). If you accept that narrow definition at least for the scope of the article, it makes sense.
Simula itself was almost a superset of Algol-60. It's pretty much Algol-60 cleaned up a little bit and with a Java-like object model bolted on top. C++ is a direct descendant of that, sometimes even syntactically - e.g. the keywords "class", "new", and "virtual" all come from Simula where they had largely the same meaning. It's close enough to our mainstream OO languages today that Simula code can be easily understood, at least so long as it doesn't use the async features:
Re: The seven programming ur-languages (2021)
#137I think this taxonomy is interesting, but I have some quibbles on the characterization of the languages I use the most. If I were to put Ruby into one of these categories, I would place it first under Self (the object-oriented languages). Ruby is the most object-oriented language that I've ever used in that everything is an object that you send signals to. Even classes in Ruby are objects (they are instances of the `…
I agree with your characterization of Ruby as a Self/Smalltalk category language. (Or, a language with an ALGOL-style syntax and a Smalltalk-style OO system.) > After the "Self" category, Ruby would fit better under the "Lisp" family than the "ALGOL" family because of Ruby's deep metaprogrammability. I don't agree with this: Lisp's metaprogramming capabilities come from its macro system, while Ruby's metaprogramming…
> I don't agree with this: Lisp's metaprogramming capabilities come from its macro system, while Ruby's metaprogramming capabilities are due to metaclasses (which is exactly why it fits in the Smalltalk category).
Though, see the Common Lisp Object System Meta Object Protocol (CLOS MOP). There were a bunch of meta-object systems for Lisp, with the CLOS MOP as the most prominent example.
Re: The seven programming ur-languages (2021)
#138Interesting to see Erlang mentioned in the Self category instead of the Prolog category, but it makes sense given how much it borrows from both.
Re: The seven programming ur-languages (2021)
#139Earlier quoted context omitted.
TLA+ and PlusCal are specification languages, not programming languages. Spec languages have their own ur-languages: TLA+ is from the LTL dynasty, Alloy and Event-B are from Z, PRISM is CSP I think?
Respectfully (you having literally wrote the book!) I disagree that there's a strong difference between specification and programming languages -- and specifically I feel that the "gap" between verification and implementation can be filled by recognizing this. To take TLA+ as an example -- I've certainly written (short!) programs in both TLA+ and PlusCal -- both imperative (typically an implementation of something th…
You raise good points! Ultimately the technical distinction between a specification and programming language comes down to the existence or not of a compiler. Imagine if Python came out in 1960, but without anybody building a Python interpreter. People would consider it a spec language.
(Also, lots of spec languages are weaker than programming languages, to make verifying them easier. IIRC mcrl2, FDR, and Promela all fall under this category.)
I still think there are practical differences, though, between a language designed for the purposes of specification and one designed for implementing programs. TLA+ has temporal predicates and cross-state nondeterminism because it makes modeling at a high-level easier, even though it makes programmatic implementation harder. That leads to different design decisions through the language.
More importantly to the OP, thinking of them as fundamentally different is useful because they draw on different inspirations. It could be that PLs and SLs converge later, but their origins and lineages are still different. And that's interesting and worth studying.
I don't think talking about ur-languages is as useful as talking about archetypes: "ur-" to me implies "the original", and that's a hard thing to do. TFA has some ur-s like self that aren't the original, but still are useful as archetypes. Off the top of my head, the archetypes of formal speciifcation would be
* Temporal Logic (LTL, CTL, TLA)
* Relational algebra (Z, B, Alloy)
* Guarded Command Language (Promela, SPIN)
* Process Calculi (CSP, FDR)
* Labelled Transition Systems (Petri Nets, mclr2)
* Just drawing a diagram and figuring out the semantics later (UML)
* Abstraction over an existing programming language
This is all real messy, and I see lots of overlapping concepts and unclear cases. Are state machines their own thing, part of LTS, or an implementation detail of the specification approach? Should we be distinguishing between the mathematical formalisms and the languages themselves? What about the vaster world of specifying code and not designs? etc etc etc
Re: The seven programming ur-languages (2021)
#140An article like this is hard to write. This is a good one. I have a few quibbles, but they are just quibbles. IMHO* a distinguishing feature of Algol like languages (aka "procedural" languages) is the distinction between expressions and statements. Though personally I've never seen the appeal, that distinction seems to be popular for some reason. * this isn't even a quibble -- the article is fine without it. Just som…
If you count the quibbles how many quibbles would there be?
To use si units, a small handful of quibbles.