Re: [Haskell-cafe] Re: In-place modification

On 10/07/07, Aaron Denney wrote:

On 2007-07-10, Sebastian Sylvan wrote:

...

On 10/07/07, Andrew Coppin wrote:

...

Sebastian Sylvan wrote:

...

That might eliminate the concurrency imperative (for a while!), but it doesn't adress the productivity point. My hypothesis is this: People don't like using unproductive tools, and if they don't have to, they won't.

When "the next mainstream language" comes along to "solve" the concurrency problem (to some extent), it would seem highly likely that there will relatively soon be compilers for it for most embedded devices too, so why would you make your life miserable with C in that case (and cost your company X dollars due to inefficiency in the process)?

...because only C works on bizzare and unusual hardware?

By what magic is this the case? Hardware automatically supports C without the efforts of compiler-writers?

No, of course not. But the most popular architectures support C with /much smaller/ efforts of compiler writers.

Competition sorts that one out. If there's a clear alternative that's let's say 10x more productive, then the cost of developing a compiler (or a backend for an existing one) is offset by the benefits of being able to offer a more productive programming environment for your customers. My point is that C isn't a magical language that is immune to progress, and I would say it's likely that the main future competitor to C in the embedded domain will eventually be [a version of] whatever langauge wins out in the other domains (e.g. due to the many-core stuff). -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862