On 2010-03-05, at 00:06, Michael Arnoldus wrote:
So my suggestions was to use complexity in the context of improving
programmer (FSE) productivity. And I hinted at some possible
measurements that might be useful for this. I however do not in any
way pretend this is clear enough to work as a clear definition of
complexity or even metrics. And - for me at least - is not clear to
me that a single metric will be sufficient with the chosen context
and purpose (I'm aware we're not even clear on purpose yet).
I'm not able to pick a single definition of complexity that fits my
(maybe our?) context and purpose. I suspect that finding the right
meaning and definition of complexity in this context is more than
half the solution - as it is with most really interesting problems.
If you have a suggestion I'm all ears :-)
I'm afraid that you cannot ask either to improve the programmer
productivity without specifying a target "processor".
Taking again the example of ("Compute the pay of each employee of my
company" + programmer) system, the productivity of programmer A could
be infinite, if the target "processor" is programmer B and A can say
to B: "Compute the pay of each employee of my company".
But if we consider as "processor" in the target (program+processor)
system a programmer C who doesn't know anything about pay, then
programmer A will have more work, and his productivity will be finite:
he will have to specify to programmer C a program where all the pay
relative algorithms are explicited.
And if the target processor is an 6502, then the productivity of
programmer A will be abysmal, without tools. If you add tools, eg. a
C compiler, then it means the target processor is not a 6502, but a C
machine, and the productivity of programmer A is accordingly increased.
Well, this not new, it has been known since the 60's that the
productivity of programmers is in direct proportion to the high
levelness of the target machine, that is the "programming language"
used, what I call "processor" in my (program+processor) systems.
--
__Pascal Bourguignon__
http://www.informatimago.com/
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
