[PRL] Code's Worst Enemy

[Peter Dillinger]

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