[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [school-discuss] Free-Open Baccalaureate Idea

Yishay Mor <y.mor@ioe.ac.uk> writes:

>>(BTW, I was not criticizing in any way.)
> Oh, but you should.  Without critique there is no quality.

No, really.  I wouldn't dare telling people what to do and how with
their time and energy, especially when I'm not taking an active part
in it.  I can only show another point of view when the effort seems
worthwhile to me, in the hope that it has usefulness.  If it's not,
please endure my ramblings. :-)

> Ant was developed as a Jakarta project to be all that Make is not.  It
> has an XML file format which is easily readable and editable by humans
> and applications alike.  It was designed to be modular, so that a
> small set of core task were implemented quickly, and other tasks added
> as time went on.
> Personally, I don't believe that good large systems can "emerge"
> without any vision or design.  I do believe in "Start small, start
> easy, and above all start now.'' .  My approach is that even when
> you're writing a small, throwaway program - first think of the next
> thing you would do, and try to design an architecture that would
> address that as well.
> Always remember "make".

It is funny that you should mention Ant, because just a couple of days
ago I glanced for the first time at an Ant build file and, although
I'm not a great fan of make, I had a hard time coming to friendly
terms with what I saw.  It wasn't exactly my idea of human readable
or human editable:

  <target name="zippkg"
          description="create the distributable zip file">
    <zip zipfile="${dist.dir}.zip" 

I agree it is an ideal format for a computer to grok, since all that
explicit syntax makes writing tools a breeze.  But is anyone really
expecting me to write this by hand:

  <target name="zippkg"
          description="create the distributable zip file">

...rather than `zippkg: distpkg' ?

(A whole new thread could be open about implicit vs. explicit syntax,
in more appropriate places.  Suffice it here to observe that even in
the extremely explicit environment of an Ant build file, the author is
choosing `zippkg' and `distpkg' instead of `zipped package' and
`distribution package'.)

The problem with make and similar tools (*cough* perl *cough*), apart
from the fact that, unlike Ant, it had no predecessor to build upon,
is the effort to keep backward compatibility at all costs --
compatibility with users' expectations and habits, that is.

On the other hand, those projects that are willing to follow a
stricter evolutionary path, and let new better ideas prevail on old
ones and reshape the system with no remorse, happen to come out just
like natural systems: complex, yet balanced.  Sorry, but to me Ant
feels as natural as an eight lane highway through Yellowstone
park. :-) In some ways, the culture of refactoring tries to address

To bring this back on thread (you didn't dream it could, did you?
;-)): fortunately writing books does not share all these drawbacks.
At least no user can bug the developer with a ``But this breaks my
expectations and habits!''  concealed behind a ``But this breaks
compatibility with older implementations!''.  Like developers,
however, get very fond of some thirty lines of code, and that makes
the acceptance of new better ideas in that area difficult, so do
writers sometimes.  I know did, both in programming and in writing,
and I confess, more than `sometimes'. :-)