Re: What would a modern LispOS look like?

Lisp Newbie, so take it easy on the flames :-)

bradb wrote:

<snipped>

- What would the software ecosystem look like? Today applications
have little reuse of parts and are written in C.

I beg to differ; looking around on my system, every non-trivial
(and even most of the trivial) programs reuse bits and pieces
(packaged into libraries).

I'd be happy if you could point out *one* thing in a common
*nix type OS that could be reused but isn't.

- Would software be easy to distribute in binary form?

Corefiles? Compiled fasl?

- How would seperation of privileges work? Multiple users/super user?

It *could* work pretty much the same way it works in *nix OSes; a
bitmap on each object sets the priviledges; bitmap for the owner,
another one for group and one more for "world". Object need not
be just a file so this will presumably work even better than the
current *nix bitmaps (which apply only to files).

- What will the filesystem look like?

As others have replied, objects (and maybe object hierarchy?)
might work satisfactorily.

- Would the system be Lisp all the way down?

Well,that at the lowest level, it is still just
opcodes; if the lisp compiler generates opcodes which
can be run directly by the hardware, then yes ... lisp
all the way down (this also makes it simpler to distribute
software in binary form) is certainly possible.

- How would support for other languages be?


There would have to be some sort of linkage format; other
languages should just be able to link into the lisp
libraries (much like most languages can link ELF binaries).

I was born the same year as the Lisp Machines, so I haven't seen this
kind of environment before and I'm interested in it.

My thoughts:
The software ecosystem would be much the same as OSS is today, you can
get source to lots of apps. I think the apps would generally be
smaller in code and binary size because of the libraries that are
already available from the OS. I would hope reuse would be higher
among OSS, because of the nature of all Lisp code running in the same
image.

There's this reuse thing again, which I don't understand. Reuse
is currently very high on systems written in C merely because
C is the lowest common denominator that other languages can talk
too. Only very new programmers actually roll their own
[zip|crc|gui|etc]
library when the default OS install gives you all of this. I assume
that these same libraries will be rewritten in Lisp for LispOS,
but thats not being "reusable" if LispOS can't (or won't) make
use of non-lisp code.

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.


Support for other languages would probably be pretty good, after all
you just need to compile to Lisp s-expressions and the LispOS can do
the rest - though I bet there would be native compiling languages too.

I'm interested in what people think about this, so please reply.

Cheers
Brad

[1] unless that language is C. Writing your spiffy tic-tac-toe-solving
library in plain std C means that it can be used on any platform that
has a conforming C compiler i.e. 99% of platforms. Those platforms that
don't have a C compiler most certainly won't have any other HLL
compiler
either and will be typically programmed in assembler or similar.

Writing that same logic into a library in most other languages limits
you to the platforms that have a compiler and/or environment for that
language.

Hence, I doubt that you would get *more* reusability with using
something
other than C; If reusability is by far the most important thing, don't
write it in C++, Lisp, Java, Python, Basic, Perl, C#, etc.


goose,

.

Relevant Pages

  • Re: SBCL is now faster than Java, as fast as Ocaml, and getting better
    ... make Lisp look less stupid. ... you just defined programmers who cite superfluous ... The creators of the ML family of languages ... consider what it takes to create a "fresh compiler" when the ...
    (comp.lang.lisp)
  • Re: static, dynamic and implicitely typed languages
    ... programming languages but nothing about theses. ... In some decades a compiler might be more intelligent than any human ... Lisp then perhaps lisp community is going to shring. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... difficult to receive good criticisms about lisp by people who know ... that powerful languages have, which may not be problems with less ... the programmer must add extra code -- type annotations -- to support ... the compiler is just another ...
    (comp.lang.lisp)
  • Re: gcc in Lisp
    ... C/C++ compiler is hard and takes a high investment in terms of time and ... most probably also in Lisp. ... with these languages there is a demand for a compiler. ... new scripting language that more or less has the feature set of Common ...
    (comp.lang.lisp)
  • When static typing is worth it
    ... typed languages like Lisp. ... developed more quickly in modern statically typed languages than ... static type system and remove run-time checks. ... incurs a run-time error if the list is ...
    (comp.lang.lisp)