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

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.

> 	• 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.

>
> 	• 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.

John Clements

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2484 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20090410/40071ab1/attachment.p7s>