Arrggh! beware the upgrade...

It depends what for - there are certainly many areas where it used to be common for which it is now a bad choice but sometimes you really do need the efficiency of a power tool with no blade guard or cutoff - at these times you should take extreme care.

I'm coming to rather like python for many purposes, but it does require discipline. It's generally easy to write nice clean, clear, intentional code BUT it is also very easy to tinker with the backstage workings in pretty much arbitrary ways - there's no protection you can change the methods of any class at runtime, just assign to them. This sort of malarky comes in very handy when writing test harnesses, injecting mocks and so forth but it would be a very bad idea in production code and needs to be documented very clearly.

Is that best a big strong guy who wipes his own bottom can do?

I don't understand what this 'best' is all about. Are you fighting some sort of imaginary war?

I think you need help.

Interinsting - what new error do you have in mind?

If you refer to Ada/Spark, then they do not claim they solve cding problems. What they do is they provide tools to write a program with higher probability to be correct, according to spec.

If you have no spec, then of course nothing or everything is correct.

It is not about the fool-proof language. It is about to *make it easy to do it right*

It should be easy to do it right. It should be hard to do it wrong.

These tools/languagees helps extremly much to make it right. Once the code passes the compiler - the hard part - then it usually works as intended. Of ourse not always, but mots of the times. I've never had that feeling with other languaes. Ever. They compile, and bail out on SIGSEGV of SIGABORT or even worse, they rather thrashes that crashes.

of course. But it should be hard to f*ck up.

Where did MS come into the picture?

Ok, It thought DO178-B was that

Yes - but hard. Had you written it in Spark, your journey would have been shorter - If you's be proficient in spark.

Of course. no-one said that these languages are a substitute for testing. But testing WLL be shorter, because most bugs will be caught at compile time.

And the 'many-eyes' mantra is no good either - as Heart Bleed demonstrated. The faulty code was there for years without being detected.

And the intention of the language. To be portable assembler. Now, I wonder why people - 50 years after that - still want to use it. It's like riding a bicycle on the back wheel only. Possible, but there are simpler ways to ride a bike

obviously aliens visit this planet too :)

I’m not sure that’s born out by the history (e.g. [1]). In DMR’s account the original goal was to be an implementation language for Unix. The interest in portability is several years later and (in the same article) the only reference to ‘portable assembler’ references C’s use as an intermediate language in compilers for other languages, hardly a recommendation for general-purpose use (the same description could be applied to LLVM IR just as easily).

Hmm, me surprised and some googling later, I see that. I've heard a lot of times about c was created because they (K&R) wanted to write a portable OS to one of the early PDPs, instead of rewriting it in assembler for that particular CPU. But it seems to be an urban legend. I stand corrected

IIRC they needed a language that was better than assembler to write their new OS in. So being primarily an engineer and a comp sci, they threw it together based on previous languages like ALGOL, B, and BCPL.

And you should remember the distinction between C as syntax, and the standard libraries it had.

Malloc() and free[() are arguably NOT part of the C language, but its standard implementation.

Certainly in my case programming 8 and 16 bit micros, they didn't come with the compilers! Nor did any file I/O.

I think stdlib was all we got. String handling mainly. And possibly floating point but on a 6809? Seriously?

On those platforms it WAS simply a fast way to write assembler. They didn't have a whole lot of registers, and if I/O was memory mapped. I/O calls were simple pointer dereferences.

At that level as far as I was concerned I could wrote e.g. bios code about 4-10 times faster than assembler in a far more readable fashion with almost no performance overheads.

If (weather==wet) take(umbrella);

is, in the assembler of then, a huge series of memory accesses and compare and jump instructions which don't make the idea of what the program is trying to do, any clearer at all.

In fact in general I would write two lines of comments for every line of assembler.

They only time you needed assembler was in handling Intel style I/O and probably some interrupt service routines, or writing things like context switchers where you had to mess around with the stack pointers

Now at that level, we didn't need to be reminded of the fact that we were dealing with hardware, not some compscis wet dream of a Turing machine abstraction. Stomp on some other routines memory and it will bite you in the bum. Stomp on the stack and all bets are off.

So we took extreme care not to.

The problem was really that C was *so* good, that people did start to write hugely complex stuff in it, and using people who wouldn't know a register or a stack pointer if it poked them in the eye or how DMA worked...to write them.

Sure, why not, it was routine on 8-bit micros. The Dragon 32 is an example that used the 6809 specifically.

There were two other factors in the rise of C. You could get a C compiler for just about anything, importantly there were several for CP/M. There weren't many decent languages that were that widely available. Also almost every university CS course used it from very early on (Cambridge being the notable exception because Martin Richards was there) so from around 1980 there were a *lot* of people trained in C.

I thought university CS courses of the era avoided C and preferred more academic, pedagogical languages: Pascal, Prolog, Smalltalk, ML, Lisp.

The benefit of C was that it was closer to assembler and suited the low power CPUs of the time, when programmers needed to think close to the metal in order to achieve acceptable performance.

On the job, C was easy to learn and the 'C Programming Language' was a very good manual.

I was taught both OO and functional programming before I ever met C at work, which may be why I was positive about OO-Design, C++ when it came along.

To this day I still prefer my brackets (C, C++, C#) in Pascal style rather than K&R, which I begrudgingly use with Java.

My postgrad CS course was 1967/68 and we had a small (but ample) exposure to Lisp, and also some flavour of Algol on the department's IBM 7094. There was some clumsiness about using the Algol implementation that is now lost in the mists of time - a character set limitation, perhaps.

Whitesmith's for me.

This was later than that. we had 16 bit micros by then for that sort of stuff. Actually in that job we had some sort of DSP chip to do floating point on. You shoved the command in one memory location and the numbers in two others, and eventually it spat out the answers.

Compscis had their head in the clouds and their noses stuck up their arses. We learnt how to code without any 'courses'

all that

I think I do too.

Did pascal have curlies?

I had a friend with an Apple II and he said he couldnt code in C because it had no curlies...on the kee bored

TimS used the indentation style name, "Whitesmith", which I'd never heard before, so I looked it up. When I look back to then, compared to now, the biggest difference for me is that I can just look stuff up. I had no idea what Whitesmith meant, but a minute later I know. Back then, I would have to spend ages trying to find out, scour multiple books, or live in ignorance.

Apparently, my “Pascal Style” is called Allman.

Pascal didn't have curlies, they had begin/end, but when I started programming C I indented my curlies the same as begin/end in Pascal

Apple is Apple, I've never used any of their stuff.

Ditto. I discovered I use Whitesmith style too. To me it makes a block look like a block.

I did for a while. Worst support community ever 'why not just reinstall' was the usual response to everything.

You're a sick man and you need therapy.

Absolutely.