[REBOL] Re: Idea for [rebol.org]...
From: moliad:aei:ca at: 20-Mar-2004 22:13
IF you had a bad day, don't read this ... this reply is long, it includes
ranting and some clearly biased content...
I also want to say first-off that I respect EVERY member of this list.
especially those of you who've spent hours on end doing tools that many of us
use day in and day out.
> > To support the reusable/shared code approach in a general way, I think
> > we need to have some other pieces in place (e.g. how to organize and
> > define "projects", include other files, etc.). This is where RT comes
> > into play.
> > There are various INCLUDE mechanisms out there, but RT has
> > their own (PREBOL); which one to support?
slim !? ;-)
the name says it all, it keeps your apps slim.
hey, self promotion is healthy for the spirit ;-)
maybe I should work on the linker, so that packaging all of that code is
easier... it was supposed to be part of forge... I don't know... no one ever
> The one, that's available and works best. If there is an official one, we
> can use it and migrate things. Yes, not the best way but at least we get
> something done. Oh, and I think if we use a own made one, we can have some
> influence on the official version. I'm sure Carl is open to look at our
> stuff and happy if he doesn't has to think our all things himself.
Yet even when people do create API-like tools... the user base is so small that
there is not much feedback, except for the very widespread usefull stuff like
the async stuff. A lot of people are talking yet I do not sense a great need
for run time linkable code.
When I released slim, many people where saying that a dynamic loader was in
dire need. WELL I delivered something... something which is meant to releive
the programmers from stress of namespaces and which even allows you to rename
what is exposed. it supports nested libs, it prevents load cycles , even if
they are present, it even allows you to include a custom validation routine, to
make sure your code is in proper context.
It even includes an encompassed I/O system for a file sandbox of any package
files you need to load.
and on top of it I took 20 hours to document it...
Yet only one person gave me real usage feedback.
I'm not saying that I have the perfect tool, far from it... yet if no one tells
me how to make into what they want, or everyone says we need something and yet
they do not really try out what HAS been done... then I do feel there is a
little bit of irony in all this discussion.
As rebolers, I think we all want to use tools which we built ourselves... it
seems to be part of what coding rebol is meant to be... yet I think there are
many more people who would rebol if that where less true.
Many say, what's the point RT, will eventually " xxxx " ( fill in the hole )
.... IF we all wait until the miracle solution appears, then we will wait
forever. and be warned, RT does not always give that miracle solution. many
things within the standard release are flawed... I'm not saying rebol is
flawed, only that Carl, can't do everything right all the time (now I'm sure to
be torched... ;-). Things evolve and many of you have provided better
solutions to given problems. async ports, xml tools, ftp patch, mysql, etc.
even the vid 1.3 is based on many user submissions which have been around for
I have provided an attempt at filling a HUGE gap in rebol's arsenal, one that
comes back all the time in discussion. can someone at least try it... or tell me
what is wrong with it... tell me how to make it better, to explain this or
that... to even send fixed or better code for any given thing? yet so far,
only two persons have really done anything with it. one has sent me a list of
typos in the doc (which incidentally means he actually read it... thanks,
again) , and the other told me "thank you, that it was time for someone to try
to build and release a framemork of complimentary tools".
do I seem a little frustrated ? ... YES... I'm frustrated that people talk.
people wait. Yet many of you are working on excellent api-like tools. I'm not
saying that the Rebol community is a bunch of this or that. only that many
times, and on many distinct issues, it seems people here are scared of claiming
that maybe they ARE as good as RT in any given tool. For some reason, many of
you are scared of claiming that you are able and it seems that there are many
excelent modules, just ready to be united into a package, which given proper
support and user trial, would relieve RT of many issues...
I mean, do you think that I can do anything about porting view to MAC OSX....
nope. I'd rather have RT work on that. and adding C source code to effect's
pipe, fixing(documenting) the image datatype (which has been done, btw). adding
new binary functions which allow us to use external dll data directly, without
any slow conversion, etc... porting the new plugin to linux, mozilla, fill-in
your needs here, etc.
> > Package support is a great example. Should it be RIP, ZIP, RPM, doc'd,
> > with metadata, allow 'includes, etc. We talked about a lot of things,
> > and would still be talking if Sunanda hadn't taken the initiative to
> > get *something* out there for comment and use.
yess and it is an AWESOME engine... its documented and soooo easy to use. plus
If I'm not mistaken it uses an http transport, which means that you can use it
through a firewall and proxy which blocks most other ports...
> I agree it shouldn't be to formal. I think we should have a vision and
> some people taking care, that everything fits together. How a piece of
> code is done isn't that interesting...
yet it should also allow for diverging tools to be included together. as long
as they are usable in the same manner. The fact that two people have different
views on how a problem can be solved, should not prevent one from getting into
an "official" distro. Users will decide. and there might be tools which are
complimentary anyways. two peoples math libraries could provide the same
functions, yet have differing preoccupation. one might be precise, the other
might be fast. Equal yet not.
What I mean is that peer-review is good, yet because of rebol's do it yourself
nature, it should not be exclusive, it has to be inclusive. the group of peers
must not be the singular. It should be able to have more than one commity so
that different groups of coders can collaborate on different packages which
Might just include all the same kind of tools.
> if it's good it will be used, if not, than not.
not always true... other wise rebol's user base would quintuple in a month....
people need to be aware, they need to learn, and they need to be convinced that
switching to a new tool, is less hassle than continuing with a "lesser" but
I hated using python in the begining, but eventually, I found out that even it
has things which I miss in rebol. so both are good tools, yet have very
> > People can collaborate via REBOl.org. Scripts can be shared by
> > multiple owners, though I don't know how many people are using that
> > feature.
it needs promotion... something which should be made more obvious in a newer
site ';-) as are MANY other features.
> The big step is taken to get a team formed. I'm in good contact with
> a couple of people here.
The dream team ;-)
> And works great (IMO) but it takes time to get people interested and tell
them what you want to do.
Yet I find that the system should work like sourceforge where anyone can start a
new "peer review group" There should not be only one all encompassing team.
This means the same kind of tools can co-exist, yet have different mindsets.
none of them are inferior. I can say that I -like- a tool better than
another... nails or screws... some people prefer nails, yet some prefer screws.
both are fasteners, and both have advantages and disadvantages. If someone in
charge of a singular working group said that their box does not support screws
then what interest is there in that box for those who prefer nails? not much.
I'll finish with this:
REBOL is an excelent tool. It has an amazing community, it has Amazing
developpers, and its now starting to mature into a platform with amazing