13 ms·

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework th

I fantasize about rebuilding the java ecosystem. Create "JPM", don't allow anything from the old Maven system in it. Create a new "hip" minimalist framework that ignores everything about java and its notions of OOP. Basic dependency management handled NPM-style. Developers encourage to put everything in the same package for their own stuff, and everything is package level. Getters and setters and encapsulation and java's poor implementation of OOP ignored. Heck, fork Spark, split out the individual pieces as modules, and start there. All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte. I'd argue that java is a better back end language than javascript in and of itself, but that the community norms have led to the pain we see. Have an extreme preference for 1.8 code (IE, the new java.time system) and away from anything bloated. Rethink for the common use cases, rather than trying to support everything under the sun. Spring still exists for that, after all. :) The problem with java isn't that it's a BLUB language anymore, but that it's a BLUB ecosystem. I'm not saying the language is perfect, but Java 8 as good as ruby or javascript for web development if the ecosystem is ignored.

fat0wl 13y ago
Hear hear. When I read about JVM performance issues I usually immediately think "team of 20+ complacent corporate devs who don't care if this succeeds or not because they can get a new job insanely easily at a moment's notice". The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" language) if the app does anything substantially complex. A ton of the hip web tech is basically for building front-end and cobbling together relatively inefficient backends. I was an RoR guy myself but moved to Java & I see the correct hipster tech here but just lacking unanimity. I bet if the RoR community decided "Clojure hell yea" or "Scala hell yea" and contributed lots of plug-ins to those ecosystems, they would generally have similar development times with a lot of performance gain for free. I'm thinking about trying Play framework on Heroku just to see what the monthly bills & New Relic readouts look like in comparison.
- cloverich 13y ago
  Here's[1] a comparison of the two from an RoR guy who used Play! (with Scala) for 16 months. I found the ensuing discussion pretty informative with minimal FUD / bashing. [1]: https://groups.google.com/forum/#!searchin/play-framework/play$20vs$20ruby$20on$20rails/play-framework/F72DYs2MPsA/f_ol4AZplz0J https://groups.google.com/forum/#!searchin/play-framework/pl...
  - fat0wl 13y ago
    Thanks but I've seen a lot of similar comparisons and they seem to focus on trivial things :/ For example the portion about "Asynchronicity" is a brief paraphrase like "Play is good in Rails its awful or doesn't exist". Performance isn't even mentioned really. I find that with Rails apps a lot of development effort is put toward optimizing for scaling rather than complex logic, where Play could potentially be stronger. A lot of the comparisons seem to be posted by RoR devs who are looking at Play as a potential new framework for a CRUD app with a very fancy UI. In my mind that's not what it is... I read a few articles about corps using it for big distributed apps with a lot of eventing. So I guess it's a bit of my personal taste but I just don't see "Rails has HAML", for example, as a reason why it's better given that HAML would be pretty trivial to implement in Play if the community wanted it. Full-featured CRUD frameworks vs. enterprise-ready app frameworks are very different ideals. They each have their place but if one tech were to emerge as really superior I think it could easily integrate all the bells & whistles that rapid CRUD devs like.
    - porker 13y ago
      > looking at Play as a potential new framework for a CRUD app with a very fancy UI. Do you know of any frameworks that are good for that (but let you easily reach down for complex logic, e.g. where data processing or AI is needed)? Every project I do needs some form of CRUD, and making it work AND be pleasing to interact with takes a lot of time. I don't mind the language, just someone, somewhere must have solved this already...
      - fat0wl 13y ago
zaphar 13y ago
Java has always been a good language if you ignored the ecosystem. The ecosystem is a large part of what defines a language though. You have to take care in how you define that ecosystem. I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.
- gngeal 13y ago
  Java has always been a good language if you ignored the ecosystem. You mean "no unsigned types (even though the language is essentially machine-level when it comes to integers), no compact memory layouts for aggregate data, no useful function values without jumping through hoops etc." is an approach that leads to good languages?
  - yareally 13y ago
    I think he's alluding to the stuff that comes after the language is released, not the language design/architecture itself. Node is not a language, so his comment probably implies that he's referring to the design choices of build system, development cycle (of tools, libraries and frameworks), and things like dependency management. That's not my opinion, but just what I understood his comment to be about (personally I prefer the npm approach any day over Maven).
- dustingetz 13y ago
  A language IS its ecosystem. In 2013 java is a good platform.
  - rbanffy 13y ago
    I believe the ecosystem mentioned is the consistently over-engineered AbstractFactoryFactory mindset that permeates so much of the Java space.
pron 13y ago
I think that much of your fantasy is already a reality. For example, look at how Dropwizard[1] assembled a best-of-breed collection of modern Java libraries into a small, yet very powerful, REST micro-framework. So the bits and pieces are certainly there, and even the JCP does good work sometimes (JAX-RS) that becomes good standard APIs with many different implementations. [1]: http://dropwizard.codahale.com/getting-started/ http://dropwizard.codahale.com/getting-started/
- nogridbag 13y ago
  Ninja web framework [1] is also worth a look. It's similar to Dropwizard in that it's less of a framework and more like a well thought out archetype building upon the best Java libraries. Two main differences I see are Ninja uses Guice for DI whereas dropwizard is manual DI. Dropwizard uses JAX-RS while Ninja has its own Play 1 style routing system. While I really like JAX-RS, the reference impl Jersey uses HK2 for dependency injection, which makes it odd to integrate into a Guice application (in fact Guice support is still lacking with Jersey 2.x). [1]: http://www.ninjaframework.org http://www.ninjaframework.org
- candl 13y ago
  Dropwizard is pretty great, but one unfortunate aspect is that it's stuck with Jersey 1.x for JAX-RS and as a result is missing some nice features, like async responses, etc.
  - pron 13y ago
    I only used it as an example to the fact that modern Java libraries bear little resemblance to those of yesteryear. I do, however, think that standard JSR APIs are still really nice to have, if they're good.
- ebiester 13y ago
  Dropwizard is a bit heavy by Node standards. The health checks, in the NPM-style system, would be its own package. The configuration class would be its own package. Resources would be their own package. Liquibase or Freemarker wouldn't be built in, nor would JDBI. I think of Dropwizard much like express for node, and most of the "cool kids" in the node community think that that's just too much for a single library. I like Dropwizard, don't get me wrong, but it isn't quite a micro-framework by other standards.
radicalbyte 13y ago
You've basically described C#: Getters, setters fixed? Check. Functional features? Check. Most crappy OO features fixed? Check. Trendy package system inspired by npm/apt-get/gems? Check. Healthy community with libraries replacing frameworks? Check. I'd recommend checking it out if you haven't already.
- mynames 13y ago
  Could you expand on "crappy OO features"?
- lightblade 13y ago
  I also like to know more about this C# package system you mentioned.
  - Glide 13y ago
    I would imagine he's talking about NuGet. Unless I've missed something dramatic in the past half year in the .net ecosystem.
- edwinnathaniel 13y ago
  Your package system is inspired by Maven, minus a good build system and other functionalities. Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair. Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosystems have NODA/JODA lib). C# is just Java with 10% syntax improvement and -30% to -40% productivity lost when it comes to everything else.
  - barrkel 13y ago
    C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way. The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor is it particularly good as a build system.
runT1ME 13y ago
So why not scala? Scala 8 years ago is where java 8 is now, and you can ignore most of the java frameworks.
- pron 13y ago
  Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast altogether. You can love it or hate it, but even its most enthusiastic fans would concede that it is most certainly not appropriate as a replacement for Java in some/many/most (depending on your view) circumstances. Also, Java is extremely popular, and some of its most painful points have been addressed in Java 8. Even an arguably better language (regardless of its name) will not easily replace Java. Hey, look across the browser at JavaScript. There are arguably better languages there; are they replacing JavaScript? If you look just at GitHub – which is greatly skewed towards new languages – you see that all other JVM languages put together make about 10% of the JVM ecosystem, with Java being the 90%. Outside of GitHub, in "the real world", the situation is even more strongly in favor of Java. I don't know if this is going to change much in the next few years. I don't mean that you shouldn't use an alternative JVM language if it makes your work better, and there are many viable and very useful alternate JVM languages – personally, I like Clojure and Kotlin – but you can't just "replace" Java so easily. I think efforts to reform the Java ecosystem are more likely to succeed – at least in the short term – than efforts that require switching to a different JVM language.
  - fecak 13y ago
    I wouldn't say that Java is extremely popular by any stretch. It's ubiquitous, but people aren't falling over themselves to become Java programmers anymore. I'd say Java is much less popular than it used to be (and I've run a Java Users' Group for 13 years). The JVM is still popular, but Java the language's popularity is arguably at a low point.
astral303 13y ago
Groovy with Gradle is a pretty good answer that is there today. Gradle way way way easier to work with than with Maven for your build system, publishes packages with dependency info, so you still get your dependencies sorted OK. Groovy has automatic setters/getters, a ton of functional-style helpers (closures, etc), dynamic & static mixins, delegates, etc.
- ebiester 13y ago
  My day job is in grails. :) However, some shops still have an aversion to other JVM languages.
- vorg 13y ago
  > Groovy with Gradle is a pretty good answer that is there today I've heard many good things about Gradle's functionality, but not so many about Groovy. Only yesterday ( https://news.ycombinator.com/item?id=6884355 https://news.ycombinator.com/item?id=6884355 ) I asked if Gradle will ever expose an API so developers can use the same language for the build scripts as they do for the projects they're building, i.e. Groovy with Gradle for Groovy projects, and Scala with Gradle for Scala projects?
- usrusr 13y ago
  Sorry, but in groovy, [[1 : 2]] - [["b" : "a"]] seems to be []. As long as they don't get fundamentals like this right i consider groovy only useful for demonstrating it's own deficiencies. The fact that this is in their Jira since 2010 and a fix would would be easy for anyone who understands the basics of hashcode and equals doesn't paint an all too rosy picture of the people behind groovy. I'd rather work with a language that _i_ don't fully understand (modersky seems to provide me with an infinite supply of intellecutal challenges) than with a language that gives me reason to doubt that it is fully understood by the people who made it.
  - vorg 13y ago
    > a language that gives me reason to doubt that it is fully understood by the people who made it It's really just one of the people who made it. Groovy has a non-technical project manager, and most of us who've programmed in corporate IT shops know how that goes. A case in point: traits were announced for Groovy 2.2 ( http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td5715831.html http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td... ) in June (2013). A rather lengthy discussion (55 messages) followed planning them, but the traits never came. The very last message asked what happened to them but the project manager never replied. Another case: tech lead Jochen Theodorou began a discussion about changes to the meta-object protocol (MOP) for Groovy 3 ( http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html ) in June last year (2012), kicking off a 91 message discussion. But the project manager canceled the new MOP, diverting Jochen into other work. Again: Groovy creator James Strachan's very last Groovy mailing list posting ( http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.html#a395571 http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... ) to that project manager who replaced him just before he left the Groovy development team in Dec 2005: "The MOP and introspection APIs do NOT solve the horribly broken name resolution rules in the current RI of Groovy [...] I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole [...] It just feels totally wrong to break Closures across the entire language just because of some use cases for Markup." The project manager's behavior is typical of non-technical people working in Software Development everywhere. E.g. on 29 August this year, Groovy's 10th birthday, someone added the project manager's name to Strachan's as a "co-developer" of Groovy on its Wikipedia page ( http://en.wikipedia.org/w/index.php?title=Groovy_%28programming_language%29&diff=570593212&oldid=569798025 http://en.wikipedia.org/w/index.php?title=Groovy_%28programm... ), giving him 3 titles (developer, project manager, and spec lead). I really had to undo it. Because the Spec was changed to dormant in April 2012 ( https://www.jcp.org/en/jsr/detail?id=241 https://www.jcp.org/en/jsr/detail?id=241 ) after being inactive for 8 years, I removed Laforge's "spec lead" title also. I also added the 3 technical people who are listed in Groovy's Codehaus repository as "despots" to give to Wikipedia page more truth ( http://en.wikipedia.org/wiki/Groovy_(programming_language) http://en.wikipedia.org/wiki/Groovy_(programming_language) ). It's a pity how Groovy stagnated over the years, and maybe it's just a very public example of why "business people" shouldn't be allowed anywhere near programming language design and development.
moomin 13y ago
I think you want Clojure and leiningen.
al2o3cr 13y ago
"All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte." LOL, I'm trying to imagine anything else in life being run like this. For instance, you go to the "car package manager" and are told that all parts must be less than 2kg and that you need to choose which ones you need...
- Falling3 13y ago
  I think your analogy makes a whole lot more sense when you keep in mind that you'd be a automotive engineer and not a consumer.
- Periodic 13y ago
  Except that there is implicit dependency management. It would be like saying that all SKUs need to be comprised of other SKUs and less than 2kg of screws, nuts, bolts and custom components. In your analogy the Spring might be an entire engine, spark plugs and all, built as a single unit. Want to use your own spark plugs? Tough luck. You get the whole engine or none at all, or you could just build your own from scratch.
m0skit0 13y ago
Forget about OOP. Check Clojure.
keypusher 13y ago
Have you looked at Groovy/Grails/Gradle? You can use the existing Java code and ecosystem or you can choose to do things the new way, you have access to a web framework similar to Rails, it's pretty nice.
- vorg 13y ago
  > you have access to a web framework similar to Rails Then why not just use Rails for Java, i.e. JRuby ?

fat0wl 13y ago

Hear hear. When I read about JVM performance issues I usually immediately think "team of 20+ complacent corporate devs who don't care if this succeeds or not because they can get a new job insanely easily at a moment's notice". The issue with these other frameworks/languages is that even when modern frameworks are used there are usually some Java backend services (or another "powerful-outside-of-the-web-also" language) if the app does anything substantially complex. A ton of the hip web tech is basically for building front-end and cobbling together relatively inefficient backends. I was an RoR guy myself but moved to Java & I see the correct hipster tech here but just lacking unanimity. I bet if the RoR community decided "Clojure hell yea" or "Scala hell yea" and contributed lots of plug-ins to those ecosystems, they would generally have similar development times with a lot of performance gain for free. I'm thinking about trying Play framework on Heroku just to see what the monthly bills & New Relic readouts look like in comparison.

cloverich 13y ago
Here's[1] a comparison of the two from an RoR guy who used Play! (with Scala) for 16 months. I found the ensuing discussion pretty informative with minimal FUD / bashing. [1]: https://groups.google.com/forum/#!searchin/play-framework/play$20vs$20ruby$20on$20rails/play-framework/F72DYs2MPsA/f_ol4AZplz0J https://groups.google.com/forum/#!searchin/play-framework/pl...
- fat0wl 13y ago
  Thanks but I've seen a lot of similar comparisons and they seem to focus on trivial things :/ For example the portion about "Asynchronicity" is a brief paraphrase like "Play is good in Rails its awful or doesn't exist". Performance isn't even mentioned really. I find that with Rails apps a lot of development effort is put toward optimizing for scaling rather than complex logic, where Play could potentially be stronger. A lot of the comparisons seem to be posted by RoR devs who are looking at Play as a potential new framework for a CRUD app with a very fancy UI. In my mind that's not what it is... I read a few articles about corps using it for big distributed apps with a lot of eventing. So I guess it's a bit of my personal taste but I just don't see "Rails has HAML", for example, as a reason why it's better given that HAML would be pretty trivial to implement in Play if the community wanted it. Full-featured CRUD frameworks vs. enterprise-ready app frameworks are very different ideals. They each have their place but if one tech were to emerge as really superior I think it could easily integrate all the bells & whistles that rapid CRUD devs like.
  - porker 13y ago
    > looking at Play as a potential new framework for a CRUD app with a very fancy UI. Do you know of any frameworks that are good for that (but let you easily reach down for complex logic, e.g. where data processing or AI is needed)? Every project I do needs some form of CRUD, and making it work AND be pleasing to interact with takes a lot of time. I don't mind the language, just someone, somewhere must have solved this already...
    - fat0wl 13y ago

zaphar 13y ago

Java has always been a good language if you ignored the ecosystem. The ecosystem is a large part of what defines a language though. You have to take care in how you define that ecosystem. I sometimes wonder if Node.js is making mistakes in the opposite direction as Java with their ecosystem these days.

gngeal 13y ago
Java has always been a good language if you ignored the ecosystem. You mean "no unsigned types (even though the language is essentially machine-level when it comes to integers), no compact memory layouts for aggregate data, no useful function values without jumping through hoops etc." is an approach that leads to good languages?
- yareally 13y ago
  I think he's alluding to the stuff that comes after the language is released, not the language design/architecture itself. Node is not a language, so his comment probably implies that he's referring to the design choices of build system, development cycle (of tools, libraries and frameworks), and things like dependency management. That's not my opinion, but just what I understood his comment to be about (personally I prefer the npm approach any day over Maven).
dustingetz 13y ago
A language IS its ecosystem. In 2013 java is a good platform.
- rbanffy 13y ago
  I believe the ecosystem mentioned is the consistently over-engineered AbstractFactoryFactory mindset that permeates so much of the Java space.

pron 13y ago

I think that much of your fantasy is already a reality. For example, look at how Dropwizard[1] assembled a best-of-breed collection of modern Java libraries into a small, yet very powerful, REST micro-framework. So the bits and pieces are certainly there, and even the JCP does good work sometimes (JAX-RS) that becomes good standard APIs with many different implementations. [1]: http://dropwizard.codahale.com/getting-started/ http://dropwizard.codahale.com/getting-started/

nogridbag 13y ago
Ninja web framework [1] is also worth a look. It's similar to Dropwizard in that it's less of a framework and more like a well thought out archetype building upon the best Java libraries. Two main differences I see are Ninja uses Guice for DI whereas dropwizard is manual DI. Dropwizard uses JAX-RS while Ninja has its own Play 1 style routing system. While I really like JAX-RS, the reference impl Jersey uses HK2 for dependency injection, which makes it odd to integrate into a Guice application (in fact Guice support is still lacking with Jersey 2.x). [1]: http://www.ninjaframework.org http://www.ninjaframework.org
candl 13y ago
Dropwizard is pretty great, but one unfortunate aspect is that it's stuck with Jersey 1.x for JAX-RS and as a result is missing some nice features, like async responses, etc.
- pron 13y ago
  I only used it as an example to the fact that modern Java libraries bear little resemblance to those of yesteryear. I do, however, think that standard JSR APIs are still really nice to have, if they're good.
ebiester 13y ago
Dropwizard is a bit heavy by Node standards. The health checks, in the NPM-style system, would be its own package. The configuration class would be its own package. Resources would be their own package. Liquibase or Freemarker wouldn't be built in, nor would JDBI. I think of Dropwizard much like express for node, and most of the "cool kids" in the node community think that that's just too much for a single library. I like Dropwizard, don't get me wrong, but it isn't quite a micro-framework by other standards.

radicalbyte 13y ago

You've basically described C#: Getters, setters fixed? Check. Functional features? Check. Most crappy OO features fixed? Check. Trendy package system inspired by npm/apt-get/gems? Check. Healthy community with libraries replacing frameworks? Check. I'd recommend checking it out if you haven't already.

mynames 13y ago
Could you expand on "crappy OO features"?
lightblade 13y ago
I also like to know more about this C# package system you mentioned.
- Glide 13y ago
  I would imagine he's talking about NuGet. Unless I've missed something dramatic in the past half year in the .net ecosystem.
edwinnathaniel 13y ago
Your package system is inspired by Maven, minus a good build system and other functionalities. Try building a large C# projects with running unit-tests, integration-tests, packaging, code-coverage, code style baked into it, and a bunch of other plugins for your build systems without pulling your hair. Your DateTime library ain't there yet sir so you're pretty much at the same situation with Java (although both ecosystems have NODA/JODA lib). C# is just Java with 10% syntax improvement and -30% to -40% productivity lost when it comes to everything else.
- barrkel 13y ago
  C# is Java with perhaps 200% syntax improvement. The things I use most often with e.g. Ruby - monadic collection operations like map, select, etc. - is there in the form of Linq, with select, where, etc. A concise, type-inferred lambda expression goes a long, long way. The .net ecosystem isn't as evolved as Java, for sure. But I don't think maven is a good implementation of a dependency management system either, nor is it particularly good as a build system.

runT1ME 13y ago

So why not scala? Scala 8 years ago is where java 8 is now, and you can ignore most of the java frameworks.

pron 13y ago
Even putting aside my great dislike for Scala (which I discussed on HN ad nauseam :)), I think everyone would agree that Scala has a very different philosophy from Java. Java has been designed as a "blue-collar" language, with maintenance of a large project with possibly hundreds of developers as a central guiding principle. C#, Go, Dart, Kotlin, Fantom etc., have a similar philosophy. But Scala is a different beast altogether. You can love it or hate it, but even its most enthusiastic fans would concede that it is most certainly not appropriate as a replacement for Java in some/many/most (depending on your view) circumstances. Also, Java is extremely popular, and some of its most painful points have been addressed in Java 8. Even an arguably better language (regardless of its name) will not easily replace Java. Hey, look across the browser at JavaScript. There are arguably better languages there; are they replacing JavaScript? If you look just at GitHub – which is greatly skewed towards new languages – you see that all other JVM languages put together make about 10% of the JVM ecosystem, with Java being the 90%. Outside of GitHub, in "the real world", the situation is even more strongly in favor of Java. I don't know if this is going to change much in the next few years. I don't mean that you shouldn't use an alternative JVM language if it makes your work better, and there are many viable and very useful alternate JVM languages – personally, I like Clojure and Kotlin – but you can't just "replace" Java so easily. I think efforts to reform the Java ecosystem are more likely to succeed – at least in the short term – than efforts that require switching to a different JVM language.
- fecak 13y ago
  I wouldn't say that Java is extremely popular by any stretch. It's ubiquitous, but people aren't falling over themselves to become Java programmers anymore. I'd say Java is much less popular than it used to be (and I've run a Java Users' Group for 13 years). The JVM is still popular, but Java the language's popularity is arguably at a low point.

astral303 13y ago

Groovy with Gradle is a pretty good answer that is there today. Gradle way way way easier to work with than with Maven for your build system, publishes packages with dependency info, so you still get your dependencies sorted OK. Groovy has automatic setters/getters, a ton of functional-style helpers (closures, etc), dynamic & static mixins, delegates, etc.

ebiester 13y ago
My day job is in grails. :) However, some shops still have an aversion to other JVM languages.
vorg 13y ago
> Groovy with Gradle is a pretty good answer that is there today I've heard many good things about Gradle's functionality, but not so many about Groovy. Only yesterday ( https://news.ycombinator.com/item?id=6884355 https://news.ycombinator.com/item?id=6884355 ) I asked if Gradle will ever expose an API so developers can use the same language for the build scripts as they do for the projects they're building, i.e. Groovy with Gradle for Groovy projects, and Scala with Gradle for Scala projects?
usrusr 13y ago
Sorry, but in groovy, [[1 : 2]] - [["b" : "a"]] seems to be []. As long as they don't get fundamentals like this right i consider groovy only useful for demonstrating it's own deficiencies. The fact that this is in their Jira since 2010 and a fix would would be easy for anyone who understands the basics of hashcode and equals doesn't paint an all too rosy picture of the people behind groovy. I'd rather work with a language that _i_ don't fully understand (modersky seems to provide me with an infinite supply of intellecutal challenges) than with a language that gives me reason to doubt that it is fully understood by the people who made it.
- vorg 13y ago
  > a language that gives me reason to doubt that it is fully understood by the people who made it It's really just one of the people who made it. Groovy has a non-technical project manager, and most of us who've programmed in corporate IT shops know how that goes. A case in point: traits were announced for Groovy 2.2 ( http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td5715831.html http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td... ) in June (2013). A rather lengthy discussion (55 messages) followed planning them, but the traits never came. The very last message asked what happened to them but the project manager never replied. Another case: tech lead Jochen Theodorou began a discussion about changes to the meta-object protocol (MOP) for Groovy 3 ( http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html ) in June last year (2012), kicking off a 91 message discussion. But the project manager canceled the new MOP, diverting Jochen into other work. Again: Groovy creator James Strachan's very last Groovy mailing list posting ( http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.html#a395571 http://groovy.329449.n5.nabble.com/Paris-write-up-tt395560.h... ) to that project manager who replaced him just before he left the Groovy development team in Dec 2005: "The MOP and introspection APIs do NOT solve the horribly broken name resolution rules in the current RI of Groovy [...] I see no argument yet for why we have to throw away decades of language research and development with respect to name resolution across the language as a whole [...] It just feels totally wrong to break Closures across the entire language just because of some use cases for Markup." The project manager's behavior is typical of non-technical people working in Software Development everywhere. E.g. on 29 August this year, Groovy's 10th birthday, someone added the project manager's name to Strachan's as a "co-developer" of Groovy on its Wikipedia page ( http://en.wikipedia.org/w/index.php?title=Groovy_%28programming_language%29&diff=570593212&oldid=569798025 http://en.wikipedia.org/w/index.php?title=Groovy_%28programm... ), giving him 3 titles (developer, project manager, and spec lead). I really had to undo it. Because the Spec was changed to dormant in April 2012 ( https://www.jcp.org/en/jsr/detail?id=241 https://www.jcp.org/en/jsr/detail?id=241 ) after being inactive for 8 years, I removed Laforge's "spec lead" title also. I also added the 3 technical people who are listed in Groovy's Codehaus repository as "despots" to give to Wikipedia page more truth ( http://en.wikipedia.org/wiki/Groovy_(programming_language) http://en.wikipedia.org/wiki/Groovy_(programming_language) ). It's a pity how Groovy stagnated over the years, and maybe it's just a very public example of why "business people" shouldn't be allowed anywhere near programming language design and development.

moomin 13y ago

I think you want Clojure and leiningen.

al2o3cr 13y ago

"All "JPM" packages expected to be under 100 lines, a la NPM. Frameworks are discouraged. Take what you need a la carte." LOL, I'm trying to imagine anything else in life being run like this. For instance, you go to the "car package manager" and are told that all parts must be less than 2kg and that you need to choose which ones you need...

Falling3 13y ago
I think your analogy makes a whole lot more sense when you keep in mind that you'd be a automotive engineer and not a consumer.
Periodic 13y ago
Except that there is implicit dependency management. It would be like saying that all SKUs need to be comprised of other SKUs and less than 2kg of screws, nuts, bolts and custom components. In your analogy the Spring might be an entire engine, spark plugs and all, built as a single unit. Want to use your own spark plugs? Tough luck. You get the whole engine or none at all, or you could just build your own from scratch.

m0skit0 13y ago

Forget about OOP. Check Clojure.

keypusher 13y ago

Have you looked at Groovy/Grails/Gradle? You can use the existing Java code and ecosystem or you can choose to do things the new way, you have access to a web framework similar to Rails, it's pretty nice.

vorg 13y ago
> you have access to a web framework similar to Rails Then why not just use Rails for Java, i.e. JRuby ?