Live data from Hacker News

The seven programming ur-languages (2021)

madhadron.com

181–190 of 326 posts

Re: The seven programming ur-languages (2021)

#181

> Lisp is about a year younger than Fortran, which makes it the second oldest language still in use today I disagree with this line since Lisp is not really a "language", but a family of them. If we consider Clojure and original Lisp to be the same language, we should also consider that to be true of Algol and Rust.

FTA:

> I am aware of seven ur-languages in software today. I’ll name them for a type specimen, the way a species in paleontology is named for a particular fossil that defines it and then other fossils are compared to the type specimen to determine their identity

Re: The seven programming ur-languages (2021)

#182
post #175

Earlier quoted context omitted.

The only popular language I can think of that requires side effects to be declared is Haskell. Which doesn't have a distinction between statements and expressions. Are there any good examples of languages that have it, where it isn't "useless"?

python, javascript, pretty much any language that is popular. I believe everything in Haskell is an expression, even the do notation, no? But I think the argument being advanced is that the distinction between statements and expressions is fundamentally unnecessary. I don’t really know of any good argument in favour of them: I tend to think lisps have the perfect and simplest possible syntax.

Yes, that is indeed the point I was making. And yes, I’m a lisp programmer.

Re: The seven programming ur-languages (2021)

#183
post #109
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 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.

> recently in the Ruby world with Cucumber.

Way to age yourself old man.

Re: The seven programming ur-languages (2021)

#185

So why is it called "ur"?

Because most other languages descended from these early languages.

Actually never heard that expression before. Thought I might not be in the know of some very obvious jargon. Turns out it was just plain English.

Re: The seven programming ur-languages (2021)

#186

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

>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 `Class` class). Ruby was explicitly inspired by Smalltalk, one of the two exemplars cited by the post.

Not everything, there are still a few keywords that are not objects. For example `end.class` will raise a syntax error.

Re: The seven programming ur-languages (2021)

#187
post #151
post #59

Earlier quoted context omitted.

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…

this distinction is something i have been struggling with for some time. i am coming from pike which only uses method invocation terminology (in pike it's actually called "function call"), and never even hints at message passing, yet in pike objects can take control over the target of a function call and even dynamically create functions based on arguments given. when learning smalltalk i could not see the what was s…

The language is made a lot more confusing by the fact that most of the time you can improve performance of a conceptually message-passing implementation by implementing it as much as possible in terms of invocation, so it's totally reasonably why even very dynamic implementations would end up spoken of as method invocation.

E.g. my long-languishing partial Ruby compiler uses C++ style vtables because they're fast and the "only" challenge is that you need to propagate method re-definitions down a chain of descendant classes (and avoid overwriting overridden versions in the descendants). In practical terms, pseudo-code for a method dispatch is ob->class_ptr.vtable[method_slot](args...) and all of the dynamism happens with a combination of dynamically overwriting and propagating method pointers down the vtable chain (I was worried it'd lead to way too much memory spent on sparse vtables and having to fall back on a hash table for less-used method names, but in practice the number of classes is usually very constrained) and filling in thunks that forwards to method_missing for names that are seen in the system but not implemented by the current class.

Effectively you can consider the vtables as perfect pre-filled caches. To someone casually looking at them to get an idea of Ruby, it'll look like Ruby's object model is almost the same as C++'s.

So I agree with you that the key practical difference is static vs. dynamic dispatch and early vs. late binding. With those distinctions you don't really even need to make the compile vs. runtime distinction. That is, you can statically compile something that includes dynamic calls to modify the object model, like my prototype compiler.

Elsewhere I suggested one way of looking at it is that to distinguish the C++/Java etc. and Smalltalk model of OO, the key test is how common it is for there to be code where determining which method body will be invoked by a given call devolves to the halting problem if you don't have the precise inputs ahead of time (e.g. in Ruby, almost every ORM would cause this).

Re: The seven programming ur-languages (2021)

#188
post #51
post #34

Earlier quoted context omitted.

Probably because they aren't programming languages in the sense you won't produce a program = executable with it, but rather a proof.

And yet Agda, which is a proof language, was included (in the ML family). Looking at some TLA+ examples, I’d say, squinting a bit… somewhere around Prolog ? I’d love to hear someone chip in !

Eh, even though you prove things about your specs (possibly) there's still a difference between proof assistances and spec languages

Re: The seven programming ur-languages (2021)

#189

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

You just described your next hobby project?

Re: The seven programming ur-languages (2021)

#190

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…

They're more grouped by their main abstraction mode, not underlying hardware architecture.

In theory you can emulate anything on something that's Turing complete, can't you? It will just be harder or easier. May not be worth the trouble. But still possible.

Post reply on HN