Re: What would a modern LispOS look like?
- From: "goose" <ruse@xxxxxxxxxxxxx>
- Date: 29 Jun 2006 08:56:14 -0700
bradb wrote:
goose wrote:
Lisp Newbie, so take it easy on the flames :-)Sure - I'm a newbie too :)
Great, lets flame each other and get it over with :-)
I fail to see how merely using a *language* gives one a better
metric on the reusability scale[1]. OTOH I have to say that
global reusability is not the most important thing, and perhaps
"local" reusability (reusability within a specific environment
or sets of environments) won't be decreased by switching the
OS language from C to Lisp.
Ok, so *nix and C have very good reuse when it comes to libraries. But
that means that the useful functionality needs to be distilled out into
a library.
That's normally the way it is, yes.
I am imagining that in a Lisp based system would have all
code running in the same image - probably with boundries of seperation.
With dynamically linked libraries, you can pretty much achieve the
same thing - a loaded library being used by process A is not reloaded
if another program wants to use that library, but there is a
boundry between the two processes (so that they don't step on each
other).
But two applications that are running can directly talk to each other
just by calling functions.
Two applications in any modern OS can do that too; they can request
data from each other, and execute code on each other. Hell, RPC means
that they can even execute code on different machine (not like *that's*
normally usefull without a load-balancer). LispOS will offer nothing
new in this regard.
So, for example you could write an editor
and any other application that needs editor functionality could easily
embed that editor inside itself. So Mozilla could use Emacs for all
its text entry. I don't see that happening very much at the moment.
It may not be happening at the moment, but it's perfectly possible
*and*
dead easy in addition to being simple and well-understood.
There are presumably reasons that it is not happening at the moment in
spite of being possible, easy and simple[1]. I don't see how switching
to a different language in which it is also possible, easy and simple
to achieve this makes those reasons go away.
IOW, the language is not what prevents this from happening; a different
language may not have much of an effect.
The closest analogue that I can think of is how KDE shares components -
but the Lisp system could be many times tighter.
Also, C libraries need to be reused in a very specific way - the way
that the original designer thought of.
Not really the point. Half the functionality (if not more) on my
system is because of entire programs that are reusable, not just
libraries. For example I have a program called bash (and
another one called echo) that lets me do the following:
for X in 1 2 3 4; do echo $X; done
I also have a program called find that lets bash use it as follows:
for X in `find .`; do echo processing $X; done
I have another program called basename that gets me the name of a file
without directory prefix and another one called cut that lets me get
the name of a file minus the extension like this:
for X in `find .`; do echo $X | basename | cut -f 1 -d .; done
I have yet another program called madplay that lets me use cut, echo,
find, basename and bash like so:
for X in `find .`; do
madplay $X -o `echo $X | basename | cut -f 1 -d .`.wav;
done
Unsurprisingly, I have a program called grep which lets me process
only the mp3 files:
for X in `find . | grep \.[Mm][Pp]3`; do
madplay $X -o `echo $X | basename | cut -f 1 -d .`.wav;
done
All the above programs work *together* (regardless of what language
they may be written in, its only luck that they are all written in
C) to allow me to transform all my mp3 files in the current and
subdirectories into wav files which can be copied to an audio CD.
I can very easily put all of the above into a file called
search_and_convert.sh and execute that everytime I need this
functionality.
I fail to see how a LispOS could improve so significantly on that that
"reusability" comes up as an advertising point, but I'm willing
to be open to examples in a hypothetical LispOS that cannot
be currently *easily* done in a *nix OS. The entire reason I
chose a *nix OS to compare to and not a windows OS is /because/
of the ease with which the components in (for example) a linux
distro can be extended or reused.
With the LispOS you could
cherry-pick the functionality that you like, possibly shadowing
functions that you don't need.
I was able to do that above with complete programs. Once again,
I must state that the only thing that facilitates this regardless
of the language being used is the cluefulness of the developers.
Lisp has many advantages over other languages/platforms, but
I'd hardly classify "reusability" as one of it's strengths.
[1] I suspect that the reasons are because developers just
don't bother to design their programs like the way you described.
Using Lisp won't make this problem go away.
.
- References:
- What would a modern LispOS look like?
- From: bradb
- Re: What would a modern LispOS look like?
- From: goose
- Re: What would a modern LispOS look like?
- From: bradb
- What would a modern LispOS look like?
- Prev by Date: Re: What would a modern LispOS look like?
- Next by Date: Re: What would a modern LispOS look like?
- Previous by thread: KnowOS (Was: What would a modern LispOS look like?)
- Next by thread: Re: What would a modern LispOS look like?
- Index(es):
Relevant Pages
|
