26 programming languages in 25 days, Part 2: Reflections on language design

Re:26 programming languages in 25 days, Part 2: Reflections ... by dogfishbar on Tuesday January 03, 2023 @08:43AM (#34231173)

Thanks for letting us tag along. What I'd like to hear are your thoughts on the Groucho Marx cigar question: laziness is useful every now and then, but in lazy languages like Haskell you pay for it everywhere. The same is true for dynamic dispatch, it's needed when working with values of sum type. But like laziness, it isn't needed wall-to-wall but in dynamically-typed languages, you pay for it everywhere. Give me a call-by-value language with arrow and sum types and I can pay as I go. [edit: added "arrow and"]

[ Parent | on HN ]

Re:26 programming languages in 25 days, Part 2: Reflections ... by TylerE on Tuesday January 03, 2023 @10:20AM (#34232459)

Ocaml then?

It has optional options-in lazyness for the few times you really need it.

Or just rolling it yourself with e.g. a python generator

[ Parent | on HN ]

Re:26 programming languages in 25 days, Part 2: Reflections ... by dogfishbar on Tuesday January 03, 2023 @10:28AM (#34232594)

Sure, OCaml is great as are the other dialects of ML. I'm hoping that someone will weigh in with a compelling case for laziness everywhere or dynamic dispatch everywhere, other than pre-existing infrastructure, libraries, etc.

[ Parent | on HN ]

Re:26 programming languages in 25 days, Part 2: Reflections ... by still_grokking on Tuesday January 03, 2023 @12:16PM (#34234364)

> hoping that someone will weigh in with a compelling case for laziness everywhere

How should this happen? You can hear even form the horses mouth that laziness by default was a big mistake.

> dynamic dispatch everywhere

Big mistake of most "OO language" indeed.

Rust got this right. Static dispatch is the default (simple and fast!) but you can have dynamic dispatch where it makes sense. I hope this design will be copied in the future everywhere. Maybe even some language manage to get rid of their mistake and switch to the sane design (looking at you Scala, just make type-classes first-class, but keep OOP for the cases where it makes sense).

[ Parent | on HN ]