Comments on: REBOL Status Report 2010.2

Comments on: REBOL Status Report 2010.2

It's time again for an update...

I've been incommunicado... almost to an extreme degree, as many of you know. But, sometimes, that's what it takes to get the job done -- So nice to have it accomplished. (If you're not aware, the project was an overhaul of the REBOL.com website, a large and intense undertaking.)

Yes, it had to be done... but, we're talking about more than a decade of documents in a wide variety of formats. I was surprised even to find several that had not been accessed nor format-updated since the 2000-2001 days. Perhaps you knew of those, but I'd long forgotten them. For example, who remembers this document on detecting an Internet connection with async-DNS or this one on encrypting strings and files. I also divided up a few of the longer docs, such as REBOL/View Graphic System Reference. That document was quite long, and splitting it up helps search engines like Google index it better.

Along the way, WIP Wiki 3.1 helped immensely. It was like a dream come true. This website project was a case showing the clear advantages of using a system written in REBOL. A huge time saver. Along the way, when I found the need for a new markup tag or other feature, it would take me less than two or three minutes to implement it, including updating the main web server. The Wiki now weighs in at just 15 KB LMFC. Quite compact, considering all that it can do. I'll be using this system a lot more in the future.

So, what remains to be done? Here's the list:

Home page - we've had this on hold until all the internal pages were updated. The home page requires a lot more "marketing" thought, as well as graphics. It's best to handle it in a few steps. First, we'll get it into the new page format, but not with any new marketing polish. Then we'll go from there, according to what I outlined earlier.
REBOL Manual - The R2 and R3 manuals are still in their old formats. A decision needs to be made: should the manuals be kept separate or should they be merged? I'm leaning toward a merge, taking the R3 manual (which was derived from the R2 manual) and notating the differences between R2 and R3 within the same pages. This would be the most efficient because R2 and R3 have a lot more in common than differences.
Merging the Blog - It would be nice to merge this main blog into the website... mainly because WIP wiki markup is so much easier to type (than using HTML-style tags.)
Other Marketing - Many of you have suggested marketing ideas, but until the website was ready to proceed, most of those ideas would have been difficult to implement. So, we're ready to take another look at suggestions and move forward.
Other "stray" content - There are various other documents, mainly on REBOL.net that should be collected into the new REBOL.com website. Since it's easy to do now, we'll make it happen as they are discovered or suggested. I'm sure Googlebot will point out a few page issues or bad links as well.
Interesting graphics - Various pages and sections could be improved with a few images. My time is limited in this regard, so if you've got ideas, contact me.

And finally, back to R3...

With the website project now under control, it's time to get back to R3 development as our main focus. So, you'll see that project resume now.

Prior report: REBOL Status 2010.1

36 Comments

Comments:

Graham
28-Jan-2010 14:00:56 Your repeated absences are extremely damaging to what's left of this community. Is the website really more important than having an intact and growing developer userbase?
Luke
28-Jan-2010 14:10:06 Graham - why not be more constructive? I'm sure your energy could be put to good use?
Henrik
28-Jan-2010 14:31:01 Graham observes, as I do, that discussions tend to degrade to "kids home alone arguing, while parents are out of town", while Carl is busy. This usually goes absolutely nowhere, but creates a lot of noise. Carl's back and things fall back into place, as always. No damage.
Carl Read
28-Jan-2010 18:02:52 Merging the R2 and R3 docs is a good idea, as when R3 behaviour surprises a long-time R2 user the explanation will most likely then be on a single page - no jumping back and forth between pages required.
is carl the only develop
28-Jan-2010 20:42:36 is carl the only developer working on Rebol?
Hi I am not an old timer here at rebol. however I've noticed a few things in this rebol community.
the question I have is : How many people are really working on Rebol ? I've read in some places that there are 5 people. however I have the impression that there is only one person i.e Carl and another one Brian. Is that right ?
Maybe Carl should be delegating more to other people, and he should be directing and reviewing what they do, in this way things could move faster.
I am not saying that he is not doing enough, on the contrary, it looks like he is working his butt out by himself, but is that the most efficient way of achieving things ?
that's my 2 cents to the first 3 comments.

batman
28-Jan-2010 20:45:03 sorry I got mixed up with the title and name, the previous post is from me, i.e batman.
-pekr-
28-Jan-2010 21:39:56 I don't want to sound like I am once again against anything, but I don't agree on merging R2 and R3 docs. And here is my reasoning:
- your aproach works only for Core. As for GUI e.g., R2 and R3 will differ very much. And even for core, when you will describe things as devices, tasking, simply an architecture, the difference is night and day ...
- the reason why I suggested to put all R2 stuff into kind of "container" was - let's forget R2. When R3 family is out, I don't care about R2 anymore. While still usefull for many ppl, simply put it will be an obsolete product, easy as that. There will be no reason nor excuse for devs not to move to R3
- R2 docs - there are many of them, and sorry, but R2 docs are kind of chaotic. I really liked like you split R2 and R3 docs. I really don't want one just one section, where various tutorials from R2 will pop-up. I want to concentrate on future = R3, and new, clean, nice docs
So - it is not only about doing R3 docs, and mentioning the differences to R2. It is also about what to do with all those R2 related docs, which exist now. Typical reaction of ppl to R2 documentation was - too many scattered resources around. We should streamline it, and starting afreash forgetting the past is the best way to go.
Brian Hawley
28-Jan-2010 22:37:35 Batman: No, Carl is not the only developer working on REBOL. There are other contributors, such as (but not only) Maxim, Henrik and me. You are free to contribute too.
Pekr, about combined docs: I agree that combined docs are best for mezzanines and other high-level stuff, especially since there is third-party documentation and books that refer to R2, not R3. And that there should be separate pages for the areas where there have been major changes, such as with GUI, ports, /Library vs. extensions, etc. Combined docs about parse may or may not be a good idea; most of the in-depth documentation about both is on the Parse Project page, and not complete.
Pekr, about R2: The only reason we can get away with such drastic changes between R2 and R3 is the continuing existence of R2. That way we can point to R2 when someone complains about compatibility. If you don't want to use R2, good for you, you won't be alone. Others have large apps that depend on R2 features, which they might not find cost-effective to port - and they won't have to.
Pekr, about existing R2 docs: They really are too chaotic, and this is unacceptable for an ongoing product. Hopefully the reorganization of the docs will clean that up.
AR
28-Jan-2010 22:59:31 It's nice to have somewhere docs stating the difference between R2 and R3.
Combined docs would make only sense, if there is a common standard in their working and just a few variations in their syntax.
As I think the difference is bigger, I am against combined docs
-pekr-
29-Jan-2010 0:16:56 BrianH: my "let's forget R2" was meant mainly in regards to docs. I know that many ppl have apps done using R2, and I respect that. However - there is many docs, especially for View, which overlap, cover the same/similar topic, etc.
The way I see it is - let's put all R2 docs in "R2 documentation" container. Then, let's have R3 docs, as already outlined by Carl, and let's just introduce structural category, called e.g. "compatibility", or "R2", and if there is a need, let's mention the difference, or point to some concrete doc in "R2 documentation" container. New docs have to really fully concentrate upon R3. It can mention difference here or there, but they should not imo drag us into complex explanation of R2 to R3 differences ...
Brian Hawley
29-Jan-2010 1:25:27 Pekr, you're not the one who has to answer when people ask for complex explanations of R2 to R3 differences. I've had to field that question at least once today. We need those docs somewhere, and in context is the best place to put them. Fortunately, in the areas where R2 and R3 are similar enough to merit combined docs there aren't really that many differences to mention, so "complex explanations" won't be necessary.
We need R2 docs because R2 is a current product of RT and needs current documentation. Most of the existing docs are outdated and disorganized. The easiest way to update the vast majority of the /Core docs is to combine them with the effort we are already expending on the corresponding R3 docs. We don't want to duplicate effort when we don't need to.
And R3 compatibility will be one of the things that future readers of R2 docs will want to know the most. Many of the early users of R3 will be familiar with R2, and just need to know the differences. There aren't as many as you might think.
Of course we can still make separate pages for the really different stuff like ports, graphics, etc. It would only make sense to combine pages when it would save us and the readers effort. We can even have separate function indexes for R2 and R3 that only link to shared pages when they are shared, if necessary.
Luis.
29-Jan-2010 3:09:29 (at)batman: Knowing that a few people are assisting Mr. Sassenrath still doesn't change the feeling for me that he seems to be carrying Rebol on his own. Apparently there is someone in charge of the OS X Port. I agree, it does seem like he is the only one developing the Core product: I can't find anything on the site that shows who is doing what. If he's out in the yard dealing with a bobcat, does Rebol development stop? An 'About Us' page with a 'who is doing what' summary would make it feel bigger than a one man band.
Rebol Docs: Hmmm... It would be cool to split them if you wanted to generate printed/pdf docs, else the merge would make the documentation too large if it included both. What about having the R3 docs available and instead of delineating the differences with R2 to provide a linkback to the R2 interpretation? And vice versa for those working up from R2. With links there'd be less clutter.
Cheers,
Luis.
Nick
29-Jan-2010 7:59:36 I like the idea of R2/R3 comparisons on the same page. I remember when learning REBOL, there was some sort of "changes in View 1xx" page - it was troublesome to have to look for features which existed in each version.
Kaj
29-Jan-2010 8:01:57 REBOL is a Genius Driven Design, so yes, Carl is pulling it. He has tried delegating with REBOL 1 and REBOL 2, but the result was not satisfactory enough. REBOL 3 is about pulling the core of REBOL back into Genius Driven Design mode and building a community to produce all the periphery around that. Since the core isn't in release mode yet, the community is not built yet, and as Henrik says, we're left arguing as kids while the head of the house is at work.
I guess Genius Driven Design is not for everyone. If you have a concept of security in your head that is based on spreading reponsibilities to multiple people, this wouldn't work for you. On the other hand, if you care about quality of design, this is the way to achieve it.
Cyphre
29-Jan-2010 8:10:24 Please, don't merge R2 adn R3 docs.
I'm sure people don't mind to do one more click to jump between the R2<->R3 related pages.
Also if you plan to put for example chat/developer feedack under each document page it would be really mess to read mixed notes for R2+R3 from people.
If you want to do merged docs on webpage then please make at least separated versions for offline reading.

DideC
29-Jan-2010 8:14:30 Docs : I prefer to keep R2 and R3 docs not mixed in the same page.
Having a link from R3/R2 to R2/R3 version of a function would be nice.
And at best, having another link "show both R2 and R3" in the same page would be even nicer. I think that it can be done by a special page, using HTML Frame or Div side by side for exemple. We don't bother about indexing, as content is already indexed from the R2/R3 respective pages (so think to disallow indexing there). And WIPWiki can be enhanced to generate this third page while it update the R2 or the R3 one. So we can have :
/r2/docs/functions/print.html
/r3/docs/functions/print.html
/compare/docs/functions/print.html
Still to the user to drag the scrollbars but it can be enhanced later.
Page not found
29-Jan-2010 10:15:49 http://www.rebol.com/cgi-bin/how-to/encrypt.html
Page not found or bad link
Sorry... the page you requested was not found.
Henrik
29-Jan-2010 10:40:17 Seems you need to remove the cgi-bin/ part. Then the link works.
Carl Read
29-Jan-2010 13:44:19 Pekr: "When R3 family is out, I don't care about R2 anymore."
R2 support needs to be continued for practical business reasons. Namely that if R2's treated as abandonware, people will have good reason to suspect R3 may go the same way in a few years. Why spend months or years developing software that might then have the rug pulled out from under it?
RT's been around long enough now to be judged on its past and current activity, not its promises. Continued support for R2 could be the most cost-effective marketing they can do.
Docs: Since there's conflicting wants on splitting them and joining them, why not have them separate but with a bit of REBOL code to build a combined set of docs too? Giving you the best of all worlds.
Carl Sassenrath
29-Jan-2010 14:25:01 Thanks BrianH, for fielding the above questions.
And, the above "page not found" link fixed - problem was here in the blog page.
To answer Carl Read's post: I think our "allocation" algorithm is recognizable. It's a queue with timeouts.
That is, we try as much as possible to concentrate on projects at the top of the queue, those we believe most important in the future. But, after a given period of time passes we must return to service some of the items lower in the queue, otherwise they'd never get attention. Both R2 and Website are examples.
Also... I came to the same conclusion on the docs. They can "appear" separately, but under the hood, many are generated from the same source pages.
Endo
29-Jan-2010 15:06:37 I prefer separate docs for R2 and R3, and one or two docs such as "porting R2 scripts to R3" and "R2 & R3 differencies".
Peter KRB
29-Jan-2010 19:38:49 Congrats on the new site, easy to navigate and read, this page,

http://www.rebol.com/docs/docs.html
might be shortened up a bit, possibly presenting to much info
http://www.rebol.com/docs.html
views better
Giuseppe Chillemi
29-Jan-2010 20:06:04 Congratulation Carl, Great effort and great result ! Hope it speeds up the maintaince of the site.
Also a question: is foreign language translation of the same page supported ?
Giuseppe Chillemi
-pekr-
30-Jan-2010 1:16:56 Carl - rebol.com is now nicely streamlined and ready for new gfx and layout, but I have still one problem with one section. On the main page, there is a link to Tutorial + Examples, as well as to Documents. Those two links lead you to different subpages, and I am not sure it is good or necessary.
I am experienced reboller, and when I try to orientiate mysel on Tutorial + Examples link, it is a bit chaotic for me, too many resources, from which I am not sure what to choose. But that might be just me, I don't know. Try to imagine new person comes to website, and tries to learn about REBOL. I think that less is more sometimes and I am not sure there is a need for two subpages here.
What is your opinion on that?
batman
30-Jan-2010 7:10:10
He has tried delegating with REBOL 1 and REBOL 2, but the result was not satisfactory enough.

was overdelegation or underdelegation done ? If he is directing them to implement his vision, and reviewing, so they stick to his vision, it shouldn't cause any problem. If those he has delegated to, can't deliver according to his expectations, then they shouldn't be involved with the work in the first place. This is done everywhere. besides the correct level of delegation doesn't exclude him for getting his hands dirty if he wants, but at least he won't be coding 95% of the project by himself. That will release him to spend more time on strategic things.

I guess Genius Driven Design is not for everyone. If you have a concept of security in your head that is based on spreading reponsibilities to multiple people, this wouldn't work for you. On the other hand, if you care about quality of design, this is the way to achieve it.

I don't know what others in the community think about that .
I don't see how proper delegating and supervision will affect quality. I see it being able to achieve quality and security at the same time, if not more, for all the reasons cited above.
God forbids, but what about if Carl disappears or falls ill? Is there anyone else to carry the flame? we have to be realistic and plan for it. One person can do so much by himself.
the correct level of delegation has a multifold effect, e.g planning for bad times , keeping rebol 3 moving on track, training some smart rebolers and giving them the chance to be mentored by carl so that they can carry on the project and having many of his ideas implemented concurrently rather than sequentially.
I am pretty sure Carl would want his project to continue, That's his baby.
in my opinion, everytime someone raises an alarm, just saying "this is not for you ... " is not a well thought out comment or an excuse for sloppiness or inefficiency, or planning for the future, or whatever....
graham, henrik, luis, pekr are just stating facts that other less vocal people see as well.
if you want a rebolution, you need lots of people to join and not turn them away with those type of comments, otherwise this will just fizzle and you will end up with only a small protest by 5 or 6 people only.

Alan
30-Jan-2010 8:55:02 Those previously hidden docs (ie: encrypting strings and files)are still hidden from the main page I believe...I can't navigate to them from the home page...
Nick
30-Jan-2010 13:34:05 The encryption docs are found under Documents -> REBOL/SDK: Software Developer's Kit
Brian Hawley
30-Jan-2010 17:41:47 Carl: Having separate pages generated from a common source would solve my documentation management concerns and Pekr's concerns about confusion. That sounds like it could work.
Kaj: "Genius Driven Design"... Never heard that term before. I like it, and it's apropos for the R3 project.
Batman: We certainly don't want to discourage people from participating, so your concerns are very real for us.
If it helps you to know, Kaj's "Genius Driven Design" doesn't preclude delegation of work, as long as the design criteria are met. As long as there is agreement about the principles, the Genius can delegate to other geniuses.
Carl has delegated a lot to people already so he can focus on the stuff that really needs his attention. The Design that he's the Genius at is mostly the overall language model, the main system models and the trickier natives and native dialects. Most of the mezzanine work is currently done by others, and a lot of the research and experimentation about native implementation strategies is being done by various people with extensions and the host kit. All of the platform-specific code is in the host kit where anyone can work on it. Some of the detailed native implementations are work-for-hire. There's even multiple people who review bug reports and write docs (though not nearly enough).
So, it's not just Carl.
shadwolf
2-Feb-2010 22:30:20 Congratulation Carl for your new rebol.com website.
-pekr-
3-Feb-2010 2:09:23 Shadwolf - the website is still not finished :-) What Carl did imo is to redesign the backend infrastructure and structure of site itself, which is now moved to R3 script backend, WIP wiki.
What is still needed is - layout, design work, and front page segmentation to provide some more marketing oriented message towards particular end target groups.
But overall I agree - new website is simpler to use, and that is a very good sign ...
AR
3-Feb-2010 7:26:38 On www.rebol.com/tutorials.html the link for
"REBOL Bots" Tutorial Article published in Web Techniques magazine
does not work.

Maybe you mean this page
www.drdobbs.com/architect/184413924?pgno=11
hacky
4-Feb-2010 21:55:28 im curious does rebol use some non-POSIX sort of hacky way of storing a sockaddr and so cant do IPv6 ?
sockaddr_storage is the POSIX way and allows for IPv6 use as well as IPv4.
see http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/socket.h.html
so it even on the table for rebol now the US Govt mandate it inclusion, or is that just one more thing to add to the very long lists of things to do sometime in the distant future if a 3rd party sees fit to add this basic option if they can be bothered ?
Kaj
5-Feb-2010 3:51:36 If it's important, someone will be bothered to implement it. It could be you if it's that important to you. :-)
nighthawk
15-Feb-2010 0:08:50 have just recently discovered rebol and am blown away by the entire concept. however, my enthusiasm has been tempered by the opinions expressed in this blog regarding the unpredictability of, and drawn out release dates for, R3 and related new features. what is the target GA release date for R3? is there one? i've searched the site and haven't found any info on it. for widespread rebol adoption to occur, particularly in the commercial product development realm, users must be confident that when they're told that this product or that feature will be available on X date, come hell or high water, it'll be there and i don't mean 2 or 3 years from now. it's been my experience that attitudes like this "genius driven design" concept should be replaced by "it's good enough," otherwise, R3 will never get out the door and rebol will be known as the best app development idea that hasn't gone anywhere, which, so far, at least, seems to be the case and is a damned shame. thoughts?
Henrik
16-Feb-2010 1:11:27 Currently the target release date for R3 is "when it's done". I know Carl and other developers is pushing hard to move toward beta and it moves forward every single day, but I think there is still a while to go, with hundreds of things to do and consider.
And one important note:
it's been my experience that attitudes like this "genius driven design" concept should be replaced by "it's good enough"

When dealing with an end-user product, it might be applicable, but the reason REBOL has blown you away is because of the "genius driven design" and the reason REBOL 3 is being made is because of the "good enough" parts in REBOL 2, that in the long run didn't turn out to be good enough. :-)
The solution to get it out of the door would be feature limitation for the first beta release. Whether R3 will get a GUI, threading and a complete suite of the protocols available in R2 for the R3 beta, time will tell.
The best idea is for now to either observe development or participate: R3 is complete enough now to begin learning it, so you already will be good at it, when it goes beta. We are at a point where the language design is largely set, with bug fixing and specific high level features remaining.
What we don't have, is the user input from beginners, who can point out fundamental mistakes in documentation or in R3, that the experts failed to observe. So feel free to download the latest alpha and kick the tires.
nighthawk
16-Feb-2010 10:57:43 i appreciate the response, however, after analyzing it, stand by my comment: "rebol will be known as the best app development idea that hasn't gone anywhere, which, so far, at least, seems to be the case and is a damned shame."
to me, the rebol concept is so good, time should be compressed to finish up r3 and get it out the door. time should be of the essence, but for whatever reason, isn't. CS writes of how time and circumstance have converged to make it rebol's time, so where's the necessary urgency take advantage of it? need development staff? go get some vcap dough and hire them. you gotta define goals, choose target dates, write everything down, publish it so you can't postpone or shirk, and then work the plan. that's the only way i know how to get things done. if you don't do these things, don't have the resources, have no time parameters for product beta and GA, and want to be total master of your own domain, then what you have is a hobby, not an enterprise. where am i wrong?

Comments on: REBOL Status Report 2010.2

And finally, back to R3...

Comments:

Post a Comment: