Live data from Hacker News

The seven programming ur-languages (2022)

madhadron.com

141–150 of 161 posts

Re: The seven programming ur-languages (2022)

#141

Earlier quoted context omitted.

Rather COBOL is a living fossil? And today's Fortran is the FORTRAN family with horizontal gene transfer from the Algol lineage of programming languages.

Can COBOL be called a living fossil? I mean, programming languages do not live; and they do not "die", per se, either. Just the usage may go down towards 0. COBOL would then be close to extinction. I think it only has a few niche places in the USA and perhaps a very few more areas, but I don't think it will survive for many more decades to come, whereas I think C or python will be around in, say, three decades still.…

I don't know; COBOL pops up in banking all the time and Fortran lives on in a lot of specialised engineering applications.

Is there anything to be gained from rewriting it in Rust? Five years ago would there have been anything to be gained from rewriting it in Haskell? Ten years ago would there have been anything to be gained from rewriting it in Ruby? Fifteen years ago would there have been anything to gain from rewriting it in Clojure? Twenty years ago would there have been anything to gain from rewriting it in Java?

And so on, all the way back.

Re: The seven programming ur-languages (2022)

#142

Earlier quoted context omitted.

Rather COBOL is a living fossil? And today's Fortran is the FORTRAN family with horizontal gene transfer from the Algol lineage of programming languages.

Can COBOL be called a living fossil? I mean, programming languages do not live; and they do not "die", per se, either. Just the usage may go down towards 0. COBOL would then be close to extinction. I think it only has a few niche places in the USA and perhaps a very few more areas, but I don't think it will survive for many more decades to come, whereas I think C or python will be around in, say, three decades still.…

Analogies are inherently reductive; by deeply scrutinizing the differences you do not prove the analogy is useless.

Re: The seven programming ur-languages (2022)

#143

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…

Naively this is quite surprising, but the devil is in the details. With the exception of Lean I'd point out they're all fairly close: Chez being 2.5x slower than C++ is not ignorable but it's also quite good for a dynamically-typed JITted language[1]. And I'm not surprised that F# does so well at this particular task. Without looking into it more closely, this seems to be a story about F# on .NET Core having the most…

Thank you. I will try your Chez idea. I love Chez, even if coding in Scheme can feel like rubbing sticks together to start a fire on an island, when e.g. Scala has induction ranges. And I didn't try Idris or Racket as they compile to Chez, but perhaps they do so better than I did.

As for parallelism this is a primary concern of mine, and I tried multiple approaches for every language where there was a choice. I used my own work-stealing code only when it beat standard libraries. AI warned me I was in over my head, that writing such a library takes years of experience, but my use case (and my expected use cases in my research) is so uniform that simple can win, minimally touching the required bases such as permuting tasks to avoid false sharing.

I don't believe that the JIT languages (F# on top) do so well because of better parallelism. This is branch optimization. For this use case an AOT compiler with ample benchmark data to influence output should do better. That isn't a thing, and the argument seems to be that few use cases stay consistent. A JIT can adapt.

Re: The seven programming ur-languages (2022)

#144

I used to think being an engineer meant learning many languages. Turns out most of them solve the same problems — the returns diminish quickly. Depth across the stack (UX, CI/CD, model internals) compounds in a way that a sixth language never will.

I think that depends on the other five languages. Learning e.g. APL or Smalltalk if you are FORTRAN - C programmer would be very mind expanding.

Re: The seven programming ur-languages (2022)

#145
post #54

I always enjoy these summaries. I took my bachelor of computer science in the early 1990s. It covered a language in most of these categories. We didn't learn APL (Who is teaching the use of those custom keyboards to 100s of young students for one semester?) The processing power of systems at the time made it clear which language classes were practically useful and usable for the time and which were not. Prolog ran li…

Virginia Tech at least used to - the school of Architecture had a programming in APL class.

Re: The seven programming ur-languages (2022)

#146

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

Behold, future children, this is the ur-comment that started the cognitive revolution in how we teach programming languages in the 32nd century. The text and its important idea were almost lost in the tides of history, but it reached us thanks to a few eccentric ur-linguists digging through the ruins of post-WWIV civilizational collapse.

you have not discovered the ur-comment, you have discovered the ruins of the pedagogy that was Ur. "look on my works, ye mighty, and despair"

Re: The seven programming ur-languages (2022)

#147

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…

Both object oriented and an Algol.

Re: The seven programming ur-languages (2022)

#148
post #54

I always enjoy these summaries. I took my bachelor of computer science in the early 1990s. It covered a language in most of these categories. We didn't learn APL (Who is teaching the use of those custom keyboards to 100s of young students for one semester?) The processing power of systems at the time made it clear which language classes were practically useful and usable for the time and which were not. Prolog ran li…

A Smalltalk implementation provides:

    Smalltalk VM 

    Smalltalk image file 

    sources file (plain-text original source code file) 

    changes file (plain-text change log, initially empty)
So there are plenty of ways to submit code to be marked.

See "OU LearningWorks: a customized programming environment for Smalltalk modules"

https://ieeexplore.ieee.org/document/841064

Re: The seven programming ur-languages (2022)

#149
> "What do I mean when I say fundamentals? If you have an array or list of items and you’re going to loop over it, that is the same in any imperative language."

Err

"Fortran: The world’s first programming language standard opened the door to modern computing"

https://www.ibm.com/history/fortran

Re: The seven programming ur-languages (2022)

#150

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…

None of the other comments are about program benchmarks.
Post reply on HN