Hitting the learning curve

I tend to start with an empty object which I fill with functions and data that gradually build up to the complete application. I have (though I'm not as well organized as some others) a few files named things like std-utils.r and gui-utils.r that contain generally useful functions -- many of them I've scavenged from other people on this list, or from REBOL.org. I generally aim to develop top-down, so I always have a working program, but it is always incomplete until I declare it finished. Working as one of the volunteers on REBOL.org has meant a slightly different approach. That is centered around persistent data structures (such as the scripts themselves, the user-information records, the discussion logs and so on). That takes some thought up front to make sure we have all the data fields we'll need, and that the items can easily be expanded when we realise we don't. Mainly, I used the experience to teach myself CGI programming, so there is a lot I'd do differently if the world was like Groundhog Day. It also involves a lot of interesting to-ing and fro-ing with, mainly, Gregg as we refine concepts (and a surprising amount of time on what we should call things) before we start cutting code. Sunanda.

Yes, the ones that I down understand at the first look. Carl Sassenrath examples are often, but not always, of this kind. The source of mezzanine function is also interesting because the code is very short and concise.

I keep there both notes and codes. I use copy and paste to test the code in the console. Regards Patrick

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 .....

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 ...

I don't understand here ....

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 ...

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-

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: >

=== message truncated ===

my pet peeve too

since every one is in on the discussion and you nailed it so good, I want to emphasise that this is specifically what steel|forge will be about... when it will exist. ciao! -MAx ------------- Steel project coordinator http://www.rebol.it/~steel

I have exactly that same problem. I have used REBOL for little chores--moving files around the office, generating automatic email--but when I want to use it for something bigger my mind is blank as to how to start. Just last week I had an excuse to use it for something a bit bigger (but still small) so I have made a small crack in that barrier. Here is what I have so far, in case it helps. Languages are interesting not only for what one MAY say, but for what one MUST say. I come from a COBOL background ("The use of COBOL cripples the mind..." Edsger Dijkstra) so I'm used to having things that must be present, and must be in certain places, so I do that in REBOL to make myself comfortable. I also have found that the examples on the REBOL web site use words like "file," "data," and so on that trigger a reflex in my mind that says, "That's a reserved word," and that is confusing. So to easy my confusion I type all the REBOL words in lower case and all the words of my own invention in upper case, just like old COBOL. It is not recommended as a style, but it helps me personally. I hope that as I go along I can develop a collection of reuseable, or at least reconfigurable, scripts that I can call into my main program with the "do (script-name)" command. I have one so far, which is a language module. It contains every scrap of text that the main program will show in any way. The idea it that by isolating all text in one file, I could move the script to another language by translating that one file. I hope to write it up for the cookbook this week. The final form of a finished script will be something like this: ** The header ** "do" commands to bring in any reuseable modules ** "Declarations" of any configuration data items that the user might want to change. ** "Declarations" of all other data items. ** All screens, defined with the layout function, each followed by all the code that is run when the various controls are activated. ** The "main program" or "first executable instruction" to get the program running. With those preliminaries explained, here is how I proceed for a script that has a GUI screen and does stuff when you push buttons, etc. Draw out the screen, physically or mentally, so I have some idea of what I am trying to accomplish. Copy a skeleton of the REBOL header as my new script file, and fill in all the stuff. This just gets me warmed up, gets a little momentum going. Put in a "do %language.r" command to bring in the language file, which at this time is just a skeleton. (I'll put this "do" into the header skeleton eventually.) If I can see far enough ahead to know what data items I will be dealing with, I will "declare" them. This is not necessary in REBOL, but I like to do it to keep track of things. "Declaring" them is just setting them to some initial value in some standard spot in the script, so I can look back at them later and remember how to spell their names. This is like DEFAULT-FILENAME: %xxxx.xxx FORMATTED-DATA: none and so on. As I go on, I will add more items. I also document each item in comments in the script so I don't forget what they are and use them for the wrong purpose. I tend to go overboard on comments, so I have heard from my co-workers. Then I define the(all) screen(s). I use just the layout function, as MAIN-WINDOW: layout [ (VID commands)... ] Now, when I set up any text, button, etc. in the layout, the text that is to appear is NOT coded as a literal in the layout. It is coded as a data name in the language file. For example: button 60x20 LMB-001 LMB-001 might refer to a value of "OPEN" in the language file. So during this layout development I also am making entries in the language file, like LMB-001: "OPEN" For any screen control that can cause some action, usually a button, I use a function call as that action. Even if the action is as simple as quit, I use a function call. This is because I like things tidy, and so that if that action becomes more complex, I don't have to rework the formatting of the script so much. For example: button 60x24 LMB-001 [BUTTON-ACTION] [inform LMH-001] In the above example, BUTTON-ACTION is a function in the script. The other action, "inform LMH-001," is the "inform" command which will display a help text on a right click. That help text is a layout in...the language file. So as I am setting up buttons, I am also adding items to the language file. I will define as many screen items as I feel like, just to get something that can be displayed. I won't necessarily do the full screen, or all screens, at this time unless I have a clear idea of what everything will be like, or unless I have a good head of steam. Then I define all the functions that were declared as actions on the screen. I just put in stubs for them, like BUTTON-ACTION: does [ ] This makes the script syntactically complete, although I believe this is not necessary--in other words, the script will run fine until you push the button with the missing funciton. But, I like things tidy, so I put in a stub for every action, and will fill them in later. Finally, I will put in the "first executable instruction" (or whatever your computing background calls it). This usually is something like view MAIN-WINDOW At this point, I have something that will bring up a screen, and do absolutely nothing. So I run it. Seeing it there gives me hope for the future. Then I start filling in the unwritten parts. Keep in mind as you read this that I am a beginner with a bias. Hope it helps. In spite of REBOL's "simplicity" I still find it strangely very difficult. Steven White City of Bloomington 1800 W Old Shakopee Rd Bloomington MN 55431-3096 USA 952-563-4882 (voice) 952-563-4672 (fax) [steven--white--ci--bloomington--mn--us]

There is a script somewhere, %colorize.r? rebol.org? it takes a script and outputs colored html. words found in rebol itself have a diferent color.AFAIK. could be used/modified to show scripts with your own words more marked up. ALso words like "file", "data" etc are reserved in a way. whenever i nedd a local variiable for a file, i call it "file", when its the file-content, or the important data in a face, thats "data", etc. "ta" and "sl" are always the big text-area and the sliider in my layouts. so when code has a similar structure, it uses similar names and i can read it quicker. to trap inbuild words, use "protect-system" at start. then, when you overwrite an inbuild word, that triggers an error. since i initially my own words first, that traps very well. Another way i experiment with is to prepend my words with a shortcut, like d-something. thats mostly to keep emacs happy when looking up definitions. but could tell "its my" too. -Volker

Correcting myself, thats view layout[ buttOn #"^q" "quit" [quit] RETURN slider 16x450 [scroll-para ta face] RETURN TA: area 600x450 ] of course -Volker

Well, he also wasn't fond of the go to statement (in any language), so he did make some good points too :-) http://www.acm.org/classics/oct95 Sunanda

All of the above is more reason to use vim (or some other equivalent editor) that does syntax coloring. My normal "development environment" for REBOL is one or more vim windows (or terminal windows with vi[m] running in it/them, depending on platform) and a REBOL console. The edit/test cycle simply toggles between windows, and the syntax coloring is always there (without the need to run some utility to get a static view of the code that's outdated with the next editor keystroke). -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Enron Accountingg in a Nutshell: 1c=$0.01=($0.10)**2=(10c)**2=100c=$1

Aaargh! How could i miss it! Yes, emacs does it too. Never checked what all this colors mean.. Thanks :)

-Volker

Me too! Kind regards, Ingo

Hi, IMO that's the part to put work in (what I'm doing). Building dialects for special tasks and makeing it possible to use those dialects together. I'm always sceptic on frameworks that have a "it does it all" approach. This forces you to follow the framework road all or nothing. I'm more addicted to small, simple dialects that just do one job self-contained.

Why do you want RT to do it? We can do it today! But assembling a set of dialects, nice protocolls etc. in a way that you still have a component model where you just pick the stuff you need, is a very complicated task. What I try to do (slowly) is to build up such a set that I'm going to use for all my Rebol projects and grow it over time. As soon as most of use base their work on the "Rebol Community Framework", I'm sure RT is open to adopt it. But creating such a framework needs leadership! Who is going to do it? That might be easy, but is the community going to support this person? If not furstration will come up.

Yes, it happens to all of us but anyway, each spent effort helps and creates value. I don't see it as a big problem. Progress will just need more time.

It's not easy to setup a community development process, get it to life and keep it going. It's all about the people. If we can setup the code, testing, doc, product design... chain we would be one big step forward. But working in an volunteer environment needs patient, it's not daily business and people able to spend more time, need to understand that not everyone might be able to contribute in the same volume.

This won't happen, otherwise it would have happend already. Why not someone else?

Same answer, it's up to us to organize this. IMO RT should focus on enhancing the base technology, managing the community must be done by the community.

Than let's decide and create facts! I don't expect Carl to be narrow minded and don't give it a look or the required priority if it makes sense to RT.

I'm not a clairvoyant, that's RT's problem. Some of us are willing to help them and have ideas. IMO the success of Rebol can be influenced massivly by us. It's not easy, but it's doable. Let's go and make a business from it. And, don't rely on RT to get your business done, this is our job.

Petr, we are used to it ;-) Robert

Hi, data drives development. I mostly follow this rule. Robert