Modern programming languages require generics(ayende.com)
ayende.com
Modern programming languages require generics
https://ayende.com/blog/197282-B/modern-programming-languages-require-generics?key=37e0cfa91b16417bae269c4bdd17f522
25 comments
I suggest "modern" here is part of a stronger claim. That if a language doesn't do X, it is not "modern": It doesn't reflect current understanding of best practice, reasonable expectations, etc. It's a failure of due diligence, not an engineering tradeoff.
For example, languages of a certain generation didn't have community archives. Python was born at the transition, and suffered for years with multiple dysfunctional ones. Ruby got gems because of that "don't be Python" cautionary tale. A language of the current generation, putting forth that older story of "people can just put up their code whereever, and no doubt someone(s) will likely make a list(s) of those" might reasonably be described as "not modern".
Software engineering, and language design, reflect a great deal of "you say we've known how to do this better for years... but, well, shrug". Ratcheting up the bar on "modern" seems one way our community achieves its oh-so-slow progress.
With an emotional vibe of "open sewers on streets, regardless of their historical precedence, low build cost, and current prevalence, are something we just shouldn't be doing nowadays."
For example, languages of a certain generation didn't have community archives. Python was born at the transition, and suffered for years with multiple dysfunctional ones. Ruby got gems because of that "don't be Python" cautionary tale. A language of the current generation, putting forth that older story of "people can just put up their code whereever, and no doubt someone(s) will likely make a list(s) of those" might reasonably be described as "not modern".
Software engineering, and language design, reflect a great deal of "you say we've known how to do this better for years... but, well, shrug". Ratcheting up the bar on "modern" seems one way our community achieves its oh-so-slow progress.
With an emotional vibe of "open sewers on streets, regardless of their historical precedence, low build cost, and current prevalence, are something we just shouldn't be doing nowadays."
Would "contemporary" work better for you? There certainly is a cluster of languages that have developed and gained (more or less) traction in the last 10-15 years. I've even heard it referred to as a "generation" -- specifically I think it's the fifth. Rust, Go, Nim, Clojure, Swift, Elixir; to a lesser extent, Zig. I'm probably forgetting a few. (We might also include Crystal or Pony though I'm not sure they are widely used at all. And Hare is an open question.)
I think Julia (built around multiple-dispatch) also ought to be mentioned in any discussion of generic programming in contemporary languages.
Unfortunately that's another word that dates itself. Think of the "Contemporary Resort" in Disney World. It has its charm to be sure, but it is very much a period piece evoking the early 1970s when it was built. Every time thinks it has the definitive opinion on design whether architecture or programming language design. History says otherwise, and it is unclear if any actual progress as opposed to simple shifting fashion is responsible.
A better term might be state of the art, but that has its own issues.
In this case, I mean, recent
I agree; there are a lot of reasons to have generics in a language, performance one of them as demonstrated; but anyway it doesn't make sense if in a strictly, statically typed language we are forced to do dynamic typing to make data structures and algorithms reusable; however, i don't understand why everyone always goes for generic types; generic modules can do that too and are much easier to understand and implement.
I'd say that no matter where, but you have to add generic parameters to algorithms to make them reusable across domains.
Doing so at type / function level allows to introduce them gradually and with low ceremony, compared to parametrized modules (likely you mean OCaml here?). Gradual approaches seem to work best in real world, hence the prevalence of generic functions and parametrized types.
Doing so at type / function level allows to introduce them gradually and with low ceremony, compared to parametrized modules (likely you mean OCaml here?). Gradual approaches seem to work best in real world, hence the prevalence of generic functions and parametrized types.
> likely you mean OCaml here
No, I was thinking of Ada or Oberon+. Here is a discussion: https://oberon-lang.github.io/2021/07/17/considering-generic...
No, I was thinking of Ada or Oberon+. Here is a discussion: https://oberon-lang.github.io/2021/07/17/considering-generic...
Can you explain what you mean by generics modules?
Here is an example: https://oberon-lang.github.io/, see section Generic Programming; note how the modules have type parameters and how generic module is instantiated by the import declaration in the example of section Object Oriented Programming.
Here is the specification: https://github.com/oberon-lang/specification/blob/master/The...
Here is a discussion why it is designed like this: https://oberon-lang.github.io/2021/07/17/considering-generic...
Here is the specification: https://github.com/oberon-lang/specification/blob/master/The...
Here is a discussion why it is designed like this: https://oberon-lang.github.io/2021/07/17/considering-generic...
Thanks for this. By coincidence, I was sketching out a polymorphism kludge this evening, and this was food for thought.
That reminds me very strongly how Zig does it
I'm not familiar with Zig, but a quick look at https://ziglang.org/documentation/master/#Generic-Data-Struc... makes me doubt that Zig does genericity on module level; looks rather like parametric polymorphism.
Not GP, and I'm just surfing unfamiliar docs, but it looks like, yes, there's general parameter polymorphism,[1] but also "modules" presented as structs,[2] and the polymorphism of struct constructors can have nontrivial impacts[3](eg Map(KeyType,void) loses value setters). Fwiw.
[1] https://ziglang.org/documentation/master/#comptime "Compile-time parameters is how Zig implements generics. It is compile-time duck typing." [2] https://ziglang.org/documentation/master/#import [3] https://ziglang.org/documentation/master/#void "By using void as the type of the value, the hash map entry type has no value field, and thus the hash map takes up less space. Further, all the code that deals with storing and loading the value is deleted, as seen above."
[1] https://ziglang.org/documentation/master/#comptime "Compile-time parameters is how Zig implements generics. It is compile-time duck typing." [2] https://ziglang.org/documentation/master/#import [3] https://ziglang.org/documentation/master/#void "By using void as the type of the value, the hash map entry type has no value field, and thus the hash map takes up less space. Further, all the code that deals with storing and loading the value is deleted, as seen above."
interesting, thanks
> The counter for this argument is that we can always specialize the code for our needs, right? Except… that this isn’t something that happens.
This feels like a weird assertion, especially when immediately followed by an example where such manual specialization happens
This feels like a weird assertion, especially when immediately followed by an example where such manual specialization happens
I guess nobody would call it “modern” but it is quite possible to have the compiler do type inference and automagically specialize functions with the user not even knowing it is happening behind the scenes. No generics needed.
Is it? To me it seemed like any potentially powerful enough type system starts needing at least some degree of type annotations at some point. Something something typechecking halting problem? Don't know the specifics though.
The papers I read would keep a running tally of the types of the variables and if they were all the same could optimize and/or specialize the called functions. If not they would just fall back to checking the types before performing whatever operations.
Basically the theory behind the Futamura projections.
I’m sure you could write some code which could keep an abstract interpreter or however type checking is implemented busy forever especially with a dynamic language with eval but, you know, you get what you pay for.
Or I’m completely wrong since I just read about this stuff for fun…
Basically the theory behind the Futamura projections.
I’m sure you could write some code which could keep an abstract interpreter or however type checking is implemented busy forever especially with a dynamic language with eval but, you know, you get what you pay for.
Or I’m completely wrong since I just read about this stuff for fun…
This is such crap. Modern programming languages (or any other tools) need to be well suited for a specific problem domain, not meet some generalized arbitrary criterion. And modern systems (as in actual low-level software, not web browsers or databases or games) suffer from a severe lack of security and reliability, not performance.
Do you enjoy your code base using 5 languages? 10? Have you done some ops support recently? Code review? Hired developers?
There are very real advantages in the use of the fewest languages that cover your spectrum of problems. If you can limit the spectrum of languages you use to, for instance, Typescript (with react native on mobile), SQL, and Kubernetes config YAML, it's a big win for productivity and growth.
There are very real advantages in the use of the fewest languages that cover your spectrum of problems. If you can limit the spectrum of languages you use to, for instance, Typescript (with react native on mobile), SQL, and Kubernetes config YAML, it's a big win for productivity and growth.
This kind of mindset and mode of organising a dev team is a common, and has the advantage of interchangeable developers, not a lot of need for on the job learning, and more long term tech stability. Basically the "we area a Java house with big teams" way. But it's far from the only one.
This kind of mindset and mode of organising a dev team is a common, and has the advantage of more interchangeable developers and more long term tech stability. Basically the "Java house" way. But it's far from the only one.
I would rather just have one code base per problem rather than one abomination per spectrum of problems.
> A modern language that is aiming for performance should take this very important aspect of language design into account.
could have been rewritten as
> A language that is aiming for performance should take this very important aspect of language design into account.
and been clearer and more objective for it.