work, life

Partly. c allows people to play with hazardous constructs, which is more fun than grinding out someone's boring application. Of course a good programmer can write reliable c code (subject to OS and libraries out of her control) but the average programmer can't.

Maybe a million lines so far, many embedded apps, several compilers, three RTOSs, tons of engineering and product support/cal programs. Lately I let other people do it for me, since I prefer hardware, especially analog, design.

The only Harvard machine that I've ever programmed was a CPU that I designed myself, from all TTL logic, for a marine data logger. I really liked the PDP-11/68K architecture, where assembly is practically a higher level language. c is really a fancy PDP-11 assembler; the 11 architecture is in plain sight.

I don't want a house with holes in the floor, that let you fall to your death if you aren't paying attention.

Sure. It's a variable that can aim at data, at a structure, at code, at any of the above in a stack, or at nothing, but can be used any time, even if the target is an unknown type, or doesn't exist.

Very flexible.

Don't inhale serpentine either. The white veins are asbestos.

California state rock!

On a sunny day (Tue, 05 Nov 2013 10:42:58 -0800) it happened John Larkin wrote in :

So by your logic no beams, no walls either, as those can break, be put in the wrong place and fall over and crush you... No bricks used, as those can come lose and fall on you, no roof, as i tcan come down or start leaking, no water as it can drawn you,

No cement?

C is a construction language for people how know how to build. No hammers?

well ehh... Nails, nails.

Well, actually is is a variable that holds the address of an other variable.

On a sunny day (Tue, 05 Nov 2013 18:55:37 GMT) it happened Jan Panteltje wrote in :

In Larkin vs C, to make it clearer for the Jury:

Question to J.L:

Do you actually know what a car is? J.L: YES A CAR CAN GET OF THE ROAD, GET DEFECTIVE, LAND IN THE WATER, GO WHERE THERE IS NO ROAD AT ALL, AND EVEN KILL PEOPLE,

Expert witness: A car is a means of transport It is very useful for humanity.

The Judge: :-)

And will be around longer than the 2N3055. ;)

My son gripes about having to use Matlab at school instead of C.

Cheers

Phil Hobbs

(Yes, but much less carcinogenic than chrysotile asbestos.)

Cheers

Phil Hobbs

There is practically nothing else that people do that has the defect rate of software. Common programs have hundreds of bugs, and multi-billion dollar software projects are total failures. I bet a trillion dollars have been lost to bad code and security vulns.

If cars were as bad as software, 20% of the population would die in crashes every year. Or maybe every month.

Some people can and do write brutally reliable software, like for cars and satellites and jet engines. But it's not part of the mainstream culture. Most people write fun tricky code, "test" it to find some of the bugs, and ship it when they have to. We're in the Dark Ages of computing. Languages that enforce discipline, like Pascal and ADA, have lost to c, because they enforce discipline.

On a sunny day (Tue, 05 Nov 2013 11:40:12 -0800) it happened John Larkin wrote in :

Well, most of the big projects are a sell by people who employ people who have no clue and never will, take obummercare for example. It is a money drain, done not for the result, but as social plan. Jobs is good for politicians, a project done in C in a few lines makes no mony. these big projects are usually in one of the languages you advertise below. Especially C++, and that is NOT C, as C++ compilers are sold with the argument that it is good for big projects. Well, Linux is written in C, not C++, and one of the biggest projects in the known universe. And it works (I main given the number of programmers that contribute).

Hey even DOD will gladly excuse you from using ADA if you can get their stuff working. But generals, industry, MIC, jobs, it is all interconnected, if they ... well you can guess.

You do not have that much :-)

well it creates jobs,

Cars run on software these days, 1 person died IIRC in that Toyota thing.

We will perhaps see google's autonomous cars.

Well you can only talk for yourself.

I know my code has bugs, I also know it works.

No, C enforces discipline, as you have to pay attention to what you are doing. Else it goes wrong really fast.

Things Like C++ and Java are grabbing the world, Python now too I think. and Java has turned out to be the biggest security hole, the slowest solution, the most un-readable mess EVER. That is why my Android is now in the dark of the cupboard, with the battery taken out, Crap from any side,.

India just launched to mars for 56 million or something, or 65 or whatever, seemed they can program too, and cheaper, wonder what they coded it in, likely C. :-)

And even roots of negative numbers, and trig functions that "explode", and floating point (in all forms) because folks don't understand how and where it can fail, and recursion because you may not understand how its bounded, and non-decimal radix data representation because people might wonder why 1/5 isn't really 1/5, and global variables because they don't hide information properly and...

Sure seems like it would be far easier and more productive to just educate the unwashed masses than to tie *all* our hands!

BASIC is for folks who like 4 function calculators, think serially, don't have to create "products", or interface with others, etc. The kind of people who make *one* of something and coax it to work.

The same mindset that uses a spreadsheet as a database.

Agreed. I like C because I can "see" what it will ultimately be doing to the hardware (more or less). I much prefer some of the

I really liked Algol (-68) but suspect too much of my programming style has now been influenced by C to make it a "good choice" anymore. But, the quality of mindset that is required to use it (C) *correctly* is much higher than a "toy" language.

The goal of any tool should be how well it lets you meet *your* goals. If your goal is "solve for R27", a calculator may be perfect! If your goal is to control the flight surfaces in real time, probably *not* a good choice!

And how many blown caps, shorted/opened diodes, etc. have there been? Do we outlaw these as well? Or, just the morons who don't know how to design with them?

No, it shouldn't. Good thing you don't write code as you don't seem to understand basic *math* -- let alone the multitude of different ways division by zero can be handled/interpreted in a programming environment. (sigh)

The problem with pointers in the hands of The Ignorant (or Careless) is when they allow you to violate the type system. You're then out beyond the realm where the compiler can protect you (from yourself). If I can point at *any* arbitrary thing (including "nothing") and

E.g., I can load a bunch of bytes off a disk file into memory and

OTOH, just because I *say* its an executable image, doesn't mean it really *is*! Or, that it actually "does something useful".

Ideally, you want folks who are *qualified* to do the jobs they are asked to do. You don't want a neurosurgeon writing code -- anymore than you want a programmer slicing brain tissue!

But, tying the hands of those *qualified* individuals just to prevent unqualified (or less qualified) ones from making mistakes is certainly not the way to go. "I'm sorry, Doctor, but you have to use the dull plastic scalpel from now on because Doctor Bozo would likely hurt himself if we left the *sharp* metal ones in here... Certainly a man of your excellence will find a way to work with these crippled tools...!"

:-)

I had this student who used Matlab to crunch data files and it would take all night to do it. I wrote it in C and it took only a minute or so. Matlab has its uses, but raw number crunching is not one of them.

Longer ago, some time during the eighties, I had to deal with testing FastBus Segment Interconnects, sort of bi-directional gateways between crates of high-energy physics acquisition hardware, now long obsolete. The supported method involved simultaneously running two programs on two computers, attacking the thing from both sides. It took an hour and a half to run the full test. I rewrote that in C on a multi-tasking OS-9 system, and it would run in less than a minute. Had to write a FastBus access library too, because the official one was a hairball with over a hundred different routines, with a poor view of and bad control over what happened in the hardware.

Still earlier, started to use OS-9, which then only had a braindead line-oriented text editor. Wrote my own full-screen text editor, inspired by the then-in-vogue RAND editor in C. It's chock-full of pointers, malloc'ed buffers, etc. I'm still using it every day, now on Linux.

I've written many hardware test programs, data acquisition, servers and clients, number crunching and simulation programs, databases, little utility programs of many sorts, GUI stuff, etc, etc, etc. C could do it all. I loved it. Still do.

Jeroen Belleman

Can you even be sure what you *think* are integers are *actually* implemented *as* integers? E.g., imagine a float type used for *all* numerics -- the syntax just allowing you to be lazy and omit the decimal for "certain" values (.00000). What happens when you count by "1"s and start getting big numbers? Does it wrap like an int would be expected to do? Or, does the +1 fall below the ulp threshold at some point (in which case, your counting *appears* to never end!)

Similarly, what (seemingly) "integer" values don't precisely "equal" themselves? I.e., increment a value N times and wonder why the result isn't exactly x+N. Or, worse, naively design your loop to terminate when count == x + N and find that this never happens -- even when count exceeds x + N.

Sure. Though that doesn't mean they have to be exposed as such. E.g., Limbo allows for lists but has no pointer support at all.

Exactly. Or, to implement the "sanity check" (cast) yourself -- e.g., in C++ -- but to do so incorrectly or incompletely.

Because they don't take steps to protect against doing this in the future. People solder components in backwards. Until/unless someone puts mechanisms in place to prevent/discourage this!

Hmmm.... why? (Sorry, I have no idea of the relative merits of MS OS products. OTOH, I don't expose them to the outside world!)

It's not just Windows. Build any FOSS project from source and note the number of "warnings" you encounter.

Each time I build a new FOSS tool, I am forced to check each warning to reassure myself that it really is *just* a warning and not some insidious bug. Then, sit down and patch the code remove the reason for the warning (is a typecast missing? should x have been unsigned? etc.)

I think much of the problem with software is that most software projects are considerably more complex than most *hardware* projects. So, there's more that *can* go wrong. And, given the "fit in one brain" definition of complexity, far harder for any person to keep track of all the details that *could* bite him. And, far fewer tools that could automate the testing/verification/etc.

Multitasking gives you this illusion at a much lower cost. And, done right, is readily extensible to *multiprocessing* (where the illusion becomes reality -- to varying degrees).

The problem many people have is they think serially -- this, then this, then that. They don't *instinctively* break problems down into parallel activities with a deliberate eye on how to exploit this parallelism -- even if it *is* illusionary (you can often have real performance gains even with the illusion of parallelism!)

I.e., you don't run a business expecting everything to happen serially (at least not an *efficient* business). So, why expect a software process to not also benefit from parallel decomposition?

Gosh. Do I have to give all the money back?

Hey, this just in:

Code, data, stack, constants, variables, buffers, structures, they're all the same thing. Just point and shoot.

It is very rare for us to have a bug in an embedded app or in a Windows tool. I think we once had one product that would crash, if you fed it an illegally long command string.

Our products have MTBFs many times the MIL217 or Bellcore calculations, millions of hours usually. That takes discipline in both engineering and manufacturing. Programming is, most often, a terribly undisciplined practice.

I wrote a math package, in 68K assembly, that we use in several embedded PID controllers. It's all saturating math, in that any operation always results in a valid number. -99/0 is -infinity.

We've sold about 5000 of these controllers so far.

For example, I do a divide by the square of an (unregulated) power supply voltage to set the PWM on a heater element. The power supply voltage should never be zero, but if it was for some reason (bad ADC?) the divide doesn't crash. How would you handle that case? Crash? Check the range of every variable before doing any math operations? Of course I can range check things but usually, knowing how the math package behaves, I don't have to.

The only major problem that we've had was a series of random temperature runaways, with each toasting about $30K worth of scientific instrument. I snuck a blackbox event recorder into the code and worked with some end-users to snoop things. Turns out our OEM customer's system was requesting the high temperatures, due to buggy code, written in c of course. I got to see their source code, and it was hideous.

We do very complex state machines in FPGAs. Sometimes I move an algorithm, with things like filters, floats, divides, whatever, from CPU code into the FPGA to save time. We program FPGAs in VHDL, very low level stuff. Bugs are rare, and even more rarely shipped.

Hardware design is a different culture. We review, reread, simulate, think a lot before we build it and turn it on. Most programmers fiddle until they get a sort-of clean compile (ignore those warnings!) and then fire it up and see if it sort of works. Repeat until it's time to ship.

I expect a PC board to work first time, first etch, to be sellable, with no breadboard prototype. I expect code to be designed to the same standards.

there is a way to compile matlab functions (mcc?) though it probably depends on yet another expensive addon

I kinda like matlab, but typing -1 for ever freaking index in anything dsp gets old real fast

-Lasse