3 ms·

Here's my exact train of thought while reading that: GetHash? What the frack? Isn't that on object somewhere? Right, object handles all the common copy semanti

Here's my exact train of thought while reading that: GetHash? What the frack? Isn't that on object somewhere? Right, object handles all the common copy semantics and so forth. Use the hash to check for equality; things on the stack instead of the heap, yadda yadda.. Dang, here the guy is going into detail why this is so important. Ah yes, value versus reference semantics. Boxing and so forth. Tiny trivia around how the CLR works. I remember those days well. Would make for a great Nerd Jeopardy question. But who cares about all of that? I'll look it up if I need it. As far as memory usage, I worry about that by using pure FP and being careful what kinds of data structures I use. Problem solved. Encyclopedic knowledge is great, but the real trick is dumping everything possible offline and then knowing how and when you should get back to looking at it.

eropple 12y ago
While in the general case I would agree with you and I try very hard to dump as much stuff offline as possible, I would argue that this is one of those things you cannot look up "if you need it", similar to the difference between 'class' and 'struct' in C# or the difference between 'class' and 'case class' in Scala (the C# one being a runtime implementation difference, the latter being a fairly large OO design difference). It's something you need to internalize to do well in the language and the environment. C# (and similarly Java) are so tightly coupled to their runtime languages that, personally, I do feel like I need to understand stuff like this at an intuitive, not-even-thinking-about-it level to be able to write good, fast, clean code.
- DanielBMarkham 12y ago
  I do not think we disagree. My point was understanding the stack and heap, boxing and unboxing, were great to know general purpose knowledge about how type systems are created and used in modern languages, whether Java or .NET If you know what it is, and you know why it is important and when it is used, then any detail you might miss or mangle really isn't that important. In a similar fashion, I can describe in general terms how a virtual lookup table is fashioned, and how method signatures work in OO linkers. I'd probably miss 90% of the details, but I retain enough of an overview to correct myself when required. I can know something in general terms well enough to know where to go when I dive deep. That's the goal. You have to internalize struct and class. Not so much on the relationship between the built-in hash function and the rest of it. You start using structs and classes, you start extending the type system, badda boom, badda bing -- you end up in the same place. No need to be able to give a lecture on it. Just be able to do the work :)

eropple 12y ago

While in the general case I would agree with you and I try very hard to dump as much stuff offline as possible, I would argue that this is one of those things you cannot look up "if you need it", similar to the difference between 'class' and 'struct' in C# or the difference between 'class' and 'case class' in Scala (the C# one being a runtime implementation difference, the latter being a fairly large OO design difference). It's something you need to internalize to do well in the language and the environment. C# (and similarly Java) are so tightly coupled to their runtime languages that, personally, I do feel like I need to understand stuff like this at an intuitive, not-even-thinking-about-it level to be able to write good, fast, clean code.

DanielBMarkham 12y ago
I do not think we disagree. My point was understanding the stack and heap, boxing and unboxing, were great to know general purpose knowledge about how type systems are created and used in modern languages, whether Java or .NET If you know what it is, and you know why it is important and when it is used, then any detail you might miss or mangle really isn't that important. In a similar fashion, I can describe in general terms how a virtual lookup table is fashioned, and how method signatures work in OO linkers. I'd probably miss 90% of the details, but I retain enough of an overview to correct myself when required. I can know something in general terms well enough to know where to go when I dive deep. That's the goal. You have to internalize struct and class. Not so much on the relationship between the built-in hash function and the rest of it. You start using structs and classes, you start extending the type system, badda boom, badda bing -- you end up in the same place. No need to be able to give a lecture on it. Just be able to do the work :)