5 ms·

I agree you with you about generics, but downvoted you anyways, because "it gets ugly fast" is not true. I've certainly felt the pain of wanting generics for so

I agree you with you about generics, but downvoted you anyways, because "it gets ugly fast" is not true. I've certainly felt the pain of wanting generics for some data structures, but I've never felt the pain to where I've needed to make specialized structures for more than 2 or 3 types. And it had no real effect on the rest of my code. It was just one of those things where if I had generics, I could remove the 3x duplication of some code. It definitely doesn't ruin the language.

khyryk 13y ago
I want map (the function). I want filter. And I don't want to keep rewriting them over and over when I work on projects. They're not required -- indeed, I get by without them --, but the topic of the OP is elegance.
- mediocregopher 13y ago
  I wrote this to scratch an itch of mine: There is nothing about go which prevents the use of generics. I wrote the following library to scratch an itch of mine: https://github.com/mediocregopher/seq https://github.com/mediocregopher/seq It provides clojure-like data-structures and functions for interacting with them (like map and filter). It's completely immutable and generic, and supports lazy operations.
  - steveklabnik 13y ago
    Yes, if you totally throw away the type information, then Go will let you write some generic code. Your library uses a _ton_ of `interface{}`, because it has to.
- TylerE 13y ago
  Precisely. Other languages, Nimrod for instance (http://nimrod-lang.org/system.html#515 http://nimrod-lang.org/system.html#515) can manage this while still keeping a simple core, including lots of type-inference. Having generics doesn't automatically turn your language into Java. The map operator in Nimrod has a definition that is clear and simple: proc map[T](data: var openarray[T]; op: proc (x: var T): S): seq[S]
sdegutis 13y ago
One of the main jobs of a programming language is to reduce the amount of duplication you have to write. It just seems to me like being okay with that is antithetical to progress in practical language development.
- AnimalMuppet 13y ago
  That's not what Go thinks its job is at all. Go thinks its job is to make it easier to write and maintain large scale software applications. Removing the amount of duplication that any one developer has to write is not one of the design criteria. If you're not running into the issues that Go is trying to solve, you don't understand why its solutions are at least somewhat interesting, nor why its trade-offs are reasonable.
  - copergi 13y ago
    >Go thinks its job is to make it easier to write and maintain large scale software applications It thinks wrong. Making people duplicate code makes it harder to write and maintain large scale software applications.
- mavdi 13y ago
  Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is. While lack of duplication might help, it is in no way a necessity for a maintainable code base.
  - iopq 13y ago
    If code is duplicate of some other code maintenance increases 2x. If it's in ten places, it's 10x. If two different version diverge and they should really be the same (but for some reason one has data packed into an array and the other has multiple arguments, etc.) it becomes impossible to fix it without breaking something
  - coldtea 13y ago
    >Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is. Actually what you describe is the Java mentality exactly! That's why Java is full of code duplication and is supposed to help with code maintenance.
yohanatan 13y ago
Any language which prevents you from removing '3x duplication of some code' is ruined.

khyryk 13y ago

I want map (the function). I want filter. And I don't want to keep rewriting them over and over when I work on projects. They're not required -- indeed, I get by without them --, but the topic of the OP is elegance.

mediocregopher 13y ago
I wrote this to scratch an itch of mine: There is nothing about go which prevents the use of generics. I wrote the following library to scratch an itch of mine: https://github.com/mediocregopher/seq https://github.com/mediocregopher/seq It provides clojure-like data-structures and functions for interacting with them (like map and filter). It's completely immutable and generic, and supports lazy operations.
- steveklabnik 13y ago
  Yes, if you totally throw away the type information, then Go will let you write some generic code. Your library uses a _ton_ of `interface{}`, because it has to.
TylerE 13y ago
Precisely. Other languages, Nimrod for instance (http://nimrod-lang.org/system.html#515 http://nimrod-lang.org/system.html#515) can manage this while still keeping a simple core, including lots of type-inference. Having generics doesn't automatically turn your language into Java. The map operator in Nimrod has a definition that is clear and simple: proc map[T](data: var openarray[T]; op: proc (x: var T): S): seq[S]

sdegutis 13y ago

One of the main jobs of a programming language is to reduce the amount of duplication you have to write. It just seems to me like being okay with that is antithetical to progress in practical language development.

AnimalMuppet 13y ago
That's not what Go thinks its job is at all. Go thinks its job is to make it easier to write and maintain large scale software applications. Removing the amount of duplication that any one developer has to write is not one of the design criteria. If you're not running into the issues that Go is trying to solve, you don't understand why its solutions are at least somewhat interesting, nor why its trade-offs are reasonable.
- copergi 13y ago
  >Go thinks its job is to make it easier to write and maintain large scale software applications It thinks wrong. Making people duplicate code makes it harder to write and maintain large scale software applications.
mavdi 13y ago
Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is. While lack of duplication might help, it is in no way a necessity for a maintainable code base.
- iopq 13y ago
  If code is duplicate of some other code maintenance increases 2x. If it's in ten places, it's 10x. If two different version diverge and they should really be the same (but for some reason one has data packed into an array and the other has multiple arguments, etc.) it becomes impossible to fix it without breaking something
- coldtea 13y ago
  >Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is. Actually what you describe is the Java mentality exactly! That's why Java is full of code duplication and is supposed to help with code maintenance.

yohanatan 13y ago

Any language which prevents you from removing '3x duplication of some code' is ruined.