Better performance in App Engine with new Lisp language Clojure
googlecode.blogspot.com
googlecode.blogspot.com
Python is now my go-to language, especially because of Scipy, NetworkX and bridges like RPy.
I would definitely put in the time if someone with mathematical modelling experience can support the idea that I'll be more productive in Clojure. Anyone?
I really would love to see a list of testimonials and anti-testimonials of people from various fields that switched to Clojure and either got much more done or got burned.
Sorry, I realise that this is a wee bit off the main topic.
Maybe that's what I should lose, the paralysis of starting out down the wrong track and simply do stuff wrong until I find a better way.
At the moment my vote would be for python or clojure + r.
So far the experience has been great. Apart from the language being really well designed, there is the wealth of java libraries accessible just by adding a single line to your project.clj. And there is Clojure support for parallel programming — there is nothing like spending all of 5 seconds on making one of your hotspots use 16 cores just by adding a 'p' in front of 'map'.
All in all, so far it has been a great experience. There were amazingly few bugs and problems.
This shows a lot of promise, and it would be great if App Engine could become (in a way) Clojure's Heroku.
Do you still have to deal with Java's baggage even if you run Clojure on App Engine? How much can you abstract away? Any libs?
The good news is that you also get Java's "Deployment for Dummies" solutions (just copy the JAR/WAR and you're good to go), though.
The nice thing is that if you suddenly decide you need to use a Java library (say, one of the Apache Commons libs), you just add one line to your project.clj file, do "lein deps" and boom, you can use the library in your project.
Having written quite a bit of software in Common Lisp, this is a welcome change.
Using ring and ring-servlet you can build the servlet app engine wants. Libraries like compojure build on top of ring.
The datastore can be accessed using http://github.com/r0man/appengine-clj or http://github.com/smartrevolution/clj-gae-datastore.
Accessing the blobstore has not been abstracted away yet and requires a bit of work to get uploads acting correctly with ring/compojure.
I've not touched task queues, xmpp, mail, or memcache and have not seen any abstractions for them.
I'm curious about the "how to get rid of Eclipse"-part. How do you "Go to implementation" and "Find usages" in Clojure without a 7 key-combination in Emacs? I would love to take a Clojure-IDE for a spin.
Go to implementation is M-. with SLIME in Emacs. It can even open up Clojure source in jar files on the classpath and let you edit (and save!) them from there.
Find usages is a little more complicated: C-c C-w c, but not too bad.
If you could write a server (not a plain HTTP webapp necessarily) in Clojure, Python, or Node.JS, provided you know all three, which would you choose and why?
1. Concurrency 2. The most (largest qty of) available FOSS libs anywhere 3. Speed 4. The ability to extend the language 5. WORA 6. Text/string processing
Python will win in scripting/*NIX integration, though.
Don't really know enough about Node.JS
As far as I know, there are semi-frequent breaking changes. Ryan Dahl has said that API stability should come with version 0.2.
Ha! It's a brave new world. It used to be you needed a whole version number under your belt before critical stuff could be built..
BTW, the new Buffer objects are awesome, and provide massive speed increases with binary data.
Java has a lot of great libraries for which there are not terrific examples in Python. Clojure gets all of them.
> Where does Python lack in text processing?
Clojure handles large strings better than Python (unless you start using substrings, in which case an underlying java bug hits you).
(oh, and Clojure is not a deliberately and comically crippled language).
Haskell is one language where i encountered that too often, whereas Clojure's Windows support does not feel second rate. The portability of the JVM and Java's libraries combined with a joyful functional language like Clojure is very attractive.
Now that the JVM is really running just about anywhere it has become a viable platform to target, and java is just one more language that targets it.
Clojure, groovy and scala are built on top of the JVM, but there are also plenty of languages that are available on mutliple platforms.
Whoever came up with just-in-time compilation deserves a gold medal, without that none of this would have ever happened.
My understanding is that JIT in Java is a variation on what the Smalltalk world called dynamic optimization. That was introduced into Smalltalk by Peter Deutsch and Allan Schiffman in the 1980s, but I don't know whether or not they invented it independently.
That invention pre-dates java itself by quite a few years, but then again, java has a lot of elements in it that were considerably older, iirc there was UCSD pascal P-code, which was another virtual machine like environment with an abstracted machine, and the 'forth' language which has quite a bit in common with how the JVM operates on the lowest level.
I was just reading that 'early history of smalltalk' thing the other day, and it struck me as though really, since the 60's there hasn't been that much progress at all.
The 'mother of all demos' combined with the 'dynabook' (iPad?) really pretty much covered everything with the exception of the mobile phones.
Sure, we all have the equivalent of several Cray-1's in our houses now (or even in our pockets), but conceptually we are still were we were back then.
Everything looks great, we're burning billions of cycles on spiffy user interfaces and showing movies.
But under the hood it's old hat.
That's why I keep circling around and around trying to find my new 'home', the environment that I think will last me for the next 10 or 20 years.
I haven't found it yet. All I see is endless repetition, configuration files, minor tweaks. Rarely a bold move (fleet comes to mind, but I don't think it will ever be a commercial success). Programming seems to be mired in endless detail, fiddling the bits and tweaking things to get a link here or a widget there and to get them to talk to each other. User interfaces have become the main focal point, when they weren't (or at least when they weren't as pretty) we were happy if stuff just worked.
I feel like a homeless guy looking for a place to stay.
Clojure might be it, I don't know...
but I'll try it for sure. No point criticizing the soup before you've eaten it.
Thanks for digging up that jit reference.
Why wouldn't Scala/Clojure/Groovy et al be possible without JIT? It's possible to run on the JVM anyway, whether said VM supports JIT or not.
Java before JIT was added to the JVM was dead slow.
"Generalizing the idea for the full set of operations, we can write an on-the-fly compiler that translates the current regular expression into special code optimized for that expression.
Ken Thompson did exactly this for an implementation of regular expressions on the IBM 7094 in 1967. His version generated little blocks of binary 7094 instructions for the various operations in the expressions, threaded them together, and then ran the resulting program by calling it, just like a regular function."
It's kind of similar to the feeling you get once you've programmed in a language with GC. You really don't want to go back, unless you have to.
Quick heads up. The ease of FFI (in Clojure's case with Java) is not unique to Clojure and it isn't necessarily a great thing. It's also an issue with Common Lisp: as FFI with C is easy, there's less incentive to develop idiomatic libraries for the language. E.g., Common Lisp lacks a standard modern way to network I/O, but it's largely been ignored as larger users of the language e.g., ITA could always build and standardize upon an internal C-based extension.
That being said, Clojure is great for reasons beyond running on the JVM: a unique approach to concurrency, incorporation of ML-family features, first order data structures beyond lists (maps, vectors) and the fact it's a Lisp-1 with a great macro facility. I'd love to see Clojure also go beyond the JVM and onto CLR, Parrot and LLVM.
Interestingly enough the other prominent "next generation Lisp", arc, is also a Lisp-1 with true macros (as opposed to Scheme's hygienic macros).
Why target another platform if not for its libraries? If Clojure is exactly the same on the JVM as it is on LLVM, why should it ever leave the JVM?
I am not in the business of conjuring up hypothetical situations about the demise of Lisp implementations and libraries; that doomsday scenario of having to recreate civilization from specs is simply not in my contingency plan :-)
Never underestimate the power of convention, de facto is the rule, rather than the exception.
Do you literally mean anywhere or compared to other GAE languages?
If so do you have a rough estimate on how many Java/Clojure FOSS libraries/modules/packages there are?
For instance, you can't really build an assembler for a new architecture from scratch without some form of assembler and so on.
The bootstrapping sequence seems to be endless, you could be blogging about writing your blogging tool if you had it already. We always seem to need some scaffolding underneath it, just one more turtle on the stack.
No more hand calculating branches these days, /me is happy ;)
(found it here: http://github.com/mmcgrana/ring )
http://code.google.com/appengine/kb/java.html#What_Is_A_Load...
It bothers me that people don't mention this.
That said, I have doubts about Clojure + AppEngine because of the loading request times. I can get a Java + AppEngine app to do about a 1 to 2 second loading request time by not using JDO and minimizing dependencies.
Unfortunately, loading the Clojure JARs (or the JRuby JARs) increase the loading request time.
Sometimes when I go to TheDeadline, I see almost a 10 second delay on the first page load. Does not happen often, but it does happen.
If they've got Python running on the JVM, why aren't they contributing back to Jython (or releasing their own Python->JVM bytecode compiler)?
"Writing less code requires less time."
Seriously? Then again, it /is/ a "to-do" app...