cool article, interesting quote

Agreed. Could it be that his consulting biz would dry up if the PHBs thought that C wouldn't give the promised productivity?

At least that comment is relevant to embedded engineering. Here's something I find vaguely interesting, but unsure how it fits in with the rest of the article:

Skimpy budgeting is another factor in failures, as seen most clearly in civil-engineering disasters. In 1940, officials found a way to build the Tacoma Narrows Bridge for half an initial estimate and did so, but the bridge famously collapsed in high winds after just four months in service. Likewise, the MGM Grand Hotel in Las Vegas saved $200,000 by not using sprinklers but paid out more than $200 million in court and rebuilding costs after a disastrous fire, Ganssle said.

Perhaps this is another 'quote out of context.'

I rarely use any salt when cooking. I finally finished off a two ounce bottle I bought over five years ago. Its processed foods that have too much salt as a preservative, or to improve the flavor to a barely acceptable level. The only time I add any salt is during very hot weather, where you lose more salt due to sweating.

As far as Potassium goes, you have to be careful about too much of it in your diet.

In article , steve writes

!!!!!!! Yours is an out of context quote!

If you must use the broken google interface to Usenet you sould at least set up the reply properly. The Google reply button is borken and only works correctly fore the small minority who use Google.

If you read what he said you would understand. He has made it clear in his embedded muse this month.

In article , Ben Bradley writes

It is very much in context. He is talking about software engineering as opposed to programming.

I disagree (in case you hadn't noticed ;)).

As I've said, C is a feature-neutral language. It won't do the software design for you, and won't protect you from doing dangerous things - you have to bring your own knowledge, experience and discipline to the party. Which is (as I understand it) what Jack was saying (in context) - and I agree with him.

To rephrase something I've said before: software *design* exists irrrespective of the language one uses to implement it. One can code well or badly in any language - but the language is not the design.

A soldering iron is dangerous - in the wrong hands.

Steve

Google "hot-swap controller"

E.g., LTC4210

-- Dave Tweed

This reminds me of an incident many years ago when I was a lad. I returned to the study, where I was building some gadget, with a cup of tea to find my young sister (~3-4 yo) holding my soldering iron by the wrong end. Her expression was extremely pained but her injuries were remarkable minor.

And yes, I learned a very important lesson. I must have been 15 or 16.

Peter

In article , Peter Dickerson writes

The lesson being don't have a sister. They are dangerous :-)

What was this gadget with a cup of tea? Sounds fascinating...

If I remember correctly, it's used for space travel.

-Mike

returned

my

Well, I have two of them - sisters that is - a lots of cups of tea and quite a few gadgets. Also had three brothers and they're far more dangerous...

Peter

External sense resistor, external fet, 16 volt limit. Not quite there. I can do an active current limiter with fewer/cheaper general-purpose parts.

John

Certainly. But the way C is taught and usually practiced is a scandal, and the fact that the majority of mid/large programming projects are total failures , and most embedded stuff is shipped with bugs, is the result.

And some languages *are* much worse than others.

But most soldering irons, in the hands of someone with a couple hours practice, quickly produce reliable solder joints almost every attempt. Most C compiles, performed by people with 4-year CS degrees, produce crap that doesn't work.

John

In article , Spehro Pefhany wrote: [... PTC ...]

Yes, that is the reason. The problem is that this is exactly the way you want to use the part. The fact that you have to elsewhere limit the current makes the part practically useless in many applications.

I did it once to a 3AG sized one. It went off like a photoflash with red hot metal splattered about. I hope you won't consider me non-adventurous when I suggest that I not try it on a 10kA part.

In article , Keith wrote: [...]

Try tasting CaCl. It'll make you want to take your tongue out and wash it.

The current limiter could indeed be a mirror in a lot of applications. But to be useful, it would need a very low saturation voltage and, say, a 1000:1 mirror ratio. Know of anything like that?

Burning up an amp to achieve a current limit of an amp isn't very appealing.

John

I can't argue with that. In fact, I'd generally agree. But my view is that it's not C that's to blame - it's the lack of s/w engineering skills out there. As I've said elsewhere, I'm pretty shocked at how poor *most* s/w design/coding is.

However: *my* embedded stuff does not ship with bugs ;). That's mainly from building up an experience-base over many years, and very little to do with the language per se, and very little to do with anything I learned in college.

I tend to think my approach to s/w design has more to do with my experience as a vintage motorcycle restorer in my late teens and twenties, working with guys who wouldn't let me get away with anything substandard. "If a job's worth doing, it's worth doing properly" etc. The thing that I sometimes have trouble convincing others about is that doing the job properly takes less time overall. So I convince them by delivering working code on time and on budget, and with no bugs.

Ok, I'll agree with that one too. Although I'll qualify that by saying that C takes some unfair stick simply because it is feature-neutral. Some folks argue that e.g. C++ is better in that respect - my experience has been the exact opposite. As the saying goes, C gives you enough rope to hang yourself - C++ gives you enough rope to rig the entire ship *and* hang yourself.

See above re experience. I suspect the best way to learn C is the same as learning hardware design - work with a good team, with frequent peer reviews, who won't let you get away with bad practice. Craftsmanship is maybe not something one can learn in college - and for some (maybe most) people, it's not something one can learn - period. It's an attitude. I have vivid memories of a somewhat sloppy colleague banging his head on his desk in frustration, yelling "my compiler doesn't understand me!".

Steve

helps).

Only when it's necessary, when it improves rather than degrades clarity. And only if you consider a subroutine call or a macro or a symbolic index into a structure to be "abstraction"; even then, the gory details are readable on a nearby page of the listing.

What do you make of this?

Looks to me that

a) the probability of programming failure increases exponentially with program complexity, limited only by the number 1.0.

and

b) there's no limit to how much complexity can be brought to bear on any given problem.

John