Re: succinctness = power

[Daniel Weinreb <address@hidden>]

Timothy Hickey wrote:

Sorry to take so long to reply.

>
> Lightweight languages (being those languages which are easy to learn 
> and use
> while still retaining expressive power) require fewer comments, almost 
> by definition. 

Sorry, but I just don't buy that. As I've said before, "easy to learn" 
and "easy to use"
can mean different things in different contexts and to different people. 
 More important,
I think the kinds of comments that were in my example were sufficiently 
high-level
that they would have been the same whatever language I had used. I do 
not think
that the rewritten code that you submitted had any less need of those 
comments
than the original.  It was the feeling of the writer of the code that 
the reader
needed to be reminded of how certain facts and invariants and contracts 
worked
together in order to produce a particular effect that he (the writer) 
thought might
not be obvious, and that kind of thing happens in any language.

>
> For the example you mailed out recently (copied below) assumes a great 
> deal of
> domain specific knowledge (what is a PRN? a PFE? ...) This must appear 
> somewhere
> in the documentation, but presumably not in the code. 

Sure, it does in the code, just not in the code fragment that I sent. 
 The concepts of
"PRN" and "PFE" are pervasive thoughout large swaths of code. If we had 
to spell
out what they mean over and over again, the comments would be unbearably 
tedious.
This was real code from a moderately big system. It's always like that.

>
> The comments in your example are of several types:
>  1. explaining what the procedure does ("...filling in the PRN if this 
> is a new process")
>  2. providing invariants (so that the sending process continues before 
> the
>    called process executes.
>  3. explaining why choices were made ("as an optimization ....)
>
> The first type of comment could be minimized by using lightweight 
> languages
> and this would minimize the amount of work need to maintain the code 
> base. 

Sorry, we disagree about this.

>
>
> The second type might be handled using some sort of assertion language
> which can express notions of the states of processes. 

I suppose it might be, though I've never seen an assertion language that
can operate at the kind of high level of abstraction that would be needed.

-- Dan