On 18/08/2012 05:14 AM, Darren New wrote:
> On 8/16/2012 4:13, Invisible wrote:
>> Similar remarks go for most of your points. There are languages like
>> Erlang
>> where support for distributed processing is built-in. Haskell is not
>> such a
>> language.

> But that's not all it takes to make it do what Erlang does. Erlang isn't
> just "distributed processing." It's "reliable processing." Which means
> you need to be able to (for example) start a new version of the code
> running while not actually throwing away the stack of call frames that
> got you there

> How would you write a Haskell library that says "once each call to X
> returns, replace that thread's version of X with new executable code,
> without otherwise disturbing the thread that's running there"?

You wouldn't be able to do this for arbitrary code. But if you insert a 
suitable layer of indirection, it wouldn't be too hard. Haskell supports 
first-class functions, after all. You can do crazy things with stuff 
like continuation-passing and so on.

Post a reply to this message

On 8/18/2012 3:14, Orchid Win7 v1 wrote:
> I very much doubt that C# lets you trivially call arbitrary machine code.

You would be mistaken. It's no harder in C# to call COM or C code than it is 
to do so from C++. Machine code? Well, you have to know the calling 
convention, but sure, you can do that.

> In that case, yeah, it ought to be possible to build something that does
> this. Nobody has, but somebody could.

OK, so Haskell supports dynamic loading of code including declaring new 
types? Funky.

> And, as I wrote in the part you snipped, this is a property of the one
> extant Haskell compiler. It's not necessarily intrinsic to the language
> itself. Somebody could write a compiler that /does/ have good object code
> compatibility. It's just that to date, it hasn't been a priority. There's
> nothing about the /language design/ that makes this impossible.

Sure. But some systems are designed to make this easy, and some aren't. For 
example, it's a lot harder to write a C# compiler that does *not* have good 
object code compatibility.

Of course any language can manage pretty much any function with enough 
effort. Even BASIC can have good object-code compatibility if you work hard 
enough at it. (I think they call it VB.NET, ;-)  The question is how much 
effort does it take, and how much does it look like part of the language 
when you're done.


>>>> How elegantly does it interface to dynamic languages like javascript?
>>>
>>> What do you mean by "interface"?
>>
>> Can you invoke a javascript library as if it were written in Haskell?
>> I.e., is it as easy to invoke something like javascript as it is to
>> invoke something like C?
>
> Don't you need a web browser to run JavaScript code?

Why would you need a web browser?

> Regardless, invoking JS is, in principle, similar to invoking any other
> foreign language. Once you work out how to call it, you'd need to write at
> least some trivial wrappers to get it to work, and after that it's pretty easy.

Except that JS is dynamically-typed. So you can't write a wrapper to a JS 
function. Plus, of *course* you *can* manage it. It's turing complete and 
runs on the same machine. The point is whether it's easy to take a lazy 
functional declarative language and conveniently invoke a stateful 
dynamically-typed collection of functions and objects. I can't even imagine 
how you'd write a wrapper for something like that, in terms of declaring it 
and invoking it. I.e., I don't even know how you'd be able to write a 
Haskell declaration of a javascript object, even assuming such library was 
already written.

> And that's what I'm saying. Most of the stuff you can't do with Haskell
> right now isn't because of poor language design. It's just that nobody has
> built the tools or libraries required to do it. Some day these things
> /could/ become possible, without changing the language.

OK. It wasn't obvious to me that the design of the language was such that 
you could have the things I was talking about.

>> Not superior. Superior at various tasks.
>
>  From what I can see, C# is superior at migrating C++ code and letting it
> integrate with old VB code...

You barely even know how it works, and you've not written any significant 
programs in it, so you're judging from a position of ignorance. :-)

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

On 8/18/2012 3:17, 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.

 > But if you insert a
> suitable layer of indirection, it wouldn't be too hard. Haskell supports
> first-class functions, after all. You can do crazy things with stuff like
> continuation-passing and so on.

Sure, and Erlang translates into machine code instructions at some point. Or 
hell, implement an Erlang interpreter in Haskell. This isn't an argument. :-)

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

On 8/18/2012 3:03, Orchid Win7 v1 wrote:
> On 18/08/2012 05:34 AM, Darren New wrote:
>> On 8/16/2012 3:14, Invisible wrote:
>>> According to Wikipedia, Mono /also/ does JIT compilation to native code.
>>> (Although I agree it would be better if there were published benchmark
>>> results for .NET itself.)
>>
>> You almost have to. But the GC and the JIT for Mono both suck compared
>> to the ones optimized by MS.
>
> You have an actual citation for that?

First google hit on "mono gc sucks"

http://phoronix.com/forums/showthread.php?26300-Mono-2-8-Is-Out-With-C-4-0-Better-Performance/page15

Later versions of Mono are much better than the first few generations, which 
sucked so bad they realized they actually needed to fix it to be even usable 
let alone competitive.

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

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

Yes, it would be cooler if you could do it for /arbitrary/ code, but 
with extant implementations, you'd have to do the next best thing.

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

>> But if you insert a
>> suitable layer of indirection, it wouldn't be too hard. Haskell supports
>> first-class functions, after all. You can do crazy things with stuff like
>> continuation-passing and so on.
>
> Sure, and Erlang translates into machine code instructions at some
> point. Or hell, implement an Erlang interpreter in Haskell. This isn't
> an argument. :-)

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.

Post a reply to this message

On 18/08/2012 06:43 PM, Darren New wrote:
> On 8/18/2012 3:14, Orchid Win7 v1 wrote:
>> I very much doubt that C# lets you trivially call arbitrary machine code.
>
> You would be mistaken. It's no harder in C# to call COM or C code than
> it is to do so from C++. Machine code? Well, you have to know the
> calling convention, but sure, you can do that.

It's no harder to call C than to call Haskell, once you define where the 
hell the function is and what arguments it's expecting. Your point?

>> In that case, yeah, it ought to be possible to build something that does
>> this. Nobody has, but somebody could.
>
> OK, so Haskell supports dynamic loading of code including declaring new
> types? Funky.

It's commonplace to write Haskell code which doesn't know exactly what 
data types it's dealing with. Dynamically loading new types that didn't 
exist at compile-time isn't really a problem, in principle. The only 
real problem is that the current language implementation doesn't support 
this well.

>> There's nothing about the /language design/ that makes this impossible.
>
> Sure. But some systems are designed to make this easy, and some aren't.

Fair enough.

> Of course any language can manage pretty much any function with enough
> effort. Even BASIC can have good object-code compatibility if you work
> hard enough at it. (I think they call it VB.NET, ;-)

VB isn't BASIC. VB is a language with a very slight resemblance to 
BASIC, which has "basic" in its name. Really, it's an utterly separate 
language.

And that's the point - any language can be made to support anything if 
you TOTALLY CHANGE THE LANGUAGE. The question is whether you can do X, Y 
or Z /without/ drastically changing the language.

> The question is how
> much effort does it take, and how much does it look like part of the
> language when you're done.

OK.

>> Don't you need a web browser to run JavaScript code?
>
> Why would you need a web browser?

JavaScript is a language invented for controlling web browsers. I don't 
know of anything else that runs it.

> Except that JS is dynamically-typed.

And Haskell can't manage dynamically-typed code.

Oh, wait. Yes it can.

> The point is whether it's easy to take a
> lazy functional declarative language and conveniently invoke a stateful
> dynamically-typed collection of functions and objects. I can't even
> imagine how you'd write a wrapper for something like that, in terms of
> declaring it and invoking it.

"I can't imagine how this would be possible" isn't the same as "this is 
not possible", as everyone is so fond of reminding me.

>> From what I can see, C# is superior at migrating C++ code and letting it
>> integrate with old VB code...
>
> You barely even know how it works, and you've not written any
> significant programs in it, so you're judging from a position of
> ignorance. :-)

I said that the design is overly complicated and cluttered. That it 
lacked simplicity and elegance. Why would I need an encyclopaedic 
knowledge of the language to say that?

Post a reply to this message

On 8/19/2012 3:26, Orchid Win7 v1 wrote:
> On 18/08/2012 06:43 PM, Darren New wrote:
>> On 8/18/2012 3:14, Orchid Win7 v1 wrote:
>>> I very much doubt that C# lets you trivially call arbitrary machine code.
>>
>> You would be mistaken. It's no harder in C# to call COM or C code than
>> it is to do so from C++. Machine code? Well, you have to know the
>> calling convention, but sure, you can do that.
>
> It's no harder to call C than to call Haskell, once you define where the
> hell the function is and what arguments it's expecting. Your point?

I'm not following. You said C# doesn't let you call machine code. I said it did.

And if Haskell tends to use things like lists extensively, or options, or 
something like that, then yeah, it can be hard to pass such things across 
computation boundaries, let alone lazy expressions. And of course if the C 
isn't actually a function in the functional sense, I'm not sure how Haskell 
handles it. For example, it's really not obvious how easy it would be to 
invoke a C function that takes as one of its arguments a pointer to a function.

Note I'm not bashing Haskell. I'm simply pointing out the assertion that 
Haskell does everything as well as every other language doesn't sound right 
to me.

> It's commonplace to write Haskell code which doesn't know exactly what data
> types it's dealing with. Dynamically loading new types that didn't exist at
> compile-time isn't really a problem, in principle. The only real problem is
> that the current language implementation doesn't support this well.

OK, cool.

> VB isn't BASIC. VB is a language with a very slight resemblance to BASIC,
> which has "basic" in its name. Really, it's an utterly separate language.

Well, it's not Dartmouth basic, no. :-)  But I was mainly kidding there.

>>> Don't you need a web browser to run JavaScript code?
>>
>> Why would you need a web browser?
>
> JavaScript is a language invented for controlling web browsers. I don't know
> of anything else that runs it.

There are lots of other applications that have incorporated javascript. For 
example, MongoDB interprets javascript to decide how to do queries and build 
indexes.

http://en.wikipedia.org/wiki/Comparison_of_server-side_JavaScript_solutions

And have you not heard of node.js?

>> Except that JS is dynamically-typed.
> And Haskell can't manage dynamically-typed code.
> Oh, wait. Yes it can.

OK. Again, I didn't know that. I thought Haskell is statically typed.

>> The point is whether it's easy to take a
>> lazy functional declarative language and conveniently invoke a stateful
>> dynamically-typed collection of functions and objects. I can't even
>> imagine how you'd write a wrapper for something like that, in terms of
>> declaring it and invoking it.
>
> "I can't imagine how this would be possible" isn't the same as "this is not
> possible", as everyone is so fond of reminding me.

I didn't say it's impossible. I said I can't imagine it. :-)

So how do you do it?

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

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

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

>>>> I very much doubt that C# lets you trivially call arbitrary machine
>>>> code.
>>>
>>> You would be mistaken. It's no harder in C# to call COM or C code than
>>> it is to do so from C++. Machine code? Well, you have to know the
>>> calling convention, but sure, you can do that.
>>
>> It's no harder to call C than to call Haskell, once you define where the
>> hell the function is and what arguments it's expecting. Your point?
>
> I'm not following. You said C# doesn't let you call machine code. I said
> it did.

No.

You said C# lets you call arbitrary machine code as easily as calling 
another C# function. I said it doesn't.

> And if Haskell tends to use things like lists extensively, or options,
> or something like that, then yeah, it can be hard to pass such things
> across computation boundaries, let alone lazy expressions.

You cannot pass arbitrary Haskell expressions to C. You can only pass 
primitive data types that C understands. (Things like int or long or 
void*.) If C needs to access Haskell stuff, you write Haskell functions 
that inspect the Haskell stuff and return something that C understands, 
and then have C call that.

> And of course
> if the C isn't actually a function in the functional sense, I'm not sure
> how Haskell handles it.

If the code you're trying to call has no observable side effects (e.g., 
sinh() or something) then you mark it as a pure function. If it /does/ 
have observable side-effects, then you mark it as an I/O action, and 
handle it the same way as any other I/O action. Really, it's not hard.

> For example, it's really not obvious how easy it
> would be to invoke a C function that takes as one of its arguments a
> pointer to a function.

Do you remember that time I used the C sort() function to work a Haskell 
data structure? Do you remember how I don't even know all that much 
about C, and yet it only took me about 20 minutes to figure it out?

Seriously, it's not "trivial". But it's pretty damned simple.

> Note I'm not bashing Haskell. I'm simply pointing out the assertion that
> Haskell does everything as well as every other language doesn't sound
> right to me.

And, as I keep pointing out, that isn't what I said. I said the core 
language design is simple and clean. I didn't say it has a library for 
every possible task. However, the language design itself doesn't rule 
out any particularly large possibilities, as far as I can tell.

>> JavaScript is a language invented for controlling web browsers. I
>> don't know of anything else that runs it.
>
> There are lots of other applications that have incorporated javascript.

Really?

> For example, MongoDB interprets javascript to decide how to do queries
> and build indexes.
>
> And have you not heard of node.js?

I've /heard of/ node.js; I have no idea what it /is/ though.

>>> Except that JS is dynamically-typed.
>> And Haskell can't manage dynamically-typed code.
>> Oh, wait. Yes it can.
>
> OK. Again, I didn't know that. I thought Haskell is statically typed.

Haskell is statically typed. But there's a library for doing stuff with 
dynamic types. Basically, it lets you convert any suitable value to a 
special "Dynamic" type. You can then later try to cast it back to 
something else, which succeeds iff that is actually the correct type. 
You know, the usual deal.

At worst, if you wanted to talk to something dynamic, you could just 
mark every single thing it touches is "type unknown" until you try to do 
something with it. It isn't that hard.

Post a reply to this message