[REBOL] Re: Threading continued
From: gerardcote:sympatico:ca at: 29-Jan-2004 23:48
Hello Max and MArteen,
What a great news,
If I can share some thought with both of you about the fact that producing something
of really great value - without knowing if the
number of real users truly justifies the effort - I would say YES for the following reasons
:
1. All the GREAT HIGH QUALITY tools that only a handful of HIGH LEVEL REBOL programmers
were and are able to produce here merit a
great RESPECT for the accomplishment and for PLUS VALUE they give to the rest of us current
programmers (no less good but generally
otherwise inclined) who want to learn from a practical POV about such things that would
be left inaccessible for most of us if you
were not there to show us the WHAT and HOW-TO carry out these wonderful things.
2. Second it is not evident to SELL those evolved tools to current not so low-level programmers
if they don't have the necessary
skills to potentialize your work or they don't have any need for them in the immediate
or worse yet if they don't see what can be
gained from them in their current day-to-day tasks. Will the ratio (Elapsed development
time vs Learning curve time) be in favor or
not for using these tools ?
This is generally the question you have to help your customers (that is other REBOL programmers)
answer to before they become
converted to your tools. Nobody wants to waste time to learn something he is not confident
if it will be useful to him.
3. I want to help you deploy the usage of your tools but I myself need more time to learn
the ABC's of using them and then help
others to get a smaller learning curve before they can use them too.
For example I'm sure Rugby can help me to remotely execute some script located on my
server and I will need this feature in some
scripts since I don't want to leave my sources in the hands of my customers - and for
now I have no sufficient money to invest into
the many toolkits RT is selling - but I don't know what else I can do for now. Wiil your
product fit my needs and will it be hard to
use. I'll try to get some DOC about it into the Library very soon. I will study it a
bit and I'll see but for sure I'd like to see
some DEMOS of the many uses someone can realize with it.
And for Max the same is true - although this time I read the DOC - with Slim and other
products you put online (Liquid being one of
them that I would like to use instead of directly using /View). But this requires time
and some basic REBOL knowledge and sometimes
advanced CS concepts too to cope with all this stuff.
Don't despair there will always be some EARS and EYES that listen, look and even wait
for the delivery of your products ... I'm one
of those.
4. Last but not least : Do it for yourself first - If you get some personal satisfaction
to deliver a real software engineering
wonder. Why bother if others want it too. Let's do it and may be after some time somebody
will even pay for your services. I don't
dream here. I'm serious. Think for your own benefits first and then others should come
after yourself. Don't lose sight of this
however : it the product is not perfectly finished and is not accompanied by some decent-reasonable
doc, it will never gain much of
the momentum and popularity it really should deserve.
So I'm a fierce supporter of your products and be proud of them - even if they are not
for the moment very popular. Keep up the
great work guys .
And just for terminating, Marteen I am curious about the way I could expect myself to
use your EVAL in collaboration with the actual
/View platform as a new way to eliminate some concurrency limits in a teaching/learning/simulation
perspective. Here is more detail.
I actually work trying to hack Carl S.'s easy-vid script to let /View start the execution
of another script using /Core or /View
(using do, launch and CALL with /View 1.3). I got many problems the most important being
REBOL blocks itself while the other script
is running and the console is closed upon termination while I would like to keep it open
for hands-on by the student following the
lessons displayed simultaneously in the first REBOL instance. Do you think you would
permit me to do this using your new tool ? I am
almost sure the answer is YES but I would nevertheless get your final advice on this.
----- Original Message -----
From: "Maxim Olivier-Adlhoch" <[maximo--meteorstudios--com]>
To: <[rebol-list--rebol--com]>
Sent: Thursday, January 29, 2004 1:31 PM
Subject: [REBOL] Re: Threading continued
> I think I know exactly how you feel.
>
> as an example, liquid, one of my brainchilds took a lot of time to mature (and its
about to undergo a new round of refinemnet).
It exists, and was shared and is available to anyone who asks for it (its now in slim
format, just not yet released)...
> liquid is really usefull, if you "get" it. Yet was it worth the "release" effort...
>
> I still don't know... I didn't get much feedback. I don't even know if anyone else
is using it... probably not.
>
> so as for your tool. as much as I'd like to say to python users that I can thread
executions of scripts (and do it better than
them, cause they can't remotely kill threads), at this point, I wonder how many tools
really need that functionality.
> Who writes servers in rebol... not many of us...
>
> How many people even use threads in python... not that whole lot either.
>
> I've had to, they (threads) are usefull, but with rebol's smaller user base... even
if 1% of us used(needs) it, you'd still have
a handfull of users, and many would use it just to see if it works... and if it goes
400% slower... not sure that's fit for server
usage in all circumstances... maybe someone who wants to create a networked front-end
for RebDB might want to introduce threading...
but will it help go faster in the end, if all threads run on one cpu (even in a multi-cpu
machine...).
