jfsurban · September 3, 2012 03:31
diff --git a/fp-vs-oop b/fp-vs-oop
 The original vision behind OOP wasn't at odds with functional programming. In fact, it looks more like modern FP than modern OOP, with its FactoryFactories and POJOs and cargo cult bullshit that are more an artifact of a failed attempt to commoditize programming talent (one which hijacked OOP) than anything else.

 Pure functional programming is great. Alan Kay would agree. However, the world is stateful. The original inspiration for OOP was the cell, which encapsulates complex physical machinery (state and behavior) behind a simpler chemical or electrical interface. The idea wasn't that complexity is a good thing (it's not) but that, when it becomes inevitable, it needs to be sequestered so that it's only visible to the few who need to fuss with the object's internals, not to the many who need to interact with it at an API level only.

 An "object" is a complex entity whose interface is designed for simplicity. An example of this would be a SQL database. Query optimization is complex, but the interface is much simpler. You don't micromanage which indexes it uses and when; you just specify the query you want to run and trust the software to figure it out. In spite of its age, SQL is the most successful DSL ever invented, and for a number of reasons, but it's relative simplicity and flexibility are high among them. An added benefit of the simpler interface is that implementations can be swapped out without rewriting the entire interface.

 Where OOP broke horribly was when someone got the (wrong) idea that every program needed to be "object-oriented", and OOP went from a set of tools solving specific problems (e.g. GUIs) very well to a general-purpose programming paradigm, which became worse because it was so poorly understood. It evolved from a stance of "use objects when complexity requires it" to "use objects as the fundamental unit of programming", which is bad because complexity and uncertainty aren't inherently good, but undesirable all else being equal.

 Scheme is a better first substrate for programming than Java, because the fundamental building block of programming should be the referentially transparent function. Only when this is reasonably well understood should people be exposed to mutable state.
	The original vision behind OOP wasn't at odds with functional programming. In fact, it looks more like modern FP than modern OOP, with its FactoryFactories and POJOs and cargo cult bullshit that are more an artifact of a failed attempt to commoditize programming talent (one which hijacked OOP) than anything else.

	Pure functional programming is great. Alan Kay would agree. However, the world is stateful. The original inspiration for OOP was the cell, which encapsulates complex physical machinery (state and behavior) behind a simpler chemical or electrical interface. The idea wasn't that complexity is a good thing (it's not) but that, when it becomes inevitable, it needs to be sequestered so that it's only visible to the few who need to fuss with the object's internals, not to the many who need to interact with it at an API level only.

	An "object" is a complex entity whose interface is designed for simplicity. An example of this would be a SQL database. Query optimization is complex, but the interface is much simpler. You don't micromanage which indexes it uses and when; you just specify the query you want to run and trust the software to figure it out. In spite of its age, SQL is the most successful DSL ever invented, and for a number of reasons, but it's relative simplicity and flexibility are high among them. An added benefit of the simpler interface is that implementations can be swapped out without rewriting the entire interface.

	Where OOP broke horribly was when someone got the (wrong) idea that every program needed to be "object-oriented", and OOP went from a set of tools solving specific problems (e.g. GUIs) very well to a general-purpose programming paradigm, which became worse because it was so poorly understood. It evolved from a stance of "use objects when complexity requires it" to "use objects as the fundamental unit of programming", which is bad because complexity and uncertainty aren't inherently good, but undesirable all else being equal.

	Scheme is a better first substrate for programming than Java, because the fundamental building block of programming should be the referentially transparent function. Only when this is reasonably well understood should people be exposed to mutable state.