From: Reprisal <nepenthereprisal@...>
Date: 2006-09-29T08:07:05+09:00
Subject: Re: "Succinctness is Power", by Paul Graham

--Apple-Mail-1-788980986
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

I don't think you are particularly in disagreement with what he is  
saying.  e.g.

So there is no argument about that-- at least, not from me.  
Individual programs can certainly be too succinct for their own good.  
The question is, can a language be? Can a language compel programmers  
to write code that's short (in elements) at the expense of overall  
readability?



On Sep 28, 2006, at 6:18 PM, 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/
>


--Apple-Mail-1-788980986--