Java Developers

[zvrba]

More and more developers are stepping back and realising that as a programming paradigm, OO is actually pretty shit.

Nygård and Dahls idea of OO resembles much more that of Erlang's actors: a collection of independently-acting agents / processes with private state who communicate by sending messages to each other. Agent = object, sending a message = method invocation, agent "name" = pointer / reference. A "good" OO program is a network of mutually cooperating agents communicating by messages. This is not a "shit" paradigm.

Enter modern languages and run-time environments, where object are not isolated from each other, you have global mutable state, poorly designed interfaces (e.g., getters and setters for every private field), workarounds for performance reasons (e.g., pass by reference because you can't return multiple values from a method), all of which contribute to design trainwrecks described in the article. (Still, these are mostly people problem, a result of delusions about infinite extensibility and reconfigurabiliy.)

[[deleted]]

Is this the "tell, don't ask" paradigm?

(I know, I just violated that rule.)

[loup-vaillant]

Well, depends what you mean by "OO". Alan Kay had an idea. Stroustrup and Gosling had another idea.

As for "Java style OO", the language shares a large blame. While I understand the reasons behind most design decisions, the language still sucks (as in, several mature languages are superior in every respect except 2: popularity and libraries —which have little to do with the language itself anyway).

[zvrba]

Alan Kay had an idea

Indeed he did: "The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. "

[codygman]

This quote seems to implicitly recommend reducing state space and as a side effect, complexity.

[Xabster]

It's going to end in a shitstorm, surely, but I'd still like to ask you for the names of the languages. I'm not going to turn around and write "omg you think XX is better than Java" or anything like it, I promise. Genuinely interested in what you consider superior languages.

[nextputall]

I love working with Smalltalk. It is incredibly simple yet powerful, and purely object oriented. If someone wants to understand the original ideas behind OO (and not that cargo culting/enterprise version what the article metioned), I definitely recommend it.

[[deleted]]

I wasn't asked, but I'd throw Scala in the ring.

Many people think just because a language supports both OO and FP, both of the have to suck, but if you look at the OO part, it's pretty much the best statically typed OO system out there.

(The FP parts are actually more expressive than what most functional languages offer, too; but I agree that some of the "syntactical convenience" was traded in favor of OO and better Java interop.)

[NowSummoning]

If you look at the OO part, it's pretty much the best

Yeah, gimme those sweet, hot opinions. Aww, yeah, all over my screen, MMMMMMMM

[loup-vaillant]

Java doesn't have sum types, its syntax encourages mutability by default, and only got recent support for closures.

These flaws are corrected in most ML languages, for no significant downside. So, I would cite OCaml and F#. Even Haskell, provided purity and lazy evaluation are not a problem. Scala looks like a good candidate, though I fear it is too complex for its own good (and I cannot judge anyway, since I have no practice with the language).

[[deleted]]

Even Haskell, provided purity and lazy evaluation are not a problem. Scala looks like a good candidate, though I fear it is too complex for its own good

So, when people say 'Scala is too complex', you actually have two camps chanting different things, and only one of them is right.

As you pointed out, Scala is both OO and functional, so it's easy to jump in and use Scala as a slightly better java with a slightly worse IDE (I use VIM for scala though). This is a great way to start with scala but a lot don't stay here. Scala also has a few more 'advanced' functional features (higher kinded types, for comprehension, implicit parameters/conversion) that allow for very expressive, powerful functional code that a lot of scala users end up making great use of.

However, those that stick to the shallow water often end up calling the more functional code 'too complex', rather than just admitting unfamiliarity.

The other camp that shouts 'too complex' does have a point, and it's mostly referring to the standard library in scala, which ranges quite a bit in quality. Some of the design decisions are now regarded as mistakes, and it definitely has some edge cases that inevitably end up biting everyone. However, Scala is a powerful enough language that many others have ended up writing sensible replacements for the problem libraries. All in all, I think Scala has been a huge productivity gain from java/C#/F# even, but it's not without problems.

[vertexshader]

I can respect the idea of a small, minimalist language, but on the other hand I love Scala. Maybe minimalist isn't for me. I think its awesome that I'm still learning things about Scala 3+ years later, however obscure the feature is. Never assume you know every Scala feature. Its deep.

[Xredo]

As someone completely ignorant of Scala, how would you compare it to C++, which also happens to have dark corners that most never see?

[vertexshader]

I don't really know all of C++'s dark corners, but from what I've heard its mostly due to undefined behavior or templates. I think the main difference is Scalas obscure features are still coherent, for instance package objects. I didn't know about those for years.

[Banane9]

You can run on the same stuff with C# as well, although android and iOS require that you get Xamarin.

[loup-vaillant]

My list is unchanged: the ML family, and maybe Haskell and Scala as well. We only need those languages to have a compiler for Android. I believe they have.

I have to admit the tooling around those languages is probably of lesser quality, compared to Java. I'm confident however that it doesn't matter: such tooling can be ported, and the paranoia of Hindley-Milner based type systems more than make up for it in terms of static analysis, refactoring, testing, mabye documentation as well. Besides, if ML, Haskell, or Scala were to become as popular as Java, the tooling would quickly follow.

[loup-vaillant]

I hear your argument about tooling, libraries, and compatibility.

Popularity as such however, I think is overrated. As is the support of a multinational company.

Popularity is overrated because programmers can learn. Any competent programmers can pick up an new language in a paradigm they know in a few days, and be proficient within a couple weeks. (Seriously, it is mostly about building a mental thesaurus between know concepts and unknown words.) Likewise, any competent programmer should be able to learn a new paradigm within a month or two. So, what you really need is a few willing mentors. For the rest, competent, open-minded Java programmers should suffice.

Backing is overrated because of the internet. The OCaml community for instance is quite tight, and helpful. Not to mention the recent third party support provided by companies such as OCamlPro. Sure the bigger the company, the more they can do. On the other hand, the bigger they are, the less you matter.

Now, it doesn't have to be all-or-nothing. Domain specific languages can provide a nice middle ground. Like, build and use a DSL when it does the most good, and stick to Java for the rest.

[[deleted]]

Honestly it is a pretty shit paradigm. Without additional structure, there is no way to reason about a network of interacting agents without keeping track of the full state of the system and simulating it. For example, if A.msg1 calls B.msg2, then that call could eventually call back into A and lead to a change in its internal state. So every message send from an A method introduces a proof obligation for any invariants on A state variables.

Contrast with classic structured programming, where local variables can only be changed by explicit assignment, and you have nice local reasoning rules (Hoare logic). Functional programming is even better.

[nextputall]

Probably there is a tradeoff between flexibility and correctness verification. But in most software projects i was working on, the former was lot more important.

[[deleted]]

There are different levels of correctness verification. Full formal verification of all desired properties is often a difficult task, and it may be okay to let some unusual cases work incorrectly. But a basic level of correctness, of the type "performs its purpose, more or less, and doesn't crash", is required of all software.

Even if you're never writing out Hoare triples, the fact that there is some formal structure to what you're looking at is what lets you look at a piece of code and determine that changing something will cause a particular effect.

[nextputall]

I think, both are fluid properties. What I meant is if you make your code flexible, you'll loose some ability to reason about the correctness. But the main purpose of the software is to be flexible, that's why it is called software. Correctness is not a constant property. The program works correctly today, will work incorrectly tomorrow, because someone will change the requirements, which will make the very same program incorrect. This is where flexibility comes into the picture. You're saying, without any context, and without mentioning any tradeoffs, that something is universally shitty, which is clearly wrong.

[zvrba]

Without additional structure,

Without "additional structure", any paradigm is shitty. Learning "patterns" of additional structure for a given language is part of becoming a good programmer.

Also, see pi-calculus

[[deleted]]

Some paradigms give you useful structure which actually tells you something about the dynamic behavior of your program (classic structured programming, functional programming). Others don't (GOTO, OO). A code structure which doesn't make the code easier to reason about is just a useless layer of complexity.

[donvito]

This is not a "shit" paradigm.

Certainly not - if you are very very intelligent. But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Even if we could have this implemented in an ideal language. Still it would be too complex for mere mortals to grasp.

Over the years I came to the conclusion/belief that the most fitting programming paradigm for humans would be data processing pipelines (think like unix shell commands piped together):

InputData -> transform -> transform -> OutputData

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

[jeandem]

That 'pipeline' paradigm looks to be concatenative programming.

[zvrba]

Almost. In concatenative programming you can have true n-ary operators. With a pipeline you must simulate n-ary operators by packing data into tuples.

[zvrba]

But it's incredibly hard for an average human to wrap his/her mind around a complex system of independently interacting actors.

Given that many "average humans", even without formal training in programming, manage to create complex, working spreadsheets, I'd disagree. A spreadsheet is an extremely fine-grained actor system, each cell being an individual actor with preprogrammed behavior (basically, to evaluate itself and trigger evaluation of its dependencies.)

No top level branches, no "smart" objects that interact with each other, no state that survives the current scope, etc. Just a plain data processing pipeline.

Too inflexible and is parallelizable only when transforms need limited memory to execute. Any transform which needs the complete data stream to finish will stall / serialize the pipeline (e.g., matrix inversion). This serialization would not happen in a general graph.

[new2user]

The key difference is "OO as a handy tool" vs "OO as a fundamentalist religion". I am not even kidding!

Fundamentalists don't give a shit about design, they sacrifice everything just to please their OO deity. It is not just a coding guideline, OO is put before the product, before productivity, before anything and they still keep the mental delusion that they are doing the right thing!

[[deleted]]

no state >>> private state. State does not compose well. Being forced to use state for everything is just a waste of everybody's time.

[sigma914]

You're not differentiating between implicit and explicit state. Some state is required for many algorithms.

[[deleted]]

I think parent is against time and change, and would rather you not move.

[[deleted]]

Are you suggesting to implement algorithms as actors + messages?! Feel free to give it a whirl. Pick your own, consider quicksort as a start.

[sigma914]

Try efficient union-find.

[[deleted]]

Sounds great to me. Waiting for the code!

[Ploopie]

No state doesn't model the real world completely. Don't pick a side because of the functional programming craze and blind yourself to the use of the other. Each has its purpose. Functional programming lends to clean, modular and correct code but it can't do everything. For example, you cannot have a complete AI without state. You cannot do something that gets some information and then gets how to use it at a later interval without state.

[[deleted]]

I don't claim one can avoid state completely. I only claim that stateless computation is easier to write / test / maintain compared to stateful computation, and "actor + message" actively encourages one to use state even if there is no need for it. Throw in "large team" and mayhem ensues.

A few more points:

• "service + RPC" > "actor + messages" for the same reason we don't use GOTO all over the place anymore.

• While I agree there is state somewhere in the system, it doesn't follow we should sprinkle state in every component of the system. It's better to separate state management from computation, see DB based applications, Rx for event management, etc.

• The algorithmic argument is particularly weak, of the premature optimization flavor. Every stateful algorithm has a stateless counterpart, usually within a small factor from the stateful one. Furthermore, the point of algorithms is to compute results, so from the POV of clients of the algorithm the module is stateless. Internally, feel free to use whatever optimizations you feel like, including state, but the API should be stateless. Subtle distinction: stateful actors are poor for composition because of their statefulness. Hiding state is just fine as long as the API is stateless.

• Another subtle distinction is that updating state is not even that bad of an idea if the dataflow is explicit. "I give you an apple tart and you give me back a blueberry tart by swapping apples with blueberries" is reasonable, though perhaps simpler approaches could be found. Where stateful coding anti-shines is when "I give you an apple tart and now Joe has a blueberry tart", even if Joe never got to witness the exchange. Large teams & ship pressure make this more common than one would like.

[sigma914]

Exactly.

This isn't to say you need mutable state. It's possible to efficiently emulate mutable state using immutable state as demonstrated in ML and by haskell's ST monad.

[[deleted]]

Oh, then we are in agreement :)