6 ms·

Part of the answer is Java itself. It's verbose, static typed, and requires a lot of boilerplate code to do properly. The fact that classes are a compile-time c

by latch 14y ago

Part of the answer is Java itself. It's verbose, static typed, and requires a lot of boilerplate code to do properly. The fact that classes are a compile-time concern, rather than a runtime concern, is just such a drag. You end up with interfaces you don't really need, only so that you can inject them into constructors so that your app is properly decoupled and testable. Part of it is a framework issue. Struts is horrible...absolutely, stunningly horrible. Your controller is an XML file (seriously). Freemarker (the main templating language) makes ColdFusion look awesome. Play is better, but it seems built for the way websites were created in mid-2000. JSON is still a second-class citizen. Static actions are a weird choice given IoC is achieved via DI in a static language. Edit: I should add that there's also the persistence story. Anyone who's done [n]Hibernate knows that it's, at best, a mixed blessing. Even Java's NoSQL drivers are verbose compared to their dynamic brothers (first-class hash support is a big issue here, for some drivers in particular). I'm not sure something like Sequel would even be possible to write, and the AR implementations are, again, limited by the compiled-time nature of the language and the inability of bend the syntax into a nice DSL. Java also lacks lambdas, and generic support is weak. And what's up with int vs Integer...the list goes on and on.

batista 14y ago
>Part of it is a framework issue. Struts is horrible...absolutely, stunningly horrible. Your controller is an XML file (seriously). Freemarker (the main templating language) makes ColdFusion look awesome. Play is better, but it seems built for the way websites were created in mid-2000. JSON is still a second-class citizen. Static actions are a weird choice given IoC is achieved via DI in a static language. 99% of websites are still built "the way they were built in mid-2000", and there's nothing wrong with that way. Client-side rendering and such is not the "new way", is just an alternative way for certain types of websites, that is still quite immature and can take you to a world of pain if done bad (see Twitter).
- latch 14y ago
  My complaint isn't about client-side rendering. It's about _anything_ that involves getting in JSON or outputting JSON. It's essentially being able to easily bind json to objects on the way in, and being able to use respond_to and to_json on the way out.
  - fizx 14y ago
    You're stuck in 2007. People doing modern java use: @Path("/hello") @Produces(MediaType.APPLICATION_JSON) class HelloController { class Greeting { public Greeting(String name) { this.content = "Hello, " + name; } public final String content; } @GET public Greeting greet(@PathParam("name") String name) { return new Greeting(name); } } > curl http://localhost:8080/hello?name=me {"content": "Hello, me"}
    - latch 14y ago
      I'm not sure if you are being sarcastic, but you do realize that's a lot of code for something so simple, right? get '/hello/:name' do content_type :json {:content => "Hello, #{params[:name]}"}.to_json end
      - gizmogwai 14y ago
        I'm not sure if you are being sarcastic, but you do realize that your version is entirely static while the other one is ready for future evolutions? By changing a single line, the java version can also produce XML or text response. By changing two lines, it can also respond to POST requests. And that's just the top of the iceberg. Oh, and in the ends, it's way faster than Node, Ruby, Python and most of the dynamic languages.
        Retric 14y ago
        That's a funny complaint when evaluating 4 lines of code one of which is end. Java makes the assumption that you need a lot of boilerplate code, so being able to make changes easily seems like a big deal. Other languages avoid that boilerplate and can make the changes just as easily for free.
        thebluesky 14y ago
        Making changes to a complex system is a "big deal" in any language. Pretty (and compact) syntax doesn't help much, especially when the refactoring tools are weak.
danielatc 14y ago
I think you need to reconsider your views regarding play. Version 2.0 has been a major improvement regarding a lot of issues. Asynchronous Requests are inbuilt as well as Websockets. (And Json serialization is as easy as Json.toJson()) I agree that static controllers are not always ideal considering that Java does not support inheritance of static methods, but the arguments of why static controllers are chosen can be found here: http://stackoverflow.com/a/5193721/616974 http://stackoverflow.com/a/5193721/616974 Still I think that developing with the play framework is a very productive process and can be compared with the likes of ror/django etc with the benefits of type safety all the way (including the templates)
- latch 14y ago
  I did look at 2.0 when it came out, and I'm under the impression that you still need to write a custom binder. Just now I tried to look it up, but the documentation points to: http://www.playframework.org/documentation/2.0/JavaJson http://www.playframework.org/documentation/2.0/JavaJson which is a 404. I also don't see a nice way to respond with the appropriate format based on the accept-header...not that you can't write that yourself.
  - Ygg3 14y ago
    How did you get that link? Here is what I get when I browse documentation. http://www.playframework.org/documentation/2.0.1/JavaJsonRequests http://www.playframework.org/documentation/2.0.1/JavaJsonReq...
    - latch 14y ago
      http://www.playframework.org/documentation/2.0/JavaRouting http://www.playframework.org/documentation/2.0/JavaRouting http://www.playframework.org/documentation/2.0/JavaXmlRequests http://www.playframework.org/documentation/2.0/JavaXmlReques... it's all over the place...search for "working with json" on those pages. Thanks for the correct link though.
  - danielatc 14y ago
    Here the version of the documentation from the git repository: https://github.com/playframework/Play20/wiki/Javajson https://github.com/playframework/Play20/wiki/Javajson it states that the jackson library ( http://jackson.codehaus.org/ http://jackson.codehaus.org/ ) is included in the framework which allows for type safe json bindings
mibbitier 14y ago
So basically, it's due to lazy programmers who moan if they have to type or think too hard. Also very very much fashion lead by hipsters who must be using the newest coolest untested thing on the planet.
- einhverfr 14y ago
  I think there is a more fundamental reason. Java, being a compiled language that has traditionally aimed at compile once, run anywhere, offers a significant overhead, but with a development speed of a compiled language. It may or may not be faster to write code in Java vs C++, but it's certainly way faster to write code in Perl, Python, or Ruby. I have always felt that Java was ill-suited to web applications generally, and that the main advantage of using it for web apps was being able to make use of third party libraries written in it. In this regard it's kind of like "why would you write your web app using DCOM on Windows?" Well, maybe because you are recycling VB logic from desktop apps?
- latch 14y ago
  Laziness, Impatience and Hubris There's no advantage to the need to over-architect. It's purely a bi-product of Java (or static languages in general). Because you can figure out how to properly write a Java program doesn't make you clever, sorry. C/C++ programmers moaned about Java and garbage collectors the same way Java programmers are moaning about dynamic language.
  - einhverfr 14y ago
    Static languages have some advantages. It's not quite the same thing (Perl being dynamic and all) but I have gone towards Moose in Perl which gives some of the things I see as advantages of static languages (such as the ability to engineer in constraints declaratively, assuming those are enforced by the language. SQL is great this way.) The real reason to use languages like C and C++ is performance. The reason for dynamic languages is rapid prototyping. Java is somewhere in the middle but not really ideal except for where you want to compile your software to run on an imaginary CPU which can be emulated everywhere :-)
joshAg 14y ago
why does a language designed around an OOP perspective need a lambda (which comes from a functional programming perspective)?
- fizx 14y ago
  Because otherwise you get a bunch of new Callable<Integer>() { @Override public call() { return 1; } }
  - masklinn 14y ago
    Or even better, for(final Iterator it = container.iterator(); it.hasNext();) { final Object o = it.next(); println((Integer) o); } compared to: container do: [:o | Transcript print: o; cr. ].
    - joshAg 14y ago
      this explanation made the most sense to me. thanks.
- koide 14y ago
  Because it's more expressive and leads to less and more maintainable code? Who cares about paradigm purity? Especially given on a language that's not totally pure already.
  - joshAg 14y ago
    I don't care about paradigm purity, but given the amounts of java and lisp i've written, I didn't see why java would benefit from a lambda.
- masklinn 14y ago
  > why does a language designed around an OOP perspective need a lambda Because only through lambdas can you actually do OOP: a core of OOP is to tell objects to do things. That you can do with lambdas, through customizing "the thing". Without lambdas, you are left with the requirement to painfully and painstakingly get bits and pieces in or out of objects in order to do the thing yourself, ending up with a horrendously procedural language with a smattering of objects added on top. It's no secret — or mistake — that blocks are first-class components (and literals[0]) in the ur-OO language: http://en.wikipedia.org/wiki/Smalltalk#Code_blocks http://en.wikipedia.org/wiki/Smalltalk#Code_blocks (as well as http://en.wikipedia.org/wiki/Self_(programming_language) http://en.wikipedia.org/wiki/Self_(programming_language) ) [0] and really one of the few pieces of syntax
rabbitfang 14y ago
...and that is why the latest generation of JVM languages such as Scala, Clojure and Groovy are so popular. Java the platform is extremely stable, highly optimized and heavily instrumented. Java is much less verbose than C++ (the main alternative when it was released), but the times have moved on. With Scala statically typed and verbose are not synonymous. Statically typed = high performance. Type inference and compact syntax = expressive. Best of both worlds. Languages like Ruby bring expressive syntax, but performance suffers. Performance is becoming increasingly important with mobile applications, one of many reasons Ruby adoption has stagnated since the end of 2010 (see open source contribution and indeed.com charts).
- house9 14y ago
  Dont forget - there is also jruby
  - rabbitfang 14y ago
    JRuby is pretty nifty, still can't compare performance-wise to statically typed languages e.g. Scala: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=jruby&lang2=scala http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Probably more comparable to Groovy in syntax and performance.
    - igouy 14y ago
      I wish people would try to write better and contribute Ruby programs for the benchmarks game :(

by latch 14y ago

batista 14y ago

>Part of it is a framework issue. Struts is horrible...absolutely, stunningly horrible. Your controller is an XML file (seriously). Freemarker (the main templating language) makes ColdFusion look awesome. Play is better, but it seems built for the way websites were created in mid-2000. JSON is still a second-class citizen. Static actions are a weird choice given IoC is achieved via DI in a static language. 99% of websites are still built "the way they were built in mid-2000", and there's nothing wrong with that way. Client-side rendering and such is not the "new way", is just an alternative way for certain types of websites, that is still quite immature and can take you to a world of pain if done bad (see Twitter).

latch 14y ago
My complaint isn't about client-side rendering. It's about _anything_ that involves getting in JSON or outputting JSON. It's essentially being able to easily bind json to objects on the way in, and being able to use respond_to and to_json on the way out.
- fizx 14y ago
  You're stuck in 2007. People doing modern java use: @Path("/hello") @Produces(MediaType.APPLICATION_JSON) class HelloController { class Greeting { public Greeting(String name) { this.content = "Hello, " + name; } public final String content; } @GET public Greeting greet(@PathParam("name") String name) { return new Greeting(name); } } > curl http://localhost:8080/hello?name=me {"content": "Hello, me"}
  - latch 14y ago
    I'm not sure if you are being sarcastic, but you do realize that's a lot of code for something so simple, right? get '/hello/:name' do content_type :json {:content => "Hello, #{params[:name]}"}.to_json end
    - gizmogwai 14y ago
      I'm not sure if you are being sarcastic, but you do realize that your version is entirely static while the other one is ready for future evolutions? By changing a single line, the java version can also produce XML or text response. By changing two lines, it can also respond to POST requests. And that's just the top of the iceberg. Oh, and in the ends, it's way faster than Node, Ruby, Python and most of the dynamic languages.
      - Retric 14y ago
        That's a funny complaint when evaluating 4 lines of code one of which is end. Java makes the assumption that you need a lot of boilerplate code, so being able to make changes easily seems like a big deal. Other languages avoid that boilerplate and can make the changes just as easily for free.
        thebluesky 14y ago
        Making changes to a complex system is a "big deal" in any language. Pretty (and compact) syntax doesn't help much, especially when the refactoring tools are weak.

danielatc 14y ago

I think you need to reconsider your views regarding play. Version 2.0 has been a major improvement regarding a lot of issues. Asynchronous Requests are inbuilt as well as Websockets. (And Json serialization is as easy as Json.toJson()) I agree that static controllers are not always ideal considering that Java does not support inheritance of static methods, but the arguments of why static controllers are chosen can be found here: http://stackoverflow.com/a/5193721/616974 http://stackoverflow.com/a/5193721/616974 Still I think that developing with the play framework is a very productive process and can be compared with the likes of ror/django etc with the benefits of type safety all the way (including the templates)

latch 14y ago
I did look at 2.0 when it came out, and I'm under the impression that you still need to write a custom binder. Just now I tried to look it up, but the documentation points to: http://www.playframework.org/documentation/2.0/JavaJson http://www.playframework.org/documentation/2.0/JavaJson which is a 404. I also don't see a nice way to respond with the appropriate format based on the accept-header...not that you can't write that yourself.
- Ygg3 14y ago
  How did you get that link? Here is what I get when I browse documentation. http://www.playframework.org/documentation/2.0.1/JavaJsonRequests http://www.playframework.org/documentation/2.0.1/JavaJsonReq...
  - latch 14y ago
    http://www.playframework.org/documentation/2.0/JavaRouting http://www.playframework.org/documentation/2.0/JavaRouting http://www.playframework.org/documentation/2.0/JavaXmlRequests http://www.playframework.org/documentation/2.0/JavaXmlReques... it's all over the place...search for "working with json" on those pages. Thanks for the correct link though.
- danielatc 14y ago
  Here the version of the documentation from the git repository: https://github.com/playframework/Play20/wiki/Javajson https://github.com/playframework/Play20/wiki/Javajson it states that the jackson library ( http://jackson.codehaus.org/ http://jackson.codehaus.org/ ) is included in the framework which allows for type safe json bindings

mibbitier 14y ago

So basically, it's due to lazy programmers who moan if they have to type or think too hard. Also very very much fashion lead by hipsters who must be using the newest coolest untested thing on the planet.

einhverfr 14y ago
I think there is a more fundamental reason. Java, being a compiled language that has traditionally aimed at compile once, run anywhere, offers a significant overhead, but with a development speed of a compiled language. It may or may not be faster to write code in Java vs C++, but it's certainly way faster to write code in Perl, Python, or Ruby. I have always felt that Java was ill-suited to web applications generally, and that the main advantage of using it for web apps was being able to make use of third party libraries written in it. In this regard it's kind of like "why would you write your web app using DCOM on Windows?" Well, maybe because you are recycling VB logic from desktop apps?
latch 14y ago
Laziness, Impatience and Hubris There's no advantage to the need to over-architect. It's purely a bi-product of Java (or static languages in general). Because you can figure out how to properly write a Java program doesn't make you clever, sorry. C/C++ programmers moaned about Java and garbage collectors the same way Java programmers are moaning about dynamic language.
- einhverfr 14y ago
  Static languages have some advantages. It's not quite the same thing (Perl being dynamic and all) but I have gone towards Moose in Perl which gives some of the things I see as advantages of static languages (such as the ability to engineer in constraints declaratively, assuming those are enforced by the language. SQL is great this way.) The real reason to use languages like C and C++ is performance. The reason for dynamic languages is rapid prototyping. Java is somewhere in the middle but not really ideal except for where you want to compile your software to run on an imaginary CPU which can be emulated everywhere :-)

joshAg 14y ago

why does a language designed around an OOP perspective need a lambda (which comes from a functional programming perspective)?

fizx 14y ago
Because otherwise you get a bunch of new Callable<Integer>() { @Override public call() { return 1; } }
- masklinn 14y ago
  Or even better, for(final Iterator it = container.iterator(); it.hasNext();) { final Object o = it.next(); println((Integer) o); } compared to: container do: [:o | Transcript print: o; cr. ].
  - joshAg 14y ago
    this explanation made the most sense to me. thanks.
koide 14y ago
Because it's more expressive and leads to less and more maintainable code? Who cares about paradigm purity? Especially given on a language that's not totally pure already.
- joshAg 14y ago
  I don't care about paradigm purity, but given the amounts of java and lisp i've written, I didn't see why java would benefit from a lambda.
masklinn 14y ago
> why does a language designed around an OOP perspective need a lambda Because only through lambdas can you actually do OOP: a core of OOP is to tell objects to do things. That you can do with lambdas, through customizing "the thing". Without lambdas, you are left with the requirement to painfully and painstakingly get bits and pieces in or out of objects in order to do the thing yourself, ending up with a horrendously procedural language with a smattering of objects added on top. It's no secret — or mistake — that blocks are first-class components (and literals[0]) in the ur-OO language: http://en.wikipedia.org/wiki/Smalltalk#Code_blocks http://en.wikipedia.org/wiki/Smalltalk#Code_blocks (as well as http://en.wikipedia.org/wiki/Self_(programming_language) http://en.wikipedia.org/wiki/Self_(programming_language) ) [0] and really one of the few pieces of syntax

rabbitfang 14y ago

...and that is why the latest generation of JVM languages such as Scala, Clojure and Groovy are so popular. Java the platform is extremely stable, highly optimized and heavily instrumented. Java is much less verbose than C++ (the main alternative when it was released), but the times have moved on. With Scala statically typed and verbose are not synonymous. Statically typed = high performance. Type inference and compact syntax = expressive. Best of both worlds. Languages like Ruby bring expressive syntax, but performance suffers. Performance is becoming increasingly important with mobile applications, one of many reasons Ruby adoption has stagnated since the end of 2010 (see open source contribution and indeed.com charts).

house9 14y ago
Dont forget - there is also jruby
- rabbitfang 14y ago
  JRuby is pretty nifty, still can't compare performance-wise to statically typed languages e.g. Scala: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=jruby&lang2=scala http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Probably more comparable to Groovy in syntax and performance.
  - igouy 14y ago
    I wish people would try to write better and contribute Ruby programs for the benchmarks game :(