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

The day before, the day after, time to leave? ...

 [1/9] from: petr:krenzelok:trz:cz at: 22-Sep-2000 7:23


Hi, the day before I left for my business trip, I answered to Bo's email sent to Phoenix ml asking why evyryone talks MS C# but not REBOL/View, so let's start with it: ----- Original Message ----- From: <[bo--rebol--com]> To: <[phoenix--phinixi--com]> Sent: Wednesday, September 20, 2000 7:19 PM Subject: RE: [PhX] C Octothorpe
> Rennie and others, > > I am wondering why there is so much hype about C# but so little in the
media
> about REBOL? I'm not just asking this because I work at REBOL, it's
that
> I really want to know. REBOL is available on almost every 32-bit
platform
> and every binary is supported by the same company. Can Java, C#,
Perl, or
> any of the others say that? Also, REBOL embraces the epitome of
interpreter
> theory and design unlike its competitors. > > Did you know that you can download a beta (Experimental) of REBOL/View
for
> several different popular platforms that includes a graphical network > script upon startup? It's available at www.rebol.com. There's an
annoying
> bug to work out in the Amiga version that doesn't allow the script to
launch
> other scripts from the interface, but at least you can get a feel for
it
> until the bug is fixed (it's still a beta after all). > > Hey, there's even a visual layout editor available for REBOL/View.
We've
> got a lot of fervent interest, but why isn't the whole world going mad
about
> it? > > Perhaps you can see better than I as I'm looking out from this side of
the
> glass wall. > > Curiously,
Bo, you know me man :-) I am starting to sound to myself as constantly complaining guy here, but well, I can see the reasons for that: I think RT marketing strategy failed. You have product defined, but who organised any series of interviews etc? Look at your history part of website. There were articles on Rebol at least one per month. I endlessly times asked about clear signal about pricing policy: 1) Got no answer thru ml 2) I can see RT strategy as chaotic sometimes - look at product announcements (e.g. Command two years ago), /Browse, /Tool etc. which are probably cancelled 3) I have some private pricing info from Tom and have to say I think RT is gonna kill REBOL ;-/ I just hope for: - clear definition of product and pricing strategy really soon now. I also offered to set separate ml for such issues ... - separate pricing for /Command and /Express. I HOPE I am not wrong thinking price levels Tom discussed with me moved to /Express solution, freeing /Command for hobbyist - or even more openly - move /Shell and /Library into /Core for free! /Core language concepts are stable enoug! Each other language has ability for extensions, some of them are open sourced. Look at what is RT doing. We have /Apache based upon /Core. So we have Apache module with no database support, it's just silly and I really can't understand how RT wants to get mid-web developers involved, as there is PHP for free with MySQL(and other format support). We have /Command with database support but only one way we can call /Command is via CGI. But NO Apache admin will leave PHP module in favor of CGI. What's more - we still don't know /Command pricing ... - RT should imho concentrate upon consulting, /Express is the right way and I sincerely hope enough effort is being put back into core technology development/advancement - if RT thinks big guys are the way to go - so be it. But technologies like ICQ, Gnutella, Napster became popular thru public presence. In real - NOONE in big companies cares about some REBOL or so. I work for big company very near management and know how things work. Big guys choosing another's big guys products ... - do /Browse plug-in and go at least for Mozilla, Opera bundle. I can assure you /View forms with type checking etc. would be cool ... - we miss some more media stuff, some global support functionality for image effects support (matrice operations), simply areas enabling ppl come to REBOL and bring new stuff. Without /Library and /Shell being in /Core language we are doomed. I have no time for MySQL library wrapper, so I would surely buy one from RT, just move it to /Core ... OK, we are with you 4 years Bo, now let's see what RT strategy is going to be about. I like REBOL so much I am really scared of answer .... Friendly, -pekr- ---------------------------- The day after. I can see strong discussion about /Command release on the ml. The discussion itself reflects something. It wouldn't be needed, if something RT shows us wouldn't be worth calling a failure. Alen, please, don't be disappointed at Ted's opinions. I have to agree with Ted on many issues (although I don't care so much of open source). Look at it from another perspective. How long are we asking about feature list and bug list being publicly available? Nothing happened. Look at what is RT doing. The form of announcement - one even can't know what is he/she buying. No licence agreement describing in what way could we as commercial developers use the product before we buy? What's that? I don't understand what I am buying from the info being present on website and it costs me half the sallary here. I like REBOL technology so much, I like also certain people at RT. I just start to loose my faith in RT itself, which seems to behave like shadow company with unclear/not-transparent-enough strategy changing every two months. Elan, as for /View, I am not sure the product will make it. Your opinions are right in many ways, you just forget something ... You mention /View spread to the public usage. But - you forget to mention RT LIMITING the usage. RT refused modularisation of REBOL as they don't believe it would bring them some money. They refused /Browse as they are not sure about its success. In opposite, - me, as a customer, would accept model as one and only /Core, with possibility to buy and plug-in what do I like, what do I need - e.g. just /Library and /View, e.g. just /View and /Shell, e.g. just /ODBC, etc. Now we've got /Command which component behavior we can't influence? Great, I can tell you I need two products - /Command with /View being in one, and /Apache + /Library for MySQL library wrapper. H*ll, I would even pay RT for small few kb MySQL wrapper Jeff did. And even 100 USD if I know that 1) I have no time or skills for developing it myself 2) will know it could become killer solution, once modules capability is added into /Core, as CGI is not what web dev. community will turn back to easily. Isn't /View great for forms e.g.? You can very easily check an entry is of type email for e.g., can't you. If RT would make /Browse at least for few browsers, bundle it, maybe it would be the way how developers/users would start to see the oportunities ... ... Time to leave after four years of loyality? PS: I like REBOL so much I would even pay for being present on some established channel for those being interested to having some at least limited access to some info of "REBOL glimpse of future" ... Sadly, -pekr-

 [2/9] from: dado:slovkaufring:sk at: 22-Sep-2000 8:28


> Hi, > > the day before I left for my business trip, I answered to Bo's email > sent to Phoenix ml asking why evyryone talks MS C# but not REBOL/View, > so let's start with it:
...
> ... Time to leave after four years of loyality?
...
> Sadly, > -pekr-
Very nicely written Pekr! I guess I can only agree. REBoL is very cool, it even changing (evolving) very fast (although it's been four years now, as Pekr says), but it does it as if it was a RT's _toy_ and not a product. Actually I can see no REAL _product_. Many things can be done with REBoL, very easily... but many things can't be done, because of thing Pekr described. You know what these things are. We did (not particullary I did...) asked for them starting on the early days (execution of external programs, libraries etc.) which have finally appeared in /Command, but are actually needed in the very heart of REBoL, /Core. And many other things that have distracted many, I believe. Always a REBEL, Jano

 [3/9] from: rebol:techscribe at: 22-Sep-2000 11:47


Hi Petr, Hi Jano, I believe that many things Petr said make a lot of sense ... to a degree. There are two competing, equally valid views of REBOL: - REBOL as a new tool to do NEW things. - REBOL as a new tool to do OLD things. Your criticism of RT's approach is based on the view of REBOL as a new tool do OLD things. I.e., how well does REBOL replace the tools we have been using all along (shell scripts, PERL, Tcl/TK, Visual Basic ... ) to do OLD things, such as integrate different applications, use OS services, conditionally launch applications, etc. This demand is natural. REBOL is such a well-designed tool to DO THINGS that - having invested the effort of learning REBOL - one immediately wishes one were able to use REBOL to do all those OLD things that one has to do all day. I think that in Carl's mind (well, I really don't know what's going in Carl's mind other than what I conclude from his design of REBOL) REBOL is intended as a tool to do NEW things in a new way. Things that have not been done because before, because the OLD tools did not inspire doing these new things, because the old tools are too clumsy to even begin to think about doing NEW things. I think RT should continue to remain focused on REBOL as a tool to do NEW things. They should encourage a visionary approach to using REBOL. They should not get caught up in trying to make REBOL the more convenient tool for doing OLD things. Why? Because if they are going to compete with established tools (some of which have been around 10 - 20 years), they have too much catching up to do, not only in terms of specialized support for legacy technologies, but also in terms of breaking through the lethargy of people who are set in their ways and have been solving the exact same type of problems in the exact same way for ten, twenty or thirty years. And to the degree that we enjoy using REBOL and desire to make REBOL a tool we can use daily in our professional life, we should be brainstorming about the new things that can be done with REBOL instead of complaining about how well REBOL manages to replace the old tools we have been using all along. How can we, for instance, use REBOL to improve the way we continue to OLD things using OLD tools? Can we implement a meta dialect in REBOL that will enable us to use REBOL to compile high-level task descriptions into executable PERL, Tcl/TK, Java or C++ scripts and programs? Which problems in a corporate context are not being tackled with existing technologies because of the limitation inherent in these technologies? Can REBOL be used as a basis to provide solutions to problems that are not being tackled because it is not feasible to attempt to solve them using anything but REBOL? More about that shortly. At 08:28 AM 9/22/00 +0200, you wrote:
>> Hi, >>
<<quoted lines omitted: 18>>
>REBoL, /Core. And many other things that have distracted many, I believe. >Always a REBEL, Jano
;- Elan [ : - ) ] author of REBOL: THE OFFICIAL GUIDE REBOL Press: The Official Source for REBOL Books http://www.REBOLpress.com visit me at http://www.TechScribe.com

 [4/9] from: ryanc:iesco-dms at: 22-Sep-2000 12:18


[rebol--techscribe--com] wrote:
> I think that in Carl's mind (well, I really don't know what's going in > Carl's mind other than what I conclude from his design of REBOL) REBOL is > intended as a tool to do NEW things in a new way. Things that have not been > done because before, because the OLD tools did not inspire doing these new > things, because the old tools are too clumsy to even begin to think about > doing NEW things. >
Excellent point! --Ryan I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein

 [5/9] from: petr::krenzelok::trz::cz at: 22-Sep-2000 22:38


----- Original Message ----- From: <[rebol--techscribe--com]> To: <[list--rebol--com]> Sent: Friday, September 22, 2000 8:47 PM Subject: [REBOL] The day before, the day after, time to leave? ... Re:(2)
> Hi Petr, Hi Jano, > > I believe that many things Petr said make a lot of sense ... to a degree. > There are two competing, equally valid views of REBOL: > > - REBOL as a new tool to do NEW things. > - REBOL as a new tool to do OLD things. > > Your criticism of RT's approach is based on the view of REBOL as a new
tool
> do OLD things. I.e., how well does REBOL replace the tools we have been > using all along (shell scripts, PERL, Tcl/TK, Visual Basic ... ) to do OLD > things, such as integrate different applications, use OS services, > conditionally launch applications, etc. This demand is natural. REBOL is > such a well-designed tool to DO THINGS that - having invested the effort
of
> learning REBOL - one immediately wishes one were able to use REBOL to do > all those OLD things that one has to do all day. > > I think that in Carl's mind (well, I really don't know what's going in > Carl's mind other than what I conclude from his design of REBOL) REBOL is > intended as a tool to do NEW things in a new way. Things that have not
been
> done because before, because the OLD tools did not inspire doing these new > things, because the old tools are too clumsy to even begin to think about
<<quoted lines omitted: 4>>
> for doing OLD things. Why? Because if they are going to compete with > established tools (some of which have been around 10 - 20 years), they
have
> too much catching up to do, not only in terms of specialized support for > legacy technologies, but also in terms of breaking through the lethargy of > people who are set in their ways and have been solving the exact same type > of problems in the exact same way for ten, twenty or thirty years. > > And to the degree that we enjoy using REBOL and desire to make REBOL a
tool
> we can use daily in our professional life, we should be brainstorming
about
> the new things that can be done with REBOL instead of complaining about
how
> well REBOL manages to replace the old tools we have been using all along. > How can we, for instance, use REBOL to improve the way we continue to OLD
<<quoted lines omitted: 7>>
> anything but REBOL? > More about that shortly.
OK, pressed for the time too now. Very nicely written, you should continue in writing books :-) But, to the topic, just one point: Even REBOL is based upon OLD technologies - it uses old TCP/IP at lower level, it uses whole OS infrastructure, it is written in old good C. You know, I know many managers coming to our big company stating - hey, I will show you, how things should work and will change it. But just after some time they always recognize, some things are as they are, because praxe shows us it's just the best state for that things to be in. And so - what about another technologies? Are they all old in comparison with REBOL? I thought RT wants to survive, and that's I thought they need to introduce something competitive. Do you find Command in form of CGI competitive or NEW aproach? Or do you want to suggest me replacing my Apache and let /Command become my new web server? It would make sense for certain (new kind of) services probably, but ... OK, later, have to leave now ... -pekr-

 [6/9] from: mjmalpha:localnet at: 22-Sep-2000 17:05


<SNIP> > I think that in Carl's mind (well, I really don't know what's going in > Carl's mind other than what I conclude from his design of REBOL) REBOL
is
> intended as a tool to do NEW things in a new way. Things that have not
been
> done because before, because the OLD tools did not inspire doing these
new
> things, because the old tools are too clumsy to even begin to think
about
> doing NEW things. > > I think RT should continue to remain focused on REBOL as a tool to do
NEW
> things. They should encourage a visionary approach to using REBOL.
They
> should not get caught up in trying to make REBOL the more convenient
tool
> for doing OLD things. Why? Because if they are going to compete with > established tools (some of which have been around 10 - 20 years), they
have
> too much catching up to do, not only in terms of specialized support
for
> legacy technologies, but also in terms of breaking through the
lethargy of
> people who are set in their ways and have been solving the exact same
type
> of problems in the exact same way for ten, twenty or thirty years. <SNIP>
I can't agree w/ the idea that employing REBOL to do OLD things is less valuable than NEW things. In my company, we're very interested in using REBOL for both OLD and NEW applications, and *especially* old ones. We have the need to acquire data from the Internet in many different forms/formats and parse it into more strategically organized forms. While some would argue that Perl or Python may be the best tools for the parsing aspect, I feel that REBOL has great potential for expressing automated processes in a far more cohesive, understandable manner --- and that has great value for purposes of software design collaboration and maintenance. I want our company's software to be readable with the least amount of "religious content". And while that may mean that I can't hire from a burgeoning pool of REBOL experts in the same way that I might in the Perl or Python world, so what? Anyone schooled in Perl or Python worth their salt can learn REBOL, and do so fairly effectively, IMHO. There are, after all, many OLD problems that need to be solved again and again as a matter of practicality -- why not employ innovative technologies like REBOL if they provide advantages such as readability, or economy of expression, or dialecting that serves a company's problem domain in an elegant, simple way? By the way, I try to make it a practice not to hire lethargic programmers that have done the same things the same way for the last ten, twenty, or thirty years, but hey, that's just me... (Uh oh ... my soapbox is coming apart under the weight of this argument ...... :) Mike Mastroianni

 [7/9] from: eoconnor:fei at: 22-Sep-2000 17:16


Amen, Elan. It's an uplift to hear those thoughts expressed. Focus on the new: peer-to-peer, collaboration, dialecting, new concepts in user interfaces, design of custom protocols, knowledge management etc. Heck, I'm not nearly as excited about the network protocols supported by REBOL as I am by the specialized ones that may soon be written by you, or any of the other gifted REBOLs on this list. I think some of the souring notes on this ml stem from the frustration of trying to make REBOL outperform some of the older, more established languages. It's not an easy comparison; if we were talking in terms of building materials, it'd be like comparing gravel to putty. REBOL is now good enough to begin writing useful NEW programs. If you're excited about technology, there's no shortage of great new solutions to build (if you've been living under a rock :^), let me know and I'll supply you with links). For example, I'm really in dire need of creative, hands-on REBOLs to help lay the foundation for Rebmail: we can't let this app be a mere replica of an OLD email client. Concentrating on the new things is easier said than done. So many of the old things were done so poorly or are so overly complex that it's hard to let them go (come to think of it, you polish-up some old-style examples in TOG, no?). Wasn't the 10-line webserver cool, though? I hope that RT finishes up the REBOL foundation it's been working on and focuses on building a mind-blowing /Express product. From what I can see, it's their obligation and best hope for a sizable revenue stream. I look forward to your next book. --Ed

 [8/9] from: kolla:nvg:ntnu:no at: 23-Sep-2000 0:30


On Fri, 22 Sep 2000 [ryanc--iesco-dms--com] wrote:
> [rebol--techscribe--com] wrote: > >
<<quoted lines omitted: 6>>
> > > Excellent point!
Except.. what new stuff? Where do I want to put computers in use now, where they're not already? -- kolla

 [9/9] from: news:ted:husted at: 22-Sep-2000 22:44


On 9/22/2000 at 11:47 AM [rebol--techscribe--com] wrote:
> Which problems in a corporate context are not being tackled with
existing technologies because of the limitation inherent in these technologies? Can REBOL be used as a basis to provide solutions to problems that are not being tackled because it is not feasible to attempt to solve them using anything but REBOL? I think the description of /EXPRESS on REBOL.COM sums the corporate context nicely. It would be wonderful to see this implemented as a support system for REBOL. This would solve several problems, inside and out. Just as /COMMAND didn't stop you from writing your own DBMS, Elan, I would suggest that we not let /EXPRESS forestall development of similar projects. Competition may not seem like an effective use of resources, but given human nature, it's the only way to achieve the best results. -Ted.

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted