The claim that Fortran and assembly languages "trace to" Algol is... odd. Fortran I was released in 1957; the first fragmentary spec for Algol wasn't released until 1958 (with Fortran project leader John Backus as one of the primary contributors). And there were also recognizable assemblers, in the modern sense, at the time (although terms like that weren't always used with their modern meanings in the 1950s, which lays up all sorts of traps for the unwary).
The seven programming ur-languages (2021)
111–120 of 326 posts
Re: The seven programming ur-languages (2021)
#112The 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…
Macro/concatenative languages should replace the Forth line. The author is off-base in thinking RPN or stacks are important to Forth rather than concatenativity. RPN is just an easy way to make interpretation simple, an implementation detail, not a functional requirement. It would be like defining APL as being evaluated right-to-left.
The stack is important to Forth, but equally so is its threaded-subroutine-call nature, which isn't present in other early languages that I know of. That puts Forth halfway between assembly and higher-level (and easier to read) languages. I never saw it as a macro language.
At least that's the viewpoint I'm familiar with from back when we heavily used it.
Re: The seven programming ur-languages (2021)
#113Earlier quoted context omitted.
> 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 ca…
> Actually even ST-72 made synchronous calls
I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context.
> 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 ).
Sure, you can implement method dispatch the same way. I've written a (partial; unfinished; very buggy) Ruby compiler that allows dynamic method redefinition with even basic C++-style vtables. The point is not the dispatch method but the ability to override them at will.
> 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
That late binding is an important part of it.
But you don't even need to deviate from static offsets to enable that late binding (you do need to do so if you want the ability to do dynamic interface-based inheritance, but even then you can use a vtable-like approach - see e.g. Protocol Extension: A Technique for Structuring Large Extensible Software-Systems, M. Franz, 1995 - which adds dynamic inheritance at runtime to Oberon) as long as the dictionaries/vtables/whatever you look them up in are mutable.
Re: The seven programming ur-languages (2021)
#114Earlier quoted context omitted.
> 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 ca…
> Actually even ST-72 made synchronous calls I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context. > 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…
Which closes the loop to my point, that Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, and there is no reason to elevate Self (nor ST) as the "ur OO language".
Re: The seven programming ur-languages (2021)
#115Agree 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)…
Yeah, K doesn't even have proper n-dimensional arrays. Funny enough, the author writes "If you do a lot of numerical work, learn J earlier." which may be a typo, but still…
> You can learn all the important parts of array-oriented programming with J and use actual words to do it.
J doesn't use actual words. It uses symbols just like APL. In fact, APL uses proper words or abbreviations for utilities things that are not part of the core language, whereas J just uses numeric codes combined with more glyphs. However, J is ASCII-only (and uses bi- and even tri-glyphs) where APL uses pleasant and mnemonic Unicode single glyphs, so you don't need to parse which adjacent ASCII symbols form a "word".
Re: The seven programming ur-languages (2021)
#116Earlier 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.
It's exceptionally narrow, in that it rules out the vast majority of languages that even purists would agree are OO.
E.g. in Ruby you can not take the value of anything and get anything but an object (e.g. integers are objects, true is an object, nil is an object), but Ruby is not an OO language by the article's definition because it fails the part about conditionals.
Even though you can do this in Ruby (probably buggy, just threw it together) - it's just not idiomatic and the language has syntactic sugar for "less OO" forms:
def true.ifTrue; yield; true; end
def true.ifFalse; true; end
def false.ifFalse; yield; true; end
def false.ifTrue; false; end
(1 5).ifTrue { puts "TRUE!" }.ifFalse { puts "FALSE!" }
Re: The seven programming ur-languages (2021)
#117Earlier quoted context omitted.
> Actually even ST-72 made synchronous calls I've not suggested it is anything but synchronous, so I don't know why you're bringing that up. It's not what we're talking about when we talk about "message passing" in this context. > 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…
Which closes the loop to my point, that Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, and there is no reason to elevate Self (nor ST) as the "ur OO language".
Which I agreed with you is a reasonable stance. To quote myself:
> 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.
I then went on to argue simply that because Smalltalk is at the root of a significant branch, I wouldn't have an issue with considering that an ur-language if one considers that branch important enough and/or consider message passing and late binding to be essential for a language to be object oriented, as opposed to having some object oriented features.
But I went on to again agree with you:
> I agree with you that Simula at least on the surface will seem more familiar to people familiar with ALGOL-derived languages with OO mechanisms than to Smalltalk.
To sum it up: I've argued that a reasonable case can be made either for Simula or Smalltalk depending on how you define OO, but that no well established definition of OO would make Self a reasonable candidate.
Re: The seven programming ur-languages (2021)
#118Earlier quoted context omitted.
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.…
He was absolutely authoritative, but: back in the early days of OOP. Both the meaning and fundamental aspects of OOP have changed (quite a bit) since then, and what Kay called OOP might be the historical forefather to, but not current type specimen of, OOP.
So yeah, we'll have to disagree.
Re: The seven programming ur-languages (2021)
#119There’s a missing “minimal language” with a combination of features that doesn’t yet exist, but should: - value semantics with both implicitly-copyable and move-only values - unboxed generics with type classes/traits/protocols and associated types - as little syntax and sugar as possible for everything else
Maybe Austral?
Re: The seven programming ur-languages (2021)
#120Earlier 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.
Yes it does. It’s a fun problem to make a sudoku solver
https://technology.amis.nl/it/solving-a-sudoku-with-one-sql-...