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.
Lucky you!
>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
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted