> This seems like you might have got caught in something of a tautological loop situation that because you were working in a language with "object layers" it seemed easiest to work in one, and thus work with an ORM.

I mean, I think this is likely the case. So, I tried this, for example in Go, which is not really a proper functional programming language as I understand it, but is definitely not object-oriented.

So for my use case, I wanted to be able to take a database schema and programmatically create a set of CRUD endpoints in a TUI. Based on my pretty limited knowledge of Go, I found this to be pretty challenging. At first, I built it with Soda / Pop, the ORM from Buffalo framework. It worked fairly well.

Then I got frustrated with using Soda outside Buffalo, and yoinked the ORM to try and remove a layer. Using vanilla Go, it seems like the accepted pattern is that you create separate functions for C R U and D, as you referred to. However, it seems like this is pretty challenging to do programmatically, particularly without sophisticated metaprogramming, and even if you had a language which had complex macros or something, that is objectively significantly harder than object.get() and object.save().

Finally, I put GORM back in, and it worked fine. And GORM is a nice library, even though I think having an ORM is not the "Go" way of doing things in the first place. But also, Gorm is basically using function magic to feel like OOP. And maybe the problem with this idea is that it's not "Proper Go" to make a thing like this, it would be better to just code it. There's an admin panel in the Pagoda go stack which relies on ent ORM to function as well. I can only assume the developer motivations but I assume they are along the same lines as my experience.

I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.

In the real world, in business logic, objects do things. They aren't just data structures.

To summarize, CRUD seems pretty easy in any language, programmatically doing CRUD seems super hard in FP. Classes make that a lot easier. Maybe we shouldn't do that ever, and that's fine, but I'm a Django guy, I love my admin panels. Just my experience.

> I certainly don't think any of this requires insane class inheritance, and maybe that's all people are talking about with OOP. But I still think methods go a long way in this scenario.

Methods at all make a language OOP. Class inheritance is almost a side quest in OOP. (There are OOP languages with no class inheritance.)

Go seems quite object-oriented to me. I would definitely assume it is easier to use an ORM in Go than to not use an ORM.

I don't use a lot of Go, so I can't speak to anything about what the "proper Go" way of doing things is.

I could try to describe some of the non-ORM, functional programming ways of working with databases as I've seen in languages like F#, Haskell, or Lisp, but I'm not sure how helpful that would be to show that CRUD is not "super hard" in FP especially because you won't be familiar with those languages.

The thing I'm mostly picking up from your post here is that you like OOP and are comfortable with it, and that's great. Use what you like and use what you are comfortable with. OOP is great in that a lot of people also like it and feel comfortable with it.