Just a spin on this: as a java developer that recently started doing a lot of python, what has really annoyed me (apart from the utterly woeful IDE functionality compared to typed languages) is the extra "boiler plate" thinking you need to do with python because of the dynamicness meaning you have to keep the types and classes you're using for your codebase in your head, rather than letting the computer deal with that.
e.g. you have a function with a "database" parameter ... it could be a string, it could be a dict, another class, or even a number. There is no way to know apart from back-tracking through the code (or run it and wait for it to fail with a TypeError when that code gets hit). With java you just read the type off the screen and you can get on with solving the problem at hand without extra thinking, and even if you do screw up your IDE tells you right away with a nice squiggly red underline, or if you're not using an IDE during compile time. With Python you might not find out about that TypeError until that 3am pager call.
People have suggested that the answer to this is forcing strict naming conventions and/or strict docstring conventions ... but if you are going to go with that level of extra work of typing "database_string" or """Lots of long docstrings explaining exactly what type the database parameter is.""" (and maintaining it!!!),you're not saving any boilerplate (biggest complaint I've seen levelled at java) so why not just use a statically typed language ?
tl;dr - for me, python adds cognitive load of keeping the minutiae of the code in my head on top of solving the actual task at hand.
That said, I like the "pick up and go" prototyping feel of Python for quick jobs - java sucks for that.
Bingo! Coming from C# and C++, I had exactly the same realization using Python (before I switched back). I always ask Python programmers "but are you just keeping track of the types in your head?" because it's impossible to keep myself from doing that. If Python (and dynamic languages in general) are just pushing the type checking into the programmer's lap, I'm not sure what the advantage is other than less verbose (looking) code.
There is some type funkiness: a Perl variable can have both string and numeric components. However, which one is in use is only a problem in serializers (JSON, etc.) -- in normal usage you can rely on choosing the right operator for the type at hand.
To be completely fair PyCharm is darn good with Python.
PyLint will get you to quite comfortable place as well.
Thanks to this thread I just discovered the state of type hinting in Python 3.5.1 and I am super excited.
I can imagine working on huge code base and having a beef with Python but being a Java developer I think that would be using the tool incorrectly. The reason why I am saying this is that in Java world we (or some of us) work on large projects, we have multi-module projects with millions lines of code.
Whenever I think about Python project, I like to think that I would build series of small, independent modules. Maintain them separately. Thus limiting burden of dynamic language. In Java/JVM land you can achieve the same with small JARs. But we often don't (for various reasons).
TL;DR: There are more than decent tools for Python. Java =/= Python. Development approach matters.
Although it won't help when using other people's libraries/code, when you're building your own code then you'll probably enjoy Python 3.5's type hints on function parameters. They negate the need for doing hacky things like specifying types in docstrings.
> Java’s type system, while verbose at times, allows you to write code that largely “just works”.
NullPointerException would like to have a word with you about that.
In all seriousness, it feels unreal that people can be that impressed by Java's safety or lambdas. Makes you shudder to think about what they've used before that.
AttributeError: 'NoneType' object has no attribute
isn't much better.
Java might not be perfect, but it does let you catch a lot of problems at compile time rather than run time, which is a step in the right direction. The alternative (run it and see) gets old fast.
Java provides less of the benefits of static typing than many other statically-typed languages (even than others available on the JVM), at a much higher cost in required ritual invocations made to the type system.
Yes, there is a value in static typing, but that value is minimized when you have a type system that isn't particularly expressive and/or have to make add a lot of redundant code to satisfy a comparatively unsophisticated type checker.
Java may have gotten slightly better since its poor performance in cost:benefit terms when it came to static typing helped launch the surge in popularity of dynamic languages, but its still not a great poster child for the benefits of static typing.
> Java provides less of the benefits of static typing than many other statically-typed languages
Don't let Java's type declarations fool you into thinking that Java is
statically typed. It's still dynamic typing, with merely some kind of type
hints slapped on top to be checked at compile time.
Type Erasure is the reason you can't use builtin types as generic arguments. And in a lot of cases it forces you to cast.
And as type erasure happens very, very early in the compilation process, you lose a lot of static type information the compiler could act on or give you warnings.
No it wasn't necessary to maintain backwards compatibility. Type erasure was implemented to allow libraries to upgrade to generics without breaking compatibility with existing applications.
1. Desktop users are tricked in to installing Ask toolbar crapware. Which other language tricks users in to doing that?
2. Java development actually have languished for very long time and it is very recent that it started to catch up with C# and other modern languages. Java forums are filled with cries and screams for adding these improvements for years on.
3. Java is built on language concepts that are now 20 years old. Back than people wanted every language look like C++. The millennials think outside the braces. They expect language to infer types instead of repeatedly being specified all over. They expect REPL. They don't want everything modeled as object and so on. Mature language does not equal modern language.
3. Java is not truely "open source" or "free". Ask Google and Apache Harmony for the legal battles they had to fight with Oracle.
4. If Microsoft had done what it's doing with C# and .Net back in 2000, I highly doubt Java would be as popular as it is now. In other words, things can be popular even while being technically legging behind. This is not to say C# was initially just a Java copy cat but it did grew up fast while Java folks set on their laurels.
5. Java is owned by Oracle. Enough said.
I think modern languages should not have obligation to look like C/C++ and it should use advances in automatic type inference, functional paradigms etc. Anything 20 years old would have great libraries and VMs, but then mainframes and Cobol were also very safe, "reliable" and had great libraries and infrastructure at some point. It's ok to use mature tools to get shit done now but proposing them as new frontier doesn't make sense.
Well, you know Archimedes and Aristotle had thought through all concepts in everything so nothing is new really :). Or more recently, all languages are just little flavors on Turin machine or Lambda calculus. But practically, Python had been one of the language that sets aside itself dramatically. It's still surprising to me that language designers - including folks on Go team - still have hard time thinking outside of braces. It's almost disguesting how C# requires braces and uses == vs =. When you look at Python, it's apparent that Guido van Rossum had no inclination to do things as it was popular at the time and he put a lot of thought in removing redundancy, putting else clause in for and so many other cool things that are now so obvious.
On the other hand, Smalltalk is way older than 20 and some of its features are innovative even today. I think finding the sweet spot between novelty and familiarity often beats innovation for its own sake.
About 1, having installed the JDK dozens of times I have never seen the ask toolbar crapware, could be true with the browser plugin (that should have died a long time ago) or the JRE (that I never needed to install).
About 3 to be honest I don't care at all of having braces, I actually dislike python because its lack of braces and what says if something is in a block is the indentation (I don't want to care about it when writing code, there are IDEs for that, specially when I move code around a lot), unless I am doing some quick tests on something and I dont have a minimal environment I do need a REPL at all (Java 9 may take care of that).
True that Java is not exactly truly open source, I have to agree with that.
Java being owned by oracle may be bad but being owned by a bad company does not make it a bad language.
Seems like these points glossed a lot of things as well.
I mean... what language that locks you down with one specific operating system (up until recently when they lost the market)?
I see other languages copying Java tools/ecosystems but I give you 10% point for which Java syntax was behind for years.
Your point #4 don't make any sense at all. The only reason Microsoft goes OSS these days because they simply _lost_ their bread and butter: developers. Back then, they haven't entirely lost them so there's no way on earth that Microsoft will be pulling whatever they're doing these days.
> It's ok to use mature tools to get shit done now but proposing them as new frontier doesn't make sense.
Unfortunately none of the current language seems to get shit done in a reliable, reusable, and ubiquity as Java.
The one thing keeping me away from Java still is the awful experience around modeling data.
Compared to something like a case class in Scala or even autoproperties in C#, writing classes with a bunch of getter and setter methods just to keep state is really tedious.
Use public fields, add getters and setters if you have to. Serialize your POJOs using Jackson. All modern data frameworks can deal with public fields just as well as getter/setter combinations.
(Unless you are publishing a public API. In that case, you can't easily convert a public field to a private field/getter/setter setup if needed, as the cat is out of the bag and clients have code against the public field.)
Do I wish there were auto properties like C#? Oh yeah, I'd love that. But I do find modeling fairly easy.
I also lament having to manually maintain equals/compare/hashCode/toString implementations. However, with IDE auto-generation of code (using IntelliJ) makes this merely noisy and annoying, and not a time sink or a constant source of dumb errors.
I'm seriously tired of this argument against getters and setters, just generate them with the IDE some also support collapsible regions with a start and end comment, and forget about them.
So considering you can just generate and forget why is it tedious?
Because it's actually useless, having the work been done by someone else or something else means the work is still done, and you still depend on that 3rd-party.
I was strictly speaking about getters and setters, and I do maintain that they are completely stupid and useless. If you're writing your 10 kLOC side-project, then sure, just use them and take comfort in knowing that there's a tool out there that you can just add to the toolset. You're (almost) the only one working on this project, there are no clear steps for how to setup a working environment because you gradually built it along the road.
But when you're on a 10 MLOC projects that's been touched by hundreds of people for decades, most of which just can't program and aren't there anymore to fix the mess they left, with untouched original parts still being the core of your system, with nobody having a clear picture of how the whole thing works because it's been divided in so many parts that interact through a poorly-defined, undocumented interface, then you become extremely wary of adding anything because you don't want to complicate things further, but you still have to make it work, because it actually solves a problem for the customer.
The more you can remove, and the less you need, the happier you will be. Using lombok or having the IDE do it may solve the problem, but there is a much better alternative: remove the problem altogether.
Because it's not about tooling, it's about being explicit vs implicit. Though, there is something to be said about having a nice default that you can easily invoke at the code-level.
The best argument is that the compiler doing it add complexity to the language. One might say adding complexity to the language is justified if it means removing complexity from the programmer's workload, but in many languages that attempt to solve this problem that's not how it works out.
Most solutions to this amount to allowing programmers to intercept field access via getters/setters. This way they can just use public fields and switch to getters/setters when they need to add special behavior without breaking the interface. Pseudocode:
// using methods; no special behavior
class Foo {
private bar
public get_bar() { return bar }
public set_bar(_bar) { bar = _bar }
}
// using methods; special behavior
class Foo {
private bar
public get_bar() { return decode(bar) }
public set_bar(_bar) { bar = encode(_bar) }
}
// using getters/setters; no special behavior
class Foo {
public bar
}
// using methods; special behavior
class Foo {
public get bar { return decode(bar) }
public set bar(_bar) { bar = encode(_bar) }
}
Rather than eliminate complexity from the programmer's workload, this just moves it elsewhere. Instead of tedium, which is something that can be alleviated by simple tooling (copy/paste, editor macros, templated code snippets), you get a constant concern over whether a field access will have unexpected behavior, which is something that can only be alleviated by complex tooling (semantic code analysis).
So ultimately this approach adds complexity to the language/compiler, adds complexity to the tooling, and has no effect on the programmer's workload.
I'm trying to think of a better approach and the best I can come up with right now is a macro system in the language (one that makes it very clear where a macro is being expanded, to avoid the same problem of "constant concern"). For example:
macro #generate_accessors(field) {
let paramname = unique_identifier()
return #[
public #[ identifier_from_string("get_" + field.as_string()) ]() { return #[ field ] }
public #[ identifier_from_string("set_" + field.as_string()) ](#[ paramname ]) { #[ field ] = #[ paramname ] }
]
}
// no special behavior
class Foo {
private bar
#generate_accessors(bar)
}
// special behavior
class Foo {
private bar
public get_bar() { return decode(bar) }
public set_bar(_bar) { bar = encode(_bar) }
}
But I haven't seen any language where this is the canonical approach.
You also have that problem in a language with non-synthesized setters, because there's no guarantee that they don't do anything - and people avoid permitting direct field access, so you'll be going through a setter with unknown behavior.
That being said, if you're throwing off side-effects like mad in setters, short of prohibiting either mutability or side-effects, there's not much the language can do to prevent that.
I really prefer Groovy's approach - default get/set behaviour is provided at compile time, but you can override in code with explicit getter/setter methods. Really seems to be the best of both worlds.
Or just use public instance variables, really. Unless you plan on explicitly specifying how your internal variables are going to be used and accessed, you don't get a free-lunch.
Meijer or Oderski advised to use Kotlin / Ceylon to lift the burden of Java POJO. They have enough syntactic sugar and type niceties to make you happy again.
That's because Java is object-oriented. Data and the functions that operate on that data are not supposed to be separated. A clean object-oriented design has no plain getters and setters.
Except that encapsulation doesn't make a lot of sense when you're just modelling information.
For example, suppose you have an Employee class that contains the employee ID, name, birth day, etc. Employee records don't do anything. They're just data. Hiding that data makes no sense if the point of their existence is just to hold the data.
You don't simply model information in an OO language, everything is an object, you're supposed to model your domain.
I don't reach into the employee class and "get" the employee ID so I can do something with it. The employee class knows what to do with their own ID.
Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious.
Low-level accessors to an "object's" state are almost never an accurate representation of the domain you are modeling -- they're bad design.
If you need them, you've probably missed a piece of the puzzle.
That being said, most programmers don't need to be doing OO at all. The level of guarantee it provides is, for most people, not worth the cost. In those cases, don't use Java.
We will all be having this same argument about functional languages in 10 years. Mutability is not functional, if you're relying on mutability you're probably just doing procedural code wrapped up in functional decorations.
Well, if we're talking Java, not everything is an object. None of the primitive types are, and Java has static methods.
> Just like a cashier doesn't reach into a Person's brain for their debit code. The cashier asks them to type it into the keypad, and points them where to do it if it isn't obvious.
OK, so I picked a bad example. What if you're dealing with records of tree data? Are you suggesting that modelling the domain means that trees should know what to do with the information about their diameter? In what way is that modelling a domain?
In software we're rarely writing simulations of the real world, and even then, it doesn't always make sense to have objects hide information that other agents could just observe about them.
We're usually dealing with information, not actors.
Take a look at Kotlin https://kotlinlang.org/
I know there is also Scala and other JVM languages. But I'm also an Android developer and Kotlin works really fine with Android-Studio (both from JetBrains).
I think the author has set an impossible task for the article: trying to sell Java without giving any specific use cases. Generalities don't cut it, especially if you've already invested time learning how to do something in Python, which isn't perfect, but can match the JVM in the areas that it does excel at (e.g. problems that need NumPy or Django).
Java is irritatingly pedantic about sticking to its idea of how OOP should work. It has that design by committee feel to it that enforces some idioms that please no one (like pushing object Factories). If you need to get a prototype out or want something that can let you automate a task quickly with little BS, you don't want Java.
Java is good for enterprise developers as it tends to reign alot of the cowboy tendencies of some programmers and helps to force everyone on the project to use the same clearly defined, well planned (and less elegant) APIs and other systems. And the JVM keeps you from being tied into some specific hardware that may go away in the future.
It's the difference between a toolkit to design and build a cool building, like the Space needle, or you need to coordinate a huge number of contractors because you're building the Big Dig or Chunnel.
IMHO, C#'s tooling and is definitely ahead. Java is starting to get there, and I can see why the JVM is still popular. But given the actions of Oracle and MS as of late, I think I'd take MS. VS starter projects are easy to setup and run... Every Java application I've worked on has been an exercise in frustration just getting the environment setup.
It's not completely free, and not completely open source, but we've been very happy with Octopus Deploy https://octopus.com/
That and Topshelf https://github.com/Topshelf/Topshelf have made deploying Windows services very easy. Topshelf is slowly adding some Linux/mono support, and OctopusDeploy supports SSH as a deployment option, but unsurprisingly things aren't as nice if Windows isn't your target.
I've found the opposite. For me, C# as a language is nicer than Java. The libraries themselves are a bit of hit and miss - personally I've found Java's concurrency APIs to be much better than C#'s, however I've found the async and LINQ support in C# to be far nicer than the Java equivalent (including Java 8 streams etc). But tooling... wow... Visual Studio feels like such a huge dinosaur compared to IntelliJ IDEA. Not to say it's that bad, but IDEA is so far ahead of any other dev environment I've ever worked with it's not even funny. Even adding Resharper to VS doesn't feel much more than scratching the surface. As always, YMMV.
Could you elaborate? Java has maven archetypes that allow that, create a base project with no effort and the right dependencies in place.
From there on compiling is just a command away, and running it usually too.
My experience with Java has been frustrating, I think it has a lot to do with what you need to know to get started. If you want to play with a language, check out how to build a quick API, you need to know a lot more than Ruby, Python or NodeJS. You need to know at least a little about Maven, a little about the build process, and for me it was more than I really wanted to do.
I pushed through learning a little about the JVM to learn some Clojure but I felt like I was troubleshooting things that I frankly didn't want to learn about. The pros didn't out number the cons for me.
To me, the article doesn't really sell Java the language. The big benefits are in the JVM and libraries, which support many languages far superior to Java. The only virtue of Java the language might be the programmers who know it, and even there, many programmers are not familiar with the new features of Java 8.
I love the jvm, I love the tooling and the ecosystem, but Java I do not love. The author presents many of Java 7/8 features as a reason for Java's greatness. The language features of Java 7/8 are really not that compelling. Let's consider that C# has had much a more progressive approach to language design for a while now.
Most places I've worked at recently have moved to Java 8 because 7 has been EOLed. It feels like we were pushed onto 8 rather than enticed by its shininess.
What makes Java great isn't java it's the jvm. It's such a brilliant piece of engineering. What makes the jvm 'meh' is it's association with java. The arguments the author makes about Java being great are in my eyes really about the JVM, its tooling and its languages.
Maven's one of the most disgustingly over-engineered, obtuse, verbose, tightly coupled pieces of s...oftware I've ever seen. From the project's own 5-minute introduction [1]:
If you have just installed Maven, it may take a while on the first run. This is because Maven is downloading the most recent artifacts (plugin jars and other files) into your local repository. You may also need to execute the command a couple of times before it succeeds...The POM is huge and can be daunting in its complexity...You executed the Maven goal archetype:generate, and passed in various parameters to that goal. The prefix "archetype" is the plugin that contains the goal... the second [command] is simply a single word - package. Rather than a goal, this is a phase. A phase is a step in the build lifecycle, which is an ordered sequence of phases. When a phase is given, Maven will execute every phase in the sequence up to and including the one defined. For example, if we execute the compile phase, the phases that actually get executed are [list of 6 items]...Although hardly a comprehensive list, these are the most common default lifecycle phases executed [list of 10 items]...
So in order to use this, I have to understand its own specialized non-standard vocabulary, like artifact, repository, archetype, plugin, goal, package, phase, lifecycle...the build configuration is in XML...it does a lot of stuff automagically, like executing five extra phases or downloading dozens or hundreds of executable files from the Internet.
People love Maven for some reason, but I'll use shell scripts or Ant for my Java builds, because when the build breaks [2], I want to be able to understand what's going on without having to read a few hundred pages of the build system manual.
I don't see any valid arguments that make Java 8 strictly better than any of the alternatives.
These languages are all in the same rough ballpark. Your particular use case/environment will determine mostly which Language you should be pick.
"the JVM has excellent support for production logging and production monitoring, allowing you to easily monitor performance metrics down to an individual thread"
Is it "excellent" compared to z/OS and mainframe (SMF and RMF, specifically)? I sincerely doubt it, but I would like to know if there is someone who can compare. I don't think any platform can match z/OS in the visibility into the system, but I am not enough expert in Java to really compare.
You're comparing an OS independent language to an entire operating system? I think you're probably right, I don't think there is a sane comparison. But I don't think that's what the parent was referring to.
I'm not sure there are too many languages that provide (eg via slf4j or JMX) extremely customisable, universal logging and monitoring across multiple libraries that are used together in a single application. That's not a function of the language itself though, just the maturity of the libraries and ecosystem around it. Combine that with the tooling (eg IntelliJ IDEA) and no matter how much you might think Java as a language is verbose/clunky/crappy (which I tend to agree with), it's pretty hard to beat for large, complex, maintainable systems.
"You're comparing an OS independent language to an entire operating system?"
No, I am not comparing Java, but JVM. JVM is a platform, so it should have insight what's happening on it, don't you think? Whether this insight comes from the platform (JVM or z/OS) or the underlying system (native host OS or mainframe) is irrelevant - you probably want both (and in z/OS you get both).
Whether Java (the language) is clunky is irrelevant - z/OS has lot clunkier languages on it (application development is huge pain on z/OS compared to JVM), and I still think z/OS beats JVM for large/complex/maintainable systems. ;-) (Basically for the same reason - more mature.) z/OS has many logging and tracing functions, at different granularity, some of them are assisted with mainframe hardware. I don't see how JVM could beat it, but I may be wrong.
i don't care what lipstick you put on that pig: when something as simple as writing to stdout requires that i first create a new class, i'm not interested.
Edit: i do consider this a legitimate issue with how Java 'does' OO. i'd be curious to understand downvoters' thoughts.
One more edit: wow, tough crowd. for those not familiar, i'd suggest reading Steve Yegge's essay "Execution in the Kingdom of Nouns"
Oh -- you're talking about the fact that you need to create a new class for your program's main method?
Yes, this is true, but it has nothing to do with printing to stdout.
Edit: I don't like Java and I've read the essay you're referring to. Please don't assume bad faith in other commenters. Your original post was factually wrong. There's enough wrong with Java that you don't need to make stuff up to criticize it.
e.g. you have a function with a "database" parameter ... it could be a string, it could be a dict, another class, or even a number. There is no way to know apart from back-tracking through the code (or run it and wait for it to fail with a TypeError when that code gets hit). With java you just read the type off the screen and you can get on with solving the problem at hand without extra thinking, and even if you do screw up your IDE tells you right away with a nice squiggly red underline, or if you're not using an IDE during compile time. With Python you might not find out about that TypeError until that 3am pager call.
People have suggested that the answer to this is forcing strict naming conventions and/or strict docstring conventions ... but if you are going to go with that level of extra work of typing "database_string" or """Lots of long docstrings explaining exactly what type the database parameter is.""" (and maintaining it!!!),you're not saving any boilerplate (biggest complaint I've seen levelled at java) so why not just use a statically typed language ?
tl;dr - for me, python adds cognitive load of keeping the minutiae of the code in my head on top of solving the actual task at hand.
That said, I like the "pick up and go" prototyping feel of Python for quick jobs - java sucks for that.