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

Is it a slow day at work John? What has caused this outpouring of angst?
I have to say that I could not agree more with everything you have written.
In particular a very special form of hell exists for those who want to fork
processes from an environment already having more than one thread of
execution.

And on that threadinf front, a colleague of mine assure me that we can get
all the synchronisation right if we have a bit more time. Me? I think the
approach we are using is wrong if we have to pay such special attention to
getting synchronisation right. You might be thinking Scala and actors, my
fried in thinking Java and "synchronised".

As for GUIs I wish I could get away from the damn things. Where I work it is
all but impossible to get people to use the keyboard for simple
investigations of  log files and the like.  We have four software engineers
and one EE that isn't scared of software. Everyone else is pretty much
totally against typing. If they can't push a button, it is TOO hard. Having
said that at least one of the guys I work with thinks Java is the bees-knees
and cannot see why you would ever want to use anything else?

FYI, our product runs of top of an embedded Linux. One with a decent Bash
shell on it too.

Me I like scripting. Powerful stuff. But just a bit too old fashioned for my
colleague with the Java fetish.

Also, I could not agree more on XML. Bloody awful to work with. JSON is
nicer, and can be readable. As is YAML. I wish I could dump this XML crap
but my guys like it too much. So, I must be wrong.

Anway, that vent was fun. We must do this soon. Back to work for me!

Regards,

Gordon J Milne

2009/5/4 John Carter <[email protected]>

> Simplicity is the price of reliability....
>
> And I'm on a campaign to regain Simplicity and Reliability in my life.
>
> I long while back I did battle with writing gui's apps and came to
> this conclusion....
>
> 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.
>
> Otherwise on balance life is more complex and buggy.
>
> 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.
>
> 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.
>
> So here is my (current) list of "Yes you can do this, but you "Never"
> should...."
>
>  * Never write a sort. The library ones are better.
>
>  * Never write (yet another) linked list implementation if
>    malloc/realloc will do.
>
>  * Never use a binary format if a human readable intermediate 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.
>
>  * 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.
>
>  * Never write a GUI unless you have more than a 100 times as many
>    users than coders, or on balance you have made the universe worse.
>
>  * Never do concurrent anything if single will do.
>
>  * Never do multi-thread if multi-process will do.
>
>  * Never invoke process fork from a multi-threaded app. Yes you can,
>    but somewhere along the line you, your colleagues, or the libraries
>    you use will get one of very fine lines of fine print wrong.
>
>
>
>
> John Carter                             Phone : (64)(3) 358 6639
> Tait Electronics                        Fax   : (64)(3) 359 4632
> PO Box 1645 Christchurch                Email : [email protected]
> New Zealand
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>