7 ms·

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, t

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.

exceptione 10y ago
That is an insightful comment. What languages do you consider (most) expressive?
JustSomeNobody 10y ago
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.
- 67726e 10y ago
  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.
  - willtim 10y ago
    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.
    - 67726e 10y ago
      What, specifically, about having a framework means the language is not expressive enough?
      - willtim 10y ago
        Frameworks do not compose. Libraries do. If you need a framework, your language has failed.
        67726e 10y ago
        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?
        willtim 10y ago
cutler 10y ago
Are you saying Scala got it right? What's your take on Kotlin?
- bad_user 10y ago
  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 http://typelevel.org for Kotlin, I might reconsider.
  - virtualwhys 10y ago
    > 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).
- Tarean 10y ago
  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.
geodel 10y ago
> 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.
- willtim 10y ago
  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-streams-once-off 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.
  - geodel 10y ago
    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.
    - willtim 10y ago
TheCondor 10y ago
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?
- axlprose 10y ago
  > 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.
marcosdumay 10y ago
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.
- leoc 10y ago
  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. ;)
  - plorkyeran 10y ago
    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.
  - marcosdumay 10y ago
    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.
randomdata 10y ago
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?
- hnbroseph 10y ago
  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.
- felixgallo 10y ago
  Java had widespread adoption.
  - randomdata 10y ago
    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.
- deleted 10y ago
  [deleted]
- prodigal_erik 10y ago
  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.
  - elsonrodriguez 10y ago
    > 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.

exceptione 10y ago

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

JustSomeNobody 10y ago

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.

67726e 10y ago
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.
- willtim 10y ago
  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.
  - 67726e 10y ago
    What, specifically, about having a framework means the language is not expressive enough?
    - willtim 10y ago
      Frameworks do not compose. Libraries do. If you need a framework, your language has failed.
      - 67726e 10y ago
        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?
        willtim 10y ago

cutler 10y ago

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

bad_user 10y ago
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 http://typelevel.org for Kotlin, I might reconsider.
- virtualwhys 10y ago
  > 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).
Tarean 10y ago
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.

geodel 10y ago

> 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.

willtim 10y ago
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-streams-once-off 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.
- geodel 10y ago
  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.
  - willtim 10y ago

TheCondor 10y ago

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?

axlprose 10y ago
> 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.

marcosdumay 10y ago

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.

leoc 10y ago
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. ;)
- plorkyeran 10y ago
  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.
- marcosdumay 10y ago
  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.

randomdata 10y ago

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?

hnbroseph 10y ago
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.
felixgallo 10y ago
Java had widespread adoption.
- randomdata 10y ago
  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.
deleted 10y ago
[deleted]
prodigal_erik 10y ago
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.
- elsonrodriguez 10y ago
  > 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.