>> But if you wrote some C
>> source code of your own, you have to tell the linker to link in the
>> object
>> code or it complains it can't find it.
>
> Right. Unless you register it. Then the linker looks up the code in the
> registry and links it against the file that the registry says the code
> is in. That's what the registry is for, and why it's called a registry.
>
> You may need to make it a COM DLL first to register it; I don't remember
> the exact details any more.

I was under the impression that the registry is *only* for dynamic 
linking, and has nothing to do with static linking [which is what I'm 
talking about here].

> In every system I've ever used, the "weird magic" is in a linker file
> that always gets loaded. For example, msvcrt.dll (Microsoft visual C run
> time) for Windows, glib for GCC under Linux, etc.

Right. That's probably it...

> Most systems do almost all of this automatically specifically because C
> doesn't have any standard syntax for doing this. I suspect if
> dynamically-loaded code was the norm in C from the beginning, much less
> would be automated by the OS's loader.

On the other hand, the main advantage of C is that almost nothing is 
built-in, which means that everything can be changed... ;-)

>> Personally, I thought "DLL hell" went away about 10 years ago...
>
> Yes, pretty much.

This is from the people who actually had to ask "does Windows actually 
support letting multiple processes open the same disk file at once?"

>> One thing Erlang can do (and Haskell can't, easily) is that because
>> Erlang
>> is a VM, you can have several unrelated Erlang applications running on
>> the
>> same VM.
>
> Yes. Indeed, the whole point of the VM is to be a virtual machine, so
> the idea of an "application" is a user-level construct, not something
> built into the language.

Fair enough.

Question: Does that mean that one process can produce so much garbage 
that it forces endless GC cycles, slowing other unrelated processes 
down? Or does the VM partition memory on a per-process basis or something?

>> Yes, the entire program is statically typed, but this one tiny part where
>> you have to do a simple runtime type check automatically COMPLETELY
>> DESTROYS EVERY SINGLE ADVANTAGE OF STATIC TYPING!
>
> I didn't say that. I said it loses a lot of the benefits, where
> "benefits" are "guarantees" in my mind.
>
> Now, in this particular case, it probably is doing enough work in the
> connected set of processes that converting from dynamic to static typing
> is worthwhile. In the discussions we were having before, I was talking
> about things like web pages, that almost never do any significant
> processing on their own at the server, so statically typing a web page
> where you're translating dynamically typed SQL results into HTML doesn't
> really help to have static typing. I.e., when it's not one tiny part but
> rather a majority of the program, it's worse.
>
>> Basically you need to manually make sure you send a version number at the
>> start of your message exchange, or something like that, and make sure
>> that
>> all servers and clients you write can handle all versions of the
>> protocol.
>
> Or you just check the types and do the right thing with them.

Well yeah, but if you're trying to use a mere textual "name" to decide 
what type something is, you need a version number or something to go 
with the name, to make it unique.

What Erlang is doing is considering any two types to be "identical" if 
they have the same *structure*. That wouldn't do for Haskell; consider, 
for example, how a PortID and a ThreadID are both 32-bit signed 
integers, but are considered utterly different, incompatible types.

[Of course, TRWTF is that it's *signed*...]

>> Or design the protocol so that it never needs to change. (Which is not
>> infeasible if you can send code as part of the protocol I suppose...)
>
> Well, they handle it by letting you upgrade the code.

You can upgrade the code, but unless you upgrade it all at once, both 
versions need to speak the same wire protocol.

>> Not really. When you compile v1, you assume that the other side will
>> be v1
>> as well. When you compile v2, the compiler checks what you changed, and
>> warns you if you don't explicitly handle the v1 data (unless it's
>> identical).
>
> That's fair. It would be interesting to see how that's specified.

I guess we sit back and see if they ever release anything...

>> The Haskell implementation has a potential advantage in that you can
>> specify
>> precisely how to serialise stuff if you want to.
>
> You just do that in code with Erlang. I.e., you write your own
> serializer, or you send a message to a local agent that then sends the
> message to the remote agent that has only what you want.

Yeah, I guess that works too.

Presumably Erlang allows you to serialise cyclic data structures, which 
is notoriously hard for a pure functional language.

>> And yet, that would seem rather heavy compared to just sending a function
>> name (or rather, a *unique* function identifier),
>
> Not all functions have names. For the functions that have names, I
> believe you just send the fully-qualified name of the function.

Only works if foo/3 on node X is the same thing as foo/3 on node Y. ;-)

> If you send a lambda, I believe it sends the bytecode. There may be
> caching involved there too, but I don't remember.
>
> I was too awed by the landmines in the data format to remember the other
> details.

I'll have to check it out sometime...

>> Come to think of it, I'm still figuring out how it manages to send
>> atoms...
>
> It sends them as text, the first time.

Oh, right. So atoms are *globally* unique, not unique to each node?

Post a reply to this message