[REBOL] Re: [Bot] email command Bot
From: maximo:meteorstudios at: 26-Mar-2004 12:24
Hi,
some text might be a little hard to follow, I wrote this over the course of several hours..
poking at it here and there... ;-)
> Yeah, it's a subtle thing, but I would like to see native optimized
> functions to access DB and do XML parsing/building. 3rd party
> libraries,
> how good they can be written, keep getting interpreted which is a
> disavantage IMHO.
there is a pro version... if you need speed, that is bound to be because you are in a
corporate environment or are developing tools as a consultant, then a little investment
shouldn't be that big a deal.
google is powered by python... and I don't see python's slowness being an issue. they
propably link to compiled modules or dlls, which we can easily do in rebol (dll)...
in any case, rebol only has few natives...
and some things inside rebol aren't absolutely stunning either... i.e. many user tools/patch
are better than the RT code (and RT does include a lot of that code into subsequent releases.).
> > /Command version contains direct mySQL access, but maybe
> DocKimble could
> > compress his mysql.r into binary format, so you would not see its
> > internals and only API would be left for you, which is
> plain simple -
> > open, insert, copy, close :-)
>
> See above. That's whay I would also like to see soon a mod for Apache
> instead of having to constantly call Rebol interpreter for doing CGI.
well, there is something called rebol.dll which looks promising :-)
I'm sure they will expand into other platforms as soon as they can.
>. other thing may be Maxim's Slim -
> > module system - Robert asked us to try that on AltME world,
> and I will -
> > maybe it can solve some dependency problems etc.
> >
> > The problem with Rebol community is, that each of us uses
> some slightly
> > different aproach, and that we can't somehow agree upon
> some "standard",
> > where others would use it and build upon it ...
rebol's strenght (i.e. "do your own") also makes it hard to WANT to play with others...
listen, even though I've done slim and wish it to improve and expand and be widely adopted,
I'm the first to admit, that I like to code my tools.
The reason I built slim, was not so that a select group would integrate an exclusive
rebol object framework.
I built it so that everyone can package his code in a "documented" specification and
then maybe one day, others will write tools which use that specification and create autodocs,
or builds a sandbox which is inserted into slim, or (insert your idea, here).
if this happens, everyone which wrote a slim gets access to those tools and can forget
about writting his own for such boring things.
we can even suspect that other loaders could come to be... as long as they conform to
the specification, any slim package can then be used by it and benefit from its particular
features/extensions.
slim also makes it easier for new commers to accept external tools. in a sense, if you
take the time to explicitely package it as a module, then there is better chance that
you put more thought into the api, and that you -EXPECT- your tool to play with others...
in any case, slim shields you from name conflict and goes a long way into making the
process pretty painless.
Also remember that many newcommers to rebol expect modules to be a part of rebol and
it CAN help them to organize their work environments much more quickly if they have only
one module/loading api to understand...
and a series of modules which deal with given problems.
> Yes, that's what I meant. Using external calls as they are
> now makes the
> main advantage of rebol (portability) useless.
but even in python, you have to compile the sources ... for each platform.
creating a VP isn't the most trivial of things... but RT COULD port a version of rebol
for one of the good VPs out there like TAO, or maybe even java byte code... still its
a major undertaking I'm sure.
> I like to use
> whatever is
> provided integrated in the interpreter which I think as optimized in
> speed/memory usage and is always available.
remember that putting "everything in" , like you say, could transform rebol into another
"bloat ware" . anything that is added in a default distro can never be removed afterwards.
if they decided to put mySQL by default, then what happens if it falls from vogue?
we end-up with a huge pile of legacy code that is virtually useless to 99% of us.
I'd rather like us to be able to COMPILE natives and link them in by using industry-standard
C++ object modules. just like python and others do it.
for my part, I'd like an os module to exist, which maps more of the os data into one
platform-independent library... things like current user name, environment variables,
temp files handling, , threads, directory mappings, etc.
there are already many things in rebol which are more transparent than in many other
languages (like file! paths :-).
But when doing multi-os corporate-wide deployment, it comes to a point where you have
to use a (python, tcl, bat, whatever) script to load your rebol app with the system
info in arguments... and that's not very pretty ... ;-)
my two cents,
keep what you like, kill the rest ;-).
-MAx
