Follow Up Arggggg!
Adrian Sutton
There’s been a few comments to my rant on choosing the right language for the task that I wanted to comment on.
Firstly the simple one from hammet:
Dude, you can say you hate C#, not .Net. .Net is not a language.
No, I definitely hate .Net. I still can’t tell you what went wrong with it or where to point the blame but my short spell of .Net programming rates as my most hated moments in computing. I have no particular problem with C#, it’s a language that’s very close to Java has some nice ideas, leaves out some nice ideas and makes some good and some bad design decisions – so be it. My beef was definitely with .Net because it didn’t matter if I used ASP.Net, VB.Net or C# nothing went right. A good deal of the blame definitely lies in my not knowing the language or the environment but I definitely shouldn’t have been able to waste a full two weeks getting obscure error messages that even intensive Googling and asking experts couldn’t sort out. I suspect something went bad in my Visual Studio.Net install which then broke something in my .Net framework install or in Windows itself. .Net has never worked for me since, nor has my IIS installation been all that rock solid. Oh well, maybe next time I have a need to use .Net it will go better.
Secondly to Manish’ comment:
I’m one of the guys who linked to that article, so you can give up reading my blog :P :)
I’m pretty sure it was actually Manish’s weblog that I found the link on but I can’t stop reading his blog as I never actually read it in the first place. I picked up his entry from java.net. Manish, your article on C++ vs Java mutability was very good actually. It’s a good example of comparing the way two languages work in a particular area in order to see the advantages and disadvantages of both. In particular it stops short of trying to convince the author that they should use one particular language all the time.
Finally, to Tahir’s comments:
Thanks for the criticism. I just updated the content of the article to include a large section called “C++ Goodies” that takes about 50% of the article’s size. The ranting has been pushed toward the end of the article. Hope that the article would be more useful now.
It’s a better article now but my reply still stands if for no other reason than because of the title. Why I Program in C++ implies that you only program in C++ which is clearly a bad idea because different tasks are best suited to different languages. The features you point out in the C++ Goodies section are interesting to note, but don’t include any real justification for having them in a language. As a reader (who’s attitude is basically gimme gimme gimme, me me me) I’d want to know how often such constructs impact on the design of software, what impact they have on developer productivity while writing the code, what impact they have on the resource utilisation of the program and particularly what impact they have on maintainability of the software.
For instance, perl has a whole bunch of really cool ways of doing things, but it is a language that is widely criticised for being hard to read and the claims, while exaggerated, are not without merit. Adding features to a programming language requires every developer of the language to learn that feature, it’s syntax and particularly it’s hidden “gotchas” because there will come a day when they have to maintain someone else’s code which uses those language features. At that point, if the developer doesn’t fully understand the language feature they are likely to introduce bugs. So there’s a trade-off to be made between ease of initial development, ease of maintenance and ease of learning the language. Where the ideal point in that trade-off is will depend on a large number of factors, including personal preference.
It’s interesting to note that some of what you called C++ Goodies I would have called C++ limitations or perhaps even C++ flaws. To point out a couple: Variables with Value Semantics – what’s the most common area of mistakes in C/C++ program? Pointers. For the record pass by value in Java is done with the clone() method. Admittedly it would probably be nice to have a default implementation of clone that performed a basic memory copy of the object or similar but personally I would prefer not to have to perform more work to get pass by value than to avoid segfaults. You disagree and that’s healthy.
I’d also pull out Automatic Storage as an obvious point of great dispute. Google should be able to provide enough heated discussion about whether the programmer should have to handle memory management or not. Personally I think it depends on the task at hand.
I too have programmed in several of the languages you mentioned but things like XSLT or Prolog don’t compete with C++ in functionality, so there is no point comparing them.
I seriously have to disagree with this. XSLT is a turing complete language and is thus capable of expressing any algorithm. You would be absolutely amazed what you can pull off with XSLT. Have a play with EditLive! for XML from my employer Ephox when it’s released in the next week or two. It uses XSLT to handle key parts of it’s logic and it was definitely the best choice of language for the task. We actually compile the XSLT into Java bytecode with Apache Xalan XSLTC.
Prolog is a complete logic programming language which again is turing complete. It’s a very powerful language and you’ll find that it’s extremely popular in AI circles because it’s so much more powerful than C++ for many AI applications. The fact that you consider it a plus that C++ can act like a logic programming language speaks volumes for the usefulness of prolog.
I would be grateful if you highlighted the incorrect statements.
I definitely want to avoid getting into a point by point argument over this issue (though higher level discussions are definitely encouraged), but here’s a couple of things that really stuck out at me:
The strength of C++ shows in its multi-paradigm programming capabilities. More specifically, you can do Imperative, Object Oriented, Functional, Logic, and Generic Programming in C++.
This is very definitely false. C++ is a hybrid Object Oriented, Imperative language. It is not a functional language and it is not a logic based language. I’m not familiar enough with generic programming to really comment on that, but if it is just templates as your description of it implies, that’s Object Oriented programming or if not, a specific attribute of typed languages. C++ can mimic the behaviour of functional languages just like any other language can (including logic, pure object oriented and imperative language) however just because you can fit a square peg into a round hole, doesn’t make the square peg round. In fact most of the text books I have which discuss functional or logic programming languages specifically contrast them to C.
Even if you were to accept that the C++ imitation of functional programming or logic programming was the “real thing”, every other imperative (or hybrid OO/imperative) language would be able to perform the same imitation. In particular I’ve written logic programming and functional programming libraries in Java as part of my university studies.
A nice feature of C++ is static linkage. If you are not sure that your clients would have all the libraries that you used to develop your application, you can link your application with them statically. This would afford wider distributability at the cost of larger program size. With Java, this is not an option.
This is at least misleading if not false. C++ uses static linkage to embed libraries that are required with the application, Java uses a jar file. If you want to make sure your clients have a particular library, you can include it in your applications jar file and it will be available (obviously subject to the same licensing restrictions as with C++). Sadly, this also suffers from a similar problem to C++’s ABI problem in that if you wind up with two versions on the classpath you can get conflicts. Java provides a solution to this in terms of class loaders, but they can sometimes cause more problems than they solve. Dependency management and avoiding conflicts appears to be an ongoing area of research.
Finally, just for the record I disagree with your Rants section. Google should have a few million disputing views along with a few million agreeing views.
Interesting stuff, thanks.