Hacker News Reader

Comment by scribu | Hacker News Reader

I think the negative attitude comes more from frustration than from anything else.

> I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is.

I didn't know what it was called either until I saw them mentioned here, but now that I know about it, I get why it would be useful. Before that, I kind of assumed all languages with generics would also allow you to access the type information at runtime.

> I have run into some problems where being able to define custom generic containers would be nice, but I don't feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software.

I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox

View on HN

> I don't mean any disrespect, but this is a very good example of the Blub Paradox: http://wiki.c2.com/?BlubParadox

Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that meets our requirements). It is similar to point 4 in the "Problems with the Blub Paradox" section.

One of the problems is who decides what is too simple. E.g. why are for loops, function calls and lamdbas considered simple enough to be in go, but generics aren't? When I TA'ed CS introductory courses, student usually had a lot less trouble with understanding generics than lambdas.

Not including feature X in programming language Y will also ensure that no-one who primarily uses Y will ever come to understand or appreciate X.

The blub paradox basically represents the opinion that it is always better for languages to include more powerful features.

I think that goes too far, working primarily in Scala I am seeing firsthand how much diminishing returns extra complexity in the language can have, but I'm certainly of the opinion that Go leans too heavily toward handicapping the language in pursuit of simplicity.

The complexity from generics isn't from the conceptual standpoint, it's from the resulting code standpoint... for the same reason that the ternary ?: operator is "too complex": it's really easy to say that `foo := cond ? 1 : 0` is better than the if/else alternative, but `foo := (a > (b.Active() ? Compare(b, a) : useDefault() ? DEFAULT : panic()) ? "worked" : "failed"` is a mess waiting to happen.

Same with generics. It's easy to point to simple examples. It hard to ensure that terrible metaprogramming monstrosities don't arise.

It's possible to write bad code with go as it is, but it's actually difficult to make such bad code inscrutable.

Maybe, but the solution to this is not to say: Only the compiler implementers are smart enough people to not create messy code with generics, only a few built-in data types are allowed to be generic and the rest will have to copy-paste implementations or use lose type information through `interface {}`

FYI, reified generics undermine type safety and correctness in general, which is one of the reasons why so few languages support the concept (another is that erased generics allow for easier interoperability and for the creation of a much wider class of static type systems).

In my experience, most people who think they need reified generics don't really understand them and can actually do fine with much safer concepts expressed on an erased runtime.

This made me think about Pony and its capabilities system.. Also of Haskell and all the rmap, lmap, rfold, lfold, rmagic, lmurloc.. :P

Reply on news.ycombinator.com