RE: Software Vendors

[boothm@xxxxxxxxxxxxxxxxx]

I hear what you are saying, but the reality today is that GUI = Windows 
from Microsoft.  The whole design changes.   I am not suggesting shoddy 
work, but what if the work is perfect and it doesn't perform the same way 
on 12 different machines?  For example, would anyone pay you to program 
for all screen sizes, including  640 x 480? Of course not, but someone 
will cough up one of those old screens and it will look like a bug to 
them. 

_______________________
Booth Martin
boothm@earth.goddard.edu
http://www.spy.net/~booth
_______________________




"SIMS, KEN" <KSIMS@SOUTHERNWINE.com>
Sent by: owner-midrange-l@midrange.com
11/29/1999 08:10 PM
Please respond to MIDRANGE-L

 
        To:     MIDRANGE-L@midrange.com
        cc: 
        Subject:        RE: Software Vendors

Hi Booth -

>Date: Mon, 29 Nov 1999 17:08:26 -0500
>From: "Martin, Booth" <BoothM@goddard.edu>
>Subject: RE: Software Vendors
>
>This discussion interests me especially since I started doing some
>client/server event driven programming.  "Bugs" means something different
to
>me now than it did on green screen and I am a lot more tolerant of the
>concept itself. 

Yes, it is true that event-driven programming is trickier because of the
timing issues and interactions with other processes.  Whether it is
client-server or not is not a major consideration.  But that is still no
excuse for shoddy programming.  OS/400 has a lot of event-driven coding 
but
you don't seeing blowing up every five minutes.

>On the green screen it tends to work or not work  -  fairly simple to be
>"zero-defect", but in the world of GUI and client/server that whole
paradigm
>disappears.  Instead there's all sorts of choices, shared DLL's, and all
>sorts of chains of events and unexpected consequences.  In other words,
>Green screen errors <> gui bugs. 

You're mixing apples and oranges here.  GUI has nothing to do with whether 
a
process is procedural or event-driven, nor does the use of shared DLLs.

I haven't done any event-driven programming for a number of years, but I
have in the past; in particular a repeater controller for an Amateur Radio
repeater.  It was event-driven, but it was not GUI, nor did I use any 
DLLs.
Since it was written in a procedural language, I had to write the whole
event processing underlying code.  Was that an excuse to have bugs?  Not 
in
this lifetime!!!  The hardware was unreliable since the interface boards
were homemade and since I was using the base system in ways that it was 
not
meant to be used (for example, I sent data OUT one of the joystick ports);
but the code was solid.

Ken
Southern Wine and Spirits of Nevada, Inc.
Opinions expressed do not represent those of my employer or anyone else.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to 
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: 
david@midrange.com
+---



+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---