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.

On Communication

Pekr's point is very reasonable, and Graham, Shadwolf, and others agree:

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.

Public Lists

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 happen?

Evanglists

Karim writes:

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 other websites.

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.

The Masses

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 rocket science.

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.

26 Comments

Updated 13-Nov-2024   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code