> 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 -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
