6 ms·

A few extra lines for sorting means you won't touch Go with a pole? That's a bit extreme. Do you really do custom sorting so often that this is a major problem?

A few extra lines for sorting means you won't touch Go with a pole? That's a bit extreme. Do you really do custom sorting so often that this is a major problem? There's plenty of other ways in which Go is shorter than the equivalent C++ (e.g. with type inference, or channel operations), but no-one's trying to claim that the shortest code wins.

masklinn 13y ago
> A few extra lines for sorting It's not just sorting, it's any parametric polymorphism: generic operations or non-built-in containers (not just in the sense of "array", an atomic ref is also a container) for instance. Go only lets do these in verbose, clunky ways, and losing much of the type safety Go is supposed to provide (what with being a statically typed language) > no-one's trying to claim that the shortest code wins. No one is indeed, so that's an irrelevant strawman.
- dsymonds 13y ago
  The post I replied to didn't explicitly say what he disliked about sorting in Go, and what "this" means in "When they fix this". I guessed that it was because the Go code is a bit longer. What else could it be? I guess it's a little clunkier, and it's true that writing generic containers in Go isn't so great, but is that sufficient to elicit a reaction of "I'm not touching it with a pole"? Nobody claims it's perfect, but is it really sufficiently horrible to warrant that?
  - masklinn 13y ago
    > it's true that writing generic containers in Go isn't so great That's one hell of an understatement. > is it really sufficiently horrible to warrant that? A number of people obviously and repeatedly say that yes, a statically typed language without parametric polymorphism is sufficiently painful to use something else instead.
    - dsymonds 13y ago
      I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing their programs a little differently, and see that writing code with parametric polymorphism is the only acceptable solution to their problem. But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with.
      - cgag 13y ago
        "But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with." i want to apply a transformation to every element in a collection i want to select the elements from a collection for which some predicate holds true
        redbad 13y ago
        Those are both sub-problems.
        cgag 13y ago
        of every software problem in history
        mseepgood 13y ago
        Use a for loop. Stop thinking in LISP/Haskell/LINQ, start thinking in Go. Go is an imperative programming language. When in Rome do as the Romans do. Look at the code of the standard library to see how it's done.
        pcwalton 13y ago
        It's not because it's unfamiliar that people are objecting; it's because it's suboptimal. Loops are harder to get right (try writing the loop to count down from 100 to 0 inclusive on unsigned ints), and they involve more boilerplate, obscuring the meaning of the code. I don't think generics are an imperative/functional thing so much as an important feature of any statically typed system.

masklinn 13y ago

> A few extra lines for sorting It's not just sorting, it's any parametric polymorphism: generic operations or non-built-in containers (not just in the sense of "array", an atomic ref is also a container) for instance. Go only lets do these in verbose, clunky ways, and losing much of the type safety Go is supposed to provide (what with being a statically typed language) > no-one's trying to claim that the shortest code wins. No one is indeed, so that's an irrelevant strawman.

dsymonds 13y ago
The post I replied to didn't explicitly say what he disliked about sorting in Go, and what "this" means in "When they fix this". I guessed that it was because the Go code is a bit longer. What else could it be? I guess it's a little clunkier, and it's true that writing generic containers in Go isn't so great, but is that sufficient to elicit a reaction of "I'm not touching it with a pole"? Nobody claims it's perfect, but is it really sufficiently horrible to warrant that?
- masklinn 13y ago
  > it's true that writing generic containers in Go isn't so great That's one hell of an understatement. > is it really sufficiently horrible to warrant that? A number of people obviously and repeatedly say that yes, a statically typed language without parametric polymorphism is sufficiently painful to use something else instead.
  - dsymonds 13y ago
    I'm curious what programs people are writing where parametric polymorphism is so crucial. I've written hundreds of thousands of lines of Go code (servers, web apps, data processing, etc.), and there's probably been maybe O(hundreds) of lines of code that were annoying or tedious because of a lack of parametric polymorphism. My suspicion is that what's more likely is that lots of people don't want to consider writing their programs a little differently, and see that writing code with parametric polymorphism is the only acceptable solution to their problem. But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with.
    - cgag 13y ago
      "But maybe there's a whole class of problem (actual problem, not a sub-problem like "I want to implement a container") that I don't come in contact with." i want to apply a transformation to every element in a collection i want to select the elements from a collection for which some predicate holds true
      - redbad 13y ago
        Those are both sub-problems.
        cgag 13y ago
        of every software problem in history
      - mseepgood 13y ago
        Use a for loop. Stop thinking in LISP/Haskell/LINQ, start thinking in Go. Go is an imperative programming language. When in Rome do as the Romans do. Look at the code of the standard library to see how it's done.
        pcwalton 13y ago
        It's not because it's unfamiliar that people are objecting; it's because it's suboptimal. Loops are harder to get right (try writing the loop to count down from 100 to 0 inclusive on unsigned ints), and they involve more boilerplate, obscuring the meaning of the code. I don't think generics are an imperative/functional thing so much as an important feature of any statically typed system.