[REBOL] Re: OT, was Re: What's Native
From: mauro:fontana:speedautomazione:it at: 23-Jun-2004 16:42
On Wed, 23 Jun 2004 14:12:31 +0200, Petr Krenzelok <[petr--krenzelok--trz--cz]>
>> Still REBOL is not that "efficient" when speaking of memory usage.
> No, it is not, that is for sure. Nor is Mozilla in comparison to IE. We
> suffer because of that, because porting rebol onto mobile devices will
> not be trivial. But maybe also in a year or two it will not be an issue
> anymore, as even today's PDAs have 64 - 128MB RAM. OTOH:
Yes, and that is just enough to run Java applications as well...
> - we are currently choosing some additional products to our SAP system,
> middleware one. We were adviced for the system to work properly (purely
> Java based), it needs at least 2GB RAM. Now that is really hilarious. So
> - before you tell us Rebol UI consumes too much of a memory, please just
> show me native Java UI. I saw one with 50K USD product - man it sucked
> and Cyphre's tree-view would beat it speed-wise, whatever-wise pov you
Well, it depends on the performance/throughput the application needs to
I may also think that CPU with 4MB of syncronous cache are hilarous, but
then when speaking of high performance computation....
Do you think rebol can provide the same functionalities with less
Can you think you can make a tool like Opera/Mozilla with rebol?
Yet, you can blame them for being huge and somewhat slow, but they win
hands down when speaking about features and easiness of use.
> - I was OO programmer too. We used CA-Visual Objects here. Objects are
> fine, but those widgets are pretty well hardwired. If they don't provide
> you with certain method, you can do nearly nothing to change that. You
> can override some functionality, but that is all. Once we wanted to add
> e.g. background image onto main screen, we had to hack two page strict
> win32 code into our app. Simply because window class of CA-VO did not
> provide us with that. And here comes beauty of compositing system of
> View - it is just rectangle area to draw into + event system - you can
> hack whatever UI element you want, if you are skilled enough. Not having
> good docs is main obstacle right now, but I hope it will change.
Well, are you suggesting that graphics framework should be made of simple
point, line, triange, rectange and such?
Of course with those basic objects you can do whatever you want.
But try to have an auto scaling/flowing/adaptive GUI and you'll see that
the work neede is more complex than tracing simple gfx objects.
> Last six months I brought my another friend to Rebol. He really
> complained about text-list, list etc. styles having somehow unfinished
> functionality etc. I showed him Cyphre's work - he told me he could not
> imagine it is even possible. I explained him basics of face based
> composition (non VID) and in a week he showe me his own grid style. Now
> he works for some company using some strict OO tool too and he often
> mentions - if I even had oportunity to use View - I could change what I
> want about UI element. All I can say is - simplicity.
Maybe I'll get flamed here, but... I'm just realistic.
Rebol is a good scripting tool. But it is just a simple tool.
Whatever you say about rebol can be said about every other scripting
language. And some of them are much more "advanced" than rebol (some of
them have modularity capacities and can be fully integrated into the
Some of them have also better support from 3rd party applications (like
However I can't see anyone of them entering the main stream as
alternatives for languages with (bloated) GUIs (or simply compiled ones),
but they are used as they were thought: as scripting languages.
I know it is sad, but again, the GUI functonality has its own importance.
Sorry for my english.