Hacker News Reader

Comment by carsongross | Hacker News Reader

The key word there is gigantic not OO.

All gigantic systems are crappy, no matter what their underlying language/paradigm is. Slightly less crappy is a win.

The problem is that OO thinking tends to inflate systems, spreading code all over the place even though it logically belongs in one place and adding object wrappers to things that don't need it. In my experience taking over Python code written by Java developers, I can usually shrink their OO code and make it more reliable by refactoring it into conceptually equivalent functional code wherever it makes sense and falling back on procedural style where appropriate.

In my experience I'd guess you aren't dealing with a deficiency of OO, after all Python is an OO language.

I'd bet you are dealing with over-engineering, which is a cultural issue within the Java/J2EE community. And perhaps a lack of closures (I prefer those over list comprehensions, since they are more general) which make java needlessly verbose.

Languages are not inherently OO or FP, but they support OO or FP style programming. Python supports procedural programming very well, you'll see lots of "def" and no "class". If you argue that the integers and strings manipulated by a procedural Python program are called "objects" and therefore it is still OO, I shall point you to the C standard which indicates that the integers and strings in a C program are also called "objects".

You can do procedural programming in Java, but you'll have to make all of the functions methods on some dummy class. This is cumbersome, which is the real complaint here. The "everything is a class" mentality is both an issue with the language and an issue with the community, but we tolerate it because they still make useful programs.

Everyone needs a little "re-education" or assimilation in order to switch languages and not write puke-tastic code in languages you don't use every week. A seasoned Java programmer will likely have no trouble writing correct Python code, but you have to wait for a few dozen sleep cycles before the programmer will write idiomatic Python code.

I agree, but I do think that java, in particular, suffers from two distinct problems:

1) A lack of closures, which, as you point out, turns every obviously functional problem into a ridiculous object model.

2) A culture that creates libraries that suffer from over-abstraction, over-engineering and that tend to model a technical aspect of a problem rather than what a non-expert end user of the library would find intuitive.

> Languages are not inherently OO or FP, but they support OO or FP style programming.

I couldn't disagree more. Languages are as they are designed to be. Erlang is FP and Java is OO by design.

If you trying to write FP in Python - you're in trouble. (Python is my main language for several years)

It does not have "mandatory OOP" but it remains as mainly imperative OO-language with some FP-goodness. C# is the same, Java - not.

If you try to do your entire program as pure FP then I guess that is true, but it's often possible and beneficial to do a lot of the work in a functional style.

Honestly though, this misses the point. If your language forces you to use an unsuitable paradigm, it's time to use another language if you can.

The solution to gigantic systems are APIs, whether services or objects. Using FP you end up emulating objects, just at a different scale.

Reply on news.ycombinator.com