Written by some Russian developer at MS. Don’t know his name, I have this text from
another Russian developer in MS from CL compiler team.
Sorry for poor translation to English - too much slang.
(begin)
You know, I was it compiler development business for a long time. Once talking to
Igor V. Potosin (one of the greatest persons in optimizing compilers) about 15 years ago
(I was young that time) I asked - why we spend this huge efforts for optimizers, if CPU speed
is doubled each 1.5 years according to Moore’s law? Usually the code generated by a stupid
compiler (“what I see is what I sing about”) is sub-optimal 1.5 or maximum 2 times for both
CISC and RISC. So, if the bad code will work the same speed on the new machine as the good
code on the old one - must we bother optimization?
Potosin anwsered, that I was not the first to ask this and that he hears this question since
early 60ies. The answer is that regardless of how many computing power you have, developers
will find a way to utilize them all, so, “pedal-to-the-metal” computer use is a Good Thing and
will be a Good Thing for a long time.
He was surely right. All of us remember Word working fine on 286. It would skyrocket on 386,
but these “bad guys” (1) - our Office collegues - ported it to Windows and made it graphical
(surely, more power appeared - why not utilize it)? Then 486 appeared, and again, Word would
skyrocket on it - no, they added some background spellchecking there, which runs always, and
again the computing power was not enough. If somebody thinks 1.5GHz PIV will be enough for all
real situations - again wrong. 1.5GHz PIV is about a half of what is needed for real-time TV
compression, I will not say on voice recognition here.
So, the speed of the program is important. The practice shows that, if some app (a serious app,
not a 1000 lines demo) works too fast, then some funny functionality is immediately added to
it, which raises sales 10% and eats all remaining resources.
Neither Java nor C# apps do not work and will never work as fast as C ones due to 100 reasons.
The language was designed by the left leg (2), and it is not the compiler developer’s fault -
the compiler developers are not guilty that Java language developers knew nothing in both
languages and compilers, so, the pitchforks (3) are spreaded as a layer everywhere there.
Dear sirs, Java is just terrifying, and the VM implementation by Sun is a song! Look at it
- and you will understand that the guys were making the first VM in their life. Bug here,
problem here, a “pitchfork” there… Let’s thank the Sun company who invested several billions
dollars to widespread this puny thing and won at last.
Another important moment. Writing a code is peanuts. About 5-10% percent of the development
cost and time. Hundreds of billions of dollars and millions of man-years (no, no aggravation)
are thrown away to software support - testing, bugfixing etc. And this is the real problem.
The developers also change their employer once per 2-4 years - the guy have just become
accustomed to a company and started to work productively - and lo! he is looking for another
job!
And now we have the interesting problem. Due to high labor mobility and high complexity of the
real-world projects - code readability and editability starts to play the #1 role.
For a code to be both readable and editable, it must be locally understandable.
So, when the new guy will look at the procedure, he would easily understand what it does and
how.
And here we have a great fun with constructors, destructors, virtual functions, inheritance,
exception handling and so on, so on.
Please tell me when C uses a function pointer? Rarely, and only when it is really necessary.
So, when you see a call in C, it is usually clear what is called, you can go and see what does
the callee do.
And in OO languages, when people (ex-students especially) love to redefine functions, it is
damn hard to understand what of 15 virtual methods would be called in this context, and read
all of them is boring. Thus the bug fixing takes 3-5 times more time.
Now on constructors and destructors. The programmer sees the variable definition which is never
used - and throws it away. The app stops to work. What a delusion? Wow, the constructor of this
variable established a connection to Exchange! (yes, a real-life example from Outlook).
Surely one must be fired for writing such a constructor, but - what is written by pen cannot be
chop away by axe.
In the result the programmer must read the definitions of all constructors and destructors for
all local variables in the function. Who wants to read 40 files for this? Nobody.
And nobody does. In the result it is impossible to understand the program merrily written in
the OO language after 3 years.
So, according to my personal experience, the reliability of programs on OO languages is far
from being perfect. Surely, if the manager monitors the process and beats one’s ears for
over-creative language use - it will be OK, but, in practice, it is much more dirty code in
OO languages.
I will be silent on operator overloading, copy constructors and such. Creative use of
templates can also provide the followers with lots of merry minutes. Wow, there are also
exceptions…
Thus the code written in the language without the hidden semantics is much more supportable and
maintainable. Just smaller number of pitchforks. If a variable is declared, it means nothing
more. Block exit - means only block exit, and nothing more. It works as it is written.
And when the source is like the USSR political news and one must dig deep to the 3rd layer of
truth - this is a brothel, not a development. Unfortunately, it is much easier to do in OO
language, as we can behold every day.
It’s surprising, but for industrial development - simplicity is a guarantee of good health 
The simpler, the better. The code must be clear for a clinical idiot, otherwise, the man who
will replace you in 2-4 years will not be able to maintain it.
You want to initialize a variable? Call a procedure.
You need to call a function? Do this directly.
But you must not - send messages to JavaScript, which will execute XML taken from the registry,
which in turn will load an ActiveX control, which in turn will call your procedure via COM
(funny? A real life example, I have fixed such a year ago, hope the author of this idiocy is
no more an MS’s employee).
The language complexity is a connected topic. The C standard is 200 pages. C++ is about 1000,
with lots of implementation-dependent stuff. The puny paper which is considered to be the
Java semantics description is just a fun. Its authors just kept silence on all interesting and
intriguing moments - (yes, where the pitchforks are lying) - the moments which are most
interesting for a compiler writer. Looks like they considered that nobody can make things
worse than they.
It’s obvious - the simpler the language, the harder is to make a semantic error in it. If a
brief and complete language description is 1000 pages - can you expect the average programmer
to know the language 50%? No. Then can you expect that a complex operator really means what the
programmer intended?
Then. Standard libraries. From the industrial point of view - again, the simpler, the better.
If such a library (especially a dynamic one) has a bug - this is a disaster. If developers have
not found it - then the users will. If they found it and worked it around - then the user
will have problems with the newer library version with the bug fixed (everything was coded
assuming the bug!). The 100% backward compatibility of the libraries is a requirement too.
Now please tell me - any Java library which meets these conditions? Or any Java procedure
without a misbehavior? I will not say that one must spend half of a life to teach these
libraries.
Yet another problem. The language age. The elder the language, the better and deeper the
developers know it. Concerning C, everybody knows what is possible to do and what is possible
but not recommended. With new-fashion languages there is no such experience, and the experience
is written by blood like army’s Sentry Service Regulation. Also do not forget that the compiler
developers are no gods and can mistake themselves, thus the bug probability in C compiler is
much lesser then in C++ (it is not necessary to work hard to find a bug in Java compiler,
especially Sun’s - the bugs will find you themselves).
In brief. In OS development and other serious project development there are very strict
performance and reliability requirements.
The first depends on the language heavily. The second depends on testing, programming
discipline and code readability/editability, which are also very much language-dependent.
If you will have a thorough look, then all good serious programs are written in C with some
assembler. Word. Excel. NT kernel. Linux kernel. Code generators (VC and GNU etc. GNU code
generator is unsuitable for sure - though can generate a good code if the stars are aligned
properly). The only good C++ program I know is MSSQLServer.
Let’s look on C++ software. Exchange Server. Outlook. PowerPoint. WMP.
Any comments?
Surely, all of the above is for big industrial projects, with millions and tens of millions
code lines and at least 50 developers working on it. The above is not relevant for the
“t.c”-like apps 100 lines long - they can be written in any language.
P.S. Here I threw lots of mud to Java but not C#. But, considering the above, and the intimate
relation between the 2 languages, I think that there can be a based opinion that the 2
languages will have the common problems.
(end)
- Dunno the English word for this. A well-known beetroot-like vegetable. A ball-formed root
about 4cm in diameter, of magenta skin with white inside and with a long mouse-like “tail”.
The name of the plant is also used in Russian slang as “bad guy”. - “By the left leg” - in a hurry, without proper thinking, by using “Hey! It works!” attitude.
- Pitchfork. Step on it - and it will strike your face with a wooden handle. “Can of worms”
is probably the exact English translation.
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
