From: michael.mabin@...
Date: 2006-09-29T10:45:11+09:00
Subject: Re: "Succinctness is Power", by Paul Graham

Silver bullets don't kill vampires, they kill werewolves
Wooden stakes kill vampires ;)
But ruby sure takes you a lot closer to doing either...

Sorry, couldn't resist.


Rick DeNatale wrote:
> 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
>
> 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: http://www.paulgraham.com/power.html  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.
>
> --
> Rick DeNatale
> 
> My blog on Ruby
> http://talklikeaduck.denhaven2.com/