Language Bindings for Erlang Again (Opinion)

[Andrew Lentvorski]

Joe Armstrong (AL/EAB) wrote:

> Yup - the problem is that is extremely difficult to see the
> world through other people's eyes.

Oh, yeah.  That's a big problem.

My students surprised me this semester when they said: "CVS is the best 
drop box system we've ever had in a computer science course."

I was appalled.  First by the fact other teachers were using bizarre 
systems for turning in code rather than just using a standard, known, 
supported open source tool.  Second by the fact that the students only 
saw the usefulness in terms of turning in the code to me.

While *I* understand the value of source control, beginners have a very 
different viewpoint.

> A couple of days ago
> I played with Ruby on Rails - I hadn't the faintest idea
> what all these funny file extensions (.rb, .yml, .rhtml) meant
> - I guess I should try to remember this experience when writing Erlang
> tutorials - and tell people what .beam, .erl, .yrl, .htr files are
> unfortunately it's very difficult to remember to do this - since
> *everybody knows this*

Well, I find Rails to be a bit "magical".  I kinda like the way Django 
does stuff, but I'm also more of a fan of Python than Ruby.  No 
particular reason for that bias other than I learned Python first and 
Ruby doesn't seem to offer me enough to be worth learning yet another 
language.

Although, I don't think I've bumped into .yrl or .htr files yet.

The beam file format description from Bjorn was very nice for decoding 
beam files.  Two things I would add are notes on tags (what they mean- 
u--Untagged; i--integer; a--atom, X&Y--Register Banks?, etc.) and how to 
decode integers.  Decoding a big integer (or negative integer) has quite 
a few strange cases.  I figured out how to decode integers up to about 9 
bytes in length, after that, I don't quite see how it all goes together 
(especially for *really* big integers).

> 	When I did start mentioning it the response was amazing (to me
> at least)
> 	- many people had never really thought
> 	about this so they just assumed that somehow you could make
> fault-tolerant systems
> 	with one computer. Then I'd ask "what happens if it crashes?" 
> 
> 	Then I'd point out that "two computers = distributed
> programming, concurrent etc." 
> 
>       So a consequence of "fault-tolerance" IS distribution and
> concurrency (this is less
>       obvious - though after 20 years of working with this is seems to
> me to be
> 	self-evident"

Maybe it's obvious once somebody says it.  Until then, you don't really 
think about it. ;)

In addition, lots of the new folks coming to Erlang aren't that 
interested in the fault tolerance.  They are searching for a better way 
to deal with concurrency.  A lot of it has to do with peer-to-peer 
networking.  Peer-to-peer demands concurrency and generally some level 
of dynamic typing for serialization/deserialization and gets really 
annoying to manage in languages like Java or C.

term_to_binary() *alone* makes Erlang worth using in network protocols.

> 	Now all of these are pretty "self-evident" - once you have seen
> the light -
>       but it *is* very difficult (once you have seen the light) to
> recall what it was
> 	like before you had seen the light - which is why writing books
> atc.
> 	is so difficult.

Yup.  No argument there.

I saw recently someone talking about a BitTorrent client.  Perhaps that 
would make a nice tutorial for modern Erlang techniques.  I know that I 
tend to go mucking about in yaws and ejabberd when I get stuck for ideas.

I think that the Python for the original BitTorrent library is only 
about 6000 lines of code.  Probably a lot of that is dealing with the 
lack of concurrency in Python and how to emulate that with generators.

-a