Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: long read, sorry...

From: atruter::labyrinth::net::au at: 6-Nov-2003 11:30

Hi Max, I can see where you are coming from. One of the problems with email as a forum for discussion is that too much becomes noise and too little can be mistaken for apathy. My own perspecive on some of the issues you (and pekr) have raised follows. The REBOL community, such as it is, probably has a more diverse background than other technical communities, with some areas of note being: - A good mix of people from multiple OS backgounds (Windows, *NIX, Mac, Amiga, other) - Different positions / perspective on the proprietary / open source / licencing question(s) - Programming background (C [and derivatives such as Perl / Java], Basic, Lisp, COBOL, etc) - Involvement (full-time, part-time, academic, professional, hobbyist, student, etc) - Skill-level (general programming and / or REBOL-specific) - Interests / focus within REBOL (GUI / graphics, Web / CGI, email, concepts, dialects, parse, algorithms, etc) This diversity is a *good* thing IMHO, and quite different from, say, the PERL community which might come predominantly from an open-source *NIX C background. That's not a bad thing in its own right, but mono-cultures are not the domain of MS alone! ;) In my case, running a software company that uses REBOL on Windows exclusively, I spend eight hours a day with REBOL. Digesting each day's REBOL list email takes about an hour of that time. I'd love to respond to / participate in more of the discussions but time is a big factor for me. I try to at least look at every REBOL project that is released (pdf-maker, konka, mysql protocol, rugby, async, steel to name but a few) but tend to focus on those that meet the following requirements: - they do not already do something that REBOL does *or* could be easily implemented (by me) in REBOL - they address a specific requirement that I currently have - they are stable (it works, and changes don't invalidate what I have done) pdf-maker and the mysql protocol are good examples of others code I have used to solve specific reporting and database requirements respectively. I started looking at rugby for simple client / server comms, but as often happens, this list provided a dozen line solution to my problem so I ended up rolling my own. Does this mean I will never use rugby? No. Does this mean I don't appreciate the effort the author put into the project or their generosity in making the fruit of their labour available to others? No. The reason I have this preference to roll my own is that I want to understand / control as much of the problem domain as possible, in as few lines of code as possible. I prefer using code with the RT stamp of approval as I only have to worry about the entry-points not the details (with non-RT code I find myself thinking of it as "external" and wanting to verify / understand its implementation). I suppose REBOL has spoiled me in this regard as its extensions are predominantly source-based (unlike black-box binary extensions). I would hazard a guess that most folks who spend some time with VID have some sort of GUI library script with various pre-defined styles and / or functions that they use. Is it a bad thing that we don't all use a common community defined GUI library? No. My GUI library does the following things: - defines a base "element" size based on current font size - uses stylize/master to standardize the size of all widgets - sets default origin and spaceing based on current font size These meet *my* requirements to have a GUI that can be specified in a cell-like manner and adjusts dynamically to font size changes. It's not complex, but it gets the job done. Would it meet anyone else's requirements? Maybe a subset or a superset but not an exact fit. Steel looks quite innovative and I like the fact that it is built directly on View. If and when RT releases VID 1.3 I'll put the time in to look at what each offers me and where I'm best off putting my limited R&D time. Will I contribute to steel discussion / development? If I end up using it, you bet! Regards, Ashley