[REBOL] Re: Is Rebol OO?
From: nitsch-lists:netcologne at: 12-Jan-2004 14:58
Am Sonntag 11 Januar 2004 22:56 schrieb Jason Cunliffe:
> > function. There is much more to using it than meets the eye. And I
> > believe not yet enough examples or use of dialects for most people to
> > understand
>
> yet
>
> > the long-term implication of the idea or how well this works in reality.
>
> I was not trolling. And I am certainly not against dialects. Simply stating
> the situation as I see it - rebol dialects really have not been tested and
> used my large numbers of people in complex apps, so we donlt know yet the
> deeper implications of using them.
>
We know. 'parse 'func (the argument header) 'compose are all dialects.
Works well :)
Make-doc is proven enough, i can read the howtos well :)
Rebol OTOH has proven that some problems do not need complex apps.
And complex design for this problems can not compete with rebol sometimes,
despite offering visual magicall wizardry tools.
> One issue of dialects has come up here, is that while they can lead to
> sweet short code, dialects are only as good as their documentation. Since
> one is possibly creating a specialistssub- language within the parent
> language, there has to be excllent way for people to know what it contains,
> whether it behaves differently or if its sytnax is consistent or not with
> their expectations and the parent language.
>
Thats the same with OO, only harder. Thats why OO is only usable
with lots of tooltips on code and auto-completion and whatnot.
You can't do what a dialect do simpler in OO.
I agree one needs documents. what is nice, this documents can be at
howto/tutorial-level and show usefull examples in some lines of code.
which makes helping other people lots easier than pagelong examples.
> VID for example is one dialect for view. But already in places it is fuses
> a slightly different syntactic set of conventions than regular rebol. That
> is good or bad depending on your POV. In general I am in favor of as much
> syntax consistency as possible. But its early days, so experimentation and
> diversity are required. When a solo developer to creates a dialect , they
> are 100% free to do whatever works best for their need and style. But if
> that work is to be really helpful to a wide community, then subtle
> variations and idiosyncrasies can soon become an obstacle to adoption.
>
As Andreas mentioned:
<Canvas ID="root" xmlns="http://schemas.microsoft.com/2003/xaml">
<Button>Cancel</Button>
<Button>OK</Button>
</Canvas>
this is the short way with oops ;) where have i seen that before? and when?
Could it even be a hint that dialects in OO have merits? ;)
> > Panel [
> > Button/System "Cancel" 'Cancel
> > Button/System "OK 'OK
> > ]
> >
> > Which one would you prefer? :)
>
> Yes no contest. But I think its a rather misleading comparison you offer.
>
> In standard OO languages like Python you typically package up any verbose
> complexity to create an class/object which is as easy and concise to use as
> your Rebol example.
Naa. This classes are then used in the same long way as they are created to
compose more sophisticated classes. while in rebol the layouts are used in
larger layouts. Think of styles build out of styles. now calculate:
if a level needs 5 lines in rebol and 25 with oops, two levels need 25:625,
three 125:15625 (if my console calculates right). And suddely you know where
the mb's are comming from. (Q&D-statistic, don't trust it ;)
> Rebol is lovely and clean partly because it removes
> extra punctuation. I think rebol is much easier to write than read.
Rebol is lovely because of excellent defaults IMHO.
> Python is perhaps the most balanced language where write-ability
> read-ability. Python's named function arguments have much to do with this.
>
> Programmers in Rebol and Python both have to be very aware of namespace. I
> think this is what Max's SLiM is addressing and so I imagine could greatly
> help dialect use in Rebol.
The difference is in length of code. Requirements change with that. So rebol
can solve a level II - problem with level I tools, where python needs its
level II tools. means rebol can work without namespaces in arrays where
python cant. the big question is, can you keep the problem at level II, or do
you need level V? the higher the level, the more python catches up. but this
is by design, rebol is tuned as dragster, python for paris-dakar.
> In rebol if you see 'button' in some code how do you know if that's a
> default button or dialected word also named "button" which may have
> overlapping behavior.
because the layout is quarter page away. You have the same problem with OO,
which of this 23**x draw()-methods in the source do you really call with
face.draw()
?
> Beyond namespace there is the social aspect of how
> customized developments can be elegant but harder to use/maintain because
> they have smaller population. In fact its the same problem in real life -
> lawyer politicians scientists, rap artists, poets all have their own
> dialects and often cannot communicate well.
All this people would have its own overloaded methods/libraries in python?
> And there are traditional
> regional dialects too where its quite possible to sit at dinner a family
> and find they share only some words. I have experienced this first hand
> with people from southern China. The guy's wife could not speak to her
> mother-in-law. ouch.
> The solution is almost always for people to know several languages so they
> have at least one in common.
>
This people need a translator who is quick in learning new languages?
That would be similar to rebol beeing tuned for doing dialects.
The people would need to adopt his style, speaking a reduced language while he
gets started. like using rebols datatypes. but better then a complete
perl-python-switch.
> With rebol dialects, success is a tradeoff between readability,
> write-ability, documentation, name-space and learning curve. They're a
> great idea, but not been around long enough to know how to use them best,
> grasp the trade-offs.
>
The more complex lacks teaching. And dialects lacks experience which teaching
too. It seems stuff like the cookbook works better than traditional bibles.
> Brody wrote brilliantly in his two classic books "Starting Forth" and
> "Thinking Forth" about the art and science of naming words carefully in
> Forth. Charles Moore has also spoken about this. And I think it applies
> deeply to Rebol also, perhaps because Rebol is like 'reverse' Forth -- it
> goes forwards] ;-)
>
Brodies style of illustrations would work wonderfull with rebol!
IIRC he is now a puppet-player. And we have more bandwith/cd's.
If Brodie would illustrate rebol-concepts with talking puppets instead of
pen&paper.. dreaming.. :)
> Designing Rebol dialects is not easy. And there are few guidelines yet. The
> minimal introductory presentation the Rebol documentation implies that god
> dialect share an emergent representation of a problem domain. banking, gui,
> etc When you understand the problem well and then want to simplify and
> focus the cod so it is more readable, then you write a dialect.
>
Same for OO-libraries.
but i disagree. ad-hoc-dialects for data can make live a lot easier sometimes.
once one knows a bit about the block-parser.
needed an internall representation a while ago. translating data to dialect1
and then parsing dialect1 to create dialect2 worked well. before rebol such
multi-pass-work was terrible, never could really immagine the intermediate
data. with rebol it was just 'probe and having a dialect with the right
keywords in some places.
> Make-swf source is good reading to see how David Oldes' has been learning
> and improving his own dialect. I think make-swf is one of the most advanced
> uses thus far of rebol dialect.
>
IMHO complex <> advanced. I would not say "when we can do this advanced stuff,
we are really good". Its more like a fully fledged kitchen compared with a
microwave. sometimes i would not change. (assuming a fully fledged kitchen
would force me to always do fully-fledged cooking).
> I look forwards to seeing copies of O'Reilly latest: "Rebol Dialects in a
> Nutshell".
> Then we'll know they really arrived!
>
I am not sure O'Reilly would need a nutshell for that. Given that they manage
to put some other languages in such size. But maybe they use coconuts there?
;)
> - Jason
-Volker
