I have started building a system with clojure, mainly because I need to use Java libraries. My main problem with Clojure is lack of proper IDE support (getting it to work well with Emacs on Windows was not trivial). I was wondering what difficulties other people have had.
Lack of "user friendly" stacktraces (coming from Haskell, it felt like a giant step back), but you get used to it eventually and learn to work your way from slime/swank.
Still having nightmare about the days when we didn't have leiningen (classpath mess, start scripts, dependency "management" hell).
It improved a lot and is improving every release it seems.
getting bitten by the "lazy bug".
(with-open [file (writer name)]
(map #(.write file (process %)) (get-data)))
and "the lazy bug" makes your file empty!
ps: the answer is dorun
An idea: if you are working in a Java environment then you might consider sticking with your Java IDE and use a Clojure plugin rather than going with Emacs etc.
For example, my setup works beautifully with:
Eclipse 3.6.1
Counterclockwise plugin for Clojure 0.2.0 RC1 (http://code.google.com/p/counterclockwise/)
Clojure 1.2 libraries (either on the eclipse build path, or automatically imported using Maven)
Interactive development using the REPL provided with Counterclockwise (nREPL)
Since I need to use a lot of Java along with my Clojure code (often in the same project!), this setup makes much more sense than wrestling with a whole new set of tools.
My problems so far:
It wasn't too easy to get EMACS/SLIME with Common Lisp AND Clojure.
Clojure 1.2.0 stacktraces are a mess so far. It's often so hard to get it what went wrong.
The debugging experience is not very nice. Tried JSWAT and Counterclockwise, but not really happy with it.
Changing my mindset from imperative to functional programming.
It got better after I read a book on lisp programming.
Related
Something is puzzling me after reading the this great answer to a related question:
There are two possibilities to share a function that I wrote in Clojure with Java developers
The first one is providing it in a JAR file so that they can call it as if I had written it in Java. Sounds great for Clojure advocacy.
The second one, the purportedly better way, requires those Java developers to use things like clojure.lang.IFn or clojure.lang.RT and invoking functions by passing their names as strings (!) instead of just calling them.
Why is the second approach "the better one"?
You are sorta setting up a false dichotomy here. Every approach involves creating a jar file: that is just how JVM programs are distributed. But there are 3 different ways for Java code to invoke Clojure code contained in a jar:
Use methods in clojure.lang.RT to initialize the runtime, load files, and then look up vars. This is the old, deprecated approach.
Use methods in clojure.java.api.Clojure to look up functions and invoke them. This is the newer version of (1), and hides some of the messy stuff you could accidentally get wrong.
Use gen-class in the Clojure library to define a more Java-friendly interface to the Clojure functions.
You can still do (3) - there's nothing wrong with it exactly. But gen-class is a pretty clunky tool, and except for the simplest examples like exposing a number of static methods, it's just not a lot of fun, and it's not easy to provide an API that "feels" like a Java API using Clojure.
But you know what's great at providing an API that feels like Java? Java! So what I recommend if you want to make a Clojure library easy to use in Java is to include some Java code in your Clojure library. That Java code, written by you, bridges the language gap. It accesses your Clojure code by mechanism (2) above, and presents a Java-friendly facade so the outside world doesn't have to know there's Clojure underneath.
amalloy/thrift-gen is an example of a library I wrote years ago following this approach. It would not be at all easy to write this in pure Clojure, just because traditional Java idioms are very foreign to Clojure, and it doesn't support them all very well. By writing my own Java shim instead, Java clients get a very comfortable interface to work with, and I can just write Clojure that feels like Clojure instead of a bunch of gen-class nonsense.
I'm new to Clojure but my end goal in learning the language is to use the Clojurescript compiler, since I plan on using the generated code on the browser VM.
Since there tutorials are abundant for Clojure and Clojurescript is just another compiler I'm doing the Clojure tutorials, but now I got to a point where I want to know where is the line between the libraries that are core clojure that will compile to javascript fine and the ones that won't.
For example, in the tutorial I'm following for Clojure I was reading this but it seems this is already using deep Java objects, and not core Clojure commons:
user=> (.length a-string)
7
user=> (.substring a-string 3)
"name"
user=> (.substring a-string 3 5)
"na"
// And for static methods
user=> (def rt (.getRuntime Runtime))
#'user/rt
user=> (.freeMemory rt)
30462304
The beginning of the chapter said In Clojure, strings are the same as Java strings, but not that Clojure uses String from Java, which is a different thing.
So, if my goal is to develop Clojure targeting the browser, what APIs and types can I use? Is there a simple distinction for this? I imagined that anything that doesn't need to be explicitly required (core libs) would be core Clojure and I wouldn't be tying myself the Java libs.
Thank you in advance.
If you want to write code to target both Clojure on the JVM and ClojureScript, see cljx.
Without using such tools (to embed code snippets explicitly written for either backend), it is not generally expected that substantial programs will work against both independently.
How can I use Clojure-CLR on Unity3d?
The complex answer is "maybe you can", the pragmatic answer is "no, you can't".
Sylwester suggested this is a duplicate of using it with Mono, which isn't really true, because Unity uses its own fork of Mono(one that's very old...2.6?), so something that's compatible with Mono won't necessarily have compatibility with Unity.
ClojureCLR requires the DLR(though they've been moving away from it), which means it's incompatible with Unity, since the DLR requires Mono 2.8+.
That said it's possible to add the DLR as a dependency, and to compile ClojureCLR to .dlls and access it from Unity, this is what I did, however my experience was that I could get a lot of my code to run fine in the development environment, but when I'd build the game, everything would break, it'd just ignore the Clojure stuff.
If Unity moves to a higher version of Mono, or ClojureCLR gets rid of dependence on the DLR, I don't see any reason Unity couldn't support it, and I actively look forward to it. But for the moment, it's not practical.
If a work-around exists(and it probably does), I never managed to figure it out.
People in the Clojure community have gotten something working.
From #swannodette "Looks like #ra and #timsgardner got Clojure running inside Unity last night"
http://f.cl.ly/items/2T2d340o0k0W2d44212G/clj2.gif
I've decided to look into Clojure (inspired by this book). After a bit of research I've learned that I may be able to take advantage of my .Net experience by using ClojureCLR rather than needing to learn the various Java libraries. However, I have found very little documentation on the CLR version of Clojure (even the official website seems to push you to the JVM implementation's documentation).
Does anyone know where some decent tutorials, books, articles or documentation can be found? If there really are none, is it safe to assume that I can learn via the JVM implementation for most of what I need to know (i.e. there is little difference between the two implementations, so the knowledge will be fairly transferable)?
If need-be I am willing to learn the JVM version and the Java libraries (would be good to expand... which is why I'm looking into a functional/lisp language in the first place).
For now you will likely find a smoother learning experience for Clojure using the JVM. There are a some really exciting new ideas in Clojure and regardless of the platform you choose these will be a lot of fun to learn, though you may find it easier to concentrate on what you are trying to learn if you are on the platform with better tooling and a bigger community.
The part of the language that makes Clojure, Clojureish will of course be exactly the same, and once you're comfortable with them then the CLR side of thing will likely be more accessible. I get the impression that the general consensus is that once Clojure is implemented in Clojure the CLR version will track much more closely to the JVM development.
Clojure has attracted a huge following* of enthusiasts with no Java or .NET experience at all (those coming from Lisp) so I don't think that the differences between .NET vs JVM are a common stumbling block.
*Arthur's opinion :)
There is a blog devoted to the Clr version of Clojure that may interest you here. I believe the contributors are both the original Clojure creator (Rich Hickey) and the CLR port creator (David Miller).
I have a set of classes written in C++. What would be best way to call them from a Perl script? Thanks.
I'm not particularly fond of SWIG and prefer to write the interfacing code myself. Perl comes with a sort of pseudo language called 'XS' for interfacing to C or C++. Unfortunately, in order to use it, you will need to know at least C, Perl, and then learn something about the interpreter API, too. If you already know Perl and C well, it's not such a big step. Have a look at the following core documents on XS:
perlxstut (XS tutorial)
perlxs (XS reference)
perlapi (Interpreter API)
Additionally, there's plenty of tutorials and how-tos on the internet.
Now, interfacing to C++ using XS requires some additional steps. It can be a bit frustrating to work out at first, but neatly falls into place once you get it. In this regard, the core documentation is sparse at best. But all is not lost. Mattia Barbon, the creator of the wxWidgets bindings for Perl, wrote a great tool "XS++" that makes this almost dead simple (or as simple as XS). It's included in Wx, but we're working on splitting it out into its own distribution. This is work in progress. You can find Mattia's XS++ code and a modified version of mine on github.
Barring a release of a standalone XS++ to CPAN, I would suggest learning to write XS for C++ from other resources:
Quite a long time ago, John Keiser wrote an excellent tutorial on XS and C++. It also includes further pointers to useful tools and documentation.
I learned XS&C++ from that tutorial and some examples I found on CPAN. I don't recall what I looked at then. But now I can point to my own work as a (good or bad, I don't know) example: Math::SymbolicX::FastEvaluator.
Similarly, the planned XS++ distribution contains a complete (albeit pointless) example of using XS++ to interface C++ and Perl. Since XS++ is translated to plain XS, you can use it to generate examples.
PS: There's also the Inline::CPP module. If that works, it is probably the easiest solution. I doubt it can handle templates, though.
Check http://www.swig.org :
"SWIG is a software development tool
that connects programs written in C
and C++ with a variety of high-level
programming languages. SWIG is used
with different types of languages
including common scripting languages
such as Perl, PHP, Python, Tcl and
Ruby."
I would normally choose XS, like tsee, but there is also Inline::C (or Inline::CPP in this case). I dislike SWiG and tend to avoid packages built around it.