[Haskell-cafe] Re: In-place modification

[Sebastian Sylvan]

On 10/07/07, Aaron Denney <wnoise at ofb.net> wrote:
> On 2007-07-10, Sebastian Sylvan <sebastian.sylvan at gmail.com> wrote:
> > On 10/07/07, Andrew Coppin <andrewcoppin at btinternet.com> 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