Please give better examples:

> Anyway, after trying to configure stuff like Kafka, Zookeeper and Maven and setting up a SOAP API, I saw that the problem with Java isn't the language

* Kafka: is written in Scala. It doesn't use XML.

* Zookeeper: it was the first of its kind. It doesn't use XML.

* Maven: same complexity as SBT, Gradle, etc... but it is declarative and again pretty much first of its kind (dependency management + build).

* SOAP: this is not Java's fault (if anything Microsoft was the big pusher)

* XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases. XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace.

The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style). But for some reason when people have to write a build or config file that they are rarely going to have to edit their fingers, eyes, and brains revolt at the complexity.

Scala also has some massively complicated libraries like Akka. Ruby has Rails. When languages/libraries get mature they get complicated and the languages warts show more and more.

I expect we will see the same thing even with modern languages like Go and Rust.

The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-trivial dynamic things in Java itself can be a huge pain. And so over time, enterprise Java apps became giant balls of XML+Java that would break at runtime if you missed an XML parameter or had a stray character somewhere. At that point, what benefit are you getting from Java's static typing? You lose much of the benefits of Java, and suffer twice as much from its drawbacks.

This is slightly better with the push away from XML and toward annotations, but it's not much better. Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

> The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML

You are going to have to show some examples.

> because doing non-trivial dynamic things in Java itself can be a huge pain

Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL".

Really the only better enterprise option back in those days was Lisp we all know how that played out.

> Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason.

But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails).

You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.

I agree with cle, and I care enough to give examples of painful XML coding in Java:

* Spring startup config (this is basically coding in another XML-based language)

* JSPs (again, programming in a new XML-based language)

* Maven Config (IMO incredibly painful-to-use XML-based language)

* Hibernate config, mapping files

* Tomcat config (basically a pre-cursor to Spring in some sense)

Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't.

Also, I think Java would have been better off never introducing annotations. They have their uses, but they've been so over-abused that I would consider them a net negative on the language as a whole. I've been thinking about starting a blog, and one of my initial blog posts may be why annotations are bad for Java.

> * Spring startup config (this is basically coding in another XML-based language)

The alternative of manually wiring up beans or giving up and using shitty singleton patterns is pretty awful (remember this was preannotation days).

A pretty sexy annotation DI these days is Dagger2 but alas you seem to hate annotations.

> * JSPs (again, programming in a new XML-based language)

That is not an XML language unless you are talking about JSPX or JSF. It is a crappy templating language. Lots of languages have those (like PHP had Smarty or Pear...). I totally agree JSP and the future JSF was a horrible addition to Java.

> * Maven Config (IMO incredibly painful-to-use XML-based language)

A config that your IDE instantly knows how to properly setup and allows for massively powerful inheritance (see super poms). If you import a Maven project with Eclipse or IntelliJ it just works.

Now I admit Maven is verbose and has lots of baggage but it has some serious pros and a lot of those pros are actually because it uses XML (like Eclipse can automatically adjust your Maven file without changing formatting). I have scripts that I have written in many languages (bash, python, etc) that can read Maven POM files thanks to XML. You can't do this with Gradle.

> * Hibernate config, mapping files

Yep that sucked but you hate annotations... so I guess you propose programmatically doing the mappings?

I despite hibernate anyway.

> * Tomcat config (basically a pre-cursor to Spring in some sense)

Oh like Apache config is any better. I mean seriously Apache has made up weird SGML config.

> Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't.

It is a dynamic language. You can instantiate classes by string names and manipulate their bytecode on the fly. You can call methods dynamically as well. Yeah it doesn't have the ease of metaprogramming like Ruby or Python but its its there through libraries (CGLIB).

Honestly I'm not sure what you mean by dynamic (please cite something) but I guess you mean interpreted and even that is sort of wrong as well (bytecode is interpreted by the JVM).

> Also, I think Java would have been better off never introducing annotations

Annotations also allow for preprocessing aka light weight macros. A full macro system probably would have been better. I look forward to your blog post (in all honesty).

You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community.

You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc.

I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)

> In practice, annotations define runtime global variables that other frameworks can make use of by doing expensive classpath scanning on startup to rewrite bytecode at runtime.

Dagger2 is DI a compile time annotation library. Yes there needs to be a lot more libraries like this.

I totally understand some of your hate for annotations (I have my own with Spring Boot).

Despite my tone from the previous comment I think there should be a lot more plain old programmatic configuration (ie just load up objects and setup some properties during the bootstrap).

I had aspirations of making a howto guide using Dagger2 and various other compile time / code generation libraries (like jOOQ and MapStruct) as I too absolutely hate the classpath scanning hell that is Spring these days.

I can't deny though that some people find the "magic" more productive particularly for ramp up time.

All in all I violently agree with you more than you think (hence why I'm looking forward to your post).

I still don't know what a dynamic language is and neither does Wikipedia for that matter [1]. Its pretty nebulous. Its like saying strongly typed.

[1]: https://en.wikipedia.org/wiki/Dynamic_programming_language#E...

Dynamically typed languages carry the types of values at runtime. That is, whatever is executing your code can look at a value itself and read off the type of it. Statically typed languages check all of the types of their values at compile time to make sure that it's sound. Then, they can strip the type information from those values and execute them without having to perform any runtime checks. In a dynamically typed language, the way to apply an operation is to read the type tag on it first, make sure the operation you want to apply can be applied to it, and then execute that operation. In a statically typed language, that check happened at compile time, so you're safe to just apply the operation to the value. Oftentimes languages may not be fully statically typed or fully dynamically typed. Java's use of reflection, instanceof, and casting means that it carries some type information at runtime. C++ has typid, C# has GetType(), etc. etc. Haskell as a language has full type erasure and can be considered fully statically typed, but there are some. GHC extensions (Typeable) which point to some type information being held at runtime by the compiler.

> Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

That's a point I never really understood. Code generation has it's downsides, but it seems vastly preferrable to the current mess of reflection: There seemed to have been a trend to move a lot of stuff that should logically occur at compile time to run time - therefore both adding a performance penalty and making debugging a royal pain - for what benefit?

There are some recent projects (e.g. Immutables and Dagger2) which seem to favour code generation over reflection again and I really hope this trend picks up steam.

> You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software.

Which sounds reasonable - until you see real-world use where all components of an application are wired together with XML - even though for most of it, there is only a single setting that wouldn't break the application.

> Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

You're equivocating on "dynamic".

Java is not a dynamically typed language.

It can be seen as "dynamic" in the sense that its behavior can be modified at runtime by external files. Then again, what languages can't?

> YAML is so much more complicated and harder to parse.

YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML.

XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML.

> Developers write hundreds of lines of XML all the time... its called HTML

There it makes sense, because it is marked up text you are writing and it is the right tool for the job.

> YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML.

I mostly agree but YAML sounds like a serialization format and not configuration format to me.

I think a large amount programmers don't realize nor respect the history. Early Java proliferation was during the late 90s and early 2000 on-premise enterprise software. Customers required extreme customization but not all of them wanted to actually crack open and edit files.

The customers wanted to use tools and XML works great for bidirectionally editing not to mention there were shit loads of XML editing tools at the time (XML Spy).

> XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML.

One of the reasons Java originally pushed XML is the support for it so good (tooling and editors). Java actually has great support for mapping XML to objects (JAXB).

Agreed up until the XML bit. It's not "XML vs YAML", it's "Why do you need all this static markup at all?".

If this is going along the lines of S-Expressions I say touche but it is what it is.

You need markup instead of code sometimes because you want declarative configuration. You want to sandbox a developer/user.

Yeah you can write declarative code in Scala (and many languages using Monads, macros or some sort of non imperative abstraction) using an embedded DSL... but it is embedded and hard to enforce someone from sticking a System.exit(1) somewhere.

Again If you are in the Lisp camp I submit there are better options.

>Kafka: is written in Scala. It doesn't use XML. Zookeeper: it was the first of its kind. It doesn't use XML.

Which is beside the point, since the parent complained about the needless complexity and layers, not just about use of XML.

>Maven: same complexity as SBT, Gradle, etc...

Which is to say: more than the task requires.

>XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases.

It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format.

And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. In which case, everything is easy to parse (and most things, easier than XML to extract values from).

>XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace.

Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration.

Which, the doing needlessly complex stuff, is what the parent complained about.

>The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style).

Unless those developers are web developers, and especially front-end web developers, no, they don't.

And even if they did, it's one thing to write HTML in its intended domain, and totally another to have to write it (or specifically XML) for configuration.

In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.

I'm curious... what do you propose instead of XML for configuration. You know that is standard and everybody knows it. Remember Java was/is very good at parsing XML.

> In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.

And yeah it is Stockholm Syndrome because shit hasn't gotten that much better. Editing massive YAML or JSON files isn't really any easier IMO. You can't even put a comment in a JSON file and unless you are using Emacs I think even S-Expressions are not easier.

> It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser.

Except XML is extremely standardized and well established and yeah there are parsers in almost every language. JSON has changed its standard a ton of times. It actually is really hard to parse correctly [1].

> (and most things, easier than XML to extract values from)

XML has XPath and XQuery. Both very well defined and have backing standards. ie not a random github project just supporting one language which is the case for JSON path. IMO XML is one of the easiest formats to extract data from. Even CSV is scary to parse correctly.

>Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about.

It isn't needlessly complex if there are requirements for such. Maven was designed to be declarative and the hope was it could be imported by IDEs which it successfully achieved.

You know one of the reasons why Rails and various other easy to use frameworks came about is you don't need as much complexity if it is a hosted model. You don't need massive configuration if you are hosting and not delivering on premise software. So circa mid 2000 was the Rails crowd trashing the enterprise Java and probably deservedly sow.

However things are shifting back towards needing complex requirements because people want their cloud stuff to have elasticity, reliability, failover, etc (aka zookeeper) and that shit requires complexity.

People complain about the complexity of Java but I honestly think modern frontend web development is so awful today that I would take even old shitty j2ee over it almost any day (well maybe not that far but close to it).

[1]: http://seriot.ch/parsing_json.php

> YAML is so much more complicated and harder to parse.

That's only true if you stray far from the core. If you stay to the language agnostic parts, it's clean and readable.

> The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML

As if developers like HTML any better. I agree with you about XML being useful because it's easy to parse and the XML hate is overhyped, but that's not what he's saying, he's complaining about configuration hell that seems intrinsic to the Java ecosystem as compared to something like Rails which relies far more on convention than configuration. That's a cultural problem, not a language problem.

There are pros and cons to both ways (aka convention over configuration). That is hiding configuration complexity often get fixed with even more internal complexity except now it is hidden.

With hiding configuration your ramp up time decreases but your overall understanding of how the library/framework may decrease.

To offer the advantages of both requires even more complexity.

Which is actually what happened with Spring Boot. It is the Ruby on Rails of Java now and it is far more complex internally than the olden days of Spring 2.0 explicit XML.

At times I miss the old school Spring XML way. There used to be only like 4 tags (bean, property and include).

You're missing the forest from the trees. Java libraries and frameworks are complicated because Java the language is not expressive enough.

As I like saying, the status quo in Java land is Spring and Hibernate and people bemoaning Scala's implicit parameters never wonder why such monstrosities like Spring or Hibernate happened. Sure, blame the culture, but that's only half the story.

The same thing happens with other inexpressive languages. One of them is Python. And here we disagree again, as I think Python is chock full of ugly parts.

It started with refusing powerful and multi-purpose language features, like multi-line anonymous functions. As a result Python has been patched repeatedly with multiple non-orthogonal features to supplant the need for multi-line anonymous functions and/or to make up for its statement oriented nature. Oh, now Python 3 got await/async as well, but somehow I don't think this will stop people from monkey patching the socket module. I'm going to make the claim that in fact Python is not a TOOWTDI platform, in spite of its much touted "spirit" and anybody making that claim never tried working with Gevent or Eventlet, trying to make it work with MySQL's client and being forced to use the native client because Django wasn't compatible with the pure one. Or with an N-th iteration of Ruby inspired libraries that hack into its meta programming features to make it smell like the DSLs in Ruby, but with limitations and leaks. I don't even want to talk about the build and dependency management tools in Python's land, because it should be self-evident how broken the Python ecosystem has been.

Another language in this category is Go. It's still young enough that people haven't used it much outside the niche it was created for and doesn't have much reuse going on in libraries. Give it time, you'll see the same pattern, same mistakes repeated again and again. Java was also a pioneer in dealing with concurrency, Java introduced generics really late and it was also built by famous engineers working for a sexy company, designed to appeal to beginners and managers.

No. It's not the Java language. It is the developers. They are the ones who have to have 35 levels of abstraction. Why? Because for some reason they think this will make modifying the software they write easier. In reality, no, it doesn't because everyone gets frustrated wading through the abstractions. If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in, then it is really hard to make any real changes to the code.

> They are the ones who have to have 35 levels of abstraction.

Have you seen FizzBuzz: Enterprise Edition ?

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

haha thanks for sharing that, one of the most absurd things I've ever seen. Every once in a while I think about picking up Java or .NET and going for the enterprise-y jobs...no thanks.

I'm going to be laughing about this for days.

its beautiful, not only is it absurd and hilarious, but it says so much. Not as a direct diss to java, but how badly a simple task can get over-designed to the point of being indecipherable. What would be great is if they added some kind of CRM or e-commerce to it, and donated the proceeds to charity. So like, could "Pay as a service" or sign up for "fizzBuzz as a service" and pay to run fizz buzz up to certain limits.

It's not a language causing shitty abstractions, it's not a framework causing shitty abstractions. It's shitty developers.

One can write a Java application and never touch XML, use AbstractFactoryWhateverTheFuck, and write sane, clean code. I've done so for years, worked on green and brown-field projects. I've also written, maintained, and modified monstrosities in Java... as well as C#, Javascript (front and back-end), PHP, Python, and plenty more.

Java is not the Hot New Thing™ and never will be. It's also not always the answer, but for a run of the mill application running on a web-server you're going to have a hard time finding a better language and ecosystem that will keep on trucking and be reasonable to work with.

The presence of many of these frameworks, spring, AOP etc, is proof that many people do not find Java reasonable to work with. If Java was sufficiently expressive, you would need only libraries.

What, specifically, about having a framework means the language is not expressive enough?

Not parent, but for example, this is how easy serialization is in Scala Play in the majority of cases:

    case class Person(name: String, age: Int, likes: List[CustomObject]) //simple data object
    implicit val personFormat: Format[Person] = format[Person] //this creates a "Format[Person]" with serialize/deserialize methods

The code to generate a serializer/deserializer is completely independent from the definition of the data, no annotations or XML needed. It is also efficient in that it doesn't use reflection. This is only possible because of how expressive Scala is - macros and strong type system means a lot of powerful code introspection can be done at compile time.

Because of implicits, most of the time I write that one line above, and an HTTP handler as a simple function from (Person => HttpResponse) and dont even think about the serialization/deserialization. And that one line is not an opaque abstraction, it is very customizable if you need it to be, and all via code not config.

Using Jackson in Java can get much more complex because annotations and XML files creep across the whole code if you want compile time generation. I think this is directly because Java's inspect/generate code at compile-time is not as powerful as macros.

Frameworks do not compose. Libraries do. If you need a framework, your language has failed.

No one needs a framework, but if one makes things easier then what is the problem?

What, in your mind, is a good language that needs no framework?

Everything has a cost. As I said, frameworks do not compose and often fundamentally take away control. If you want to change the behaviour of your framework, you need to hope they have created the necessary callback interfaces.

> If I can hold ten items in my brain's working memory and all ten are taken up by keeping track of how many levels deep I'm in...

If you find yourself doing this, it is a clear indication that the software design is failing to abstract properly or at all.

(I'd argue that the industry in general has a terrible ratio of "coders" to people who can design programs, thus you're much more likey to come across poor designs than good ones. Beware of this when judging programming languages.)

> a clear indication that the software design is failing to abstract properly or at all

I believe, it is an indication that people tried to fix all the leaks in the abstractions, which turns the abstraction into an ugly twin of the stuff it tried to simplify.

ORMs are a good example. They start easy and simple, but lack various features of full SQL. If you start a new project, the ORM is fine. At some point, you are forced to use plain SQL, which clashes horribly with the ORM concepts. Thus the desire to extend the ORM. Over time more and more features are bolted on and the complexity grows.

IMO that's still bad design on the end user of the ORM library. There's a time and place to use tools like Hibernate, but it became fashionable so it's used all over the place where it doesn't fit and has created huge messes.

There's a really bad trend in the industry of choosing libraries or tools based on trying to improve your resume, rather than trying to find the best solution to a problem.

I've worked with a number of ORMs, mostly home-grown, admittedly.

I've yet to see a good one.

Often ORMs fail to implement JOINs efficiently.

Every ORM fails to give you a powerful query language: if they had a powerful query language, someone would write an ORM for the ORM, because the reason ORMs exist is that "SQL is hard", as the doll says, and any powerful query language will get the same treatment. But SQL is not really hard, and not having SQL eventually means you pay a huge price.

And then there's things like LDAP, which are absolutely awful. LDAP's object naming scheme has no canonical text representation. Let that sink in. And that's not even the main problem -- forcing your database to be hierarchical and a collection of objects, with no standard relation/pointer type, is. (Yes, Active Directory has an Object DN type, I'm aware.)

Just say NO to ORMs.

This is a well known issue [1], and isn't due to ORMs being poorly written.

It's not true that people who know SQL always prefer using it to using an ORM. In one of my prior jobs we had strict controls on the queries that ran in production for performance reasons. We screened all of the query plans the planner generated, but we also used an ORM. Sometimes we needed to work around or even reimplement the queries that used to be in SQL due to niche features like index hinting or the HAVING clause. And yet usually we used the ORM because it was more concise and reduced manual mapping of columns to fields.

[1]: https://en.wikipedia.org/wiki/Object-relational_impedance_mi...

Absolutely, just look at all the Hadoop users who don't really have big data.

I disagree, it is some developers. Just as some developers can create a big ball of magic code dynamic code or as some developers can make insanely cryptic code in Scala/Haskell that looks like the user is typing in windings.

Java 8 and the current ecosystem can be incredibly lean and devoid of high levels of abstraction. Like today how I took the lovely Sinatra inspired http://sparkjava.com/ out for a spin. I think if Java can shed the memory of it's horrible past (and the enterprise space was truly bad) then it has a lot to offer developers these days.

I agree that there is a Java culture, but I also think that it developed into the way it is because it was so popular during a time when there werent very good engineering practices by non-technical people. The movement towards wanting managers with a technical background I think is fairly recent. The majority mass of java developers now probably "grew up" in the jaded horror story environments we seek to avoid.

Also, i think new grads tend to only know how to make things dry via abstraction (not considering the trade offs) and b/c of javas popularity and oop as a buzzword, always did it via inheritance.

I'm not sure you can really separate the two. Sun pushed out the language and also helped develop much of the culture (enterprise beans, the pet shop example). Languages shape peoples thinking.

Java libraries are complex because Java is inexpressive? Not because the libraries attempt to do everything for every situation? Are there some concrete examples you can point to?

It has been my experience and observation that something like a JMS library in Java are complex because of a different interpretation of "do one thing and do it well." In the Java world, possibly because of enterprise adoption, that means pluggable transport for the queue, pluggable aaa, pluggable security and encryption, pluggable durability storage, configurable delivery protocols and guarantees, aspect based hooks to support different ha patterns, pluggable dispatch on delivery and probably some other things I can't think of this early in the morning. Each JMS implementation is "the best damn message queue ever made" with tons and tons of features. That's not an expressiveness issue, unless it's too expressive. Java makes it easy to add a layer of abstraction at each of those decision points. The typical user here wants to get a message from one piece of software to another, maybe with ordering; JMS will do that more ways than you can imagine or care about and can use pieces of machinery you didn't even want to know about. Where does expressiveness play in to that?

> Java libraries are complex because Java is inexpressive? Not because the libraries attempt to do everything for every situation?

Why do these reasons have to be mutually exclusive?

Furthermore, your second point relies on every single cumbersome/complex java library also being a perpetrator of trying to do too much. Surely a lot of people here can probably think of smaller libraries that explicitly don't try to do everything, and are still "complex" and cumbersome to use. The best examples I can think of were of internal libraries at previous jobs, and that happened across many languages not just java. These sorts of annoyances pop up repeatedly in a wide variety of languages, despite not necessarily having the same culture as java.

Not to play evangelist here, but I just haven't had as many of these kinds of issues with libraries since switching to more modular typed functional languages (i.e. ML/Haskell), and it has really played a role in helping me see the forest instead of the trees. Noticing how language complexity and inexpressiveness leads to those kinds of problems isn't supposed to be obvious or intuitive, because it's effectively a Butterfly Effect that causes most of its severe repercussions much further down the line. We can play whack-a-mole with smaller sources of complexity (such as java having kitchen-sink libraries) as long as we like, but shouldn't the goal be to hunt down where all those "complexity moles" are even coming from in the first place? Because if that is the goal, and even smaller more focused libraries still produce annoying amounts of incidental complexity, then there's not much room to blame anything other than the constraints of the language at that point.

> Java libraries and frameworks are complicated because Java the language is not expressive enough.

I have written Java code and rewritten code large parts done by others. The issue I have noticed is architecture and framework mindset of people who just do not think solving problem at hand is important and good enough task. It would be ok if they wrote elegant library/framework but it was still junk and solved only very narrow problem. At each instance it was the problem of culture and people using Java because I was perfectly able to write productive and simple code with just standard plus very few extra libraries.

> Another language in this category is Go. It's still young enough that people haven't used it much outside the niche it was created

Huh, may be you should be able to give example of highly expressive and popular languages which are a hit with developers in very different domains. Because it is easy to pile on popular Java and increasingly popular Go without talking about alternatives.

No Java is simply not expressive enough, that's why so many frameworks exist. Adding Lambdas certainly helps, but you are missing out if you restrict yourself to Java.

Let me give an example of how Java limits ones thinking.

Look at these Stack overflow answers: http://stackoverflow.com/questions/28459498/why-are-java-str...

They are great examples of Java/C# users being unable to explain succinctly what the APIs are doing, because they lack the necessary common language. They have to answer with great essays describing various scenarios and use cases.

A Haskell user just needs to compare the type signatures, showing where the IO is happening. She will then understand the differences and the implications.

I guess I am not obsessed with expressiveness. I think of programing as something to help business/users to get on with what they want to do, as opposed to exercise in elegant self-expression. Towards that goal Java, Go seems very fine languages to me.

But as my example pointed out, expressiveness is often the difference between being able to understand something and not. Expressiveness permits better abstractions, better composition and better libraries, allowing cheaper and faster software. Something business users will appreciate.

I do not disagree that Java, Go could be better. It is just that I remain big sceptic because such better languages leaves very important things which matter in real world and covered by Java, Go etc but not by better languages e.g tooling, GC, powerful runtimes, build tools and so on.

I would wait till Scala does something great natively without standing on shoulders of JVM/JRE etc.

Python does not lack power. It's a different problem.

Monkeypatching is everything you need in terms of power. The problem is that it is too powerful, and Python lack intermediately powerful constructs. So if you have a problem that could be perfectly solved by passing around anonymous functions, creating a DSL, or writing some macro, you will either write everything by hand, Java style, or use monkeypatching and get a mess of mutable code.

Still, monkeypatching will solve the problem. It is more powerful than any of those other features. It's just that killing your fly can be best done with some small tool, and cannons leave a mess wherever they are used.

The last time I looked at Python (which was something like a decade ago) the impression I was left with was that there was a sort of cognitive dissonance or collective self-deception going on. There was a simple, clean language subset which was the one presented in the official tutorial, by and large; and lying underneath there was another language full of introspection and underscores, which seemed to be necessary to get (many) things done without a boilerplate explosion. The impression I got was that everyone writing Python was convinced that those other guys didn't need to think about these dangerous, advanced features, but they were in the 10× hacker elite for which the power was necessary and appropriate. Now probably that's an exaggeration and somewhat unfair, but I think it's probably not completely wide of the mark. ;)

My experience with Python is that 90+% of your code base can be in the "nice" subset, but it requires some discipline. The key is to always, always, always encapsulate the complex parts in helper functions or libraries, and accepting that maybe it isn't worth making your code twice as complicated to save a single line.

The official answer from any Python developer to anybody asking about "magic" is "do not use it". It's simple, gets the message across, and when the ones asking are experienced enough to not need asking about it, they'll just be one disaster away from being experienced enough to know when to use it. (There are plenty of resources on how to do it. Just no assurance that you should.)

Overall, it's a more useful response than the Ruby's community one. Ruby seems to have inherited the Lisp propensity of meta-programing everything so many of its basic libraries are incredibly hard to follow. Even with Ruby's metaprograming features being easier.

Still, providing safe metaprograming features sidesteps everything. I do love Haskell.

Go is as old now as Java was when Spring and Hibernate started to appear on the scene. If it time leads to this kind of pattern, why was Java 'over the hill' by this age, yet Go is still considered young?

Java was adopted very rapidly (as soon as it ran acceptably on commodity hardware) because the industry desperately needed a safe subset of C++. The pain point addressed by Go is mostly deployment and packaging, which is why mostly devops (who have rejected OS packaging for some reason) are excited about it.

> The pain point addressed by Go is mostly deployment and packaging, which is why mostly devops (who have rejected OS packaging for some reason) are excited about it.

What happened to OS packaging was mostly a result of the arcane tools around .debs and .rpms, which led to sysadmins reinventing the wheel (poorly) using symlinks, tarballs, and shell scripts.

FPM helped to a great degree, but even then, what if you want two different versions of the same application on the same machine? And if you hack your way around that, how will you manage which instance of the application gets which port?

When Docker came out, that kind of ended the idea of using OS packages for deploying in-house applications. Why bother with a packaging infrastructure that will only tie you to a certain OS?

I still think OS packages have a place, especially for system level software. Nobody ever complains about how SSH failed to install or upgrade...

But even when using containers for internal software, Dockerfiles can still be a pain to deal with for the simple reason that most languages have horrible build-chains that produce unusable outputs, which as you said Golang addresses beautifully.

However I think you're off the mark when you say "mostly devops" are excited about it. It's entire companies that are excited about it, and for one simple reason: Languages with these bad build chains and bad outputs have led to the creation of an entire teams of people to deal with it.

The realization of this is spreading, and it's going to be an interesting time.

Java had widespread adoption.

But, if Go hasn't already achieved the same kind of adoption after this many long years, doesn't that suggest that Go will always be relegated to the niche it was designed for? In which case, according to the parent, it won't need to adopt those patterns in the first place.

It was always fashionable to hate java. Java was bad and old pretty much right after being born.

i think java came up when oop was being hyped (the nominative subtyping variety) and design pattern mania ruled the land.

such things are less en vogue these days.

That is an insightful comment. What languages do you consider (most) expressive?

Are you saying Scala got it right? What's your take on Kotlin?

Kotlin is a cool language, but doesn't do enough to differentiate itself from Java 8.

There are real benefits to picking the mainstream / popular option, which includes tons of documentation, forum discussions, books and developers available immediately for it. So when you go against the mainstream, those alternative tools have to be worth it.

I think Scala got over the worthiness threshold, by exposing one of the best OOP implementations exposed in a static language, sane generics, higher kinded types and implicits which make it possible to encode type-classes, which led to a community emphasizing on functional programming.

I think Kotlin isn't over that threshold. Some people view its thin layer approach to be an advantage. But it either has to evolve in being more than that, or to divorce itself from the JVM, because it is in direct competition with Java 8 otherwise. Evolving to be more than a Java++ goes against its own philosophy. Divorcing itself from the JVM is a work in progress, they also have a Javascript compiler, but the results aren't convincing enough for now.

It's a nice language, but personally I like those with a strong community of functional programmers and libraries. If I'll see http://typelevel.org for Kotlin, I might reconsider.

> but doesn't do enough to differentiate itself from Java 8

Short of implicits and higher kinded types what has Kotlin not yet copied from Scala? FP in the pure sense is still very much niche, nobody cares about Scalaz and Cats in Java land.

Providing a less powerful Scala as an alternative to Java might very well prove to be a great strategic move. Scala's certainly not going mainstream anytime soon, probably in part due to its being too powerful.

Going on 6 years in Scala, staying put for now, but will jump ship if/when something better comes along (for me Kotlin is not it).

I find Scala enormously impressive because it manages to bridge the gap between subtyping. Not sure whether that is worth the complexity this brings, though.

Subtyping makes a lot of things that are easy in purely functional languages hard. I think that is also the main reason why you don't get global type inference.

Thinking of it, SOAP is the most Java-like thing taken to the extreme that I can think off.

Needlessly complex, dozens of imbricated layers that no one knows why they even exist, cult of "the library and server will do it for you, you don't need to know how that works", and when the library invariably fail on some obvious stuff you're left hanging with inscrutable XML files and no decent way to debug the exact layer that fails, with every thread mentioning that issue on the web being met by a variation of "you shouldn't be doing that" or "add this additionnal middleware layer to solve it"

All of that to send two ints and get one back.

Hehe, yes.

I had to write a SOAP endpoint last week, because the dev in the other company didn't like REST.

It was just one endpoint, that took a set of values.

Took me a few days to get the WSDL right, because no good examples or tutorials were to be found...

In the end it took me 80% of the time to figure out that I had a wrong XMLSchema version used to define my types. Only some heavy XML IDE found this bug, all validators just told me that I didn't define any types, haha... well at least I learned something in the process :)

Yeah my first project ever on Java was an API with Spring Data Rest connected to Oracle. 80/90 percent was config and issues w connecting to Oracle. Spring Data Rest was very nice.

I take it you prefer CORBA?

Oh man! I'm old enough to having coded CORBA in Java and in C++. I'm glad we aren't stuck in that era.

Very cool.

The beside my SOAP project last week, I only heard about SOAP and CORBA in university distributed systems class and that was ten years ago.

How is CORBA worse than SOAP? :D

SOAP is worse than CORBA in roughly the same way dying by falling from the Empire State building is worse than dying by being run over by a bus.

I had to deal with CORBA 6 months ago in the large scale architectures class at my university. I'm _very_ glad that class is over.

I admit to never having to tame that particular beast. And given the sub comment about it being on the same greatness level as SOAP, I think I may pass :D

Yea, the hobby projects I do using the JVM (currently working on a side-project written mostly in Clojure) look completely different from the eleventy-layers-of-abstraction design-patternsplosion programming-in-xml garbage you're forced to work with at your typical Java shop.

The culture in Javaland is a huge problem, and Scala doesn't really help with that. I'm constantly butting heads with Software "Architects" because, among other things, I tend to prefer building my programs using small libraries rather than uber-frameworks like Spring. I suppose my main problem is that I didn't start my career in Javaland, so I didn't get indoctrinated properly.

I'm not sure if it's a question of indoctrination; I'd prefer to think that it is much more a lack thereof. Many things are "developed" without any appreciation of elegance - and the bit of old, overdesigned and overcomplicated C++ code I've seen tells me that Java's culture problem just stems from everyone moving away from there and continuing their style in Java-Land.

No language will ever be able to combat this - the only strategy you can have is to make your language so different and confusing to regular people that they won't use it; but I doubt that would result in good languages being created.

If you have a look at how modern C++ is presented and explained nowadays, there's much more focus on readable/useful code and actual design. Many language communities go this route (Clojure, Python, what have you), but that doesn't stop the average Joe to ignore those advices it if he so desires.

Add in some crunch time where everything must be implemented ASAP and without consideration of the consequences and voilà: You end up shovelling snow around[1].

That being said, I especially like Clojure's approach to things. For example: Turns out good, maintainable C++ uses const almost everywhere - to avoid messes, you try to encapsulate mutable parts as much as possible (unless performance dictates otherwise). This is a thing that is still very clunky in C# and Java (and it seems very much overkill to use virtual inheritance for this. Say hello to IReadOnlyDictionary<T>). In contrast, Clojure makes almost everything read-only and uses mutation at very specific points. This is great - although of course you won't be writing any high fidelity videogames this way.

Edit: Of course, when I say elegance, I realize that it's very hard to get actual things done from the Tower of the Elephant Tusk[2]. But yeah, stopping once and a while to understand/consider your problem and possible implications of your implementation gets you a long way.

[1]: http://gizmodo.com/programming-sucks-why-a-job-in-coding-is-...

[2]: http://thecodelesscode.com/case/143

> The problem seems to be that Java devs like to create things more complex than they need to be.

This is the biggest myth! Like seriously how does using a particular language make you want/enjoy making things more complex?

Why is Java (ecosystem and language) complex? Because Java has a massive very old ecosystem with organizations that have extremely complicated requirements.

Someone else argued Java is complex because it isn't expressive. This is a myth as well as clearly Go language proved you don't need powerful types or annotations to be simply.

Let me give you an example. The Java JSON parser Jackson. It is beloved and yet It is seriously freaking complicated!

Why is it complicated? Well lots and lots of organizations have different requirements.

Most of the libraries in Java that are mature are extremely complicated! They are this way because of requirements and evolution.

Scala is complex but it hides it (and I guess some would say elegantly). I prefer being explicit and so do many Java programmers consequently the complexity is sadly exposed.

There is another language rapidly evolving on the complexity front: Javascript.

The ramp up time alone with modern Javascript is now close to being worse than Java (the transpiling, tools, etc).

>Like seriously how does using a particular language make you want/enjoy making things more complex?

It's not the language, it's the community that uses the language. It's working with people who tolerate working in that language and with that sort of people. The Java community drives out developers with an aesthetic revulsion for things like a ShoelaceTyingStrategyFactory, and you're left with the dregs.

In short, the causation is backwards - folks who want to or enjoy making things more complex end up using Java more often.

> In short, the causation is backwards - folks who want to or enjoy making things more complex end up using Java more often.

That is complete utter nonsense. Developers most likely use Java because

1. they have to which is the case for Android or using existing libraries/code base or

2. because they already know it which is typically caused originally by number 1.

3. The language is still one of the popular language so for many it is a safe bet.

As for ShoelaceTyingStrategyFactory... I have seen that crap in Typescript, I have seen it in C#, I have seen it in Objective C... Its caused by complex annoying needless requirements.

See what happens with Java can happen with any language where you are don't have a proper development process of removing needless requirements. You end up with complexity. And yeah sure some people enjoy solving complex things and making it scale but the neither the language nor the community caused that.

Now if you are talking about the spec writers like the JSR authors... yes those guys actually had it in there interest to make it complex because their company would be the only company that could make a reference implementation (for example Day software with JSR 283). But this is not the Java developer community as a whole.

I'm making the exact opposite point. People use Java for whatever reasons, it's not really a contributing factor. People avoid Java because of ShoelaceTyingStrategyFactory reasons. How likely is the average Java developer to make a ShoelaceTyingStrategyFactory when you convince the vast majority of people who avoid that sort of thing to use a different language?

> Why is it complicated? Well lots and lots of organizations have different requirements.

A sane culture would produce couple of simple libraries solving different requirements. Insane would throw solutions to all the requirements and a kitchen sink into one big ball of mud mega-library.

It's not that hard to write a JSON parser.

> A sane culture would produce couple of simple libraries solving different requirements. Insane would throw solutions to all the requirements and a kitchen sink into one big ball of mud mega-library.

Even Spring doesn't do this. Most Java libraries and frameworks are highly modularized via Maven.

Most complain they are too modularized and want an uber jar.

> It's not that hard to write a JSON parser.

Actually it really is [1]. You know a valid one that handles edge cases... something a lot of Java libraries do really well... handling edge cases requires complexity.

[1]: http://seriot.ch/parsing_json.php

Java frameworks are made for very large enterprise systems operating at high scale. Not for startups or POCs or personal projects. Frameworks for that actually exist in Java too, but they are harder to find.

Once you know Spring, it actually makes you faster at building robust systems. Hibernate too, though SQL is easy enough I'd recommend against it, but c3p0 is a must for robustness, and hibernate does make it easy to switch to it.

Now, Java is akin to PHP in that a lot of devs use it at small to medium size companies that don't always value tech. This means a lot of Java is written badly, concepts are misunderstood, best practices like layered architecture, interface indirection, class inheritance are pushed to extreme nonsense and abused greatly.

Kafka and Zookeeper and Maven are hard to setup, but it's because they solve very complex prolems. I don't know any other open source dependency manager who offer the robust features of maven like self hosting, build and dependency resolution all in one and signed artifacts. Zookeeper is like the only coordination frameowrk that passes Jepsen. Kafka is unmatched in its special use case too. You're playing with framework handling highly complex problems, you shouldn't expect the easiest learning curves.

Why are you even playing with these? There's very little project that would need such beasts.

Come over to .NET and in particular F# - things are way nicer here :) FSX scripts are becoming a way of life for many.

Not really. .Net devs (C# in particular) still love their levels of abstraction.

More application layers!

i am looking forward to a stable and reliable .net for os x and linux. after that i really want to give f# a try.

.Net core has been very stable for me so far!

Edit: but it doesn't run F# yet

Well it kinda actually really does...

I've always said Java was the first language ecosystem that let developers write code they neither understood nor could manage. I've been doing this long enough to remember what life was like pre-Java, and I did not at that time have a lot of conversations with developers for which their contribution was "I just use the foo framework, I don't really know anything about it."

So congrats to Java for helping shitty devs get shitty code to production faster.

I remember saying python at an IT company once and they were about to expell me from the building. Their face showed à deep '3 seconds of my life wasted'.

It's really sad.

So many cool things have been build with Ruby, JavaScript, PHP and Python...

At university my OOP professor was all about how these languages aren't "real" programming languages, like Java or C#. And when I meet people working at older IT shops, that do Qt or Java, they all feel superior.

This chauvinism is a real danger to the industry.

How intellectually lazy of a developer do you have to be to use Java, stick with it and think you are better for using it than other choices? Wonder if your prof has ever even tried paradigms other than OOP

He also does FP classes. I think his distaste was more about dynamic typing than about non OOP languages.

> The problem seems to be that Java devs like to create things more complex than they need to be.

This was my experience as well when I first tried to experiment with Kotlin for backend web development (coming from a py/rb/jS background).

I would still happily use Kotlin if I had to be on the JVM, but I came away with the impression that most – certainly not all – of the libraries and tools in the ecosystem are... not to my taste.

Out of curiosity, what is the scale of the projects you've used these technologies on? LOC, concurrent users, years of operation... As you can probably guess, I suspect that Java and it's ecosystem are created for a different scale, where this abstraction suddenly ceases to be excessive.

I suspect most Java devs "think" this is the case and do this "abstractions for big scale" all the time, even if 99% of the project would do better without it.

May be. I have a different perspective - I'm now supporting a legacy NodeJS project which would desperately need more abstraction, but the original author was really into "getting things done" mentality and didn't think about future maintainer (me) at all. Magic strings, implicit hierarchies, code duplucation, different entity id scheme on client and server with hackish "translations"... I would give a lot for my project to have a little more of this Java "Enterprise" style right now.

Pretty much hits the nail on the head.