3 ms·

More FUD and rationalizations from GhettoLang! > do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Easy I want "slow

by p0nce 12y ago

More FUD and rationalizations from GhettoLang! > do you want slow programmers, slow compilers and bloated binaries, or slow execution times? Easy I want "slow compilers and bloated binaries". In my experience "bloated binaries" in the real world aren't as bad as one would think, since instruction cache problems only appear when your working set is huge, not when your total binary size is huge. Equating big binaries with slowness is simply misleading. What's next, increased download times? > The generic structures are less useful than a concrete one. Without generics you can't separate algorithms from data structures so everything is much less useful. If the members names are worse, sub-type then rename symbols. > Generic structures can be less optimized than a concrete solution. False. That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template. And type erasure is not a solution, it prevents inlining, constant folding and hoisting. Eg: In C++ std::vector<MyObject>::operator[] has 1 indirection, while using a generic C void* container would have 2. Guess which one is faster? > Generic algorithms can be less optimized than a concrete solution. sigh Also wrong since generics do not prevent specialization if needed. See: static if in D, template specialization in C++.

masklinn 12y ago
> In my experience "bloated binaries" in the real world aren't as bad as one would think, since instruction cache problems only appear when your working set is huge, not when your total binary size is huge. The "bloated binaries" part is especially odd given the state of the Go compiler's optimisations (or lack thereof): $ cat >| test.go package main func main() {} ^C $ go build test.go $ wc -c test 467008 test $ cat >| test.go package main import "fmt" func main() { fmt.Println("Hello, World!"); } ^C $ go build test.go $ wc -c test 1806192 test
egonelbre 12y ago
> Without generics you can't separate algorithms from data structures so everything is much less useful. Generics is not the only way to separate data and algorithms. I agree that it is possible to sub-type/embed and rename - although looking at generic code, I rarely see that happen. > That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template. When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case.
- p0nce 12y ago
  > Generics is not the only way to separate data and algorithms. Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"? > When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case. I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions.
  - egonelbre 12y ago
    > Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"? The one I mainly meant was interfaces. Of course there are also DSLs and code generation. > I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions. I mentioned that in the summary. It's about tradeoffs. Even if all the cons/pros are listed people could still come to different conclusions, because people value different things. And there's nothing wrong about it. The amount you need to reimplement depends on the amount of available third-party packages - the more good packages there are the less you need to build those custom data structures.

by p0nce 12y ago

masklinn 12y ago

> In my experience "bloated binaries" in the real world aren't as bad as one would think, since instruction cache problems only appear when your working set is huge, not when your total binary size is huge. The "bloated binaries" part is especially odd given the state of the Go compiler's optimisations (or lack thereof): $ cat >| test.go package main func main() {} ^C $ go build test.go $ wc -c test 467008 test $ cat >| test.go package main import "fmt" func main() { fmt.Println("Hello, World!"); } ^C $ go build test.go $ wc -c test 1806192 test

egonelbre 12y ago

> Without generics you can't separate algorithms from data structures so everything is much less useful. Generics is not the only way to separate data and algorithms. I agree that it is possible to sub-type/embed and rename - although looking at generic code, I rarely see that happen. > That "concrete solution" not only has to be written, but it will also perform identically to an instantiated template. When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case.

p0nce 12y ago
> Generics is not the only way to separate data and algorithms. Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"? > When you know where exactly the code will be run, it can be possible to create a better package taking into account the context where it will be run. By concrete, I mean a package in a real-world problem. Basically, abstract things are harder to optimize for a particular case. I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions.
- egonelbre 12y ago
  > Do you see any way other than the 3 ones discussed in the OP article under the label "Generics"? The one I mainly meant was interfaces. Of course there are also DSLs and code generation. > I could agree with that if time wasn't limited, but imho building custom data structure/algorithms for each problem will precisely leave less time to optimize for performance since reaching a working state first will be longer without reusable abstractions. I mentioned that in the summary. It's about tradeoffs. Even if all the cons/pros are listed people could still come to different conclusions, because people value different things. And there's nothing wrong about it. The amount you need to reimplement depends on the amount of available third-party packages - the more good packages there are the less you need to build those custom data structures.