H2CO3 · August 30, 2015 05:40
diff --git a/comment-711484 b/comment-711484
 > Object Oriented Programming (OOP) as an idea has been oversold. […] Extremist languages like Java force you to think of everything in terms of objects.

 Yes, OOP has been oversold. But that’s not the problem of OOP; that’s the problem of incompetent programmers who are trying to use one tool for everything. Of course what Java doing is extremism too (also, see the amount of incompetent programmers in each language… Java is considered an “industrial” language, so it’s perhaps only C and C++ that have more utterly incompetent users than Java; people just want to be rich.) But nobody said you have to use Java! In fact, I think you should not use Java. Having to write an entire class just to possess a main function? Stupid! There are better languages that support OO yet don’t *force* you into the OO mindset, e.g. Objective-C or C++.

 > State is not your friend, state is your enemy. Changes to state make programs harder to reason about […]

 Except when it’s the declarative approach that’s harder to reason about. Which one is easier to understand, printf or the IO monad? If you want to write a non-trivial (!) database query, wouldn’t it be easier to understand a procedural program written in your own favorite language than a highly convoluted SQL statement?

 > Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands.

 Again, that’s not the problem of OOP, that’s the problem of design patterns. Just like you don’t have to (and shouldn’t) use Java, you don’t have to (and mostly you shouldn’t) use these “design patterns” either. Most of the time, they turn out to be artificial constraints on the implementation, taking away the programmer’s freedom and creating code bloat. They make things overly complex (e.g. disguise verbs for nouns, as you pointed out), and that’s where the problem lies.
	> Object Oriented Programming (OOP) as an idea has been oversold. […] Extremist languages like Java force you to think of everything in terms of objects.

	Yes, OOP has been oversold. But that’s not the problem of OOP; that’s the problem of incompetent programmers who are trying to use one tool for everything. Of course what Java doing is extremism too (also, see the amount of incompetent programmers in each language… Java is considered an “industrial” language, so it’s perhaps only C and C++ that have more utterly incompetent users than Java; people just want to be rich.) But nobody said you have to use Java! In fact, I think you should not use Java. Having to write an entire class just to possess a main function? Stupid! There are better languages that support OO yet don’t force you into the OO mindset, e.g. Objective-C or C++.

	> State is not your friend, state is your enemy. Changes to state make programs harder to reason about […]

	Except when it’s the declarative approach that’s harder to reason about. Which one is easier to understand, printf or the IO monad? If you want to write a non-trivial (!) database query, wouldn’t it be easier to understand a procedural program written in your own favorite language than a highly convoluted SQL statement?

	> Very few real world OOP programs even consist entirely of nouns, they’re filled with verbs masquerading as nouns: strategies, factories and commands.

	Again, that’s not the problem of OOP, that’s the problem of design patterns. Just like you don’t have to (and shouldn’t) use Java, you don’t have to (and mostly you shouldn’t) use these “design patterns” either. Most of the time, they turn out to be artificial constraints on the implementation, taking away the programmer’s freedom and creating code bloat. They make things overly complex (e.g. disguise verbs for nouns, as you pointed out), and that’s where the problem lies.