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