Why I'll pay for REBOL/command (or not). Was - Will REBOL/View be comme
[1/4] from: pa::russo::perd::com at: 22-Sep-2000 17:05
>/***************************************************************************
>*****
<<quoted lines omitted: 5>>
>****************************************************************************
>****/
I agree with Elan's analysis wholeheartedly and I want to share with
some concept from a business letter I'm preparing Rebol Tech's
marketing staff.
Why I'll pay for Rebol/Command eventually
------------------------------------------
Rebol/Command is fairly priced. I can gain far more than the
$300-$500 in a variety of ways, _IF_ I can use the whole family of
REBOL products.
First, I can cut development costs, if I can really write-once, run
everywhere. With the "ugly threesome" I have to do a lot of testing,
literally for each browser version on each platform.
Second, Rebol is so compact, I can deliver my killer-application by
e-mail. That's rebolutionary and it opens the door to a whole new
world of applications.
Third, it takes a lot of time to train a software engineer on
HTML/XML+Javascript+Java. He can learn REBOL in a far shorter time.
So I can reduce training costs.
Last, but not least, REBOL's productivity is terrific.
So REBOL is something I'm happy to pay for... but I'm saying it's
REBOL as a whole environment that it's worth his money.
REBOL/Command is mainly, if not exclusively, a server-side tool.
That's crystal clear.
So...
Why I don't pay for Rebol/Command now
-------------------------------------
Basically, because I don't have a clear roadmap for Rebol/View development.
I believe it's /View, a free /View, that makes the difference with
other solutions. But today we don't have a hint to the release date.
So, I can't plan to develop a couple of important applicationsusing
REBOL because I can't guarantee a delivery date. REBOL/View could be
released tomorrow or next century as far as we know.
Moreover, quite ironically for a 40+ platforms product, I can't use
it to develop my applications because it falls very short from
covering my market. I have no idea about the release time for the
Macintosh version, the second delivery platform as share in the
common user market. If I don't have a Mac version, I lose about 30%
of my educational market and I doubt Amiga, BeOS or Linux versions
could amend for this.
So what is that I need to choose REBOL as my preferred development tool?
------------------------------------------------------------------------
1. I NEED A CLEAR ROADMAP.
I have to plan my work myself and I need to know if and when a tool
will be available.
2. I need /View.
It's the trojan horse for the client-side. It's a free /View that
makes the difference from a marketing viewpoint. And because it's a
client-side tool, I need first the Windows version,and immediately
after the Mac one. Then I have all my market covered today. Then we
can think of Linux, BeOS, etc.
3. I need to deliver my client-side script in such a manner that none
can look at my code.
This is coming as a /command runtime. Obviously, I expect it to offer
also the /View features.
4. I need a robust server-side tool.
I already have it. It's REBOL/Command.
Finally, what is that I'll be glad to pay for?
----------------------------------------------
My technician soul likes REBOL, very much. I want it to stay alive
because I want to work with REBOL. And I want to reward the men who
brought REBOL to us.
But my manager soul would like to pay for support more than for
products. Seeding, assistance, counseling, training, tech news,
etc... about the family of the REBOL products as a whole... that
would be the real value to me.
--
Paolo Russo
[pa--russo--perd--com]
_________________
PERD s.r.l.
Virtual Technologies for Real Solutions
http://www.perd.com
[2/4] from: petr:krenzelok:trz:cz at: 23-Sep-2000 16:33
> Why I don't pay for Rebol/Command now
> -------------------------------------
> Basically, because I don't have a clear roadmap for Rebol/View
development.
> I believe it's /View, a free /View, that makes the difference with
> other solutions. But today we don't have a hint to the release date.
<<quoted lines omitted: 8>>
> of my educational market and I doubt Amiga, BeOS or Linux versions
> could amend for this.
Let's say everyone of us has his/her needs for the products. Let me add my
own ones:
I need REBOL/Command and REBOL/View to work together. We've changed some
main concept of our CCD camera, so maybe I will be able to overcome /command
at all, but not sure yet, waiting for our hw guys to decide ... BUT, if I
will need to use some library calls, and would like to offer GUI front-end,
then it's clear I will need /Command and /View together. You know why can I
see RT's policy as failure?
- I am asking one stupid, really stupid question for more than a half a
year. I can't get the same kind of really stupid :-) answer. If I will
regard Carl as having official word for the company, I would think they will
deliver what I need, if I understood him correctly. I remember him stating
something in regards to /Command and on-demand loadable components. IF it
was true, then /View component would be loadable to /Command. But there is
no separate /View component available and marketing department answered me
the requested modularity is not the way to go. Then I repeated my question,
how do I get /View component being available for /Command? Bzzz ... no
answer yet. Maybe Elan thinks I want to use new modern technology for old
purposes, while I would like to offer something new and maybe exciting to
academic and amateur astronomers. I think RT would gain much more thru
presence in various fields of usability by not being so strict about product
usage (e.g. freeing /Library and /Shell components for free or low fee /Core
usage, but making it really pluggable/unpluggable) .... I just yesterday got
to rebmail website and keep smiling while seeing Carl talking about
plug-ins, while opposite is true for REBOL itself ...
I use Visual Objects from Computer Associates here at work, but I really
apreciate CLEAR roadmap for existing products - "planned for 3.0, next
version, not planned, 1Q2K1, interface for 3rd party add-ons" etc kind of
answers ...
I am really confused by seeing all that "BUY IT" links thru website, while
not being able to read end-user/developers agreement before I buy. It really
makes me laught :-) What should I base my decision upon, if I don't know
anything about the form of app delivery to customers? I am e.g. interesed in
form of delivering solution using /Library component, while letting people
adjust my code ... Is there any kind of solution, while preventing our
customers from buying /Command for XXXUSD? You mentioned run-time /Command
version. I've never before heard about anything like that :-) Will it solve
my needs? Will runtime isolate library calls e.g. while steel allowing users
to adjust scripts? So many question ....
> So what is that I need to choose REBOL as my preferred development tool?
> ------------------------------------------------------------------------
<<quoted lines omitted: 6>>
> 4. I need a robust server-side tool.
> I already have it. It's REBOL/Command.
Hmm, now I can see I am not alone having similar requirements ...
I think RT had enough time (more than 3 years?) to define strategy. We are
customers, we are REBOL supporters, we would like to get REBOL to our
customers, now RT - show us the way how ...
PS: If I will decide to write my articles for our magazine I mentioned
yesterday, I want to have clear answers, to prevent myself fooling people,
as I expect the same kind of questions going my way ....
Thanks a lot,
Cheers,
-pekr-
[3/4] from: tsummerfelt1:home at: 23-Sep-2000 9:24
On Sat, 23 Sep 2000 16:33:03 +0200
[petr--krenzelok--trz--cz] wrote:
> I need REBOL/Command and REBOL/View to work together. We've changed
as an intermediate solution, you could always throw a tcl/tk front end
around your rebol/command programs...of course you may find tcl/tk so
easy to work with (and complete) that you end up switching to it
completly :)
> > 1. I NEED A CLEAR ROADMAP.
coincidentally, there is a tcl/tk roadmap (for the 'free' and 'commercial'
aspects of the language)
[all the rest of your points are easily covered by tcl/tk]
the only real reason i added rebol to my language toolbox was the easy
of net related programming.
at the moment it's much easier to throw a tk front end to rebol programs
than it is writing rebol/view...
i would think that i'm not alone in saying that most programmers can't
be tied down to one language. rebol offers quite a bit to programmers,
but i don't find it the end-all solution to every programming problem.
at this point i wouldn't want to maintain a rebol program much more than
50 lines long. it's taking me longer to wrap my mind around rebol than
it did python. and unfortunately i keep bumping into brick walls that
have no answers in the docs...
.t
*--------------------------------------------------------------------------
|
| http://members.home.net/tsummerfelt1
|
*--------------------------------------------------
[4/4] from: petr:krenzelok:trz:cz at: 23-Sep-2000 19:13
----- Original Message -----
From: <[tsummerfelt1--home--com]>
To: <[list--rebol--com]>
Sent: Saturday, September 23, 2000 6:24 PM
Subject: [REBOL] Why I'll pay for REBOL/command (or not). Was - Will
REBOL/View be commercial? Re:(2)
> On Sat, 23 Sep 2000 16:33:03 +0200
> [petr--krenzelok--trz--cz] wrote:
<<quoted lines omitted: 3>>
> easy to work with (and complete) that you end up switching to it
> completly :)
Ah, I've investigated several scripting languages. If I would not go with
REBOL, I would probably go with Python. I saw also tcl/tk, but no impression
here :-)
> > > 1. I NEED A CLEAR ROADMAP.
> coincidentally, there is a tcl/tk roadmap (for the 'free' and 'commercial'
<<quoted lines omitted: 4>>
> at the moment it's much easier to throw a tk front end to rebol programs
> than it is writing rebol/view...
hehe, then I will sound as REBOL zealot :-) Heh, show me easier and more
open gui set-up than we have using VID ;-) You can't :-)
> > i would think that i'm not alone in saying that most programmers can't
> be tied down to one language. rebol offers quite a bit to programmers,
> but i don't find it the end-all solution to every programming problem.
We just need RT to clear some issues a little bit, to stop holding language
development back (e.g. we need /draw, /math, /sound etc stuff) and if RT
will have only 10 or so programmers and will limit us, they are slowly
killing language. I still believe they will see some sense in moving into
one rebol.exe and component architecture, and making /library free. You will
start to see many interesting custom solution in certain areas of usability
coming. Limiting REBOL to net stuff is plain stupid ...
> at this point i wouldn't want to maintain a rebol program much more than
> 50 lines long. it's taking me longer to wrap my mind around rebol than
> it did python. and unfortunately i keep bumping into brick walls that
> have no answers in the docs...
Hmm, how long are you programming in REBOL? It's pretty readable on my side.
Well, I havent studied some 50K of source yet, would be interesting :-)
-pekr-
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted