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

81–90 of 326 posts

Re: The seven programming ur-languages (2021)

#81

Post by ucarion »

marcosdumay wrote: post #69
OskarS wrote: 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 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.

To your point, Berkeley's intro-level CS class, CS61A, used to use teach Prolog as an example of logic programming. They use SQL now instead.

I can't really attest to whether that's a better choice for learning logic programming, though. It's easier to "run programs" in Prolog. SQL wants to be a cog in a machine where Prolog is more freestanding.

Re: The seven programming ur-languages (2021)

#82

Post by neallindsay »

JW_00000 wrote: post #64
neallindsay wrote: post #38

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

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 certainly see people writing "classes" in JS a lot more now.

Re: The seven programming ur-languages (2021)

#83

Post by Nevermark »

> A reader pointed out to me that getting Forth in a deep way usually involves building Forths, since they’re small enough for a single person to build one from the ground up fairly quickly.

I would say the same about Lisp.

In fact, each list in Lisp is like its own little stack in Forth. Prepending an element to the front of a list is like pushing onto a stack. Separating the first element from the rest of a list is like popping from a stack.

Lists of lists & atoms are like stacks that can contain references to other stacks, as well as atoms.

Re: The seven programming ur-languages (2021)

#84

Post by TheRealPomax »

vidarh wrote: post #62
TheRealPomax wrote: post #54

Earlier quoted context omitted.

You seem to confuse "ur language" for meaning "the original that others came from", which makes sense if you're familiar with the term "ur", but is not how this article uses the term. They use it to mean type specimen (as noted in the article). As type specimen, Self makes a lot more sense: it took the OO concepts pioneered by Smalltalk and then made them even more OO .

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 for discussing OOP models, it's the most permissive, and you can get the other OOP models by adding various (sets of) restrictions.

(Much like how a regular grammar is a context free grammar with additional rules)

Re: The seven programming ur-languages (2021)

#85

Post by denotational »

eschneider wrote: post #66
colanderman wrote: post #56

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.

This is an overly simplistic take in my opinion.

From a PLT perspective they are programming languages just like any other, and one can analyse them using the same machinery (formal semantics, typically of the operational style) as any other programming language.

Just because they are not even close to an imperative paradigm doesn’t make them any less of a programming language. They are reasonably close to process-calculus/message-passing languages in the sense that you can treat a Verilog process as a receiver listening to channels that contain messages generated when nets/variables are driven.

I agree that a software developer who tries to write Verilog as if it were C will very quickly run into trouble, but that isn’t because it’s not a programming language; it’s because it’s a programming language with a similar syntax to C but with drastically different semantics.

Re: The seven programming ur-languages (2021)

#86

Post by lamontcg »

seanhunter wrote: post #36

Years of bitter personal experience have taught me that FORTRAN is the real ur-language in the sense that a suitably determined programmer can write FORTRAN code in just about any language. I have certainly had to debug this code all over the place.

Does this make Perl a FORTRAN?

Re: The seven programming ur-languages (2021)

#87

Post by fanf2 »

gumby wrote: post #5

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…

ALGOL 68 and Rust are expression-oriented languages.

Re: The seven programming ur-languages (2021)

#88

Post by KingLancelot »

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…

[dead]

Re: The seven programming ur-languages (2021)

#90

Post by nologic01 »

Ahh this is good. But what are ur-languages really? Can we tell when we have counted all of them? Is the collection determined more by the application domain (the problems we think are important to solve) or the architecture of Von Neumann type computing)? E.g. I don't know much about quantum computing but I suppose there is an ur-language associated with it.

Whenever I see a taxonomy I itch for some underlying logic that unifies them. If the explanatory scheme is successful then you might actually convert the taxonomy into a tree, where the root is some property that all of them ur-languages share etc.

Post reply on HN