[REBOL] Re: even further ... Re: Introducing REBOL/Base - FAQ
From: greggirwin:mindspring at: 3-Oct-2002 10:53
<< Carl is AmigaOS' main designer, and AmigaOS is heavly based on "dynamic
linked library", and none has encountered trouble with them. M$ is another
Yes, it's not the concept of a DLL that I don't like, but how distribution
is handled (or allowed), what regression testing is done for compatibility,
etc. Another big distinction is that of libraries that are shared by many
apps, as well as the OS, versus each app (or suite of apps, etc.) having
their own version of a library that affects only them.
<< Amiga's libraries adopt this trick: if version 1.0 has these procedure:
b, c The next library version MUST have old a, b, c procedure and add newest
ones. A, b, c may be remapped on newst ones, but their entry point must be
removed, M$ doesn't adopt this trick ;) >>
With COM you can define the interface and then ensure that the original
interface is always supported in future versions through typelib versioning.
This, in itself, isn't a perfect solution. I built a set of DLLs for a
client who then modified them as time went on. Occasionally they would see a
problem and attempt to solve it by turning off compatibility checking (this
is in VB) which, of course, only caused many more problems as the ripple
effect kicked in and more pieces had to be re-built to match the new
interface IDs being generated.
DLLs aren't the problem of course. People are. :) I *love* reusable
libraries of code! I couldn't live without them. The question is, how to
make it work? Because of the way REBOL works, we're probably going to be
seeing apps that are built of many small pieces which may change
dynamically. Whether the concept of Web Services takes off or not, the world
is different now. With REBOL, it's about communication (messaging). We don't
have to use components and libraries as we have, historically, with other
langugages. We need a good model that is simple, flexible, and robust. Lots
of details to consider on that front.
In any case, RT seems to have a plan. They released /Base and Carl said they
want to know what we think, so let's keep thinking and telling them. He also
said another tool would be forthcoming to help with including the pieces
they took out, so I think they have something in mind about how to handle
What do *I* want as a developer?
I want to be able to send out a single EXE, that isn't dependent on anything
that might be changed for the OS or another app. External pieces I ship
should not be used by anyone else, so I can handle them however I want. If I
break my own app, that's my fault.
If I deploy a script, either it's targeted at REBOL developers, sysadmins,
etc. who know how this stuff works, or it's for users. If it's for users,
there needs to be a single interpreter/runtime that is used for everything
(IMHO). E.g. under Windows, .r files will be associated with rebol.exe and
that version of rebol needs to be able to run every script they might get.
This doesn't fit very well with the current model though.
> What I hope doesn't happen is for REBOL to become like some other
> languages that are really only good for programmers because it just
> requires too much effort to set them up, use them, and learn about how
> things work.
Modularized Rebol will be good even for rookie ;)
"Where did you get all those facts!?!"