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

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