Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

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