16 ms·

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

dvanduzer 11y ago
There is no non-political reason to enumerate choices of languages limited to those that run on the JVM. Clojure and Scala exist because of the JVM, not because of Java. Java 8 will or won't be an interesting language independently of the JVM, oddly enough.
eklavya 11y ago
A type system (at least scala)? Although Clojure does have one, it's not as good to use as Scala's (personal opinion).
struppi 11y ago
Disclaimer: I personally prefer clojure, but earn most of my money as a consultant / coach helping clients develop Java code. For Java code, it's often easier to predict the performance characteristics of a part of the code. But you shouldn't trust your judgements anyway - instead use a profiler - so this is not really a reason. Speaking of performance: I once talked to someone working for Elasticsearch, and they told me that they cannot use clojure for most of their code because of their performance requirements. Clojure collections are almost as fast as Java collections in many scenarios, but that is apparently not fast enough for them. This is probably not a valid reason for most projects, though. There is a huge number of Java developers out there, and Java is easier to learn for someone coming from C++ or C# or JavaScript than clojure (at least I am pretty sure about that). So hiring cheap developers might be easier if you use Java. You might count that one as a political statement. There are some great tools for Java out there: IntelliJ Idea, Yourkit Profiler, JRebel, ... Cursive Clojure is great, but IntelliJ for Java has even more integrated workflows. There are very mature open source libraries / frameworks / tools for Java: JUnit, Spring, Guice, Dropwizard, Gradle, Elasticsearch, ... You can have commercial support for many of them. Most of the libraries I use with clojure are version 0.3 or something like that with no possibility for commercial support (but they work fine anyway). Static typing: A lot of people complain about it, but it can really help you to create maintainable code. See for example http://talks.samirtalwar.com/use-your-type-system.html http://talks.samirtalwar.com/use-your-type-system.html
- mullr 11y ago
  Really high performance Java code tries to avoid any allocations on the hot paths, since that requires GC. This means a lot of in-place mutation on pre-allocated objects. (Lucene does this, for example) While this isn't impossible in Clojure, you do have to give up a lot of the immutable goodness that makes it such a pleasant development environment.
RyanZAG 11y ago
In the same way some people pick C++ over Lisp, some would choose Java over Clojure for similar reasons. It's not some kind of war or personal affront to you - some people simply prefer the Algol style to the Lisp one. This even includes people who are very fluent in the Lisp style.
- dvanduzer 11y ago
  https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
bad_user 11y ago
There's a gravitational pull towards popular languages because popular languages have more books, more (idiomatic) libraries and tools, copy-pasteble examples all over the web and a big pool of developers that can be productive from day 1 on simple problems. In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometimes it's worth it, sometimes it isn't. For a startup, with a small but capable team that's trying to outrun its competition to market, then using the most productive tools possible is a good choice. In other contexts though, like in a big company where long-term maintainability might be more important than speed to market, well, Java might be the better choice, and not because of the language per se (I think Java code is often unreadable), but more because the cost of maintainability is low due to its popularity and its slow pace of change.
- manyxcxi 11y ago
  I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly. I'm not saying Java is good looking by any means, but I've never found it to be heard to read in the "I can't completely grasp exactly what everything is supposed to do" kind of way. I often find Python and JS to have enough shortcuts, callbacks, and anonymous functions to find other people's code much harder to grok than other people's Java.
  - the_af 11y ago
    Java's verbosity (and misuse of OOP, but to be fair, that's not the fault of the language) can get in the way of understanding. Why use multiple words to say something when a single word will do? "Unreadable" is obviously hyperbole; "harder to read" is probably more accurate. On the contrary, I think the recent additions from Java 8 are a step in the right direction.
  - lomnakkus 11y ago
    > I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Not bad_user, obviously, but excessive verbosity can be antithetical to readability. (As can excessive conciseness.) It can make the overall structure and meaning of the code hard to discern, even though can clearly tell where what gets assigned to what variables, etc.
oweiler 11y ago
Apart from the slightly better performance, memory consumption. Clojure's persistent collections require a fair amount of memory (which in most cases doesn't matter as memory is cheap).
jinst8gmi 11y ago
> Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine? If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Other than no new learning required I can't think of many reasons to pick Java as a first choice. Java tends to be popular because it's the oldest, most familiar default for the JVM rather than any particular strength.
- ubertaco 11y ago
  >If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Put another way: if you're on a dev team where nobody knows Clojure/Scala, and everyone knows Java, (and, optionally, the codebase is already in Java), and your team doesn't have time for everyone to learn an entirely new language (including cleaning up the beginner's mistakes that come with that process), then Java's the better choice. Don't get me wrong, Java grinds my gears sometimes, and I frequently wish I could use Kotlin or F# or some kind of typed Ruby in my Java-shop workplace, and I enjoy picking up the cool ideas from languages like Idris (dependent types are really cool!) in my free time. But I'm sympathetic to my coworkers in the environment where I work: 4 devs in the whole company, startup pressure to get to a break-even point so we don't go under, and a backlog longer than all of us could finish this year even if we froze it now. Sometimes circumstances require what looks like a short-term decision in order to ensure that there's a long term to worry about later.
  - jinst8gmi 11y ago
    With existing Java code and/or a tight timeline with existing skills I can see how that would be the best choice :) I'm thinking more in terms of the surprisingly high proportion of Java developers who have never learned another language since learning Java 10-15 years ago and dismiss any alternatives without ever exploring what else is out there (you clearly don't fall into that category :).
    - 11y ago
lugus35 11y ago
Java shines by the number of java professionals available on the market.
- deleted 11y ago
  [deleted]
fulafel 11y ago
Many people have a gut-level aversion to dynamically typed languages.
aardvark179 11y ago
I love clojure, but on a large code base I find good refactoring tools to be extremely helpful when trying to evolve how things are implemented. In that respect Java wins hands down just because of the tooling around it. It also may be easier sometimes to use Java for working with particular libraries. There are however areas where I'd use clojure every time. Luckily the JVM is really good for doing mixed language work on, so you don't have to work entirely in one language.
winterbe 11y ago
Most parts of software development probably is not about starting new projects from scratch but about maintaining existing code bases. That's where Java really shines due to its (often hated) backwards compatibility.
lmm 11y ago
All IME, and as a Scala fan: Clojure has a weakly integrated type system (an inherent disadvantage of optional type systems). At the simplest level this makes silly errors much easier and means you have to write more tests to maintain the same defect rate. The lack of types mean you require extensive use of macros for advanced functionality. IME macros have major maintainability issues in a multi-person codebase. Both these things are major disadvantages for automatic comprehensibility of code. Autocompletion can be more-or-less usable but will never be as good as in Java or Scala. Automated refactoring is inherently unsafe in the presence of macros (Scala's fancier typed constructs (typeclasses, for/yield with custom types) mean you need macros much less often; Java tends to force you to expand these things out by hand (or else use annotations which act as de facto macros), which has its own maintainability issues but does at least mean automated refactoring will work correctly). Some of the language culture pushes people towards less principled abstractions. From this side of the fence that looks like anti-intellectualism; no doubt from their side it's pretension on typed programmers' part. But either way I think they're setting themselves up for long-term maintainability issues (e.g. the semantics of clojure transducers in the presence of errors are infuriatingly not-quite-right, which will either remain a painful gotcha forever, or necessitate a painful migration in the future). As a minority language Clojure may not be as well supported in the surrounding ecosystem - partly things like IDEs but also code coverage tools, profilers, monitoring.... Remember the JVM ecosystem is wider than just the languages themselves. There are good things about Clojure, but it's by no means clear-cut.
- raspasov 11y ago
  What do you think is not quite right about errors in tranducers? When you use them with core.async channels you can supply an optional exception handler, which is quite nice. In terms IDEs, Cursive for IntelliJ is great, and it gives almost Java-like capabilities (with limitations inherent to more dynamic languages, of course).
  - lmm 11y ago
    I forget the exact behaviour, and maybe it's been improved. But I remember that it didn't map cleanly onto values - sometimes you want to continue after a single error, sometimes you want to bail out immediately, and the ways of doing this felt very ad-hoc.
meekins 11y ago
Java EE is currently an excellent framework for complex distributed enterprise applications.
pjmlp 11y ago
It is the systems programming language of the Java platform, if you see the JVM as an OS. So you need to be comfortable with it, as there will always be cases you need to jump out of the alternative language into Java. Also, most companies will only hire to work with Java on the JVM, because they don't want to be hostage of the cool language some of the dev team guys/contractors decided to use instead. It is very rare to see traditional Java shops to use alternative languages. Usually the ones using them are either startups or companies like Facebook and Twitter, which aren't the typical business culture.
jbooth 11y ago
Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance. They're conservative about adding features, so they've managed to keep the language pretty small, and the core concepts of "what is good Java code" have been mostly the same for like 15 years, even through major releases like 1.5.
- jinst8gmi 11y ago
  I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java. Java developers usually consider features which the language doesn't have to be bad or make code unreadable, that is until those same features are added to Java, when suddenly they are a source of pride and a sign of Java being "modern". In reality Java's feature freeze until Java 8 was largely driven by Sun's financial woes.
  - RyanZAG 11y ago
    I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value ) However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.
mark_l_watson 11y ago
I have been using Java since the first beta, and have written a large pile of Java books (pun not intended), but I too prefer Clojure as a practical, simple to use and simple to read language. That said, Clojure / Java interop is really nice. I frequently find myself simply adding existing Java code to my lein project file. I would suggest just keep using Clojure and when it makes sense, mix in Java when you want or need to.
- chvid 11y ago
  This might sound like a snarky comment but it is actually not. If you want a dynamic language on the Java platform; then why not use JavaScript? There is an easy-to-use engine in Java 8 and JavaScript is widespread and somehow familiar to Java-developers.
  - mark_l_watson 11y ago
    I like JavaScript for Meteor.js and general front end development but I have never thought to use embedded JavaScript. Clojure is a practical little language and suits my taste.
  - lmm 11y ago
    JavaScript is just not a nice language to maintain - bizarre scoping, confusing inheritance model, extremely clunky syntax, confusing standard data types. Being "dynamic" isn't a feature so much as an acceptable cost, but JavaScript doesn't really give me any expressibility advantage over straight Java, yet alone compared to Scala.
malcolmgreaves 11y ago
IMO Java doesn't shine anywhere. It's statically typed, but lacks support to be flexible. Thus many Java programs rely on reflection at runtime or casting. This negates all of the benefits of static typing, turning the language into a dynamic one. The main choice is then either Clojure or Scala. This comes down to dynamic versus static type checking. With a dynamic language, one is significantly less sure if a program is correct. In large programs that use dynamic languages, many tests must be created that are essentially doing the work that a type checker in a static language would do automatically. In a static language, entire classes of bugs are eliminated. Scala provides the best support for strong, static typing on the JVM.
- incepted 11y ago
  > Scala provides the best support for strong, static typing on the JVM I'd argue that Ceylon and Kotlin offer most of Scala's advantages with none of its baggage and bloat. And drama.
  - lmm 11y ago
    All those things will come as those languages mature, and until then neither has much library or tool support.
    - incepted 11y ago
      No tool support? Kotlin and Ceylon both have very good IDE plug-ins that already work much better than Scala, despite Typesafe pouring a lot of money into their own plug-in.
      - lmm 11y ago
        There are a lot more tools in the JVM ecosystem than just IDEs, and by now most of them have Scala support.

dvanduzer 11y ago

There is no non-political reason to enumerate choices of languages limited to those that run on the JVM. Clojure and Scala exist because of the JVM, not because of Java. Java 8 will or won't be an interesting language independently of the JVM, oddly enough.

eklavya 11y ago

A type system (at least scala)? Although Clojure does have one, it's not as good to use as Scala's (personal opinion).

struppi 11y ago

Disclaimer: I personally prefer clojure, but earn most of my money as a consultant / coach helping clients develop Java code. For Java code, it's often easier to predict the performance characteristics of a part of the code. But you shouldn't trust your judgements anyway - instead use a profiler - so this is not really a reason. Speaking of performance: I once talked to someone working for Elasticsearch, and they told me that they cannot use clojure for most of their code because of their performance requirements. Clojure collections are almost as fast as Java collections in many scenarios, but that is apparently not fast enough for them. This is probably not a valid reason for most projects, though. There is a huge number of Java developers out there, and Java is easier to learn for someone coming from C++ or C# or JavaScript than clojure (at least I am pretty sure about that). So hiring cheap developers might be easier if you use Java. You might count that one as a political statement. There are some great tools for Java out there: IntelliJ Idea, Yourkit Profiler, JRebel, ... Cursive Clojure is great, but IntelliJ for Java has even more integrated workflows. There are very mature open source libraries / frameworks / tools for Java: JUnit, Spring, Guice, Dropwizard, Gradle, Elasticsearch, ... You can have commercial support for many of them. Most of the libraries I use with clojure are version 0.3 or something like that with no possibility for commercial support (but they work fine anyway). Static typing: A lot of people complain about it, but it can really help you to create maintainable code. See for example http://talks.samirtalwar.com/use-your-type-system.html http://talks.samirtalwar.com/use-your-type-system.html

mullr 11y ago
Really high performance Java code tries to avoid any allocations on the hot paths, since that requires GC. This means a lot of in-place mutation on pre-allocated objects. (Lucene does this, for example) While this isn't impossible in Clojure, you do have to give up a lot of the immutable goodness that makes it such a pleasant development environment.

RyanZAG 11y ago

In the same way some people pick C++ over Lisp, some would choose Java over Clojure for similar reasons. It's not some kind of war or personal affront to you - some people simply prefer the Algol style to the Lisp one. This even includes people who are very fluent in the Lisp style.

dvanduzer 11y ago
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

bad_user 11y ago

There's a gravitational pull towards popular languages because popular languages have more books, more (idiomatic) libraries and tools, copy-pasteble examples all over the web and a big pool of developers that can be productive from day 1 on simple problems. In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometimes it's worth it, sometimes it isn't. For a startup, with a small but capable team that's trying to outrun its competition to market, then using the most productive tools possible is a good choice. In other contexts though, like in a big company where long-term maintainability might be more important than speed to market, well, Java might be the better choice, and not because of the language per se (I think Java code is often unreadable), but more because the cost of maintainability is low due to its popularity and its slow pace of change.

manyxcxi 11y ago
I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly. I'm not saying Java is good looking by any means, but I've never found it to be heard to read in the "I can't completely grasp exactly what everything is supposed to do" kind of way. I often find Python and JS to have enough shortcuts, callbacks, and anonymous functions to find other people's code much harder to grok than other people's Java.
- the_af 11y ago
  Java's verbosity (and misuse of OOP, but to be fair, that's not the fault of the language) can get in the way of understanding. Why use multiple words to say something when a single word will do? "Unreadable" is obviously hyperbole; "harder to read" is probably more accurate. On the contrary, I think the recent additions from Java 8 are a step in the right direction.
- lomnakkus 11y ago
  > I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Not bad_user, obviously, but excessive verbosity can be antithetical to readability. (As can excessive conciseness.) It can make the overall structure and meaning of the code hard to discern, even though can clearly tell where what gets assigned to what variables, etc.

oweiler 11y ago

Apart from the slightly better performance, memory consumption. Clojure's persistent collections require a fair amount of memory (which in most cases doesn't matter as memory is cheap).

jinst8gmi 11y ago

> Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine? If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Other than no new learning required I can't think of many reasons to pick Java as a first choice. Java tends to be popular because it's the oldest, most familiar default for the JVM rather than any particular strength.

ubertaco 11y ago
>If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Put another way: if you're on a dev team where nobody knows Clojure/Scala, and everyone knows Java, (and, optionally, the codebase is already in Java), and your team doesn't have time for everyone to learn an entirely new language (including cleaning up the beginner's mistakes that come with that process), then Java's the better choice. Don't get me wrong, Java grinds my gears sometimes, and I frequently wish I could use Kotlin or F# or some kind of typed Ruby in my Java-shop workplace, and I enjoy picking up the cool ideas from languages like Idris (dependent types are really cool!) in my free time. But I'm sympathetic to my coworkers in the environment where I work: 4 devs in the whole company, startup pressure to get to a break-even point so we don't go under, and a backlog longer than all of us could finish this year even if we froze it now. Sometimes circumstances require what looks like a short-term decision in order to ensure that there's a long term to worry about later.
- jinst8gmi 11y ago
  With existing Java code and/or a tight timeline with existing skills I can see how that would be the best choice :) I'm thinking more in terms of the surprisingly high proportion of Java developers who have never learned another language since learning Java 10-15 years ago and dismiss any alternatives without ever exploring what else is out there (you clearly don't fall into that category :).
  - 11y ago

lugus35 11y ago

Java shines by the number of java professionals available on the market.

deleted 11y ago
[deleted]

fulafel 11y ago

Many people have a gut-level aversion to dynamically typed languages.

aardvark179 11y ago

I love clojure, but on a large code base I find good refactoring tools to be extremely helpful when trying to evolve how things are implemented. In that respect Java wins hands down just because of the tooling around it. It also may be easier sometimes to use Java for working with particular libraries. There are however areas where I'd use clojure every time. Luckily the JVM is really good for doing mixed language work on, so you don't have to work entirely in one language.

winterbe 11y ago

Most parts of software development probably is not about starting new projects from scratch but about maintaining existing code bases. That's where Java really shines due to its (often hated) backwards compatibility.

lmm 11y ago

All IME, and as a Scala fan: Clojure has a weakly integrated type system (an inherent disadvantage of optional type systems). At the simplest level this makes silly errors much easier and means you have to write more tests to maintain the same defect rate. The lack of types mean you require extensive use of macros for advanced functionality. IME macros have major maintainability issues in a multi-person codebase. Both these things are major disadvantages for automatic comprehensibility of code. Autocompletion can be more-or-less usable but will never be as good as in Java or Scala. Automated refactoring is inherently unsafe in the presence of macros (Scala's fancier typed constructs (typeclasses, for/yield with custom types) mean you need macros much less often; Java tends to force you to expand these things out by hand (or else use annotations which act as de facto macros), which has its own maintainability issues but does at least mean automated refactoring will work correctly). Some of the language culture pushes people towards less principled abstractions. From this side of the fence that looks like anti-intellectualism; no doubt from their side it's pretension on typed programmers' part. But either way I think they're setting themselves up for long-term maintainability issues (e.g. the semantics of clojure transducers in the presence of errors are infuriatingly not-quite-right, which will either remain a painful gotcha forever, or necessitate a painful migration in the future). As a minority language Clojure may not be as well supported in the surrounding ecosystem - partly things like IDEs but also code coverage tools, profilers, monitoring.... Remember the JVM ecosystem is wider than just the languages themselves. There are good things about Clojure, but it's by no means clear-cut.

raspasov 11y ago
What do you think is not quite right about errors in tranducers? When you use them with core.async channels you can supply an optional exception handler, which is quite nice. In terms IDEs, Cursive for IntelliJ is great, and it gives almost Java-like capabilities (with limitations inherent to more dynamic languages, of course).
- lmm 11y ago
  I forget the exact behaviour, and maybe it's been improved. But I remember that it didn't map cleanly onto values - sometimes you want to continue after a single error, sometimes you want to bail out immediately, and the ways of doing this felt very ad-hoc.

meekins 11y ago

Java EE is currently an excellent framework for complex distributed enterprise applications.

pjmlp 11y ago

It is the systems programming language of the Java platform, if you see the JVM as an OS. So you need to be comfortable with it, as there will always be cases you need to jump out of the alternative language into Java. Also, most companies will only hire to work with Java on the JVM, because they don't want to be hostage of the cool language some of the dev team guys/contractors decided to use instead. It is very rare to see traditional Java shops to use alternative languages. Usually the ones using them are either startups or companies like Facebook and Twitter, which aren't the typical business culture.

jbooth 11y ago

Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance. They're conservative about adding features, so they've managed to keep the language pretty small, and the core concepts of "what is good Java code" have been mostly the same for like 15 years, even through major releases like 1.5.

jinst8gmi 11y ago
I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java. Java developers usually consider features which the language doesn't have to be bad or make code unreadable, that is until those same features are added to Java, when suddenly they are a source of pride and a sign of Java being "modern". In reality Java's feature freeze until Java 8 was largely driven by Sun's financial woes.
- RyanZAG 11y ago
  I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value ) However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.

mark_l_watson 11y ago

I have been using Java since the first beta, and have written a large pile of Java books (pun not intended), but I too prefer Clojure as a practical, simple to use and simple to read language. That said, Clojure / Java interop is really nice. I frequently find myself simply adding existing Java code to my lein project file. I would suggest just keep using Clojure and when it makes sense, mix in Java when you want or need to.

chvid 11y ago
This might sound like a snarky comment but it is actually not. If you want a dynamic language on the Java platform; then why not use JavaScript? There is an easy-to-use engine in Java 8 and JavaScript is widespread and somehow familiar to Java-developers.
- mark_l_watson 11y ago
  I like JavaScript for Meteor.js and general front end development but I have never thought to use embedded JavaScript. Clojure is a practical little language and suits my taste.
- lmm 11y ago
  JavaScript is just not a nice language to maintain - bizarre scoping, confusing inheritance model, extremely clunky syntax, confusing standard data types. Being "dynamic" isn't a feature so much as an acceptable cost, but JavaScript doesn't really give me any expressibility advantage over straight Java, yet alone compared to Scala.

malcolmgreaves 11y ago

IMO Java doesn't shine anywhere. It's statically typed, but lacks support to be flexible. Thus many Java programs rely on reflection at runtime or casting. This negates all of the benefits of static typing, turning the language into a dynamic one. The main choice is then either Clojure or Scala. This comes down to dynamic versus static type checking. With a dynamic language, one is significantly less sure if a program is correct. In large programs that use dynamic languages, many tests must be created that are essentially doing the work that a type checker in a static language would do automatically. In a static language, entire classes of bugs are eliminated. Scala provides the best support for strong, static typing on the JVM.

incepted 11y ago
> Scala provides the best support for strong, static typing on the JVM I'd argue that Ceylon and Kotlin offer most of Scala's advantages with none of its baggage and bloat. And drama.
- lmm 11y ago
  All those things will come as those languages mature, and until then neither has much library or tool support.
  - incepted 11y ago
    No tool support? Kotlin and Ceylon both have very good IDE plug-ins that already work much better than Scala, despite Typesafe pouring a lot of money into their own plug-in.
    - lmm 11y ago
      There are a lot more tools in the JVM ecosystem than just IDEs, and by now most of them have Scala support.