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

> 
> Simplicity is the price of reliability....
> 
Ye old KISS principle :)

> 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.
> 
Unless the customer demands it, which he more than likely will (he wants a
"modern" looking application to replace that terminal emulator based
mainframe system, not something that looks even older).

> a) Prefer single process to multi.
> 
> b) Prefer multi-process to multi-thread.
> 
> 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.
> 
Depends on the programming language/environment you're using of course. When
using Java MT is far easier to implement than is MP (and more reliable).
In fact with many languages running on VMs they will be implicitly MT.

>   * Never write a sort. The library ones are better.
> 
>   * Never write (yet another) linked list implementation if
>     malloc/realloc will do.
> 
IOW, don't reinvent the wheel. Quite correct.

>   * Never use a binary format if a human readable intermediate will do.
> 
Makes debugging so much easier. But can at times make reading/writing the
data harder.

>   * 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.
> 
Don't reinvent the wheel again :)

>   * Never use XML unless it is the intermediate format for more than
>     one independently developed application. ie. You need "validate" to
>     assign blame for borkeness.
> 
XML is overrated indeed. But many customers demand it irrespective of
whether it's useful or not. Again that "we want to be modern" thing.