Bugs, Death and everything 
Author Message
 Bugs, Death and everything

Having read all the interesting replies to my call for help over using matcher arrows, switchon et al in sectioned POP-11 code, my previous queries over trying to get the mouse functions to return a continuous stream of coordinates for <move> events, and the refreshing conversation regarding X-windows and death; I find myself moved to make the following remarks:

I used to program embedded systems in assembly language.  The code was easy to write efficiently, and usually worked first time.  To debug it was easy because there was no one else's compiler or operating system to{*filter*}things up.  All the errors were mine (with one exception) so very easy to find and correct.  The exception being once when I tried programming a system where the hardware designer had forgotten to allow for a wait state on a rather over convoluted piece of memory page address decoding, and
 my efficient code ended up running too fast for the computer.

Interrupts worked nicely when programming directly to the chips' registers, and were never lost because I could ensure that the correct ones were enabled at the right times.  This also made multitasking a joy.

I was always certain of the data types and scopes, because I allocated the stack, heap and registers myself.  And pointers were easy to understand when they had their own set of address registers reserved for them.

Maths was fast and safe because such things as divide by zero conditions were all caught by a routine check on the floating point unit's registers and stack.

Best of all; I could design and build my own hardware if I wanted!

My colleague Alistair has said that I could have developed my image analysis and multivariate analysis system faster and more efficiently if I had used Z80 machine code rather than poplog.

He is probably right (except that I might have had a lot of paging to do with the Z80 address range).

Helen.

PS: Death also occurs with version 14.0 under sunview if you have a lot of windows open. (confirmed by others at University of Plymouth)



Fri, 22 Dec 1995 22:41:38 GMT  
 Bugs, Death and everything
Very interesting comments.

Quote:
> I used to program embedded systems in assembly language.  The code was
> easy to write efficiently, and usually worked first time.  To debug it
> was easy because there was no one else's compiler or operating system to
>{*filter*}things up.  All the errors were mine (with one exception) so very
> easy to find and correct.
> ....

> My colleague Alistair has said that I could have developed my image
> analysis and multivariate analysis system faster and more efficiently if
> I had used Z80 machine code rather than poplog.

A few idle thoughts. I wonder how easy it would have been for someone
else to maintain and debug, or port to another machine.

I don't doubt what you say, but I wonder about the *range* of
programming tasks for which what you say is true.

E.g. if it were program that did a lot of parsing or planning and had to
build lots of complex and tangled temporary data structures of with lots
of cross links, and had to reclaim space from time to time, and had to
compact to prevent fragmentation, and had to leave some things unmoved
because they were pointed to "from outside", and had to make use of
inheritance of types to sub-types to support "re-use" and "modularity",
would it still have been just as easy in machine code as in Poplog?

I suspect there are some programmers for whom the answer may be yes
and the vast majority for whom it would be no.

But maybe that's because I have been indoctrinated, and have never
written machine code programs?

Aaron



Sat, 23 Dec 1995 14:20:11 GMT  
 Bugs, Death and everything

In reply to my simplistic comparison of assembly language with poplog, Professor Sloman writes:

Quote:
> A few idle thoughts. I wonder how easy it would have been for someone
> else to maintain and debug, or port to another machine.

I would agree with Professor Sloman on this point; though it would be a lot easier for the person who originally wrote the software.  However: many 3GL & AI programmers tend to obfuscate their code for the same reason.  It gives job security!

Quote:
> I don't doubt what you say, but I wonder about the *range* of
> programming tasks for which what you say is true.

One adopts a different style to programming in assembly.  I would personally avoid tangled data structures or inheritance of types and subtypes.

However: routine algorythms for parsing can be just as easy in assembly.  They merely require an understanding of BOOLean operations and binary arithmatic to make them much more elegant than any solution in a higher language.

The same applies to routine control structures such as switch statements et al.

The code (my code) is easy to read because I believe in commenting each line and each routine etc.  I also keep rigidly to the correct fields in the code.

This does howeve need reasonably good touch typing skills to enable one to input so much text into the source files!

Helen.



Sat, 23 Dec 1995 17:23:40 GMT  
 Bugs, Death and everything

Quote:
> > My colleague Alistair has said that I could have developed my image
> > analysis and multivariate analysis system faster and more efficiently if
> > I had used Z80 machine code rather than poplog.

> A few idle thoughts. I wonder how easy it would have been for someone
> else to maintain and debug, or port to another machine.

> I don't doubt what you say, but I wonder about the *range* of
> programming tasks for which what you say is true.

My second inclination (after any setback) has always been to write
everything myself. I believe that for many problems it takes longer
to understand the (usually poor) documentation and limitations of a
software library package than it does to write your own. Not that
Poplog has poor documentation - it is actually quite good, but the
sheer amount of it makes it hard to find things: it takes a long
time to learn where to find things (large Lisp systems are even
worse/larger).

The best (only?) argument I've heard against this position (which Aaron
wonders about here) is maintainability. It is probably going to be
even harder for someone to understand my code (which I'm unlikely
to document more than necessary) than a library which is intended for
use many times (and which they might already be familiar with). There
can be exceptions (eg specific application/general package).

OTOH, I'm not (usually :-) tempted to write my own compiler, OS etc.
Large, familiar, well understood pieces of software with standard
interfaces can *not* be used ok - and this is my understanding of
the point made by the original poster - *unless* they are robust.

With hindsight, I think that the liability of X is going to seriously
diminish the attractiveness of Unix in the marketplace (and products,
like Poplog, which now rely on it). After my limited contact with X,
I am going to avoid any further contact as much as possible. Maybe,
as implied by some of the postings, it is now much improved. Too
late: once bitten, twice shy.

Nevertheless, Unix and X are still very popular on "Unix boxes" (of
course!) and in academic environments (I discount their commercial use
as database servers as irrelevant - but I won't go into that). So it
will be very interesting over the next three years to see what happens.
Will OS/2 make a comeback? Can microsoft swamp everyone
with NT? Who will be using Windows? Can IBM and Apple convince
everyone that Pink is the way forward?

Jonathan Cunningham

p.s. Relevance to popforum? Suppose, as I think quite likely, Unix
takes a diminishing share of the market (and maybe even unit sales).
Will people still use Poplog?



Sat, 23 Dec 1995 18:11:49 GMT  
 Bugs, Death and everything
I am moved to write by Helen's musing on the difference between
high and low level languages :-

Quote:
> I used to program embedded systems in assembly language.  The code was
> easy to write efficiently, and usually worked first time.  

How things look rosier from a distance!  You forget about the dreadful
performance because you didn't have enough time to encode the dynamic
allocation of 2D hash tables that you knew would be the key to good
performance.  Well, you wouldn't have done it in fortran either so
"clearly" using a high-level language doesn't help.  You forget about
the vast zones of memory wasted because you didn't bother with a proper
garbage collector (gee, a buddy system is good enough, what do you think?)
You forget about those awkward occasions when your neighbor (it was
never you) crashed every terminal on the system because they missed out
a full stop.  

Most of all, you forget that you were pleased when you wrote a chunk
of code to perform formatted output -- for the 15th time -- and it only
took you two weeks.  Yes, those were the days alright.

Quote:
> To debug it
> was easy because there was no one else's compiler or operating system
> to{*filter*}things up.  

It was also easy because it was so hard to write anything one only ever
wrote trivial code.  I, too, can debug assembler which consists of a bunch
of loads, adds, and stores.  It is when I am writing the code for
computing the transitive closure of relationships I keep screwing up.
Something to do with storage management keeps cropping up.  Perhaps
one day they'll be a general purpose solution ....

Quote:
> All the errors were mine (with one exception) so  ...

And all the working code was written by yourself, too.  It's about the
25th time I wrote a slightly different formatted print routine I began
to suspect there might have been an easier way of working.  (N.B.  Who
else have written formatted print routines in Prolog?  Hmmm, quite a
lot of you ... might be a pattern.)

Quote:
> Maths was fast and safe because such things as divide by zero
> conditions were all caught by a routine check on the floating point
> unit's registers and stack.

And fundamentally incorrect, too.  Every time you add one to a number in
assembler you are obliged to check for overflow and branch to the
arbitrary precision arithmetic package.  This in turn relies on the
correctly written (first time, no doubt) dynamic allocation package
which relies in turn on the safe deallocation of store which relies
on the sound tagging scheme for arithmetic ... oops, we just
invented Lisp.

Arithmetic on today's processors is just plain wrong.  It was always
wrong.  Read the RISKS digest for overwhelming support of this view.
It must count as one of the most powerful reasons for serious s/w
designers to move to high-level languages.  And I don't count model-T
type languages such as FORTRAN or C++ as high-level for this very
reason.

Let's face it, if you can't add one to an integer with a reasonable
hope of safety, what makes you imagine you can write a complex
program at all?

Quote:
> My colleague Alistair has said that I could have developed my image
> analysis and multivariate analysis system faster and more efficiently
> if I had used Z80 machine code rather than poplog.

This sounds like a straightforward comparison between a system you are
very familiar with and one which you are learning.  To illustrate
this with a more obvious example -- I have no doubt that
a FORTRAN programmer would be best off doing almost any one-off job
in FORTRAN rather than POPLOG because of the extensive learning curve
associated with POPLOG.  Learning a new system like POPLOG is a
significant investment, unfortunately.

The beauty of POPLOG is that it doesn't force you to write the core
analysis routines in Pop.  If you want to write them in C or even
assembler -- go ahead!  That's the way POPLOG was built to be used.
All you do is link them into POPLOG and get the best of both worlds.

Steve



Mon, 25 Dec 1995 09:38:46 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Bugs, Death and everything

2. red screen of death (pluggableTextMorph bug?)

3. BUGS, BUGS, BUGS, BUGS, C4 BUGS

4. Imminnent Death of the 'Imminent Death of the Net' Postings

5. Windows XP: DOS death-knell?

6. Rumours of death...

7. "Death of Proof": reports exagerated

8. the big death is coming?

9. Death of a timer

10. Bloated GUI's will be the death of Java

11. Death of Process

12. !! Urgent Reports Question (A.S.A.P) Near Death !!

 

 
Powered by phpBB® Forum Software