Classes vs. Data Structures • Hacker News Board

Re: Classes vs. Data Structures

#101

Post by verall » Tue, Jun 18, 2019, 12:07 AM UTC

cogman10 wrote: post #78

verall wrote: post #71

Earlier quoted context omitted.

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 th…

I agree completely.

The correct simplification to make is not explaining virtual memory or MMIO. Pretend we have nicely-acting linear address space. The computer is a mail-sorting octopus and when it runs out of hands it only has mailboxes to put things in. Still not a great analogy.

Everytime I start to hear "addresses are like real addresses, ways to find where something lives" I know it will be an explanation for people that want to understand them well enough to not use them.

It is also rough because some people try to explain pointers with Java. AP CompSci in american high schools is happy to try to explain pointers to Java users, it's not surprising people have a rough time!

Re: Classes vs. Data Structures

#102

Post by Silhouette » Tue, Jun 18, 2019, 12:07 AM UTC

narag wrote: post #84

cogman10 wrote: post #78

Earlier quoted context omitted.

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 th…

Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. So is this not how it's explained nowadays? No wonder there's people that doesn't get it. So many concepts, not only about programming, I have learnt in my life first with "this is what happens", then with the precise definition...

I think part of the problem is that many popular languages now default to using two very different behaviours for elementary tasks like passing variables or parameters around, depending on whether the variable is a "reference type" or a "value type". Simple things like numbers have value semantics. Objects and whatever else works a bit like an object in your language have reference semantics. If you want a reference to a simple value like a number, you box it so the basic type is now wrapped in an object, or something equivalent. Maybe that's even a semi-automatic process that is done for you in some cases. Anyway, that's just how variables work, and the idea that in principle you could have a value of any data type or a reference to any data type doesn't even occur to someone who has learned this way.

Then you get to data structures, and you're trying to explain the fundamental difference between dense, buffer/array-like structures and sparse, graph/pointer-like structures, and there might be no concept of an underlying memory model where the difference is clear.

This has always seemed like a horribly ambiguous and inconsistent mental model to me, and there must surely have been quite a few bugs caused by programmers not clearly understanding the differences between value and reference semantics and exactly when each applies in their chosen language(s). And yet for reasons I can't understand, many of the popular languages today do seem to follow something close to this model.

Re: Classes vs. Data Structures

#103

Post by [deleted] » Tue, Jun 18, 2019, 12:10 AM UTC

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…

[deleted]

Re: Classes vs. Data Structures

#104

Post by holy_city » Tue, Jun 18, 2019, 12:11 AM UTC

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).

A better analogy would be the coffee shop (as a physical building) versus the street address of the building. If you want to do anything in the coffee shop you have to go there, the pointer (address) tells you where to go.

And just like real world street addresses, you can't make blind assumptions about pointers.

The value may make logical sense, or it may be completely meaningless and you require direction from someone to find it.

You can't just write down a random address and expect a building to exist at it.

You can hold onto the street address for a coffee shop, put it in a notebook, then one day go to the address to find that the coffee shop was torn down and the street address is invalid.

Re: Classes vs. Data Structures

#105

Post by narag » Tue, Jun 18, 2019, 12:13 AM UTC

avmich wrote: post #93

narag wrote: post #57

Earlier quoted context omitted.

The problem here is that this is a piece of opinion, presented as a lesson, implying that the author is the master and the readers the apprentices.

Can author imply anything else? If reader knows better, why reader reads at all? Actually, before reading nobody can know what's in the writing, so author is naturally more knowledgeable. Lesson is just a transfer of knowledge - which may turn out to be useless, but only after the fact.

Can author imply anything else?

Of course.

If reader knows better, why reader reads at all?

Because the reading, as you yourself said:

...may turn out to be useless, but only after the fact.

I don't find it wrong, just irrelevant.

Oh, and using "data structure" to mean a "struct" is annoying for us old farts that learned the standard meaning, it's causing people to get confused. Actually, since classes are a data structures (in the old sense), the very title sounds like nonsense.

Nothing too bad, every day people does much worse in the Internet, but add the μαιευτικη´ and it comes out as inappropiate.

Re: Classes vs. Data Structures

#106

Post by loktarogar » Tue, Jun 18, 2019, 12:14 AM UTC

thom wrote: post #39

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…

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.

it's not for you.

Re: Classes vs. Data Structures

#107

Post by narag » Tue, Jun 18, 2019, 12:21 AM UTC

Silhouette wrote: post #102

narag wrote: post #84

Earlier quoted context omitted.

Honestly, I think the answer to "Pointers, WTF?" is simply describing how data is stored in memory. So is this not how it's explained nowadays? No wonder there's people that doesn't get it. So many concepts, not only about programming, I have learnt in my life first with "this is what happens", then with the precise definition...

I think part of the problem is that many popular languages now default to using two very different behaviours for elementary tasks like passing variables or parameters around, depending on whether the variable is a "reference type" or a "value type". Simple things like numbers have value semantics. Objects and whatever else works a bit like an object in your language have reference semantics. If you want a reference…

Assembly was fun, but I understand it would be cruel and not so useful to teach it to today students, but I can't figure out how someone can learn some concepts whithout the "memory is an array" model.

My favourite book at college about (the real) data structures started building the array, even if it was already implemented in the language.

Re: Classes vs. Data Structures

#108

Post by Silhouette » Tue, Jun 18, 2019, 12:21 AM UTC

jayd16 wrote: post #33

hudon wrote: post #19

Earlier quoted context omitted.

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…

This is a violation of OOP. Instead, consider methods that produce and consume a serialized representation of the data instead. Things like Java serialization and Python pickle attempt to do what you say and are considered failures (or at least security risks) because they allow a third party to act on object implementation internals. Security aside, a denormalized representation of data could be different than the i…

But this is partly a self-made problem, because in this OOP model you have decided that the internal representation of your data is to be hidden and therefore the data is only accessible via the provided interface.

In practice, it is debatable how often that is helpful when you're implementing generic data structures. An alternative is to specify the representation explicitly and provide a set of functions designed to work with it, but also to allow direct access by other functions when that is useful.

You can still build a layer of more abstract interfaces on top and write more generic algorithms in terms of those interfaces rather than any specific concrete representation, as for example Haskell's typeclass system does.

Re: Classes vs. Data Structures

#109

Post by jayd16 » Tue, Jun 18, 2019, 12:30 AM UTC

Silhouette wrote: post #108

jayd16 wrote: post #33

Earlier quoted context omitted.

This is a violation of OOP. Instead, consider methods that produce and consume a serialized representation of the data instead. Things like Java serialization and Python pickle attempt to do what you say and are considered failures (or at least security risks) because they allow a third party to act on object implementation internals. Security aside, a denormalized representation of data could be different than the i…

But this is partly a self-made problem, because in this OOP model you have decided that the internal representation of your data is to be hidden and therefore the data is only accessible via the provided interface. In practice, it is debatable how often that is helpful when you're implementing generic data structures. An alternative is to specify the representation explicitly and provide a set of functions designed t…

>An alternative is to specify the representation explicitly and provide a set of functions designed to work with it, but also to allow direct access by other functions when that is useful.

I don't see that as an alternative. I consider this natural OOP. You don't lose anything by strictly enforcing the encapsulation because you can always explicitly provide low level methods into the data structures. Conversely, you lose all safety when you open up encapsulation. The method API of an object is the contract it provides. If you go around that contract it's much harder to make safe implementation changes.

Because of this, low level access should be opt in, in the way you describe.

Re: Classes vs. Data Structures

#110

Post by magpi3 » Tue, Jun 18, 2019, 12:30 AM UTC

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…

As a teacher, it's a necessary tool. But you are right that it can be abused by teachers who are both attempting to inspire critical thinking AND trying to navigate their students to the "correct" answer at the same time.

If a teacher wants to convey a specific opinion or viewpoint, they should just share it. But if a teacher is genuinely willing to listen and wants to get their students to think critically about a topic -- without a desire to navigate the students in a specific direction -- then the Socratic method is very useful. But the teacher has to be truly willing to listen to their students. And that is hard for some teachers.