Re: I read wiki, I agree it has one very serious problem less but I
have worked before with messages in windows and the interface was very
limited. It is like permitting only
functions which take Long arguments.
However, It made me think about [C++] name mangling I never understood how big a problem it is.
True, there is also a speed
penalty, supposedly by a factor of ~3 as compared with pure function
call. However, the flexibility of a messaging system is
INCREDIBLE! For example, from a source code standpoint there is
almost no difference whether you call(=send&receive a message to) an
object from within your own, call a library object, call a kernel object or
call an object across LAN or over the Internet!
Another advantage is that the built-in message-handling mechanisms have
standard ways of dealing with exceptions and do not do crazy things such as
throwing a protection fault or similar nonsense if a message would not come,
come out of order or carried some unexpected data.
Further, a message can carry a flag, data (parameters) but it can also carry
executable code/script (like for example JavaScript over TCP/IP link) - which
can add an unprecedented power to the program!
It is of course possible to pass executable binary code through a normal
C function argument but that is almost never practical for many reasons.
Message based systems are now regarded as the best development platform for
parallel processing, for example Erlang is a message based language used quite a
bit by Ericsson and other telecoms. Erlang has become the language of
choice for handling telephone exchanges (you have typically thousands of
threads running on a multi-CPU mainframe).
We have to distinguish between badly designed too complicated message oriented
system such as MS Windows, and well-designed message-based systems like Unix/Linux
kernels.
Message oriented programming may have some disadvantages, specifically if done
excessively on too low a low level (unnecessary substitution of normal
function calls by messages) then it leads to a flat hierarchy of modules that
generate 2^N number of interlinks. This is a mistakes that Mag
programmers have made: they overused message passing for their particular
application (radar sensor), breaking the program into about a score of
tasks rather than no more than 5, as I would recommend.
We (at Mag) used message-based RTOS
which was quite good but since it was in a pure C code, it was fairly
low level and you had to do a lot of explicit function call to send/receive
messages and handle associated events. I realized that this could be
greatly simplified if another high level language implemented much of this
formalism, since all these message handling functions are really quite generic
and repetitive. It is like with
function-oriented programming, it looks quite complicated if implemented
in assembly because you have to code everything involving argument passing
explicitly, while exactly the same structure looks much simpler in a high level
language.
I believe declaring processes and passing messages looks equally simple
in Erlang or Objective-C because of the built-in support.
I understand now that the biggest mistake of C++ creator wasn't the lack of
garbage-collector, nor too complicated syntax and depressing templates; his
biggest mistake was probably the lack of high vision of what exactly do we need
objects for! His objects carried from Simula are simply
run-time allocated data structures where member functions are function pointers
within a structure. They do not do really much more than ordinary
functions, they are just differently packaged. You can totally simulate
such C++ classes just using C structures but without data hiding (except
prefixing the names), all structure data fields would be public. Hiding
of the private data and private member functions was the main new thing (which
I did not really care much about). This is the main issue: had
objects a la C++ been really as useful as
C++ promoters claim, many programmers would have emulated such
function-containing structure types a long time ago without C++. Because
that wasn't the case, it is telling me that the usefulness of such classes was
probably overstated! However, the message-oriented Objects are totally
new animals, that could not have been easily simulated before, using the
standard C!
I think that’s the main issue that Microsoft directors have missed completely
and drove themselves into a blind track of adopting the C++ on top of poorly
working and unreliable .NET to overcome the C++ inherent binary
incompatibility, while it appears Apple's CEO avoided that mistake by deciding
to stay away from C++ altogether! Jobs experience gained on the failed
Next venture appears to have paid very well for Apple!
Stan Bleszynski, 25-Oct-2009