Are the two DBs comparable feature-wise? Would you have been able to develop your DB before the old one with the same outcome?
Can someone else understand your code as well?
You can write super tiny code in an OO language too, but noone would be able to decipher it. (I once got a project like that ...)
I've seen small functional codebases. They were smaller because like in a typical java project you have 1000s of lines of code defining DTOs, entites etc. Guess what, the functional projects just didn't have that. It was all some generic form of lists and objects being passed around - pure guessing, no proper autocomplete etc.
I hated it. It felt so unproductive.
Yes. The older one has some data import functionality that the new one doesn't have, but this is a very small area of the code base. Most of that functionality was provided by 3rd party tools.
No. It was my years of experience that got me to where I am. I would not have even thought that I could attempt such a thing on my own if I didn't have that experience. On the other hand, it was only a FP language that gave me the confidence to try. OO would either lead to state complexity. Alternatively, if I took an FP approach in an OO language, it would come with performance concerns with functional structures that aren't implemented as well, and a constant battle with language idioms and syntax that was not designed for FP (I've done this with some success, but it's pushing uphill)
The new code is significantly easier to follow, and several people have. It took 3 weeks of training to do a handover of the previous database code (I did one of those weeks, and 2 other colleagues did the other 2 weeks)
You can try to compress your code in any language. I could have done that in FP too, but clarity, maintainability, and extensibility were all primary concerns.
The definitions in Java are verbose with little benefit. Scala can offer the same with less boilerplate. Generic lists, maps, etc, offer a lot of power if you have a lot of functions that operate on those few structures (and a good FP language will have this). But you also have the choice of describing structures for compilers in performance critical code. My own DB code has a lot of datatype descriptions, so even when simple things like vectors are passed around, they have to meet conformity constraints. These apply during compilation (so that correct types are passed), and testing, but are removed from runtime code for performance.
I did feel less productive in my earlier days. But this shifted over time. It's the complete inverse for me now, and that's despite having 20 years of OO experience.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Are the two DBs comparable feature-wise? Would you have been able to develop your DB before the old one with the same outcome?
Can someone else understand your code as well?
You can write super tiny code in an OO language too, but noone would be able to decipher it. (I once got a project like that ...)
I've seen small functional codebases. They were smaller because like in a typical java project you have 1000s of lines of code defining DTOs, entites etc. Guess what, the functional projects just didn't have that. It was all some generic form of lists and objects being passed around - pure guessing, no proper autocomplete etc.
I hated it. It felt so unproductive.
In order:
I did feel less productive in my earlier days. But this shifted over time. It's the complete inverse for me now, and that's despite having 20 years of OO experience.