Live data from Hacker News

The seven programming ur-languages (2021)

madhadron.com

71–80 of 326 posts

Re: The seven programming ur-languages (2021)

#71
post #52
post #45

Earlier quoted context omitted.

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…

> 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 end up having to build your own message dispatch machinery with no syntactic support to make it cleaner that will make your code look fundamentally un-idiomatic, and so doing so is tends to be limited to specific problems.

It's this combination that makes Smalltalk-derived languages feel different.

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

I'd argue when we say Smalltalk without qualifying it, most of us will be talking about Smalltalk-80.

Re: The seven programming ur-languages (2021)

#72

I think reactive/synchronous languages [1] deserve a category of their own. They share little/no overlap with any of the others. My background in electrical engineering biases me to Verilog, VHDL, and LabVIEW as exemplars, but there are many others. The distinguishing characteristic of the category is that programs are effectively declarative functions of time and can be composed as such, much like electronic circuit…

Verilog/VHDL isn't so much a programming language as a hardware definition language and woe to anyone who conflates the two. Verilog/VHDL is it's own class of thing and sits outside of software languages.

Without weighing in on exactly if it is or isn't a "language", I think VHDL/verilog absolutely have a place in the list and are a fantastic thing for (some, particularly lower-level interested) programmers to learn precisely because it's such a different way of thinking about programming and huge piles of heterogeneous behavior happening concurrently. It really cooked my head for the first week or two and I think I came out the other side better. (I hated writing VHDL with a passion. It was painful medicine for a software person used to algol-style languages. But I'm really glad I did.)

Re: The seven programming ur-languages (2021)

#73

I've never heard of ALGOL both predating and influencing FORTRAN. FORTRAN was announced as a product at the Western Joint Computer Conference in 1957 [1]. ALGOL was developed at a meeting in Zurich in 1958 [2]. [1] https://www.softwarepreservation.org/projects/FORTRAN/paper/... [2] https://en.wikipedia.org/wiki/ALGOL

ALGOL has certainly influenced the development of FORTRAN at least, with Fortran 90 and later fitting in pretty neatly amongst the various ALGOL-likes.

Re: The seven programming ur-languages (2021)

#74

There’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

The first point jumped out to me as contradictory: for immutable values copying is only an implementation detail. Apparently "value semantics" can also refer to mutable values with exclusive ownership, is that the idea here or something else?

> Apparently "value semantics" can also refer to mutable values with exclusive ownership, is that the idea here or something else?

Yes, that's what I meant here.

Re: The seven programming ur-languages (2021)

#76

I 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 `…

Lots of languages fit in the ALGOL + Self category - probably most of the popular languages today.

That's fine, this isn't actually a taxonomy, these ur-languages are the progenitors of concepts and techniques. Of course they can blend in decedents.

Re: The seven programming ur-languages (2021)

#77
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…

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.

Re: The seven programming ur-languages (2021)

#78
post #9

Pretty 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

And, not to put too fine a point on it, being extremely proficient will give you a massive competitive edge in the industry.

Re: The seven programming ur-languages (2021)

#80

I think reactive/synchronous languages [1] deserve a category of their own. They share little/no overlap with any of the others. My background in electrical engineering biases me to Verilog, VHDL, and LabVIEW as exemplars, but there are many others. The distinguishing characteristic of the category is that programs are effectively declarative functions of time and can be composed as such, much like electronic circuit…

My education was in EE but I switched over to programming ASAP. So my take on Verilog/VHDL is, like, super uninformed/perpetual honeymoon/starry-eyed. But it always seemed to me that these HDLs, since they fundamentally are pretty low-level and asynchronous, if translated to assembly somehow, ought to expose a ton of instruction level parallelism.
Post reply on HN