> This meant Lucene was less concerned with things like MVCC, ACID, and 3-NF, and was instead concerned with much more practical concerns, like how to build a fast and humane interface for unstructured data.
I absolutely hate this attitude. Different use cases have different requirements. The author here appears to be dismissing any use case different than their own as not practical.
You can use Lucene and implement these types of features on top of it if they're important to you. I think what the author was trying to say was the Lucene contributors decided to focus on a certain thing and leave other implementation features up to people using the library.
Lucene gives you a lot of levers to control how it works and if you want to build a distributed, MVCC, ACID compliant datastore on top of it, you can. It's just not a concern of the library.
Totally agree. I have a hard time taking seriously a perspective on the merits of a data technology that is so dismissive towards concerns like MVCC, ACID, and normal forms. These have been foundational to data technologies for nearly 50 years at this point for a reason. To discard them as "impractical" indicates to me a severe immaturity of perspective.
I absolutely hate this attitude. Different use cases have different requirements. The author here appears to be dismissing any use case different than their own as not practical.