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

On Mon, 4 May 2009, John Carter wrote:

> And I'm on a campaign to regain Simplicity and Reliability in my life.

I'll reply to all comments in this mail.

"Jeroen Wenting" <jwenting@...> said...
>> JC said..
>> 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).

Sure the customer is king... but I will make it clear to the customer
his options and the trade offs.

There is a factor of 100 (money / performance / integration /
installation / reliability /...) cost to a gui over a command
line. Bill Gates can do it (sort of, buggily) because he is shipping
millions of copies.

Often I'll do a "slow reveal". Deliver the command line version first,
saying this is just the first prototype... and then go off and do
something else for awhile.

Often the customer decides it's doing the job and integrates nicely
with what they are really doing!

If they nag the next step up is a thin web wrapper on a command line.

(Yes a web-server + browser is less simple... but the separation of
concerns is excellent, the factor of "millions shipped" reading
billions of hostile web pages means browsers are relatively bullet
proof as apps go.)

Never confuse what a customer wants with what he needs. An ethical
engineer accepts what the customer wants, then subtly guides the
customer to wanting what he needs.

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

Alas, no. The point about multi-process is the OS AND HARDWARE makes
some very very HARD guarantees about their behaviour. So your point
(almost) reduces to an argument not to use Javarish languages...

Except there is a backdoor. You can dissect your Javarish app into
multiple processes with simple inspectable testable (preferably
RESTful) interprocess comms between them.

The glitch is you tend to need something else to set up and watchdog
the flock of javarish processes. But that is something web servers,
inetd's, service engines are Good at.

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

Hmm. Not quite. Not so much "Don't reinvent the wheel" but more "You
need of the order 2000 ops before Brute Force Simplicity loses to
Science and Technology".

ie. Unless you have a really pressing performance need and an
excellent pre-debugged library... usually Brute Force Simple Linear
wins over Smarter Algorithm. This is in terms of Performance,
maintainability, simplicity and reliability!

M. Edward (Ed) Borasky wrote....

>On Sun, May 3, 2009 at 8:23 PM, John Carter <john.carter@...> wrote:
>> * Never write an interpretor. Use a standard scripting language,
>> they are _much_ better, more powerful, well documented and less
>> buggy.

> Yeah, but ... if you had given this advice before Python, Ruby and
> Lua were written, we'd only have Perl! :)

Actually no. We'd be stuck on the original "sh" :-))

But unless you choose to throw more time (and smarts) than Guido,
Matz, Larry at the problem. You are going to end up with a buggy,
poorly designed, undocumented, non-portable, inexpressive kludge with
no libraries.

One the other hand five minutes work will give you well documented,
portable, reliable products of 20 years evolution by some truly fine
minds, backed with huge libraries of resources.

To paraphrase Larry Wall... Hubris is one of the virtues of a
programmer...just be prepared to balance that with dollops of Laziness
and Impatience.

To the various kind respondees that suggested this manifesto needed a
blogish home...

Thanks...

I regard my ideas as coffee beans.

They taste better once they have been nicely roasted in an appropriate
forum or two.

Thanks.



John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : [email protected]
New Zealand