Invisible wrote:
> In C it's not especially easy to write a half-line anonymous function 

I didn't say it was convenient. I said it was first class.

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

ETS and the process dictionary both spring to mind.

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

I've never heard "functional" actually mean anything except "what you write 
is functions", as in, mapping inputs to outputs. Anything mutable makes it 
non-functional.

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

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.

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

Yes, exactly. Still think it's functional?

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

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.

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

Well, let's rephrase that. It's certainly easier in Erlang than it would be 
in straight C. :-)

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

Look up the history of NIL. Then look up the history of Hermes. Now you have 
three similarly-organized systems that all show you can run long-term 
mixed-developer systems reliably by using these techniques.

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?

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

Armstrong's 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.

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

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

Name clash of methods? Sure. Name clash of values you're returning against 
the three or four already-defined values? No. Treat it as a reserved word.

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

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

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

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

Actually, I'm rather surprised at the number of people who use 
syslog-reliable (which runs over BEEP) let alone BEEP itself. What makes you 
think nobody uses BEEP?

>>> 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.  And if A connects to B, then B passes a 
connection to C to A, A needs a connection to C anyway. You don't want to 
wait till that point for A to find out it is firewalled from C.

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

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

>> Plus, you should be dealing with the occasional "process suddenly ends
>> for no reason" exception robustly anyway. :-)
> 
> Layers within layers of crash recovery... :-}

Incidentally, NIL worked it where you declared which processes were a group, 
and you could kill them off or roll them over as a group. So you didn't have 
the problem of one module being upgraded while another module isn't.

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

I'm sure you can find it if you can figure out which module it talks to. But 
it's like .NET, where debugging output goes to the configured output 
methods, and if you haven't configured them, it disappears. If you're used 
to (say) C's assert() macro, finding out you have to configure where assert 
messages go on a run-by-run basis is rather disconcerting if you didn't even 
think to look.

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

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

It's in the source code. Welcome to open source!

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

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

Well, that's the next version of .NET.  I think it's cool. I wish people who 
weren't using Microsoft could use it as easily.

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

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?

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

http://www.erlang.org/doc/apps/mnesia/users_guide.html

Were you maybe reading the reference manual instead of the user's guide?

-- 
Darren New, San Diego CA, USA (PST)
  "How did he die?"   "He got shot in the hand."
     "That was fatal?"
          "He was holding a live grenade at the time."

Post a reply to this message