garethjrowlands

Quite so. I was just trying to make some small suggestions on how to handle the consequences of making that object immutable.

Here are some links along the same lines:

* _Aggregate Roots_ in DDD limit pointers, https://martinfowler.com/bliki/DDD_Aggregate.html * Guidance on where to mutate, _Functional core, imperative shell_, https://www.destroyallsoftware.com/screencasts/catalog/funct...

> using immutable object doesn't make all your problems go away, it makes them different

Yes, and here is a concrete example of the kind of 'different' problems you get: nested immutable structures, say `a.b.c.d`, become harder to update than simply `a.b.c.d = newValue`. The functional solution for this is 'lenses' (and other 'optics'). My favourite Kotlin framework that I use in my day job provides lenses for HTTP - URL query parameters, request and response bodies and so on - which work very well.

Unix pipes don't do stream fusion, which is the optimisation to which he was referring.

For those that didn't know, Haskell does of course have list comprehensions:

    [x| x <- foo, not (elem x y)]

Here's an example finding consonants:

    [c| x <- ['a'..'z'], not (elem x) $ "aeiou"]

Not really. In the example, function composition, `.`, joins the functions together.

You can smash a list of functions together but they'd all have to take and return the same type, and the list would introduce commas and square brackets, so it wouldn't look quite the same.

Creating a new value only gives you a stale data problem if you had pointers to the old value. You don't have to have pointers like that, it's a choice.

To take an obvious example, you might load a value from a database (company or employees, say), create a new value (with the higher salary, say), then write the new value to the database.

This paper describes the differences between objects and ADTs, https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...

Maybe try to aim for functional core, imperative shell, see https://www.destroyallsoftware.com/screencasts/catalog/funct...

Dropwizard was amazing when it came out and is still much better than deploying to Tomcat, say. But it's showing its age and I'd consider it too frameworky these days. My current currently preference is http4k, which is more library and less framework. Admittedly, that's Kotlin and thus not a fair comparison, but then, newer things can take advantage of other newer things.