Live data from Hacker News

The seven programming ur-languages (2022)

madhadron.com

121–130 of 161 posts

Re: The seven programming ur-languages (2022)

#121

One correction I'd make to the article's taxonomy: Ruby is an object oriented language not an Algol. Its inspiration is Smalltalk, and much of the standard library naming comes from that route (eg collect rather than map). Ruby is object oriented from the ground up. Everything (and I do mean everything) is an object, and method call is conceived as passing messages to objects. While Ruby is most often compared to Pyt…

I think the choice to identify a specific ur-language as "Object oriented" throws people off since OO is just a style of programming in the same way that procedural is. I don't think it's useful to say that Python and C++ are both the same kind of language because they both have multiple inheritance, rather that's just an observable commonality, like noticing that both Delhi and Vegas are too hot. Yeah, but I don't t…

Object-oriented programming is less of a syntax and more of a philosophy. While Erlang’s syntax belongs to the ML family, its creator, Joe Armstrong, argued that Erlang aligns more closely with the original OOP philosophy defined by the inventor of Smalltalk than Java does: 'The essence of object-oriented programming is messaging, not classes and inheritance.'

Re: The seven programming ur-languages (2022)

#122
post #55

I wrote something similar here: https://fmjlang.co.uk/blog/GroundBreakingLanguages.html We agree on Algol, Lisp, Forth, APL, and Prolog. For ground-breaking functional language, I have SASL (St Andrews Static Language), which (just) predates ML, and for object oriented language, I have Smalltalk (which predates Self). I also include Fortran, COBOL, SNOBOL (string processing), and Prograph (visual dataflow), which wer…

I don’t understand why self is placed in the list instead of smalltalk. Smalltalk came first, and Alan Key was the one who invented the “OOP” name. Also ML is seen as a child of Lisp.

> I don’t understand why self is placed in the list instead of smalltalk.

The article explains that:

> Smalltalk inherited the notion of a value and its type from earlier languages, and implemented the idea of a class. All objects had a class that gave their type, and the class was used to construct objects of that type. Self disposed of the notion of class and worked solely with objects. As this is a purer form, I have chosen Self as the type specimen for this ur-language.

Re: The seven programming ur-languages (2022)

#123
post #113

Earlier quoted context omitted.

> Agda, Idris, etc. are functional languages extended with complex types I think they are not. No amount of type level extensions can turn a regular functional language like Haskell into something suitable for theorem proving. Adding dependent types to Haskell, for example, doesn't suffice. To build a theorem prover you need to take away some capability (namely, the ability to do general recursion - the base language…

> To build a theorem prover you need to take away some capability (namely, the ability to do general recursion - the base language must be total and can't be Turing complete), not add new capabilities. In Haskell everything can be "undefined" which means that you can prove everything (even things that are supposed to be false). Despite what the fanatical constructivists (as opposed to the ones who simply think it's p…

How does this disagree with "the base language must be total and can't be Turing complete"

Re: The seven programming ur-languages (2022)

#124
in the world there should only be one debate and one summary about programming languages, and everybody should read that as a starting point before they enter the fray.

for example, I would say what i was taught, that lisp is lists made out of cons cells, which contain references to either other lists/cons cells or to atoms. lisp doesn't "have" parentheses any more than lisp has the rest of the ASCII table, but parentheses were chosen as a convenient way to write list structure down in ascii form because parentheses nest in exactly the way lists do and lists are the important thing.

then there never needs to be another discussion of parentheses and how you feel about them except in a sub-discussion if anybody has any bright ideas about alternative ways to convert list structure to ascii on paper. you disliking parentheses does not mean you dislike lisp; it just means you don't understand lisp, like for instance you think lisp has something to do with ascii.

similar ideas apply to C, wherein the braces and semicolons do not matter, what matters is datatypes that correspond to von neumann architectures including especially pointers, and where binary representation is easily exposed (with a syntax that does not matter but for the record is &, |, ~, ^, >. if you hate those choices for operator syntax you could easily convert your own C to use parenthetical lists of CamelCase names of LeftAddRight or whatever floats your boat instead of a + sign), just keep in the front of your mind how data is represented internally and how it's mapped to the syntax you like, and whatever list structure you choose to order the lines of code)

Ur-ness is not interesting, just as the city of Ur was no doubt a lot less interesting than the city of Rome. Study Algol only to learn about call-by-name, then forget it.

I could go on, but, like the ripples from a gold coin thrown in the bay, the effect will soon dissipate as if I had never written anything at all.

Re: The seven programming ur-languages (2022)

#125

Earlier quoted context omitted.

This is just wrong, you're being too didactic. Idris specifically lets you implement nontotal functions in the same way that Rust lets you write memory-unsafe code. The idea is you isolate it to the part of the program with effects (including the main loop), which the compiler can't verify anyway, and leave the total formally verified stuff to the business logic. Anything that's marked as total is proven safe, so you…

I mentioned this later > You can separate terms that can be used in proofs (those must be total) from terms that can only be used in computations (those can be Turing complete), like in Lean What I meant is that the part of Idris that lets people prove theorems is the non-total part But, I think you are right. Haskell could go there by adding a keyword to mark total functions, rather than marking nontotal functions l…

Haskell has liquid haskell to do that.

Re: The seven programming ur-languages (2022)

#127
post #56

Earlier quoted context omitted.

Since Python introduced new style classes, it also became a pure OOP language, even though it might not look like it at "Hello World" level, all primitive types have become objects as well. I love to point this out to OOP haters, >>> type(42) >>> dir(42) ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floo…

I have found the definition of OOP to be fuzzy. For example, I don't see why having methods would make a data type object oriented. I associate OOP with factories, inheritance, using classes in places that might be functions otherwise, and similar abstractions. Perhaps this is the counterfactual: I program in Python regularly, but don't program in an OOP style; I use dataclasses and enums as the basis, in a way simil…

Rust can definitely do OOP, not only I could easily convert "Raytracing in one Weekend" from C++ into Rust, while keeping the same design, Microsoft has no issues adding a Rust projection for COM/WinRT, which are OOP ABIs.

However that is not the same as Python, which is 100% OOP, when using basic stuff like numbers, from Python language semantics those things are object, and there is the whole machinery in place even for basic stuff like addition.

And yes OOP is fuzzy from CS point of view there are multiple approaches and it doesn't get reduced to the way C++ and Java do it, just like FP and LP are fuzzy as well.

Some folks would swear if it isn't Haskell or Prolog, than it isn't FP or LP, when a CS book and programming language evolution will be more fuzzy.

Re: The seven programming ur-languages (2022)

#128
post #56

Earlier quoted context omitted.

Since Python introduced new style classes, it also became a pure OOP language, even though it might not look like it at "Hello World" level, all primitive types have become objects as well. I love to point this out to OOP haters, >>> type(42) >>> dir(42) ['__abs__', '__add__', '__and__', '__bool__', '__ceil__', '__class__', '__delattr__', '__dir__', '__divmod__', '__doc__', '__eq__', '__float__', '__floor__', '__floo…

If that's enough to make a language pure OOP, then Common Lisp is also a pure OOP languge: CL-USER> (class-of 42) #

Common Lisp Object System and The Art of Metaobject Protocol.

Yes.

Re: The seven programming ur-languages (2022)

#129
post #122
post #55

Earlier quoted context omitted.

I don’t understand why self is placed in the list instead of smalltalk. Smalltalk came first, and Alan Key was the one who invented the “OOP” name. Also ML is seen as a child of Lisp.

> I don’t understand why self is placed in the list instead of smalltalk. The article explains that: > Smalltalk inherited the notion of a value and its type from earlier languages, and implemented the idea of a class. All objects had a class that gave their type, and the class was used to construct objects of that type. Self disposed of the notion of class and worked solely with objects. As this is a purer form, I h…

Yes, but I still don't understand that explanation. Clearly self is a descendant of Smalltalk, that purified a part; but still is a descendant. At least I understand the "ur-" as indicating linage, more about time as features. For me is still backwards.

Re: The seven programming ur-languages (2022)

#130

I recently revisited a language comparison project, a specific benchmark tallying the cycle decompositions in parallel of the 3,715,891,200 signed permutations on 10 letters. I kept a dozen languages as finalists, different philosophies but all choices I could imagine making for my research programming. Rather than "ur" I was looking for best modern realizations of various paradigms. And while I measured performance…

I haven't looked into the code, but Lean being so slow may be misleading depending on how you benchmarked it. IMO the fairest test is how "Lean code" (or Rocq code, etc.) is actually run, which is as native C code following extraction.

Given the sane C defaults that are applied by code extraction techniques, the delta really shouldn't be so great. But it's a common pitfall to torture one's own verified code in order to get it proven, and I'm also not sure how good of support there is for parallelism.

Post reply on HN