Re: Guis, Processes, Threads, Simplicity - A Personal Manifesto

On Mon, 4 May 2009, John Carter wrote:

> Unless the app is to be used by more than a 100 times as many people
> than are writing it... it should be a command line app not a GUI.

Why not this: it should be a library rather than a command line app or a 
GUI app?

> Recently I have wasted more time than I care to mention on the
> intersection between threads and processes... and have written these
> rules into my soul.

It would be cool but eventually you will have to reject your rules and 
spit on them. With all your soul.

> a) Prefer single process to multi.
>  * Never do concurrent anything if single will do.

If you have a multi-process problem, you could solve it in a 
single-process manner by making a task scheduler to simulate multiple 
processes inside of your single process. It's sort of like writing the 
kernel of an OS, but if you have a single stack, it's even more tiresome.

Such a simple rule doesn't work because it doesn't tell you to what extent 
you should try to use single process instead of multi process.

> b) Prefer multi-process to multi-thread.
>  * Never do multi-thread if multi-process will do.

If you have a multi-thread problem, you could solve it in a multi-process 
manner by doing a lot of routing of data from process to process using 
pipes and a lot of management of the synchronisation of all copies of the 
data. I mean that there are problems for which pipes and RPC really suck.

> c) A process may invoke a multi-threaded app (if it must), but invoking 
> "fork" from a multi-threaded app is too fraught with subtleties. It can 
> be done, but if you want it reliable... don't.

Multi-threaded apps often need to start other programs and you can't 
control the need by telling your customer that it's evil. Ok, the customer 
will sign with someone else and you won't have to implement it yourself, 
which is probably what you want. ;)

>  * Never write a sort. The library ones are better.
>  * Never write (yet another) linked list implementation if
>    malloc/realloc will do.
>  * Never write an editor. It'll will suck your soul, and then still suck.
>  * Never write an interpretor. Use a standard scripting language, they
>    are _much_ better, more powerful, well documented and less buggy.

Do you know what the first wheels looked like? They sucked. Somewhere 
along the line, there are people who really do reinvent wheels and it 
makes better wheels that you are using every day.

Well, usually, you don't need to reinvent a sort, an editor or an 
interpreter, but some people actually have a need for it... though a lot 
do it just because they feel like it... NIH vanity, or a manner to 
self-train, or just a sense of adventure, or... yes, some people reinvent 
wheels simply because they don't want to look for a wheel in the first 
place.

>  * Never use a binary format if a human readable intermediate will do.

The "non-binary" format is only readable because you have a reader for it. 
The "text editor" is your reader. Then a "human readable" format means 
that humans have to do all the rest of the reading (parsing and stuff).

What you have is a bunch of tools that understand the "text/plain" file 
format and that gives you a base layer of interoperability. But if you 
have sufficiently portable tools that can process a non-"text/plain" 
format in any way you might need, then so what?

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal, Québec