On 19/08/2012 05:08 PM, Darren New wrote:
> 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.

No, it isn't.

It's exponentially harder IF YOUR LANGUAGE SUCKS. If you have a powerful 
language, then adding new things is quite easy.

> 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.

Well, no, that should be quite easy: You have a rule that inside a 
transaction, you don't try to do anything observable to the outside 
world. If you do, it won't work, and it will be your fault. Problem solved.

The trouble is, they tried to make it so that any arbitrary code can be 
run in a transaction. That's impossible. Which is why it didn't work.

You might say "but almost all C# code would be disqualified!" But 
remember, the purpose of a transaction is /only/ to coordinate threads. 
You don't run the entire application inside STM, just the tiny bits 
related to synchronisation.

> 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.

Would it, now?

Adding features for distributed concurrency and hot code replacement 
would make Haskell have crap syntax and weak typing?

No, I didn't think so. :-P

You're aware of the prior art on this subject, I assume? You know about 
the project where they managed to actually implement typed message 
sending and remote code execution? Transparently? Without altering the 
Haskell language at all, just the compiler?

Sure, it didn't do /everything/ that Erlang does. It was only a 
prototype. But it refutes the whole "it would make Haskell identical to 
Erlang" argument.

> 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.

Being able to implement something is one thing. Being able to implement 
it /easily/ is another. And that's the goal of designing a good 
language: to make stuff easy.

Post a reply to this message