[PRL] Code's Worst Enemy

[Matthias Felleisen]

Peter, in Jan 1984, when I started my PhD at IU, I had heard of the  
idea of closures (not the name, and no details) and I challenged my  
boss at a German company when he suggested it would be easier to code  
certain GUI things that way. Not challenge, but my reaction was "we  
can program like that, without the `closures.'" Pretty much the way  
you are writing now. And pretty much the vast majority of Java  
programmers feel. By March 1984, I couldn't believe I had programmed  
for nearly six years without closures. I felt like I had to start CS  
over. Indeed, I told Dan by the end of that semester that I had  
learned more in his course than for most of my Masters at UoA at Tucson.

So let me ask two questions:

(1) How many problem-specific or domain-specific constructs or (sub) 
languages have you implemented in a hygienic and modular macro system?

(2) How many ML programs with functors and structures have you  
written and how large are they (in terms of functors and structures)?  
I would accept PLT Scheme programs with modules and units and  
classes, too.

And let me ask a rhetorical question:

(3) Do you miss closures from ACL2? (Pls don't respond.)

Thanks -- Matthias



On Dec 29, 2007, at 12:06 PM, Peter Dillinger wrote:

> On Sat, Dec 22, 2007 at 11:19:11PM -0500, Riccardo Pucella wrote:
>> The fact that Java contributes to code bloat because of lacking  
>> abstraction facilities is of
>> course a big part of the problem with code size in Java, and that  
>> is something that we now how to deal with better with our languages.
>
> you mean like the kind of abstraction provided by macros?  i estimate
> ACL2s would be no more than 10% smaller than its current 25,000  
> lines if
> i had macros.  and potentially much harder to read & understand.
>
>> But the message I got was that any project that starts small and  
>> grows over the course of ten years to hundreds of thousand lines  
>> of code will almost inevitably be a mess, irrespectively of the  
>> language. (I don't buy the "it's harder to reach hundreds of  
>> thousands lines of code in ruby-or-name-your-fave-language.) You  
>> have to design for such sizes, and factoring out in libraries and  
>> separate modules is key. That Java has no module system comes to  
>> bite you here. Don't talk to me about packages...
>
> just because it doesn't have a module system, doesn't mean you can't
> do modular development.  in fact, you can even get the compiler AND
> the runtime environment to enforce modularity.  the language support
> for interface specification and parameterization is less than rich,  
> but
> it get's the job done, especially when your specification is evolving
> rapidly.  actually, one could argue assertions give you a
> Turing-complete specification language that doesn't slow down the
> final runtime.
>
> as an example, i have the Java part of ACL2s divided into three  
> modules:
> acl2s-lib, a library for talking to ACL2 in Java, depends on nothing
> but the Java API.  acl2s-uilib, a library for constructing a script
> management interface to ACL2, depends on acl2s-lib.  acl2s-plugin,
> which of course uses acl2s-lib and acl2s-uilib, is the only part that
> depends on Eclipse APIs.
>
> how is one bitten, again?
>
> -- 
> Peter Dillinger
> peterd at gatech.edu
> http://www.peterd.org
>
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl