Comment by marcosdumay | Hacker News Reader

Comment by marcosdumay | Hacker News Reader

Parent Full thread

> As a total beginner to the functional programming world, something I've never seen mentioned at length is that OOP actually makes a ton of sense for CRUD and database operations.

That's because you are wrong. There's nothing in relational databases mapping that make objects a better target than even the normal data structures you see in functional languages.

> In my case, I wanted to do CRUD endpoints which were programmatically generated based on database schema.

What is a pure transformation.

The problem is that CRUD applications are an incredibly bad explored area. There only mature projects out there are the OOP ORM ones. That's not because OOP is inherently better suited to the application, it's because there's simply not a lot of people willing to risk into working at that problem.

(And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK. Mine is certainly because I know if I built an amazing system, nobody would come.)

> What is a pure transformation.

I don't know! Can you explain it, or how I would use it for this application?

> And the reason people are not willing can be because developers don't choose their tools through rational evaluation, or may be some irrational one IDK.

I think "do the tools exist in the world" is a pretty rational evaluation. I'd love to see the FP equivalent!

> I don't know!

A pure function is a function whose output only depends on the paramters and not has any internal state. Which in my opinion is a somewhat useless distinction, because you can make your state/instance/whatever the first parameter, (what C and Python do) and tada, every function that doesn't use globals (or static in C), is a pure function.

Is that distinct from a pure transformation?

A pure transformation is an abstract operation, a pure function implements it.

a pure function doesn't have side effects. it doesn't read from nonlocal state or trigger distant changes nor perform any manner of io.

a pure function doesn't change its inputs, it simply uses them to craft it's outputs.

bringing in an object or function via parameter to perform these side effects still leaves the function impure.

I agree that a return type and a parameter are quite different things in a specific implementation, but on an abstract level, they are basically the same and there is now reason to distinguish between output parameters and the return value other than due to language syntax.

I don't see how mergeing an input and an output parameter to a single in/out parameter makes any difference, other than making it inconvenient for the caller to keep the old state around, which is often what you want. The fact that the callee than can derive the new state from the old state by only specifying the changed values does not fundamentally change anything and is only convenient for the implementation.

Reply on news.ycombinator.com