--Apple-Mail-2-489977373
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed
On 03/10/2007, at 08:55, Nadav Har'El wrote:
> There's a famous paper on the design of the Unix "spell" program,
> which
> ran (if I remember correctly) on some PDP 10 with 65 KB of memory.
> Much
> of the work involved in fitting all the words in less than that
> memory.
> When I started working on Hspell, it was obvious that nobody really
> cared
> about how much memory it would take. When it ended up taking 100 KB
> of disk
> space and 4 MB of memory, everyone thought it was perfectly
> acceptable (and
> even small if you compare it, for example, to aspell).
And with good reason, too. The art of programming changed focus not
because we are lazier these days than the heroes of the ancient world
(although this may be true as well). Because resource limitations
have changed, and hardware prices changed, it's rather obvious that
the focus of what is considered "good programming" has changed.
In the days of yore, in order to fit the data into a decent file for
the compiler to chew, you'd do nasty things like cut down on comments
and indentation, and of course variable names. In fact, IIRC,
FORTRAN, prior to the 77 version, didn't even allow indentation.
Doing these things today may cost you your reputation. The focus has
moved from saving on source code length to saving on maintenance
time, because nowadays, programmer time is the bottleneck. And this
goes further than just the length of code, because of course, there
is some trade-off between efficiency and maintainability. I find
myself many times writing code which I know would not be very
efficient (e.g. make several database accesses which could be reduced
if effort was put into it). Why? For two reasons, mainly. (A)
Spending my time and effort to make the program more efficient would
be more costly than those additional database calls. My time is
limited, I'm one of the most expensive resources in my company, so
they wouldn't want me to spend it thinking of tricks to make
something efficient, which basically would not affect the company's
income. If the program is inefficient in a way that can't be solved
by buying an inexpensive disk and inexpensive memory, and its
inefficiency is noticeable by the users, only then would it be
worthwhile for me to spend the extra hour on efficiency.
And (B) in order for my program to be readable, easily maintainable,
modular, so that I (or some other programmer) can later read it, and
swiftly understand what's going on and easily add or change features,
you lose efficiency. Code becomes more bloated, but you have nice
easy to understand loops inside instead of a complicated set of
statics and globals where you depend on previous state and the
programmer needs to start writing state charts to understand what is
going on.
Of course, the best of us can write pretty efficient code which is
both elegant and maintainable, and doesn't require too much planning
time. They find the optimum point easily. My guess is that the more
you approach that ideal as a programmer, the more your time costs
your employers.
Herouth
--Apple-Mail-2-489977373
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=ISO-8859-1
<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; "><BR><DIV><DIV>On 03/10/2007, at =
08:55, Nadav Har'El wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Arial" size=3D"3" =
style=3D"font: 12.0px Arial">There's a famous paper on the design of the =
Unix "spell" program, which</FONT></P> <P style=3D"margin: 0.0px 0.0px =
0.0px 0.0px"><FONT face=3D"Arial" size=3D"3" style=3D"font: 12.0px =
Arial">ran (if I remember correctly) on some PDP 10 with 65 KB of =
memory. Much</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Arial" size=3D"3" style=3D"font: 12.0px Arial">of =
the work involved in fitting all the words in less than that =
memory.</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT =
face=3D"Arial" size=3D"3" style=3D"font: 12.0px Arial">When I started =
working on Hspell, it was obvious that nobody really cared</FONT></P> <P =
style=3D"margin: 0.0px 0.0px 0.0px 0.0px"><FONT face=3D"Arial" size=3D"3" =
style=3D"font: 12.0px Arial">about how much memory it would take. When =
it ended up taking 100 KB of disk</FONT></P> <P style=3D"margin: 0.0px =
0.0px 0.0px 0.0px"><FONT face=3D"Arial" size=3D"3" style=3D"font: 12.0px =
Arial">space and 4 MB of memory, everyone thought it was perfectly =
acceptable (and</FONT></P> <P style=3D"margin: 0.0px 0.0px 0.0px =
0.0px"><FONT face=3D"Arial" size=3D"3" style=3D"font: 12.0px Arial">even =
small if you compare it, for example, to aspell).</FONT></P> =
</BLOCKQUOTE></DIV><BR><DIV>And with good reason, too. The art of =
programming changed focus not because we are lazier these days than the =
heroes of the ancient world (although this may be true as well). Because =
resource limitations have changed, and hardware prices changed, it's =
rather obvious that the focus of what is considered "good programming" =
has changed.</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>In=
the days of yore, in order to fit the data into a decent file for the =
compiler to chew, you'd do nasty things like cut down on comments and =
indentation, and of course variable names. In fact, IIRC, FORTRAN, prior =
to the 77 version, didn't even allow indentation. Doing these things =
today may cost you your reputation. The focus has moved from saving on =
source code length to saving on maintenance time, because nowadays, =
programmer time is the bottleneck. And this goes further than just the =
length of code, because of course, there is some trade-off between =
efficiency and maintainability. I find myself many times writing code =
which I know would not be very efficient (e.g. make several database =
accesses which could be reduced if effort was put into it). Why? For two =
reasons, mainly. (A) Spending my time and effort to make the program =
more efficient would be more costly than those additional database =
calls. My time is limited, I'm one of the most expensive resources in my =
company, so they wouldn't want me to spend it thinking of tricks to make =
something efficient, which basically would not affect the company's =
income. If the program is inefficient in a way that can't be solved by =
buying an inexpensive disk and inexpensive memory, and its inefficiency =
is=A0noticeable by the users, only then would it be worthwhile for me to =
spend the extra hour on efficiency.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>And (B) in order for my =
program to be readable, easily maintainable, modular, so that I (or some =
other programmer) can later read it, and swiftly understand what's going =
on and easily add or change features, you lose efficiency. Code becomes =
more bloated, but you have nice easy to understand loops inside instead =
of a complicated set of statics and globals where you depend on previous =
state and the programmer needs to start writing state charts to =
understand what is going on.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Of course, the best of us =
can write pretty efficient code which is both elegant and maintainable, =
and doesn't require too much planning time. They find the optimum point =
easily. My guess is that the more you approach that ideal as a =
programmer, the more your time costs your employers.</DIV><DIV><BR =
class=3D"khtml-block-placeholder"></DIV><DIV>Herouth</DIV></BODY></HTML>=
--Apple-Mail-2-489977373--
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
