Nothing to do with Scheme (was: Re: [plt-scheme] No More Boring Code)

On Fri, Apr 10, 2009 at 2:07 PM, John Clements <clements at brinckerhoff.org>wrote:

> On Apr 10, 2009, at 1:11 PM, Michael Coffin wrote:
>
>  I used to be a huge fan of fancy abstraction tools. I still like them a
>> lot when I program for fun. However, after working for a few years on a huge
>> code base (Google's) written by thousands of programmers of varying skill,
>> I'm not so convinced anymore. A couple things to remember:
>>        • Code is read a lot more often than it's written, and while
>> boilerplate is a pain in the ass to write, it's easy to read precisely
>> because it's trivial.
>>
>
> This is a little like saying that I'm reading much faster now that I put 30
> copies of the word "the" at the beginning of each sentence.  That is, the
> addition of the trivial code doesn't change the complexity of the
> non-trivial code; indeed, it serves to obscure it. It's hard to extract and
> focus on the important bits from the background noise of the boilerplate.


I don't enjoy reading boilerplate any more than you do. I'm just saying that
there are things that are much worse.

>
>
>         • Reading code that makes heavy use of powerful abstraction
>> mechanisms ( e.g., Haskel, and Python to a lesser extent) can be really hard
>> to read because each abstraction layer essentially defines a
>> problem-dependent language. That's nice when you have a program that uses a
>> single such language, but it gets out of hand pretty quickly with a large
>> code base, where you have dozens of subsystems, each written in its own
>> idiosyncratic language. It's pretty wrenching to try to follow an execution
>> path where each step requires you to learn a new language.
>>
>
> Yep.  That's not an argument against abstraction, though: it's an argument
> in favor of only letting a select, smart set of people design your
> abstractions.
>

First,  "smart" is not the same as "good designer" -- the latter set is a
small subset of the first. But more importantly, with thousands of
programmers, it is really not practical to have all abstractions designed by
only  a few people. Institutionally, how do you do it? A smart programmer
who isn't allowed to do any design is going to feel like a typist and just
leave. At a place like Google, trying to do this would lead pretty quickly
to a mass exodus. It just wouldn't be a fun place to work anymore.
Programming is a social activity, not just a technical one.


>
>
>>        • It often pretty easy to compensate for lack of powerful
>> abstraction by using instead code generation tools to define new languages.
>> This has the advantage that the languages are actually documented, and tend
>> to get standardized pretty quickly, partly because it's not that easy to
>> write them.
>> I know this is all anecdotal, and I don't think it's conclusive at all.
>> But I now suspect there are some practical issues with powerful abstraction
>> mechanisms, especially with large, shared code bases.
>>
>
> Wait wait... code generation tools *are* a form of abstraction.  What
> you're saying here is what I said 1 paragraph up: you want your abstractions
> to be designed by smart people.  I agree with this completely.


Code generation is a form of abstraction, but it's self limiting because it
isn't so easy. So it gets used to solve a few really troublesome problems,
but it's too much work to use on smallish problems.

>
>
> John Clements
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090410/71d90f45/attachment.html>