[asdf-devel] New ASDF maintainer sought

[Pascal J. Bourguignon]

Faré <fahree at gmail.com> writes:


> Bad reasons to split:
> * ease of browsing? Nope, it's harder when split.
>  You have to search for text in all files,
>  lookup an index to see the order (that does matter).
> * speed of compiling? Nope, for hours of maintenance, you only get a few
>  fractions of a second of speedup in the rare case that you only make
>  a simple change to a file that leaves all APIs untouched. And only on
>  a few implementations where you can somehow achieve separate compilation
>  through ad-hoc non-portable scripts. Full build takes a fraction of a second
>  MORE time, not less time, when you first have to concatenate all the
>  subfiles, anyway, because in the end, the reason we put it all into
>  asdf.lisp is because it was all necessary to bootstrap ASDF.
> * ease of maintenance? Nope, additional maintenance nightmare.
> * ease of distribution? Nope, it's easier to distribute one Lisp file
>  than a directory of files.
> * ease of deployment? Nope, it has to be loaded all at once,
>  and there's no portable way to concatenate FASLs.
> * ease of bug tracking? Nope, it's easier to md5sum or diff one file
>  than to try to assert and maintain coherence between tens of files.
> * smaller size? Nope, you only increase the total overhead,
>  and don't diminish the intrinsic complexity and size.
> * more sizeable chunks? Nope, my screenful of emacs buffer remains
>  of the same size.
>
> I'm sure we could figure out or imagine more reasons and non-reasons.
> But in the end, before you do such a sweeping change, can we have
> a rationale?
>
> [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
> Question:  How many Intel/Microsoft executives does it take to screw in a
> light bulb?
>
>
> Answer:  None, they simply make darkness an industry standard.

Let's agree to split when it reaches half the max emacs buffer size.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/