This post makes me wonder, what about Jython? I don't use it, but it would be a nice fit for the OP (writing performance critical code in Java, and use Jython as a glue).
Are there any drawbacks with it?
Java for Everything
21–30 of 344 posts
Re: Java for Everything
#22The problem with verbosity and repetition is not that it takes longer to type the code, at all. The problem is that it creates dependencies which you have to manage by hand. Changing `Foo a = new Foo()` to `Bar a = new Bar()` doesn't seem that bad... except when you have to propagate that change through the code base. Half of Java's tooling is dedicated to solving a problem that doesn't exist in good duck-typed langu…
DISCLAIMER: I write mostly java, at home and at work.
Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all.
However, there are refactors for things that are much more difficult in a duck typed language. For example, if I have a bunch of methods named 'execute()' in my code, and I decide that this is a sad state of affairs and ripe for a refactor, I can refactor one of them to a different name and the tools will 'get it right', renaming the right calls (calls into this type) and not renaming the wrong ones (calls to another type's execute() method which has no relation to this type's execute() call). In python, you just can't do that. You'd have to rename all of them, defeating the point.
Similar concerns crop up for 'find callers', or 'add argument to method'.
There are also refactor scripts that are equally possible in both python and java, but which nevertheless require either a lot of manual editing, or an intelligent tool that can automate it, such as 'extract method' (taking the selected code and turning it into a (helper) method, figuring out which variable(s) would have to be passed along to make it all work as needed.
The point is: Duck typing does not obviate the need for refactors. It does make certain refactors impossible to 'safely' automate ('safely' in the sense of ensuring that, post-refactor, the code does the same thing as it did pre-refactor).
As far as 'dynamic == slow, static == fast' being a bit of an oversimplification, yup, that's true. Java _IS_ a heck of a lot faster than python, but that's mostly an implementation detail; you could make a pretty quick python. dynamic definitely does not help, but it can be worked around. Javascript JIT engines are seeing a lot of serious improvements right now, and a large part of it is guesstimating type info. They're getting pretty fast.
In the spirit of the article, though, static typing isn't just a boon for speed reasons (based on the practical upshot that java IS fast, and most dynamic solutions simply aren't, even if they could be with more engineering efforts): It becomes quite useful when you start having to read the additions to your code written by someone else, or rereading your own code half a year down the line when updates are required. explicit static typing also helps with refactoring, which is useful especially when you have to fix or extend your project.
Re: Java for Everything
#23"Java for everything, because it's the only statically type language with a fast runtime I know well".
Ok, Java is not terrible (PHP is terrible), and the JVM is a marvel of eat-your-RAM engineering, but this makes me sad, because there are only two things that can be said about Java: it's not terrible and it has a big ecosystem. There is nothing brilliant about it. It is slowly crawling toward convenient feature, but it's never going to be at the same level as a well-designed functional language in terms of correctness and readability-to-expressiveness ratio.
Re: Java for Everything
#24> I’m even taking this to an extreme and using Java shell scripts. Having a strong Java background, it is a pleasure to write Groovy for shell scripts. I like the blog post. Whenever I looked into other languages/platforms, I found the "tradeoffs" of Java (as pointed out by the other languages/platforms) to be less important for me. Java/the JVM may be evolving slowly. But it evolves and does it in a reasonable way (…
Why not just use Groovy for everything instead of java ?
Speaking of - how is Groovy doing these days? I looked at the Groovy webpage and I saw ads splattered here and there - never a good sign, I also see that the mailing lists are pretty quiet. Is Groovy dying?
Re: Java for Everything
#25> I’m even taking this to an extreme and using Java shell scripts. Having a strong Java background, it is a pleasure to write Groovy for shell scripts. I like the blog post. Whenever I looked into other languages/platforms, I found the "tradeoffs" of Java (as pointed out by the other languages/platforms) to be less important for me. Java/the JVM may be evolving slowly. But it evolves and does it in a reasonable way (…
Why not just use Groovy for everything instead of java ?
That's what I do. It has the added benefit that anything you do to improve using Groovy can be leveraged with plain Java too.
Re: Java for Everything
#26Java is perfect also for client side.
We have a client app (a complex VoIP softphone) with different codebase for all platforms (C++ for windows, java for android, ObjectC for iOS). Right now we are in the way to reduce all this in one single codebase written in Java and the user interface in html/css/javascript, so the user interface is always running in a webview.
-Java for windows desktop (there are pretty installers which automatically download and install the JRE if not present)
-Java for MAC and Linux desktop (same as for windows desktop. the same installer tools can generate also Linux and MAC packages)
-Java for Android (with a very minor conversion for which we already wrote a converter app)
-Java for Web (currently using a java Applet which works perfectly. We plan to use GWT to transform to JavaScript in the future)
-Java for iOS (will see)
This way we plan to cover 99% of all devices with java only (with some minor transformation for some platforms). What is your opinion on this? I am in the right direction?
Re: Java for Everything
#27I would just add one more thing - I doubt there is another language where you write native apps for Android, iOS and Web sharing 70% of the code: http://arstechnica.com/information-technology/2014/11/how-go...
From the JVM side, we have: Scala, Clojure, Groovy, Kotlin, etc thanks to RoboVM.
From the CLR side, we have C# and F# thanks to Xamarin.
Even the worst language among the six I have listed is still far better than the verbosity of Java.
Re: Java for Everything
#28He learned something that most good Perl programmers learn fairly quickly: The interpreter/compiler is just the VM; the real language is the combination of all libraries available for it.
There's no shortage of good libraries for Python. He just chose to not learn about them.
And all the fast ones aren't implemented in Python....
Re: Java for Everything
#29Java is perfect also for client side. We have a client app (a complex VoIP softphone) with different codebase for all platforms (C++ for windows, java for android, ObjectC for iOS). Right now we are in the way to reduce all this in one single codebase written in Java and the user interface in html/css/javascript, so the user interface is always running in a webview. -Java for windows desktop (there are pretty install…
On mobile devices the issue is Oracle dropping the ball and leaving to third parties (RoboVM, CodenameOne,...) the work of providing JVM implementations.
This on iOS, still no story on Windows Phone, which actually happens to be over iOS on some European countries.
Re: Java for Everything
#30That's where Go comes in very well in the interviews assuming interviewer also knows or can understand Go. It has short and precise syntax and the code usually doesn't need explanation.