Classes vs. Data Structures • Hacker News Board

Re: Classes vs. Data Structures

#111

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

bendbro wrote: post #56

ivan_gammel wrote: post #42

Earlier quoted context omitted.

You are getting it wrong. Data structures do not own functions, instead they are passed to functions. So you have shapes and somewhere else you have perimeter function which has switch statement to determine the algorithm of calculation based on the type of the structure.

Ah, and what owns these functions? And more pressingly, why would you ever pass a data structure to a function that had more than one algorithm to compute a result? The data structure (or perhaps some intermediary (an adapter?)) should own the algorithm within a function that computes only on that data structure. This ensures that all methods associated with your data structure are obviously and explicitly associated…

Given these two possibilities, why would one choose to place switches in disparate places throughout your code?

You are touching on something called the "expression problem". You might be interested in reading some commentary about it. There is an inherent decision to be made any time you have many algorithms each operating on many data types. In most programming models, you have to choose between grouping your code based on your data types (but then any new algorithm needs to be implemented on each data type) or based on your algorithms (but then any new data type needs to be supported by a new case in each algorithm). Neither is the "right answer". You fundamentally have a two-dimensional system here, and you need to decide which axis you are going to prioritise in your design.

Re: Classes vs. Data Structures

#112

Post by CodeMage » Tue, Jun 18, 2019, 12:42 AM UTC

avmich wrote: post #97

CodeMage wrote: post #87

Earlier quoted context omitted.

To be fair, actual Socratic dialogue can be very effective and rewarding, without being patronizing. What you're describing there -- what the blog post is like -- that's just as awful as you said, or worse. I couldn't get much further past this: What is an object? An object is a set of functions that operate upon encapsulated data elements. ...what?

Maybe we should try to be patient here and assume some valid point of view - even if possibly unusual for a personal experience. That is, can we try to justify this approach? It's like HN guidelines - "assume good intent".

We can try, but we won't get as far as you might like. I gave the post a second chance and pushed myself past the point I originally criticized and past all such points.

I could write an in-depth critique of the whole post, but it's 5:30 pm and I would rather focus on finishing my work so I can go home and be with my family.

So instead of that, I'll just give you a summary of what I think about the post:

1) The post essentially compares two different approaches: a specific variant of object-oriented programming and a specific variant of functional programming.

2) There are various points in the post where the author plays fast and loose with definitions of certain concepts, in order to make them fit his narrative.

3) The Socratic dialogue format does not help make the reasoning clearer, it just makes the readers uncomfortably aware that they're being railroaded into reaching certain conclusions.

4) The conclusions reached in the post are a mixed bag of: a) useful and interesting, b) correct but incomplete, and c) correct only under very specific circumstances, rendering them potentially dangerous.

Re: Classes vs. Data Structures

#113

Post by hardwaresofton » Tue, Jun 18, 2019, 12:46 AM UTC

Jach wrote: post #38

I guess this applies for Java and C++ style "classes". This does not precisely apply to the first ANSI-standardized OOP system, Common Lisp's. Standard classes do not own methods, instead methods are specializations of a generic function that stands alone and dispatches on the class types (or EQL values) of all its arguments. I'd really like it if Uncle Bob eventually has his fill of Clojure and moves on to explore w…

To add another point to the Common lisp over Clojure argument, DECLARE[0] offers a way to take advantage of type declarations natively.

I stopped using Clojure and don't consider it for new projects because I think types are invaluable documentation now, and it pains me that clojure and it's community doesn't believe the same way (typed clojure[1] does exist but it's contentious).

[0]: http://clhs.lisp.se/Body/s_declar.htm

[1]: https://github.com/clojure/core.typed

Re: Classes vs. Data Structures

#114

Post by ChrisSD » Tue, Jun 18, 2019, 12:54 AM UTC

narag wrote: post #107

Silhouette wrote: post #102

Earlier quoted context omitted.

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.

I think learning some assembly is essential for any student that wants to use a low level programming language. It's a good way to learn not only about pointers but also the stack, registers, etc. I don't mean they need to be able to manually create a full program in assembly but doing simple exercises can be enlightening on their own.

Of course you also have to mention that even assembly is an abstraction. Memory isn't really a big array, cpus have caches and all that jazz. This matters when writing performant algorithms.

Re: Classes vs. Data Structures

#115

Post by phailhaus » Tue, Jun 18, 2019, 12:55 AM UTC

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…

> 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

That's because to them, _everything_ is an "indirect reference". Every time they use a variable it feels like an indirect reference, so what the hell is so special about a pointer?

Took me an intro class in computer systems before I could really understand pointers, because nobody wanted to bite the bullet and teach me about the stack. Pointers don't make sense if you don't know that the stack and the heap exist.

Re: Classes vs. Data Structures

#116

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

jayd16 wrote: post #109

Silhouette wrote: post #108

Earlier quoted context omitted.

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…

You don't lose anything by strictly enforcing the encapsulation because you can always explicitly provide low level methods into the data structures.

But then you're not really gaining anything either, unless perhaps you have some mechanism to enforce that the low-level access should only be used in specific circumstances when it is deliberately intended. It's like writing classes that have a few data members, but then writing direct get and set accessors for each of them anyway. There's no more complicated invariant that you're enforcing at that point, and without any non-trivial invariants to be enforced, the whole argument for encapsulation and data hiding becomes moot.

Conversely, you lose all safety when you open up encapsulation. The method API of an object is the contract it provides.

Do you always need that safety, though? If your data is defined to be stored in a certain representation, and direct access to that underlying representation in that format is available if needed, isn't that representation now just another part of the contract? Again, you're balancing two competing priorities: is there some invariant to be enforced that is sufficiently complicated for data hiding to be a useful safeguard, and is it useful to interact efficiently with, or make safe assumptions about performance based on, the true data representation?

Which one is the more important consideration must surely depend on how complicated your representation and any related invariants are. Being able to pattern match against values of some relatively simple algebraic data type can be very useful, for example. On the other hand, it's not much fun to accidentally corrupt the super-efficient look-up structure at the heart of your whole system that now uses a complicated set of hash tables and the odd Bloom filter internally after someone spent three weeks optimising it for a 50% speed boost.

Re: Classes vs. Data Structures

#117

Post by ci5er » Tue, Jun 18, 2019, 1:17 AM UTC

phailhaus wrote: post #115

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…

> 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 That's because to them, _everything_ is an "indirect reference". Every time they use a variable it feels like an indirect reference, so what the hell is so special about a pointer? Took me an intro class in computer systems before I could really understand pointers, because nobody wanted to b…

> Pointers don't make sense if you don't know that the stack and the heap exist.

Now, THAT's interesting...

Re: Classes vs. Data Structures

#118

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

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…

[deleted]

Re: Classes vs. Data Structures

#119

Post by bendbro » Tue, Jun 18, 2019, 1:18 AM UTC

Silhouette wrote: post #111

bendbro wrote: post #56

Earlier quoted context omitted.

Ah, and what owns these functions? And more pressingly, why would you ever pass a data structure to a function that had more than one algorithm to compute a result? The data structure (or perhaps some intermediary (an adapter?)) should own the algorithm within a function that computes only on that data structure. This ensures that all methods associated with your data structure are obviously and explicitly associated…

Given these two possibilities, why would one choose to place switches in disparate places throughout your code? You are touching on something called the "expression problem". You might be interested in reading some commentary about it. There is an inherent decision to be made any time you have many algorithms each operating on many data types. In most programming models, you have to choose between grouping your code…

Thanks. I will look into this. I would like to see examples that obviously require algorithm-grouping or type-grouping, as in my experience, algorithm-grouping has always lead to headaches.

I think I have encountered this issue in the past but was turned of by the lack of formality in the discussion. I wish there was more academic, concrete discussion of these issues, because I feel that what I am doing now (informal discussion) likely has many holes.

Re: Classes vs. Data Structures

#120

Post by mike_ivanov » Tue, Jun 18, 2019, 1:20 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.

I feel an urge to tell somebody a monadic astronaut burrito story.