[j-nsp] MX104 capabilities question

[Phil Mayers]

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