Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The OO patterns are still quite popular in enterprise software, where people mostly work in large teams. Hiding implementation details is terribly annoying for a single developer, but can be a great way to reduce complexity for other team members.

The same consideration applies to other powerful constructs, such as static typing, garbage collection, operator overloading, and macros.

Whether you work alone or in a team can significantly influence how one appreciates such features.



There’s nothing stopping you from hiding implementation details in a functional paradigm, no need for objects or other OO patterns.


I could certainly be wrong, but that doesn't seem to be the case to me.

When you completely separate routines from the data, you end up coupling the code that calls the routine with the data it’s passing. I don’t see how it would be possible to maintain that level of separation while achieving the same level of isolation that’s possible with objects, where it’s possible to truly know nothing about the data in a given interaction.

I’m referring here to the purest aspect, in terms of pure functions. At some point, the data has to come from an impure source, and honestly, I don’t see why a closure would be better than an object—practically, they’re the same thing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: