8 ms·

I love this: "Key := Val Updates an existing Key The key must be present in the old map. If Key is not in the old map Erlang will complain loudly. Using two op

I love this: "Key := Val Updates an existing Key The key must be present in the old map. If Key is not in the old map Erlang will complain loudly. Using two operations instead of one has several advantages: A spelling mistake cannot accidentally introduce a new key" Lord knows how many times I accidentally created a new key with a spelling typo, and then later when I wanted to retrieve the data, I was like "What the hell is wrong? I know I put data in that key, so why is nothing coming back? I guess I have discovered a rare bug in the compiler that no one has ever discovered before."

bjourne 13y ago
To counteract such bugs I usually try to use as short names as possible. I mean, there is no point in writing productionDatabase when prodDb works just as well. It has several advantages but one of them is that the latter is much less likely to be misspelled.
- laureny 13y ago
  I'd say the latter is much more likely to be misspelled since you abbreviated it arbitrarily. It's easy to write it prodDB or proddb, or was is productionDb? Using actual English names actually minimizes the risks of mistakes. And of course, using a statically typed language makes all these concerns moot since the compiler won't let you make these mistakes in the first place.
  - RussianCow 13y ago
    Static typing does nothing for hashes/maps. That would only help with attributes on objects.
    - lmm 13y ago
      Right, but the example code would probably, in a staticly typed language, be implemented with an object rather than a map.
    - laureny 13y ago
      It certainly does if your keys are not strings but objects.
  - colanderman 13y ago
    using a statically typed language makes all these concerns moot No, you can make exactly the same bug with a static type system. Structurally typed records are just that – structurally typed. If you add an extra field you never use, the type system doesn't care. You need further static analysis to catch that. (Beside, Erlang ships with a decent static analyzer.)
    - tel 13y ago
      Depends on your brand of static typing.
      - drdaeman 13y ago
        In fact, Erlang's records are something like this. They are tuples under the hood (with a first element being atom name of record "type"), and pre-processor translates matching properties by name to matching tuple elements in proper position. So, you can't made typo in this scenario - the code won't compile. I.e., you declare: -record(foo, {bar = ?default_bar, baz = ?default_baz}). And every time you write #foo{bar = 1} you get {foo, 1, ?default_baz} under the hood. Obviously, records are unusable as general-purpose dictionaries as they have fixed structure. One big inconvenience with records is the fact that you have to type record's name every single time you have to do anything with it. And writing MyFoo#foo.bar is cumbersome, compared to MyFoo.bar in most other languages. Another issue is that records exist only before pre-processing. Even compiler is unaware of member names, let alone the runtime. This makes introspection and live code operations (by connecting a shell to a running instance) quite inconvenient.
        tel 13y ago
        It'll still yell at you for typos, though. You can confuse positional with nominal, but you can't make invalid nominal statements. Which is not at all to say that Erlang's tuple/record trick is anything but a clever trick. It is kind of neat to see how far you can go with just that, though.
        lostcolony 13y ago
  - bjourne 13y ago
    The abbrevation is not arbitrary and instead is very conventional among programmers. An arbitrary abbrevation would have been "ProDaBa" but no one abbrevates like that. The casing is also standardized: ProdDB in Python, prodDB in Java and (i believe) ProdDb in C#. Though that is beside the point because you still have to decide which letters to capitalize whether the name is long or short.
    - wylee 13y ago
      In Python, I would use `prod_db` as a dictionary key and not a name that looks like a class name. That said, I do agree that some very common abbreviations are okay in some contexts.
- draegtun 13y ago
  I prefer to counteract these potential bugs by locking the keys of a hash. For eg. in Perl: use Hash::Util 'lock_keys'; my %hash = (key1 => 'foo', key2 => 'bar', key3 => 'baz'); lock_keys %hash; Now any attempts to lookup or amend a key that doesn't exist produces a runtime error... $hash{key1} = "FOO"; # updates fine $hash{key4} = "XXX"; # throws error
rdtsc 13y ago
I also like how such rather large changes are being introduced in a language that has been in production for many decades. That is pretty remarkable.
- davidw 13y ago
  I think Erlang is sort of unique in this way. Many languages go through a lot of changes when they are not all that popular, and then blow up in popularity and finally have a lot of users who are wary of Big Changes. Ruby, for instance, was around for years and years before it started to get popular because of Rails. Python, too, was a product of the early 90ies, but as late as some Linux conference in... '99 or 2000 or thereabouts, I recall sitting at a BoF table with Guido and just a few other people, and the language not being that big a deal. Erlang is still not really all that popular, but has always had a lot of Important Code in production thanks to Ericsson, which has made it more difficult to change even though there are some things that even the creators acknowledge as not particularly elegant.
  - rdtsc 13y ago
    It is funny Erlang is one of those languages and run-times that is used quite a bit without people knowing about. Its reliability properties put at the core of many services (Facebook chat, Amazon, phone gateways etc). It is both a blessing and a curse. If a service or program doesn't crash and cause a lot of drama and headaches it also doesn't get noticed in a certain way. I forgot who mentioned it (one of Erlang Factory talks probably), but for example if you access the Internet via your smart phone, there is like a 30% change that it goes through Erlang at some point (due to going through Ericsson's servers).
    - davidw 13y ago
      I seem to recollect reading about Facebook Chat getting rewritten in C++. Maybe here somewhere?
      - Fishkins 13y ago
judk 13y ago
That syntax for that purpose was totally stolen from Go. Nice to see the cross pollination going in both directions.
- BarkMore 13y ago
  Go's := (short variable declaration) is closer to Erlang's => (introduce a new key) then it is to Erlang's := (update an existing key).
  - snogglethorpe 13y ago
    ... and in that sense, Erlang is following existing practice better than Go did — := is "traditionally" an assignment operator, not a binding operator.
- deleted 13y ago
  [deleted]
ams6110 13y ago
But now the culprit typo is typing -> when you meant := Maybe less likely, but if you've been writing a lot of code using -> and then in one case need := I can see it happening quite easily.
- Tuna-Fish 13y ago
  The system would complain loudly in an error message with a line number. The problem with accidental key typos is that at their worst they are completely silent, and if the value you intend to replace was another valid value, finding the bug might not be easy.

bjourne 13y ago

To counteract such bugs I usually try to use as short names as possible. I mean, there is no point in writing productionDatabase when prodDb works just as well. It has several advantages but one of them is that the latter is much less likely to be misspelled.

laureny 13y ago
I'd say the latter is much more likely to be misspelled since you abbreviated it arbitrarily. It's easy to write it prodDB or proddb, or was is productionDb? Using actual English names actually minimizes the risks of mistakes. And of course, using a statically typed language makes all these concerns moot since the compiler won't let you make these mistakes in the first place.
- RussianCow 13y ago
  Static typing does nothing for hashes/maps. That would only help with attributes on objects.
  - lmm 13y ago
    Right, but the example code would probably, in a staticly typed language, be implemented with an object rather than a map.
  - laureny 13y ago
    It certainly does if your keys are not strings but objects.
- colanderman 13y ago
  using a statically typed language makes all these concerns moot No, you can make exactly the same bug with a static type system. Structurally typed records are just that – structurally typed. If you add an extra field you never use, the type system doesn't care. You need further static analysis to catch that. (Beside, Erlang ships with a decent static analyzer.)
  - tel 13y ago
    Depends on your brand of static typing.
    - drdaeman 13y ago
      In fact, Erlang's records are something like this. They are tuples under the hood (with a first element being atom name of record "type"), and pre-processor translates matching properties by name to matching tuple elements in proper position. So, you can't made typo in this scenario - the code won't compile. I.e., you declare: -record(foo, {bar = ?default_bar, baz = ?default_baz}). And every time you write #foo{bar = 1} you get {foo, 1, ?default_baz} under the hood. Obviously, records are unusable as general-purpose dictionaries as they have fixed structure. One big inconvenience with records is the fact that you have to type record's name every single time you have to do anything with it. And writing MyFoo#foo.bar is cumbersome, compared to MyFoo.bar in most other languages. Another issue is that records exist only before pre-processing. Even compiler is unaware of member names, let alone the runtime. This makes introspection and live code operations (by connecting a shell to a running instance) quite inconvenient.
      - tel 13y ago
        It'll still yell at you for typos, though. You can confuse positional with nominal, but you can't make invalid nominal statements. Which is not at all to say that Erlang's tuple/record trick is anything but a clever trick. It is kind of neat to see how far you can go with just that, though.
      - lostcolony 13y ago
- bjourne 13y ago
  The abbrevation is not arbitrary and instead is very conventional among programmers. An arbitrary abbrevation would have been "ProDaBa" but no one abbrevates like that. The casing is also standardized: ProdDB in Python, prodDB in Java and (i believe) ProdDb in C#. Though that is beside the point because you still have to decide which letters to capitalize whether the name is long or short.
  - wylee 13y ago
    In Python, I would use `prod_db` as a dictionary key and not a name that looks like a class name. That said, I do agree that some very common abbreviations are okay in some contexts.
draegtun 13y ago
I prefer to counteract these potential bugs by locking the keys of a hash. For eg. in Perl: use Hash::Util 'lock_keys'; my %hash = (key1 => 'foo', key2 => 'bar', key3 => 'baz'); lock_keys %hash; Now any attempts to lookup or amend a key that doesn't exist produces a runtime error... $hash{key1} = "FOO"; # updates fine $hash{key4} = "XXX"; # throws error

rdtsc 13y ago

I also like how such rather large changes are being introduced in a language that has been in production for many decades. That is pretty remarkable.

davidw 13y ago
I think Erlang is sort of unique in this way. Many languages go through a lot of changes when they are not all that popular, and then blow up in popularity and finally have a lot of users who are wary of Big Changes. Ruby, for instance, was around for years and years before it started to get popular because of Rails. Python, too, was a product of the early 90ies, but as late as some Linux conference in... '99 or 2000 or thereabouts, I recall sitting at a BoF table with Guido and just a few other people, and the language not being that big a deal. Erlang is still not really all that popular, but has always had a lot of Important Code in production thanks to Ericsson, which has made it more difficult to change even though there are some things that even the creators acknowledge as not particularly elegant.
- rdtsc 13y ago
  It is funny Erlang is one of those languages and run-times that is used quite a bit without people knowing about. Its reliability properties put at the core of many services (Facebook chat, Amazon, phone gateways etc). It is both a blessing and a curse. If a service or program doesn't crash and cause a lot of drama and headaches it also doesn't get noticed in a certain way. I forgot who mentioned it (one of Erlang Factory talks probably), but for example if you access the Internet via your smart phone, there is like a 30% change that it goes through Erlang at some point (due to going through Ericsson's servers).
  - davidw 13y ago
    I seem to recollect reading about Facebook Chat getting rewritten in C++. Maybe here somewhere?
    - Fishkins 13y ago

judk 13y ago

That syntax for that purpose was totally stolen from Go. Nice to see the cross pollination going in both directions.

BarkMore 13y ago
Go's := (short variable declaration) is closer to Erlang's => (introduce a new key) then it is to Erlang's := (update an existing key).
- snogglethorpe 13y ago
  ... and in that sense, Erlang is following existing practice better than Go did — := is "traditionally" an assignment operator, not a binding operator.
deleted 13y ago
[deleted]

ams6110 13y ago

But now the culprit typo is typing -> when you meant := Maybe less likely, but if you've been writing a lot of code using -> and then in one case need := I can see it happening quite easily.

Tuna-Fish 13y ago
The system would complain loudly in an error message with a line number. The problem with accidental key typos is that at their worst they are completely silent, and if the value you intend to replace was another valid value, finding the bug might not be easy.