4 ms·

> I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line.

by Veedrac 11y ago

> I think the right way to look at programming language features is to look at the cost-benefit tradeoff. Generics, to me, are clearly on one side of the line. The right way is to look at the cost-benefit tradeoff in context. There is no fixed line. Go has goroutines and channels because the designers judge that for the area they're aiming at, the benefit outweighs the cost. Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. (You could argue this is just another Blub paradox, but IMHO that would only make sense if the designers weren't proficient in languages including generics, like Java.)

pcwalton 11y ago
> Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. You can find some person who enjoys anything. But I think having basic OCaml-style generics has essentially zero downsides and so many upsides that it's essentially an open and shut judgment call for every statically typed language.
jasode 11y ago
>, but the fact is that some people in enjoy the simplicity that comes from Go not having them. The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.) As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process. Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash. However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.
- Veedrac 11y ago
  > The Golang team was not extolling the lack of generics in Go as a point of pride. Indeed, they're extolling the simplicity one gets. To quote their FAQ: > Why does Go not have generic types? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better. > As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
  - jasode 11y ago
    >Indeed, they're extolling the _simplicity_ one gets. To quote their FAQ: [...] If they can find a way to add it that doesn't take away the _simplicity_ You're missing my point because you've used "simplicity" twice in a way that I was trying to define in a more holistic manner. You, and the FAQ you quoted, was talking about language-specification-simplicity. I was trying to make the discussion more cognizant of holistic-simplicity which means new complexity is created when one part is "simpler". >There are reasonable ways to write code that largely avoids them There are workarounds for everything, sure. Workarounds affect holistic-simplicty. Also, what's "reasonable" is subjective. In any case, I'm not convinced that language-spec-simplicity trumps holistic-simplicity.
    - Veedrac 11y ago
      It's just a different way of solving a problem. Labelling it a workaround is disingenuous if people are claiming they prefer writing code in that manner. It's also incorrect to dismiss language complexity as specification complexity. One might just dismiss all of C++'s complexity as specification complexity. It ignores all the difficulties it adds to run-time, compilation (speed, correctness and compiler flexibility), incidental knock-on effects on other language constructs, external tools, syntactic simplicity, learning speed, code consistency and, as the article covers, just being itself a distraction from the real problem. And if you write code in this manner anyway, the simplicity in the language makes a big difference. > Also, what's "reasonable" is subjective. I fully agree.

by Veedrac 11y ago

pcwalton 11y ago

> Same with generics - don't conflate them being good for you in your circumstance to them being good for everyone in every circumstance. We can argue to the ends of the earth where that line lies, but the fact is that some people in enjoy the simplicity that comes from Go not having them. You can find some person who enjoys anything. But I think having basic OCaml-style generics has essentially zero downsides and so many upsides that it's essentially an open and shut judgment call for every statically typed language.

jasode 11y ago

>, but the fact is that some people in enjoy the simplicity that comes from Go not having them. The Golang team was not extolling the lack of generics in Go as a point of pride. They have admitted that it is a useful feature but they haven't decided yet how to add it to the language. (Maybe they never will.) As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. If you don't have generics as a 1st-class language feature, you've now forced complexity into the users' code with empty interface{} and copy & paste code. Or, you create new complexity by writing a code gen tool to simulate generics. The complexity is now in the code-to-write-code-tool & the build process. Certainly, there are some languages that don't need generics: proprietary 4GL such as SAP ABAP, procedural-SQL such as Microsoft Transact-SQL and Oracle PL/SQL, and shell scripting languages such as bash. However, with Go positioning itself as a "general" programming language, the lack of generics is more a consequence of Google's priorities and timeline of development rather than a pinnacle of design. Programmers have wanted to write algorithms that work with multiple types for decades before Go was invented and leaving it out as a language feature actually doesn't make things simpler if "simplicity" is looked at holistically.

Veedrac 11y ago
> The Golang team was not extolling the lack of generics in Go as a point of pride. Indeed, they're extolling the simplicity one gets. To quote their FAQ: > Why does Go not have generic types? > Generics are convenient but they come at a cost in complexity in the type system and run-time. We haven't yet found a design that gives value proportionate to the complexity, although we continue to think about it. If they can find a way to add it that doesn't take away the simplicity they enjoy, all the better. > As far as it being "simpler" that Go doesn't have generics, I've never understood this conclusion. That's if you require generic objects. There are reasonable ways to write code that largely avoids them (namely, by specializing your code on specific, standard types for the given problem). Whether this is reasonable for your circumstance depends on your circumstance and the way you like to solve problems.
- jasode 11y ago
  >Indeed, they're extolling the _simplicity_ one gets. To quote their FAQ: [...] If they can find a way to add it that doesn't take away the _simplicity_ You're missing my point because you've used "simplicity" twice in a way that I was trying to define in a more holistic manner. You, and the FAQ you quoted, was talking about language-specification-simplicity. I was trying to make the discussion more cognizant of holistic-simplicity which means new complexity is created when one part is "simpler". >There are reasonable ways to write code that largely avoids them There are workarounds for everything, sure. Workarounds affect holistic-simplicty. Also, what's "reasonable" is subjective. In any case, I'm not convinced that language-spec-simplicity trumps holistic-simplicity.
  - Veedrac 11y ago
    It's just a different way of solving a problem. Labelling it a workaround is disingenuous if people are claiming they prefer writing code in that manner. It's also incorrect to dismiss language complexity as specification complexity. One might just dismiss all of C++'s complexity as specification complexity. It ignores all the difficulties it adds to run-time, compilation (speed, correctness and compiler flexibility), incidental knock-on effects on other language constructs, external tools, syntactic simplicity, learning speed, code consistency and, as the article covers, just being itself a distraction from the real problem. And if you write code in this manner anyway, the simplicity in the language makes a big difference. > Also, what's "reasonable" is subjective. I fully agree.