I dont get it... Why is everyone from science schools so obsessed with Perl and Python when we got C?

[Heater]

I find it amazing.

We have "safe" or at least safer languages for a long, long time. Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features.

And what happened? Developers did not like them. Developers said "Learn your language" C/C++ is fine.

And here we are today in a bug infested world. Like Linus Torvalds I think it is silly to make a distinction between bugs and security issues. They are all bugs. When we class bugs as security issues we end up putting band aids on things that we happen to find that cause security vulnerabilities rather than fixing the problem.

So it's amazing then, that finally even developers are starting to take the idea of safe languages seriously. Finally accepting how fallible they are.

[DavidS]

I find it amazing.

We have "safe" or at least safer languages for a long, long time. Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features.

And what happened? Developers did not like them. Developers said "Learn your language" C/C++ is fine.

And here we are today in a bug infested world. Like Linus Torvalds I think it is silly to make a distinction between bugs and security issues. They are all bugs. When we class bugs as security issues we end up putting band aids on things that we happen to find that cause security vulnerabilities rather than fixing the problem.

So it's amazing then, that finally even developers are starting to take the idea of safe languages seriously. Finally accepting how fallible they are.

I actually agree with you on most of that. A bug is a bug, and should be treated as a bug.

No one would have stopped anyone from implementing a Unix like system in Pascal (or any other language), remember Unix itself was not always in C, it began life in Assembly Language, the choice of HLL is kind of arbitrary (except for the fact that C was designed for Unix with a crossover on the authors of the two projects ).

Though I do think there is a place for languages that do not have bounds checking (can be up to 2 extra instructions on an array access depending on contex). And you can not easily bounds check a pointer dereference (I know Pascal did not have pointers in its early days, though they have been there for a long time now).

[ejolson]

I find it amazing.

We have "safe" or at least safer languages for a long, long time. Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features.

And what happened? Developers did not like them. Developers said "Learn your language" C/C++ is fine.

And here we are today in a bug infested world. Like Linus Torvalds I think it is silly to make a distinction between bugs and security issues. They are all bugs. When we class bugs as security issues we end up putting band aids on things that we happen to find that cause security vulnerabilities rather than fixing the problem.

So it's amazing then, that finally even developers are starting to take the idea of safe languages seriously. Finally accepting how fallible they are.

In the race to the bottom we have following pearls of wisdom:

• Pointers don't cause segmentation faults, people cause segmentation faults.
• When pointers are outlawed, only outlaws will have pointers.
• The only thing that stops a bad programmer with a pointer is a good programmer with a pointer.

The reason, so far, that Linus has reportedly insisted on C is because there are many good programmers who know C well. If the Linux kernel switched to FidoBasic, for example, the pool of knowledgeable programmers would shrink so significantly that all the wonderful benefits of that superior language would be lost.

In order to avoid a digital apocalypse in which there are no C programmers sufficiently skilled to maintain the majestic programs already written, it may be expedient to provide earlier opportunities to gain experience using pointed programming idioms rather than limiting the beginner to dull and pointerless languages. Along similar lines, is it really such a good idea for children to play with plastic toys until graduating from secondary school and then be given an automobile to play with?

On the other hand, I hear automobiles will soon be made entirely of plastic and only deep-learning neural networks will be allowed to drive.

[Musketeer]

I find it amazing.

We have "safe" or at least safer languages for a long, long time. Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features.

And what happened? Developers did not like them. Developers said "Learn your language" C/C++ is fine.

And here we are today in a bug infested world. Like Linus Torvalds I think it is silly to make a distinction between bugs and security issues. They are all bugs. When we class bugs as security issues we end up putting band aids on things that we happen to find that cause security vulnerabilities rather than fixing the problem.

So it's amazing then, that finally even developers are starting to take the idea of safe languages seriously. Finally accepting how fallible they are.

I actually agree with you on most of that. A bug is a bug, and should be treated as a bug.

No one would have stopped anyone from implementing a Unix like system in Pascal (or any other language), remember Unix itself was not always in C, it began life in Assembly Language, the choice of HLL is kind of arbitrary (except for the fact that C was designed for Unix with a crossover on the authors of the two projects ).

Though I do think there is a place for languages that do not have bounds checking (can be up to 2 extra instructions on an array access depending on contex). And you can not easily bounds check a pointer dereference (I know Pascal did not have pointers in its early days, though they have been there for a long time now).

We had already Free Pascal opus magnum for Pi

https://ultibo.org

[DavidS]

I find it amazing.

We have "safe" or at least safer languages for a long, long time. Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features.

And what happened? Developers did not like them. Developers said "Learn your language" C/C++ is fine.

And here we are today in a bug infested world. Like Linus Torvalds I think it is silly to make a distinction between bugs and security issues. They are all bugs. When we class bugs as security issues we end up putting band aids on things that we happen to find that cause security vulnerabilities rather than fixing the problem.

So it's amazing then, that finally even developers are starting to take the idea of safe languages seriously. Finally accepting how fallible they are.

In the race to the bottom we have following pearls of wisdom:

• Pointers don't cause segmentation faults, people cause segmentation faults.
• When pointers are outlawed, only outlaws will have pointers.
• The only thing that stops a bad programmer with a pointer is a good programmer with a pointer.

*(++Agreed)=Me;

The reason, so far, that Linus has reportedly insisted on C is because there are many good programmers who know C well. If the Linux kernel switched to FidoBasic, for example, the pool of knowledgeable programmers would shrink so significantly that all the wonderful benefits of that superior language would be lost.

In order to avoid a digital apocalypse in which there are no C programmers sufficiently skilled to maintain the majestic programs already written, it may be expedient to provide earlier opportunities to gain experience using pointed programming idioms rather than limiting the beginner to dull and pointerless languages. Along similar lines, is it really such a good idea for children to play with plastic toys until graduating from secondary school and then be given an automobile to play with?

I thought that all kids played with pointers in programming languges now days. At least since CS has become an intrical part of primary school in the 1980's.

On the other hand, I hear automobiles will soon be made entirely of plastic and only deep-learning neural networks will be allowed to drive.

You are likely correct on that, unfortunately. when that happens I am never again comming withing 50 miles of a road.

[Musketeer]

Just for the funzies from another keg:

18 % USA people knows how to ride with manual box.

[DavidS]

Just for the funzies from another keg:

18 % USA people knows how to ride with manual box.

I will assume that you are saying drive with a manual transimition?

If so I am surprised the number is so low, as most people I know will only ever drive a automobile with a manual transmition. And driving with a manual transimition was a required part of the test for ones license when I got mine back in 1993, I would think it would still be on the test as a lot of vehicles still in use have manual transmitions.

I live in the USA, always have.

[Heater]

I'm surprised the number is so high.

After a half a year in California I don't recall seeing a car with stick shift anywhere.

[ejolson]

Just for the funzies from another keg:

18 % USA people knows how to ride with manual box.

The other statistic is that 7% know how with automatic.

The question I have is how many can program the Raspberry Pi in C with pointers and whether there is any correlation between the type of automobile transmission and a person's favorite programming language.

[rpdom]

I found pointers a pain to work with in C when I've bothered. Pointers to pointers doubly so (or is that lunchtimes?)

I learnt to drive on auto and manual gearboxes back in 1982. I prefer manual.The only auto I've driven in the last few decades belonged to a stranger who was not in a fit state to drive themself home (medical reasons) and as they lived less than 10 minutes walk from my home, I offered to drive their car home for them. I have since learned that they have quit driving for that reason. I had no problem driving an auto even after a few decades of only driving manuals, but then I do adapt to driving different vehicles quite quickly.

[Michiel O.]

Pascal is arguably a safer language by design and offers range checking and so on. Ada goes all out for safety features. Developers did not like them.

Indeed, but that's not because of the 'safety features'.

• The reasons why Pascal can't be used for serious programming is outlined by Brian Kernighan here.

• Ada, a language designed by a Department of Defense committee, is so frustrating to program in, that developers became totally unhappy with it. That's not a recipe for popularity.

[jahboater]

• The reasons why Pascal can't be used for serious programming is outlined by Brian Kernighan here.

Interesting paper.

Comparing C and Pascal is rather like comparing a Learjet to a Piper Cub - one is meant for getting something done while the other is meant for learning

In general, if you want to "get the job done" use C. If you want to explore fancy programming paradigms or "safer" programming, use another language - but expect that other language to rely on C for its implementation and run time support.

[Heater]

In any kind of non-trivial program one is going to end up with complicated data structures, like linked lists, binary trees, or some custom layout that represents your data. For example in a PCB design program one has a board that contains components that contain pins, that contain pads, ....

To create this kind of structure one needs the language to support references of some kind. ThisThing references ThatThing references ThatOtherThing...

One could do this in C with no pointers, just store the things in various arrays of thingStructs and use the array indices to reference them.

Or one can do it by putting pointers to things inside thingStructs, then mallocing memory for the thingStructs and linking up the pointers.

"Smart" C programmers like to use the later because "performance" or whatever silly reason. Then spend their whole careers hunting down the bugs they have created.

I suspect using simple arrays would be quicker in many cases as it improves spacial and temporal locality and is thus more friendly to the large caches we have today.

Using arrays instead of pointers removes one huge source of bugs. But one should go further...

Arrays in C are not safe either. Step of the end of an array and you are screwed. It would be far better not to use arrays directly either.

No, whether using pointers or arrays one should define ones data structure properly, then write functions that do all the access to that data, read, write, update, delete, etc. Those data access functions can then check for array bounds, wayward pointers etc. Those access routines isolate the "dangerous" C stuff to a small area of code and can be tested very thoroughly.

Of course "smart" C programmers hate to do this kind of thing. Because "performance" or whatever silly reason.

[Heater]

Michiel O.

I know that Brian Kernighan paper from a long time ago. For the most part I agree. It should be noted though that some of his complaints are historical, Pascal now supports separate compilation and so on.

Ada is indeed frustrating. Been there, done that.

That is certainly not a recipe for popularity. On the other hand popularity has proven to be a recipe for the world of endless bugs and security vulnerabilities we now live in.

I don't campaign for Pascal or Ada, quite the opposite in fact. I do suggest that the C and C++ are brain damaged. They allow you to write things that simply don't make any logical sense. They silently compile and run that stuff producing the wrong results, bugs and security holes.

For example:

1) Integer overflow.
2) Out bounds array access.
3) Use of random pointer values.

Etc, etc.

"Smart" programmers will always retort that one just has to learn to program properly and be careful. Fine, but most of the bug ridden, security perforated code we are talking about was actually written by smart programmers.

This is an absurd situation we have gotten ourselves into with our favorite language(s).

[jahboater]

No, whether using pointers or arrays one should define ones data structure properly, then write functions that do all the access to that data, read, write, update, delete, etc. Those data access functions can then check for array bounds, wayward pointers etc. Those access routines isolate the "dangerous" C stuff to a small area of code and can be tested very thoroughly.

Also the data structure may be changed easily without affecting any of the code that uses it.

Of course "smart" C programmers hate to do this kind of thing.

Do they? Seems common sense to me.

[jahboater]

1) Integer overflow.
2) Out bounds array access.
3) Use of random pointer values.

Add run-time checks for all that stuff and it would be as slow as Python ...

[PeterO]

Of course "smart" C programmers hate to do this kind of thing. Because "performance" or whatever silly reason.

Of course "white bearded" C programmers know when to use arrays and when to use pointers. They can also tell when people are pontificating about "smart C programmers" without actually being one themselves. To listen to them you would think that no one has ever succeeded in writing anything other than trivial little programmes in C.

It seems to me that a lot of programmers today use modern language features as a "crutch" to make up for their own lack of attention to details when writing code. I still write code using only the tools that were available to programmers from the early 1960s and it certainly gives you a different perspective to the process and makes you pay close attention to details. With edit/compile/test cycles easily taking 15 minutes you quickly learn to plan out your code rather than "designing at the keyboard" which seems to be popular these days.

PeterO

[Heater]

jahboater,

In general, if you want to "get the job done" use C.

So your suggestion is to just continue creating buggy security hole ridden software as we have been doing for decades now?

What if I define "getting the job done" such that it include some rigorous guarantees of correctness? After all, we don't want the job to be done incorrectly or badly. Given that definition I guess you would then have to say "avoid using C".

If you want to explore fancy programming paradigms or "safer" programming, use another language - but expect that other language to rely on C for its implementation and run time support.

This is currently true. For example Rust is being promoted as the "safe" language of the future. Sure enough Rust uses LLVM for compilation and LLVM is written in C++.

However, I don't see that as an issue. That isolates all the "unsafe" world to LLVM or whatever. Where it is used and tested by thousands everyday. Meanwhile the code your write today in whatever funky new safe language is hopefully far less bug ridden.

And of course. If such a funky new safe language takes off, somebody somewhere will create compilers and tools for it in the new funky safe language. This is already underway with Rust for example.

Maybe, just maybe, it's the dawning of the end of an era. A change from the crude practices of the past to something better. Similar to the time when assembler programmers, the majority at the time, argued vigorously against the new fangled high level languages comming along. We just had to wait for them to die off before making progress.

[Heater]

jahboater,

Also the data structure may be changed easily without affecting any of the code that uses it.

Yes indeed. Exactly.

Even better, the code that supports the data structure can be reused by other programs that can then use the same data for different purposes.

Do they? Seems common sense to me.

Indeed. That is why I put quotation marks around "smart". Actual smart programmers and teams take the trouble to do that.

Add run-time checks for all that stuff and it would be as slow as Python ...

It can be done a lot faster than that.

Firstly, with a suitably designed language syntax/semantics a lot of that can be done with static analysis at compile time.

Secondly the checks that are needed at run time can be pretty quick.

Have a read about the design of Rust for example.

Thirdly, we have just suffered large performance hits on account of mitigations for Spectre and Meltdown. We should be willing to sacrifice a few percent performance for correctness.

[jahboater]

Heater,

What if I define "getting the job done" such that it include some rigorous guarantees of correctness? After all, we don't want the job to be done incorrectly or badly.

Or not get the job done at all. I don't see much (by comparison) very large scale software written in Ada or Pascal or whatever. All the popular OS's are written in C for example.

Look at MISRA or CERT-C, use all the validation software available.
Avoid undefined behavior, all possibilities of which are clearly listed in the ISO standard.

One thing I like about C is the "sensible" validation.
Take

char c;
c = c + 10;
will complain about the narrowing conversion
c = c | 10;
will not - because it can never be a problem.

char *ptr;
*(int*)ptr = 42;

The warning -Wcast-align will complain on platforms where alignment is required (and so will never fail on x86).
-Wcast-align=strict will complain on all platforms regardless, which helps if you subsequently port the code.
/* use memcpy() of course */

[Heater]

PeterO,

Of course "white bearded" C programmers know when to use arrays and when to use pointers. They can also tell when people are pontificating about "smart C programmers" without actually being one themselves.

As you are clearly referring to me there I have to say:

White bearded programmers should know better than to stoop to argumentum ad hominem.

I am saddened to find you resort to unnecessary insult to support your ill thought out argument. If you want to check my C coding skill, or lack of, please take a look at for example:
https://github.com/ZiCog/fftbench/blob/ ... fftbench.c
https://github.com/ZiCog/fibo_4784969/b ... B/fibo.cpp
https://github.com/ZiCog/fibo_4784969/b ... %2B/bint.h

I look forward to your review comments.

To listen to them you would think that no one has ever succeeded in writing anything other than trivial little programmes in C.

Good. If you start to think that you are on the right track at last. Because overwhelming evidence over decades suggests that no one has ever succeeded in writing any thing other than a trivial little program in C correctly.

As evidence I present the Linux kernel:
https://github.com/torvalds/linux

As you know Linux is a gigantically huge and complex code base that has been worked on by thousands of programmers. I'm pretty sure the vast majority of those programmers are actually very smart and skillful in C. They also have a stringent review process in place.

Linux is also riddled with bugs and security issues which get uncovered everyday. There is a lot of discussion and work going on in the kernel community to try and address this.

It seems to me that a lot of programmers today use modern language features as a "crutch" to make up for their own lack of attention to details when writing code.

Perhaps true. On the other hand a lot of skillful programmers of the past and present have used old languages, we are talking C/C++ here, to create all the bugs and security issues we live with today. And they continue to do so. Even if they do pay a lot of attention to details.

With edit/compile/test cycles easily taking 15 minutes you quickly learn to plan out your code rather than "designing at the keyboard" which seems to be popular these days.

I have a lot of sympathy for that view.

[Heater]

jahboater,

Or not get the job done at all. I don't see much (by comparison) very large scale software written in Ada or Pascal or whatever. All the popular OS's are written in C for example.

All very true.

I don't want to get hung up on Pascal or Ada particularly. I don't even like to have to use them. They are from a time gone by.

On the other hand, the fact that we have always done something some way for eons is not an argument that it is the only way or even a good way to do it. And not an argument that we should blindly continue to do it that way.

Look at MISRA or CERT-C, use all the validation software available.
Avoid undefined behavior, all possibilities of which are clearly listed in the ISO standard.

These suggestions are commonly made when this topic is discussed.

I urge you to read this article https://www.zdnet.com/article/microsoft ... sing-rust/ to see why this has not been working for decades now.

One thing I like about C is the "sensible" validation.

Thank God it makes at least some token effort at validation. It's all warnings on, all the way for me.

And a good sprinkling of assertions.

Followed by a good shake down with Valgrind and the sanitizers.

[jahboater]

And a good sprinkling of assertions.

Take a look at static_assert() by the way.
Its been in C since C11 but I have only recently started using it.

Code: Select all

static_assert( __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__,
  "The byte order must be little endian (use -mlittle-endian)" );

Code: Select all

static_assert( sizeof(int) == 4, "int should be 32 bits for this program" );

Note how you can use sizeof().

You can put them anywhere in a function or outside of a function, all done at compile time.

[Michiel O.]

With edit/compile/test cycles easily taking 15 minutes you quickly learn to plan out your code rather than "designing at the keyboard" which seems to be popular these days.

I must respectfully disagree with this. I have worked on big codebases which indeed took over 10 minutes to compile, and I found this made me unhappy because such long compilation times take me outside 'the flow'. It makes me hesistant to compile & test often, and nudges me towards the extra step of solving partial problems in separate projects first, before integrating them into the big project. Especially in the initial phases of tackling a programming problem where I haven't fleshed out yet how my data structures, algorithms and/or API have to look.

If you prefer edit/compile/test cycles of 15 minutes because that supposedly makes your design better because it's not 'designed at the keyboard' (where else? on paper? on a whiteboard? in your head?) it sounds like a mild case of Stockholm Syndrome to me.

[jahboater]

With edit/compile/test cycles easily taking 15 minutes you quickly learn to plan out your code rather than "designing at the keyboard" which seems to be popular these days.

I must respectfully disagree with this. I have worked on big codebases which indeed took over 10 minutes to compile,

When I was learning programming, at first anyway, everything was on punched cards and we had one run per day.
Focuses the mind on getting it right first time.