On 07/07/16 02:21, Gavin Henry wrote:
That last sentence is quite a sweeping statement about C.
The underlying basis for the statement - C is a hard language to program
well - is not at this point a controversial one, IMHO.
You can make great software in any language. I think this argument is
false.
I think the argument has a lot going for it.
C is a difficult language to use well; even developers with decades of
experience get caught out by the subtleties of things like pointer
aliasing and integer behaviour. There's a huge research effort by smart
people to improve that situation - as an example, things like ubsan in
Clang to detect and warn on use of undefined behaviour. John Regehr's
blog is a good read on the topic of how gnarly C can be, for those
interested.
I think it's totally reasonable to argue that other languages can fit a
problem set better than C, can reduce the cognitive load on the
developer, and can prove more amenable to things like static analysis
and automated testing.
Other languages could include, here, a restricted subset of C with
least-surprise behaviours. But TBH, given the focus on multicore, I
think a language with better support for concurrency would be a more
appropriate choice (Erlang was mentioned; it's a shame that never took
off, it's really ideally suited for the task of network protocol speaker).
Developers are people, and recognising the human limits of the process
is important. Frankly, I would agree with the notion that C is a very
poor choice for almost anything outside hardware-level work (kernel,
driver) these days, simply because CPU is cheap, and human cognition
expensive, and higher level languages trade costs in former for savings
in the latter.
Cheers,
Phil
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
