>> 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...
>
> I can't think of any language nowadays that doesn't have first class
> functions. COBOL and FORTRAN, maybe, but that's about it.

Java? Eiffel?

> Yes. gen_server separates out the functional part from the
> non-functional part. But that doesn't give Erlang itself any benefits.
> No doubt functional programming is easier to debug. You just have to
> manually separate it out from the rest of the non-functional stuff.

Indeed. It lets you write in a functional style, but doesn't force you 
to. I suppose some people will claim that's "pragmatic".

>> Oh... my god.
>
> Yes, exactly. Still think it's functional?

Personally, no...

>> I'm not sure a language with multi-billion lines of code in
>> mission-critical production applications can be considered "niche".
>
> It's niche, as much as formula-1 race cars are niche cars in spite of
> being famous and wildly expensive. ERlang's niche is telecom programs
> that run for decades without crashing.

Sure. But people often reverse the word "niche" as a kind of polite way 
of saying "hopelessly unsuccessful". ;-)

>>> 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?
>
> Well, let's rephrase that. It's certainly easier in Erlang than it would
> be in straight C. :-)

People claim that Unix (or maybe specificaly Linux) is insanely 
reliable, and that's almost all pure C.

> Do you think Ericson had *not* been trying to come up with this system
> before they wrote millions of lines of code in it? Do you think they
> wouldn't have started using a different system if Erlang didn't give
> them the benefits they expected?

I'm sure Ericsson things that Erlang is great. That's not "scientific" 
necessarily though. ;-) I'm not seriously disagreeing with you, just the 
fanboys.

>> "The" PhD thesis?
>
> Armstrong's PhD thesis.

I wonder if that's the document I just read, or a different one...

>> 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.
>
> I didn't use Erlang very much, and it never occurred to me to use an
> atom in all upper case, let alone one that says 'EXIT'.

> This is exactly why so many messages returned start with "ok".

So many, BUT NOT ALL. It seems to vary inconsistently. Sometimes there's 
an atom to tell you whether it was OK or not, and sometimes there's only 
an atom to tell you when it failed.

>> Some people might refer to that as "luck". ;-) Apparently there are
>> Windows 95 systems with this kind of uptime.
>
> No there aren't. All the 16-bit Windows machines had a seconds counter
> that wrapped after 42 days and crashed the computer.

Got a reference for that?

>>>> I'm not actually sure why though.
>>> Reliability. ;-)
>> In what way is this more reliable?
>
> If you lose a connection to a node, you can ask the other nodes if they
> lost a connection too, for one thing.

Oh, I see.

> And if A connects to B, then B
> passes a connection to C to A, A needs a connection to C anyway.

What makes you think that?

>> And the "cookie" is presumably sent unencrypted from node to node when
>> they try to connect too.
>
> No, the cookie doesn't get sent at all.

So how do you compare it then?

>> BTW, how do you identify a remote node? Is it just by DNS name or IP
>> address or something?
>
> http://www.erlang.org/doc/reference_manual/distributed.html#id80719
>
> The documentation *is* online.

Right. So it's DNS name, plus a user-defined atom (presumably so you can 
run several nodes on a single machine).

>> 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...
>
> Why do you make mistakes like that? How often do you write code and use
> reserved works as variable names?

More often than you'd think. For example, I might try to use "if" for 
"input file" and "of" for "output file". Shame both of those are 
reserved words in Haskell. But - fortunately - this causes a 
compile-time error in Haskell. You say "treat special atoms as reserved 
words", but if they really were reserved words, you'd get a compile-time 
error informing you of your mistake, rather than mysterious run-time 
behaviour which possibly only shows up under unusual conditions.

>> What, you mean you don't *know*? Isn't this *documented* somewhere? ;-)
>
> It's in the source code. Welcome to open source!

EPIC FAILURE. >_<

>> 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."
>
> No, because there really wasn't much of an alternative to C for many
> years. People tried many alternatives, and they all sucked so bad they
> never really got out of the lab. So clearly C is doing something right.

That's the actual reason? I've often wondered about this, but it was a 
long time ago when all this stuff presumably happened...

>> That's seriously the only reason why it has a Turing-complete
>> processing unit inside it?
>
> I don't know what else it does. Billing records, managing the
> configuration changes, etc. The point is it's not switching individual
> voice packets, any more than your CPU is getting involved in deciding
> which ethernet packets going past are addressed to the machine the
> ethernet card is plugged into.

Wait - the CPU on my PC *doesn't* process the incomming packets??

> Erlang can hand you the AST for you to run macro preprocessign on at
> compile time. (That's how records work, for example.) You think figuring
> out the AST when you have a *statically* typed language is hard?

Strictly, what I'm looking at isn't the parse tree of the Haskell source 
code. I'm looking at the internal data structures used by the Haskell 
optimiser. And it's not so much that the data is complex, it's that most 
of it is complex, and it's difficult to guess where the hell the 
function for examining it is defined. And the API just plain isn't very 
documented. I get the impression that the inside of the compiler is just 
very complex, and not especially tidy, which is surprising.

> http://www.erlang.org/doc/apps/mnesia/users_guide.html
>
> Were you maybe reading the reference manual instead of the user's guide?

Yeah, possibly.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message