Carl ar Rebol, comment please :-) (was) Re: Re: language shoot-out :-)
[1/10] from: petr:krenzelok:trz:cz at: 4-Nov-2002 6:19
Joel Neely wrote:
>Hi, Carl,
>
>I started to work up REBOL versions to submit a while back; I got
>frustrated when the ackermann blew up with stack overflow at 7
>(the test calls for 8).
>
Well Joel, now as RT seems to be back to proper developer's support,
maybe Carl could organise a poll to see, what would developer's welcome
most in the next few months, year, two years period. My favorites are
(in no respective order):
user-level:
- exposing convolve mechanism for custom effects purpose (for those who
like to produce demos)
- partial compile (for those who are brave enough to loose a bit of a
dynamic fashion of a language and need crunching numbers - math, image
pixel manipulation)
- full async networking, including callbacks and async console, as was
suggested by Holger - open/async tcp://blabla.com:ble :my-callback-func
- upgrade to View (further draw development/mainly bugfixes!,
speed-up/native platform acceleration support, color text)
- better sound
- better XML support (more protocols)
profi (Command nad Pro?):
- threading support
- tail recursion (for Joel :-)
- ability to call into language API, extend it ...
- finishing security issues, as proposed at the end of following doc -
http://www.rebol.com/docs/ssl.html
- decide to a) upgrade fast-cgi and mySQL support or b) drop them, as
they don't seem to be on pair with current state of menthioned
technologies development
OK, maybe someone comes with another ones. The point is - developer
should not feel locked, or he/she will have to look for the solution
outside the rebol scope. The plan should be clear - to not further
isolate rebol in usage, but let developers spread rebol into various
interesting places of usage. Remember - one single project can bring in
attention of new audience, new developers - and in the end - RT can't
loose.
OK, now I will let Carl to announce, what gets implemented as the
upcoming Christmas' present ;-)
-pekr-
[2/10] from: gchiu:compkarori at: 4-Nov-2002 22:36
On Mon, 04 Nov 2002 06:19:42 +0100
Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:
>user-level:
>- exposing convolve mechanism for custom effects purpose
<<quoted lines omitted: 21>>
>OK, now I will let Carl to announce, what gets
>implemented as the upcoming Christmas' present ;-)
I would like: bug fixed and improved IMAP support for Xmas
:)
--
Graham
[3/10] from: carl:s:rebol at: 4-Nov-2002 11:36
Petr,
We are interested in making many improvements, but we are going to start
partitioning improvements into two groups: those that can be developed by
outside developers, and those that require changes to the kernel and must
be done inside.
Another problem that also comes up whenever I see a list like this: setting
priorities. For example, tail recursion is a nice dream, but would you
want it if it slowed down code execution? Remember, every additional check
added to the inner loop of an interpreter slows down everything. So, we
avoid that where possible. (Please don't lecture me on the benefits of
tail recursion, I've implemented it in several other languages, and know it
well.) Wouldn't you rather have REBOL running on portable devices instead?
So, priorities, priorities.
-Carl
At 06:19 AM 11/4/02 +0100, you wrote:
[4/10] from: gchiu:compkarori at: 5-Nov-2002 9:11
>
>I would like: bug fixed and improved IMAP support for
>Xmas :)
Oops, and also the "remove at" POP bug.
--
Graham
[5/10] from: petr:krenzelok:trz:cz at: 5-Nov-2002 0:35
Carl at REBOL wrote:
> Petr,
> We are interested in making many improvements, but we are going to
<<quoted lines omitted: 7>>
> everything. So, we avoid that where possible. (Please don't lecture
> me on the benefits of tail recursion,
I don't try to lecture you at anything. The list was just what came to
my mind. It was not actually "my" list of requirements. I just wrote it
down to show, that different ppl have probably different requirements.
And why? Because maybe each of us has slightly different usage for
Rebol, and that's only good. We just need to carefully choose, what has
the biggest priority. So, you just picked probably the least needed
feature from the list. But what about other ones? :-)
> I've implemented it in several other languages, and know it well.)
> Wouldn't you rather have REBOL running on portable devices instead?
Yes, as for me, - absolutly.
> So, priorities, priorities.
Yes, but I somehow can't believe, you at RT don't have any already ...
So, wouldn't a poll help? I am no marketing guy, so I don't know if it
would help, but maybe you at RT know average contract price for certain
feature to be implemented? That way we could take that price and count
number of product sales needed to cover the cost. Or there could be some
voucher mechanism - prepayment for upgrade, which would help finance the
thing, and once delivered, would offer total cost of product for those
who prepayd at some discount (that is model normaly used imo). Of course
I am not sure if it would work ... just trying to outline various
possibilities ...
-pekr-
[6/10] from: nitsch-lists:netcologne at: 5-Nov-2002 9:49
Am Montag, 4. November 2002 20:36 schrieb Carl at REBOL:
> Petr,
> We are interested in making many improvements, but we are going to start
<<quoted lines omitted: 6>>
> want it if it slowed down code execution? Remember, every additional check
> added to the inner loop of an interpreter slows down everything.
basically tail-recursion is a goto with arguments, replacing a call?
how about a special call-word, like
loop-less: func[a b][do-something if more[tail-recurse 'loop-less c d]]
> So, we
> avoid that where possible. (Please don't lecture me on the benefits of
> tail recursion, I've implemented it in several other languages, and know it
> well.) Wouldn't you rather have REBOL running on portable devices instead?
> So, priorities, priorities.
>
> -Carl
>
[snip]
-Volker
[7/10] from: bry:itnisk at: 5-Nov-2002 13:16
Carl at REBOL wrote:
> We are interested in making many improvements, but we are going to
start
> partitioning improvements into two groups: those that can be developed
by
> outside developers, and those that require changes to the kernel and
must
> be done inside.
When we talk about improvements that could be made by outside developers
then I think a good thing might be to have a number of scripts dialects
etc. bundled together as 'libraries', after all people are used to
downloading the xml library for a language. This would need some slight
redesign of the rebol web-site, replace library with Code Examples, make
a link to "Common Libraries".
[8/10] from: joel::neely::fedex::com at: 5-Nov-2002 10:35
Re: Carl ar Rebol, comment please :-) (was) Re: Re: languageshoot-out :-
Hi, Petr, Carl, and all,
Petr Krenzelok wrote:
...
> maybe Carl could organise a poll to see, what would developer's
> welcome most in the next few months, year, two years period. My
> favorites are (in no respective order):
>
...
> profi (Command nad Pro?):
> - threading support
> - tail recursion (for Joel :-)
Hmmm. Thanks for thinking of me (;-) but this is *not* on my list
of requests. At my current (but still evolving, of course ;_)
level of understanding, I view tail recursion elimination to be
incompatible with the design philosophy of REBOL. AFAIK TRE requires
either:
1) Code rewriting at "compile time" to replace what the programmer
expressed with something equivalent but faster/cheaper/etc.
or
2) Expression inspection by the interpreter at "run time" to allow the
interpreter to determine dynamically how to do something equivalent
but faster/cheaper/etc.
The problem with (1) is that the concepts in which it is stated just
don't exist in REBOL AFAICT. There's no difference between "code" and
data
, there's no "compile time", and e.g. the body of a function is
still expected to be a valid REBOL block (although with new context).
The problem with (2) is that it's expensive (unless enough use is
made to amortize the inspection overhead) and incompatible with the
totally dynamic character of REBOL.
FWIW, my list would probably (not well thought out) contain items
such as:
- Documentation.
- Mac OS X support equivalent to other platforms.
- Documentation.
- Addressing some of the performance and consistency issues already
raised on this list (to ease effective learning for beginners and
effective use by not-so-beginners).
- Documentation.
Some folks may wonder about my rating Mac OS X so highly (yeah... I've
read the how-to-set-priorities discussions over the years). First, in
the interest of full disclosure, my main personal box now is an iBook,
and I tend to restrict myself to tools that I can use on all of the
platforms I routinely use (Mac OS X, wxx, Solaris, Linux). However,
let me point out another issue here, that is not just my personal
preference:
Many Unix-/Linux-oriented publications are paying increased attention
to the OS X environment, and increasinly describing it at the best of
both
worlds: a Unix system "under the hood" but with a nice end-
user-oriented GUI for those suffering from commandlinephobia. I'm
seeing more articles written by or for serious Unix/Linux geeks that
are very favorable to OS X.
Yesterday I was in the local Apple store talking to the tech guy, and
he observed that they've had quite a number of programmers to come in
and pick up OS X laptops to use for Java development.
I respectfully suggest that presence on OS X would serve as a way to
get ahead of the curve
on a platform that seems to be increasingly
well-regarded by a couple of important communities (*nix and Java),
rather than waiting to see where the masses are and playing catch up.
Just my $0.02 ...
-jn-
--
----------------------------------------------------------------------
Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446
[9/10] from: jan:skibinski:sympatico:ca at: 5-Nov-2002 12:34
Joel,
> Many Unix-/Linux-oriented publications are paying increased attention
> to the OS X environment, and increasinly describing it at the best of
> "both" worlds: a Unix system "under the hood" but with a nice end-
> user-oriented GUI for those suffering from commandlinephobia. I'm
> seeing more articles written by or for serious Unix/Linux geeks that
> are very favorable to OS X.
>
Just my two cents about the above. I do not know OS X, but I was
quite impressed with NextStep several years back. If it was not
for such a poor support for drivers I would be still using it -
despite
the fact that that OS has been scrapped for whatever reasons.
Bad company policy perhaps. So if OS X is similar or better than
NextStep I can understand your feelings towards OS X.
Jan
P.S.
Regarding the drivers: installation of NextStep on Intel box
once took me about three days until I was able to select and
collect compatible hardware. With many failures, crashes
and new reinstallations in meantime. And of course, the NextStep
team, small as it was, was not able to keep up with support
for new hardware gadgets.
The only thing I disliked in NextStep was its lack of support
for virtual consoles. Although one could always switch from GUI mode
to text mode, but in the event of GUI (Display Postscript) crash
the entire system would freeze. On Linux one just goes
Alt-Ctr-F(number)
to enter a virtual console and to recover by simply killing X window.
[10/10] from: rgaither:triad:rr at: 5-Nov-2002 12:43
On Tuesday, November 5, 2002, at 11:35 AM, Joel Neely wrote:
> FWIW, my list would probably (not well thought out) contain items
> such as:
<<quoted lines omitted: 5>>
> effective use by not-so-beginners).
> - Documentation.
I like this list as well though my order would be slightly different.
1. Bug fixes
Those mentioned for November plus a few others that I suspect
fall into that performance/consistency group Joel has noted.
2. Documentation
The new FAQ is a step in the right direction but we need a whole,
more comprehensive approach to documenting the world of REBOL.
It isn't enough to know something is there without any explanation
of why or how it works.
3. Mac OS X support equivalent to other platforms
4. Library Project
This goes along with #2 as a critical part of providing the resources
new developers (and even existing ones) need to be effective.
On the Library and Documentation points I think it is very important
to realize just how the power of this "little" language requires a
large
amount of material to present it properly.
> I respectfully suggest that presence on OS X would serve as a way to
> "get ahead of the curve" on a platform that seems to be increasingly
> well-regarded by a couple of important communities (*nix and Java),
> rather than waiting to see where the masses are and playing catch up.
I too am using an iBook as my primary machine and for exactly the
same reasons. I have never owned or used a Mac before being a *nix
and windows guy up until middle of this year. OS X has the right stuff
and I think you will see more and more support from the developer
community at large as they explore it.
FWIW, Rod.
Rod Gaither
[rgaither--triad--rr--com]
Oak Ridge, NC USA
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted