2 ms·

This has been posted on HN multiple times before, invoking little discussion if any. Author does nothing of interest. Writing lots of boilerplate and then figu

This has been posted on HN multiple times before, invoking little discussion if any. Author does nothing of interest. Writing lots of boilerplate and then figuring out how to reduce it seems wasteful. And calling the alternative to his approach OOP would be a false dichotomy. You can do the same with much less mucking around with boilerplate by creating data classes first and business logic classes later. In Delphi you have best of both worlds. You can create a form and when you inherit from it, you can re-arrange all the UI elements and add more to your liking. If inheritance means "I want to reuse these properties" OOP works well.

SmooL 8y ago
"Writing lots of boilerplate and then figuring out how to reduce it seems wasteful." "You can do the same with much less mucking around with boilerplate by creating data classes first and business logic classes later." That's exactly what the author is trying to argue against. The authors point is that because business logic changes, and that because you can't always be omniscient, it's hard to write the correct abstractions the first time. So although it sounds wasteful to write boiler plate and then abstract, it's less wasteful than abstracting, then coding, and then later having to change it all because you got it wrong.