[REBOL] Re: What language am I looking for?
From: petr:krenzelok:trz:cz at: 13-May-2001 17:23
----- Original Message -----
From: "Ken Anthony" <[kenneth--nwinet--com]>
To: <[rebol-list--rebol--com]>
Sent: Sunday, May 13, 2001 6:13 AM
Subject: [REBOL] What language am I looking for?
> Hi all,
> I've followed the discussion of scope with regard to Rebol with some
> concern. The idea that variables that are all static and global does not
> give me the warm fuzzies (or that you have to declare variables local in a
> function. Just the act of declaring them should make them local.)
Hmm, maybe it was done so to keep things "easy"? Simply - if you want to
define your word local, you have to state it. Or use the 'use block, or
create separate 'context ...
> Another thing that bothers me is that redefining a word should be
explicit.
> If I have to remember every word in an application before adding another
> then that is placing a burden on me that computers were made to carry. It
> would be fine if there was an "Option Explicit", but protect and unprotect
> misses the point.
OK, maybe Rebol modules system, as it was planned (but nowadays RT is silent
about it), will cover your needs. But also remember - the main rebol concept
is - "series" - lear more about series and maybe things will be a little bit
cleaner for you .. (http://www.rebolforces.com/series.html by Ladislav
Mecir)
> I'm a VB programmer these days because that's the language the project was
> written in when I joined my present employer. We do have to use C where
> it's the only option, although I personally haven't touched the language
in
> years. The project has about 700,000 lines and hits a database with over
a
> hundred tables. I need to be able to write this kind of application in my
> language of choice.
I am not sure Rebol is ready to handle it. We miss components. Rebol chosed
to finisn many of usefull functionality first, instead of finishing main
language concepts first - one of them being run-time dynamic components. We
currently have several rebol products, and sometimes RT doesn't want to
inculde feature x or y, because rebol executable size would grow fast. Once
components will come, it will allow
a) per component pricing
b) one kernel thru all rebol apps, which in turn means that change in
component doesn't require you to update/download all your rebol product.
c) if rebol.exe grows to some over 1.44 MB, it will be bad :-), while it
would not look so drastic, if separate math, sound, streaming media etc.
took 500KB each.
You will surely miss rebol data browser, which I am thinking about to write
(no free time yet), as I don't find scrolling lists the way to go, while
they are usefull in most cases. We need strong columnar data browser, with
abstracted data connectivity API, caching, etc., so only visible data +
cached data are in memory. Long lists make rebol app resource hungry beast
...
One other thing - RT code is not compilable - so no speed-up, sorry. Using
rebol runtime will allow you to hide your sources, but that's all - no
speed-up
BUT - on the other hand - bear in mind that RT provides us with library
component, so you can put your heavy stuff into library, but you probably
lose some of multiplatform advantages, but with clever app design (isolated
layers) it should not be much of a problem ...
But - rebol is young ... and ... rebol is cool. We all hope many things
will come (e.g. modules, components, async. networking protocols, maybe
threading). Rebol also stil waits for killer app to appear. :-)
Cheers,
-pekr-
