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

71–80 of 184 posts

Re: Classes vs. Data Structures

#71

Post by verall »

ci5er wrote: post #59
thom wrote: post #39

Earlier quoted context omitted.

The only thing more annoying is when people ape Why's (Poignant) Guide to Ruby and you have to follow the adventures of some tedious otter as it meets the rabbit people who ultimately explain pointers in a way which takes a thousand too many words.

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…

What I see is two types of people, people that understand basic computer architecture and those that don't.

The C memory model and pointers come easily to those that understand what a memory address is and how long one is on their favorite architecture.

In my experience, people without this knowledge might understand how to use pointers, but not really why they are. And the answer to the "why pointers" question is _not_ "Imagine you want a function that swaps two parameters" nor "because they you would have to copy structs all of the time"

Re: Classes vs. Data Structures

#72

Post by cheesymuffin »

stupidcar wrote: post #35

Whenever I hear "Socratic dialog", I reach for my revolver. Is there any other form of teaching so irritating and patronising? You might have a brilliant store of insight to impart, but if you insist on trying to do so via a twee, affected and unbelievable conversation with a Mary Sue wise professor, I'm going to write you off as insufferable before the fawning moron you have as proxy for your audience utters their f…

You have a revolver? That's awesome!

Re: Classes vs. Data Structures

#73

Post by marcosdumay »

hudon wrote: post #19
danmaz74 wrote: post #9

Earlier quoted context omitted.

In a purely oop language, data structures exist as an implementation detail, but you can never access them directly (as in, bypassing the object interface). That's by design.

I get that in your application, you may want to keep a linked list behind its interface 90% of the time. However, considering your system as a whole, at some point you may want to take that linked list data and write it to a database, in which case the cleanest thing is to bypass the interface and extract the "data structure object" so to speak and deal with it in a database-related object, rather than encumbering yo…

It's one of the most efficient ways.

But it's not the cleanest way by any measure. It has tighter internal coupling than any other easy to imagine way. Most of the times, people will use the list normal interface to take the data.

If performance is a requirement, most OOP people will create a database interface, that the linked list class can write without taking outside of its interface. Most FP people would do it the other way around, and create an interface to applying data to a function that the list can implement. Either way, it can tie with the dirty introspection in performance.

Re: Classes vs. Data Structures

#74

Post by lliamander »

tomrod wrote: post #62
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 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).

When learning abstract programming concepts, I think it is important to have some practice operationalizing that knowledge. Precise definitions are important, but by themselves aren't enough because it doesn't guarantee you'll understand the implications of that definition.

Analogies seem like they help, but often lead to error when you reach a point where the analogy is stretched to far.

To see if you understand pointers, try exercise #3 here: https://www.joelonsoftware.com/2005/12/29/test-yourself/ . Just step through the code in your head, and then use your mouse to highlight the text in the box below it. Hopefully that helps you to get started in the right direction.

Re: Classes vs. Data Structures

#75

Post by marcosdumay »

lmm wrote: post #53
antisemiotic wrote: post #13

Earlier quoted context omitted.

In Haskell this can be pushed further, by making existential types, i.e. opaque type that's only known to implement some type class. This doesn't seem to be that useful in Haskell (I think it's because of the immutability), but trait objects in Rust are pretty much the same and are used more often. As a side note, I hope that the situation with pre- and postcondition checking improves (runtime verficiation like in Ra…

> This doesn't seem to be that useful in Haskell (I think it's because of the immutability) I suspect it's because of the polymorphism. Why write a function that operates on some unknown a for which a Foo implementation exists when it's so easy to write a function that operates on any a for which a Foo implementation exists? The only time I've seen existentials used is for safety - in particular ST-style monads where…

Optparse-applicative has a very nice use of existential types to break a definition loop.

Re: Classes vs. Data Structures

#76

Post by mannykannot »

Why does every software example always involve shapes?

Because they allow us to avoid discussing the complications that arise when entities have lifetimes, over which, at different stages, different operations are meaningful.

Re: Classes vs. Data Structures

#77

Post by abecedarius »

chongli wrote: post #55
evancordell wrote: post #54

Earlier quoted context omitted.

Is there a difference between using the Socratic method interactively and transcribing a socratic discourse that never occurred?

A huge difference. Interactively, you can both ask and answer questions and you can steer the dialogue toward the pupil's areas of ignorance. As a form of writing, you're left to guess at what your pupil might be thinking. Apart from Plato, few people have ever managed to succeed at this.

Plato succeeded if you judge by his historical rep, but I can't stand the guy, for reasons not entirely unlike the complaint starting this thread. Though good dialogs do exist (I like Raymond Smullyan's).

Re: Classes vs. Data Structures

#78

Post by cogman10 »

verall wrote: post #71
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…

What I see is two types of people, people that understand basic computer architecture and those that don't. The C memory model and pointers come easily to those that understand what a memory address is and how long one is on their favorite architecture. In my experience, people without this knowledge might understand how to use pointers, but not really why they are. And the answer to the "why pointers" question is _n…

Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. This concept is important not only for how pointers work but even how data is stored on a hard drive. You don't have to go into great detail. All you need to do is say this is a number, it takes n number of bytes to store (Most people who haven't been living under a rock have a knowledge of bytes, just explain it to them using their phone data plan). Draw a picture showing one set of bytes next to another. Write 0x100 at the first set, 0x100 + number of bytes you put in at the second.

Then, it is simply "0x100 is what's in a pointer".

I don't think that is complex (it shouldn't be). It is intuitive to most. Seeing a picture should solidify things. And finally, it is semi-accurate to how a pointer actually works. Getting into the mud of "A pointer is like a reference in a scholarly paper" or "A pointer is like a link on a webpage" simply confuses what a pointer actually is.

And, if that isn't enough, simply write a program using pointers and print out pointer values. It really is a crazy simple concept that doesn't need a whole lot of metaphors.

What's worse is when the authors of "what's a pointer" don't know what a pointer is themselves. I've seen that far too often.

Re: Classes vs. Data Structures

#79

Post by lliamander »

charlieflowers wrote: post #34
justinpombrio wrote: post #7

The first set of points: > Classes make functions visible while keeping data implied. Data structures make data visible while keeping functions implied. > Classes make it easy to add types but hard to add functions. Data structures make it easy to add functions but hard to add types. is known as the Expression Problem https://en.wikipedia.org/wiki/Expression_problem . The last point: > Data Structures expose callers…

Regarding the claim ... > Data Structures expose callers to recompilation and redeployment. Classes isolate callers from recompilation and redeployment. ... most projects (maybe all?) I've worked on in 20+ years deployed a full set of new bits upon release, rather than trying to differentiate at the level of which source code files were and were not touched. So this strikes me as a carryover from many years ago when…

Well, it also affects things like packaging and swapping out alternative implementations of different components.

Re: Classes vs. Data Structures

#80

Post by ridiculous_fish »

charlieflowers wrote: post #34
justinpombrio wrote: post #7

The first set of points: > Classes make functions visible while keeping data implied. Data structures make data visible while keeping functions implied. > Classes make it easy to add types but hard to add functions. Data structures make it easy to add functions but hard to add types. is known as the Expression Problem https://en.wikipedia.org/wiki/Expression_problem . The last point: > Data Structures expose callers…

Regarding the claim ... > Data Structures expose callers to recompilation and redeployment. Classes isolate callers from recompilation and redeployment. ... most projects (maybe all?) I've worked on in 20+ years deployed a full set of new bits upon release, rather than trying to differentiate at the level of which source code files were and were not touched. So this strikes me as a carryover from many years ago when…

Consider any scenario in which you don't control all of the source code that gets run. For example, software which supports 3rd party plugins, Apple releasing a new version of iOS, etc.
Post reply on HN