Wednesday, July 27, 2005
How's C++ ?
C++ is not doing so well. It's falling behind for Windows development, and that's enough to say it's not doing so well. It is suffering from excessive stability (!) as requested by ANSI/ISO standards. It is suffering from not being a single product (like Delphi or VB) just like Unix was suffering years ago, until Linux came by. It is also suffering from lack of tools, partially because of its complex grammar, partially because nobody is willing to invest too much time / money on a shrinking market.
C++ is suffering because a standard library came too late in a balkanized world full of custom implementation of (e.g.) String buried down into large frameworks (e.g. MFC) leading to all kind of integration troubles.
C++ is also suffering because too many programmers didn't invest the necessary time to become good C++ programmers. They are not using smart pointers, RAII, exceptions, the standard algorithms and containers, they are not really using OOP / OOD, they never really grew outside C. Therefore, productivity is low and more than a few managers promptly considered alternative (easier) languages.
C++ is also slowly growing in other communities, first and foremost in embedded programming. However, here is meeting a strong resistance from the old generation of die-hard "assembly and just a little C" programmers.
Change is always met with resistance, and resistance is not necessarily bad. If your target platform is a 8 bit processor with 2 KB or RAM and a whoopee 8 KB of ROM, you may not want C++. Better yet: you may not want abstraction at all. You may enjoy the power of what I call perfect knowledge of global state. You know that at a certain point you can reuse a location (maybe a few bits only) because it will be overwritten a few instructions later. You know you don't have to calculate a specific value because a previous portion has "accidentally" left it on a specific register. And so on. Been there, done that :-).
There are, of course, serious scalability problems with the notion of perfect knowledge of global state and in general with the lack of abstraction. In many cases, the few bytes you save and the few clock cycles you save have little or no economic sense. Sure, you have to factor in development time, lost opportunities due to longer time-to-market, and all those money stuff that the true nerd doesn't want to hear about.
Very recently, a customer told me that an outsourced (actually offshored) product based on old 8-bits technology and entirely programmed in assembly could be manufactured at a lower cost here, using ARM processors and C/C++. That's very common indeed. Most often, conservatism is not based on a careful economic and risk analysis, but on pride and prejudice (sorry for the trivial pun :-).
Anyway, considering that several "embedded systems" are now (necessarily) equipped with powerful processors and considerable memory, there are very little (or no) sound technical arguments against C++, and many technical arguments to use C++, because when your application grows, perfect knowledge of global state is a risky business. As usual, the hardest step will be a real transition to OOP, and that will take some time. UML is still lagging in embedded programming, even more than in other fields (this is pretty obvious given that abstraction is not considered valuable).
Sideways notes: saving memory does not necessarily means tweaking bits (although tweaking bits is easy). A well-known approach (well, maybe not so well-known :-) is to create a small custom language for the problem at hand, write a compact interpreter for the language, and then store the "program" in this custom language. This is a very old technique, used for instance to move Zork to the "personal computer" in the eighties: see How to Fit a Large Program Into a Small Machine by Marc S. Blank / S. W. Galley, Creative Computing, July 1980.
A few readers may also be interested in a simple pattern language to save memory:
Proceedings of the Memory Preservation Society - Patterns for managing limited memory by James Noble and Charles Weir.
C++ is suffering because a standard library came too late in a balkanized world full of custom implementation of (e.g.) String buried down into large frameworks (e.g. MFC) leading to all kind of integration troubles.
C++ is also suffering because too many programmers didn't invest the necessary time to become good C++ programmers. They are not using smart pointers, RAII, exceptions, the standard algorithms and containers, they are not really using OOP / OOD, they never really grew outside C. Therefore, productivity is low and more than a few managers promptly considered alternative (easier) languages.
C++ is also slowly growing in other communities, first and foremost in embedded programming. However, here is meeting a strong resistance from the old generation of die-hard "assembly and just a little C" programmers.
Change is always met with resistance, and resistance is not necessarily bad. If your target platform is a 8 bit processor with 2 KB or RAM and a whoopee 8 KB of ROM, you may not want C++. Better yet: you may not want abstraction at all. You may enjoy the power of what I call perfect knowledge of global state. You know that at a certain point you can reuse a location (maybe a few bits only) because it will be overwritten a few instructions later. You know you don't have to calculate a specific value because a previous portion has "accidentally" left it on a specific register. And so on. Been there, done that :-).
There are, of course, serious scalability problems with the notion of perfect knowledge of global state and in general with the lack of abstraction. In many cases, the few bytes you save and the few clock cycles you save have little or no economic sense. Sure, you have to factor in development time, lost opportunities due to longer time-to-market, and all those money stuff that the true nerd doesn't want to hear about.
Very recently, a customer told me that an outsourced (actually offshored) product based on old 8-bits technology and entirely programmed in assembly could be manufactured at a lower cost here, using ARM processors and C/C++. That's very common indeed. Most often, conservatism is not based on a careful economic and risk analysis, but on pride and prejudice (sorry for the trivial pun :-).
Anyway, considering that several "embedded systems" are now (necessarily) equipped with powerful processors and considerable memory, there are very little (or no) sound technical arguments against C++, and many technical arguments to use C++, because when your application grows, perfect knowledge of global state is a risky business. As usual, the hardest step will be a real transition to OOP, and that will take some time. UML is still lagging in embedded programming, even more than in other fields (this is pretty obvious given that abstraction is not considered valuable).
Sideways notes: saving memory does not necessarily means tweaking bits (although tweaking bits is easy). A well-known approach (well, maybe not so well-known :-) is to create a small custom language for the problem at hand, write a compact interpreter for the language, and then store the "program" in this custom language. This is a very old technique, used for instance to move Zork to the "personal computer" in the eighties: see How to Fit a Large Program Into a Small Machine by Marc S. Blank / S. W. Galley, Creative Computing, July 1980.
A few readers may also be interested in a simple pattern language to save memory:
Proceedings of the Memory Preservation Society - Patterns for managing limited memory by James Noble and Charles Weir.
Comments:
<< Home
Devo dire che il paragone con gli unix mi sembra molto azzeccato. Io credo comunque che la lentezza della standardizzazione e la mancanza di alcune librerie sia stato il punto fondamentale. In windows ( credo 80% del mercato desktop) si sente la reale necessita di un toolkit grafico standard, di una libreria per la programmazione di rete, del supporto multithreading e di accesso a database. Di recente ho discusso con amici dell'università su un confronto Java/C++. Quel che ne è emerso è che Java ( come .NET ) offre il grande vantaggio di un'ampia libreria standard, non importa quanto ben progettata!!! Avere il multithreading nel linguaggio è comodo, anche se (io sostenevo che) magari Eiffel lo fa meglio già da dieci anni. CORBA si fonde abbastanza bene con Java, anche se magari sfruttando le idee di SCOOP si può fare meglio. A molti fa comodo la GC anche se si perde in efficienza e si perde il RAII. Si risparmia tempo, almeno nel poter tirare giù qualcosa di funzionante alla velocità della luce. Salvo poi passare a fare qualcosa di più complicato...:-))
Post a Comment
# posted by 
: 5:14 PM
: 5:14 PM << Home
