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

The use of `class` for things that should be simple free functions

quuxplusone.github.io

Post reply on HN
Print view View original

361–370 of 406 posts

Re: The use of `class` for things that should be simple free functions

#361

Post by jimmaswell »

jl2718 wrote: post #360
AlexanderDhoore wrote: post #336

Earlier quoted context omitted.

It's code and state. Nothing more. Nothing less.

My first computer book was: “Data Structures + Algorithms = Programs”. Thinking in this way has simplified my code tremendously. I think OO is taught because it’s more tactile. Literally it takes more keystrokes, and so much is pattern repetition that it facilitates learning and feels like progress. Functional is like learning Latin by studying Ovid one word at a time. When books (or mips) were expensive, this was ho…

OO is just the most intuitive way to compartmentalize state to many people, me included.

Re: The use of `class` for things that should be simple free functions

#362

Post by gfxgirl »

savingGrace wrote: post #335
AlexanderDhoore wrote: post #311

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He careful…

I felt as though I should know the moral of the story, yet I did not. https://stackoverflow.com/a/11421598 Moral of the story is that closures and objects are ideas that are expressible in terms of each other, and none is more fundamental than the other. That's all there is to the statement under consideration.

Maybe I'm mis-understanding the definition of class or object but isn't a "File" in even Haskell an example of a class. Files have state which is either the read head or write head and in most languages you can change the head using seek.

I don't think the fact that you call `file.seek` vs `seek(file)` the difference between functional and object oriented. functional people say "state = evil, side effects = evil" and yet that version of `seek` has both.

The functional version of files would have to move the head out of the file

newWritePosition = write(file, currrentWritePosition)

And there would be no need for seek since you're holding your own write and/or read position.

If you close over a bunch of state and pass back a function or functions to work with that closed state you've just created an object with state and side effects. That's exactly what FP people say is bad.

Re: The use of `class` for things that should be simple free functions

#364

Post by AlexanderDhoore »

gfxgirl wrote: post #362
savingGrace wrote: post #335

Earlier quoted context omitted.

I felt as though I should know the moral of the story, yet I did not. https://stackoverflow.com/a/11421598 Moral of the story is that closures and objects are ideas that are expressible in terms of each other, and none is more fundamental than the other. That's all there is to the statement under consideration.

Maybe I'm mis-understanding the definition of class or object but isn't a "File" in even Haskell an example of a class. Files have state which is either the read head or write head and in most languages you can change the head using seek. I don't think the fact that you call `file.seek` vs `seek(file)` the difference between functional and object oriented. functional people say "state = evil, side effects = evil" and…

I don't know what your point is here. When you do IO, even in Haskell, you will be mutating state in the outside world. Also know that many functional languages, especially the lisps, will allow you to mutate state in a closure.

Re: The use of `class` for things that should be simple free functions

#365

Post by Tomis02 »

JoeAltmaier wrote: post #198
amw-zero wrote: post #48

Earlier quoted context omitted.

None of these situations require an object to do. You can always have a function that takes in an extra ‘state’ argument. You can then do everything you said by passing in the corresponding state values.

Sure, you can build your own object and pass the 'this' pointer around manually. You could use C for everything, and tediously do everything again that objects do for free. But why? There's a lot of object-hating going around. Its silly. Use objects to encapsulate functionality, they are good at that and everybody understands what it means.

> Use objects to encapsulate functionality

Sadly objects are also used in an attempt to hide data (because direct access to data is considered dirty in OOP).

Now, consider a non-trivial OOP class hierarchy. You have an object that needs to mutate another object's data (an object that is completely unrelated to your initial object). In order to solve this you have options:

- completely rearchitect your code so that you take this use case into account

- find the shortest path between these two classes and add setters to each class

- hack the code and call it "technical debt"

First one is not feasible, second one is unmanageable (complexity increases dramatically), third one is usually chosen.

Speaking from experience, OOP is most of the time the worst tool for the job.

Re: The use of `class` for things that should be simple free functions

#366

Post by Tomis02 »

kyralis wrote: post #266
totony wrote: post #220

Earlier quoted context omitted.

Classes usually have a more complex state than the state passed to utility functions, which is a reason I'd be incline to use e.g. a struct as a state vs a C++ class. Makes it harder to write bad code.

So, let's say what you actually mean here: overly complex state is a problem, regardless of the syntactic sugar around passing it. I've seen monstrous state variables passed around to "pure functions" at least as much as I've seen monstrous god objects; the problem is around complexity and data flow design and has very little to do with function vs object.

Upvote for the comment, but the reality is OOP (at least in C++) encourages people to write code this way. When you have a sufficiently large code base and an unforeseen requirement comes in, one that wasn't planned for in those architectural committees, you have a problem. And that problem is solved by either a man-century of refactoring, or by taking some shortcuts that destroy the purity of the code and eventually lead to these monstrous god objects that you mentioned. This happens over and over, to the point where you can't just say "oh it was an accident, happened just one time".

Re: The use of `class` for things that should be simple free functions

#367

Post by Tomis02 »

kqr wrote: post #87
cataphract wrote: post #51

Earlier quoted context omitted.

But if you're passing a state object around, you might as well use a class, no? Admittedly simplifying a bit, an instance method is a function that implicitly takes "this" as the first argument.

There's one big difference in terms of convenience in many common implementations of classes and methods. There are essentially three different pieces involved: In OO notation, we have A.B(C) In almost all languages, you can store C in a variable and supply it "later": z = C A.B(z) You can also store A in a variable and supply it "later": x = A x.B(C) However, it is much more rare to be able to store B in a variable…

> This means that at the time you select which method to call, you must also have at your disposal the instance on which you want to call it!

The time you "select which method to call" is when you write the code, right? You select it once. Like, "printf(arg);". I selected printf (in my mind), I called it. I don't need to do "x = print; x(arg)".

> With functions, things get easier. If you have B(A, C), you can generally just store B in a variable on its own:

> y = B

> y(A, C)

>Some OO languages allow you to store plain methods that aren't yet bound to a particular instance (JavaScript, modern Java) but far from all do...

Sorry, I lost the plot here. If you have B(A, C) then you don't need "y = B". B is an invariant of sorts. Just like you don't usually store the address of a class method; you just call that method on an object. Nobody writes:

> x = &objectInstance::method;

> x(args);

People just write

> "objectInstance.method(args);"

Therefore in your case, if using functions, you just do B(A, C). No assignment needed, works in every language.

What am I missing?

Re: The use of `class` for things that should be simple free functions

#368

Post by steerablesafe »

jcelerier wrote: post #217
gpderetta wrote: post #191

Earlier quoted context omitted.

You can then specify the function pointer type, although mildly inconvenient. If you want to use lambdas though, then yes, you are out of luck as their type is unnameable.

but that fails as soon as you have a case where you want to pass an algorithm implementation that does have state. That was my point - whenever I assumed that I would not have state... well I ended up needing to refactor everything because I ended up needing to add a new strategy that did require some state later. In the context of C++, struct / class types are more generic that function pointers and there's no real…

There is nothing wrong with writing generic code that works both with functions and function objects. Note that stateless (empty) function objects can often be more efficient than function pointers.

Re: The use of `class` for things that should be simple free functions

#369

Post by strokirk »

As a Python programmer, I've found that since I started using `mypy` I've written a lot more classes - I generally like using multiple small functions, but classes have two big benefits for me:

1. I don't have to repeat / import type signatures as much

2. I can collapse a bunch of related functions more easily in my editor.

So functional programming (in python at least!) has a few things to solve regarding ergonomics for me to return to it.

Re: The use of `class` for things that should be simple free functions

#370

Post by cessor »

nightski wrote: post #288
kyralis wrote: post #263

Earlier quoted context omitted.

You're talking yourself in circles. Your final sentence contradicts the remainder of your point. Testing is limited when you do not have the ability to fully control state, and understanding can be limited when information is hidden. The impacts of this are determined by the information being hidden, its relationship to the function's behavior, and the documentation of that behavior relative to the calling context. L…

I think information hiding is the wrong term. It should be hidden for modification, open for inspection. Functional programming naturally promotes this. OO does not. That's my opinion. It's been a useful discussion though so I appreciate everyone's input.

The term information hiding used in this thread is very confusing (to me, at least).

I believe David Parnas introduced it in 1971 to mean that a program's design was sliced along shared units of concerns (things that vary together) rather than "steps in a flowchart".

https://prl.ccs.neu.edu/img/p-tr-1971.pdf

I believe what you are trying to convey is called "data abstraction", as for example used by Reynolds, 1975;

mentioned here: https://www.cs.utexas.edu/~wcook/papers/OOPvsADT/CookOOPvsAD...

explained here: https://link.springer.com/chapter/10.1007%2F978-1-4612-6315-...

Post reply on HN