>> Erlang is partially functional, in that functions are apparently
>> first-class, and it's got single-assignment and immutable data
>> structures.
>
> Functions in C are first class. That doesn't mean it's functional.

In C it's not especially easy to write a half-line anonymous function 
and pass that as the argument to something. In fact, function pointers 
are probably the number #1 thing about C that I can't figure out how to 
work, but presumably this only affects me...

> The
> immutable data structures come from the single-assignment, except where
> the data structures aren't immutable, of which there are several.

I wasn't aware that there are any mutable data structures. Then again, I 
read an introductory design document, so...

> Well, that's the killer. To me, if every statement can have
> side-effects, then it's not a functional language.

Depends on your definition of "functional". Some people say that 
first-class functions is the definitive thing. Others claim it's 
referential transparency. A few people even claim it's the type system 
or the syntax...

> You have none of the benefits and all of the
> draw-backs of a functional language in Erlang.

Awesome.

>> The document I
>> read claims that it's considered beneficial to limit side-effects to
>> just a few places in the codebase,
>
> Except that message sending and message receiving are both side-effects
> as is spawning or linking another process, so that works pretty poorly.

The guy goes on to point out that by using gen_server, your code has no 
explicit message passing or process linking at all, and this is an 
extremely awesome thing because it means that your own code is free of 
side-effects.

> Plus, as I said, having the side-effects means you cannot (for example)
> use your own functions in guards.

Oh... my god.

> For some reason, the Erlang enthusiasts think the crappy syntax and the
> single-assignment procedures are intentional and beneficial properties
> of the language. Like any niche language, the fanboi's refuse to accept
> that any compromise was made during its design.

I'm not sure a language with multi-billion lines of code in 
mission-critical production applications can be considered "niche".

> Actually, in the documentation, I think there's a note on each built in
> function that says whether you can use it in a guard or not.

Fail.

>> One data point is scientific fact?
>
> It's a scientific fact that you can achieve nine 9's of uptime over the
> course of a decade with programs written in Erlang, yes. Pretty sure
> that's really, really hard to do with any other programming language.

Do we know that it isn't really, really hard to do in Erlang too? I 
mean, one system did it, but how much time, money and effort did they 
throw at the problem?

Now show that using something other than Erlang would have required 
/more/ time, money and effort, and we have something resembling a proven 
fact. ;-) Now repeat this for more than one system...

>> As I say, this doesn't really seem to be spelled out anywhere else
>> that I could find, and it seems a rather crucial detail.
>
> It's kind of in all the books and stuff. I think the PhD thesis is
> presumed required reading, if nothing else.

"The" PhD thesis?

>> (Quite how you tell the difference between an exception and a normal
>> result is left to the imagination...
>
> Well, an exception will start with EXIT, while a regular result is
> unlikely to, unless you specifically confuse things that way.

It just looks like the sort of thing I might do by mistake, spend 20 
minutes wondering why my application is acting screwy, and then have a 
little facepalm moment.

(E.g., one time I was building a Smalltalk application, and I wanted 
certain building blocks of the application to have names that would 
display on the screen. Obviously the name of a FirstOrderFilter doesn't 
change for each instance, so I added a class method called #name... All 
kinds of fun erupted after that. Eventually I discovered that the Class 
metaclass already /has/ a #name method, or something like that. Ouch!)

>> You mean that if message #5 doesn't arrive, message #6 is actually
>> guaranteed not to arrive?
>
> If message #5 didn't arrive because the receiving machine crashed, yes,
> message #6 isn't going to be received either. If message #5 didn't
> arrive because the network switch died, then #6 isn't going to be
> delivered either.

Presumably if the link dies and then comes back, or any other 
combination of circumstances, either the TCP link is still alive (in 
which case it resents #6 *and* #5), or the link has been broken (in 
which case neither message arrives).

> Yes, exactly. More precisely, you can't tell if the message was received
> and processed or not.

OK.

>> These people are /serious/ about reliability. o_O
>
> Well, yes, that's how you get 5 minutes of downtime over the course of
> 10 years.

Some people might refer to that as "luck". ;-) Apparently there are 
Windows 95 systems with this kind of uptime.

> Well, not quite. If the network between the machines dies, each machine
> is going to think the other crashed. This makes a mess.

"Ow, I don't care *what* universe you're from, that had to hurt!"

>> Thing is, I can open the REPL and type in a function, and then ask to
>> spawn that on a remote node. How does *that* work?!
>
> Hmmm. Actually, I think perhaps it *is* willing to ship functions
> around. The details escape me at the moment. Maybe you can send
> functions but not modules? I don't honestly remember.

Or maybe if you do this, it just tells you to sod off. I don't know...

>> I'll bet. No doubt somebody has written libraries for other languages
>> to speak the same wire protocol.
>
> I don't know. Probably, but I'm not sure why you would.

There are libraries that implement BEEP, even though nobody ever uses 
it. I'm *sure* there are libraries for a massively successful thing like 
Erlang. ;-)

>> I'm not actually sure why though.
>
> Reliability. ;-)

In what way is this more reliable?

>> You would think that a fully interconnected mesh would quickly exhaust
>> the supply of TCP ports too.
>
> Unless you have more than 50,000 machines, unlikely.

Hmm, yes. The number of links rises exponentially, not the number of 
links per node.

> One of the OTP functions shows how to authenticate and encrypt the
> connection en Erlang code, IIRC. That's also one of the tutorials.
>
> Actually, I had forgotten. There is a "cookie" you can set, and anyone
> connecting needs the same "cookie". So there is a minimal security
> level, not unlike the similar feature in X servers.

And the "cookie" is presumably sent unencrypted from node to node when 
they try to connect too.

BTW, how do you identify a remote node? Is it just by DNS name or IP 
address or something?

> What, you're believing fanboi's?

Doesn't everything? ;-)

>>> The two-versions limit is because the code itself isn't GCed. They
>>> document that they could have GCed the code, but that would have added
>>> lots of overhead for something relatively rare.
>>
>> Fair enough.
>
> Plus, you should be dealing with the occasional "process suddenly ends
> for no reason" exception robustly anyway. :-)

Layers within layers of crash recovery... :-}

> I found it annoying that there's no global roadmap. So you read about
> something and it says "If X happens, a message is sent to the error
> logger." WTF is the error logger? Where's the documentation. Then you
> track that down, and it's all talking about bits and pieces that are
> also not documented, etc, with the assumption that you have a bunch of
> people who wrote the error logger hanging around to tell you how to find
> where the errors got logged and such.

An error logger where you can't find the log? Oh, that's epic! :-D

Honestly, I thought only Haskell does this kind of stupidity...

(Yesterday, the new version of the Haskell Platform was released. Which 
is just as well, because the home page has been saying that the next 
release is due in "January 2011" for several months now.)

>> Escaped experiment, eh? ;-)
>
> That's exactly what it was. Except that by the time it escaped, there
> were millions of lines of production code written in it, so you couldn't
> even reasonably fix it.

Well, you can do syntax changes with a conversion program. But 
large-scale language changes? No, not really, no.

>> The advice presumably being that workers should only receive "real"
>> messages, and supervisors should only receive exceptions. Then there
>> can be no ambiguity. (Until the supervisor's supervisor asks it to do
>> something...)
>
> Well, more like, normal worker processes shouldn't communicate with
> messages that start with the atom "EXIT". It's not that hard.

It looks like the sort of mistake I would eventually make, and then 
spend a seriously long time trying to debug. Maybe being all upper-case 
is enough to prevent this, I don't know...

> Hermes gives you as many mailboxes as you want, with as many connections
> to each mailbox as you want, and you can send both connections and
> mailboxes in messages to other processes. So if you want hot-swap code,
> write your processes as being capable of packaging up its mailboxes and
> sending them to a new process.

OK.

>> So you're saying that all the "interesting" stuff like the SSL
>> implementation is actually just an off-the-shelf C library?
>
> It's possible.

What, you mean you don't *know*? Isn't this *documented* somewhere? ;-)

>> I never did understand what's so great about Tk. It looks horrid, it's
>> really hard to use, and it's almost impossible to get the layout you
>> want...
>
> Well, no, it's really easy to use, it's easy to get a good-looking
> layout, and it only looks horrid because it looked cutting-edge 10 years
> ago and nobody ever improved the look of it since then. (Altho they've
> worked on that more lately.)
>
> That's exactly why half a dozen non-Tcl languages actually went so far
> as to embed a Tcl interpreter into their code in order to be able to use
> Tk. I'm pretty sure it's not Tk that's at fault here. ;-)

That's like saying "C is a fantastic language, it's really easy to use, 
and that's why 90% of all software ever written uses it. I don't think C 
is at fault here."

>> Damn. If the actual switching is in hardware, that the heck do you
>> need the CPU for at all?
>
> For deciding what to connect. You pick up the phone? The 6800 connects
> your phone to the dial-tone generator. It's not sitting there generating
> the waveform in software. You push a button? The 6800 routes your line
> to the DTMF decoder, which signals the 6800 each time you let go of the
> tone. When you've dialed enough numbers, the 6800 figures out what line
> you're supposed to connect to and plugs you through.

That's seriously the only reason why it has a Turing-complete processing 
unit inside it?

Man, you would have thought QBASIC would be enough for _that_ level of 
functionality...

> I don't know. Go work for Erricson. ;-)

Worst FAQ answer *ever*! :-D

> It means the compiler is a function in the OTP libraries that you invoke
> in order to compile the code.

FWIW, I wish more languages were implemented like this...

(I'm just bitter because I spent yesterday trying to figure out how to 
get GHC to compile and optimise some source code, and then give me the 
AST. Which I managed, BTW, but trying to figure out WTF the AST actually 
means? Ugh!)

> You can look at the documentation for it to see what it does.

At this point, I don't hold out a lot of hope... o_O

> The other problem is that all the documentation assumes you've read the
> previous documentation and knows what they're talking about, but it
> doesn't actually give you pointers to any of the previous documentation.

I hate that. The Oracle documentation is like this too. Even the 
chapters in a single document refer to things out of sequence. Like, in 
chapter 1, it uses technical terms that aren't explained until chapter 
2, and chapter 2 uses things that were explained in chapter 1, but the 
explanation in chapter 1 doesn't make sense until you read chapter 3 
anyway. WHO WROTE THIS CRAP?!

Still, it could be worse. Consider the following quotation from one of 
the Haskell standard libraries:

http://www.haskell.org/ghc/docs/6.6/html/libraries/mtl/Control-Monad-Writer.html

"Inspired by the paper Functional Programming with Overloading and 
Higher-Order Polymorphism, Mark P Jones (http://www.cse.ogi.edu/~mpj/) 
Advanced School of Functional Programming, 1995."

(Notice that the URL no longer exists.)

I emphasise: /standard libraries/. Not even some exotic add-on library. 
One of the base libraries that comes with the compiler. And there's not 
one single line of human-written text on that page, beyond the reference 
to the paper where this stuff is actually explained.

> You'd like mnesia, tho. It's a lot like STM in some ways.

Except the part where there's at least 3 extensive yet readable 
technical introductions to what it does, why you'd want that, and how 
you use it, with full example source code and explanations. ;-)

Post a reply to this message