Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The seven programming ur-languages (2022)

madhadron.com

Post reply on HN
Print view View original

101–110 of 161 posts

Re: The seven programming ur-languages (2022)

#101

Post by jounker »

gobdovan wrote: post #19
gobdovan wrote: post #15

there's a few more semantic families: verilog, petri nets and variants, Kahn process networks and dataflow machines, process calculi, reactive, term rewriting, constraint solvers/theorem provers (not the same with Prolog), probabilistic programming, plus up and coming (actual production-ready) languages that don't fit perfectly in the 7 categories: unison, darklang, temporal dataflow, DBSP It may feel like a little b…

also Sussman's propagators are nice to check out [0] [0] The Art of the Propagator (mit url down for the moment)

So they reinvented speadsheets?

Re: The seven programming ur-languages (2022)

#103

Post by stared »

I agree with "learn different classes of languages". OCaml was a language in which finally a function was a (mathematical) function. Mathematica thought me to look at expressions themselves as inputs. PostScript (with its reverse Polish notation going beyond simple arithmetics) rewired by brain.

At the same time, I don't agree with that it does not matter if one picks "Java, C#, C++, Python, or Ruby". If your goal is to do quick sort, then well, it does not.

If you want to use language for something (not only for its sake), then it makes a day and night difference. A person who wants to do 3D games and being shown Ruby or a person wanting to do exploratory data science and deep learning and being given Java are likely to get discouraged.

Re: The seven programming ur-languages (2022)

#104

Post by ekropotin »

stared wrote: post #103

I agree with "learn different classes of languages". OCaml was a language in which finally a function was a (mathematical) function. Mathematica thought me to look at expressions themselves as inputs. PostScript (with its reverse Polish notation going beyond simple arithmetics) rewired by brain. At the same time, I don't agree with that it does not matter if one picks "Java, C#, C++, Python, or Ruby". If your goal is…

Even tho I probably never will get paid for writing Rust, I have zero regrets about learning it - it tough me really think about data ownership in programs.

Re: The seven programming ur-languages (2022)

#105

Post by the__alchemist »

pjmlp wrote: post #56
steve_gh wrote: post #25

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…

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 similar to Rust, which by some definitions can't do OOP. So, if Rust can't do OOP (assumption) and I can write Python and Rust with equivalent structure (Assumption), does that mean Python isn't strictly OOP?

Re: The seven programming ur-languages (2022)

#106

Post by ianburrell »

macintux wrote: post #3

Reminds me a bit of Bruce Tate’s approach in 7 languages in 7 weeks, which is where I first encountered Erlang. I think from a historical perspective, describing COBOL and Fortran as part of the ALGOL family is a stretch, but I suppose it’s a good reminder that all history is reductive.

I also think going back farther is a stretch. The first assembly languages were imperative, but what made Algol, Fortran, and Cobol interesting were functions and other features that allowed complex programming. Algol has the most descendants but Fortran was the first imperative programming language.

Re: The seven programming ur-languages (2022)

#107

Post by LeCompteSftware »

Syzygies wrote: post #97

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 mature and painless out-of-the-box parallelism of these languages. I assume this is elapsed time, it would be interesting to see a breakdown of CPU time.

I don't think these results are quite comparable because of slightly differing parallelism strategies; I'd expect the F# implementation of just spinning off threads to be more a little more performant than a Rayon parallel iterator, which presumably has some overhead. But that really just shows how hard it is to do a cross-language comparison; Rust and C++ can certainly be made faster than the F# code by carefully manipulating a ton of low-level OS concurrency primitives. This would arguably also be little misleading. Likewise Chez and Haskell have good C FFI; does that count? It's a tricky and highly qualitative analysis.

[1] FYI, one possible performance improvement with the Chez code is keeping the permutations in fxvectors and replace math operations with the fixnum-specific equivalent - this tells the compiler/interpreter that the data are guaranteed to be machine integers rather than bigints, so they aren't boxed/unboxed. I am not sure without running it myself, but there seems to be avoidable allocations in the Chez implementation. https://cisco.github.io/ChezScheme/csug/objects.html#./objec...

Re: The seven programming ur-languages (2022)

#108

Post by mcmoor »

gf000 wrote: post #99
zozbot234 wrote: post #89

Earlier quoted context omitted.

These are not true programming languages because by definition they are not Turing complete. If they were Turing complete it would be possible to write a false proof that just compiled down to a non-terminating program.

There has never been a requirement for a "true" programming language to be Turing complete. Also, basically every such language has escape hatches similar to unsafe in Rust to allow expressions that are not provably terminating. They can then just be accepted as an axiom.

I feel like Turing completeness has always been set as the boundary of programming language if there's any boundary at all. That's what people has been using to not include HTML as programming language for example. Or to include MTG as one.

Re: The seven programming ur-languages (2022)

#109

Post by thesuperbigfrog »

the__alchemist wrote: post #105
pjmlp wrote: 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…

> if Rust can't do OOP (assumption)

Rust handles basic OOP, but not all of the characteristics seen in C++ or Java:

https://doc.rust-lang.org/book/ch18-01-what-is-oo.html

Re: The seven programming ur-languages (2022)

#110

Post by AdieuToLogic »

bitwize wrote: post #61
steve_gh wrote: post #25

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…

Aren't camels a Perl thing?

> Aren't camels a Perl thing?

That's a deep cut. :-)

For anyone reading this, O'Reilly was once legendary for their cover-art mascots.

Post reply on HN