Comments on: In reply to comments about grindstones, caves, focus.
Thanks for your comments on my prior blog, Grindstones, caves, focus, and multitasking not.
Because this is an important topic, rather than reply to your comments
within the comment section, I'm posting replies to each of the main
points. If I missed something important on the topic (there was
off-topic chitchat), let me know.
Pekr's point is very reasonable, and Graham, Shadwolf, and others
Just expose yourself via some one-sided communication channel. And what is better than some blog? Why not, at least once per 2-3
weeks, to write small blog about how you added some cool function to
VID, show some diagram, screenshot, piece of code, whatever...
I agree, but I know that I'm reluctant to discuss the project during development when many design decisions are still pending and up in the air.
Let me explain by way of a current project:
The GUI project is deep. I could write up a message from time to time, but when you see it, a lot will have changed. For instance, the original GUI design specified important concepts of "look" and "feel". After several weeks, I tossed those concepts entirely. Why? Because they had become non-beneficial to the design.
So much of good design is not just about adding and improving concepts, it's also about removing and simplifying concepts.
Think of architects that create large buildings. They don't just keep adding new ideas. They constantly refactor and reduce.
Still, it seems there must be some way to write more about it... so, essentially, I agree with your point.
On Creative Process
This comment from Kaj is so true I want to print it in big letters and
hang it over my desk...
I think the point of creativity is that you don't know exactly what will
come out at the end of the process. It's a continuous backtracking
process and pretty much impossible to write and tick to-do lists for.
This mistake is made often by other people who work serially.
Yes, this "truth of development" I've seen my entire career, even
at HP, Amiga, Apple (but often ignored).
However, I still use todo lists... because they are lists of end
requirements and less of how it works. I always measure
against those objectives.
Carl Read is reading my mind again with:
Have a public to-do list, where you can add comments to each item as
well as just tick them 'done'. It'd show activity as well as bits of your thinking here and there.
It is a good idea and I want to see that happen. I think of it as a requirement of the R3 project. There are many components that need to be done, not by me, but by others.
The question then becomes, what are the best methods of making this
Maybe, Rebol Technologies needs an "evangelist". A kind of guru who
likes to speak about Rebol.
I've thought this for a long time, and I really would like to, but it's not clear to me exactly how it would work. The reason is that most
developers want real meat, not tap-dancers... as we see from so many
Now, it could be that the evangelist is really more like the lieutenant
concept that Brian Tiffin noted. It's a job based on specific needs... like coordinating source contributions or validating their quality, getting other websites to promote REBOL, filtering and funneling questions to me, and other things that I might think of, if I spent more time on it.
Popper talks about the masses...
the masses are only interested in real world working code and apps
that do the job, they see an app, use it, get interested in its
construction then start advocating its use were ever they go, its not
Yes, that's a good summary of the state of computing and the Internet,
and why I've concluded that we (humankind) may be doomed in the
next decade or so.
That's the main reason why my DirecTV box is a piece of junk, why
most of our friends own computers that are a wreck, why my cellphone
was totally messed up (but, I got a new iphone this month), and even
why a gas pump at a gas station recently crashed on me (but not in the way that gave me 10 gallons of free gasoline.)
The problem is this: real physical designs (like buildings, planes,
highways) require real design. However, computer sofware
designs can be made to work without any real design... just by using
enough bandaids, gum, and tape. (Just imagine if we could see those
designs as buildings... we'd run for cover!)
Picking a language
Thaddeus is thinking over his choices of languages...
I intensely dislike C, Java, and their progeny. Also, pretty much all of
the other languages I've seen have some kind of major downside, like
not being supported anymore, or not being on more than one platform.
The way I see it, I now have the choice of using Euphoria 3.1, using
REBOL 2.7.6, waiting for Euphoria 4.0, or waiting for REBOL 3.0.
Henrik's reply makes sense: "it's a good idea to learn 2.7.6, because
no matter what, you'll need some of the skills for R3."
My reply is always: use the language that makes the most sense for
your product. For example, I don't like using C code, but that's that
REBOL is written in (and, of course some of you will way... I don't have
a REBOL compiler, yet. ;)
Also, always be sure to point out features you find useful in other
languages. We can't always do them, but as R3 progresses, many may be possible.
And finally, I think R3 will make it easier to build much better GUIs... in much less time.
What is the focus?
Icarii cuts through the chitchat with:
WHAT is the top level thing you are currently working on? You mention
that you are working on something but we have no idea what it is.
Answer: it's the GUI, the new "VID" (quoted, because I want to rename it, as it is not that much like the old VID.) This project is huge... and has been through many design stages and revisions. But, it is running, and I want to say more really soon... if this wild horse will just calm down and stop its endless bucking.
Carl, your blog is an explanation, but not a solution to remedy the situation. R3 project was (and hope still is) supposed to cure also organisational aspects of REBOL development. We lost many ppl's interest, because mostly only you can update/fix R2. That was supposed to change with R3, but the problem is - we are NOT there yet.
That is why many ppl opted against VID3.4. VID is fine, but why VID, and not continuing on important Core features, to finally upload R3 host sources to DevBase, and allow others to contribute? Even Unicode's design is not fully finished (collations, sorting, etc.).
If one would like to continue with e.g. SQLite usage, we need library interface. For that, we will probably need plug-ins, for those we will need modules, for those object semantics need to settle, etc.
The point is - if we don't cross that break point, it is still the same situation as with R2 - only RT can do important things for us, not the community itself.
So - after VID is finally in some usable stage, let's please update the project plan on rebol.com, but in such a way, that will lead us to more community involvement ASAP ...
Well a matter of fact is that rebol is unique ....
After 10 years no one intented to clone it and for several reasons 1st rebol have plainty of amazing ideas in it and that's not easy to redo them.
Second rebol is still underground not alot of people knows it and even less people plan to use it in big industrial things.
Cooperative work means trusting. Sure all of us can't come out with things as sharp as you would done them. But sharing the duty gives you more time to spend on the design. And my dad always said me it's by forging that you became a blacksmith. That means through your past you built a big big knowledge and unfortunatly none of us experienced the same. Knowledge is ment to be shared.
And by sharing it we can enhance our skills and even more contribute to the project.
You took a really good example the architecture industry.
the architect plan the building says "look here is a draw of what I want to build" but he didn't build the building.
I think actually you are doing all the job alone and for us a part cheering you there is nothing left to do...
3000 years ago egyptian built the 3 pyramides and obviously that wasn't the work of only 1 guy.
I understand that you spend alot of time on VID. VID is the showroom of rebol... Unforunatly if you can make a PHPBB clone using full rebol/cheyenne for the people using it there will be no differences betwin the php version or the rebol version (well rebol version will be smoother :P and will never crash and will take less space in storage drive but unfortunatly those aspect the user that post messages will not even care)
VID is important that's what makes rebol a totally different thing.
Maybe too you have a better idea on how the other modules have to be done and you really want to comme out with a new design for VID wich would be a stable base for the next 10 years.
Well to conclude we are not saying your work is not interresting we are just pending to get news. From our point of view no news means no news. From that point any speculations are allowed.
What about doing just a roadmap with all the parts of rebol and a planned time to work on each of them and every week you come out with the advancement on each part by just putting a simple comment. And if a part keeps you working more then planned you simply on the week report says you are busy you need more time to work that part.
I think in that process it would be cool for you to get acknoledgement from your fans if they like or not the way you take.
I mean usually in creativity we have creators that come with ideas and the public likes them or not. Maybe for computing there is another way (opened by GPL) where you can see the software as a living thing enriched by the cumulation of the experiences of each and every conceptors.
But the problem with rebol is that it have to stay tiny and simple and that makes the groth of the builtin functionnalities really painfull. Since the whole computing area can't be delivered into 512Ko we have to make compromises.
evangelist can be big companies saying to the world:"we work with rebol and here are the benefits compared to the previous solution 3 coders instead of 400 10 hour of work instead of10000 etc...) using rebol we big companie could save 100 biillions dollard and offer to each and everyone of our actioners a brand new prosh carera II etc..."|
It very much seems that like a good red wine Rebol 3 will be ready in its own time. It cannot be shaken or poked into action as it will turn into the equivalent of vinegar.
Waiting for Rebol 3 is as mind numbing as watching wine mature.
A simple one line blog of what you are working on each day, no explanation required, would change that at a stroke.
"After several weeks, I tossed those concepts entirely. Why? Because they had become non-beneficial to the design."
Reading an adventure that delivered no setbacks to the hero would make for a dull novel...
You'll get differing responses to whatever you emit from your cave. Some will find it innately interesting, others will be happy or annoyed about where you seem to be going and others again will think you should be doing something else entirely. Etc. This can't be helped, but it should be better than long silences.
"again"? Well of course - it's quite an interesting one!
Peter really said it all, but maybe I can offer some more explanation. Shadwolf, and Carl correct me if I'm wrong, but I think Carl tried the architect approach with REBOL 1, and it worked only half. It was done by several people because it was a big project, but the complete interpreter needed to be rewritten for REBOL 2. Halfway REBOL 2, Carl tried open-sourcing some parts, but it didn't take off because many of the ingredients for a community project were missing. It's an attractive comparison, but software development is really quite different from building construction. The architect would never be able to construct the building himself, but in software development, a talented individual can. Further, even if you demotivate your builders by whipping them, it is still possible to build pyramids that last thousands of years. In contrast, even well-willing and highly motivated programmers often ruin a software project. Even smaller parts of the construction are too complex and too intertwined with the rest of the design to be done well by less talented builders. To visualise the difference: building construction is about adding more stones every day, not about taking them away and rearranging them almost to the end of the construction.
Software development is really much more like cooking. The chef himself can do it best. And too many cooks will spoil the broth. If you do spoil it, you can still eat it, but it will leave a bad taste.
I have confidence that the R3 design is solving the problems of establishing a base for community development. But I think we all agree. We are hungry and at the least we need some small reports from the kitchen now and then.
Insamuch as the comments regarding your lack of posting seem to deter/alarm blog readers, please note that you may find it so if you noted that the regulars stopped posting replies for an inordinate length of time...
As a midpoint, let's try to find a solution: If DevBase is the only current 'progress' indicator, what about interfacing DevBase to a webpage (limiting view options as necessary)?
Carl it sounds like you know people are irritated that you don't communicate more, and maybe you aren't totally sure why. It is your process, and it works. So, if it works, stick with it?|
RE: I've thought this for a long time, and I really would like to, but it's not clear to me exactly how it would work. The reason is that most developers want real meat, not tap-dancers... as we see from so many other websites.
Have you guys looked at the communities that get grown using evangelists? They are "the masses". They are fickle, and often thoughtlessly praise technology without really understanding it very much.
I don't get the impression that such folks are the norm in the REBOL crowd.
RE: the masses are only interested in real world working code and apps that do the job, they see an app, use it, get interested in its construction then start advocating its use were ever they go, its not rocket science.
Actually it is rocket science. It is really hard. 90% of software projects fail because people don't want to accept this.
I know these things cant be set in stone, but some incremental delivery would be really useful to see progress and to know that R3 is coming. If you were worried about releasing incomplete functionality, it could be time limited (1 month after build). Seeing progress against a plan for the incremental delivery would be even better. Are we X% there? (this could be in terms of gross number of chunks of functionality, of course we all know the scale is not linear)
Absolutely agree with pekr that we need core aspects working as much as (if not more so) than the VID aspects. If the framework architecture can emerge, then the community can get to work building other parts of the jigsaw, and so the outside world will see the edifice emerge.
Carl, I have had to explain the merits of your new "VID" development for people whose projects don't require GUIs or graphics. The basics can be figured out from the hints you have given so far, such as changes to bind and send.
It would really help if you could give some more direct clues as to the effects your VID work is having on the non-graphical underlying runtime. This would help alleviate the concerns of those REBOL developers who don't use REBOL as much for GUIs, but more for web and server applications.
The designing process shouldn't stop the production process. Both should be done in same time but not on same time scale...
By nature conceptualising things take time. It always start with a basic idea. And after we try several implementations we get or not the a product that respond the most to our idea. But on the way you can see the basic need evolving too wich implicates even more time.
But for the people outside this process it's frustrating to not being able to contribute or to know what are the current advancement of the process.
I'm less concerned by the time it will take to achieve R3 than to get news it's like an "hello world!" a proof that you still concerns about the topic ^___^.
RE: the REBOL evangelist idea.
Evangelists are people that interpret a given subject to people who have a beginning interest in that subject. I've been one of those people for a period of years in an area unrelated to computer languages and software.
That said, most of the discussions on this blog, though very interesting and definitely cutting-edge, are not of interest to people who want to employ REBOL as end users. They are of interest to people who are coding REBOL.
So the "evangelist," whomever that is, explains to end-users how REBOL works for them. The most powerful explanations are demonstrations of the problem-->REBOL-->solution kind.
Carl has done a great job of that in his Quick-Start tutorials for the REBOL version previous to R3. Having someone continue that function would, I believe, increase the communication with end-users that will spread REBOL faster.
Who will it be? I think it could be someone with enough appreciation for coding REBOL to explain the advantages to end-users. Once end-users see the simplicity and speed of REBOL, they will spread the word. Whomever will be the REBOL evangelists (because it will take more than one) needs that combination of technical understanding and communication skill that passionately expresses all the REBOL advantages to people seeking elegant solutions to their computing problems.
This is a huge, ongoing task. And REBOL will have to be stable long enough for that communication to take place.
Maybe the REBOL home page could be automatically updated with a synopsis of each new post to REBOL sites. This feature might enliven the home page and reduce the pressure on the CTO to provide content when, of necessity, there are other priorities. It may also encourage more community awareness and involvement.
Just In: Rebol Talk Forum: "text too graph"
August 23, 2008, 02:26:44 AM
The next post to the forum might be a library script, or from the REBOL TALK forum, etc.
This could be added to the page in the area of say, the REBOL 3 Project table.
Or perhaps Update: instead of Just In: |
Surely, with all the technology under our fingertips, we could actually 'use' the computer to take care of these updates... A window onto DevBase on the front page would do.
KC: I'm a bit weary of that, check some new posts on older blog posts...
Looks like the cave has beckoned again... :P
Do the words 'hobbit' and 'precious' come to mind to anyone else?...
With recent advancements of java-script (Google V8, Mozilla's Spidermonkey or SquirrelFish (which might be even 1.6times faster than V8)), most ppl might find its speed more and more acceptable for RIA like apps. Current situation with R3 does not really help anyone and lowers chances for the overall R3 success.
Carl, we really need to move on, to allow community to get involved, to get further development organised by You, as month by month, the window of oportunity is slowly closing ....
|drag applets and run the|
you forgot to mention the highest threat to the likes of R3, that being the re-introduction/implimentation of java drag applets by such a powerful and well respected org.
its being pushed really hard this time around, so it seems the so called window is already closed sad to say,it might not be a popular thing to point out here but the fact is they do supply all the working GUI and related code you might need to use these options.
it already sounds interesting to many coders out there today and they are looking to use it apparently.
Also highlighted is the capability to drag applets directly from a browser and run them as desktop widgets.
This is being done by a new implementation of the Java Plug-in. "Browsers don't need to embed the Java [virtual machine] in them. Bryant said.
"My end users can take the mouse, _drag that applet out of the browser, drop it on their desktop and now it's running as a desktop_ [application] outside the browser," Bryant said.
A browser-independent architecture in Java SE 6u10 enables the plug-in to operate in the same fashion across a variety of browsers.
A modern look and feel is featured via Nimbus, offering enhanced user interface controls for developers. It is drawn using Java 2D vector graphics.
about the only thing they dont seem to do _yet_ is optimise for SIMD (SSE*/Altivec etc) Co-Pro general use.
Java is not RIA and is never going to be - it is monstrose thingy :-)|
yet another 30 days and not a single peep from the cave, nothing to see here, move along please....
i hear java is getting more coverage and market share again.
and they are doing this by getting into the up and coming Mass Wireless Docsis WiMax world deployments, and kit in a very big way, due to listening to the users and vendors wants and needs, and making the effort to provide these people what they need to profit and grow right now and the near future, they even talk to them and provide timely updates.
a little unknow fact for you readers,there was a potential for Rebol a few years ago to get into the UK cable STBs market and firmware to replace the old TCP:IP GUI and back end, but when it was layed out for them to try and talk with the executive involved in exploring new options, the answer came back from rebol central in effect "we dont want to try as we dont have the staff to support it"
they missed their chance then and they are missing so many chances now, and thats a shame, when you get people giving reasons not to try, rather than reasons and actions to try, and yet other people defending inaction its time to say good night and see you sometime.....
30days, there are two blogs - one general blog (this one), and R3 specific one. There is now some activity in there.|
30days, Carl doesn't want to "put the cart before the horse" so to speak.
We all realize he is on to something. If he jumped into that market he would have been drowned and more locked into the current Rebol offering. He has the opportunity to get this right. Yes, it's taking a lot longer than we all want, and many opportunities have been missed. There will be others. If R3 is going to be what we are all hoping for, and what has been keeping here, the opportunities will be there.
Patience and enjoy what you have with R2.
I think at least one "product evangelist" should be focusing on showing how to use Rebol for quick solutions to problems. The videos that Nick Antonaccio is doing are an example, see http://musiclessonz.com/rebol_video_links.html .
One or more others can show end users how wonderful solutions built with Rebol can be, as Brian Deneen describes.
As far as R2 goes, anyone can add their own productions to the already existing work. With R3 not being released yet, someone needs some access to what is happening, along with the discretion that will minimize the "oops, we didn't go that way after all" problem.
Post a Comment:
You can post a comment here. Keep it on-topic.