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.
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.
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?
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.
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.
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
I don't think generics are an imperative/functional thing so much as an important feature of any statically typed system.
Think about the sorting example I wrote earlier: https://news.ycombinator.com/item?id=7080562 If you were writing it in Java, is sort.Sort an interface or an abstract base class? Well, you can only "extend" one class (single inheritance only), so you would probably want Sort to be a Java interface. That means that you would always have to implement all three functions, not just one as I did, since Java interfaces cannot have default implementations. The comments indicate that most posters didn't even consider the idea that you could reuse the StringSlice functions. That method of easy composition simply doesn't exist in Java.
In general, generics get used a lot as a band-aid to avoid multiple inheritance in C++ and Java. You can't (or shouldn't, in C++) have your Foo inherit from both a (non-abstract) Bar and Baz. But you can certainly template on them. In C++, this kind of thing is called "traits" and Alexandrescu wrote a whole book about it. It's also why std::string is actually std::basic_string<char, std::char_traits<char>, std::allocator<char> >. In Go, you don't need all this... you just implement as many interfaces as you like and you're done.
So the Java and C++ programmers need time and an open mind to get up to speed. There's also another contingent of programmers that really just wants Go to be like their favorite strongly-typed functional programming language (Haskell, Scheme, SML, etc.) I like to think that these people will eventually give up. After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker. People have sort of accepted that that is not what Lisp is about and that there are other languages that will give you that if you want. Hopefully much the same will happen for Golang.
There are a few of optional type checkers for Lisp to choose from.
There is a difference in Go, and that is you don't need to explicitly implement the interface. That is, you don't need to declare that you do. But I am unconvinced that is so different from implementing interfaces in C++ and Java that C++ and Java programmers "need time and an open mind" to understand Go idioms.
Don't get me wrong: I think Go is a neat language and culture. I like many aspects of it. And I know the stance the designers of Go have on generics: they would like to do them, but they can't think of a design that they like. And they don't consider it that important, so they've bunted on it. They may do them in the future. But I find it strange when people who are not the designers of the language argue against having them, in any form.
Actually, that's not a band-aid. It allows strings to be generic over allocators without suffering the performance penalty of a virtual call on every malloc and free. Go's solution would be to just take the penalty of a virtual call (as interfaces require virtual calls everywhere) and try to make it up with devirtualization optimizations and/or inlining.
> After all, nobody comes into every Lisp thread demanding that Lisp grow a type-checker.
That's because making a workable type system for Lisp is a very hard problem. By contrast, generics are well known at this point.
However, compile-time polymorphism is a mixed bag because of how it tends to blow out the icache by generating many copies of similar code. Java does away with it completely, and nobody seems to be protesting. The Linux kernel is written in C, and nobody seems to be protesting that the lack of compile-time polymorphism makes his/her job impossible. Clearly, the decision as to whether to include compile-time polymorphism in a language is something reasonable people can disagree about.
With regard to a type system for Lisp: it's been done before. Check out Qi.
The most common simple example is reasoning about the following pair of functions
f :: a -> a g :: Int -> Int
g a = 3
f a = a g a = a * 2
g a = if (a == 0) then 1 else a * g (a - 1)
---
So we can take it up a notch. Consider Functors in Haskell. In order to avoid the full generality, let's just say Functor is the container interface and types like [], Set, and Map instantiate it. This gives them the function
fmap :: (a -> b) -> f a -> f b
fmap :: (a -> b) -> [a] -> [b]
fmap :: (a -> b) -> Set a -> Set b
fmap :: (a -> b) -> Map k a -> Map k b -- for some key type k
Furthermore, since every mention of `a` vanishes in the result of the function we know that each value in the input container must either be transformed by the input function or dropped.
-- a specific example, not a general function
fmap f [a, b, c] = [f a, f b, f b]
notFmap :: (Int -> Char) -> [Int] -> [Char]
notFmap f [n1, n2, n3] = [f (n1 + 2), head (show n2), chr n3] ++ "hello world!"
fmap g (fmap f x) == fmap (g . f) x
fmap id x == id x
fmap f [] = []
fmap f (x:xs) = f x : fmap f xs
The take away is that while you can definitely write something that "maps over containers" without using parametric polymorphism, you have a harder time taking advantage of parametricity to have the types provide guarantees about the safe behavior of functions. Types (and in particular type inference) can sometimes make things more expressive, but their primary power lies in making things easier to understand and reason about.
func<T> id(t T) T {
switch t := T.(type) {
case int: return t + 1;
default: return t;
}
}
[1]: http://how-bazaar.blogspot.co.nz/2013/07/stunned-by-go.html
what :: Typeable a => a -> a
what :: (a -> TypeRep) -> a -> a
Suffice to say that the degree of guarantee breaking that this kind of code invites makes Typeable a very specialized library that's almost never recommended without a "unless you really know what you're doing" kind of warning.
I'm not sure why you bring this up - nearly every language that enables reflection lets you do this, including Haskell[0].
No decidable static type system can ensure correct semantics for all use cases, including even badly written code[1].
[0] And you don't even need reflection to do this, per se; it just makes it more convenient.
[1] One could design a static type system that did, but it would be undecidable.
You can always get around things, but languages that make a strong commitment to keeping reasoning as a priority are qualitatively different from those that do not.
fmap _ _ = []
In fact, it is one of the fundamental cornerstones of internal DSLs
perhaps odd, because i come from a crappily-typed PHP background. but if PHP teaches you anything, it's that you can accomplish just about anything with arrays (maps/slices).