51–60 of 326 posts
Where does TLA+ and PlusCal fit in? They do not match any of the listed families, do they?
Probably because they aren't programming languages in the sense you won't produce a program = executable with it, but rather a proof.
Looking at some TLA+ examples, I’d say, squinting a bit… somewhere around Prolog ? I’d love to hear someone chip in !
Earlier quoted context omitted.
Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, or let alone Self. ST was the first dynamically typed OO language (scripting language actually) though.
Ii is, because it inspired both the Smalltalk branch and the more mainstream OO languages, and hence it makes sense to consider it as a possible ur-language in that sense. Smalltalk is a branch, but it's an important enough branch introducing important enough new concepts that unlike with Self I wouldn't have an issue with people considering Smalltalk it's own ur-language, and because I agree with you that Simula at…
What do you have in mind, apart from duck typing?
> considering Smalltalk it's own ur-language, and because I agree with you that Simula at least on the surface will seem more familiar to people familiar with ALGOL-derived
For ST we have to differentiate the 72 and 74 from the 76 and later versions. Starting from 76 it has inheritance, compiled methods and virtual method dispatch quite similar to (though less efficient than) Simula 67.
Agree on the families, but I would pick a different representative for many of the categories. Algol -> C. Mostly because you can actually do things with C, and yet it remains a fairly small language that's a relatively pure exemplar of the Algol tradition. Lisp -> Scheme. Also because it's a tiny language that tries to push the fundamentals of the Lisp family (code-as-data, recursion, functional programming, macros)…
Earlier quoted context omitted.
I'm a bit confused about this quibble when the article text is about "Self and Smalltalk", not just Self? If anything the quibble should be "why is the section called Self when it's about the _two_ ur languages Self (the ur language for prototype based OO) and Smalltalk (the ur language for class based OO)"?
The title is "Self (object oriented programming)" and it ends with "Self disposed of the notion of class and worked solely with objects. As this is a purer form, I have chosen Self as the type specimen for this ur-language", so while it gives Smalltalk the space it deserves, it then turns around at points out Self as the ur-language for OO.
Where does TLA+ and PlusCal fit in? They do not match any of the listed families, do they?
TLA+ is similar to Prolog, extended with a next-state operator and the temporal operators (again, to serve its niche purpose).
(Though the main TLA+ implementation, TLC, doesn't implement logic variables as richly as Prolog does, so coding style within a relation tends to be almost a bit more imperative. They exist in the language though, via the unbounded ∃ operator.)
(I categorized the temporal declarative language TLA+ into the Prolog family in another comment -- a main distinction here is, though one can express reactive relationships in TLA+, the intent of the language and design of the TLC model checker is that such relationships are only usable for verification code, whereas implementation code must be written as state-succession pairs. A true reactive language permits and encourages both styles of coding for implementation code -- e.g. Verilog's = and [1] https://en.wikipedia.org/wiki/Synchronous_programming_langua...
An 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…
My big quibble with this is that the OO category is way too narrow. The way it is worded it excludes almost all languages we'd currently consider OO, and is so strict it largely makes the category pointless. Loosen it to exclude the "You do conditionals..." bit, and focus on the message passing, and e.g. Ruby and other languages that are message passing focused to the point of it tending to dominate semantics over it…
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.
My big quibble with this is that the OO category is way too narrow. The way it is worded it excludes almost all languages we'd currently consider OO, and is so strict it largely makes the category pointless. Loosen it to exclude the "You do conditionals..." bit, and focus on the message passing, and e.g. Ruby and other languages that are message passing focused to the point of it tending to dominate semantics over it…
I always thought that the "message passing" style of OO (which I always hated as a term, because it implies asynchronicity, but I digress) is firmly something else than the "classes and interfaces" style of OO, and that it's an unfortunate accident of history that we give them the same name.
This is ironically exacerbated when what is often presented as the important bit of Smalltalk are examples like the one in the article of allowing definition of control structures (you can do that in Ruby too, e.g. a partial impl: "def true.ifTrue = yield" - now you can do "(1 But while that's neat, that doesn't even require dynamic dispatch, just the combination of being able to invoke methods/dispatch messages to true and false, combined with convenient syntax and support for closures. You could add that to a language and still not have a Smalltalk descendant in any meaningful way.
What matters much more is that objects at least may take control over the target of a message dispatch even if they often don't, whereas method invocations in "those other" OO languages is mainly controlled by the class definition, and that is often glossed over as an advanced subject or "scary magic". For example how Ruby ORMs tend to use introspection to let you dynamically treat columns on database tables as methods based on the actual current schema of the database - in other words the ability to do not just dynamic dispatch but late binding.
IMO the eighth ur-language is Erlang (with cousin Elixir), which brings the ultra-scaling actor model, an abstract operating system designed for high reliability and low latency, and a bunch of nice rare features like builtin binary structuring/destructuring and pattern matching. While it had its origins in prolog, it's now sufficiently far away from prolog's inner machinery that it only has syntactical similarity. L…
> A Smalltalk object can do exactly three things:
> 1. Hold state (references to other objects).
> 2. Receive a message from itself or another object.
> 3. In the course of processing a message, send messages to itself or another object.
Replace "Smalltalk object" here with "Erlang process" and the description holds.
> Unlike most other languages, Smalltalk objects can be modified while the system is running. Live coding and applying fixes ‘on-the-fly’ is a dominant programming methodology for Smalltalk and is one of the main reasons for its efficiency.
Erlang's famed robustness similarly owes much to its ability to update code in a running program.
[1] https://en.wikipedia.org/wiki/Smalltalk#Object-oriented_prog...