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

161–170 of 326 posts

Re: The seven programming ur-languages (2021)

#161

Post by colonwqbang »

jgilias wrote: post #144
codeflo wrote: post #35

Earlier quoted context omitted.

I'm not sure I fully agree with that characterization. Many people would intuitively classify assignment as a statement, yet it's an expression in C, which is fully in the Algol tradition. And Rust is certainly a descendant of C, but blurs the lines a lot further with loops being expressions.

Rust is certainly a descendant of ML. It just adopted curly braces to make it more palatable to C-ish people. https://doc.rust-lang.org/reference/influences.html

Rust is a strict, GC-less Haskell but with a simpler type system and a more complicated syntax :)

Re: The seven programming ur-languages (2021)

#162

Post by jasonwatkinspdx »

turndown wrote: post #148
pulvinar wrote: post #112

Earlier quoted context omitted.

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.

What do you mean by threaded here?

https://en.wikipedia.org/wiki/Threaded_code

It's a way of structuring an interpreter. In forth a word is just a pointer to its definition, which in turn is just a list of pointers to other words, potentially user defined or built in primitives. Execution threads through these pointers, much like making subroutine calls with arguments being passed implicitly on the stack.

It's much more compact and lower overhead than a classic interpreter walking a full Abstract Syntax Tree structure. These days most languages are going to a full native code JIT however.

Re: The seven programming ur-languages (2021)

#163

Post by NoToP »

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 accidentally general purpose. Recursive queries, a feature present in all implementations since the 90s, put it just over the line of turing completeness.

Re: The seven programming ur-languages (2021)

#164

Post by davidw »

Animats wrote: post #158
davidw wrote: post #109

Earlier quoted context omitted.

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.

I suspect that idea is now dead. Anything new that accepts something that looks like natural language now needs to be at least as smart as ChatGPT. Stuff that sort of looks like a natural language but is really a formal language now comes across badly. There have been very few non-English programming languages. There was a French version of COBOL once. I'm surprised that something hasn't come out of China. There's a…

Interesting point about AI... that really could be a game changer, although to me it doesn't feel like it's as precise as we often ask code to be. Yet.

Re: The seven programming ur-languages (2021)

#165

Post by colanderman »

hwayne wrote: post #139
colanderman wrote: post #129

Earlier quoted context omitted.

Respectfully (you having literally wrote the book!) I disagree that there's a strong difference between specification and programming languages -- and specifically I feel that the "gap" between verification and implementation can be filled by recognizing this. To take TLA+ as an example -- I've certainly written (short!) programs in both TLA+ and PlusCal -- both imperative (typically an implementation of something th…

You raise good points! Ultimately the technical distinction between a specification and programming language comes down to the existence or not of a compiler. Imagine if Python came out in 1960, but without anybody building a Python interpreter. People would consider it a spec language. (Also, lots of spec languages are weaker than programming languages, to make verifying them easier. IIRC mcrl2, FDR, and Promela all…

Agreed! Phylogeny is messy. And thinking a bit more I realize I'm wading deep into "cereal-is-soup" territory, which is a sure recipe for unhappy diners.

Re: The seven programming ur-languages (2021)

#166

Post by tokai »

nerpderp82 wrote: post #108
joatmon-snoo wrote: post #99

Earlier quoted context omitted.

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…

Looking up words you don't know =/= Reverse engineering

Re: The seven programming ur-languages (2021)

#167

Post by cratermoon »

vidarh wrote: post #24
cratermoon wrote: post #19

Earlier quoted context omitted.

Yeah, I'd have to go with Simula/Simula 67 as the OO ur-language.

I'm ambivalent about that. As a technicality and inspiration it makes sense, but having learnt Simula (I studied in Oslo; it was the introductory language for many years) it does not give you the same focus on objects as Smalltalk does. But if you want to put another language than Smalltalk as the OO ur language, I'd certainly pick Simula over Self.

My knowledge of Simula is limited to reading about it and looking at small code samples, so I'm learning. But it's probably telling that I've learned more about Simula and seen Simula code but I've only ever heard about Self as a kind of footnote.

Re: The seven programming ur-languages (2021)

#168

Post by cratermoon »

vidarh wrote: post #45
Rochus wrote: post #30

Earlier quoted context omitted.

Simula 67 is much closer to the mainstream OO concepts we see in C++, Java, C# and Python than Smalltalk, or let alone Self. ST was the first dynamically typed OO language (scripting language actually) though.

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…

> prototypes instead of classes

Maybe the author picked that one as being in the lineage of JavaScript?

Re: The seven programming ur-languages (2021)

#170

Post by tel »

sebstefan wrote: post #27

Which category does Coq go in? https://github.com/coq/coq With code example: https://github.com/coq-community/coq-100-theorems/blob/maste...

It's definitely ML-relevant, but I'd argue that it's in its own league, and is maybe a suitable ur-language for that league.
Post reply on HN