3 ms·

> Generics were hardly bleeding edge by 2002. yes and no. It's clear from the history at the time that they were not a proven, obvious win. > Generics for .N

> Generics were hardly bleeding edge by 2002. yes and no. It's clear from the history at the time that they were not a proven, obvious win. > Generics for .NET and C# in their current form almost didn't happen > being told by product team members that "generics is for academics only" https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-generics-history-some-photos-from-feb-1999 https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge... My argument is that this particular question has, since then, been settled in favour of generics, outside of academia, and in mainstream languages such as c#. Generics are now "established and proven" in ways that they were not then. Hindsight: https://twitter.com/matthewwarren/status/920667986108846080 https://twitter.com/matthewwarren/status/920667986108846080 C# is IMHO mainstream, deliberately so. Features in it typically come from other languages. It is a "populariser" of promising programming language ideas for mainstream productivity, not a testbed. > Doesn't mean the average developer understood the point at the time as a junior dev, I got the point inside a minute: I was already in the habit of when declaring Customer class adding a strongly typed CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List<Customer> etc was such a clear win.

masklinn 5y ago
> I was already in the habit of when declaring Customer class adding a strongly CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List<Customer> etc was such a clear win. TBF a common rejoinder back then was that this specific pattern made the opportunity cost of domain-specific operations very low, so you could better those collection interfaces to the specific needs. Of course 95% of the time they extended the corresponding class or implemented the interface so that wasn't actually true.
- SideburnsOfDoom 5y ago
  > this specific pattern made the opportunity cost of domain-specific operations very low, Yes, I did miss the "added value" operations declared on that list class, e.g. AddressList typically contained a "GetCustomerPrimaryAddress", etc. But there were ways to bring that back, by subclassing or (later) extension method on that list. Indeed, 95% of the code was tedious forwarding to the non-generic non-typesafe "list of objects". Around the same time the dominant pattern of saving or loading data to a data store moved from "active record" where these methods were common, to "repository and DTO" where they were not. Might be co-incidence.

masklinn 5y ago

> I was already in the habit of when declaring Customer class adding a strongly CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List<Customer> etc was such a clear win. TBF a common rejoinder back then was that this specific pattern made the opportunity cost of domain-specific operations very low, so you could better those collection interfaces to the specific needs. Of course 95% of the time they extended the corresponding class or implemented the interface so that wasn't actually true.

SideburnsOfDoom 5y ago
> this specific pattern made the opportunity cost of domain-specific operations very low, Yes, I did miss the "added value" operations declared on that list class, e.g. AddressList typically contained a "GetCustomerPrimaryAddress", etc. But there were ways to bring that back, by subclassing or (later) extension method on that list. Indeed, 95% of the code was tedious forwarding to the non-generic non-typesafe "list of objects". Around the same time the dominant pattern of saving or loading data to a data store moved from "active record" where these methods were common, to "repository and DTO" where they were not. Might be co-incidence.