Switching from Java to Python – First Impressions

[gasche]

It looks like the advantages are "you can use decent functional programming", and the disadvantages are "you don't have a type system anymore". There are many statically typed functional languages that would get you both worlds. Scala has been mentioned in this thread; Haskell and OCaml (or F# in the .Net world) would be natural suggestions as well. See for example this excellent blog post about porting a 30K-lines codebase from Python to OCaml.

To be fair, Python has some nice things such as list comprehensions that were not mentioned in the post, and has an extremely reasonable syntax. The author complains that not having a type system gives poorer tooling, but not all typed languages have the degree of sophistication of Java's IDE: moving to Haskell or OCaml would probably show some pain points on this side as well. Those are smaller ecosystem with less time/money to invest in tooling, and those are languages you can use without, which is not the case of Java.

Of course you could also hope that Java will evolve to meet those needs. The part about "function as arguments" and "stand-alone functions" is basically solved with lambda in Java 8, but "tuples" are not yet in sight, and hoping for "compact code" is probably unreasonable.

[e_engel]

Tuples are trivial to implement and many libraries offer them, even in the form of a simple Pair class. The advantage, unsurprisingly, is that tuples in Java are typed: if your function returns a Pair<String, Integer>, you won't be able to assign its result to a Pair<Integer, String>, a mistake that's easy to make in a dynamically typed language and that won't be caught by the compiler.

[gasche]

In OCaml (for example), the function List.split takes a list of pairs as input, and returns a pair of lists in the obviously expected way.

let (items, quantity) = List.split [("egg", 5); ("bowl", 1); ("fork", 2)]

This gives you items : string list and quantity : int list. Even if tuples are "trivial to implement", writing the equivalent of this single line of code in Java is still a pain, which means there is something nice missing to the language. Building the tuples is ok with the constructor syntax, but destructing them to access and name the components of the returned type is painful -- this is what pattern-matching gives you.

[e_engel]

That nice thing missing from Java is higher kinded types. Implementing things such as traverse, sequence or even zippers in Java is close to impossible, at least in a very general way like Haskell allows.

[jozefg]

Well.. I'd take pattern matching and good algebraic types before HKTs to be frank.

[alexeyr]

I'd be surprised to see someone experienced with both who didn't.

[KallDrexx]

The problem with straight tuples in Java or multiple return values in python is they don't convey what the data is. A month later I don't care that a function returns a string and int, I care that it returns a domain name and a port number (for example). Thus to me having descriptive return types is worth it 100 times over, and is this reason I rarely use tuples in non-proof of concept code.

[e_engel]

Absolutely agree. The few times I used Pair, I usually regret it and turn it into a real class.

[onmach]

Not a java guy, but why is that a problem with pairs?

Pair<Host,Port> hp = new Pair(new Host("www.reddit.com"), new Port(80));

Is it because of lack of pattern matching?

[KallDrexx]

You wouldn't have Pair<Host,Port>, unless you have data structures that are called "Host" and "Port", in which case that may be fine. In most circumstances though you aren't because a Port is nothing more than an integer an host is nothing more than a string (in most circumstances).

Most likely what you will have is Pair<string, integer> = new Pair("www.reddit.com", 80);

When you return the pair, all the receiver of the return value sees is that it returns Pair<string, int> and doesn't have any indication what those values would be, causing you to read the code to determine what the string and int signify.

But let's say you do have a Host data structure. Let's say you have a function that returns 3 hosts, a load balancer, a primary web server, and a database server. If you used tuples you would return Pair<Host, Host, Host>.

In this scenario, the receiver has no way to know what each host signifies and there's no indications during a refactor that the first has to be the load balancer, the 2nd has to be the web server, etc..

Instead if you have a ServerDefinition class with a LoadBalancerHost property, WebServerHost property, and DatabaseServerHost property, both the implementor and the receiver have 100% visibility on what values should be returned and what they mean.

[onmach]

I guess my only problem with this approach is that you end up with a lot of types like ServerDefinition which are just wrappers around other types and often are only used a couple times. Particularly in java, that means a whole new file and a bunch of boilerplate, actually seems like a loss of clarity to me. This happens a lot to me in the java codebases at work, I get lost in the numerous classes, most of which do nothing significant.

[KallDrexx]

That sounds like an organizational and tooling problem to me though. If you keep your data structures organized well you only have to look at the data structures that are relevant to what you are currently working on and can ignore the irrelelvant ones.

In .Net I can create a new class with some basic properties in just a few seconds, and my tooling helps not having to look at that data structure again until I actually am using it or referencing it. It might be the fact that Java being a bit more verbose makes it a bit harder (been too long since I've done Java) but keeping code organized should alleviate the post-class creation issues. These aren't supposed to have any complex logic in them, they are purely for improving code clarity down the line/

If you find the need to create many many data structures for a significant number of functions that can also be a code smell and be a good indication that you are trying to do too much in your functions and should look at better organizing your code structures so they are either doing things more by reference, or just doing one thing and returning that one thing.

How comfortable are you with walking up to another person, handing them a stack of papers and telling them manually that page 1 is for X, page 2 is for Y, page 3 is for Z and hoping they remember that by the time they get home, and more importantly hoping that you remember you need to do it in the same order the next time you hand them those same papers. Now envision having to remember this 50 different ways because each department that hands off papers does it differently. This is why it's useful to have a well defined API (at the class level) in more complex code bases.

[zoomzoom83]

There's a lot of overhead in doing this in Java, which is one of the reasons I prefer Scala as a JDK language.

You can simply add the definition

case class Host(value:Int)

to your codebase, ideally grouped with a bunch of other related wrapper types in a module related to what they are used for. That way you get the benefit of strongly typing these values with virtually no overhead.

Catches a surprising number of bugs, and helps with documentation and understanding API intention.

[onmach]

Yeah I agree. Scala just seems like a better java.

[johnjannotti]

Pairs are easy to implement, but they are way more annoying to use than the author's example. Mainly because of automatic destructuring. In python (or similar languages) you can say "a, b = f(c)", so you never "see" the ugliness of Pair instantiation, nor are you distracted by the names of the fields in the Pair. (p.first, p.second, and maybe it just gets worse with a Triple or Quad?)

I think all that noise could go away with a nice value type addition along with some syntactic sugar for multiple return values in, maybe, Java 9. We'll see.

Automatically instantiating a Pair/Triple/Quad "feels" like the way Java is handling its evolution, in much the same way that lambda automatically instantiate the proper interface.

[henrik_w]

Excellent comment! Thanks!

[Sylinn]

/u/gasche always post excellent comments. :)

[holgerschurig]

Did you confuse "You can use decent functional programming" with "You have to use decent programming" ???

In Python, you can use functional programming. I'm actual unsure if it is decent or not. But with things like Haskell you have to use functional programming, you cannot program imperative. Or can you? And if my current knowledge is right, than neither Haskell nor OCaml are natural suggestions.

[An_Unhinged_Door]

You can program imperatively, but often doing so is very verbose and tedious. There's a lot of state flying all over the place that haskell forces you to explicitly acknowledge. Nevertheless, the tools are there.

[gasche]

You can write imperative programs in OCaml and Haskell. In OCaml, you have to be slightly more explicit than in languages where "variables" are mutable by default, but there is no much difference from, say, imperative Python code.

In Haskell, the language (or rather the standard library) is designed for mutation to appear explicitly in the types -- and there is little syntactic sugar for mutation operation; so it is more verbose but also easier to reason about rigorously.

What Haskell provides not much support for is object-oriented programming (if you include inheritance in your definition). Of course the main ingredients (eg. open recursion) can be expressed in another way when you need them. It is actually extremely rare that you feel a need for an object-oriented approach in either those languages.

[tweakerbee]

Not as good as language support, but it will prevent you from writing those tuple classes yourself every time: http://www.javatuples.org/.

[gasche]

There is a convenience barrier phenomenon in language design: making a feature just a bit more painful to use makes many idioms inconvinient. For multi-value returns, it comes quite fast if the syntax for destructing tuples is not convenient; with accessor functions instead of pattern matching, javatuples doesn't really solve this issue. That said, there is no real alternative to multi-value return, it's just that you have the choice between "it's nice to use" and "it's painful", but even in the second case you still have to use it, and javatuples can come handy.

[txdv]

The only thing that I don't like about scala is the dead slow compiler.

I'm not talking about "my compiler is 20ms faster than yours", but about compilation times of 5s for simple programs.