[REBOL] Re: Hitting the learning curve
From: petr:krenzelok:trz:cz at: 5-Nov-2003 14:17
Ged Byrne wrote:
>I've read the recent 'losing the case' thread with
>interest.
>
>Personally, I've just come to the end of my honeymoon
>with Rebol.
>
>I've been throwing to gether 5 line scripts that do
>what pages of Java or VB do in 5 pages. I've stopped
>saying 'Wow,' and I'm starting to ask 'How.'
>
>The problem is that, given a blank piece of screen,
>where do I begin when devising my own code to solve my
>own problems. What is the starting point.
>
>Different languages have their own starting points.
>In VB I start with a blank form, dropping controls and
>then writing the event handlers.
>
Well, I can tell you one thing. I didn't like that aproach. I worked
with VO, which was not so form based (which is imo bad aproach anyway),
but with main window, defining menu, what menu items refer too, etc. - I
hate those delphi/VB MDI apps. But that is not the point - even with VO,
there was lot's of unneded stuff predefined in form of prebuilt apps,
templates (even changeable but anyway) ... all this stuff provides you
own logic of how child windows are stored, referred too, dbases
organised etc. To not end with kludge, our team did exactly following -
deleting whole stuff and astarting with main loop - we build our own
system framework, classes, applied some DOS based keyboard navigation
thru whole IS, we have done things like localisation and remote
automatic update, we removed registry crap dependency etc. - and we were
lucky .....
>In Java I start with an object model. I identify my
>objects with methods and properties and then start
>composing the relative classes.
>
That nearly seems as ideal case for project goals identification, but
then I don't understand, what is your problem with rebol? If you are
able to identify your goals with java, why not using rebol? After all -
IIRC someone created class/method aproach for rebol too ...
>In Perl or Ruby I start with the input stream, usually
>a file, and start heading for the output stream.
>
I don't understand here ....
>What is the starting point with Rebol? Given a
>problem and an empty .r file how do I start growing my
>problem? With a form to enter the data? With a set
>of objects? With a set of functions? By defining a
>dialect?
>
Hmm - as I said - you have to learn how to correctly identify project
goals and how to fulfill them. Deciding between objects, functions,
dialect - is after step. I will try to define my aproach later, but let
me get back to dialects:
I don't know if I am alone, but Rebol dialects (or dialects in general)
can be cool thing as well as they can become very tricky. Rebol dialects
are completly free form, so dialect author can introduce stuff looking
as coming from Mars, as well as it can look as any other programming
language :-) The problem is, proven using VID, that dialects don't fit
rebol language correctly. I tried to think about it for a while, but I
am not sure, how you can eg. dialect to work with official rebol help?
How can you know (talking VID now), what styles are available, what are
their facets? Not to mention "catastrophe", when you need to mix dialect
with rebol level (button "OK with [rebol-code-here]) - you suddenly deal
with whole underlying View infrastructure - and once again - there is no
help mechanism for objects, so the only thing you are left for in the
case of object is to 'probe it - I can guarantee you, that only handfull
of ppl understands how styles are constructed, when does it happen, how
whole event mechanism flows etc etc.
Now general question - has anyone thought how to make this situation
better? I am not sure there is an easy answer. As far as VID is
concerned, I propose:
- VID 1.3 - provide users with more robust and encapsulated styles
(tree, grid, tabs) so ppl will not need to touch underlying engine too often
- fix inconsistencies and bugs
- new level of docs are imo needed - View engine description, working
with events, effects at face level ... show how to build UI in non VID
fashion. Then start to explain VID, e.g. single button style ... explain
how and when certain things happen and show us how to customize button
and build own style "get-style 'button" output is far from being enough ...
But that is just VID of course ...
>There seem to be so many approaches, but no single
>method affords itself?
>
OK, one other problem I can see with rebol is - lack of frameworks.
Maybe I now understand your java aproach - maybe you have "I have all
and I have nothing at hand" feeling with rebol. Sometimes I have feeling
that if you want to do something using rebol, you have to start over and
over again - from scratch ... missing more general mechanisms to work
with. I don't want to use async:\\whatever kind of stuff - I want RT to
decide what is good and what not, and if it is good it should be added
to rebol, simply to provide such common base to all of us. Or e.g.
things like Medusa multi-protocol server framework with plug-in system?
I know top gurus here will say - you can do it yourself, but imo if
common base = Rebol is not updated and does not provide such
mechanisms, it can't grow - it will push ppl to start over and over
again ...
Last case was IOS. Last year I asked RT for IOS desktop sources, because
I wanted to sell IOS here and I simply need Czech language ... I offered
them to send them Czech translation strigns, but was said that such
aproach is not affordable. I still can understand them, but that is
something I regard negative marketing - look I am no marketing guy, but
common sense tells me something is wrong here. Imo there is bad
identification of business case - IOS development would be much more
vital, if RT would open the desktop and provide IOS in the form of SDK.
What is any tool good for, if I can't properly adapt it to my
conditions? At least IOS situation looks a bit better last months as
there is someone who cooperates with RT on its further development. But
if not, I dare to say that such "marketing" decision only helps to kill
otherwise excelent product.
The problem of community:
It can be said by one sentence - Rebol has not reached critical mass of
developers. We can see it in the case of projects - as Max said - there
is noone to help. Even top developers have their main daily jobs, so
they have less and less time for rebolling, or simply can't afford to
donate more free time to rebol. It happens to all of us ...
I too, was asked several times - stop talking and show us some code. And
I say - stop talking BS if you don't understand there is several levels
of team roles needed :-) Well, really - you can code, I can do testing,
someone other docs, someone other can define product design etc etc. Can
we tell what role is more important than other one? And so it happens.
How could it be changed? Honestly - I don't know, but maybe following
would help:
- more RT (Carl's activity) in a leaader role
- RT identifies area to solve, sets coordinators, they choose team, team
works ... (I think library project worked similar way ...)
- but as I am not talking only about rebol based apps, but rebol
development itself, RT's participation is absolute necessity ... that is
one of reasons why 1.3 VID failed ... team reached some decision points,
but talking to Carl once per 2 - 3 months is really not enough ...
So ... if RT has enough money to survive curent way ... let's be it and
I wish them millions, really :-) ... but ... times goes by and other
technologies development don't sleep. I always ask myself - how can
rebol survive in a current state of things? ... and honestly I prey
REBOL not becoming another Amiga ...
That is my opinion on identifying basic rebol related areas ... I hope
they are not offending, as they were not ment that way anyway ...
-pekr-
