Hitting the learning curve
[1/25] from: gedb01::yahoo::co::uk at: 5-Nov-2003 9:49
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. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. 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? There seem to be so many approaches, but no single method affords itself? 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.
[2/25] from: patrick:philipot:laposte at: 5-Nov-2003 12:10
What is the starting point with Rebol? This is how I proceed for what it's worth. I start looking for related topics in the library. I appreciated most Carl examples which are the more Rebolish (or Rebolistic?). I have downloaded the entire Library in a folder named DOC. I store there all the documentations I have been able to collect about Rebol: The CookBook, The How-to, Zine articles, Ladislav document. I have also a special folder named "Good to know" where I store bits and tricks gathered from my own experience or from the Mailing List. After getting a more precise idea of the different parts needed, I start a new text document to write it down. Then I start a console session to test some points directly. I keep validated piece of code also in my text document. Very often, at this stage, some help is required from the ML. Finally if a GUI is needed, I start a simple layout which is refined progressively and noted in my text document too. At this stage, or earlier, my wife call me for this big thing that cannot wait and I am glad to have all my work written down waiting for me until I can resume a few hours or days later (depending on the big thing). Regards Patrick
[3/25] from: gedb01::yahoo at: 5-Nov-2003 11:49
Patrick, Thanks for that. Are there any particular examples that deserve particular attention? I'm intrigued by your 'text document.' Is this document just your own notes, or Rebol? Thanks, Ged. Patrick wrote: | What is the starting point with Rebol? | | This is how I proceed for what it's worth. | | I start looking for related topics in the library. | I appreciated most Carl examples which are the more Rebolish (or | Rebolistic?). | I have downloaded the entire Library in a folder named DOC. | I store there all the documentations I have been able to collect about | Rebol: The CookBook, The How-to, Zine articles, Ladislav document. I | have | also a special folder named "Good to know" where I store bits and | tricks | gathered from my own experience or from the Mailing List. | | After getting a more precise idea of the different parts needed, I | start a | new text document to write it down. Then I start a console session to | test | some points directly. I keep validated piece of code also in my text | document. | | Very often, at this stage, some help is required from the ML. | | Finally if a GUI is needed, I start a simple layout which is refined | progressively and noted in my text document too. | | At this stage, or earlier, my wife call me for this big thing that | cannot | wait and I am glad to have all my work written down waiting for me | until I | can resume a few hours or days later (depending on the big thing). | | Regards | Patrick
[4/25] from: SunandaDH:aol at: 5-Nov-2003 7:14
> What is the starting point with Rebol?
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.
[5/25] from: patrick:philipot:laposte at: 5-Nov-2003 14:02
> Are there any particular examples that deserve > particular attention?
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.
> Is this document just your own notes, or Rebol?
I keep there both notes and codes. I use copy and paste to test the code in the console. Regards Patrick
[6/25] 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.
<<quoted lines omitted: 9>>>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-
[7/25] from: nitsch-lists:netcologne at: 5-Nov-2003 15:49
Hi Ged, I have a Scratchpad.r where i start developing. Thats the blank screen or the form. In VB I start with a blank form, dropping controls and then writing the event handlers. my vb-blank-area (text-area with slider, quit-button): view layout[ buttin #"^q" "quit" [quit] slider 16x450 [scroll-para ta face] area 600x450 ] starts with hotkey from my editor. error: console, a quick "q" in the console quits and i am back in editor. In Java I start with an object model. I identify my objects with methods and properties and then start composing the relative classes. Not so necessary in rebol imho, because most of the usefull classes are inbuild and very flexible. In Perl or Ruby I start with the input stream, usually a file, and start heading for the output stream. me too. using 'save/all and 'load/all. Very usefull with rebol, because data is easy to structure (hierarchy of blocks), search and (!) to create by hand for debugging. my blank data-page: words: [files names something] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does[save/all data-file reduce words] ;loading once at atart, so no func set words any[ attempt[load/all data-file] ; catchs errors, like "does not exist" reduce[[%a %b] ["the a file" "the b file] #a-something] ] to reset data-file i usually put a single "[" in, so the load fails, default values are used. So a blank page with gui and load/save is: ;;;;;;;;;;;;;;;; words: [files names something] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does[save/all reduce words] ;loading once at atart, so no func set words any[ attempt[load/all data-file] ; catchs errors, "does not exist" etc. reduce[[%a %b] ["the a file" "the b file] #a-something] ] view layout[ buttin #"^q" "quit" [save-data quit] slider 16x450 [scroll-para ta face] area 600x450 ] ;;;;;;;;;;;;;; hacked a bit straightforward, have now a basic file-commenter used a lot "probe something" and "?? variable. usefull too: keep variables in global context while debugging. quick to look in. be carefull with "attempt[load someting]". it hides all errors. so it hides wrong filenames too. while debugging, you can set "attempt: :do" so attempt will break on errors. You can do "area/text: %file.r". but the filename is converted to string. will not be found in the initial file-block. so use "find files TO-STRING area/text" once file is stored, it will not look for new files. try to fix that. hints: union files read %./ appends, deletes doubles and keeps old order of first argument. insert/dup with the difference of two "length?" can be used to add "none"s to the comments-field. REBOL [Title: "Scratchpad - for developing"] words: [files comments] ;persistent to load/save data-file: %scratchpad-data.txt save-data: does [save/all data-file reduce words] ;loading once at start, so no func set words any [ attempt [load/all data-file] ; catchs errors, like "does not exist" reduce [ f: sort read %./ ;files head insert/dup copy  none probe length? f ;a none-comment/file ] ] view layout [ button #"^q" "quit" [save-data quit] tl-files: text-list data files [ tf-file/text: first face/picked index: index? find files tf-file/text ta-comment/text: pick comments index show [tf-file ta-comment] ] return tf-file: info ta-comment: area [ index: index? find files to-file tf-file/text change at comments index copy ta-comment/text save-data ] ] ] ;-Volker Am Mittwoch, 5. November 2003 10:49 schrieb Ged Byrne:
[8/25] from: gedb01:yah:oo 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: > >[...]
<<quoted lines omitted: 133>>> there is someone who cooperates with RT on its > further
=== message truncated ===
[9/25] from: maximo:meteorstudios at: 5-Nov-2003 11:15
> -----Original Message----- > From: Ged Byrne [mailto:[gedb01--yahoo--co--uk]]
<<quoted lines omitted: 4>>> Rebol gives me tools to create abstractions, it > doesn't give me any help to manage them.
my pet peeve too
> 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.
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
[10/25] from: Steven:White:ci:bloomington:mn:us at: 5-Nov-2003 11:56
>>> [gedb01--yahoo--co--uk] 11/05/03 03:49AM >>> >>>I've been throwing to gether 5 line scripts... >>>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.
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]
[11/25] from: nitsch-lists:netcologne at: 5-Nov-2003 19:45
Am Mittwoch, 5. November 2003 18:56 schrieb Steven White:
> >>> [gedb01--yahoo--co--uk] 11/05/03 03:49AM >>> > I come from a COBOL background ("The use of COBOL cripples the mind..."
<<quoted lines omitted: 6>>> words of my own invention in upper case, just like old COBOL. It is not > recommended as a style, but it helps me personally.
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
[12/25] from: nitsch-lists:netcologne at: 5-Nov-2003 19:49
Am Mittwoch, 5. November 2003 15:49 schrieb Volker Nitsch:
> view layout[ > buttin #"^q" "quit" [quit] > slider 16x450 [scroll-para ta face] > area 600x450 > ]
Correcting myself, thats view layout[ buttOn #"^q" "quit" [quit] RETURN slider 16x450 [scroll-para ta face] RETURN TA: area 600x450 ] of course -Volker
[13/25] from: SunandaDH:aol at: 5-Nov-2003 14:27
> I come from a COBOL background ("The use of COBOL cripples the mind..." > Edsger Dijkstra)
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
[14/25] from: joel:neely:fedex at: 5-Nov-2003 14:50
Hi, Volker, Volker Nitsch wrote:
> Am Mittwoch, 5. November 2003 18:56 schrieb Steven White: >>... So to easy my confusion I type all the REBOL words in lower case
<<quoted lines omitted: 5>>> color.AFAIK. could be used/modified to show scripts with your own > words more marked up.
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
[15/25] from: antonr:iinet:au at: 6-Nov-2003 14:21
And who is that? Anton.
[16/25] from: greggirwin:mindspring at: 5-Nov-2003 23:49
Hi Ged, GB> I've stopped saying 'Wow,' and I'm starting to ask 'How.' What a great question! GB> The problem is that, given a blank piece of screen, GB> where do I begin when devising my own code to solve my GB> own problems. What is the starting point. GB> Different languages have their own starting points. Yes, and most *give* you a starting point. They also give you a definite "way" to think about solving your problem. Some have you think about code or the UI, others about structure or "the model" (UML et al). GB> What is the starting point with Rebol? Given a GB> problem and an empty .r file how do I start growing my GB> problem? With a form to enter the data? With a set GB> of objects? With a set of functions? By defining a GB> dialect? GB> There seem to be so many approaches, but no single GB> method affords itself? That's true! It's one of the things I really like about REBOL, but I can see where you're coming from. When I started with REBOL, I was attracted to the GUI side of things--having specialized in VB for 11 years--and it took me a while to let go of that, probably still haven't completely. :) The reason I think this problem is a good one to have, is because with other tools you might map your problem to their domain without thinking about whether that's the best thing to do. With REBOL, I think there is less bias for any particular method, so you look at your problem and run through the various options in your head about how you might solve it. If your problem involves a user entering data, a GUI might be the right thing. If it involves listening for TCP connections or automatically processing files, probably not. I'd hazard a guess that we all create a system of patterns we start to recognize over time, and we may even have skeleton projects for them; on disk or in our heads. As a general rule, when I start a new project, I create a directory for it and create a notes.txt file. That's where I collect my thoughts and ideas. It's also where I jot down pseudo-code or structures as I think through the problem I'm solving. Writing down the steps you need to take to solve the problem is a really good place to start. What happens, with REBOL more than many other languages for me, is that your solution will end up looking like how you naturally expressed it in pseudo-code. With REBOL, one of the really important things is the set of words you end up defining and how they work together. If I'm writing a module or set of functions that are to be used as a small library, I start with an object to put them in their own namespace. That's an easy pattern to spot. If I'm writing things that are going to use Windows API calls, I usually start by getting all the routine! bits working, using test calls, and then decide if I should just use wrapper functions or build a dialect around them in some cases. For small data entry apps, I have a boilerplate system and some other toys to get simple things up for testing. If I have multiple views, or other stuff going on in the UI, I'll usually sketch out a quick FSM using my FSM dialect to help me visualize things a bit. Sometimes I start with data. I'll manually create the data, or write a data generator to do it, then I can play with how it's going to work, see if I can read and write the data in formatted how I want, if it's easy and extensible, etc. Folks who do a lot of CGI probably have a definite starting point for how they do it, and even skeleton scripts to get things rolling. HTH! -- Gregg
[17/25] from: nitsch-lists:netcologne at: 6-Nov-2003 7:57
Am Mittwoch, 5. November 2003 21:50 schrieb Joel Neely:
> Hi, Volker, > > > All of the above is more reason to use vim (or some other equivalent > editor) that does syntax coloring.
Aaargh! How could i miss it! Yes, emacs does it too. Never checked what all this colors mean.. Thanks :)
[18/25] from: amicom:sonic at: 5-Nov-2003 23:46
Max, Wanted to let you know I am looking forward to Steel/Liquid/Glass when it is available. What stops me from looking into it right now is that I need to focus on tools that are completed that I can use in my business. Unfortunately, I have little to no free time to spend on other projects. I use Rebol a lot and every day, but hardly ever on my own time. When Carl developed VID, I recall him saying that he hoped it would be inspiration for the user community to come up with something more robust and specialized. I believe VID was more of a proof-of-concept than THE solution. Thanks for taking the reins in this aspect. A future Steel/Liquid/Glass user, Bohdan "Bo" Lechnowsky Lechnowsky Technical Consulting At 11:15 AM 11/5/03 -0500, you wrote:
[19/25] from: gedb01:yaho:o at: 6-Nov-2003 9:19
Gregg, That is excellent. It certainly does help. I'm particularly interested in your FSM dialect, is it something you've published? Thanks, Ged. --- Gregg Irwin <[greggirwin--mindspring--com]> wrote: >
[20/25] from: greggirwin:mindspring at: 6-Nov-2003 6:25
Hi Ged, GB> That is excellent. It certainly does help. Great! GB> I'm particularly interested in your FSM dialect, is it GB> something you've published? I don't think I've published it here, or on REBOL.org, but I did put it on IOS so at least *some* others could look at it. IIRC, there wasn't much interest in it here, so I just send it out on demand to people who are into in FSMs. For general publication, I'd like to include more docs and how-to's, and that all takes time. Mail me directly if you're interested. -- Gregg
[21/25] from: maximo:meteorstudios at: 6-Nov-2003 10:22
WOW, that lifts the spirit... btw, I USED to say to other programmers that rebol had fantastic support... I miss the days when you where there to answer all our questions... it rarely took more than a day, and sometimes those where hard questions... now I think this list is the main support line... maybe RT counts on it a little too much? thanks! -MAx --- You can either be part of the problem or part of the solution, but in the end, being part of the problem is much more fun.
[22/25] from: amicom:sonic at: 6-Nov-2003 10:17
Max, I also miss those days. It was quite a blessing to be able to take hard questions, try to figure out the answer myself, and if I really needed to I could walk into Carl's office (if his door was open) or one of the other developers and get a definitive answer. Sometimes, the question was a pivotal point so Carl would think about it for a while (and he really put thought into all the issues) and sometimes he would call a development meeting to get others' opinions on which direction to take Rebol. I was also very impressed to see how in-depth Carl thought about something before implementing it. I never sensed that he coded "off the cuff", but only after extensive mental deliberation weighing all the pros and cons and keeping an eye on the future. Rebol is an amazing piece of work. I agree that the main ingredient missing now is communication from the top. I have a potential solution. I'll see if I can set up a meeting with Carl to discuss it. It will benefit both the Rebol community and RT itself. Stay tuned. Bohdan "Bo" Lechnowsky Lechnowsky Technical Consulting At 10:22 AM 11/6/03 -0500, you wrote:
[23/25] from: ingo:2b1 at: 6-Nov-2003 19:20
Hi Bo, Max, as much as I hate posts like my following ... I just _have_ to say it! Maxim Olivier-Adlhoch wrote:
> WOW, that lifts the spirit... > > btw, I USED to say to other programmers that rebol had fantastic > support... I miss the days when you where there to answer all our > questions... it rarely took more than a day, and sometimes those where > hard questions...
Me too! Kind regards, Ingo
[24/25] from: robert:muench:robertmuench at: 8-Nov-2003 18:25
On Wed, 05 Nov 2003 14:17:43 +0100, Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:
> OK, one other problem I can see with rebol is - lack of frameworks.
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.
> 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.
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.
> 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 ...
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.
> 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?
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.
> - more RT (Carl's activity) in a leaader role
This won't happen, otherwise it would have happend already. Why not someone else?
> - RT identifies area to solve, sets coordinators, they choose team, team > works ... (I think library project worked similar way ...)
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.
> - 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 ...
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.
> 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 ...
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.
> That is my opinion on identifying basic rebol related areas ... I hope > they are not offending, as they were not ment that way anyway ...
Petr, we are used to it ;-) Robert
[25/25] from: robert:muench:robertmuench at: 8-Nov-2003 18:25
On Wed, 5 Nov 2003 09:49:08 +0000 (GMT), Ged Byrne <[gedb01--yahoo--co--uk]> wrote:
> 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.
Hi, data drives development. I mostly follow this rule. Robert
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted