I really flipping "hate" C. It's used for everything in Linux it seems like. Things that really ought to be high level turn out to be a libfoo.so, requiring a C compiler.
It's not a gui programming language. It's not a text-handling programming language. It's not a symbolic programming language.
But it's used as those, constantly.
Pointer-based errors are endemic to C; they ought to be an expected part of the language usage by now. There are reasons why static analysis tools such as Klocwork are out there, and are very expensive... and keep being bought. Because C is bad for an incredibly large range of tasks that it keeps getting used for. I've done some of that, and using C (or C++) made things harder and more error-prone.
It's also very good at other tasks... like writing OS kernels or drivers. I've done some of that, and C made it possible.
Although at this point, I'd be interested to give writing an OS in D a spin to see how it works.
> I really flipping "hate" C. It's used for everything in Linux it seems like. Things that really ought to be high level turn out to be a libfoo.so, requiring a C compiler.
I'm confused by what you mean. What is this "higher level" that functionality should exist at that is above libfoo.so?
It's not a gui programming language. It's not a text-handling programming language. It's not a symbolic programming language.
But it's used as those, constantly.
Pointer-based errors are endemic to C; they ought to be an expected part of the language usage by now. There are reasons why static analysis tools such as Klocwork are out there, and are very expensive... and keep being bought. Because C is bad for an incredibly large range of tasks that it keeps getting used for. I've done some of that, and using C (or C++) made things harder and more error-prone.
It's also very good at other tasks... like writing OS kernels or drivers. I've done some of that, and C made it possible.
Although at this point, I'd be interested to give writing an OS in D a spin to see how it works.