[erlang-questions] Erlang and the learning curve
Wed Jan 5 07:47:09 CET 2011
On 5 Jan 2011, at 05:03, Steve Vinoski wrote:
> I thought it provided a richer way of working with binaries. Are
> binaries present in the language only for performance reasons? Klacke
> can tell us for sure, but I don't think so; they're there to provide a
> simple yet extremely powerful abstraction for manipulating bytes and
> bits. When you're dealing with network protocols, like you do in the
> telecoms world for which Erlang was originally created, the need to do
> that easily and in a way that makes for readable and maintainable code
> is critically important. The fact that binaries and bitstrings also
> turn out to be useful in other app domains should come as no surprise.
Just to straighten out the ancient history part, binaries were indeed
introduced into the language for performance reasons - or rather, in
order to provide a more semantically suitable datatype for handling
network packets. This was back in the Good Old Days, when network
protocols tended to be byte-coded rather than bulky text, so the most
common ways to handle the packets were:
- decode them, or extract some component part, based on offsets and
- pass them along as payload
Binaries are much more appropriate for this than linked lists of bytes,
and protocol handling is so commonplace in Erlang that it makes perfect
sense to provide the most suitable datatypes for the task.
Note that originally, we had binaries without the bit syntax. You manipulated
binaries using split_binary/2, binary_to_list/1, list_to_binary/1, and decoded
them (after converting to lists) mainly with bsl, bsr, band and bor, which was
quite horrible, especially when the data was bit-oriented rather than byte-oriented.
The bit syntax was added to make the important task of encoding and decoding
network packets more tractable. It was added for performance, and indeed,
for several years, a hand-coded encode/decode would outperform the bit
syntax. Still, practically everyone started using the bit syntax.
The binary module was largely created because with the bit syntax, binaries
turned out to be more suitable for many text processing tasks than lists
(especially after providing a fast regexp library). Given that text representations
are now ubiquitous also in protocol handling, and in other areas where
Erlang has started becoming popular, it feels pretty natural to have a module
that provides efficient text searching and manipulation operations - the kind
that practically every mainstream language supports.
Ulf Wiger, CTO, Erlang Solutions, Ltd.
More information about the erlang-questions