Re: Deploying Common Lisp applications

On Tue, 24 May 2005 12:04:48 +0200, <qrczak@xxxxxxxxxx> wrote:
> GP lisper <spambait@xxxxxxxxxxxxxxx> writes:
>
>>>> - just stick all your code in one big binary, branch on argv[0]
>>
>> You must be a recent developer. This trick is very common, several
>> bin files use it to select various sets of command line options. Look
>> for symlinks within the same directory. 'Busybox' isn't as common
>> nowdays with CD installs, but those floppy installs loved it.
>
> This saves disk space at the expense of modularity / maintenance.
> It's a workaround, not a good solution.

The disk space savings was immediately utilized to provide a broader
command set, granting users a greater ability to solve (in the busybox
case) installation problems in 'non-standard' hardware. "Good" is
relative. I needed that ability several times, thus my evaluation of
the trick is different.


> In both cases it's needed because the native way of making programs
> has a big constant cost, which is better paid once instead of for each
> program separately. When it's not needed from the maintenance point
> of view, it's bad.

This is back to the 'Best deal is 2 out of 3' rule. Eye of the
beholder etc. "good" and "bad" remain relative judgements, different
needs, different judgements...but these cases can be written down and
determined (I have counted bytes more than once). Just handwaving and
declaring it wrong is another story.


> Well, in *some* cases the original commands are perhaps split too much,
> e.g. most of the code of gzip and zcat is the same (they are different
> interfaces for subsets of the same functionality), so they are better
> put in the same program even from the maintenance point of view. But
> these are only a few cases.

I was maintaining two sets of code recently, one dealt with a file,
the other with a unix pipe. The two programs performed indentical
manipulations on the data streams. Lisp actually made this simple to
see that I should combine them into one program with just 2 entry
point functions. My old perl way-of-thinking would have left it as
two separate files. In perl (or similar) I would have needed some
sort of dispatcher as the front end in a combination program. In a
lisp image, I get that for free....for some disk space rent.

YMMV

It's not a few cases, it can occur everyplace where there is a
datastream transformation. Look at the RAID tools, probably would
show up in crypto tools, etc.


--
With sufficient thrust, pigs fly fine.
.

Relevant Pages

  • Re: political
    ... that's just a com trick ... ... Is the command not to eat of the Tree of Knowledge clear ... When God speaks, it's ... to your flawed and limited human wisdom) introduces inconsistancies ...
    (alt.smokers.cigars)
  • Re: mode independent UI description language
    ... but without defining ... > would be a common definition for multi-modal interfaces... ... It's a 'text user interface' in that the 'hot-button' ... to execute any command, I 'cord' on the 'text' of the command ...
    (sci.cognitive)
  • Re: forgetting my DCL: what am I missing?
    ... >> Here's a little DCL trick that will solve your problem. ... command substitution happens in phase 2 of DCL command processing -- ... wanted to do and sneaked in the apostrophe trick. ...
    (comp.os.vms)
  • Re: Inheritance question
    ... def execute: ... Ship and Add may or may not share a common base class depending on whether ... The client code is independent of the actual command, ...
    (comp.lang.python)
  • Re: Very Confused: Class, Imports, ...
    ... Sure, Miguel, you can do that without either. ... Just open a command window; ... >> what you need to do is compile common.vb to common.dll using the ... >>> I created a new file named common.vb where I created a class named common and where I ...
    (microsoft.public.dotnet.framework.aspnet)