Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The seven programming ur-languages (2021)

madhadron.com

Post reply on HN
Print view View original

91–100 of 326 posts

Re: The seven programming ur-languages (2021)

#91

Post by dfox »

vidarh wrote: post #59
codeflo wrote: post #42

Earlier quoted context omitted.

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.

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 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).

Re: The seven programming ur-languages (2021)

#92

Post by OkayPhysicist »

felixgallo wrote: post #7

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…

That got briefly mentioned in the Object-Oriented section. It's worth noticing that the article specifically excluded Java and C++ from that section, putting them in the Algol heading instead. Smalltalk and Erlang share enough ideologically that it seems reasonable to me.

Re: The seven programming ur-languages (2021)

#93

Post by paulddraper »

I think there are additional examples, where the syntax isn't necessarily wildly different, but the paradigm is

* Shader code: is ostensibly C, but fundamentally different runtime characteristics.

* Dataflow (or Signals/Excel): Topological graph of computation.

* HCL (or Cloudformation/CDK/etc): Connecting execution via a different runtime.

* React Hooks

IDK it just seems like there is a lot.

Re: The seven programming ur-languages (2021)

#94

Post by OkayPhysicist »

vidarh wrote: post #17

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…

From the perspective of "Here is a list of language families from which you probably should learn at least one of each", the message-passing OO languages are completely divorced from the class-based OO languages. Tossing the latter in with the ALGOL languages is probably fine, as long as the actual language-to-learn recommendation is one of them.

Re: The seven programming ur-languages (2021)

#95

Post by vidarh »

TheRealPomax wrote: post #84
vidarh wrote: post #62

Earlier quoted context omitted.

As type specimen self makes less sense to me. In that sense it might make sense as the ur-language of it's own type (prototype-based OO languages), but it's too specific to be a specimen of the overall OO category. I don't agree it made the concepts more OO in any sense. Self's changes feel far less significant than what Smalltalk brought to the table. That an object inherits it's structure and functionality from som…

Smalltalk says "objects are instances of some class of thing", whereas Self went "no, objects are just objects, and what class of thing they are is mutable". Since we can get from Self's model to Smalltalk's model by adding restrictions on what you can do to both objects and prototypes, Self is quite objectively a better type specimen. I wouldn't call it an "ur language", that was a silly choice in term, but as basis…

I suspect we'll have to agree to disagree on this, as I don't agree with you at all that it is "objectively a better type specimen". I'd argue it's not even a good type specimen, in that it shares fewer characteristics with the majority of OO languages than Smalltalk does.

The defining aspect of OO languages if we go by Kay is message passing and late binding. How that is achieved is secondary to the classification. Both Self and Smalltalk provides that, but Smalltalks way of providing that is more typical of the class of languages as a whole.

To me, either Kay is authoritative, or we go the other direction and include more of the ALGOL-derived languages. In neither case is Self a good representative of what OO languages are like, and that to me makes it a poor type specimen.

Re: The seven programming ur-languages (2021)

#97

Post by nerpderp82 »

todd8 wrote: post #44

The comments here are interesting, lots of possibilities for other ur-languages. My suggestion is macro based languages. Macro based programming predates all programming languages other than ASM[1]. The simple macro systems, like early assemblers provided, aren't ur-languages, but once macros can expand other macros and generate definitions of new macros, the macro systems can become general purpose programming syste…

The last two books are available at your favorite site.

Re: The seven programming ur-languages (2021)

#98

Post by fanf2 »

neallindsay wrote: post #82
JW_00000 wrote: post #64

Earlier quoted context omitted.

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 think of "functional" meaning first-class and higher-order functions, but lots of people use that term to mean pattern matching and type systems. It definitely seems like the author of this article meant the "ML" category to mean the latter. When they added the `class` keyword in JavaScript it didn't change the capabilities of the language—it's still prototypal under the hood, but I guess the syntax matters. I cert…

ALGOL 68 has first-class and higher-order functions. Arguably ALGOL 60’s call-by-name allows you to do some higher-order things, even though its functions are not first class.

Re: The seven programming ur-languages (2021)

#99

Post by joatmon-snoo »

nerpderp82 wrote: post #96

I 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-...

Re: The seven programming ur-languages (2021)

#100

Post by Mesopropithecus »

notacoward wrote: post #58
vidarh wrote: post #17

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…

> 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.

Post reply on HN