[REBOL] Re: Hitting the learning curve
From: gedb01::yahoo at: 5-Nov-2003 14:42
Thanks Petri,
Your post helped clarify my thinking a lot. I wasn't
arguing for the form or object based approach, I was
trying to point out that these langauges have a task
flow. VB encourages me to build forms and Java
encourages to build objects. They both offer lots of
support for the creation of these.
>From my rather ponderous start, I think you have
pinpointed what are my 2 main issues:
- Lack of documentation
- "I have all and I have nothing at hand"
It seems that Rebol encourages me to do just one
thing: to abstract.
You suggest just taking the Java approach, and I
could. The problem is that it doesn't feel right.
When working for Java the is a massive amount of
repitition. You just accept this as being part of
java, and there are tools like IDEs and Code
generators to help.
When I try the same approach in Rebol, it feels wrong.
One of the main appeals of Rebol is that all that
typing can be generated. Instead of creating a set of
interfaces and objects to describe my model of the
real world, why not create a dialect to succinctly
describe the model.
This, I think, is where I hit the problem. While
Rebol gives me tools to create abstractions, it
doesn't give me any help to manage them.
With Java I have Javadoc, class browsers,
autocompletion in my IDE. There are so many tools to
help me deal with the object structures being created,
either by myself or somebody else.
With Rebol this help does not exist. This is
particularly accute when using somebody elses dialect,
such as view. Once I have consumed the documentation,
the only option is to either read the source (which
I'm not advanced enough to understand yet) or use
trial and error (which is time consuming and
unreliable.)
Fortunately, Rebol is so much fun to play with I keep
going. However, though I love to play with it when it
comes to getting some work done I find I can't quite
use it.
--- Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote: >
> Ged Byrne wrote:
>
> >[...]
> >
> 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
=== message truncated ===
