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

evaluation result (or... goodbye)

 [1/27] from: maarten::koopmans::surfnet::nl at: 2-May-2002 20:43


Thanks for sharing this. Having started in a new environment I feel your pain. Sadly I find myself doing more and more in P&P (Perl & Python) as they *do* interface with the rest of the world and have a vibrant community. Let alone the license policy... It's a tough conclusion, and if things change I may return to be a REBOL again. For now.... goodbye --Maarten On Thursday 02 May 2002 18:56, you wrote:

 [2/27] from: laplace:worldnet at: 3-May-2002 11:32


A study of researchers shows that many decisions are taken long BEFORE technical arguments are presented and that those arguments are above all used to confirm decisions already taken than to objectively evaluate the best solutions. In some cases Java is better, on other cases it is not. So I don't think that people has to generalize and I don't understand why there is a long list about Java as this is a mailing list about rebol.

 [3/27] from: sunandadh:aol at: 3-May-2002 8:50


laplace:
> So I > don't think that people has to generalize and I don't understand why there > is a long list about Java as this is a mailing list about rebol.
I appreciated Boris' analysis of the language needs for his project. It clearly shows up the strengths and weaknesses of various software platforms, Rebol included. Carl Sassanrath is on record as saying that Rebol is for "programming in the small". The available documentation (for which he is also on record as saying "is horrible and I apologize profusely"), the lack of debugging tools, the lacklustre support for developers (Feedback @rebol.com is almost entirely one-way), and confusing and off-putting commercial licensing terms all make the point that it is nowhere near ready for "programming in the large". Which is a pity. RT have achieved miracles and produced a potentially world-beating software platform. Sunanda.

 [4/27] from: jason:cunliffe:verizon at: 3-May-2002 6:01


Maarten ...good luck in the new environment. It could be worse.. Python does have a great community, incredible tool chest http://www.vex.net/parnassus/ and is lots of fun too. Thanks. Au revoir ./Jason ______________________________________________ Jason Cunliffe [NOMADICS: Director art+design] Tel/fax: +1 718 422-1078 [jasonic--nomadics--org] N 43:00.000' W 074:31.875' ALT:1144 ft 84 Henry Street #3C Brooklyn NY 11201 USA ----- Original Message ----- From: "Maarten Koopmans" <[Maarten--Koopmans--surfnet--nl]> To: <[rebol-list--rebol--com]> Sent: Thursday, May 02, 2002 2:43 PM Subject: [REBOL] Re: evaluation result (or... goodbye) Thanks for sharing this. Having started in a new environment I feel your pain. Sadly I find myself doing more and more in P&P (Perl & Python) as they *do* interface with the rest of the world and have a vibrant community. Let alone the license policy... It's a tough conclusion, and if things change I may return to be a REBOL again. For now.... goodbye --Maarten

 [5/27] from: pharguindey:bancobisel:ar at: 3-May-2002 10:45


I agree... BTW Java was born like the desktop all-purpouse app-killer.... but it never take off in the desktop.. (do you remember the Corel Office?? :-), all the stupid NetPC marketing noises???, The end of propietary OSes!, The true Programing once run everywhere ... (Yes... if you have a eternal life to keep waiting ) Now it'seems that Java it's claimed like the "server" option.... Please give me a break..!!! JAVA The wrong solution for a inexistent problem -----Mensaje original----- De: laplace <[laplace--worldnet--fr]> Para: [rebol-list--rebol--com] <[rebol-list--rebol--com]> Fecha: viernes 3 de mayo de 2002 0:29 Asunto: [REBOL] Re: evaluation result (or... goodbye) A study of researchers shows that many decisions are taken long BEFORE technical arguments are presented and that those arguments are above all used to confirm decisions already taken than to objectively evaluate the best solutions. In some cases Java is better, on other cases it is not. So I don't think that people has to generalize and I don't understand why there is a long list about Java as this is a mailing list about rebol.

 [6/27] from: carl:cybercraft at: 4-May-2002 1:01


On 03-May-02, laplace wrote:
> A study of researchers shows that many decisions are taken long > BEFORE technical arguments are presented and that those arguments
<<quoted lines omitted: 3>>
> to generalize and I don't understand why there is a long list about > Java as this is a mailing list about rebol.
I thought that a good post, especially as Boris had been asking the list for advice. A useful way to say thankyou for the feedback he'd received, as even though REBOL wasn't chosen, it's feedback in return. Think of it as a comparison of REBOL and Java (and other software) and not as a post to start a discussion about Java. People may look at REBOL and try to work out what useful things they can do with it, while others like Boris will have a particular need and look at REBOL to see if it's the right tool for the job. There's more likely to be success with the first scenario than the second at the moment, but evaluations like Boris's may help to up the hit rate for the second if notice is taken of them. -- Carl Read

 [7/27] from: rotenca:telvia:it at: 3-May-2002 17:05


Hi, Sunanda
> Which is a pity. RT have achieved miracles and produced a potentially > world-beating software platform.
Is typical of Amiga world from the ancient times: wonderful programmers, unsurpassable software, poor support, wrong alliances, self-destructionist marketing. --- Ciao Romano

 [8/27] from: maarten:koopmans:surfnet:nl at: 3-May-2002 17:13


> laplace: > > So I
<<quoted lines omitted: 5>>
> Carl Sassanrath is on record as saying that Rebol is for "programming in > the small".
But it isn't. You can program in the large with the language as is. It is more than good enough.
> The available documentation (for which he is also on record as saying "is > horrible and I apologize profusely"), the lack of debugging tools, the > lacklustre support for developers (Feedback @rebol.com is almost entirely > one-way), and confusing and off-putting commercial licensing terms all make > the point that it is nowhere near ready for "programming in the large". >
These things are true. I understand that they need to pay their bills. OTOH: so do I. And I am not that much into religion. I am into working solutions. And if Rebol doesn't do the job for me because all of the marketing problems, bad luck.
> Which is a pity. RT have achieved miracles and produced a potentially > world-beating software platform. >
I agree again. But it is very hard to make money on a software platform (look at Borland over the last ten years). If I were them (which I am not), I would have two versions of Rebol: Command and Command/View both for free. Then the Rebol Dev kit with Encap for $500 with unlimited redistributable licenses. *Then* I would start selling IOS. But I am not RT, and I hope they have good luck in what they try. It will be tough though. The only way to make money is by doing large volumes which is why you need a full--blown feature-set. Look at PHP, Perl. Python isn't that succesfull in terms of profit, Borland has been struggling for years. So I see the need for a solution based approach (IOS), but even then the lack of communication is not very appealling. Experiencing another environment puts these things into perspective, which isn't necessarily that good. I hope the best though.... REBOL is by far the best software engineering product I have encountered and i *do* like the people at RT a lot. Hope they'll make it work. --Maarten

 [9/27] from: laplace:worldnet at: 3-May-2002 19:14


I have many critics about rebol myself I will post about that one day. But as for this mail I talk about the details not about the principle of criticism (which I vote for). About the of what I have read there's nothing more than techno-marketing arguments that Sun promotes. That's why I have the impression that the decision was alreday taken and that arguments were just to apparently "rationalize" the decision. Shortly saif the argument could be resumed by "We take Java because it is Sun". So no need to make a long study about that. I have been consultant for somme Multinationals and I have some clients that asked me to justify TECHNICALLY their decisions to the management. So whatever I would really think is useless, I have to only find "good" arguments for the client.

 [10/27] from: pwoodward:cncdsl at: 3-May-2002 14:32


Wow - actually a pretty good evaluation of various technologies and the reasons to adopt them (or not) at an organizational level. While I personally enjoy REBOL, using it daily for a variety of tasks, and to test out programming theories, it's hard for me to recommend it to a large organization. Although in my current position, there is a good chance that we may develop a 2.0 version of our product using IOS in spite of the barriers, because we believe that the benefits REBOL can bring to the table may outweigh it's hurdles. Currently I've been doing a lot of programming in Java. My last 7 years of programming for hire have spanned 68000 assembly, C, C++, FoxPro, Access, Java, Visual Basic, SQL, PL-SQL, Perl, ASP (VBScript & JScript), Lotus Script, PHP, Lite, Python, and REBOL. I've used REBOL since it was available for download, and have also used Java since it's beta (although I took a break until Swing got settled in). Every language has a place, some are just really good at doing certain things. Also I'm a stong believer in not re-inventing the wheel where possible. Java is good. There's a reason it's been widely adopted. I don't think REBOL is going to slay Java, nor was it set out to do so. Java and Rebol can co-exist, along with C, C++, and dozens if not hundreds of other languages. When I have to explain things to my friends who are non-programmers, I usually use something along the following: With earlier languages like C, you have to really work hard to solve the problem at hand. You have to be concerned with not just your problem (say, how to calculate payroll) but with problems imposed on you by the underlying computer hardware - memory allocation, etc. In the "old days" you had to be really smart, and keep track of a lot of things in order to write software. With newer languages like Java, you don't have to be as concerned with the underlying details. You can largely focus on the problems at hand, instead of writing a memory manager, or other "implementation detail". In essence, Java and languages like VB are lowering the barrier to entry. Making it possible for mere mortals to program usefully. Sure, this isn't always a good thing, but, using Java or REBOL really makes me appreciate the underlying work that has gone into them so that I don't have to think about irritating details (until I find a bug). - Porter

 [11/27] from: carl:cybercraft at: 4-May-2002 10:56


On 04-May-02, laplace wrote:
> I have many critics about rebol myself I will post about that one > day. But as for this mail I talk about the details not about the
<<quoted lines omitted: 9>>
> really think is useless, I have to only find "good" arguments for > the client.
Fair enough. But that kind of "decision"-making also represents one of the obstacles REBOL has to overcome if it's to gain wide acceptance, so it doesn't hurt to see it in action. And even if that was the case with Boris's post, his "Rebol was rejected for not allowing direct multi-threading, for its singularity on the market and for very trapping licensing policy." are not new criticisms on this thread, are they? Especially with regards to its licensing policy. Other criticism in his post was "for the serious project our 2-week familiarity may not be enough, but there are no Rebol experts around." Fair enough, surely, though note the "If use it anywhere, the first choice is probably to ask sys-admin guys to install it for inter-company communication, get used to it and then think of further usages." If they did that, the next time they consider REBOL they may have some experts around. Also asked was "what serious projects had used Rebol?" There's been some hints here that it is being used for serious commercial projects, but can you point to any article on the web describing one? It's still seriously under the radar in that regard. There's Morpheos of course, but the new, perhaps-REBOL-powered version didn't appear in April as promised. (Or hadn't when I looked near the end of the month, anyway.) If a REBOL-powered version does appear and it's good then it'll do a lot to advertise REBOL, but until then, who's openly using REBOL in a big way? (As apposed to those who may be sensibly keeping it secret least their competitors start using it too.) -- Carl Read

 [12/27] from: sunandadh:aol at: 4-May-2002 3:28


Maarten.Koopmans:
> > Carl Sassanrath is on record as saying that Rebol is for "programming in > > the small". > > But it isn't. You can program in the large with the language as is. It is > more than good enough.
We may be disagreeing no what is large and what is small. But Rebol does have some limitations that can trip you up very early on. I know some of these are being relieved (e.g. IOS link doubles the number of available variables) but even so, 8000 (the IOS limit) is not enough. Try these three snippets (you'll need a new console after the first one) to find the fundamental limits on your machine: (the third may run for hours in a machine with insufficient real memory. It only takes moments with 384k). ;; ----------------------- ;; Maximum different variable names print length? first system/words nn: 1 print mold disarm try [ forever [ to-word join "Var" nn nn: nn + 1 ] ; forever ] ; try print length? first system/words ;; ----------------------- ;; maxium stack depth recur: func [nn [integer!]] [prin [nn " "] recur nn + 1] recur 1 ;; ----------------------- ;; maximum memory (or block size) print system/stats ;; memory in use nn: ["X"] print mold disarm try [ forever [ append nn nn ;; double the length print [now/time/precise length? nn] ] ; forever ] ; try print system/stats Sunanda.

 [13/27] from: brett:codeconscious at: 4-May-2002 22:55


I'm intrigued.
> But Rebol does have some limitations that can trip you up very early on. I > know some of these are being relieved (e.g. IOS link doubles the number of > available variables) but even so, 8000 (the IOS limit) is not enough.
What would require 8000 variables to run? Has anyone hit the current limit in a production application? Just Curious. Brett.

 [14/27] from: sunandadh:aol at: 4-May-2002 9:35


Brett:
> What would require 8000 variables to run? Has anyone hit the current limit > in a production application?
I've got dangerously close: up to 3500 out of the available 4000 for pre-IOS/link. (Rebol alone takes nearly 2200 so I "only" use 1300). I'll cheerfully admit that part of that is bad design -- I'd do it differently if I was recoding with what I know now. (The application displays a gallery of photos. The user can select the dimensions, eg 5x7. Each photo/VID object needs a name in the workable-but-bad design. If someone wants 50x100 that'd be 5000 names). The application also lets the user add fields to a toy database. Record are Rebol objects, and fields are variables in the objects. If the user adds another 500 unique field names (unlikely, but never underestimate how far a user will go) that'll blow the 4000 limit. If the 2.6 adds substantially to the 2200 variables that 2.5 uses without increasing the 4000 total limit, this application could be due for a rapid rewrite. Sunanda.

 [15/27] from: rotenca:telvia:it at: 4-May-2002 16:35


If one uses many small functions, can easy re-use the same words. I have a function with 37 local words: almost none is new. If RT corrects the set/get bugs with unloaded words, we would have no real limits. --- Ciao Romano

 [16/27] from: greggirwin:mindspring at: 4-May-2002 9:58


In regards to global word limits, and the concept of reusing words, this is something Bertrand Meyer promotes in the design of Eiffel and its Base libraries. The goal is not to reduce words usage, but to provide consistent interfaces. For example, every dispenser class uses the same method names (add, remove) rather than having specific names for each type (e.g. a stack would usually use Push and Pop as method names). This way people learning the library have a greatly reduced set of terms to deal with and new classes, which conform to this practice, are easier to understand and learn. If you look at the built-in REBOL functions, you'll see this in practice for parameter names (value, block, word, name, etc.). If we follow that convention, usage is kept in check, at least to some extent. Sunanda's example, where names are generated dynamically, is obviously a special case and, as he said, it's a situation that is fixable for his example app. In the early days of VB, there were some pretty harsh limits that people started bumping up against eventually. People didn't complain about the limits so much (they could be worked around), but they complained loudly because the limits were "soft". The documentation on exactly what the limits were, or how you might hit them based on the way stuff was declared, or *where* it was declared, and what VB did in the background, made it difficult to know how close you were. Worse, it wouldn't just tell you when you hit a limit. Your app might run fine...most of the time, but, occasionally, it would just lose its mind and do some flaky things. Very scary. I wrote a simple tool that became very popular (VBSpace). All it did was scan your code and make an educated guess about how close you were to certain limits. Not 100% scientific, but people could avoid the problems by playing it a little safe when things got into the questionable area. To sum up, of *course* I want unlimited space to build big systems. That said, I can live with the current limits for now, and we know those will be raised shortly. As long as the rules are laid out, and we know where we stand, it's not an untenable situation. --Gregg

 [17/27] from: rotenca:telvia:it at: 4-May-2002 17:53


Hi all, a patch for check: svvf/check/redraw: func ["patched by ana" face act pos][ all [pos: find face/effect 'cross remove pos] if face/data [insert face/effect 'cross] if face/colors [face/color: pick face/colors not face/data] if face/effects [face/effect: pick face/effects not face/data] ] Brett, if you like, you can put it in your patches.r --- Ciao Romano Paolo Tenca

 [18/27] from: carl:cybercraft at: 5-May-2002 12:28


On 05-May-02, Romano Paolo Tenca wrote:
> If one uses many small functions, can easy re-use the same words. I > have a function with 37 local words: almost none is new. If RT > corrects the set/get bugs with unloaded words, we would have no real > limits.
So you're saying that in a case like this... func1: has [a b c][some code or other] func2: has [a b c][some other code] there's only ever a single instance of 'a 'b and 'c in existance at any one time? Does that also apply if 'func2 calls 'func1? -- Carl Read

 [19/27] from: brett:codeconscious at: 5-May-2002 10:53


> Brett, if you like, you can put it in your patches.r
Suprised that has not surfaced before. Ta :^) Brett.

 [20/27] from: brett:codeconscious at: 5-May-2002 10:49


> So you're saying that in a case like this... > > func1: has [a b c][some code or other] > func2: has [a b c][some other code] > > there's only ever a single instance of 'a 'b and 'c in existance at > any one time? Does that also apply if 'func2 calls 'func1?
It is not so much how many instances of 'a, 'b and 'c are around - more that the names of each of these three words count toward the word limit. Imagine a spreadsheet where each row label is the name of a word! and each column represents a context that words can be bound to. A given word might have a few entries in different columns of the spreadsheet corresponding to different instances of it in different contexts, but the number of rows cannot grow beyond 4000 (not sure of correct number). Not entirely sure if that helps, but I think it is relevant :^) Regards, Brett.

 [21/27] from: rotenca:telvia:it at: 5-May-2002 12:15


Hi Carl
> So you're saying that in a case like this... > > func1: has [a b c][some code or other] > func2: has [a b c][some other code] > > there's only ever a single instance of 'a 'b and 'c in existance at > any one time? Does that also apply if 'func2 calls 'func1?
There are many instances of 'a 'b 'c around, but the limit is only about the number of different words in the global context, the object! pointed by system/words. But "These words are locals", one can say! Correct, but every time the system loads some new code, the sistem by default add all its word to the global context. If a word is already in the global context, it is not added. Only when the code is executed the words of your code become local.
>> print length? first system/words
2509
>> use [foo][] >> print length? first system/words
2510 ; foo is added to the global context
>> use [foo][] >> print length? first system/words
2510 ; foo is already in the global context and is not added
>> func [foo][foo: 2] >> print length? first system/words
2510 ;foo is already in the global context and is not added It is Load and the implicit Load at Console and Do level, which add new words to the global context. I do not know why Rebol make this, I find it unuseful at all. There is a workaround, but a bug in get and set makes its use very limited. You can find an example at my rebsite: http://web.tiscali.it/anarkick/gcmask.r If RT corrects the bugs, we could write all the code without adding a single word to the global context. To end, when searching the name for a new word one can check this list to find a word to re-use: request-list "global words" sort first system/words --- Ciao Romano

 [22/27] from: rotenca:telvia:it at: 5-May-2002 12:20


Hi Brett, if you like to change layout, you could correct this line also: | 'sense set value block! [new/feel/engage: func [face action event] value] the correction: | 'sense set value block! ([new/feel/engage: func [face action event] value]) --- Ciao Romano

 [23/27] from: brett:codeconscious at: 5-May-2002 21:46


Hi Romano, Conducting a clean of the REBOL code? :^) Is there any point to using sense (once fixed)? Looks to me like it could produce more problems than it is worth. Regards, Brett.

 [24/27] from: rotenca:telvia:it at: 5-May-2002 14:00


Hi Brett,
> if you like to change layout, you could correct this line also: > > | 'sense set value block! [new/feel/engage: func [face action event] value] > > the correction: > > | 'sense set value block! ([new/feel/engage: func [face action event]
value]) Correction of correction: :-) | 'sense set value block! (new/feel/engage: func [face action event] value) --- Ciao Romano

 [25/27] from: rotenca:telvia:it at: 5-May-2002 23:28


Hi Brett
> Conducting a clean of the REBOL code? :^)
:-)
> Is there any point to using sense (once fixed)? Looks to me like it could > produce more problems than it is worth.
At what problems are you thinking? At shared feel objects? Perhaps a make feel [engage: ...] should be used? Do you suspect that this is an "intentional bug" of RT? --- Ciao Romano

 [26/27] from: brett:codeconscious at: 6-May-2002 10:19


Hi Romano,
> > Is there any point to using sense (once fixed)? Looks to me like it
could
> > produce more problems than it is worth. > > At what problems are you thinking? At shared feel objects? Perhaps a make
feel
> [engage: ...] should be used?
Yes, I was thinking about the affect on a shared feel object, but I also wonder if there is any use for it at all. Maybe it was part of an earlier grammar for layout that is now obsolete (because of action blocks) and was never actually removed. Have you an example of how it could be used? Regards, Brett.

 [27/27] from: rotenca:telvia:it at: 6-May-2002 15:03


Hi Brett,
> Yes, I was thinking about the affect on a shared feel object,
Another little thing is that normally engage function is bound to the feel object, for example the cue function normally is in the feel object.
> but I also wonder if there > is any use for it at all. Maybe it was part of an earlier grammar for layout > that is now > obsolete (because of action blocks) and was never actually removed. > > Have you an example of how it could be used?
Many times i want to change only the engage field 1) to pass more info to the action function, for example the event object (to check control/shift keys with mouse). 2) every time i want to use over/away actions, i must rewrite engage, because Vid usually does not offer a hook for them like action/alt-action. 3) time events often requires to rewrite engage. 4) I could want only a selective show face, to hide the face from an action function. 5) sometimes i do not want cue 6) sometimes i want different on state for different event types .... Yes i can do all with the feel word, but this is true also for font facets or edge facets, nevertheless we use no-wrap, bevel, font-size xx instead of font [size:...] edge [...]. Almost all useful facets have layout shortcuts, i can live without them but writing code is more easy with them. The same, i think, for sense. I must say it is not documented, but many are undocumented things in Vid, like map in list, for example. --- Ciao Romano

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