Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

> The OO craze has a part to play in this madness as well. More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit.

Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.

> Even today you’ll still find a strong bias towards OO courses being taught at the university level using Java, and the bias was certainly stronger 5 - 10 years ago.

Because that's what people use to write real programs.

> The engineers at Google working on Android are too busy architecting grand frameworks for solutions and not busy enough solving actual problems.

Because we all know, Google is known for hiring flakes who can't code or design real systems.

Worse is better means getting things done even if your tools kind of suck or your understanding of the problem isn't yet great. It leads to architecting and less than ideal solutions, but at least you ship!

View on HN

> OO actually works well for scaling complexity, much better than toy immutable functions do.

Sure, but the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled.

A low-hanging example of this is the singleton pattern, and the Wikipedia section titled "Example of use with the Abstract Factory pattern" saves me from having to bother making the point any further: http://en.wikipedia.org/wiki/Singleton_pattern#Example_of_us...

It is my fervent hope and wish that all programmers someday accept that there is no universal methodology, that FP and imperative and OO all have their place and their faults, and that it is OK to sometimes not use one of them somewhere.

If you get good at programming, you actually know when to apply these patterns (and many others not in the GoF bible).

And of course, I mix OOP and FP styles all the time, I'm not a purist by any means (a guy who does F# once commented on how FP my C# code looked).

> If you get good at programming...

This is a very important point (hopefully more "when" than "if"). I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

I'm really tired of seeing naive programmers throw the handful of design patterns they know at every problem, not because the abstraction is a fit, but because their toolbox simply doesn't have that many tools.

This is one of the biggest problems with Java — and other “pure OO”, “everything is an object” languages of the same style — particularly from a teaching perspective: when all you have is a class, every problem looks like an object.

If we present a language like Java as being the default, standard, safe option, how are new developers ever going to gain enough knowledge and experience to realise that their elaborate design with seven different classes in Java could have been replaced by a single 10-line function in Python, or a few short lines of Prolog, or a single query in SQL?

>the problem is that OO is frequently applied where you don't need scalability, and then OO becomes the complexity that needs to be scaled.

You nailed it. And, so did the author, with this:

>so often I find I’m reading code that looks more like a plan for something that solves a problem, rather than something that actually solves a problem.

Java--or perhaps the OO culture that came up with it, or perhaps the enterprise culture in general, or perhaps all three--does encourage a certain overengineering mindset. I am speaking as a recovered victim.

This permeates the entire culture. Remember when the Design Patterns books were first popular? Every Java dev was looking for a way to wedge in as many patterns as possible. There was a real sense that it was required to do development right. I think this (along with reading Java's APIs) is where Java devs began to fancy ourselves Architects Of Everything. You couldn't just solve a problem, no matter how simple. Instead, you had to develop something that could be infinitely extended or modified in the future. And, you'd better be sure that nary a public interface required updating if those future changes were necessary. Nevermind that you layered on extra classes, instantiated everything with a factory, and increased the initial complexity of using the code by orders of magnitude.

So, you were no longer solving a problem. Instead, you were architecting a flexible solution that could support solving the problem, along with every future variation of the problem you could conceive at the time. Then, you implemented your solution for the actual problem within this new, broader mini-framework you just created.

So, when reading this code, it's not uncommon to go through layer after layer trying to figure out where the actual work was being done.

But, the problem is that those future changes seldom came. So we were guaranteeing that our initial solution was overly complex and creating all of this baggage, while relatively infrequently redeeming that heavy cost in terms of avoidance of actual future pain that we imagined.

> Once real systems (like UI frameworks) are written with FP, we can compare apples to apples. Until then...wtf? OO actually works well for scaling complexity, much better than toy immutable functions do.

Seems like we are working on very different kinds of systems. Right now I'm working on Hadoop-based data pipeline. While Hadoop itself is mostly written in Java, many recent tools like Spark or Kafka are created in Scala instead. Yes, they still use some kind of OOP where necessary, but it works as a helper tool, not as principal paradigm. At the same time, ideas from FP are used extensively.

Do you consider Hadoop-based systems not "real"?

But ok, let's take something different. Python for example. Python with its main web framework - Django - is really shiny. I would say, it is one of the best web frameworks ever. What about OOP in Django? Controllers are just functions on module level, models are just "poor" records for storing data (no behaviour), ORM is singleton-based. So I would say it's procedural, not object-oriented, at least, not in Java sense. And still sites like Instagram or Washington Post use Django.

Do you consider Instagram not a "real" system?

Ok, maybe it's just web. Java was never good for web, actually. Let's take one another example area, say, scientific computations. Science is something that is really complex, right? Even simple statistical algorithm involves tricky numerical computations, optimization methods, probability models, etc. Matlab is good at these. R is good at these. Python (SciPy) and Julia are good at these. C and Fortran are not very convenient, but fast and thus used extensively. What about Java? Is Parallel Colt best possible choice? Not very impressive. Ok, maybe Matlab, Python, C, etc. are really good only for little experiments and are not really scalable? Hmm, have you ever wondering what software Mars Curiosity is using? It's 2.5 million lines of C code with tests in Python [1]. And nothing about Java or OOP.

So, do you consider Curiosity software not a "real" system?

I'm pretty sure Java is good for some sort of applications. I've heard a lot of good things about using OOP for UIs. But Java is not the only language used for complex systems, and UIs are not the only "real" kind of systems.

[1]: http://programmers.stackexchange.com/questions/159637/what-i...

> Python with its main web framework - Django - is really shiny. I would say, it is one of the best web frameworks ever

For small sites, maybe. Once the codebase gets large, it becomes much harder to maintain than a Java webapp of similar complexity written in a sane framework.

Intagram's website is small? Ok, so show me the large one written in Java. But let's agree: this should really be web site/web interface, not some back-end service in large distributed system like Twitter or LinkedIn, because in such systems there's a great mixture of the whole bunch of different languages.

So far list of websites written in what I used to think of "sane Java framework" (Spring Web) is not very impressive [1] compared to Instagram, Washington Post or Reddit.

[1]: http://spring.poweredsites.org/top

Really? I heard the same claims about Perl, but didn't see much evidence of it when I worked on a large Perl app.

What about OOP in Django? Controllers are just functions on module level, models are just "poor" records for storing data (no behaviour), ORM is singleton-based. So I would say it's procedural, not object-oriented, at least, not in Java sense.

Strongly disagree. The internals of Django are full of inheritance and mixins (a form of multiple inheritance), and so are the class-based views and the forms.

The CBV class hierarchy is complex enough that someone had to make this site to help everyone keep them straight: http://ccbv.co.uk/

If you only write FBVs and implement your own views and forms from scratch you can keep your code fairly procedural, but I would say that Django heavily [ab]uses the OOP features of Python.

> The CBV class hierarchy is complex enough that someone had to make this site to help everyone keep them straight: http://ccbv.co.uk/

It's funny how your comment compromises OOP - even in Django class-based views make things complicated :)

Anyway, I didn't mean that Django doesn't use OOP at all or forbids you to do so, but rather that it provides another approach (mostly procedural) and pretty successfully. Most people outside the OOP dome actually know that this paradigm is good for particular tasks. But what people under the dome don't know is that there are many other approaches that work not worse, and often even better than OOP.

For scientific computation, libraries such as JAMA or la4j performs much faster than scipy on matrix operations or common linear algebra operations : http://martin-thoma.com/matrix-multiplication-python-java-cp... https://code.google.com/p/java-matrix-benchmark/wiki/Runtime...

Sorry, but both of these benchmarks are terrible. First link compares run time of the whole programs, including start-up time, time for parsing file and printing out resulting matrix. I'm pretty sure matrix multiplication was the fastest of all these operations. I haven't read details of second benchmark (in fact, I've got lost in all these XXXFactories and couldn't find where things are actually happening), but I see no Python sources to compare with. So it's quite useless in this discussion too.

Also note, that performance was not the only point of my comment. In fact, my point was in simplicity of designing complex scientific systems. In Python you have excellent stack: NumPy + SciPy + Scikit-* + Pandas + Numba + Cython + Theano + Pylearn2 +... The list is endless, and all these tools may easily be used together. In R you have CRAN with everything you may ever be wanting. In Matblab you have a number of both - open-source and proprietary libraries. Julia community is also growing quickly. (Note, none of these libraries uses OOP as its primary paradigm.) And what about Java? Java has a little disjoint set of libraries that neither solve large set of problems, nor interoperate with each other well.

Actually there are "real systems" being written in FP e.g. Clojure @ SoundCloud.

They just aren't architected the same way. Instead of a monolithic WAR you end up with a series of micro services. FP is actually more suited than OO for micro services since it naturally forces developers down the "do one thing well" approach.

So I would stop with the "OO is what real people use" nonsense if I were you. Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space and you may find yourself on the wrong side of history.

> Because languages like Scala and Clojure are rapidly taking over from Java in the enterprise space

Let's see how much of the momentum these languages keep after Java 8. Default methods, the new stream API and lamdas provide much what most developers need without introducing baroque features and orthogonal infrastructure.

Doesn't change the point. It's called JAVA but with lazy streams and closures, everything Java culture built prior that will be moot and that's what the article is pointing at. Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ...

OOP is too verbose by it's essence compared to closures. I tend to see curried functions as anonymous objects (old lisp koans joke on their duality).

> OOP is too verbose by it's essence compared to closures.

Then CLOS is too verbose?

CLOS is a layer on top of CL, it's optional. Also, LISPs are as verbose as you want them too. If you identify boilerplate you macro it away. It's part of the culture. Some systems (php/symfony2, eclipse/emf) go out of their way to generate unnecessary temporary files, templates and such but it's still cumbersome.

To be honest, CL shows its age (mapc, mapl, do, dotimes, loop ...), more functional approaches like sml are very tempting, for the small size of their core in which you define all other patterns. I'd love to see a blend of lisp and ml (racket maybe?).

Talk about workarounds.

Lisp macros ? (first-class and generic, not bad for a workaround)

No, faced with the fact that CLOS is also verbose, although in a language that is all about closures, you started to present workarounds how to simplify its verbosity.

I don't find CLOS verbose. Private slots by default, accessors as option ... I find LISPs quite succint in general, sure lots of parens, but usually the bare minimum of information is required. This contrasts with the large amount of useless code you can see in Java class definition that amount to nothing (setting fields, toString, manual get/set).

CLOS is verbose if all you're doing is encapsulating some state. If, on the other hand, you plan on doing anything remotely interesting, it's very succinct and expressive. Trying to emulate the functionality of CLOS' multiple dispatch and mixins in Java or C++ is hell beyond hell.

As for verbosity, I'll take ":accessor foo" over methods "getFoo" and "setFoo" with inane, useless autogenerated comments any day of the week.

I find it very strange that you've thrown LOOP in there. It may not be as sexy as canned functional algorithms or simple recursion, but for complex algorithms, it's an absolute joy to use.

I couldn't count the number of times I've been writing C or C++ and wished I could express an idea more complex than "Initialize some variables (which may or may not be of the same type (but not of arbitrary different types)); run while this is true; do this thing after every iteration" without just slapping everything into and in the immediate vicinity of a while-true block. I don't have that problem with LOOP.

> OOP is too verbose by it's essence compared to closures.

Could you comment on Smalltalk's blocks?

I never used ST, I thought a block == closures, but according to http://c2.com/cgi/wiki?SmalltalkBlocksAndClosures there were differences until they wanted to make blocks real closures.

edit : I should have said closures + curryfication so you can partially augment the creation of a final callable entity that binds many parameters (similar to an object constructor arguments)

> Same thing happened in PHP land, people say PHP is great now, but what is PHP ? PHP5, which is a perlish javaesque thing ? or the regex craze html implicit template system that was PHP4 ? ...

Get the facts straight please.

As much as I don't like everything about PHP, PHP means PHP5 and it has been like that for a few years.

I'm talking about languages evolution. PHP5 got a Javaesque Object System, closures, generators. The idioms that will emerge will be close to other language with similar features, and what made php php is becoming less and less so.

PHP is actually the perfect example to disprove my point (pig with new lipstick). I'll reflect on that.

PHP is a funny thing, started very very low (https://twitter.com/agumonkey/status/488432654577303554), and nowadays it's got a lot of very positive improvements (linguistic features, faster interpreter, principled community). Who knows how long it will survive ...

If you think those features change anything then you must have a poor understanding of FP or why people are moving to Scala/Clojure. It is a fundamentally different way of developing code that is starting to look really appealing to the enterprise.

The iterative development with a REPL approach deployed with micro services lends itself well to Agile development where big bang architecture simply doesn't work.

I did the two FP courses from Mr. Odersky using Scala as the main language and then continued playing with the language for small experiments.

While the language is awesome in general, I would not recommend it at work.

Any particular reason you wouldn't recommend it at work?

As the author of this post mentioned the culture of the Java developers, the "architect" thing and the frameworks, Scala has its own similar problems: it attracts a group of academics on type systems and creates over-engineering in a completely different direction.

Also, while I think Scala is simple at its core concepts and syntax, it gets complex because it has too many features and tries to support all features present in other programming languages. Why do you want structural typing there?.

Also, I hated sbt.

> it gets complex because it has too many features and tries to support all features present in other programming languages

Which things do you have in mind?

> Why do you want structural typing there?

Isn't that a simplification? Instead of saying "here are types which you can use as e. g. parameter types, and here are types which you can't use (like in Java)", it says "all types work the same way".

I understand what it is.

I don't see the need of it if you already have a class-based system.

Go uses structural typing. But it is the only thing they have. Rust has traits, and it is the only thing they have.

I can't think now of more stuff but I remember you could even write xml in the language.

> I don't see the need of it if you already have a class-based system.

Like in Java?

    	new Object() { void foo() {}}.foo(); // Works

Ooops.

The point about XML is so stale already that I won't even bother commenting on it.

You seem to be stuck in the topic of how useful structural typing is. Which I agree with.

Eh what? No. I couldn't care less about structural types.

I care about simple, consistent rules. "X is a type, you can use it wherever you want" is one.

"X is a type, but there is also Y, which you can't really express in position A and B unlike X, but can only use it if you carefully avoid doing things #1 to #4" isn't one.

I agree with partly with you.

I don't think it helps for consistency when you have to ask yourself why some functionality is defined in terms of a trait if it could be defined in terms of the structural type and just providing the methods would be sufficient.

Oh, I also disliked implicit conversions a lot. I considered them a wart at some point. Made everything hard to read and reason about.

Almost every other way of "extending" a type would have worked better in practice eg. Xtend’s Extension Methods.

Extension methods have mostly the same drawbacks as implicits, but none of the advantages.

It's not like Scala developers didn't know extension methods before designing implicits.

Instead, they tried to come up with a more useful, principled way, which also covers a lot of the stuff which is hardcoded and implemented ad-hoc in other languages (like implicit conversions in Java).

In the end, I think they made the right call:

- Implicit parameters are the basis for abstractions which unify the "strategy pattern" of OO languages with FP's typeclasses,

- implicit classes provide extension methods, but are better in pretty much every regard (higher reusability, less error prone) and

- implicit conversions cover the ad-hoc conversions everyone takes for granted, without having to hard-code these hacks into the language (e. g. don't like Java's/C#'s/... implicit convert-everything-to-String conversion? Don't import it in Scala).

The secret of Scala is that it can be used in a wide variety of ways by a wide variety of teams. Yes, you can end up hiring people that would rather work in Haskell, or those that hate the type system and would rather code in Clojure. I've seen people that attempted to make Scala look like Java, or even Javascript. My current team, working in Scala, has had plenty of people like that. But the fact that you can get too academic with Scala does not mean you have to.

Some parts of our codebase really work better with said academic style, so we keep them. In others, the type system was used in ways that did not make any sense, and were rewritten.

Scala's strength is precisely that it can look like anything you want. If you are not interested in said freedom, then sure, avoid Scala at work. But for us, using the style that works better in each part of the system without actually having to change languages is extremely powerful.

I will steal that argument for D.

I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.

IMHO, D is a better teaching language than Python and a better systems language than Java. I wish Android was written in D. I can't enjoy using a language with significant whitespace or extremely forced OOP.

The core language is good enough already, and better than most. They way it defines functional purity is the way it will be taught in universities in the future. It also embraces concurrency, and this will only become more important as computers get more processors.

What it lacks is libraries, therefore you are right about point a. The lack of a library like Ogre3D is an issue. The lack of an equivalent to jdbc for D is an issue. That's the reason for me to mention D here, the more exposure it gets, the better.

But about points b and c, no way. You deliberatedly ignore the third compiler GDC, which integrates the open source D front end with GCC and produces faster binaries than DMD.

GCD is still maintained basically by a single person, who replaced another person that basically stopped contributing and resulted the project stagnant for some years.

I worked on Scala for two years seven or so years ago (2005-2007), and I'm not really worried about it (Scala is a great OOP language, and a soso FP language). Compared to Scala, Clojure has a minuscule user base (as one would expect for a Lisp).

Well there is an overwhelming trend towards Scala/Clojure both in the enterprise and for large internet sites. When companies like Twitter, LinkedIn, Foursquare, Netflix, eBay etc start embracing FP languages you can be sure the rest of the world takes notice.

My point was that serious companies are doing serious work with FP languages.

Scala isn't really functional, its more like a better Java that happens to include some FP abstractions (like C# does with Linq). Its actually a good OOP language, better than Java and even C#.

Clojure is a Lisp, its niche. There will always be some people around who want to program in a Lisp, and many of them are just choosing Clojure today. Nothing new really.

I'm a Clojure fan, and the syntax has nothing to do with it. The pervasive immutability, persistent data structures, ease of threading and STM mechanics are the good bits as far as I'm concerned.

The language could have a Python skin on it and still maintain much of what makes it pleasant to work in. I'd probably even prefer it.

Furthermore, the reaction to Clojure by the lisp community in general seems to be quite negative, like it's some inferior lisp that doesn't even have things like reader macros, and it makes no sense why it's getting traction when CL never did.

Which is all to say, I think the answer to what makes Clojure compelling is actually quite nuanced, and you're painting over it with a broad brush. Maybe with the wrong color.

It's unfair to call Scala 'not really functional'. Although I agree it allows for very rich OO programming, dismissing it as merely adopting "some FP abstractions" and comparing it to LINQ is bordering on FUD. To substantiate these claims, you have to at least give an example in which Scala falls short in being a functional programming language.

Interestingly, Scala's combination of OO and FP has given it (besides a lot of mockery and criticism) the title of a "postfunctional language".

Btw: I don't mean to pick on you, but you are talking a lot in absolutes on things I happen to disagree with in this thread.

I agree on that.

Many things considered the domain of "functional" languages these days, like typeclasses and higher-kinded types are supported in Scala.

Saying that Scala is 'not really functional' is more or less denying OCaml, F#, SML (in fact, pretty much every language except Haskell, Idris, ...) the status of a functional language.

F# at least pushes you into a functional style; its support for classes is just interop; this is as opposed to Scala, which really innovates on Java OO. OCaml is specifically OO (hence the O in the name), though with lots of functional features. SML and Scheme...are SML and Scheme. They don't fit nicely into OO or FP buckets.

Would you consider C# to be a functional language? It has lazy streams, generators, and good support for list comprehensions? Or is it just an OO language with functional features?

If you consider a language to be more functional, because it forces you to use functional approaches even where it produces an inferior solution, then F# will certainly win this comparison.

Just have a look at F#'s higher-order functions for collections to see what I mean.

I consider a language "functional" if it allows me to write good functional code. Scala supports that by enabling me to choose good object-oriented code instead of bad functional code where it makes sense. (There a certainly other approaches to enable good functional code.)

I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, dependent types and typeclasses.

(Note that I'm not saying that functional language need to support all of this. But a language which supports none of those items: I think we can make a clear call in that case.)

The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#). I can't, however, do that with F#, and believe me...I really want a Scala-like language for .NET so I can move on from C#.

> I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, dependent types and typeclasses.

C# has first class functions and has had them for a long time. C# also has real value types via structs, allowing more efficiency with FP styles, better than what Scala can provide on the JVM. Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.

Scala has better local type inference than C# (though non-determinstic...), but lacks global type inference like ML, Haskell. Scala also doesn't support general dependent types, settling for a much weaker (must still useful) path dependency. Path dependency is a very OO friendly feature, and in fact really amplifies OOP in general; whereas for FP, path dependency's benefits is limited to records.

> The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#).

So a language is automatically not functional, because other supported paradigms in that language don't suck?

So if OO in OCaml, F# wouldn't suck, they wouldn't be functional either?

> C# has first class functions and has had them for a long time.

I'd say C#'s functions are slightly better than Java's. The distinction between Action and Func is a terrible hack, and both of them are just a thin syntactic layer over delegates. Is that really first-class? They don't even provide function composition in the standard library.

> Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.

Bad luck for F#, I guess. Just ask them how much fun it is having to support two different kinds of Generics.

> Scala has [...]

As mentioned, that list wasn't a claim that Scala supports all of them (I think not even Haskell gets all the points).

> I really want a Scala-like language for .NET so I can move on from C#.

You can't have one because:

> Generics in C# are also reified, vs. erasure in Scala

The fact that this is true of C# vs. Java -- or perhaps more critically .NET vs. the JVM -- is why you can't have a Scala-like language on .NET (its specifically why you don't have Scala itself on .NET, which was a thing, but foundered on this problem.) Reified generics on a platform are great so long as all your (statically-typed) languages have type system just like the one assumed for the platform, but they ruin the interop story for any other type system, and a Scala-like language without a good interop story with the rest of the ecosystem would be pointless.

Compared to the real functional languages (Haskell), the only reason I can think of that scala is called a functional language is because the community would be insecure in their smugness otherwise. You can totally use scala as a better java dipping into FP occasionally as you would in C#. It's not like say F#, which really forces you into a functional mindset.

Post functional is as vacuous as post modern, ultimately these labels are not meaningful.

Rich Hickey makes a similar argument:

http://www.codecommit.com/blog/scala/is-scala-not-functional...

See https://news.ycombinator.com/item?id=8069466.

references?

http://www.google.com/trends/explore#q=java%2C%20clojure&cmp...

>Because that's what people use to write real programs.

Many people said the same of GOTO statements a generation ago.

I don't believe the parent of your post meant to say that nothing ever changes ;) Personally I think Java is a good, first language to learn. It's quite simple and easy to get started with. I'm not saying Java exclusively mind you, but that it is one decent language to start with.

As for the OP, I disagree. There are tons of good Java projects out there and there are tons of crappy Java projects out there ... just like pretty much every language ever invented.

>Because we all know, Google is known for hiring flakes who can't code or design real systems

They have some nice scallable backend systems, but a lot of their output is ho-hum, especially when it comes to their Java inspired teams (GTW etc).

> Because we all know, Google is known for hiring flakes who can't code or design real systems.

The primary reason Java is the language used for Android is the very same reason that Android is used so much in enterprises: it is easy to learn, and easy to get developers for. But the language's primary redeeming quality has become an economic one, and not that the language itself is so rewarding.

Most of the Googlers I know writing Java code would rather not be writing Java code. They would prefer Python or even Javascript (and a lot of FP enthusiasts also), but Java is what Android needs so Java it is. I would be very surprised if Google was hiring many people who only knew Java or were even very enthusiastic about it.

Perhaps the only language more reviled than Java in Google is C++.

I worked at Google for a long time.

The most problematic language at Google was (by far) Python. Mostly because tools that would start out as small Python scripts would evolve to become large Python codebases that ended up being unmaintainable.

There were several examples of unmanageable Python codebases at Google that got rewritten in C++ or Java. I'm struggling to think of examples of code going in the opposite direction.

This does not mean Python is a bad language. It just makes a different set of tradeoffs in its design. C++ and Java were designed with features that are known to increase verbosity but make it easier for large teams to work together. Python wasn't.

That's a really useful insight. What particular problems did you run across in Python that Java/C++ handled better?

It's hard for someone who was not the author to dive in to the middle of the code and understand it, debug it or upgrade it, due to the lack of explicit types.

Additionally there static analysis was limited to lint and refactoring tools didn't exist, or at least nobody seemed to use them (I never used PyCharm but I heard it can do some cool stuff).

Also for whatever reason these codebases often weren't very well structured and there was a common tendency to define configuration files that were themselves Python, resulting in the codebase spilling out into things that were theoretically just static data, complicating unit testing.

PyCharm is pretty neat, but coming form IntelliJ it's baby stuff. The tooling around Java can simply not be matched by a dynamic interpreted langauge. Probably ever.

And the more expressive your type system is, the more that becomes true. It will be interesting to see what is done for Idris tooling if it gets some popularity.

There's also lamdu[0] being made for Haskell which is pretty interesting.

0: https://peaker.github.io/lamdu/

What part of Python would you blame that on? Dynamic typing? Multiple inheritance?

That was not my point. Android is a developer platform; it uses Java because that is an accessible language for app developers, not because it is liked internally.

+1 for the "toy immutable functions". Immutability everywhere is the current hype, but like mutability it has its advantages/disadvantages. The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability). However on HN, the war is dogmatic whereas reality is not that black and white. As a Java developer, I find immutable String and primitives very convenient. For the rest, the liberty left to the developer is sufficient for high performance applications.

> The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability)

No, no, no. Immutable data structures are not actually inefficient, they are just different. They were designed for different tasks and work better in that tasks. Imagine, for example, that you need to traverse list of customers in a large multithreaded application. While traversing, you don't want this list to be updated. So if the list is implemented with a mutable array, you have either to lock it all the time, or create a copy, both of which are pretty inefficient. With immutable list, on other hand, you can freely traverse it because you are guaranteed it will not change during processing.

Multithreading is one of the main sailing points for immutable data structures, but not the only one. IIRC, Java String are immutable to allow creating substrings as views on the same char array, which, on average, increases performance, not decreases it. Another cool thing is that with immutable data structures you can add new cool features like auto generation of `hashCode()` or memoization.

Surely, some algorithms require mutable data structures by design. Change one pixel in 1M image stored as immutable array is definitely bad idea. That's why most functional language tend to, but not limit you to using immutable data structures only.

> IIRC, Java String are immutable to allow creating substrings as views on the same char array, ...

If you point to substring() as a view of a string, nope, that behaviour has changed for quite some time already. Surprisingly for me as well, back then.

Ah, yeah, I remember discussion about this, but didn't know about its result (I'm not active Java developer for some time now). Anyway, I think you've got an idea - immutability assumption may be pretty useful and improve performance in some cases, not decrease it (if you use it correctly, of course).

What I find quite amusing is that all these posters bashing OOP, end up using languages that actually do offer some form of OOP, as they seem to lack the understanding that Java OOP is not the only way of doing OOP.

As all modern languages, even functional ones, have OOP support.

Also I thought the point was Java and not OOP.

Java devs are known to over-engineer everything. There are many nicer OOP languages out there, where the devs don't tend to do this.

> There are many nicer OOP languages out there, where the devs don't tend to do this.

Because they aren't used in enterprise applications. Just give them time.

I don't think "enterprise" is the problem here.

When I got software engineering at university, we learned Java. So all those fancy (mostly over engineered) ideas where taught us with it. When we did some web or IA stuff, we did it in PHP, JavaScript and Python and the lecturer went for small concise solutions.

I never found a way to sense the differences between OOP flavours (NPI). Are you thinking of ST/Ruby where it's object and method all the way down ?

There are many models:

- OO like in Smalltalk

- OO like in SELF

- OO like in BETA

- OO like in CLOS

- OO like in COM

- OO like in Haskell

- OO like in C++

- OO like in Eiffel

- OO like in Ada

- OO like in Sather

A few more models might exist.

HyperCard and AppleScript. And JavaScript is pretty unique at this point. Scala's OO is also pretty unique with traits and type members.

How unique is JavaScript from SELF?

In regards to Scala, I would say OCaml has similar capabilities.

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

> Scala's capabilities are not really comparable to OCaml, which doesn't even have traits.

Yes, it has a bit of everything anyone thought about in FP in it.

However you can make use of traits like feature by mixing in modules and objects, while taking advantage of first class modules in OCaml.

> JavaScript has many influences beyond Self

Sure, but I am unaware of any that make it such a great language.

Scala's OO features are more like Java's done better. OCaml is this weird object system that is structural most of the time sometimes nominative, and then there is that weird ML module system. Ah...I totally forgot about Moby. [1]

JavaScript has been very successful, and got a whole generation of programmers playing around with prototypes without knowing it.

[1] http://moby.cs.uchicago.edu

Thanks for pointing out to Moby.

JavaScript's success has less to do with how good the language is, rather sharing the same fate as successful systems programming languages, by being the only gate to the kingdom.

I think the biggest difference between Scala and OCaml is that Scala users don't (have to) tell beginners to avoid the OO part at all costs.

OO in OCaml feels as if the designers thought "we think OO sucks, so let's implement terrible support for OO to get our point across".

OCaml's object/class system is actually pretty good. It isn't used very often in OCaml because most of what OO gives you can be more naturally expressed in other parts of the language, but that doesn't mean that it's bad. In particular, classes are still the best mechanism for open recursion in OCaml, and should be used when that is what is required.

> OO like in Haskell

Please explain. Are you referring to type classes?

Yes. Type classes is a way of doing polymorphism in Haskell, the central point of OO.

I thought the central point of OOP was to encapsulate functions ("methods") and the data ("objects") they operate on, thereby providing a way to structure code? That's why it's called "Object Oriented Programming" and not "Polymorphism X Y".

Wikipedia at least seems to agree with me.

That is only in the case of OOP as introduced by Smalltalk.

For example, OOP with multi-methods, does not imply such encapsulation.

I think one problem that people have when they are talking about object oriented (or FP for that matter), is that there isn't a clear definition around what it means. Most developers agree that it is some mix of encapsulation, polymorphism and inheritance.

There is a lot of disagreement about which of those is more important. For me polymorphism is the most important, encapsulation is useful sometimes, and inheritance might be a negative attribute. For you encapsulation.

I had that revelation at my college Lab, teacher discussing why OOP was such a beautiful thing, none of them could agree on definition of OOP nor the qualities.

FP is smaller and stricter, it's almost formally defined (you have denotational semantics for FP VM for what it's worth).

OO is more general than that, it's just a general paradigm for code reuse. Polymorphism is one of many forms of code reuse (allowing functions to accept multiple type signatures). I wouldn't call it the "central point" because polymorphism can be done without OOP, and OOP can be done without polymorphism.

What you're saying is that traditional OO conflates polymorphism with encapsulation and inheritance, creating one big complexity murder-death-ball; whereas Haskell lets you have these things a-la carte, so you can deploy them as needed.

It is central. Without polymorphism you don't have a way to abstract algorithms over types.

So you just get ADTs as introduced by Mesa/Modula-2.

You can do OOP with only ad-hoc polymorphism, which is just method overloading, which is what Java and C++ do. Actual parametric polymorphism isn't necessary for OOP, and there are non-OOP languages that have it (e.g. SML has polymorphism but does not have objects).

So, polymorphism and object-orientation are orthogonal concerns. OOP is about encapsulation, inheritance, and modules that couple mutable state (attributes) and behavior (methods).

For the curious, Ocaml mixes both, its object model is parametric (see: http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-objects.html)

> You can do OOP with only ad-hoc polymorphism...

Which is still polymorphism. I purposely did not enumerate all CS forms of polymorphism, but can get more detailed if you will.

   ArrayIndexOutOfBoundsException
   ...
   extends IndexOutOfBoundsException
   extends RuntimeException
   extends Exception
   extends Throwable

Not exactly an abomination, but I would not call it thing of beauty

Most words exist in fairly deep ontologies also, is English an abomination?

Sidestepping much? We are, obviously, not speaking about a natural language here.

I think this is an example of an hierarchy without a purpose.

Pointless OO, what's not to love here..

There is a clear ontology in the above classes, and it's nice to formalize that in the language rather than just keep it informal in a naming convention. I mean, why not have subtypes if you have subtypes?

It seems that you argue for subtyping for the sake of subtyping.

Up to you man. Peace.

I don't read it that way.

One way of viewing nouns in English is as a hierarchy. At the top of the hierarchy you have "thing", and as you descend the pyramid you get more and more specific. "What is that thing?" -> "What is that animal?" -> "What is that mammal?" -> "What is that ungulate?", etc.

There are times when it is appropriate to use "animal", and times when it is appropriate to use "ungulate". It depends on context. OO allows you to have the same levels of abstraction, and it can be a powerful tool.

NOW, having said that, there are two problems with this:

1) Not everything is a noun. Sometimes you want to deal with verbs.

2) Realistically, these hierarchies (in Java) tend to become overly-complicated over time. That's what OP is talking about.

There are cases, though, like the aforementioned Throwable, where having a deeply (more than 3 layers deep) nested hierarchy is wholly appropriate.

This kind of metaphor is why object systems go so epically wrong. You just want the minimum set of objects that you need to express the problem. In my experience, any attempt to map that to natural language taxonomies leads to a large number of object subtypes that just exist to name things, not DO things.

When dealing with OOP, I stick with patterns and keep everything else as flat as possible.

> is English an abomination?

Yes, yes it is. All natural languages are. They are living, breathing, evolving, organic concepts. They don't have the benefit of being designed and prescribed by an individual or group of individuals like programming languages do.

FP wasn't mentioned in the article. Criticism of OO doesn't necessarily mean embracing FP, as far as I know.

What other choice is there? Old fashioned procedural? Logic rule driven? Some "other flavor of OO but lets not call it OO" (e.g. component entities)? From a paradigm perspective, there are really only two in active contention.

CES is definitely not a flavor of OO. It can be mixed with OO and it can easily be implemented in OO languages, but it's far from being OO. You can't say 'entities are objects so CES is object oriented' because entities are not objects in the OO sense.

So yes, the other options are static procedural and component oriented like CES. Interfaces without inheritance are also gaining popularity, I think this is what Go and Haskell do.

I guess it really depends on your definition of "objects." If it quacks like a duck, its probably a duck. Inheritance is not necessary at all for objects (since at least the Treaty of Orlando).

It's true that there's no definition of "object oriented" that fits every language that has "objects". But that also means that the term "OOP", without the context of a language, is useless in discussions, because it doesn't mean anything.

Like Java, Go and Javascript have "objects", but you all know how different they are. So don't make them equal by calling both of them "object-oriented". If structs in C were called "objects", would C be object-oriented as well?

Go is fairly OO in its own 1970s style. JavaScript is definitely OO and not many would argue otherwise. C is not: struts don't support encapsulation directly. However, many have invented or reinvented OOP in C (including me) with void* and hand rolled virtual dispatch tables (you can even find that in Linux). Heck, how do you think the first C++ compiler was written? And you could of course do objects in assembly...it's even easy given a few macros. [1]

OOP is simply programming with objects. If you have values that contain encapsulated state, and you are instructing them to do things with that state, you have objects and are doing OOP. You can do that in any Turing complete language, but some languages support it better than others.

[1] http://www.drdobbs.com/embedded-systems/object-oriented-prog...

It is possible to use OOP without taking the AbstractFactoryInjectorBean train all the way to the last stop.

There seems to be an implication in your comment that people aren't using FP to write "big serious programs". Is that really what you are implying?

In that domain, yes! How many UI frameworks are functional (beyond I think...Om?)?

Let's wait and see if Om inspire others. You know that ideas take time to diffuse, OOP/MVC has been a somehow natural fit for IHM, but like many other ideas (closures?) now that people can see it, maybe they'll change their mind.

It's unfair to focus on "UI frameworks" when UI frameworks are specifically aimed at supporting client OSes where they have to deal with "preferred frameworks", all of which were developed when OO was all the craze. Functional programming has only been discovered as a practical paradigm quite recently! Besides, implying that "big serious programs" necessarily implies that they are UI programs is completely wrong.

Unsurpisingly, if a given JS UI framework is OO, it is not OO in the traditional sense because JavaScript itself is not OO in the traditional sense. If you make a framework, you use the language of whatever runtime you are targeting.

Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do.

So you are arguing that there is some perceived evidence for OO in UI programming, but I think that could more easily be attributed to historical trends. Note that I'm not necessarily disagreeing with your conclusion, just that your reasoning is flawed.

OOP is well suited to UI programming because it is built around metaphor. FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g.

> Functional programming is often used to write server code that must easily parallelize and scale across cores, CPUs and clusters. Mostly because the FP paradigm is more obviously advantageous in that setting, but also because those services have less baggage of trends than UI heavy programs do.

As someone who works in a distributed systems team, ha! Where are these functional programmers writing high performance parallel code? Microsoft? Google? Facebook? Maybe map reduce and some pipeline descriptions can count as functional but that's about it (even the UDFs are imperative).

The best HPC programmer I know (and probably one of the best in the world) uses C++ and CUDA, neither very functional.

> FP doesn't quite work because UI programmers like to think in terms of buttons and windows rather than f and g.

This is because people have been educated in thinking in objects for thirty years now. This is again a result of history, not because of the qualities of OO over FP.

Besides, there's no reason why you couldn't do that using functional programming. FP is not (necessarily) object oriented, but that doesn't mean you cannot reason about 'objects' in a different sense.

> As someone who works in a distributed systems team, ha! Where are these functional programmers writing high performance parallel code? Microsoft? Google? Facebook? Maybe map reduce and some pipeline descriptions can count as functional but that's about it (even the UDFs are imperative).

I'm not talking "distributed" systems that do HPC work; functional programming in general cannot achieve that level of low-level performance (as long as you don't count Rust's ambitions). I'm talking 'scalable' systems that do a lot of messaging processing (like web services and queueing systems). Twitter, Walmart, LinkedIn (Scala), Facebook, Whatsapp, dozens of companies in the telecom industry (Erlang) and Jane Street (Haskell, OCaml, F#) are examples.

These scalable messaging systems...we have those also. Also C++ mostly. I would be surprised if Google was very different.

Functional programming has been known and researched for decades. Mostly what happens is the obviously good features filter down into more mainstream languages, hence the new stream extension in Java 8, and the rest (lazy by default?) gets left behind.

The key selling point of functional languages is not lambdas, but immutable state and referential transparency. People read "advantages of functional programming" and think "anonymous functions" and "they're talking about scary Haskell" which is wrong.

Although lambdas are a big improvement to Java, they are not helping enough to make the language more functional. Java is built upon mutable state to its very core, and will never share FP's redeeming qualities.

Lazy by default is a feature of Haskell, and is not a feature of (or necessary for) functional programming. Scala, OCaml, F# and Lisps are not lazy by default.

> The key selling point of functional languages is not lambdas, but immutable state and referential transparency.

Not everyone agrees, evidently! In his influential paper, Hughes argues that higher-order functions and laziness are key to functional programming.

I'm going to agree with parent. OO programming is mostly about objects...they have names and identity, with that identity they can have mutable state (would be difficult to have state without identity and aliasing). In pure functional programming land, all values are anonymous, there is no way to tell if you seen something for unless you setup a GUID in the value (which would also require state, but whatever). Those values have no identity, so mutable state is impossible, leading to a very different style of programming.

If you allow for value identities (via GUIDs or if your language is really impure) in your functional code, you wind up with a style of programming that is very similar to programming with objects (messaging those values to do things with their state). Heck, you wouldn't even need overt mutable state to arrive at a very OO style (see clojure).

Hughes didn't disagree with what I said; I would contend that higher-order functions and laziness only improve modularity iff the language was referentially transparent in the first place. The assumption that the theoretical FP language he discusses is referentially transparent is found on page 2 of Hughes' paper.

Java's lambdas only serve to reduce boilerplate; everything done with Java's lambdas was long possible using anonymous classes. Theoretically, they do nothing to present the advantages discussed by Hughes [1].

Hughes also didn't talk about laziness-by-default: his argument still holds if laziness is available somehow (which it is in many FP languages).

[1]: Of course, lambdas might improve the style and expressivity of idiomatic Java enough to make up some ground.

You can make immutable objects in Java. The result is quite, quite unpleasant IMHO, but so are many other things in Java. You just create an object that has final fields and a constructor (or a builder if you have a more complex object).

Now, nothing stops that immutable object containing a mutable object of course, but that's up to you ... Guava has immutable collections if you want them.

Better language support for immutability would not go amiss though.

Reply on news.ycombinator.com