4 ms·

Whoa. This makes the language feel much more approachable. I love that they've provided both an "upsert" and a semantically distinct "update" for their maps. Wo

Whoa. This makes the language feel much more approachable. I love that they've provided both an "upsert" and a semantically distinct "update" for their maps. Working without upsert is painful, but the problem of accidentally inserting when you meant to update is an irritating pitfall. They've really picked a good middle way here. Does anyone know how often Learn You Some Erlang is updated? I'd definitely take another pass at the language with these features in place. Kudos, team!

sandal 13y ago
Not a direct answer to your question but Joe's "Programming Erlang" book has been fully updated, and includes a chapter on the new map feature.
- jasonlotito 13y ago
  As someone who owns both of his PragProg books, the second edition is also a big improvement over the first. If you ever tried learning Erlang, and didn't stick with it, but still want to learn it, I highly recommend the second edition.
mononcqc 13y ago
Author here. I haven't yet updated it, but plan to eventually update the website with these features. The thing is a lot of it won't need to change majorly. Maps should be a replacement of data structures like dicts and gb_trees, but I personally do not see them as a replacement of records within a module, where I feel their restrictiveness is welcome, for two main reasons: 1. especially to crash early in live code upgrades, despite, I'm sure, a lot of people disagreeing with me. 2. The module isolation inherent to records makes people think at a protocol level and with their API much, much better than the common pattern of saying "screw it", sharing the state around, and breaking abstraction all over. I like how it constrains the programmer to think of what should be passed around in messages, and that maps may remove that "think hard" part of the problem. Maps should be especially nice and enable more complex dictionary manipulations, nested key/val mapping, and so on, and in terseness of operations. More elegantly, they could be a decent fix to 'use ETS to optimize K/V operations', although they won't benefit from the same parallel access. I plan to explain this and possibly revisit some code snippets from the book in an add-on chapter, and also show what I wouldn't change. Regarding Funs, I probably will just add a section to the anonymous function part, and see if I ever used recursive anoynmous functions before. It's likely that I avoided them on purpose in the book and as such, won't need to add too much there. Let me know if that sounds good to you.
- sitkack 13y ago
  I definitely agree on records forming the basis for a protocol. Maps do not serve the same purpose, I could see maps _used_ in a protocol but not the basis for it. Long live records! It would be nice if records became a concrete thing in Erlang.
- colanderman 13y ago
  Maps should be a replacement of data structures like dicts and gb_trees Why? Why do you need to pattern-match on a structure whose keys you don't know a priori? Why should the syntax prefer one map-like data structure over another? Don't get me wrong, I love that maps are in the language now – as a replacement for records, where syntax and pattern matching make sense and are used all the time, and the data structure issue is much less sensitive. Please don't hamper their performance by forcing them to support the use case for which dicts and gb_trees are intended!
  - mononcqc 13y ago
    Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, key/val lists, and so on are like that. The user has to know the keys to use them sometimes. The data structure definition doesn't. The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be, and they do not have pattern matching. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Maps are pretty much dicts and trees with pattern matching added more than anything. They even have the same issues with considering the equality of integers and floats. Records still have their use case as is right now. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I prefer to prioritize semantics over syntax.
    - colanderman 13y ago
      Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. So? Having a similar interface doesn't mean they have comparable implementations. Even in the maps runtime implementation, we see a benefit of knowing that a structure is homogeneous: run-time type information can be lifted out of the structure, saving memory and time. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, proplists are like, the poster child static heterogeneous structure, precisely because I do know all the keys in advance! It's just that in a given instantiation, some of them map to the value "undefined"! The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be Then reimplement the dict module. How does syntax help here? and they do not have pattern matching. Again, why do you need to pattern match something whose keys are determined at runtime? I've never wanted such an ability in a language; I don't see the benefit. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Why not? OCaml can perform typechecking of structurally typed values. That's a solved problem. If there's no plans to support it in Dialyzer I'll add it myself. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I think we disagree on what a "map" is. You say a map is one thing (a replacement for a key-value store), but when I see syntax that looks, walks, and quacks like a structurally typed record, I see a structurally typed record, and I'm utterly baffled why those things should have anything to do with each other.

sandal 13y ago

Not a direct answer to your question but Joe's "Programming Erlang" book has been fully updated, and includes a chapter on the new map feature.

jasonlotito 13y ago
As someone who owns both of his PragProg books, the second edition is also a big improvement over the first. If you ever tried learning Erlang, and didn't stick with it, but still want to learn it, I highly recommend the second edition.

mononcqc 13y ago

Author here. I haven't yet updated it, but plan to eventually update the website with these features. The thing is a lot of it won't need to change majorly. Maps should be a replacement of data structures like dicts and gb_trees, but I personally do not see them as a replacement of records within a module, where I feel their restrictiveness is welcome, for two main reasons: 1. especially to crash early in live code upgrades, despite, I'm sure, a lot of people disagreeing with me. 2. The module isolation inherent to records makes people think at a protocol level and with their API much, much better than the common pattern of saying "screw it", sharing the state around, and breaking abstraction all over. I like how it constrains the programmer to think of what should be passed around in messages, and that maps may remove that "think hard" part of the problem. Maps should be especially nice and enable more complex dictionary manipulations, nested key/val mapping, and so on, and in terseness of operations. More elegantly, they could be a decent fix to 'use ETS to optimize K/V operations', although they won't benefit from the same parallel access. I plan to explain this and possibly revisit some code snippets from the book in an add-on chapter, and also show what I wouldn't change. Regarding Funs, I probably will just add a section to the anonymous function part, and see if I ever used recursive anoynmous functions before. It's likely that I avoided them on purpose in the book and as such, won't need to add too much there. Let me know if that sounds good to you.

sitkack 13y ago
I definitely agree on records forming the basis for a protocol. Maps do not serve the same purpose, I could see maps _used_ in a protocol but not the basis for it. Long live records! It would be nice if records became a concrete thing in Erlang.
colanderman 13y ago
Maps should be a replacement of data structures like dicts and gb_trees Why? Why do you need to pattern-match on a structure whose keys you don't know a priori? Why should the syntax prefer one map-like data structure over another? Don't get me wrong, I love that maps are in the language now – as a replacement for records, where syntax and pattern matching make sense and are used all the time, and the data structure issue is much less sensitive. Please don't hamper their performance by forcing them to support the use case for which dicts and gb_trees are intended!
- mononcqc 13y ago
  Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, key/val lists, and so on are like that. The user has to know the keys to use them sometimes. The data structure definition doesn't. The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be, and they do not have pattern matching. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Maps are pretty much dicts and trees with pattern matching added more than anything. They even have the same issues with considering the equality of integers and floats. Records still have their use case as is right now. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I prefer to prioritize semantics over syntax.
  - colanderman 13y ago
    Maps literally have a module definition that ends up being similar to dicts if you want to swap them in directly. So? Having a similar interface doesn't mean they have comparable implementations. Even in the maps runtime implementation, we see a benefit of knowing that a structure is homogeneous: run-time type information can be lifted out of the structure, saving memory and time. You can know a data structure's keys in advance while still having it dynamic and not a record: proplists, proplists are like, the poster child static heterogeneous structure, precisely because I do know all the keys in advance! It's just that in a given instantiation, some of them map to the value "undefined"! The weakness of dicts and gb_trees is two-faced: they're both slower than maps promise to be Then reimplement the dict module. How does syntax help here? and they do not have pattern matching. Again, why do you need to pattern match something whose keys are determined at runtime? I've never wanted such an ability in a language; I don't see the benefit. Records and maps are distinct in my opinion. I, for example, won't expect to be able to use Dialyzer and do type checking of specific key's values (much like with dicts, trees, k/v lists), but will do so with records. Why not? OCaml can perform typechecking of structurally typed values. That's a solved problem. If there's no plans to support it in Dialyzer I'll add it myself. Maps have more in common semantically with dicts than they have with records, where the similarity is syntactical. I think we disagree on what a "map" is. You say a map is one thing (a replacement for a key-value store), but when I see syntax that looks, walks, and quacks like a structurally typed record, I see a structurally typed record, and I'm utterly baffled why those things should have anything to do with each other.