Live data from Hacker News

Classes vs. Data Structures

blog.cleancoder.com

121–130 of 184 posts

Re: Classes vs. Data Structures

#121

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…

When Socratic dialogue is done well, it is pretty helpful. When I read some article, I have questions in my head as the author makes her points. If the author is good enough, they can anticipate the reader's questions and write directly to the internal dialogue occurring in my head.

Plato merely makes this process explicit in his Socratic dialogues.

So, the existence of poorly thought out or agenda driven dialogues do not in themselves show the method is a bad one, just like bad musicians do not discredit music as a whole.

Re: Classes vs. Data Structures

#122

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…

I'm going to write you off as insufferable before the fawning moron you have as proxy for your audience utters

You must admit, you're throwing stones from a glass house when you write like that :p

Re: Classes vs. Data Structures

#123
post #28

Earlier quoted context omitted.

Haskell does address it exactly as you say. Functions and values both being expressions is much less complex. As an example, imagine if you couldn't freely substitute 2+2 and 4. Functional languages say those are the same, imperative languages say one is a value and one is a function call. It's not particularly intuitive if you're not used to high level math or functional programming, but it really is a lot simpler (…

I'm not sure that functions alone are sufficient. That's why Haskell supports existential types, and there isn't a convention for distinguishing them so the critique applies.

Existential types are types of values.

Re: Classes vs. Data Structures

#124
post #28

Earlier quoted context omitted.

Haskell does address it exactly as you say. Functions and values both being expressions is much less complex. As an example, imagine if you couldn't freely substitute 2+2 and 4. Functional languages say those are the same, imperative languages say one is a value and one is a function call. It's not particularly intuitive if you're not used to high level math or functional programming, but it really is a lot simpler (…

I'm not sure that functions alone are sufficient. That's why Haskell supports existential types, and there isn't a convention for distinguishing them so the critique applies.

Existential types are types of values. There is no distinction.

Re: Classes vs. Data Structures

#125
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…

There are substantial differences between Clojure's constellation of protocols/records/multimethods and CLOS, but at least the feature of CLOS that you cite is exactly what multimethods in Clojure do, see: https://clojure.org/reference/multimethods

Re: Classes vs. Data Structures

#126
post #85
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).

I'm semi-convinced the reason many people have a problem understanding pointers is because C makes them needlessly confusing. Or at least in my experience people struggle more with C pointers than they do with learning assembly.

FWIW I struggled with pointers in Pascal before struggling with pointers in C.

I do think one area that causes issues with C is any sort of string manipulation requires a reasonable understanding of pointers, and most introductory programming classes tend to focus on things like string manipulation.

Re: Classes vs. Data Structures

#127
post #84

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

Pointers now belong in a weird territory where you can be a perfectly fine programmer without ever having explicitly used a pointer. So most people who have worked with pointers either did it because they cut their teeth on it in school or needed to use C/C++ for hobby/work.

Re: Classes vs. Data Structures

#128
post #59
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…

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 takes either type, or that the & really serves no purpose.

Consider these four lines of code:

    char *p1   =  "hello";
    char  a1[] =  "hello";
    char *p2   = &"hello";
    char  a2[] = &"hello"; // only this one is junk
For the assignment to p1 you get an implied & effectively added into your source code. It may be convenient, but it leads beginners astray with muddled thinking about types.

A little-known limitation of C is that you can't really pass arrays to functions. You get that free & again, meaning that you end up passing a pointer. We should need to do printf(&"hello world\n") but that would be inconvenient, so instead we have a language that appears to behave in inconsistent ways.

Array dimensionality plays a role here. A real X by Y array, with two dimensions X and Y, can syntactically be used in the same way as an array of pointers to arrays. After being passed to a function, the sizeof operator breaks for both (since now you have just a pointer) but the 2-dimensional nature is lost for only one of the styles.

Even the bracket notation is trouble. It is why cute stuff like 4["foo"] can be used to mean 0. That seems harmless enough, but the oddities extend well beyond syntax that nobody should be using. Other issues are pointer arithmetic being surprising and some people being surprised that pointers have types beyond simply "pointer".

I find that the best hope for a clear understanding is to constantly remind the student of the above, right from the start. This is slower going, but it prevents serious misunderstandings from persisting and building on each other.

Re: Classes vs. Data Structures

#129

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…

C++ is still painfully slow to compile, and seems to get slower every year.

Re: Classes vs. Data Structures

#130
Classes vs Data Structures, or maybe Objects vs Data Structures, or maybe Classes vs Objects, or maybe Data vs Data Structures, or maybe Data vs State, or maybe Classes vs Types, or maybe OOP vs FP, or maybe I don't know what I'm talking about...
Post reply on HN