4 ms·

If you truly care about speed you'll have different optimizations for int32 and int64. Depending on who you are working with, the lack of generics is a blessin

by zimbatm 12y ago

If you truly care about speed you'll have different optimizations for int32 and int64. Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once.

Mr_P 12y ago
> If you truly care about speed you'll have different optimizations for int32 and int64. This is exactly why c++ allows template specialization, and if you don't care for hand-optimizing, you can get both implementations almost for free. > Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once. I can't comment on the competency of your coworkers, but I certainly see how Go could be useful in situations without the kind of performance-constraints which demand a language like c++.
masklinn 12y ago
> If you truly care about speed you'll have different optimizations for int32 and int64. I'm pretty sure that's what C++ templates specialisation is for...
loup-vaillant 12y ago
Generics generally simplify code, you know. Plus, generic code tend to make guarantees non-generic code cannot. Picture this function: foo :: (a -> b) -> (b -> c) -> (a -> c) What does it do? As you can see this function takes 2 arguments, which appears to be functions. It also returns a function. The argument and return type of these functions are unknown, so you can't manipulate them. You can just pass them around directly. This puts really tight constraints on your code. So, assuming nothing fancy happens, there is only one correct body of code for this type signature: foo f g = \x -> g (f x) In other words, function composition. --- Generic functions have more guarantees than non-generic functions. Therefore, you are more likely to know what a generic function is actually doing.
- nwmcsween 12y ago
  Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. A better form IMO is restricting the types allowed as it: 1. makes understanding much easier, 2. Doesn't create bloat in the form of n copies for visible symbols.
  - loup-vaillant 12y ago
    > Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. This is backward. A function, polymorphic or otherwise, does not influence code that does not call it. Modulo far-reaching side effects of course. It's when you look at the call site that you have to figure out what this strange `fold` function could possibly be about. I'll grant that polymorphic functions are often more abstract than monomorphic ones. But they are simpler. They are also better at separating concerns. Take `map` and `filter` for instance. They capture common iteration patterns, so you don't have to entangle that pattern with the actual logic of your loop. Without parametric polymorphism, you could not write them (more precisely, you would have to repeat yourself over and over). > A better form IMO is restricting the types allowed as it: 1. makes understanding much easier That's just false. If you restrict the types a function can operate on, you allow the function to do more things to its data. The more you know about its input, the less you know about the function. With parametric polymorphism, you are actually hiding information from the function, preventing it from making whole classes of mistake. Free tests! Parametric polymorphism makes functions that use it simpler (as in, less moving parts). How could that possibly be harder to understand? Please give a concrete example, I don't understand where you're coming from right now. > 2. Doesn't create bloat in the form of n copies for visible symbols. That's an implementation detail, and mostly false anyway. Not every language is C++. Most languages that make use of parametric polymorphism don't duplicate code.
    - nwmcsween 12y ago
      > A function, polymorphic or otherwise, does not influence code that does not call it. Obfuscate does not mean influence, it obfuscates it you now have to follow the rabbit hole to where the type information is (language detail but it is how almost all parametric polymorphism is) which makes reasoning about it a pain. > That's an implementation detail, and mostly false anyway. No it's not 'unbound' parametric polymorphism in a compiled language has to produce symbols for any visible (not internal) function as there would be no way to know what might get called. > Most languages that make use of parametric polymorphism don't duplicate code. Yes any compiled language does how on earth would you call a symbol that took a bool vs a size_t (I recommend you look at how ELF works). On somewhat related note a sufficiently smart compiler could 'deduplicate' common parts of the slow path within a generic function and create calls but that's about all it could do for deduplication without performance hits.
orbifold 12y ago
Which in c++ you can easily do, as you probably know. All you need to do is have an if statement that compares the type parameter of your template to int32 and int64. The good thing is that this kind of optimizations is transparent to the user if the code works. Even Haskell has something similar, with the SPECIALIZE pragma. Although in this case you have to trust the compiler to come up with the optimizations.

by zimbatm 12y ago

Mr_P 12y ago

> If you truly care about speed you'll have different optimizations for int32 and int64. This is exactly why c++ allows template specialization, and if you don't care for hand-optimizing, you can get both implementations almost for free. > Depending on who you are working with, the lack of generics is a blessing. Some developers can't restrain themselves and create over-complex abstractions that are used only once. I can't comment on the competency of your coworkers, but I certainly see how Go could be useful in situations without the kind of performance-constraints which demand a language like c++.

masklinn 12y ago

> If you truly care about speed you'll have different optimizations for int32 and int64. I'm pretty sure that's what C++ templates specialisation is for...

loup-vaillant 12y ago

Generics generally simplify code, you know. Plus, generic code tend to make guarantees non-generic code cannot. Picture this function: foo :: (a -> b) -> (b -> c) -> (a -> c) What does it do? As you can see this function takes 2 arguments, which appears to be functions. It also returns a function. The argument and return type of these functions are unknown, so you can't manipulate them. You can just pass them around directly. This puts really tight constraints on your code. So, assuming nothing fancy happens, there is only one correct body of code for this type signature: foo f g = \x -> g (f x) In other words, function composition. --- Generic functions have more guarantees than non-generic functions. Therefore, you are more likely to know what a generic function is actually doing.

nwmcsween 12y ago
Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. A better form IMO is restricting the types allowed as it: 1. makes understanding much easier, 2. Doesn't create bloat in the form of n copies for visible symbols.
- loup-vaillant 12y ago
  > Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. This is backward. A function, polymorphic or otherwise, does not influence code that does not call it. Modulo far-reaching side effects of course. It's when you look at the call site that you have to figure out what this strange `fold` function could possibly be about. I'll grant that polymorphic functions are often more abstract than monomorphic ones. But they are simpler. They are also better at separating concerns. Take `map` and `filter` for instance. They capture common iteration patterns, so you don't have to entangle that pattern with the actual logic of your loop. Without parametric polymorphism, you could not write them (more precisely, you would have to repeat yourself over and over). > A better form IMO is restricting the types allowed as it: 1. makes understanding much easier That's just false. If you restrict the types a function can operate on, you allow the function to do more things to its data. The more you know about its input, the less you know about the function. With parametric polymorphism, you are actually hiding information from the function, preventing it from making whole classes of mistake. Free tests! Parametric polymorphism makes functions that use it simpler (as in, less moving parts). How could that possibly be harder to understand? Please give a concrete example, I don't understand where you're coming from right now. > 2. Doesn't create bloat in the form of n copies for visible symbols. That's an implementation detail, and mostly false anyway. Not every language is C++. Most languages that make use of parametric polymorphism don't duplicate code.
  - nwmcsween 12y ago
    > A function, polymorphic or otherwise, does not influence code that does not call it. Obfuscate does not mean influence, it obfuscates it you now have to follow the rabbit hole to where the type information is (language detail but it is how almost all parametric polymorphism is) which makes reasoning about it a pain. > That's an implementation detail, and mostly false anyway. No it's not 'unbound' parametric polymorphism in a compiled language has to produce symbols for any visible (not internal) function as there would be no way to know what might get called. > Most languages that make use of parametric polymorphism don't duplicate code. Yes any compiled language does how on earth would you call a symbol that took a bool vs a size_t (I recommend you look at how ELF works). On somewhat related note a sufficiently smart compiler could 'deduplicate' common parts of the slow path within a generic function and create calls but that's about all it could do for deduplication without performance hits.

orbifold 12y ago

Which in c++ you can easily do, as you probably know. All you need to do is have an if statement that compares the type parameter of your template to int32 and int64. The good thing is that this kind of optimizations is transparent to the user if the code works. Even Haskell has something similar, with the SPECIALIZE pragma. Although in this case you have to trust the compiler to come up with the optimizations.