5 ms·

I note that every advantage of OOP you cite is a modularization feature (even subtyping, since OOP basically conflates modules with types). Clearly you are not

I note that every advantage of OOP you cite is a modularization feature (even subtyping, since OOP basically conflates modules with types). Clearly you are not entertained by rants based on my experiences, so maybe I should just cut 'n paste pg: "Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations. (See Greenspun's Tenth Rule.) Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway. Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work." http://www.paulgraham.com/noop.html http://www.paulgraham.com/noop.html

barrkel 17y ago
Modularization is independent of programming discipline; you can have modules in procedural programming, OOP, FP, etc. I didn't argue that OOP is exciting, just that it is not a conspiracy perpetrated by a business elite to reduce the productivity of the average programmer. And appeal to authority won't work on me, sorry. FWIW, I think pg goes too far in his rant - I think he mistakes a certain strand of Java enterprise development in large corporations for all business OOP. The programming languages I use most often outside of C - Delphi (I maintain the compiler, written in C) and C# - both support closures, and of course C supports textual macros. As a compiler engineer I'm not oblivious to the fact that code is data and vice versa: turning code into data, and data into code is my meat and potatoes, as is symbolic manipulation of code trees (I implemented Delphi's closure support). But there's a downside to treating all the world as a list, and building all your structures out of conses: lack of documentation, encapsulation, machine checking. These things matter when you're trying to build an economy of software modules in a closed source world. In my own past in business development, I even used call/cc for certain web client / server dialog scenarios, using a DSL especially built for GUI data binding and events over an AJAX protocol. Assuming that all, or even the majority, of business developers are inefficient bumblers performing make-work is foolish, insulting and extremely myopic.
- toadpipe 17y ago
  Modularization is indeed independent of programming discipline. That is basically my point. Breaking a program down into the correct components is all-important, but most of this happens well below the module level. Unless the system has been over-engineered to death, as OOP encourages. Three cheers for not being swayed by appeal to authority, but I'm curious about what you think counts as "business OOP" that doesn't count as "enterprise," as "enterprise" seems vague enough to encompass pretty much anything. Your critique of lists and conses is again centered on the notion that documentation and encapsulation should be done in code and enforced by the machine. These things may well be necessary to build an economy of software modules in a closed source world, but the original article is just one example of the brain damage that this sort of world creates. I'm glad you've been exposed to functional concepts, and I don't think that business developers are idiots, but I do think they live in an environment that is by and large toxic to good programming practices. I'm not paranoid, I just see a lot of evidence for the validity of Conway's Law.

barrkel 17y ago

Modularization is independent of programming discipline; you can have modules in procedural programming, OOP, FP, etc. I didn't argue that OOP is exciting, just that it is not a conspiracy perpetrated by a business elite to reduce the productivity of the average programmer. And appeal to authority won't work on me, sorry. FWIW, I think pg goes too far in his rant - I think he mistakes a certain strand of Java enterprise development in large corporations for all business OOP. The programming languages I use most often outside of C - Delphi (I maintain the compiler, written in C) and C# - both support closures, and of course C supports textual macros. As a compiler engineer I'm not oblivious to the fact that code is data and vice versa: turning code into data, and data into code is my meat and potatoes, as is symbolic manipulation of code trees (I implemented Delphi's closure support). But there's a downside to treating all the world as a list, and building all your structures out of conses: lack of documentation, encapsulation, machine checking. These things matter when you're trying to build an economy of software modules in a closed source world. In my own past in business development, I even used call/cc for certain web client / server dialog scenarios, using a DSL especially built for GUI data binding and events over an AJAX protocol. Assuming that all, or even the majority, of business developers are inefficient bumblers performing make-work is foolish, insulting and extremely myopic.

toadpipe 17y ago
Modularization is indeed independent of programming discipline. That is basically my point. Breaking a program down into the correct components is all-important, but most of this happens well below the module level. Unless the system has been over-engineered to death, as OOP encourages. Three cheers for not being swayed by appeal to authority, but I'm curious about what you think counts as "business OOP" that doesn't count as "enterprise," as "enterprise" seems vague enough to encompass pretty much anything. Your critique of lists and conses is again centered on the notion that documentation and encapsulation should be done in code and enforced by the machine. These things may well be necessary to build an economy of software modules in a closed source world, but the original article is just one example of the brain damage that this sort of world creates. I'm glad you've been exposed to functional concepts, and I don't think that business developers are idiots, but I do think they live in an environment that is by and large toxic to good programming practices. I'm not paranoid, I just see a lot of evidence for the validity of Conway's Law.