4 ms·

This is library code which most users of the range library will not themselves need to write. Using ranges absolutely leads to shorter and more elegant code. Th

by tomnj 8y ago

This is library code which most users of the range library will not themselves need to write. Using ranges absolutely leads to shorter and more elegant code. The implementation of the library is complicated. Much of what’s likely unfamiliar with this example is the use of C++ “concepts” (a technical term), and is not actually necessary, but is placed there to actually give better error messages to users of the library (without them, template code is basically duck-typed, and can give terrible error messages). I’d argue that the core of that code: the transform followed by the join is actually quite readable. I also wouldn’t at all say C++ is overly academic. It’s an extremely pragmatic community. Yes, the standardization process is slow, but I don’t view, as a C++ user, the issues you mention as serious. To me, there’s nothing wrong with using high quality third party libraries like boost (and Eric’s range v3 library). My biggest frustrations with C++ are the build and packaging stories.

Something1234 8y ago
Boost is not high quality. It massively balloons the compile time, and there's random incompatibilities between minor versions. It's also a hunt to figure out which header I need to include for certain libraries. There's no consistent feeling to the library. My biggest gripe is that it makes vims completion stupid slow by bringing in a large number of headers.
- gumby 8y ago
  Finally! It's not just me. But...I will say some good ideas made it into the standard thanks to a first implementation in boost, though what ended up being standardized is typically much cleaner and more orthogonal. Then again this is how we got the standard containers and so much more standard library goodness -- via Stepanov stepping up and writing the STL. The best way to think of boost as the npm.
- tomnj 8y ago
  > boost is not high quality This is just false.
  - AnimalMuppet 8y ago
    You could be right. But this is not a convincing rebuttal.
- gpderetta 8y ago
  > There's no consistent feeling to the library Well that's because it is really a collection of mostly unrelated libraries by a large number of different authors. There is some general theme (emphasis on value based generic programming in the stl style as opposed to more traditional Oop), but that's about it.
- fermienrico 8y ago
  You're talking about compile time and issues with your IDE. It is unfair to call it "Not high quality". We can think about this from an end-user standpoint that it bloats the IDE and impacts usability. Fine. Your IDE/compile times may be different than others. Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose. Please don't conflate your minor development environment gripes with the excellence of Boost. It is really not fair.
  - humanrebar 8y ago
    Your viewpoint is valid. But so is the viewpoint that one of the major problems with C++ culture is the misconception that developer experience and high quality tooling are afterthoughts and orthogonal to "quality". In this viewpoint, readability in a editor or IDE at least as important as readability in a browser or email.
    - fermienrico 8y ago
      I agree that C++ is a big mess. Complaining about an external third party library that is trying to fix the issues for its compile time and how fast it loads IDE is very obtuse and unfair. Boost is a bandaid. Don't complain about the bandaid, complain about what causes the wound. Overall, I agree with you that C++ has poor user-experience - don't blame Boost for it!
      - int_19h 8y ago
        To be fair, it is very common to hear "well, why don't you just use Boost?" in response to the criticism of the C++ standard library. It may be an external third party library in name, but in practice it has long since became stdlib++ for idiomatic C++, and a testing ground for new libraries to be eventually adopted into the standard.
  - jlarocco 8y ago
    I don't think it's an unfair complaint. Developers interface with the language using compilers and IDEs, and until recently (with libclang getting more popular) that interface has been terrible. In a lot of cases it's still terrible. It's a real inconvenience, and there's no benefit coming with the cost. > Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose. I've used Boost for over a decade now, and IMO "extremely high quality" is a stretch. Some modules are better than others, but there's no getting around the fact that many of them are only necessary because the C++ standard library is so bad.
contravariant 8y ago
I'm not convinced by the argument that it's fine since most people can just use a library someone else wrote. Requiring complex code to do something simple doesn't bode well if you want to try something complex. And when judging a programming a language it's a bit weird to reason from the perspective of someone not writing the code.
- tomnj 8y ago
  Nothing comes for free though. While we can easily write list comprehensions in Haskell or Python, their implementations are complicated. In the case of Haskell and Python, lists and comprehensions are language features, and for C++ ranges, they’re implemented as a library. Both approaches provide building blocks for users to build software and not have to roll their own implementations.
  - marcosdumay 8y ago
    Haskell list comprehensions are a small layer of syntactic sugar over the monadic implementation, that is implemented on a library (that comes with the compiler, but it's still a library). It is entirely dependent on lazynes, first class functions and complex compiler optimizations. But there isn't much specific code for comprehensions there.
btschaegg 8y ago
While I tend to agree with your points overall, I'd like to point out that this part irks me a bit: > and is not actually necessary, but is placed there to actually give better error messages to users of the library That's not the first time I see this kind of reasoning; you can find it all over programming. If the alternative is an API that sucks (and yes, template errors in C++ do suck), picking that alternative is not a very viable option. Another scenario where this often pops up is whenever someone complains about very verbose error handling. If you want to write quality software, you shouldn't just skip that part (in fact I'd say it's the most important part of the code you're writing). In the same vein, there's a talk by Andrei Alexandrescu somewhere (on D), where he points out that probably 0% of the main functions ever written in C or C++ are correct in that they catch everything that can go wrong. Also, since I find that most code should be written in a library style (i.e reusable, well-encapsulated) except if it's explicitly tied to a specific program (say config or cli argument parsing), I also don't find "only library implementers will have to deal with this" is a convincing argument. OTOH, at least, writing in a library style doesn't necessarily imply overly generic code, so that might not be that much of an issue.

by tomnj 8y ago

Something1234 8y ago

Boost is not high quality. It massively balloons the compile time, and there's random incompatibilities between minor versions. It's also a hunt to figure out which header I need to include for certain libraries. There's no consistent feeling to the library. My biggest gripe is that it makes vims completion stupid slow by bringing in a large number of headers.

gumby 8y ago
Finally! It's not just me. But...I will say some good ideas made it into the standard thanks to a first implementation in boost, though what ended up being standardized is typically much cleaner and more orthogonal. Then again this is how we got the standard containers and so much more standard library goodness -- via Stepanov stepping up and writing the STL. The best way to think of boost as the npm.
tomnj 8y ago
> boost is not high quality This is just false.
- AnimalMuppet 8y ago
  You could be right. But this is not a convincing rebuttal.
gpderetta 8y ago
> There's no consistent feeling to the library Well that's because it is really a collection of mostly unrelated libraries by a large number of different authors. There is some general theme (emphasis on value based generic programming in the stl style as opposed to more traditional Oop), but that's about it.
fermienrico 8y ago
You're talking about compile time and issues with your IDE. It is unfair to call it "Not high quality". We can think about this from an end-user standpoint that it bloats the IDE and impacts usability. Fine. Your IDE/compile times may be different than others. Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose. Please don't conflate your minor development environment gripes with the excellence of Boost. It is really not fair.
- humanrebar 8y ago
  Your viewpoint is valid. But so is the viewpoint that one of the major problems with C++ culture is the misconception that developer experience and high quality tooling are afterthoughts and orthogonal to "quality". In this viewpoint, readability in a editor or IDE at least as important as readability in a browser or email.
  - fermienrico 8y ago
    I agree that C++ is a big mess. Complaining about an external third party library that is trying to fix the issues for its compile time and how fast it loads IDE is very obtuse and unfair. Boost is a bandaid. Don't complain about the bandaid, complain about what causes the wound. Overall, I agree with you that C++ has poor user-experience - don't blame Boost for it!
    - int_19h 8y ago
      To be fair, it is very common to hear "well, why don't you just use Boost?" in response to the criticism of the C++ standard library. It may be an external third party library in name, but in practice it has long since became stdlib++ for idiomatic C++, and a testing ground for new libraries to be eventually adopted into the standard.
- jlarocco 8y ago
  I don't think it's an unfair complaint. Developers interface with the language using compilers and IDEs, and until recently (with libclang getting more popular) that interface has been terrible. In a lot of cases it's still terrible. It's a real inconvenience, and there's no benefit coming with the cost. > Boost is extremely high quality in terms of its documentation, algorithms, and readability of the code - which is its core purpose. I've used Boost for over a decade now, and IMO "extremely high quality" is a stretch. Some modules are better than others, but there's no getting around the fact that many of them are only necessary because the C++ standard library is so bad.

contravariant 8y ago

I'm not convinced by the argument that it's fine since most people can just use a library someone else wrote. Requiring complex code to do something simple doesn't bode well if you want to try something complex. And when judging a programming a language it's a bit weird to reason from the perspective of someone not writing the code.

tomnj 8y ago
Nothing comes for free though. While we can easily write list comprehensions in Haskell or Python, their implementations are complicated. In the case of Haskell and Python, lists and comprehensions are language features, and for C++ ranges, they’re implemented as a library. Both approaches provide building blocks for users to build software and not have to roll their own implementations.
- marcosdumay 8y ago
  Haskell list comprehensions are a small layer of syntactic sugar over the monadic implementation, that is implemented on a library (that comes with the compiler, but it's still a library). It is entirely dependent on lazynes, first class functions and complex compiler optimizations. But there isn't much specific code for comprehensions there.

btschaegg 8y ago

While I tend to agree with your points overall, I'd like to point out that this part irks me a bit: > and is not actually necessary, but is placed there to actually give better error messages to users of the library That's not the first time I see this kind of reasoning; you can find it all over programming. If the alternative is an API that sucks (and yes, template errors in C++ do suck), picking that alternative is not a very viable option. Another scenario where this often pops up is whenever someone complains about very verbose error handling. If you want to write quality software, you shouldn't just skip that part (in fact I'd say it's the most important part of the code you're writing). In the same vein, there's a talk by Andrei Alexandrescu somewhere (on D), where he points out that probably 0% of the main functions ever written in C or C++ are correct in that they catch everything that can go wrong. Also, since I find that most code should be written in a library style (i.e reusable, well-encapsulated) except if it's explicitly tied to a specific program (say config or cli argument parsing), I also don't find "only library implementers will have to deal with this" is a convincing argument. OTOH, at least, writing in a library style doesn't necessarily imply overly generic code, so that might not be that much of an issue.