Gus Wirth wrote:
Andrew Lentvorski wrote:
Superfically, because Ada isn't succinct. Lines of code productivity
is constant. Verbose languages are less productive.
Where is the proof for that? You're saying that because I have to type
more I'm less productive? If my typing speed was my limiting factor,
then maybe. But I would hope that programmers spend much more time
thinking than typing.
It isn't typing speed. It's richness of concept.
There have been two studies I know of that concluded the same thing.
Speed of lines of code generated tends to be constant irrespective of
language.
And, I cannot find either study with Google. Useless POS ...
This also matches my empirical experience with engineering. In VLSI
design, DEC had a rule of thumb about weeks per engineer per schematic.
It is roughly constant regardless of tools, chip, technology, etc.
Individuals tend to have a fixed complexity tolerance. The only thing
which helps is better complexity abstraction. The engineers will then
increase the complexity until they are back at the same rate.
The fact that so many bugs crop up in succinct languages counters your
argument. Writing bugs is not being productive. Java is more verbose
than C yet it can be argued you're more productive using Java because it
eliminates entire classes of bugs, for example pointer problems.
I don't buy that. Java seems about the same verbosity as C in my
experience.
Personally, I think it's less verbose than C because I don't have to
futz with passing and validating data structure pointers to every
function which mutates that data structure like I do in C. However, any
gains are well within +-10%. I consider that statistical noise.
The nice example I have of conciseness is list comprehensions:
C:
for(int ii=0; ii<container0.length; ++ii) {
// Mangle(e=container0[ii]) and put it into container1[ii]
}
Python (and other languages like Lisp, Haskell, Ruby, etc.):
container1 = [mangle(e) for e in container0]
The issue is *not* less typing. The issues:
1) I don't have to declare an index
2) I don't have to check the limit of the index (fencepost error)
3) I don't have to update the index
4) I don't have to worry about dereferencing an invalid index
That's a bunch of overhead that produces bugs when all I want to do is
iterate over the container. Pulling the idiom into the language reduces
the bug opportunities while also decreasing the lines of code.
*That's* why a succinct language tends to be more productive.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg