5 ms·

Here’s a few of my personal favorite insane nostalgics: * Donald Knuth: http://tex.loria.fr/litte/knuth-interview http://tex.loria.fr/litte/knuth-interview *

Here’s a few of my personal favorite insane nostalgics: * Donald Knuth: http://tex.loria.fr/litte/knuth-interview http://tex.loria.fr/litte/knuth-interview * Linus Torvalds: http://harmful.cat-v.org/software/c++/linus http://harmful.cat-v.org/software/c++/linus * Martin Sústrik: http://250bpm.com/blog:4 http://250bpm.com/blog:4

getcrunk 9y ago
I wish I could give you gold
bb88 9y ago
Martin's take is really good, it's a really well thought through blog post.
- blub 9y ago
  No it's not, they confuse "undefined behavior" with "hard to analyse behavior" for starters. Exceptions are not UB, but the control flow is totally not obvious. If I were to start a project today, I'd rely heavily on optional and result types and use exceptions only for serious errors, when it makes sense to unwind ans start from a clean slate.
- jensa1948 9y ago
  I don't think it is a good blog post. He first criticises exception handling as undefined behavior which it is certainly not, and then criticises exception handling in general because it decouples error raising from error handling. This is whole point of exception handling because they should be used for non-local errors. Most of the "errors" handled in Martin's projects ZeroMQ and Nanomsg (which are both great libraries btw!) should not be handled as exceptions, as they are not unexpected values but rather states that have to be handled. Here, he uses the wrong tool for the job and criticises the tool. He then criticises exceptions thrown in constructors and favors a init-function style. I never had any problem with this because I follow the rule that there shouldn't be much code in the constructor. The one and only task of a constructor is to establish the object's invariant. If that is not possible, then the object is not usable and the caller needs to react and shall not use the object. In the second series, he first compares apples (intrusive containers) and oranges (non-intrusive containers), and then argues that the language forces him to design his software that way. Basically he argues that encapsulation makes it impossible in his case to write efficient code, and that you have to sacrifice it for performance. However, with C++, you can extract the property of being an object in an intrusive list into a re-usable component, e.g. a mix-in, and then use your intrusive list with all other types. I can't do this in C in a type-safe manner, or I have to modify the structs to contain pointers, but why should they have anything to do with a container at all? Besides that, I think that Martin is a greate programmer who did an amazing job with ZeroMQ. But I have the impression that he is wrong in this case.
pjmlp 9y ago
That same Linus is using Qt nowadays...
- ori_b 9y ago
  And the core of his QT program is still written in C.
  - pjmlp 9y ago
    For someone that was so religiously against C++, he should have kept using Gtk+.
    - coldtea 9y ago
      He wasn't religiously against C++, just pragmatically.
- Valmar 9y ago
  Qt isn't quite the same as vanilla C++, however.
- bb88 9y ago
  He is, but insists that all of the business logic remains in "sane" c files. https://news.ycombinator.com/item?id=16489944 https://news.ycombinator.com/item?id=16489944
oblio 9y ago
Dude, that's a Knuth article from 1993. I don't really like C++ and I haven't been forced to use it (with C and C++ you are basically forced to use them, few people use them for greenfield projects willingly, same for JavaScript; this of course doesn't apply for people who are already C/C++/JavaScript programmers), but from everything I've seen about modern C++ they are moving to a more consistent programming style. Criticizing C++ in 2018 with arguments from back in 1993 feels dishonest.
- alxlaz 9y ago
  Knuth's arguments still hold though: "The problem that I have with them today is that... C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste. But each user of C++ has a favorite subset, and that's fine." In fact, they do so even better than they did back then. E.g. I eagerly anticipated C++11, but virtually every codebase that's older than three or four years and not a hobby project is now a mixture of modules that use C++11 features like unique_ptr and modules that don't. Debugging code without smart pointer semantics sucked, but debugging code that has both smart pointer semantics and raw pointers sucks even harder. There's a huge chasm between how a language is standardized and how it's used in real life, in non-trivial projects that have to be maintained for years, or even decades.
  - 72deluxe 9y ago
    I am currently on a team maintaining a giant codebase and migrating to C++11 (and beyond) for a new compiler. We do not have issues with the deprecation of auto_ptr, the use of raw pointers or general debugging COM problems. The code base is 20 years old and we do not complain to debug it. Debugging pointers seems a poor reason to criticize an entire language! C++ may be complicated but the English language is also complicated; just because people tend to use a smaller vocabulary than others doesn't make the language irrelevant or worthless. Looking at how English has been used to create a raft of rich and diverse poetry, plays, prose and literature in general, the same should be applied to C++ because the unique use of it in a variety of varying circumstances surely is its beauty.

getcrunk 9y ago

I wish I could give you gold

bb88 9y ago

Martin's take is really good, it's a really well thought through blog post.

blub 9y ago
No it's not, they confuse "undefined behavior" with "hard to analyse behavior" for starters. Exceptions are not UB, but the control flow is totally not obvious. If I were to start a project today, I'd rely heavily on optional and result types and use exceptions only for serious errors, when it makes sense to unwind ans start from a clean slate.
jensa1948 9y ago
I don't think it is a good blog post. He first criticises exception handling as undefined behavior which it is certainly not, and then criticises exception handling in general because it decouples error raising from error handling. This is whole point of exception handling because they should be used for non-local errors. Most of the "errors" handled in Martin's projects ZeroMQ and Nanomsg (which are both great libraries btw!) should not be handled as exceptions, as they are not unexpected values but rather states that have to be handled. Here, he uses the wrong tool for the job and criticises the tool. He then criticises exceptions thrown in constructors and favors a init-function style. I never had any problem with this because I follow the rule that there shouldn't be much code in the constructor. The one and only task of a constructor is to establish the object's invariant. If that is not possible, then the object is not usable and the caller needs to react and shall not use the object. In the second series, he first compares apples (intrusive containers) and oranges (non-intrusive containers), and then argues that the language forces him to design his software that way. Basically he argues that encapsulation makes it impossible in his case to write efficient code, and that you have to sacrifice it for performance. However, with C++, you can extract the property of being an object in an intrusive list into a re-usable component, e.g. a mix-in, and then use your intrusive list with all other types. I can't do this in C in a type-safe manner, or I have to modify the structs to contain pointers, but why should they have anything to do with a container at all? Besides that, I think that Martin is a greate programmer who did an amazing job with ZeroMQ. But I have the impression that he is wrong in this case.

pjmlp 9y ago

That same Linus is using Qt nowadays...

ori_b 9y ago
And the core of his QT program is still written in C.
- pjmlp 9y ago
  For someone that was so religiously against C++, he should have kept using Gtk+.
  - coldtea 9y ago
    He wasn't religiously against C++, just pragmatically.
Valmar 9y ago
Qt isn't quite the same as vanilla C++, however.
bb88 9y ago
He is, but insists that all of the business logic remains in "sane" c files. https://news.ycombinator.com/item?id=16489944 https://news.ycombinator.com/item?id=16489944

oblio 9y ago

Dude, that's a Knuth article from 1993. I don't really like C++ and I haven't been forced to use it (with C and C++ you are basically forced to use them, few people use them for greenfield projects willingly, same for JavaScript; this of course doesn't apply for people who are already C/C++/JavaScript programmers), but from everything I've seen about modern C++ they are moving to a more consistent programming style. Criticizing C++ in 2018 with arguments from back in 1993 feels dishonest.

alxlaz 9y ago
Knuth's arguments still hold though: "The problem that I have with them today is that... C++ is too complicated. At the moment, it's impossible for me to write portable code that I believe would work on lots of different systems, unless I avoid all exotic features. Whenever the C++ language designers had two competing ideas as to how they should solve some problem, they said "OK, we'll do them both". So the language is too baroque for my taste. But each user of C++ has a favorite subset, and that's fine." In fact, they do so even better than they did back then. E.g. I eagerly anticipated C++11, but virtually every codebase that's older than three or four years and not a hobby project is now a mixture of modules that use C++11 features like unique_ptr and modules that don't. Debugging code without smart pointer semantics sucked, but debugging code that has both smart pointer semantics and raw pointers sucks even harder. There's a huge chasm between how a language is standardized and how it's used in real life, in non-trivial projects that have to be maintained for years, or even decades.
- 72deluxe 9y ago
  I am currently on a team maintaining a giant codebase and migrating to C++11 (and beyond) for a new compiler. We do not have issues with the deprecation of auto_ptr, the use of raw pointers or general debugging COM problems. The code base is 20 years old and we do not complain to debug it. Debugging pointers seems a poor reason to criticize an entire language! C++ may be complicated but the English language is also complicated; just because people tend to use a smaller vocabulary than others doesn't make the language irrelevant or worthless. Looking at how English has been used to create a raft of rich and diverse poetry, plays, prose and literature in general, the same should be applied to C++ because the unique use of it in a variety of varying circumstances surely is its beauty.