Hacker News Reader

Comment by RubenSandwich | Hacker News Reader

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.

View on HN

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.

If it's not possible to write function-like-macros that actually behave like functions, then function-like-macros need to be not used.

It's a good recommended that you don't use them.

https://www.securecoding.cert.org/confluence/display/c/PRE00...

This is a recommendation I've seen in most coding guidelines I've read.

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.

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.

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.

>"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

You can do it in D.

https://dlang.org/phobos/core_simd.html

Explicit SIMD is nightly-only in Rust right now; it's being actively worked on.

Reply on news.ycombinator.com