re: You Either Have It Or You Don't VIEW POST

re: My take is that he is making the point that in many systems your data is much like documents that don’t have a schema and that is well modelled by ...

This is a great answer, thank you. You're right, Clojure is well-suited to processing maps with varying keys, which by extension fits well with use cases like arbitrary unknown JSON.

It seems like the "antipattern to maintainablity" stance also only makes sense when taken in the context of this specific domain. Still controversial, but less so than the blanket statement.


What is interesting is that Rich made so many systems in C++ and one in C# and after 18 years came to the conclusion that types don't help at all and that the examples of where they help are contrived.

Back when I started OO was the big new thing over procedural. It is still the orthodoxy. Yet more and more people are coming to the the conclusion that class hierarchy polymorphism only helps in very narrow places and hurts maintainability. I worked on several large Java systems with dozens of developers and now agree that classes are over used and abused on the typical business apps I worked on. The last large scale multiple dev team system I worked on was written in Scala and found that algebraic types, pattern matching, lexical scoping and functional programming was much better for maintainability.

I have come to the conclusion that the examples where class hierarchy helps are contrived. Yet as a grad student I taught OO as the orthodoxy and I completely bought into it. The fact that Rust and Go doesn't have that class hierarchy based polymorphism and JavaScript only recently introduced classes fits with my experience that people have quietly moved away from the orthodoxy and more great software is being written as a result.

The talk by Rich suggests to me that I should be more open minded about types in general being over-applied much like I have come to appreciate classes were over-applied.

code of conduct - report abuse