4 ms·

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containe

by 16s 13y ago

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containers.

alok-g 13y ago
So what? Got to start isolating interface from the implementation. That implementation inside has overlaps does not mean the interface should be compromised. The latter needs to be designed according to the common needs of the user (here, programmers) rather than the implementation alone. Think "user experience" people!
- 16s 13y ago
  You asked why they would do this. I answered your question. Maps are sets. And by implementing map, you can use it as a map or a set. Perhaps you're not looking for an answer to your question? Say I implement log, but not log2. If you understand what log is and how to use it, you have log2. If you don't understand this, you ask why log2 is not provided.
  - alok-g 13y ago
    I think I do understand what you are saying. But then, by the same token, so many things are not needed in a programming language. C++ for example has often being criticized for not having a power operator (a^b). Why not just work with a Turing machine (simulated on a computer), then you have everything. It is not just about having it or not having it. It is also about user experience. Why should I write log(x)/log(2) assuming that is a commonly used operation such that the library could have provided me with simply log2(x)? Just yesterday there was an user experience related article on confirmation vs. undo. The message was that if most of the users are likely to take the action, then undo is better than confirmation, and if most of the users are unlikely to take the action, then a confirmation is better. While it is bad to provide every option to the user, it is also just as bad to miss the options that the users commonly use. The real question then is if a set is commonly required or not. I believe it is used often enough.
    - hackinthebochs 13y ago
      It's like some people don't understand that an API is an "interface" and simplifying that interface is a boon to productivity, readability, DRYness, etc. All your points are spot on and its absurd that some people don't get that in this day and age. "Abstractions are useless, lets all just program with cmp and jmp statements"--seriously folks, have we not learned anything?
      - alok-g 13y ago
        Indeed. What I hate is that even after having a good understanding of software development and computer science fundamentals, and having a good picture of the solution to a given problem, I still cannot today program without having to perform multiple Google searches, reading Stack Overflow messages, etc. to deal with what should be trivial stuff. Just for example, if I were to need a set, I would search for "set" in Go documentation. If the set itself is not included, on the very least the documentation should talk about what should I do instead. But they won't even have that in there. Result: Few more Google searches.

by 16s 13y ago

A map is a set. In a map, the key and value can be different things. In a set, they are the same. That's the only difference. They are both associative containers.

alok-g 13y ago

So what? Got to start isolating interface from the implementation. That implementation inside has overlaps does not mean the interface should be compromised. The latter needs to be designed according to the common needs of the user (here, programmers) rather than the implementation alone. Think "user experience" people!

16s 13y ago
You asked why they would do this. I answered your question. Maps are sets. And by implementing map, you can use it as a map or a set. Perhaps you're not looking for an answer to your question? Say I implement log, but not log2. If you understand what log is and how to use it, you have log2. If you don't understand this, you ask why log2 is not provided.
- alok-g 13y ago
  I think I do understand what you are saying. But then, by the same token, so many things are not needed in a programming language. C++ for example has often being criticized for not having a power operator (a^b). Why not just work with a Turing machine (simulated on a computer), then you have everything. It is not just about having it or not having it. It is also about user experience. Why should I write log(x)/log(2) assuming that is a commonly used operation such that the library could have provided me with simply log2(x)? Just yesterday there was an user experience related article on confirmation vs. undo. The message was that if most of the users are likely to take the action, then undo is better than confirmation, and if most of the users are unlikely to take the action, then a confirmation is better. While it is bad to provide every option to the user, it is also just as bad to miss the options that the users commonly use. The real question then is if a set is commonly required or not. I believe it is used often enough.
  - hackinthebochs 13y ago
    It's like some people don't understand that an API is an "interface" and simplifying that interface is a boon to productivity, readability, DRYness, etc. All your points are spot on and its absurd that some people don't get that in this day and age. "Abstractions are useless, lets all just program with cmp and jmp statements"--seriously folks, have we not learned anything?
    - alok-g 13y ago
      Indeed. What I hate is that even after having a good understanding of software development and computer science fundamentals, and having a good picture of the solution to a given problem, I still cannot today program without having to perform multiple Google searches, reading Stack Overflow messages, etc. to deal with what should be trivial stuff. Just for example, if I were to need a set, I would search for "set" in Go documentation. If the set itself is not included, on the very least the documentation should talk about what should I do instead. But they won't even have that in there. Result: Few more Google searches.