5 ms·

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

sam_lowry_ 6y ago
I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.
- skinkestek 6y ago
  I've - read that from start to end exactly zero times, - picked up generics in a day or two, - struggled with advanced types twice, half a day each time - struggled with type erasure twice, also about half a day each time. Meanwhile generics often saves me a number of minutes pr hour and makes everything cleaner and easier to read. I used Java before generics but once it arrived I never looked back and neither did anyone i know.
- karmakaze 6y ago
  Java before 5 wasn't a language, it was a library and number of jvm implementations. It wasn't until Java 5 that there was a memory model spec that defined how stuff was supposed to work.
jacques_chester 6y ago
People from the post-1.4 era of Java aren't aware how huge code generation was before generics showed up. And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks. It is the worst solution to any problem solvable by a type system.
- BoorishBears 6y ago
  My favorite example of generics wonkiness was when I needed a channel to wrap an untyped channel to avoid "infecting" every call site for a utility function with untyped pointers. I thought it was madness, but bringing it up to a very large Golang group and get "nope channels are cheap! That's fine! There's repetition but it's easy to follow" I've said before, my personal take is use Go, get a feel for the Go mentality, then take it with you to another language. Go is just too stuck between low level and high level for me personally. I'd rather go under with Rust or over with Kotlin or C#
- pjmlp 6y ago
  Here is a good one, using Eclipse EMF for code generation having as input UML data files generated from Rational Rose.
uncledave 6y ago
Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types! Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. I'm not even sure I'm happy with it for abstract data types. Please can we keep Go special.
- travv0 6y ago
  > Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. What does any of that have to do with generics?
  - uncledave 6y ago
    Well the generic programming model tends to favour using light weight abstract data structures instead of well defined types. Those abstractions are by nature leaky so many internal concerns leak out of abstraction boundaries into the caller and give them one hell of a bad time.
    - cannabis_sam 6y ago
      > Those abstractions are by nature leaky Do you have any examples?
- Smaug123 6y ago
  `Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>>` This is not a problem with generics, but with C#'s lack of discriminated unions and/or tiny-types. Except what on earth are you doing with a dictionary whose keys are lists of dictionaries? I am quite sure someone has not modelled their domain correctly there. That's not something you can blame on the existence of generics - I shudder to imagine how much worse it could have been without generics!
praptak 6y ago
Go (without generics) is not Java 1.4. Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.
- anothernewdude 6y ago
  I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.
  - praptak 6y ago
    Most of the casting in Java 1.4 was from collections of Object. In Go the collections are typed, so the casting is confined to some very specialized pieces of code.
    - simiones 6y ago
      The only difference between Go and Java 1.4 in terms of collections is that Go has a generic map type, which Java didn't. Java 1.4 still had generic arrays, just like Go. In fact, it was a little easier to program with generic arrays in Java vs Go (but also less safe) because in Java a subtype[] can be passed to a function which takes a supertype[] (arrays are covariant).
    - pjmlp 6y ago
      Yeah, right because we never been there before. class IntList { private List objList; public add(int elem) { objList.add(Integer.of(elem)); } } Rest is left as exercise for the readers that never used Java generics, or C++ templates.

sam_lowry_ 6y ago

I miss Java 1.4. It was small and concise. Java 5 added so much that none knows all of it. Just look at the length of Java Generics FAQ. It's hilarious.

skinkestek 6y ago
I've - read that from start to end exactly zero times, - picked up generics in a day or two, - struggled with advanced types twice, half a day each time - struggled with type erasure twice, also about half a day each time. Meanwhile generics often saves me a number of minutes pr hour and makes everything cleaner and easier to read. I used Java before generics but once it arrived I never looked back and neither did anyone i know.
karmakaze 6y ago
Java before 5 wasn't a language, it was a library and number of jvm implementations. It wasn't until Java 5 that there was a memory model spec that defined how stuff was supposed to work.

jacques_chester 6y ago

People from the post-1.4 era of Java aren't aware how huge code generation was before generics showed up. And then all that momentum, all the tools, the books, the conference presentations, the code ... all of it. Pop! It died. Because code generation sucks. It is the worst solution to any problem solvable by a type system.

BoorishBears 6y ago
My favorite example of generics wonkiness was when I needed a channel to wrap an untyped channel to avoid "infecting" every call site for a utility function with untyped pointers. I thought it was madness, but bringing it up to a very large Golang group and get "nope channels are cheap! That's fine! There's repetition but it's easy to follow" I've said before, my personal take is use Go, get a feel for the Go mentality, then take it with you to another language. Go is just too stuck between low level and high level for me personally. I'd rather go under with Rust or over with Kotlin or C#
pjmlp 6y ago
Here is a good one, using Eclipse EMF for code generation having as input UML data files generated from Rational Rose.

uncledave 6y ago

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types! Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. I'm not even sure I'm happy with it for abstract data types. Please can we keep Go special.

travv0 6y ago
> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. What does any of that have to do with generics?
- uncledave 6y ago
  Well the generic programming model tends to favour using light weight abstract data structures instead of well defined types. Those abstractions are by nature leaky so many internal concerns leak out of abstraction boundaries into the caller and give them one hell of a bad time.
  - cannabis_sam 6y ago
    > Those abstractions are by nature leaky Do you have any examples?
Smaug123 6y ago
`Dictionary<List<Dictionary<string, object>>>, SortedSet<Dictionary<int, string>>>>` This is not a problem with generics, but with C#'s lack of discriminated unions and/or tiny-types. Except what on earth are you doing with a dictionary whose keys are lists of dictionaries? I am quite sure someone has not modelled their domain correctly there. That's not something you can blame on the existence of generics - I shudder to imagine how much worse it could have been without generics!

praptak 6y ago

Go (without generics) is not Java 1.4. Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.

anothernewdude 6y ago
I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.
- praptak 6y ago
  Most of the casting in Java 1.4 was from collections of Object. In Go the collections are typed, so the casting is confined to some very specialized pieces of code.
  - simiones 6y ago
    The only difference between Go and Java 1.4 in terms of collections is that Go has a generic map type, which Java didn't. Java 1.4 still had generic arrays, just like Go. In fact, it was a little easier to program with generic arrays in Java vs Go (but also less safe) because in Java a subtype[] can be passed to a function which takes a supertype[] (arrays are covariant).
  - pjmlp 6y ago
    Yeah, right because we never been there before. class IntList { private List objList; public add(int elem) { objList.add(Integer.of(elem)); } } Rest is left as exercise for the readers that never used Java generics, or C++ templates.