<br><br><div class="gmail_quote">On Fri, Apr 10, 2009 at 2:07 PM, John Clements <span dir="ltr">&lt;<a href="mailto:clements@brinckerhoff.org">clements@brinckerhoff.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Apr 10, 2009, at 1:11 PM, Michael Coffin wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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&#39;s) written by thousands of programmers of varying skill, I&#39;m not so convinced anymore. A couple things to remember:<br>

        • Code is read a lot more often than it&#39;s written, and while boilerplate is a pain in the ass to write, it&#39;s easy to read precisely because it&#39;s trivial.<br>
</blockquote>
<br></div>
This is a little like saying that I&#39;m reading much faster now that I put 30 copies of the word &quot;the&quot; at the beginning of each sentence.  That is, the addition of the trivial code doesn&#39;t change the complexity of the non-trivial code; indeed, it serves to obscure it. It&#39;s hard to extract and focus on the important bits from the background noise of the boilerplate.</blockquote>
<div> </div><div>I don&#39;t enjoy reading boilerplate any more than you do. I&#39;m just saying that there are things that are much worse. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
        • 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&#39;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&#39;s pretty wrenching to try to follow an execution path where each step requires you to learn a new language.<br>

</blockquote>
<br>
Yep.  That&#39;s not an argument against abstraction, though: it&#39;s an argument in favor of only letting a select, smart set of people design your abstractions. <br></blockquote><div><br>First,  &quot;smart&quot; is not the same as &quot;good designer&quot; -- 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&#39;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&#39;t be a fun place to work anymore. Programming is a social activity, not just a technical one.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
        • 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&#39;s not that easy to write them.<div class="im">
<br>
I know this is all anecdotal, and I don&#39;t think it&#39;s conclusive at all. But I now suspect there are some practical issues with powerful abstraction mechanisms, especially with large, shared code bases.<br>
</div></blockquote>
<br>
Wait wait... code generation tools *are* a form of abstraction.  What you&#39;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.</blockquote>
<div><br>Code generation is a form of abstraction, but it&#39;s self limiting because it isn&#39;t so easy. So it gets used to solve a few really troublesome problems, but it&#39;s too much work to use on smallish problems. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><font color="#888888">
<br>
John Clements<br>
<br>
</font></blockquote></div><br>