Weak Linked Languages
As I watch LabVIEW build.... and build... and build... it reminds me of why C++ is the wrong direction for computer languages. I stopped getting C/C++ Users Journal a few years ago because each issue was more depressing than the previous. The trends shown in that magazine were toward an ever increasing amount of templating. I don't object to generic programming. I do object to the way that C++ does it. C++ aims for maximum generated code efficiency by trying to include and inline everything. The more the compiler knows during a pass, the better code it can generate. This has two problems. First, C/C++ compilers work on one object file at a time. The only way to give the compiler more information to work with is to put more and more information into each object file (via the #include statement). More information for each object file means slower compile time for the object file. In a source base the size of LabVIEW, that adds up to a ton of time. The second problem is that it couples all of your source files together. If you make a change to the implementation of your "list" class, the implementation of that class is inlined into every single source file, necessitating a rebuild of every single source file. The build/fix/debug cycle becomes 30 minutes for every line of code you change. That's a productivity killer.There is a whole class of languages that doesn't work that way. I call them "weak linked" languages. These languages try to have minimal dependencies between objects. They give up a little in run-time efficiency because they have to discover some things at run-time that C++ programs set at compile time but the programmer productivity tradeoff is huge. Languages like C#, Java, and LabVIEW only make you "compile" the file that you just touched, not the other 5,000 files that may come in contact with the file you touched. Build/fix/debug in LabVIEW is 5 seconds for just about any change.
Beyond compile time, weak linked languages give you some other cool benefits. Notice how in LabVIEW, you can open a heirarchy of 200 VIs, go to any one of them, and hit the Run button and run the thing? A weakly linked language gives you that flexibility. Java has something a bit like it, though it's IMHO inferior :-) Any class in Java can have a "main()" function. From the command line, you can just start up the program by calling any classes main(), not just the one big entry point that is supposed to start the program. The JUnit framework takes advantage of that benefit to make a nice unit test system.
Just as programmers gradually gave up assembly language to get more productivity (and more maintainable code) in spite of a slight loss in run time efficiency, languages like LabVIEW are the way programming will be done in the future. The folks around me who program in G already know that.
posted by Joel @ 8:19 AM
4 Comments:
Are you suggesting that LabVIEW be re-written in <pick your favorite weakly linked language>? Or just stating, that you wish it were?
Also the book by John Lakos describes ways to alleviate some of the slow compile and linking problems you are describing for C++ http://tinyurl.com/9v8fp
This comment has been removed by a blog administrator.
I'm not a big fan of "rewriting" software. "refactoring" yes, "rewriting", no. See a good Joel on Software rant on this topic. I would say that, if we were writing LabVIEW from scratch (giving me that responsibility is a big stretch right there), I'd save C++ for leaf parts rather than doing the entire architecture in C/C++. The newer languages just have less coupling. Heck, we are writing more and more of the LabVIEW product in G. So, in a sense, we are already refactoring LabVIEW into our favorite weakly linked language...
I'm familiar with the Lakos book and he has great recipies on how to make things better. Unfortunately, the fact that he had to write the book at all is an example of the failures of C++ for architectural software. It is much harder to write code his way (the "right way"). Thus, coders just don't do it. The pImpl paradigm is a great way to decouple modules. Too bad it's such a PITA to write it and maintain it when languages like Java and C# do it as the standard paradigm. Then, you get the STL in there and it all goes to heck. You can't reliably pass std::string across a module boundary unless all modules use the identical source code of the STL... Argh, I'm on a rant. When I calm down, I'll make a more reasoned article about it :-)
-Joel
You make some really good points, and being a C++ fan I am not sure if I agree or disagree with you.
Certainly C++ has its weaknesses, but I think switching to another language to alleviate the weakness in C++ is tricky. I fear we would only be trading one set of weaknesses for another.
I look forward to your (non-ranting :) ) article.
Post a Comment
<< Home