On 2012-02-23 9:07 AM, ianG wrote:
Um. I feel exactly the reverse. I feel uncomfortable with crypto code
written in languages that guarantee buffer overflows, stack busting
attacks, loose semantics at data and calling levels, a 5 x developer
penalty, and an obsession about the metal not the customer.
Language wars are off topic, but ...
They had this debate at google, wherein they discovered that good java
developers could not reliably estimate the way in which java code
scaled, but that good C++ programmers could reliably estimate the way in
which C++ code scaled. Since incorrect scaling behavior can bring
google to its knees ...
My C++ code does not have buffer overflows, nor does it ever store
potentially hostile data of unlimited size, nor does it ever casually
impose types on void pointers
As for the customer, whenever you want to install something other than a
program developed in C or C++ on a multitude of different customers with
a multitude of different computers, install hell ensues.
The five times or ten times developer speed advantage of garbage
collected languages is true of write only code. As the amount of
maintenance increases relative to the initial write time, this developer
time advantage disappears.
My experience is that whipping up initial prototypes, or one off
quickies, or scripts to process a great pile of text, goes about ten
times faster in a garbage collected language than in C or C++, but then
as the program gets larger and more professional, problems ensue.
For larger programs, I doubt that there is any developer penalty:
garbage collected languages get memory leaks also, typically in the form
of obscure and complex data structures which grow without limit when
they are not supposed to, which problems when they occur are harder to
track down than in C++ where garbage collection is under manual control.
The primary developer advantage of garbage collected languages is
garbage collection, which these days is supported by C++, the
disadvantage of C++ garbage collection being that automatic garbage
collection in C++ is not all that automatic. It is yet another optional
thing that has to be managed, which disadvantage is however
approximately independent of program size - the larger the program, the
smaller the relative overhead of manually specifying how and when
allocated data is to be automatically freed, and the more time one
spends maintaining the program, rather than the write only program
development characteristic of software developed in garbage collected
languages, the greater the benefit, and the less the cost, of explicitly
specifying the memory type and lifetime of data.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
