long read, sorry...
[1/2] 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
[2/2] from: maximo:meteorstudios at: 6-Nov-2003 10:17
> -----Original Message----- > From: Ashley Trüter [mailto:[atruter--labyrinth--net--au]]
<<quoted lines omitted: 7>>> little can be > mistaken for apathy.
> The REBOL community, such as it is, probably has a more > diverse background > than other technical communities, with some areas of note being: > [...] > This diversity is a *good* thing IMHO
depends on the perspective. it is good since it proves rebol is flexible and is able to tackle many things. Yet, it is less good cause there is less concerted effort. It also makes improving rebol harder. Cause there more to cover than many other code bases.
> In my case, running a software company that uses REBOL on Windows > exclusively.
>I'd love to respond to > / participate in more of the discussions but time is a big > factor for me.
I also participate less than I use to, since I have less free time at work, and am forced to use REBOL less and less WRT python... :-(
> 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.
And that is why rebol is so addictive to all the more advanced programmers. When you "get" it, then everything seems simple/possible.
> (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
This might also be because you are forced to do so in many circumstances... we are all genious in our own little world, but have a hard time making our things work together.
> I would hazard a guess that most folks who spend some time > with VID have
<<quoted lines omitted: 3>>> use a common > community defined GUI library? No.
and I agree, but it is also because there is no massively supported extended alternative. If you had an engine which did this and went far beyond... in an easy as VID dialect... I am tempted to say that you might look into it and if it was stable and complete, you'd be happy to use it, at least occasionaly.. This is a specific example, but other areas of rebol are still sprawled and segmented. Many have ideas, many have tidbits, for the more average developper or rebol novice, this quickly becomes a liability. Having to learn a language and then having to redo what is standard in your previous app (like python users and regexp) is a tedious process which discourages many people, even seasoned rebolers. When you want to bring someone in your turf, you need to have a bridge that is solid, shiny and lighted, so that its not scary to cross. This rebol provides by iteslf, because of its super language and underlying concepts. the problem, is that once your on the other side, most if not all miss home, because houses have windows without shutters, streets with no signs, (althtough they are straight and in good condition, with very few patches), etc... many don't have the time, patience, knowledge, reference, or even skills to reprogram some core functionality which is basic in all the other languages which rebols tries to upturn... I know you'll say, yeah but we have something of our own, we have something better, we have, we have... but in the perspective of any new user, we miss, we miss, we miss, we miss... and in some regions, its hard to explain why. I also know I love rebol cause I LOVE to program my own core stuff. I am very specific with what I like and don't, and often, I find other people do sloppy stuff (not specifically talking about rebol stuff here, which is well above average IMHO).
> Steel looks quite innovative and I like the fact that it is > built directly > on View.
(that would be glass... I know... its hard to keep track ;-)
>If and when RT releases VID 1.3 I'll put the time in > to look at
<<quoted lines omitted: 3>>> up using it, > you bet!
This kind of argument is true, and I admit that it is true for me too. When I set off to do steel, I knew I'd have a hard time convincing ppl. Not because they are dumb... but because they are RIGHT. Things have to be usable for anyonw to use them, of course. Which is why I keep the grip tight on the ship's helm and move on, expecting the day I'll arrive at port. -Max
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted