Advice for programmers
 

No doubt many of you have read innumerable
humourous/sensible(?) snippets of advice on this subject.

My favourite one (by far) is this:

"Never annotate. Code which was hard to write should be hard to understand."

David

I wrote no internal comments in the first, very short, assembly language program I coded while being paid to be (supposedly) professional.

I quickly became ashamed of that omission and did not repeat it.

I frequently spend more time on the spec than the program itself...

Assembler costs 10-15x more than the same program in high level language, and changes the nature of the problem that actually gets solved

30 million lines of Windows cannot be correct, cannot be made correct.

[url="http://www.boo.net/~jasonp/progrmrs"]Just so we get the basics out of the way...[/url]

(When I was younger I'd collect other people's collections of internet jokes, and when someone sent me another I'd mail them back the whole batch).

[QUOTE=Christenson;255611]I frequently spend more time on the spec than the program itself...

Assembler costs 10-15x more than the same program in high level language, and changes the nature of the problem that actually gets solved

30 million lines of Windows cannot be correct, cannot be made correct.[/QUOTE]

Agreed. It is even worse, because the "correct" behavior isn't even
well defined. Consider the task of putting specs for Windows into
(say) Backus-Naur form. Yikes!

[QUOTE=R.D. Silverman;255619]Agreed. It is even worse, because the "correct" behavior isn't even
well defined. Consider the task of putting specs for Windows into
(say) Backus-Naur form. Yikes![/QUOTE]

None of which is specific to Windows since it applies equally to all 'commodity' OS's that have achieved widespread use.

Brian Gladman

[QUOTE=Brian Gladman;255841]None of which is specific to Windows since it applies equally to all 'commodity' OS's that have achieved widespread use.

Brian Gladman[/QUOTE]

My apologies - my comment was intended to apply to the whole thread, not just to Bob's comment but I didn't manage to include the comment on which Bob himself had commented.

Brian

Frivolity
 

Glad to see that this thread has "taken off".
Since it's my birthday, I'm going to insert a musical jest
(as many of you know I'm inclined to do)

A few days ago I asked my (female and beloved) doctoress about
her affection for and taste in music. She replied "I can take it or leave it".

I (optimistically) considerd the interpretation might have meant
"if you passionately like some pieces, you are very likely to dislike others".
I asked her to clarify this potential ambiguity, and she explained that
she didn't go into record shops and buy CDs.

I enquired about her father's age and tastes.
She said "75 and a sort of polymath"
I said I was referring to his taste in music.

"Something like the Bluespots" she replied.

I laugh. "I suspect you meant the Inkspots".

That is my idea of a humorous exchage between very good friends!

David

[url=http://www.youtube.com/watch?v=iP6IUqrFHjw&feature=related]Choosing my favourite is impossible[/url]

[QUOTE=jasonp;255612][url="http://www.boo.net/~jasonp/progrmrs"]Just so we get the basics out of the way...[/url]

(When I was younger I'd collect other people's collections of internet jokes, and when someone sent me another I'd mail them back the whole batch).[/QUOTE]

That's a little dated, but I will warn you that I *do* know how to use negative subscripts to modify the operating system (as well as know why it's not good technique) and still occasionally decode machine code listings to ensure that some change to the source code hasn't actually changed the object code anywhere besides where it was supposed to.

And add, correctness is more important than fanciness.

[QUOTE=R.D. Silverman;255619]Agreed. It is even worse, because the "correct" behavior isn't even
well defined. Consider the task of putting specs for Windows into
(say) Backus-Naur form. Yikes![/QUOTE]

Yup, even Linux is getting too large. A much better model for device drivers is needed. So is one for what programs are allowed to do; the Ubuntu folks have a capability list model which seems excellent, but it keeps me from reading up on number theory!

I think correct behavior for an OS can at least begin to be defined, and it can be trivially shown that Windows doesn't meet it.
1) The operator is in control of the system.
a) A misbehaving program can always be killed
b) A request for shutdown is always respected.
c) The only persistent, automatic results of "Viewing" documents involves log entries and possibly a cache of the document.
d) in a world where the programmer of a given program is unknown, the programs should not have the full priveleges of the user invoking them.
e) A secure system console is required.
2) The file system acts in a well-defined manner.
a) The only operations allowed to a program which is automatically run when inserting removable storage media involve translation to and from filesystem calls and the low-level format on the medium. The operating system enforces this.
3) The operating system must not have memory leaks
4) The operating system must not expect to be rebooted, ever.
5) The operating system must not need to write significant amounts of state to disk to shut down.

One more thought, from Fred Brooks "The Mythical Man Month": Windows is an example of the "second system effect". The first system was the DEC VAX running VMS, which was an absolutely beautiful machine.

As I have already said, your comments are wrongly directed at Windows since they apply to _all_ commodity OS's - i.e. those used in computer systems sold into the commercail and retail markets.

The only OS's that have been even _remotely_ close to being verified against formal behavoural specifications are very specialised and not even remotely capable of meeting the needs of ordinary commodity computer users.

Commodity Operating systems are designed to meet the needs of the vast majority of users, almost all of whom have a much stronger interest in functionality than in correct OS behaviour. And, sadly, functionality and dependability are diametrically opposed requirements.

Brian Gladman