The problem with slow development tools
The article ”Modern” C++ Lamentations by Aras Pranckeviciusis a wide-ranging rant about the inefficiency of C++ template programming and the degree to which it’s inappropriate for many of the areas where C++ is used. Aras is one of the developers for the Unity game engine
In particular, he highlights the disastrous compilation and execution speeds when using a lot of the STL. Not only that, but the debugging time is extremely slow, due to the inordinate amount of extra symbol information associated with hundreds of thousands of lines of code pulled in to implement relatively simple concepts that are standard in other languages, libraries and runtimes.
On top of it all, even the high-level C++ code isn’t very easy to read, despite the tremendous amount of abstraction.
The optimized version of C++ code has an even worse compilation time, but it has a comparable/reasonable run-time to the C/C++-style version. However, it’s very difficult to debug optimized code, which makes it doubly bad for development. Interactive development is hindered because of long compile times and, when debugging is necessary, most introspection tools don’t work (e.g. reading variables) very well. It’s the rare developer who can make headway debugging optimized code.
He compares versions of an algorithm built using “classic” C/C++ programming vs. STL programming. He then compares to C#, which compiles and runs and debugs very quickly—and is very easy to read, to boot.
The problem with C++ boils down to its approach of making “everything a library”. It’s almost like an exercise in abstraction: since a few generic-programming concepts can be used to build everything in the library rather than the language, that’s what C++ does. It’s almost as if it does it to prove that it can be done. I’m all for removing redundancy in a language, but C++ is far from such a language. It’s almost like the designers don’t use their own language.
He cites Christer Ericson (Twitter)
“Goal of programmers is to ship, on time, on budget. It’s not “to produce code.” IMO most modern C++ proponents 1) overassign importance to source code over 2) compile times, debug[g]ability, cognitive load for new concepts and extra complexity, project needs, etc. 2 is what matters.”
Aras continues discussing the future of C++ and how it is currently used in game companies, for example. These are the companies using C++ the most. Rust is making some inroads, but the area is dominated by C/C++.
Finally, he has some good advice for programmers—for any professional, really—on how to take criticism and turn it into something useful.
“Ignoring literal trolls who complain on the internet “just for the lulz”, [the] majority of complaints do have [an] actual issue or problem behind it. It might be worded poorly, or exaggerated, or whoever is complaining did not think about other possible viewpoints, but there is a valid issue behind the complaint anyway.
“What I do whenever someone complains about thing I’ve worked on, is try to forget about “me” and “work I did”, and get their point of view. What are they trying to solve, and what problems do they run into? The purpose of any software/library/language is to help their users solve the problems they have. It might be a perfect tool at solving their problem, an “ok I guess that will work” one, or a terribly bad one at that.”
As a postscript, the article It is fast or it is wrong by Nikita Tonsky discusses a very similar issue with Clojure vs. ClojureScript.
“What do ClojureScript/Google Closure compilers do for so long? They are wasting your time, that’s what. Of course it’s nobody’s fault, but in the end, this whole solution is simply wrong. We can do the same thing much faster, we have proof of that, we have the means to do it, it just happens that we are not. But we could. If we wanted to. That huge overhead you’re paying, you’re paying it for nothing. You don’t get anything from being on JS, except a 2× performance hit and astronomical build times.”
I find these points interesting because programming is very much about which tools you use and how they help you to turn your work around more quickly. I’m in charge of choosing which languages, libraries and tools we use at Encodo and I’m hyper-aware of the efficiency losses when developers are hindered by their tools or libraries. Being the lead developer of our framework Quino makes me doubly aware of this.
If you have a very slow feedback loop, then you’ll take much longer to get your work done. I remember back in the late 90s/early 2000s, working with C++, where I would have to schedule builds because it took over 30 minutes to rebuild all of my static libraries if I made a low-level change. This was on a project that cross-compiled to Mac and Windows. Instead of working on my project, I spent way too much time massaging PCH files and avoiding making low-level changes so that I could continue testing.
Bad tools that run too slowly are a problem. That’s why you should always be very careful in choosing your languages, libraries and environments. Jumping ship to the “new hotness” very often means that you’re going to have your time wasted by tools that aren’t ready for prime time.