Objective 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.
The seven programming ur-languages (2021)
101–110 of 326 posts
Re: The seven programming ur-languages (2021)
#102Agree 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)…
I'm not sure if it's common knowledge that "ur-" means "original".
In academic literature, "ur-" doesn't just mean original, as much as it means "essential essence of" or "fundamental". In contexts where you're talking about the first/original thing, or something that provided characteristics that would eventually become a trend, "proto-" would be more appropriate.
For a famous example, Umberto Eco's essay "The Ur-Fascist" isn't describing what the first or original fascist movement was, but instead exploring what makes Fascism Fascism. This usage seems to be pretty consistent across academia, who engage in the vast majority of cases of slapping foreign prefixes onto English words.
Re: The seven programming ur-languages (2021)
#103I feel like C++ needs to go into its own category, seemingly infinite features with only thinly veiled illusionary safety.
Not a fan of snarky comments generally, but this one made me laugh. And cry.
Re: The seven programming ur-languages (2021)
#104Earlier quoted context omitted.
I think part of the problem of trying to separate the two is that the most prominent implementations appear deceptively similar on the surface, even with unfamiliar syntax. E.g. put even Smalltalk in front of someone familiar with C++, and they'll quickly latch on to the similarities once a few of the basics are explained, to the point that explaining message passing as different from method invocation is tricky, not…
ST80 does not really do the object controlled message dispatch that was there in earlier Smalltalks. Well, you can override Behavior>>#doesNotUnderstand: and do all sorts of cool tricks with that, but it is mostly meant as error-recovery path (which is partly apparent from the name), not as something that should be regularly used. One weird aspect of Smalltalk that more or less directly comes from the control structu…
> ST80 does not really do the object controlled message dispatch that was there in earlier Smalltalks. Well, you can override Behavior>>#doesNotUnderstand: and do all sorts of cool tricks with that, but it is mostly meant as error-recovery path (which is partly apparent from the name), not as something that should be regularly used.
The same way you can override "method_missing" in Ruby but you apply it as rarely as possible, but the dispatch is still dynamic and methods can be overridden and dynamically defined. That's the point. Not that you literally implement a dispatch directly on the object.
Put another way, the main distinction is that the precise method body invoked by sending a given message to an object may be impossible to statically determine.
> One weird aspect of Smalltalk that more or less directly comes from the control structures implemented as messages taking blocks is that on the language level there are two distinct function-like objects: methods and blocks (ie. lambdas) that behave differently and interact with each other (return statement is scoped to method and only valid during the dynamic extent of said method invocation).
Ruby sort-of inherits this too, but at any point where you take the value of a block, it becomes an object - it's purely an implementation artefact, and with lambda/proc providing both lexical and method-local scope for return.
Re: The seven programming ur-languages (2021)
#105Ruby is mostly a Self in this classification, right? Or maybe a Self/ALGOL hybrid. It does have iteration as a method (.each), but also has traditional if statements.
To some extent yes, it's certainly influenced by Smalltalk. I just wish the author hadn't focused that much on control flow in that paragraph.
Ruby afaik also supports live programming up to a point (REPL), but it's still not the same live-ness as in Self or Smalltalk.
Re: The seven programming ur-languages (2021)
#106Earlier quoted context omitted.
> introducing important enough new concepts 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 di…
> What do you have in mind, apart from duck typing? The focus on message passing and late binding combined. "Duck typing" is seriously diminishing it. You can write code that appears that way even in C++ with RTTI and inheriting from a shared root class and heavy use of virtual. But to achieve the equivalent of the combination of message passing and late binding in a language like C++ not built for it you typically e…
> message passing and late binding combined. "Duck typing" is seriously diminishing it
Actually even ST-72 made synchronous calls, but at least with a token stream interpreted by the receiving object (thus at least a bit of "message passing"). In ST-76 and later versions "message passing" is just nomenclature used by the ST folks for something that is just ordinary method dispatch and call (if you have doubts, you can analyze the innards of the ST-80 VM yourself e.g. with these tools: https://github.com/rochus-keller/Smalltalk ). The major difference is the dispatch based on signature hash (similar to e.g. Java interface method calls) instead of static offsets, which enables late binding (at the expense of performance); and since everything including ordinary integers derive from Object, all values and objects are subject to dynamic method dispatch; it's no coincidence that Smalltalk was the first language to be associated with duck typing. The unification of scalar values and references, dynamic typing, and likewise the minimal syntax where control structures are implemented by means of runtime constructs were already known from Lisp; also closures (i.e. ST blocks) were already known before they were added to ST.
Re: The seven programming ur-languages (2021)
#107Pretty excellent summary, this is roughly the taxonomy I have in my head. I would maybe add SQL as an ur-language as well. It's not quite general purpose like most of these, but it should have a place in this list, I think. It has some kinship with Prolog and the declarative style, but it's really it's own thing. You could also maybe argue for something like LabView. Many programmers look down on purely graphical pro…
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.
Re: The seven programming ur-languages (2021)
#108I despise this writing style. What is the point the author is trying to make? Define what a ur-language is up front, don't be so damn coy. This isn't much more than a list of interesting languages for some definition of interesting.
It's talking about different families of programming languages, much like how we classify the different languages that people today speak[1]. I definitely got thrown off by the choice of terminology, but it makes sense once you go through the list. [1] https://www.theguardian.com/education/gallery/2015/jan/23/a-...
The reader shouldn't have to reverse engineer a document!
https://en.wiktionary.org/wiki/ur-
Jesus! I thought these navel gazing low effort language posts went out of favor in 2012.
I know all of these languages and Forth isn't foundational for anything we currently use, maybe the JVM because it has a stack if you really try and torture the definition. It is just a collection of languages so the author can look smart.
If they wanted to provide insight, they would demarcate how the semantics of computation are different from each of these languages. It doesn't even mention the power of Forth in being able to extend the language and runtime from within the language itself.
I'll see myself out.
Re: The seven programming ur-languages (2021)
#109Pretty excellent summary, this is roughly the taxonomy I have in my head. I would maybe add SQL as an ur-language as well. It's not quite general purpose like most of these, but it should have a place in this list, I think. It has some kinship with Prolog and the declarative style, but it's really it's own thing. You could also maybe argue for something like LabView. Many programmers look down on purely graphical pro…
SQL might be in its own category or not, but it shares a trait that languages in other categories ended up with: "I know, we'll make it kind of like writing English so that people who aren't experts can program!".
This is one of those things that seems to keep coming back - recently in the Ruby world with Cucumber.
Re: The seven programming ur-languages (2021)
#110IMO 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…
Erlang is a nice and unique language, but I feel at its core it falls into the object-oriented/message-passing paradigm, very much in the vein of Smalltalk. Consider these paragraphs from Smalltalk's Wikipedia entry [1]: > 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…
Joe Armstrong talked about that in the past, and I can sort of see it if I squint, but at the end of the day, there are a lot of things in Erlang that are not processes, like most of your basic data types, so I'd just say Erlang is good at borrowing, like a lot of practical real world languages are, and in doing so, came up with a niche where it's pretty good. It takes things from the FP world, its syntax from Prolog, and definitely has message passing as an integral part of how you architect a system with it.