[REBOL] Re: Community (was IOS).
From: jason:cunliffe:verizon at: 19-Mar-2002 19:23
> java sux 16,600
> perl sux 14,300
> php sux 33,400
> c++ sux 4,620
> rebol sux 157
I played this game for little while yesterday too - using keys such as
'bugs', 'docs', 'help', 'crash', 'fun', 'how-to', etc. If well correlated,
it _might_ really reveal something interesting, but probably about google
more than the languages you want to compare, especially Rebol. Why?
One thing which makes rebol different is that .r files are largely invisible
to google searches
Try finding index.r for example. The whole idea of publishing to rebsites
and by extension IOS, is that one uses globally propagated Internet
protocols to support custom community networks and thus new group-level
interoperability.
The normal web 'invisibility' of REBOL is superb catch-22 in this sense. A
strange early victim of its own success.
This is also why I suspect it can be hard to find timely rebol help, because
lots of cool rebol examples and source are not visible to google. Someone
posted a rebol/view find script not long ago. But rebol needs a built-in set
of find functions like RedHat did for rpm and when they added RedHatNetwork
stuff also.
As the web space gets increasingly polluted with pop-up spam, this
invisibility seems like it should/could be real selling point.
But it needs better bridges so that people can hide or reveal rebol better
according to their needs.
At present Rebol offers but not quite yet delivers a viable alternative to
ordinary HTML life.
What features are missing?
- The desktop of /View does not include any useful ways to search or sort
among rebsites.
- No option to list rebsites other than icon array. No detailed list mode.
The idea of rebsites starts off great, but seem to have been abandoned by
/View
When you roll over the mouse on rebsite icons you get a line of text. That
shows the potential, but it is not well used.
A few bytes can go a long way when they give people relevant information
BEFORE they click and maintain some state AFTER. Almost all the problems
with HTML for community building come down to the lack of persistence and
the fact that http is stateless..Thus cookies, server sessions etc etc.
Rebol delivers persistence and state. Rebol/View knows how to check first in
its cache before trying the Internet. But imo this wonderful idea is not
really followed though to its next logical steps.
- No update or 'visited' visual iconographics.You have no way of even
knowing which rebsite you have already looked, which noes have new material,
etc..
Rebol seems made for this, but in effect the only resource we have is this
is mailing list and even then the only way to find anything is to do some
funky search though mailing list archives. Time-consuming.
It would be good if rebsites could give any kind of indication of their
activity level. That would allow rapid browsing and sorting of sites,
propagation of new ideas etc. Community building of a new kind.
- There is no built-in way to group or label rebsites, other than to write
ones own index.r files with more rebsite links. But these will soon be hard
to maintain as they are static. This goes against the splendid potential in
Rebol for emergent adaptive networking using "fast, cheap and
out-of-control" strategies. I wish default /View desktop would encourage
better default access and use of rebsites, and rebol data. As has been
pointed out rebol data and programs are only a matter of perspective.
In any event is strikes me that with REBOL/View and some smart use of Rugby
integrated into every /View installation, all the above could be answered.
Maybe I am just too ignorant still of IOS, its desktop and publish
functions. Does it already fix all these problems??
./Jason
