On 8/19/2012 3:13, Orchid Win7 v1 wrote:
>>> You wouldn't be able to do this for arbitrary code.
>>
>> And that's what I'm talking about. If you want your program to run 15
>> years without ever stopping, you pretty much need to be able to replace
>> arbitrary bits of code, including type signatures, while you're running.
>
> And if this was a problem for your application, you would write it in such a
> way as to facilitate doing this.

Except it's exponentially harder if your language doesn't support it.

For example, there's STM for C#. But it's tremendously harder to make it 
work, because C# supports arbitrary mutations of variable values. You 
*could* make it work, with enough strictures, but it's not worth it.

> (And, again, if somebody wanted this, you could probably come up with a
> Haskell implementation that supports it natively. It's just that nobody has.
> It would take some design work, but I think you could do it without changing
> the language itself.)

See STM on C#.

> Implementing an Erlang interpreter in BBC BASIC would be hellishly
> difficult. Doing it in Haskell wouldn't be all that hard. That's the
> difference.

We're not comparing Haskell to BBC BASIC. The point I'm making is that many 
of the decisions in Erlang were made to support this sort of long-running 
self-healing software. Yes, you could do the same thing in Haskell, but then 
it would look like Erlang. I could do the same thing in C# by writing an 
Erlang interpreter in C# and linking in a bunch of C code for the stuff that 
C# can't do natively (like reboot the machine it's running on). But that's 
not comparing language strengths. That's just asserting they're turing complete.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message