On 8/20/2012 1:25, Invisible wrote:
> 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.

OK, show me a Haskell library that lets me replace any function of the 
language with a new version of that function, keeping the old function for 
any lazy values that might refer to it, until all those lazy values have 
turned strict.

Can you write a Haskell function that wraps every other Haskell function 
declared?  Maybe. I know a few languages like that. But it still doesn't 
make adding that feature easy.

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

Except that makes it useful for the areas in which C# is used, namely 
calling library code. You can't know if the code you're calling does 
something observable. That's the point.

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

Right. More to the point, they tried to make it so you could use arbitrary 
library code for which you don't have the source inside a transaction.

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

Right. But say the bit you want to synchronize is implemented in someone's 
library, and they log a message when something fails.

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

Well, I think "crap syntax" is debatable, but I'm tending to agree with you. 
Weak typing? Most certainly.

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

That's not the main part of Erlang. You're talking about Erlang as if we 
were talking about SQL and one of us is focusing on the fact that it's also 
a functional language. That's not the point.

The fact that Erlang has remote code execution and sends messages is a 
*result* of the Erlang design goals, not a fundamental property. (For 
example, Hermes has the same design goals, and it doesn't support remote 
execution in the language either.)

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

You keep asserting that it's easier in Haskell to do some of these things 
than it is in Erlang or C#. But you've yet to actually provide any evidence 
of this beyond vigorous assertions.

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