Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Classes vs. Data Structures

blog.cleancoder.com

Post reply on HN
Print view View original

171–180 of 184 posts

Re: Classes vs. Data Structures

#171

Post by kasey_junk »

roelschroeven wrote: post #170
kasey_junk wrote: post #82

Earlier quoted context omitted.

Note that your model is also an abstraction. Modern architectures move data around between a variety of memory locations (and store it in multiple locations) which are all addressed via the pointer ‘transparently’. It’s not really a memory address anymore and hasn’t been for some time. That’s not to say your model is bad, it’s the same one I have in my head. But it’s no more ‘real’ than coordinates or library cards o…

Isn't it still the model that is exposed to the programmer, even though internally all kinds of things are going on to make it all go faster? For example, nowadays many/most processors have separate caches for instructions and data, meaning that they strictly speaking don't conform to the Von Neumann architecture. But the programmer doesn't see the different caches, ideally doesn't even see the cache at all. It's lik…

That depends on the architecture, the os, the compiler & the runtime.

Part of the confusion in teaching pointers (I think) is that we act like they are a lower level abstraction than they are (because they used to be). On modern commodity hardware with mainstream languages pointers have very little to do with memory addresses. Accessing memory via them will not happen in constant time, they may or may not perform better when used, even if the language doesn’t copy them on use the OS or processor might etc.

I just find when I try to teach people the memory address model of pointers there are so many exceptions that the model isn’t helpful. Like the OP I struggle with an alternative.

Re: Classes vs. Data Structures

#172

Post by eska »

hotBacteria wrote: post #159

I like the shapes problem because I actually encountered it and it made me think. I'm not sure about the switch approach described in the post: function area(shape) switch shape.type case "square": return shape.side ** 2 case "circle": return 2 * PI * shape.radius case "triangle": return ... case "segment": return 0 case "polygon": return ... ... case "oval": return ... You can have a lot of cases, some of them requi…

I have to admit I don't quite understand your issue. To me it seems like you've used a lot of OOP and cannot befriend the idea that the data structure (e.g. "Circle" in file GeometryTypes.blub) and operations that are performed with it (e.g. collisions in "CollisionDetection.blub") are completely separate. There should be no discussion whether the circle type and collision belong in the same file, while combinations are in some other file. Think of it like this: if you're going to add 3d rendering of circles, will you put that in Circle.blub together with collision detection? Wouldn't you rather add it to 3DRenderer.blub?

That said, ultimately it doesn't really matter. If you're going to implement collision detection like this, then yes, you will have a combinatorial explosion. This is not a language issue. Switching from Java to some other language with a different form of dispatch will not save you from implementing a lot of algorithms when adding bezier curves into the mix.

The practical approach is reduce the problem to a common case, e.g. to turn the collision shapes into a set of triangles first, and then perform triangle-triangle collision detection.

Re: Classes vs. Data Structures

#173

Post by [deleted] »

eska wrote: post #164
danmaz74 wrote: post #151

Earlier quoted context omitted.

Data oriented design makes sense in video games where perfomance Is very important, but in most business applications having good abstractions which are flexible and easily maintainable is much more important than optimising for cache usage.

I keep hearing this from OOP proponents, but I just don't find it to be true in my experience. Programs written with DOD in mind have very clear data flow and only pass on and use data that is relevant. Programs written with OOP in mind primarily care about some notion of beautiful code and abstractions, which I find to be highly subjective. As a result they generally have very muddy data flow where e.g. unrelated da…

[deleted]

Re: Classes vs. Data Structures

#175

Post by tabtab »

hotBacteria wrote: post #159

I like the shapes problem because I actually encountered it and it made me think. I'm not sure about the switch approach described in the post: function area(shape) switch shape.type case "square": return shape.side ** 2 case "circle": return 2 * PI * shape.radius case "triangle": return ... case "segment": return 0 case "polygon": return ... ... case "oval": return ... You can have a lot of cases, some of them requi…

Business logic tends to be more organic than the rules of geometry and physics. Thus, many of the "toy" OOP examples that use shapes and physics don't extrapolate well to real world abstractions, which often turn out to be semi-abstractions. Geometry and physics generally don't change so we know certain patterns will always stay around. Business logic (the domain) is often NOT like this. Be careful.

Re: Classes vs. Data Structures

#176

Post by burfog »

burfog wrote: post #128
ci5er wrote: post #59

Earlier quoted context omitted.

Have you ever come across anything that explains why pointers are hard for some people? I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed. Pointing people to the very elegant treat…

I've taught pointers to multiple people who struggled. C makes pointers difficult by having some syntax oddities that seem to mainly be intended to save a few characters of source code. The biggest trouble is that C often gives you a free ampersand ("&") when you need one. Consider that p=f and p=&f both can be used to assign the address of a function f to a function pointer p. To a beginner it could look like p take…

Yes, I know about the off-by-one. I can't edit it now.

3["foo"]

Re: Classes vs. Data Structures

#177

Post by burfog »

cogman10 wrote: post #81
tomrod wrote: post #62

Earlier quoted context omitted.

I don't think I understand pointers. Maybe we can help each other. My mental model of pointers is a map: lat/long identify the object of interest (the local coffee shop), but not what is interesting about it (their menu and hours).

Do you know what an array is? If so, then you can think of memory like as a giant array of bytes and a pointer as the index in that array. Hurray, you now understand pointers :) Don't muddy it up beyond that.

There are different notions of what an array is.

In some languages, an array is dynamic. You don't have to declare the size. You can just put stuff at any index you desire, and the array will grow as needed. For example, just set foo[1000000000] to 42. That might take a gigabyte or more of RAM, or just address space, or neither.

The indexes might not be required to be numbers. Some languages allow strings or even arbitrary objects as indexes. You could index by a JPEG or a device handle or a float.

The values might not be required to have a consistent type. Some languages would let you throw random different-sized things into an array.

Re: Classes vs. Data Structures

#178

Post by cogman10 »

burfog wrote: post #177
cogman10 wrote: post #81

Earlier quoted context omitted.

Do you know what an array is? If so, then you can think of memory like as a giant array of bytes and a pointer as the index in that array. Hurray, you now understand pointers :) Don't muddy it up beyond that.

There are different notions of what an array is. In some languages, an array is dynamic. You don't have to declare the size. You can just put stuff at any index you desire, and the array will grow as needed. For example, just set foo[1000000000] to 42. That might take a gigabyte or more of RAM, or just address space, or neither. The indexes might not be required to be numbers. Some languages allow strings or even arb…

* In some languages, an array is dynamic.

Doesn't really matter for the general concept.

* The indexes might not be required to be numbers.

In most of those languages, that data type is called a map, dictionary, or even associative array. I've seen few languages actually use the phrase "associative array" primarily because it is confusing.

But, to be clear, I'm talking about the common "array" definition. That is, a value indexed by a number.

* The values might not be required to have a consistent type.

Yet, I was clear in saying "a byte array". A pointer points to the byte address and doesn't care about what type is ultimately represented. That is why void pointers are a thing. It is a language level action to reinterpret the pointer into a concrete object type.

But again, that confuses the issue of what pointers are with concerns like memory layout and object sizes. To be clear, you don't need to those concepts to understand what a pointer is.

* Some languages would let you throw random different-sized things into an array.

I specifically said "array of bytes". It does not matter what a language lets you do. A pointer is the head of a byte address and the interpretation of that byte and subsequent bytes are a language level concern. All unneeded information for a discussion on "what is a pointer".

Re: Classes vs. Data Structures

#179

Post by flakiness »

Was surprised how Uncle Bob getting better at trolling these days. He's been provoking, but somewhere in recent years he turned himself to a troll. (Or he's just talking to his audiences, who aren't HN readers.)

Re: Classes vs. Data Structures

#180

Post by ci5er »

burfog wrote: post #128
ci5er wrote: post #59

Earlier quoted context omitted.

Have you ever come across anything that explains why pointers are hard for some people? I find it difficult to explain pointers to people because I don't understand what they are missing. I could use some help understanding their lack of understanding. When they don't get "indirect reference to the address of a data structure or object in memory", I'm stuck on how to proceed. Pointing people to the very elegant treat…

I've taught pointers to multiple people who struggled. C makes pointers difficult by having some syntax oddities that seem to mainly be intended to save a few characters of source code. The biggest trouble is that C often gives you a free ampersand ("&") when you need one. Consider that p=f and p=&f both can be used to assign the address of a function f to a function pointer p. To a beginner it could look like p take…

So ... the problem with understanding pointers is C syntax? That sounds ... plausible.
Post reply on HN