3 ms·

I'm not sure what a fair or unfair language would be. Is an unfair language one who's compiler output is non-deterministic? If that is the case then C fails tha

I'm not sure what a fair or unfair language would be. Is an unfair language one who's compiler output is non-deterministic? If that is the case then C fails that test with undefined behavior. What I'm really trying to say is that as an industry we need to stop proping up C as if it's some golden god. Was it a good compromise for it's time? Of course but we can and should do better because it's clear that writing 'good' C code might be beyond the realm of man.

jackmott 10y ago
If we want to do that, we need to make it possible to fully harness the abilities of the computer in other languages. Just as a litmus test: In how many languages can you cause the SIMD shuffle instruction to be used, explicitly? How many have compilers that can take advantage of it? JVM / .NET languages don't do this (I know .NET can do SIMD, but it can't do shuffle). Rust can maybe do it? Not sure on the status. Dlang SIMD support seems only partial. Which can do a popcnt explicitly or automatically? There are lots of little holes in other languages just in the space of "Can I even use the instructions the cpu has". Then of course being able to control memory completely is a huge advantage in some domains. Any language that lets you do that will have most of the same danger problems as C or C++ I'm sure you could come up with something that is a little safer with as much power, but it isn't so easy for someone to just stop using C/C++ right now if they need that control.
- RubenSandwich 10y ago
  I would answer that you can use Rust to your first question. But I agree with your general sentiment that currently C/C++ is the only choice for certain domains. But there is nothing theoretically stopping us from creating safer system languages. (See Rust and Swift, much less so Swift. But Apple is working towards that goal with the option to disable reference counting in a future version which will give much more predictable performance.) My argument is that we need to stop pretending that C/C++ is not worth improving. Every time someone criticizes a gotcha of C/C++ HN gets very defensive. We need to kill our gods if we want better ones and I personally think we need better system programming languages because it is far too easy to write bad C/C++ code.
  - jackmott 10y ago
    I agree there are a number of improvements that could be made if we sacrificed backwards compatibility, it is just so hard to get everyone on board.
  - pmelendez 10y ago
    >"My argument is that we need to stop pretending that C/C++ is not worth improving." I don't think that's the sentiment of their communities though. Not sure about C, but in the case of C++ it has been continuously adding significant features in the latest three iterations (C++11,C++14 and C++17), if that is not signal of improvement I don't know what it is
- lossolo 10y ago
  You can do it in D. https://dlang.org/phobos/core_simd.html https://dlang.org/phobos/core_simd.html
- steveklabnik 10y ago
  Explicit SIMD is nightly-only in Rust right now; it's being actively worked on.
juliangoldsmith 10y ago
Play stupid games, win stupid prizes. If you're passing an expression with side-effects (which should, in most cases, be on its own line) into a macro, you need to make sure that macro behaves as you intend. Writing good C code isn't impossible, it just requires more resources than writing poor C code. A lot of places aren't willing to put the resources in to write good, secure code, in any language.
- aidenn0 10y ago
  If it's not possible to write function-like-macros that actually behave like functions, then function-like-macros need to be not used.
  - mvkg 10y ago
    It's a good recommended that you don't use them. https://www.securecoding.cert.org/confluence/display/c/PRE00-C.+Prefer+inline+or+static+functions+to+function-like+macros https://www.securecoding.cert.org/confluence/display/c/PRE00...
  - mfukar 10y ago
    This is a recommendation I've seen in most coding guidelines I've read.

jackmott 10y ago

If we want to do that, we need to make it possible to fully harness the abilities of the computer in other languages. Just as a litmus test: In how many languages can you cause the SIMD shuffle instruction to be used, explicitly? How many have compilers that can take advantage of it? JVM / .NET languages don't do this (I know .NET can do SIMD, but it can't do shuffle). Rust can maybe do it? Not sure on the status. Dlang SIMD support seems only partial. Which can do a popcnt explicitly or automatically? There are lots of little holes in other languages just in the space of "Can I even use the instructions the cpu has". Then of course being able to control memory completely is a huge advantage in some domains. Any language that lets you do that will have most of the same danger problems as C or C++ I'm sure you could come up with something that is a little safer with as much power, but it isn't so easy for someone to just stop using C/C++ right now if they need that control.

RubenSandwich 10y ago
I would answer that you can use Rust to your first question. But I agree with your general sentiment that currently C/C++ is the only choice for certain domains. But there is nothing theoretically stopping us from creating safer system languages. (See Rust and Swift, much less so Swift. But Apple is working towards that goal with the option to disable reference counting in a future version which will give much more predictable performance.) My argument is that we need to stop pretending that C/C++ is not worth improving. Every time someone criticizes a gotcha of C/C++ HN gets very defensive. We need to kill our gods if we want better ones and I personally think we need better system programming languages because it is far too easy to write bad C/C++ code.
- jackmott 10y ago
  I agree there are a number of improvements that could be made if we sacrificed backwards compatibility, it is just so hard to get everyone on board.
- pmelendez 10y ago
  >"My argument is that we need to stop pretending that C/C++ is not worth improving." I don't think that's the sentiment of their communities though. Not sure about C, but in the case of C++ it has been continuously adding significant features in the latest three iterations (C++11,C++14 and C++17), if that is not signal of improvement I don't know what it is
lossolo 10y ago
You can do it in D. https://dlang.org/phobos/core_simd.html https://dlang.org/phobos/core_simd.html
steveklabnik 10y ago
Explicit SIMD is nightly-only in Rust right now; it's being actively worked on.

juliangoldsmith 10y ago

Play stupid games, win stupid prizes. If you're passing an expression with side-effects (which should, in most cases, be on its own line) into a macro, you need to make sure that macro behaves as you intend. Writing good C code isn't impossible, it just requires more resources than writing poor C code. A lot of places aren't willing to put the resources in to write good, secure code, in any language.

aidenn0 10y ago
If it's not possible to write function-like-macros that actually behave like functions, then function-like-macros need to be not used.
- mvkg 10y ago
  It's a good recommended that you don't use them. https://www.securecoding.cert.org/confluence/display/c/PRE00-C.+Prefer+inline+or+static+functions+to+function-like+macros https://www.securecoding.cert.org/confluence/display/c/PRE00...
- mfukar 10y ago
  This is a recommendation I've seen in most coding guidelines I've read.