I'll see his succintness, and raise him,
brevity
It's not just power, it's the soul of wit!
I must say that I've just skimmed this article, which by the way, can
be found at: Succinctness is Power so I can't say that
I won't change my mind on a deeper reading, but it feels like it's off
the mark.
His argument seems to be based in Fred Brook's observation that the
productivity of programmers tends to be fairly constant when measured
in lines of code per unit time. Fred went on to write that, as far as
he could see , there was "no silver bullet" to solve the problem that
software too too long to produce.
The real problem, it seems to me, is not efficiently producing lines
of code, but producing the right lines of code, and what's right tends
to change over time, as:
* You understand the requirements as you implement them.
* You understand the implementation better as you implement the
requirements.
* Your customer understands the real requirements better as he/she uses
what your current set of lines of code implements.
* Your customer understands the real requirements better as he/she
discovers that the environment (business, technical or otherwise) has
changed or is changing.
Now brevity, a term which I prefer to succinctness since it's more
terse, helps a bit because when things change there's less code to
change. Maybe.
In order to change code you first need to understand what you are
changing. I've recently taken over the maintenance of a huge wad of
poorly structured PHP/SQL code, and I still don't feel comfortable
changing it.
Now it might be easier, or at least less of a task if there were less
code, but I'm not sure that that's the real problem. The problem is
how the code is structured, or perhaps how it isn't structured.
Well developed code gets polished instead of developing cruft.
Now brevity, although it might reduce the bulk of cruft, doesn't
really change the problem, and taken to the extreme it can exacerbate
it. In my early days, oh so many decades ago, I used to do about half
of my work in APL, which is if nothing else an extremely terse
language. But like other terse languages, it got the reputation,
often well deserved, of being a write-only language, a combination of
perl and hieroglyphics.
But this really is less a language issue than one of the programming
teams approach. A little less brevity, and a little more attention to
how understandable the code will be in the future, either by you or
your successors is more important, and sometimes at odds with,
brevity.
IIRC in Fred's "No Silver Bullet: Essence and Accidents of Software
Engineering" paper, he held out a glimmer of hope for object-oriented
programming, which was something new to him at the time he wrote the
paper. Brad Cox wrote at least one article revisiting "No Silver
Bullet" and holding out his evolving view of reusable "software-ics"
as the way to kill the vampire. But the reusability which really
helps is the reusability of the knowledge acquired as a particular set
of software evolves, and that takes a combination of the right
languages and tools, and an approach which embraces the need to evolve
and re-factor that code.
The real silver bullet is a process which keeps software malleable.
Dynamic typing is a key ally in forging the right kind of alloy. <G>
Okay, I guess I need to read that article in more detail and then turn
this into a blog entry myself.
···
On 9/28/06, Rich Morin <rdm@cfcl.com> wrote:
This is probably old news to many here, but I found it
to be an interesting read, with implications for Ruby."Succinctness is Power"
Paul Graham
--
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/
