Language Bindings for Erlang Again (Opinion)
Mon Jun 12 13:24:01 CEST 2006
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
> 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
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
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
> 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.
More information about the erlang-questions