In general, is it possible to use Scala Frameworks with Clojure and vice versa?
I heard a lot of good things about Akka and Play but i like Clojure better than Scala.
It surely is possible. You can call clojure code from Java and vice versa. You can do the same with scala as well and though I have never tried it, I think you also can call Scala from clojure and vice versa.
But I cannot imagine how one would do that in a useful way? Clojure being data first vs. classes for Java and Scala being the main concept I don't see how one would use them on the same parity.
Maybe writing a wrapper around the library from one side or the other so you can stay within one language for your business logic, that would seem useful.
OTOH, that I dont see it being useful, doesn't mean there is no use case for it.
Still, I would suggest doing a prototype with Scala and Akka for your problem and compare it to a prototype with clojure and maybe core.async and see what fits you better.
There are interoperability issues between Java and Scala code. Essentially, you can use Java libraries from Scala without any problem, but using a Scala library from Java will have some limitations. Some features such as traits and implicits aren't part of the Java language, and they can be essential parts of libraries. I suspect that you'll run into the same issues you have with calling Scala code from Java if you end up picking Clojure.
All in all, if you're going to use the Play! Framework with Clojure, I'd recommend using the Java API instead of the Scala one. There is also a Java API for Akka.
Related
I am writing a Clojure program which need to generate a Java source. Is there a good idiomatic way/template engine for that.
In Java world I would probably use Velocity or Freemarker. I know I can still use them from Clojure, but wondering if there is better way.
Probably you can take a look at Rythm template engine, which is much faster than Freemarker and Velocity, also much easier to use.
Document could be found at http://www.playframework.org/modules/rythm-1.0.0-20121210/home
Note although the document is for play-rythm module, the most part of it also apply to pure rythm environment
I've been using Clojure with StringTemplate for the purpose you describe for quite some time now with good results. I 've also defined a helpful set of macros that make the invocation of the StringTemplate renderers from Clojure a breeze. StringTemplate is established, solid and used for heavy-weight compilers so it can't fail you. On simplicity / speed or other trade-offs I cannot comment.
I came across google guice and could not really understand it and what it did, although there seems to be alot of hype around it. I was hoping to get a clojurian perspective of the library and why it is needed/not needed in clojure applications and if there was anything similar built into the language.
Because of Java's OO and type system, dynamically switching between different underlying implementations (for test (mocking) purposes for instance) can be difficult to manage. Libraries like Google Guice are intended to handle these dependency injections in Java more gracefully.
In Clojure and other functional languages functions can be passed around, which makes using different implementations much easier.
There's several ways this can be done in Clojure:
Using your choice of function as parameters in higher order functions.
(Re)Binding your choice of function to a var.
Encapsulating your choice of function inside closures that can then be passed around and called.
Chapter 12 of Clojure Programming has some nice examples of OO patterns like dependency injection and the alternative ways to handle these in Clojure.
Sean Devlin also has a Full Disclojure video on Dependency Injection in Clojure. His example might have been chosen better, though. Instead of using completely different function implementations in his closure, he uses a factory that returns different 'versions' of a function. The gist stays the same though.
Basically, dependency injection is a pattern that is a necessary evil in OOP, and can be solved easily (or is not even a problem) in FP.
The rough Clojure equivalents are still in development. There are two libraries currently in development (as of Oct '12): Prismatic's Graph (not yet open sourced) and Flow by Stuart Sierra.
Note that I consider Guice to be more than dependency injection. It provides a framework for application configuration / modularization. The above libraries aim to accomplish that goal.
I'm at loss of how to create a Java enum in Clojure. I want to create a Java enum that uses a Java interface and then pass it into a Java method, all within Clojure. I want to do this to work with the neo4j graph library (I don't want to use someone's prebuilt interface, I want to write my own interop code).
I searched around the internet, and it looks like I can use the proxy method, but I can't for the life of me get it to work. Here's the equivalent Java code I need to write in Clojure:
private static enum RelTypes implements RelationshipType
{
KNOWS
}
And here's my stab at it (It's not right :( ):
(proxy [org.neo4j.graphdb.RelationshipType] [] (KNOWS))
I'm also wondering if there's a good website that documents things like this that I'm missing. I know about the Clojure docs on the Clojure site, which is really useful, but for example of usage I can't always find what I need. Perhaps I need a good reference book?
Why not just create the enum in Java? Sometimes falling back to Java is the simplest answer.
Here is a very old thread about using proxy to define enums from Rich Hickey and Stuart Sierra along with some alternatives using gen-class. I think the proxy path should work with something like this for you:
(proxy [Enum org.neo4j.graphdb.RelationshipType] [ "KNOWS" 1 ])
But that won't generate anything you'd want an external Java user to use, in which case gen-class is likely the better solution.
I am currently deciding on an alternative JVM language to port an existing Swing desktop application written in Java 6. Given that JavaFX specifically targets this kind of application, it would seem that my best option is JavaFX Script.
However, what about other kinds of applications and libraries? Would JavaFX Script be the best choice in general for a second JVM language?
Currently, it seems that Scala is the most talked about alternative to the Java language. This month (October 2009), it is at position 34 in the TIOBE index, while JavaFX Script is at position 44, and Clojure, Fan, and Groovy are at positions below 50.
So, what are your impressions? Which language would you invest your time in learning and using (and why), assuming you can freely choose the language for a given project to run in the JVM?
My main question would be: why are you porting an existing application? The answer to this question may give you some idea of where you want to go.
Some quick perspectives on the main choices:
Scala is in my view, a better Java than Java. If you want a language that takes the best bits of Java buts adds a lot of new innovations and features, then it may well be for you.
Clojure is an amazingly well designed language, particularly if you believe in a future of highly complex, concurrent applications. It's also extremely productive - I can probably create more value/hour in Clojure than any other language. However, unless you already know Lisp it will seem very unfamiliar at first. If you are willing to live on the cutting edge to get these benefits, Clojure may well be for you.
JavaFX script - has some very nice features for GUI design, and clearly has support of Sun/Oracle. On the other hand, I don't see it having massive traction outside this domain. I'd suggest giving it a trail run to see if it meets you needs.
Java - should still be on your list! If the reason you are porting is because the code has become difficult to maintain, then maybe a focused phase of re-factoring while staying on Java can get you the benefits you want. It's possible to write perfectly good GUI applications in Java.
Groovy - really nice scripting language on the JVM. Particularly good if you want to embed scripting features within an existing Java/JVM application. Not sure I'd choose it for (re)writing a complete application however.
JRuby / Jython - haven't seen these much myself but heard good things. Probably most suitable if you have Ruby / Python skills in the team but also want the benefits of the JVM platform.
The best alternate language, and the best language overall, IMO, is that which best allows you to write the program in the best model for you.
So, if you are writing a GUI app, then Scala may be the incorrect choice, as you wouldn't be moving away from Swing.
If JavaFX best meets your needs, then use that language.
If you know LISP then Clojure would be a good choice, but, like Scala, not for this problem, it sounds like.
If you don't know lisp and you want/need a functional programming language, then Scala would be the best choice.
Basically, there is no one language that is best in all situations, it helps to know what you want to do, and the strengths/weaknesses of the various options.
Those all sound like good choices. You could add JRuby to the list...
Those of us who use multiple languages to solve problems can combine them in a lot of ways. Personally I use PL/SQL, XSLT, JavaScript, and Java plus the pseudo languages HTML, XML, CSS, Ant, and Bash. What do you use?
Paraphrasing one of my favorite quotes:
Always write your code as if it were going to be maintained by a homicidal maniac that knows your home address.
I have a D/MySQL/JavaScript[1]/HTML/CPP[2] app.
[1] compile time D template generated
[2] C pre-processor used to generate apache configs and SQL sprocs
Yes, I am trying to take things to the insane! ;)
I work on a desktop application, so my alphabet soup looks like: C# and C++ as well as XML and T-SQL.
Java + Clojure works very well as a combination for me.
Java is good for the low level code that needs to be well optimized. It also gives you access to the huge array of libraries in the Java ecosystem.
Clojure is great for rapid development of higher level code, working interactively in a REPL. It has great support for meta-programming and concurrency, and I often use Clojure to "glue together" Java based components into a working application.
It helps enormously that Java and Clojure run in the same JVM - calling between the two is very easy and has effectively zero performance overhead.