old code is good code!

Benjamin Pollack benjamin.pollack at gmail.com
Sat Apr 16 20:20:58 UTC 2005


On 4/16/05, Lex Spoon <lex at cc.gatech.edu> wrote:
> 
> Comanche works great.  I've been a happy user for years.  Maybe Swazoo
> has improvements, but Comanche is a proven platform.  Let's not trash
> our good software in an effort to promote the new stuff.
> 
> This is a big peet peeve of mine in Squeak for the last few years.  Old
> software is GOOD software.  Old software has the bugs ironed out, and it
> has the most desired features implemented.
[snip]
> I'm all for exciting, experimental code--it puts the "cool" into Squeak.
>  However, we also need to value our existing stable software.  Heck,
> even if your main interest is to try crazy coding experiments, wouldn't
> you like to have stable XML, SMTP, HTTP, and RFC822 support to base it
> on?  We won't get there with calls to rewrite code just because it is
> old [6].
> 
> Old code is good code.

I agree with you completely, but there are two aspects here. Old code
*that continues to work* is great and should be kept around. Old code
that prevents you from using new code or new hardware, on the other
hand, is bad. Squeak is so organic that its packages cannot be
orthogonal, so you get into problems if you want to have old code and
new code in the same image. On SqueakMap, there are a ton of packages
that are made for a specific Squeak image version only and that are no
longer actively maintained, so even if you want to use that package,
you have to either willingly downgrade and ignore all of the modern
packages that need the functionality of the newer images, or spend
hours trying to rewrite parts of the old code to interface with the
new system. For example, GLORP requires 3.6, whereas WriteBarrier and
some of the other interesting caching stuff require 3.7 (but not 3.8).
This makes using old code even when you want to hell.

At the time I wrote the paragraph on Comanche, Swazoo was getting
actively updated to run on newer images, including 3.7 and 3.8, and I
don't think Comanche was running on anything newer than 3.6 without
serious effort. Since that page was written specifically for newbie
users, having a guide that said, "To use Comanche, download these four
packages in this order (dependency checking not enforced), file in
these two Monticello changesets to fix some conflicts, and then tweak
this line of code" would have been ridiculous. Thankfully, Göran
donated the knowledge and time to clean up the mess, get it all
running well on Squeak 3.7, and produce the newbie-friendly
KomHttpServer 7 package, so as I indicated in another thread, the next
version of that page I make will recommend Comanche. But I think that
the overall sentiment you're finding issue with here is a symptom of
the incredibly delicate balance between various Squeak packages.
Solving that problem requires getting into things like module systems
and Squeak base images that come up biannually, generate a lot of
angry talk, and ultimately produce nothing of interest (or on rare
occasions produce a fork). Would people like to code on a stable base?
Of course! But that base doesn't exist, and with our current system,
may not be possible.

--Benjamin



More information about the Squeak-dev mailing list