Hacker News Reader

Comment by LAC-Tech | Hacker News Reader

I'm not sure how I feel about this.

If you look at my code in "multi-paradigm" languages like typescript, there's not a heck of a lot of loops, mutations or side effects. I like expressions, and immutability, and higher order functions. They make things shorter and means there's less state for me to keep track of - or screw up.

But at the same time, I like objects. Almost all of mine are immutable. I went through a phase of using plain old data + a collection of functions that transform them, but found a good object where all of that was self contained simplified things a lot.

I also have to say that sometimes FP programmers don't seem to understand OOP a lot. I'm of the opinion that working on an old school opinion that a legacy Java codebase doesn't really make you an expert on OO.

So while I'm glad we're thinking about purity, and avoiding side effects, I'm kind of sad that there's an object backlash. They're fantastic contstructs.

View on HN

With immutable objects, aren't you just left with syntactic sugar around structs and functions? I'm picturing CLOS, which is undoubtedly an OO system but lacks 100% of what you use objects for. Are there languages which let you use dot-syntax for "methods" which just wrap normal functions?

What does CLOS lack that you want from an OO system?

Nothing! I mean I personally just use defstruct unless I want inheritance, but that's certainly not because CLOS lacks anything. I meant "you" as in the person I responded to, who wants immutable data structures with tightly coupled functions. It's because CLOS is among the most object oriented systems I know of that I used it as an example; there seem to be some basically orthogonal traits which nonetheless wind up highly correlated, and CLOS is the purest OO you can get this side of Smalltalk while looking different from what you see in Java or whatever.

With immutable objects, aren't you just left with syntactic sugar around structs and functions?

Yeah I've gone down this thought experiment. Conclusion I came to is that while you could view it that way, there's something powerful about Just Having One Thing, not structs + functions. It's almost a mindset shift as well, like you're requesting the object to do something and don't care how.

Are there languages which let you use dot-syntax for "methods" which just wrap normal functions?

Yeah, Dlang has that.

https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

> It's almost a mindset shift as well, like you're requesting the object to do something and don't care how.

I definitely see what you mean, a lot of FP encourages very general abstractions rather than something domain specific. That being said, I think Elixir has a pretty good handle on using functions as sort of black-box interfaces you can change later. Not sure if that's a language thing or a culture thing though.

> Yeah, Dlang has that.

Ooo, that's really nice. Super simple but a definite improvement to readability. Reminds me of |> in Elixir (or ~> in Clojure), particularly the chaining part. It clicks differently though, and definitely makes things readable for many programmers. Now that I'm writing this out, doesn't Rust have something like this? Like functions strapped right to a struct?

I suggested this wonderful feature to julia but it was rejected:(

Glad to hear D has it.

as OP said it would make functional languages more ergonomic (especially for OO folks) and most importantly enable code completion!

There already is a syntax for that: a |> bar |> foo

neat, thanks!

it's still a bit unergonomic to type but a very useful beginning!

Reminds me of hurting my fingers in c where you had to type '->' instead of '.' !

Haskell[0]? Idris2[1]?

[0] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4532#not...

[1] https://idris2.readthedocs.io/en/latest/reference/records.ht...

At that point you're left with two benefits: 1) Organizing your codebase so that it is easy to find which functions operate on which data 2) Controlling access to those methods on the programming language level. I.E, TankerService is the only class with Tanker instances and therefore the only part of the code with access to those methods.

Dynamic dispatch is really what differentiates OO from just being syntactic sugar around structures and functions.

Koka has that [0].

a.f(b) == f(a, b)

[0]: https://koka-lang.github.io/koka/doc/book.html#sec-dot

The problem with state in objects is that in more complex systems you often need to change a bunch of related state at one time. When it's all bound up in individual objects that manage their own state this becomes very complicated.

Sorry, I don't get what how that's harder.

    newData = f(oldData)

    newObject = oldObject.f()

Furthermore, it chains nicely and offers pleasant autocompletion in your IDE:

    newObject = oldObject.f().g().h().i().j().k()

    newData = k(j(i(h(g(f(oldData))))))

Just to steel man the "Functions and Data" side of the equation in a lot of FP languages that'd be something like

    newData = oldData |> f |> g |> h |> i |> j |> k

And to straw man the OO way a little...

newData = oldData.f().g().h().i().j().k()

wont work by default unless you also happen to return the object after every method (builder style) which looks weird and is not standard

I don't know what you mean. You can return a different type, the only constraint is that the methods don't return void and the subsequent method exists. This has nothing to do with the builder pattern.

You still have to do work though, to ensure, that always some fitting object with the correct methods is returned, so that you can chain further. Functions by definition (as opposed to procedures) return something and as long as that is the correct thing or type of thing for the next function, all is fine.

You don't have to do work; at any step you have the functions available that operate on the object returned (whatever it is). On the "Functions and Data" side you are similarly constrained by the possible functions that operate on that data.

What I meant by "work" is, that inside your methods you have to return an object, which has the method, which is the next thing in your a().b().c()... chain. Often in OOP you would not return the object itself, unless you do the builder pattern. Of course you can return other objects, if it is intended, that the chain has a call to a method of another object next. However, you may only call methods of the returned objects and you must return objects.

In the function and data scenario, all that needs to be made sure is, that your functions have the return type, which the next function expects, otherwise it is a type error, regardless of whether the language complains or not. A function call chain implicitly assumes the types to be correct, otherwise you will likely run into an error.

The difference is, that in the functions and data scenario, you already have functions, which take data of some type and return data of some type. You do not change them in any way, while on the other hand with objects and methods you need to change the methods, so that they do return some fitting objects.

There's no law stopping you returning a new object from a method outside the builder pattern.

Immutable objects are a pretty old idea, smalltalk had select (map) methods that returned a whole new collection back in the 80s.

...and in fact most strings in OOP languages work like this:

    String next = original.substring(2);

this has nothing to do with OO, function chaining depends on the output of the previous function regardless

Chaining is one way of making function composition more ergonomic, but there are others. Functional languages tend to have an operator (e.g. |> in Elixir. Think x |> f() |> g() |> h() |> i(), etc.) that gives the same benefits of chaining, but the functions don't have to be methods providing greater flexibility.

You can have the chaining syntax without object-orientation, like in Nim, D, Koka, VimScript, …

Right that's one object. Often you need to change the state of a bunch of related objects in a transactional way. The way redux works for example. It's somewhat analogous to database transactions.

Not sure what you mean here. Redux changes the state of one piece of data - the thing inside the redux store. Really not hard to imagine that with one big object in the exact same fashion.

I’m not a functional programmer by trade, but I think you’re alluding to (and should reframe your argument to discuss) concurrent reads and the implications of immutable data in a multithreaded scenario. It’s about simplifying your programs state machine. If I have some object A in an OO world, some N threads may act on said object concurrently resulting in some degree of non-determinism for any function of A. In FP, as I understand it, this is mitigated as you’re not dealing with mutable data structures but immutable objects whose data is consistent over the lifetime of any logical operation. Effectively, you just need to deal with conflicts on writes which you can design for.

This is just a side effect of functional programming but such behavior can be embedded into and made a fundamental part of your foundational data structures in an OO program.

Can I make a stupid example? Lets assume you got some building with people inside. One person exits the building. mybuilding.leave(person) or so. What does .leave(...) do? Ah, it needs to reduce the counter of people in the building by 1. Oh and by convention this means, that the person is checking out, so lets update their schedule to account for that. Ah they are also currently "out of office". Ah and the person at the door, who keeps watch has now seen another person leaving. Maybe the person went through a scanner. The scanner statistics need to be updated.

And so on and on. All kinds of objects need updates for their states. You need to direct all this stuff, without forgetting things. Otherwise the state of your objects will become inconsistent and at some point it will show as some kind of bug. At that point you might find yourself debugging the whole thing, to find out when the inconsistency starts or what causes it.

No need for multiple threads or any of the kind. Complications from splitting the state up and parking it in various objects and having to tell the computer how to update these objects. Instead of looking at 1 function at a time, which only works on its inputs and gives an output, you have to remember to call all the appropriate methods across some reasonable part of your entity landscape.

If you have a bunch of related objects that need to change together in a particular way, encapsulate them in a bigger object and offer methods that return the new, different bigger object.

Depends on the problem. Sometimes the locality of every state inside the function you write is beneficial, other times it makes it much easier to just not care about the state of a given thing, and let the encapsulation do its job. I just want to use it as per its contract.

Reply on news.ycombinator.com