Spirit rover OS problems

Because you can use a chain saw to cut things does not mean that it is appropriate to slice bread in the kitchen with it. There is a time and place for each tool.

C was designed, and stated to be designed by its authors, for system work such as construction of operating systems and low level constructs.

to

Go back and count how many references to animal rear output were made. That is a debating technique ? I am not going to get into it with people who abuse me and swear at me.

My agenda is type safe programming, and type safe programming languages. I never made any secret of that. Anyone here is welcome to look at my site materials at

I run both a Pascal web site and a Basic language web site, by the way.

I thought it was more about how to create really dependable systems. Systems are hardware, software and documentation as a complete package. Let us not be half-hearted about any of this. You should pick the tools and personnel that will best suit getting the job done within your time, budget and mission constraints. [%X]

I do not see why you keep plugging"type safe" languages when such may actually get in the way of achieving things for some projects. I personally use very "type unsafe" languages for my High Integrity Systems. It is not a problem for me because I have other means for ensuring that the systems behave as advertised no matter how bad the un-advertised environmental conditions get for the system. Then, when you are trusting your life to automated systems you want to know that thetesting and inspection regime has been consistently followed through from beginning to end of the project. [%X]

Where were you during that era? I recall many a failed system being reported through the media (exhorbitant gas bills etc) during the time I was at Secondary School (pre-1969). Getting the systems wrong these days has a bigger impact for many more people because automation has spread to a whole range of other areas. We need to still improve our sense of craftsmanship in developing our systems no matter how good we think we are now.

... snip ...

To me the purpose of style is to foster clarity, which again varies with the reader.

Well put, and very much my POV. We are good at what I call "complexity management" when dealing with hardware, and pretty crap at it with software. I find this fascinating. (I think I understand some of the reasons for it now.)

Like probably many of the folks here, I do both hardware and software. But my hardware hat stays on when managing complexity. Whether a language is typesafe or not interests me only marginally - with any language it's the clarity of the design, and the comprehensibility of the interplay between the many elements, that interests me. Good coding is of course important, but it's part of the implementation of the design rather than the design itself. (Maybe like good soldering is taken for granted in assembling a PCB, or good practice is assumed when laying it out.)

Steve

Some languages/tools/practices stop you from doing something bad. None of them stop you from doing something badly.

solution.

Maybe we're talking about different things. From your statement above, it sounds like you believe strong typing can remove all errors in computer programs. Is that what you mean?

I'd probably agree with that statement, but I believe that a type system strong enough to specify absolute correctness is undecidable, and thus not likely to be used by the vast majority of programmers.

If you can demonstrate a decidable type system that can completely specify the correctness of the floating point square root function, I'd be grateful to see it.

Kelly

Not necessarily. How about: while (*target++ = *source++); for copying a string. OK, granted, "while" is not "if". Well then, how about: for (index = 0; index < sizeof(bit_map); index++) { if (entry = bit_map[index]) process_set_bits(entry); }

Tanya

The above statement I made has been torn so far out of context as to be unrecognizable. The entire subject I was referring to was torn off.

I went back and looked at the context of the orginal message, it made sense there. Torn from its context, no, it dosen't. You can go back to the original if you wish.

If you stop programmers from doing something bad, how will they ever learn?

You need to study up on your basic psychology. Skinner showed that you learn better not by making mistakes, but by being rewarded for doing it right. If you are prevented from making mistakes, you learn all the better.

How is that applicable to programming? You're going to have someone leaning over the should of the programmer patting him on the head and saying "Good boy!" each time he gets a line correct?

to

Anal? Pig? Ad Hominem is a fallacy.

The closest either of us came to swearing was your pasture metaphor, where you "starred" out the vowel in a certain four-letter word for which I (in my response to the metaphor) substituted the euphemism "cow pats."

Which also seems to be the first (temporally, anyway) reference "to animal rear output" made by either of us.

If you were actually offended by the phrase "excrement of a male bovine," I truly apologize. I chose the phrase specifically to be somewhat more light-hearted and certainly less offensive than the single-word colloquiallism it represents.

Please re-read the post, replacing both (well, one and 1/2) occurrances of the offending phrase with "Nonsense!" In both cases the target of the epithet was the statement and not the person making it.

My agenda is better software, with the tools that are available (and sadly unused) today.

I don't sell lint, I don't work for or personally know anyone who sells lint, and I won't profit (directly or monetarily) from increased use of lint. I beat the lint drum, and have done so for years, because it's cheap and effective, and I hope someone else might benefit from my experience.

People are using C because 1) they like it and trust it, 2) it's readily available, 3) there are few other options. Other reasons, such as an existing base of reusable code, also exist.

People are generally not using lint, even though it it probably the single most effective and cost-efficient measure they could take to produce better code (at least, if they are already doing code reviews). Dismissing lint as a less than 100% solution, or labeling it less than useful because of "unnecessary warning messages" is doing a disservice to the reader.

People are not using type safe languages because 1) with few exceptions, they're just not available, 2) they're not C, 3) many programmers are suspicious of their utility and efficiency. Point 3) is a result of point 1) and the natural conservatism of a group obsessed with counting cycles or bytes, some of whom distrust even C.

Telling people that type safe languages will solve all their software problems is either dishonest or naive. Promoting type safe languages while admitting they will not solve all software problems and deriding lint for the same deficiency is inconsistent at best.

C has problems, as all languages do. Lint mitigates many of these problems. It doesn't solve all of them. (All together now:) There is no silver bullet.

And don't let rules or "nanny tools" targetted to the LCD replace thinking in your software development process.

Anecdote: In the last 10 years I can remember exactly two "wild pointer" bugs in the software projects I was involved in. In neither case was the code linted (not my code). I don't remember lint finding any wild pointer bugs in my code in that period, but I do remember a couple cases about 15 years ago on code for a pre-ANSI pre-prototype compiler where a function expected a pointer and I passed the value instead. Lint caught those for me.

Let me know when IP Pascal targets the AVR (probably the easiest 8-bit target out there), and I'll give it a try. Though I personally prefer Modula-2.

Regards,

-=Dave

I know of no way to justify an assignment within the conditional expression of an if statement. Your example could be re-written

for (index = 0; index < sizeof(bit_map); index++) { entry = bit_map[index]; if (entry) process_set_bits(entry); }

And would likely generate identical code (with a good compiler anyway).

The canonical example for which there is no substitute (at least none that don't break good structured programming rules) is

while ((key = get_key()) != EXIT) process(key);

Regards,

-=Dave

The error you made is only possible because you split the expression in two. Even if you were the only person in 1000 to make that mistake, a 0.1% chance is still more likely than an impossibilty.

And it's a real bitch of a bug as well, because it's very likely not to show up in testing. It's quite possible that an error such as this could perhaps lead to the loss of a multi-billion dollar space vehicle.

Silly of me not to realise your private definition of "expression" was unrelated to the meaning of the term within the language under discussion.

No, it isn't. It's perfectly legal C code. Whether or not it's what the programmer intended is unknown.

Quite. In the same way as the previous statement may well be the programmer's way of saving the value of b for later. I entirely fail to see the difference.

Once again you're wrong - it's a statement.

You don't think precision and clarity in language is important in software engineering?

Max is correct.

"a = 5;" is a statement.

"a = 5" is an expression.

The trouble is, when you show them they have safety nets they get a bit lazy. Take away the safety nets and make the rewards for good results worth their while and they will also improve. You need both carrot and stick in appropriate measures.

First, I was making a joke. Second, Skinner is outdated and doesn't really apply to complex behavior anyway.

As far as the context goes, you'd need the programmer to actually be rewarded for doing the right thing for this to make sense, and also know that the reward is linked to the action. Having to do lots of work over and over doesn't turn that work into a habit or reduce the desire to find shortcuts.

If you are prevented from making mistakes, but are never taught that such mistakes exist, you probably won't learn. The novice programmer who is required by the compiler to do extra work with no justification may just consider it a bunch of hurdles to jump through without a real understanding about why such hurdles exist. There is no direct link in that novices mind between the extra work and the fact his programs work more often.