It isn't exclusively. But it is generally considered one within the functional paradigms - paradigms which are increasingly incorporated outside the traditional functional languages.
Absurd reasoning. Use assembler or machine code then. It will make you think even more.
The point of using a tool that takes care of mundane problems is that you take your biologically constrained mental capacity and apply it more effectively to other aspects of the problem.
The lower-level tool you use, the more limited you are from solving problems that need higher abstractions. You will just be caught up in the plumbing details.
I would expect every professional C programmer to know these things and they follow these cautions most of the time, expect when they don't. The issue is not not knowing. It is about human lapses. Following rules are what computers are good for and humans aren't.
> Function calls that returned pointers to the next function (state-machine type stuff) just blew my mind first time I saw it used. Blindingly fast, but damned difficult to debug.
The article is partly about avoiding such cleverness.
From the article: "You can do almost anything with C, but that doesn't mean you should. "
C is a "dangerous language" (in the words of the kernel developer) as is. The last thing one should be doing is to make it worse with black magic like this. If you want to get clever with passing around functions, use Lisp/ML.
> IME nothing creates a security hole faster than the programmer thinking that just choosing Virtuous tools will somehow protect them from making mistakes.
To me, that would be like arguing that we should not have guard rails because they will make people complacent or that seat belts might make people drive recklessly or that if we make smoking expensive or inconvenient, people will still get cancers by other means.
Of course, there will always be the case of automation complacency and there will be other ways to make errors. But generally, safety features do increase safety. They may not solve everything, but the net effects are quite clear.
> give some people more credit than you're giving them
Hey, I am not the one insulting people - OP thinks only C programmers are adults and the rest are children. I am saying that people are not that different. We all make mistakes.
> Jaded and cynical more than a little?
From psychology studies. I place low trust on human actors in any system. This is an empirically supported position.
> By your logic we shouldn't be able to have anything as complex and large as Windows or Linux
Not at all. C is intentionally unsafe by design, delegating that responsibility to humans. For specific projects, this is a rational choice (kernels, drivers etc). For many others, it isn't. Look, I don't want my Office Suite to be written in C# either.
C programmers do catch obvious bugs immediately and things seemingly run fine. They catch some more using code analyzers and reviews. But it is a matter of record that most programmers don't have extensive training in writing secure code, including C programmers who may think they write good secure code. At one point, Microsoft had company-wide drives to teach security to its programmers and made certain books required reading.
Popular public projects like Linux get a lot of audits and MS can afford such for its own. But much of C code in the wild does not have this. And whenever they are conducted, it is usual to find bugs that simply don't happen in other languages.
I am saying that C should be regarded as a special tool, not as the default tool. There wasn't much choice 20 years ago, but the alternatives are increasingly attractive. The performance penalties for increased safety are quite minuscule now.
What do you mean - "believe"? That is not an opinion. That is a well-known fact. Unless you write exhaustive (and I do mean mathematically) test cases, you can have danglers and buffer overflows that can go undetected for years. Audits show this over and over.
C gets its performance by simply not doing much in machine checks. It expects the human to take over that responsibility. This is by design. The consequences follow naturally.
> you just clearly indicated that you are not worth talking to.
Rust is machine correctness. The forums are more about political correctness.
> c is the common sense way.
Nothing common sense about it. People just think whatever makes sense to them is universal common sense. C is the least "correct" (in terms of software engineering safety/proving etc) high level language.
> I can avoid "unsafe" things in C simply by imposing similar limits to limits Rust imposes on what I am allowed to do.
Sure, except you can't do that reliably (you may think you do, that is not of consequence). Moving those rules from paper to software makes them enforced reliably.
> Calling people lazy and stupid and suggesting that only if they do what you want them to do they won't be lazy and stupid is not a winning strategy for getting anyone to care.
Read the post I was responding to. The OP was calling anyone who does not choose C to be "lazy, or just aren't educated enough". I simply turned it around.
> I call bullshit, and I'll put my decades of industry experience on that.
I don't care for your claims of experience. I have been programming for decades as well.
> Programmers need to fucking pay attention to what they're doing.
Of course they do. "Attention" however has very weak reliability. This is a very well established fact by psychology studies.
> There are no languages in the world that prevent the programmer from making serious structural mistakes.
There are however programming languages that make mistakes much less likely - including structural mistakes. Don't you think Haskell does not provide more tools to express structure and prove safety than an assembler? I am going for extreme contrasts to illustrate the point.
I find it amusing that programmers, of all people, the very people who are supposed to understand how tools make a difference, argue that they don't. The people who are supposed to ever build better and better tools, insist that whatever tools they made a learning investment in, argue that they don't need to be improved any further.
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
> Now go back to play with VB or JavaScript.
Unfortunately people who happen to do unsafe code have this "eliteness" delusion. You are not smarter than anyone else. Write a large enough codebase and you will miss that buffer overflow somewhere, even though you know exactly what it is and have been on the lookout. Time and again, audits of well known software, written by very experienced programmers, show this.
People are not machines and make mistakes. The only solution is to design tools and paradigms where entire classes of mistakes are not likely to occur in the first place. The checks need not be runtime checks with performance penalties, but if you want safety and security in the end product, the machine checks must be quite robust. Don't ever rely on humans for that, pretending you have "competent" programmers. Prove, don't assert.
If programmers can't design languages that have safety features (with low costs) that everyone knows they need, how can anyone trust them to solve other domain problems?
They are all "professional" tools by definition. Don't use unsafe tools unless absolutely necessary is the lesson.
> In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
Completely wrong. Even people who "know what they are doing" (most think they do, but really don't. C enables entire classes of problems that simply don't exist elsewhere), still make avoidable errors with C because they are only human. This is not really an opinion. We know matter-of-factly that there are "no true Scottsmen".
Personally, I like Nim. C is great, when machine generated. I get most of the benefits of C, with almost none of the risks. Unlike Rust, Nim does have some costs for the safety and productivity it enables, but these are quite marginal.
Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.
> 'Sanitizing' it, 'child proofing' it would take away that power and make it useless.
No, it does not. Programming languages like Rust allow you to do all the unsafe stuff you want. It is just that they are safe by default, but you can step out anytime you need to.
> I think it more likely that programmers have become lazy, or just aren't educated enough to be responsible with a powerful programming language
Programmers don't use a safe programming language like Rust because they are indeed "lazy, or just aren't educated enough" - your words. Learn Rust. Then, by all means, reject it if it does not suit the project. Most reject Rust, only because they don't understand it yet.
No one refuses to use Rust because of NIHS because they would not have invented C either.
The real reason is entrenchment. People are just used to old ways. Rust's borrow checker has a learning curve. C programmers are used to old imperative style programming, not things like pattern matching.
> Yes I have a 4 year degree, and it had lots of math.
Good for you. And yet you don't understand the value of an array programming language?
> And as opposed to your snide, and rude remarks
Oh, that stings?
> > If you can't write it in C, you shouldn't be writing code, anywhere! Be a plumber! Be an electrician, be an HVAC person, be any of the high paying jobs that this country is crying out for!
Does the above sound intelligent to you? I just replied in kind.
> leave writing code, to those of us who started with assembler, learned C after that and can write any kind of code you want or need, and yes that includes everything.
Your assembler and C experience won't help you learn Haskell faster. This is like Sheldon on Big Bang Theory arguing that he has a better opinion on Biology or Medicine since he knows Physics, since that is eventually underneath it all. Doesn't work that way.
In CS research departments, they have a few low-level coders around. These are implementers, not researchers.
We can all do Google searches. How many mathematicians do you know today who do modern math in C? All your results are for rudimentary C 101 tutorials for programming newbies explaining what a for loop is. These are basic arithmetic level tutorials. That is not where math research is today.
GSL gives you some very useful algorithms, but it won't help you write clean math code. You want to write code as close to the symbolic stuff, not clutter it with imperative loops, memory allocations, deallocations and casts.
Compare some Julia code vs. gsl_vector code side by side.
Statisticians choose R over C for very good reasons. Web devs use PHP/Ruby over C for very good reasons. CS researchers and Engineers choose Matlab over C for very good reasons. Kernel/Programming language/Core library designers choose C/C++ for very good reasons. There is no silver bullet.
Just about everything is an improvement over C in terms of productivity and safety. All too often, people mistake sunk cost bias for rational choice. Low-level programming choice is often mistaken for intelligence.
> Cant we all grow up and just go back to using C?
That is not growing up. That is being plain stupid.
Julia is faster Matlab. Just about everyone who uses MATLAB knows C. These are properly-educated computer scientists. MIT isn't a place for VB6 coders.
Julia is meant for people who think in Math, not instruction sets. If you never had college level math education, you will be unable to see its utility.
The problem isn't that people don't understand C. It is that YOU don't understand WHY no one who uses Matlab is eager to write in C, even when it is bloody slow. It is too distracting from the problem at hand. You think they are complicating things for the sake of a PhD. No genius. They are desperately trying to get done. They work all day with high-dimensional matrices. C is a pain in the neck to code that.
Do you have a 4 year college degree? Did that have any significant math in it? Do you read CS research papers? If not, you are perhaps just an overpaid code monkey who solves fairly repetitive and dumb problems. You won't get this.
Given that most of the posters here did not even understand what Julia is, even after googling it, I'd say that an average Slashdot coder today is not much different from that HR Rajeesh.
Slashdot Mirror
It isn't exclusively.
But it is generally considered one within the functional paradigms - paradigms which are increasingly incorporated outside the traditional functional languages.
Absurd reasoning. Use assembler or machine code then. It will make you think even more.
The point of using a tool that takes care of mundane problems is that you take your biologically constrained mental capacity and apply it more effectively to other aspects of the problem.
The lower-level tool you use, the more limited you are from solving problems that need higher abstractions. You will just be caught up in the plumbing details.
I would expect every professional C programmer to know these things and they follow these cautions most of the time, expect when they don't.
The issue is not not knowing. It is about human lapses. Following rules are what computers are good for and humans aren't.
RTFA: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
If you think you are immune to C dangers, you aren't an experienced programmer at all.
> Function calls that returned pointers to the next function (state-machine type stuff) just blew my mind first time I saw it used. Blindingly fast, but damned difficult to debug.
The article is partly about avoiding such cleverness.
From the article: "You can do almost anything with C, but that doesn't mean you should. "
C is a "dangerous language" (in the words of the kernel developer) as is. The last thing one should be doing is to make it worse with black magic like this. If you want to get clever with passing around functions, use Lisp/ML.
> Or maybe tomorrowâ(TM)s will introduce a new security vulnerability in your code.
Well, of course. JVM is after all written in C/C++ :-).
> IME nothing creates a security hole faster than the programmer thinking that just choosing Virtuous tools will somehow protect them from making mistakes.
To me, that would be like arguing that we should not have guard rails because they will make people complacent or that seat belts might make people drive recklessly or that if we make smoking expensive or inconvenient, people will still get cancers by other means.
Of course, there will always be the case of automation complacency and there will be other ways to make errors. But generally, safety features do increase safety. They may not solve everything, but the net effects are quite clear.
Who is talking about melting computers?
I am talking about bugs and security holes.
> give some people more credit than you're giving them
Hey, I am not the one insulting people - OP thinks only C programmers are adults and the rest are children. I am saying that people are not that different. We all make mistakes.
> Jaded and cynical more than a little?
From psychology studies. I place low trust on human actors in any system. This is an empirically supported position.
> By your logic we shouldn't be able to have anything as complex and large as Windows or Linux
Not at all. C is intentionally unsafe by design, delegating that responsibility to humans. For specific projects, this is a rational choice (kernels, drivers etc). For many others, it isn't. Look, I don't want my Office Suite to be written in C# either.
C programmers do catch obvious bugs immediately and things seemingly run fine. They catch some more using code analyzers and reviews. But it is a matter of record that most programmers don't have extensive training in writing secure code, including C programmers who may think they write good secure code. At one point, Microsoft had company-wide drives to teach security to its programmers and made certain books required reading.
Popular public projects like Linux get a lot of audits and MS can afford such for its own. But much of C code in the wild does not have this. And whenever they are conducted, it is usual to find bugs that simply don't happen in other languages.
I am saying that C should be regarded as a special tool, not as the default tool. There wasn't much choice 20 years ago, but the alternatives are increasingly attractive. The performance penalties for increased safety are quite minuscule now.
What do you mean - "believe"? That is not an opinion. That is a well-known fact. Unless you write exhaustive (and I do mean mathematically) test cases, you can have danglers and buffer overflows that can go undetected for years. Audits show this over and over.
C gets its performance by simply not doing much in machine checks. It expects the human to take over that responsibility. This is by design. The consequences follow naturally.
> you just clearly indicated that you are not worth talking to.
Ran out of arguments?
> rust is political correctness
Rust is machine correctness. The forums are more about political correctness.
> c is the common sense way.
Nothing common sense about it. People just think whatever makes sense to them is universal common sense. C is the least "correct" (in terms of software engineering safety/proving etc) high level language.
> I can avoid "unsafe" things in C simply by imposing similar limits to limits Rust imposes on what I am allowed to do.
Sure, except you can't do that reliably (you may think you do, that is not of consequence). Moving those rules from paper to software makes them enforced reliably.
> Calling people lazy and stupid and suggesting that only if they do what you want them to do they won't be lazy and stupid is not a winning strategy for getting anyone to care.
Read the post I was responding to. The OP was calling anyone who does not choose C to be "lazy, or just aren't educated enough". I simply turned it around.
Unfortunately, C and C++ are used heavily beyond the kernels and drivers.
> I call bullshit, and I'll put my decades of industry experience on that.
I don't care for your claims of experience. I have been programming for decades as well.
> Programmers need to fucking pay attention to what they're doing.
Of course they do. "Attention" however has very weak reliability. This is a very well established fact by psychology studies.
> There are no languages in the world that prevent the programmer from making serious structural mistakes.
There are however programming languages that make mistakes much less likely - including structural mistakes. Don't you think Haskell does not provide more tools to express structure and prove safety than an assembler? I am going for extreme contrasts to illustrate the point.
I find it amusing that programmers, of all people, the very people who are supposed to understand how tools make a difference, argue that they don't. The people who are supposed to ever build better and better tools, insist that whatever tools they made a learning investment in, argue that they don't need to be improved any further.
> The advantage of C is that the incompetent coders fail early and obviously.
Actually, it is the opposite. With C, bugs exist silently without generating either compile time errors or obvious runtime errors.
Dude, just search any software engineering journal. Unsafe languages make for more bugs. The design of the tool determines safety and performance as much as training, if not more.
> Now go back to play with VB or JavaScript.
Unfortunately people who happen to do unsafe code have this "eliteness" delusion. You are not smarter than anyone else. Write a large enough codebase and you will miss that buffer overflow somewhere, even though you know exactly what it is and have been on the lookout. Time and again, audits of well known software, written by very experienced programmers, show this.
People are not machines and make mistakes. The only solution is to design tools and paradigms where entire classes of mistakes are not likely to occur in the first place. The checks need not be runtime checks with performance penalties, but if you want safety and security in the end product, the machine checks must be quite robust. Don't ever rely on humans for that, pretending you have "competent" programmers. Prove, don't assert.
If programmers can't design languages that have safety features (with low costs) that everyone knows they need, how can anyone trust them to solve other domain problems?
They are all "professional" tools by definition. Don't use unsafe tools unless absolutely necessary is the lesson.
> In the hands of somebody that knows what they are doing, C is not more dangerous than any other language.
Completely wrong. Even people who "know what they are doing" (most think they do, but really don't. C enables entire classes of problems that simply don't exist elsewhere), still make avoidable errors with C because they are only human. This is not really an opinion. We know matter-of-factly that there are "no true Scottsmen".
Personally, I like Nim. C is great, when machine generated. I get most of the benefits of C, with almost none of the risks. Unlike Rust, Nim does have some costs for the safety and productivity it enables, but these are quite marginal.
Yes, there is a case for C in kernels, drivers etc.
But most of the C in the wild is for things that should never have been written in C in the first place - hence a lot of avoidable security holes.
Yeah, in the 80s, they were having silly holy wars between C and Pascal. Fortran was the better tool for linear algebra code then.
> it's not 'child proofed'
Programming languages, in general, need to be human proofed. We have a ton of empirical data to support this for decades.
> 'Sanitizing' it, 'child proofing' it would take away that power and make it useless.
No, it does not. Programming languages like Rust allow you to do all the unsafe stuff you want. It is just that they are safe by default, but you can step out anytime you need to.
> I think it more likely that programmers have become lazy, or just aren't educated enough to be responsible with a powerful programming language
Programmers don't use a safe programming language like Rust because they are indeed "lazy, or just aren't educated enough" - your words. Learn Rust. Then, by all means, reject it if it does not suit the project. Most reject Rust, only because they don't understand it yet.
No one refuses to use Rust because of NIHS because they would not have invented C either.
The real reason is entrenchment. People are just used to old ways. Rust's borrow checker has a learning curve. C programmers are used to old imperative style programming, not things like pattern matching.
> Yes I have a 4 year degree, and it had lots of math.
Good for you. And yet you don't understand the value of an array programming language?
> And as opposed to your snide, and rude remarks
Oh, that stings?
> > If you can't write it in C, you shouldn't be writing code, anywhere! Be a plumber! Be an electrician, be an HVAC person, be any of the high paying jobs that this country is crying out for!
Does the above sound intelligent to you? I just replied in kind.
> leave writing code, to those of us who started with assembler, learned C after that and can write any kind of code you want or need, and yes that includes everything.
Your assembler and C experience won't help you learn Haskell faster. This is like Sheldon on Big Bang Theory arguing that he has a better opinion on Biology or Medicine since he knows Physics, since that is eventually underneath it all. Doesn't work that way.
In CS research departments, they have a few low-level coders around. These are implementers, not researchers.
> Or just run this simple google search: https://www.google.com/search?... [google.com]
We can all do Google searches. How many mathematicians do you know today who do modern math in C?
All your results are for rudimentary C 101 tutorials for programming newbies explaining what a for loop is. These are basic arithmetic level tutorials.
That is not where math research is today.
> http://www.gnu.org/software/gs...
GSL gives you some very useful algorithms, but it won't help you write clean math code. You want to write code as close to the symbolic stuff, not clutter it with imperative loops, memory allocations, deallocations and casts.
Compare some Julia code vs. gsl_vector code side by side.
Statisticians choose R over C for very good reasons. Web devs use PHP/Ruby over C for very good reasons. CS researchers and Engineers choose Matlab over C for very good reasons. Kernel/Programming language/Core library designers choose C/C++ for very good reasons. There is no silver bullet.
Just about everything is an improvement over C in terms of productivity and safety. All too often, people mistake sunk cost bias for rational choice. Low-level programming choice is often mistaken for intelligence.
The closest C++ has to Julia is Armadillo.
http://arma.sourceforge.net/
Even that is not pitched for research, but to migrate Matlab code, once the algorithm has been developed.
Julia removes the need for this migration.
> Cant we all grow up and just go back to using C?
That is not growing up. That is being plain stupid.
Julia is faster Matlab. Just about everyone who uses MATLAB knows C. These are properly-educated computer scientists. MIT isn't a place for VB6 coders.
Julia is meant for people who think in Math, not instruction sets. If you never had college level math education, you will be unable to see its utility.
The problem isn't that people don't understand C. It is that YOU don't understand WHY no one who uses Matlab is eager to write in C, even when it is bloody slow. It is too distracting from the problem at hand. You think they are complicating things for the sake of a PhD. No genius. They are desperately trying to get done. They work all day with high-dimensional matrices. C is a pain in the neck to code that.
Do you have a 4 year college degree? Did that have any significant math in it? Do you read CS research papers? If not, you are perhaps just an overpaid code monkey who solves fairly repetitive and dumb problems. You won't get this.
Given that most of the posters here did not even understand what Julia is, even after googling it, I'd say that an average Slashdot coder today is not much different from that HR Rajeesh.