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- >I can see there are some guys here who really know >their Rebol - what approach do you take to a new Rebol >project? > > Ged Byrne. > >________________________________________________________________________ >Want to chat instantly with your online friends? Get the FREE Yahoo! >Messenger http://mail.messenger.yahoo.co.uk > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
