aubeynarf

That’s its uninitialized position, I believe

I guess, as a Scala enthusiast, it’s second nature to me - Scala incorporates immutable-by-default into its design so there are accommodations for it (.copy() methods on case classes, well-thought-out operators and methods on collections, “val” bindings, expression-oriented syntax).

It also lets you have normal OO classes and mutable vars anytime you want them, so you’re not stuck in a corner like you may sometimes be in Haskell if you don’t know the applicable FP pattern.

This helped me out quite a bit in a recent programming test for an employment screen – the challenge was to implement a time based key value store. One of the requirements that was revealed was that it needs to be able to back up and restore – this was as simple as storing the current root of the data in a list or map; it is effectively a snapshot.

it’s not radical, it’s just a guarantee that if you hold a reference to an object, it won’t change state under you. It’s a bit like every object has MVCC and copy-on-write semantics built in.

It’s easy enough to edit the object, producing a new copy, and then explicitly store it back where it goes or send it to whatever consumer needs it.

jeez dude you’re carrying a lot of baggage

Can you briefly describe how you’d fit the two together?

I always wonder about the people who describe calling out Russia’s dirty tricks and non-stop toxic behavior as “Russophobia”

You haven’t really thought through this have you

Or pragmatic functional programming, or rediscovered by “OO” programmers who realize they are messing up the Redux store bad.

Check my top level comment and several other replies on this post.

One I’ll mention here is “Tasks for testing and refactoring”. “Task” is the key word - testing and refactoring isn’t a backlog item that the product manager gets to deprioritize. (haha, like the product manager even realizes they are supposed to manage the backlog). It’s part of ongoing continuous codebase improvement and done whenever and wherever it’s needed.

I’ve been a software developer since 1997, I’d love to have a beer and shoot the shit with them!

I have not used that GORM, but ORMs have those problems generally.

I don’t see any ban of accountability, refactoring or debugging, coordination, or endorsement of screaming.

I recognize most of these as specific antipatterns that get adopted because some manager read a blog or no one actually had a clue was “agile” meant.

Groovy’s ORM? I recall it being Hibernate under the hood and I had to fight with it to avoid common problems like hidden IO and N+1 query blowups (iterating over a set of results and then touching the wrong property means you are making another network call for each), learning its particular DSL for schema definition and associations, and not having a way to represent any but the simplest SQL constructs. The usual ORM stuff.

To the extent that you can write a syntax-checked SQL statement and it deserializes the results into some collection of row objects, it’s fine. But that’s not the “ORM” part.