On 10/07/07, Aaron Denney <[EMAIL PROTECTED]> wrote:
On 2007-07-10, Sebastian Sylvan <[EMAIL PROTECTED]> wrote:
> On 10/07/07, Andrew Coppin <[EMAIL PROTECTED]> 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
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
