Hacker News new | ask | show | jobs
by ChuckMcM 4683 days ago
It has been more than 10 years, it has been at least 50 since there were moans about productivity in the early 60's.

Feynman had some interesting thoughts on minimal computation that sort of paralleled Shannon's information complexity. As you know Shannon was interested in absolute limits to the amount of information in a channel and Feynman was more about the amount of computation per joule of energy. But the essence is the same, programs are a process that use energy to either transform information or to comprehend & act on information so 'efficiency' at one level is the amount of transformation/action you get per kW and "productivity" is the first derivative of figuring out how long it takes to go from need to production.

It has been clear for years that you can produce inefficient code quickly, and conversely efficient code more slowly, so from a business value perspective it there is another factor which is the cost of running your process versus the value of running your process. Sort of the 'business efficiency' of the result.

Consider a goods economy comparison of the assembly line versus the craftsman. An assembly line uses more people but produced goods faster, that was orthogonal to the quality of the good produced. So the variables are quantity of goods over time (this gives a cost of goods), the quality of the good (which has some influence on the retail price), and the ability to change what sort of goods you make (which deals with the 'fashion' aspect of goods).

So what is productivity? Is it goods produced per capita? Or goods produced per $-GDP? Or $-GDP per goods produced? Its a bit of all three. Programmer productivity is just as intermixed.

2 comments

> It has been clear for years that you can produce inefficient code quickly, and conversely efficient code more slowly (...)

That's not only false, but is often the opposite.

The symptom number one of an inexperienced programmer is to waste development hours reinventing the (square) wheel, while a good programmer is lazy (already knows which solution works best, and will probably just import it from a tested library).

So an experienced programmer not only doesn't waste computation power, also doesn't waste hours on the development cycle.

I agree with everything else you pointed.

Since I'm trying out my CODE keyboard [1] I thought I'd go into a bit more detail.

My statement about inefficient code quickly is in terms of joules per computation. So while it is absolutely true that a junior perl programmer might slowly generate inefficient code and an experienced (lazy) perl programmer might quickly generate optimal perl code, neither of them would produce the same product written in assembly code (or better yet pure machine code).

To put that in a different perspective, I once wrote a BASIC interpreter in Java (one of my columns for JavaWorld) and it was pretty quick to do, and yet looking at the "source" to Microsoft BASIC written in 8080 assembler it was not very efficient. But it took Bill a lot longer to write Microsoft BASIC in assembler, and you couldn't even begin to port a full up Java VM to the 8080 (let's not argue about J2ME).

But step back then from that precipice, you have two versions of BASIC, one runs in a Browser and one runs on a 16 line by 64 character TVText S-100 card. (or 24 x 80 CRT terminal). Now you can run the same program in both contexts, unchanged, but the amount of energy you expend to do so varies a lot. So which is more "efficient?" I'd argue the one written in 8080 assembly is more efficient from a joules per kilo-core-second standpoint. Which was written more quickly? Mine, it only took about a week.

That is why talking about efficiency and productivity without getting anally crisp in your definitions can lead to two opposite interpretations of exactly the same statement.

[1] I find the lack of a wrist pad to rest on a challenge.

I love Feynman's idea of minimal computational energy - it suggests that we could actually measure elegance.

And to be fair we do - the great works of art, craft a d even science are almost always elegant. And it is something we atrive for. Some buggers have it and the rest of us wade around with feet of clay - but it is conceivably measurable.

Going to be easier to go with the editor's taste I think though.

>> I love Feynman's idea of minimal computational energy - it suggests that we could actually measure elegance.

It's a lovely idea, but in practice would be hard. "I just updated my interpreter and my code got 20% more efficient!" "How does it compare to that other code?" "I don't know, it's incompatible with the new interpreter."