6 ms·

> "Processor", "Context", "Box", "Request" There are a lot of interfaces in the existing library that one could consider quite abstract as well. Reader? Writer

> "Processor", "Context", "Box", "Request" There are a lot of interfaces in the existing library that one could consider quite abstract as well. Reader? Writer? error? Another thing worth noting is that many/most C++ codebases manage to avoid the type of generic proliferation you're talking about.

mike_hearn 8y ago
I'm not sure C++ is a great example of a language that avoids generics abuse. The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers. Java is actually a much better example of where generics are used rarely and well. Containers are parameterised by exactly one thing - the type of what they contain. You don't parameterise them with different allocation strategies or comparators. Type inference means generics are often automatic, but still catch mistakes for you. And whilst nothing stops people making bad abstractions in any language, the standard library sets a pretty good example by and large. That said, Kotlin's generics are better still and probably the best implementation I know of.
- grandmczeb 8y ago
  > The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers The main reasons template errors suck so much in C++ are 1) lack of a proper mechanism to constrain instantiations (hopefully addressed by Concepts) and 2) The general mess that is function overloading and automatic type conversions. For example, the classic "template hell" error message people usually encounter when starting to use C++ is failing to properly overload operator<< (example here[1]). That error message could easily be as simple as "No `operator<<` for class C", but instead the compiler needs to inform the user of every possible overload match, every possible type conversions that could cause a match, and templates that could have matched but can't be instantiated along with a reason for the failure. Of course it doesn't help that std::ostream is absurdly abstract, but it's really just making a bad problem worse rather than the fundamental root of the problem [1] https://godbolt.org/z/XveitP https://godbolt.org/z/XveitP
- oihoaihsfoiahsf 8y ago
  I think it's 100% ok for a big utility library like boost or std to have complicated internals to support a variety of use cases. The go standard library likewise is big and complicated (although perhaps not quite as). My main concern is that user code can be written simply. And to be clear, I'm not holding up C++ as an example of a great language. In fact, I'm kind of looking at it as a worst-case scenario. I'm only saying that most C++ programs I've been exposed to are relatively free of creeping genericity.
- naasking 8y ago
  > The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers. The reason STL errors are so convoluted is because the C++ template language is Turing complete.
  - jcelerier 8y ago
    no, it's because every function is implemented with a dozen helper function so compiler error stack traces have to show all the intermediate, generally return-only, helper functions
    - pjmlp 8y ago
      True if we are speaking about C++11 and earlier. With C++14 onwards, it is a matter of developers actually making use of static_assert, constexpr if and enable_if. Not as comfortable as just using concepts, but they get the job done.
    - naasking 8y ago
      > no, it's because every function is implemented with a dozen helper function Which are needed and/or allowed for reuse because the template language is Turing complete. More restrictive type-level languages have better error messages because the compiler either understands what you're intending to do or you're limited in the things you can express, full stop.

mike_hearn 8y ago

I'm not sure C++ is a great example of a language that avoids generics abuse. The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers. Java is actually a much better example of where generics are used rarely and well. Containers are parameterised by exactly one thing - the type of what they contain. You don't parameterise them with different allocation strategies or comparators. Type inference means generics are often automatic, but still catch mistakes for you. And whilst nothing stops people making bad abstractions in any language, the standard library sets a pretty good example by and large. That said, Kotlin's generics are better still and probably the best implementation I know of.

grandmczeb 8y ago
> The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers The main reasons template errors suck so much in C++ are 1) lack of a proper mechanism to constrain instantiations (hopefully addressed by Concepts) and 2) The general mess that is function overloading and automatic type conversions. For example, the classic "template hell" error message people usually encounter when starting to use C++ is failing to properly overload operator<< (example here[1]). That error message could easily be as simple as "No `operator<<` for class C", but instead the compiler needs to inform the user of every possible overload match, every possible type conversions that could cause a match, and templates that could have matched but can't be instantiated along with a reason for the failure. Of course it doesn't help that std::ostream is absurdly abstract, but it's really just making a bad problem worse rather than the fundamental root of the problem [1] https://godbolt.org/z/XveitP https://godbolt.org/z/XveitP
oihoaihsfoiahsf 8y ago
I think it's 100% ok for a big utility library like boost or std to have complicated internals to support a variety of use cases. The go standard library likewise is big and complicated (although perhaps not quite as). My main concern is that user code can be written simply. And to be clear, I'm not holding up C++ as an example of a great language. In fact, I'm kind of looking at it as a worst-case scenario. I'm only saying that most C++ programs I've been exposed to are relatively free of creeping genericity.
naasking 8y ago
> The reason STL errors are so convoluted is largely due to the unintuitive and complicated way they use generics to support obscure features like changing the allocator used by containers. The reason STL errors are so convoluted is because the C++ template language is Turing complete.
- jcelerier 8y ago
  no, it's because every function is implemented with a dozen helper function so compiler error stack traces have to show all the intermediate, generally return-only, helper functions
  - pjmlp 8y ago
    True if we are speaking about C++11 and earlier. With C++14 onwards, it is a matter of developers actually making use of static_assert, constexpr if and enable_if. Not as comfortable as just using concepts, but they get the job done.
  - naasking 8y ago
    > no, it's because every function is implemented with a dozen helper function Which are needed and/or allowed for reuse because the template language is Turing complete. More restrictive type-level languages have better error messages because the compiler either understands what you're intending to do or you're limited in the things you can express, full stop.