Hacker News Reader

Comment by smanek | Hacker News Reader

It really depends on you (and I say this as someone who just chose to write a huge CL webapp).

If you have experience with Java - I'd probably go with Clojure. If you have a lot of background with Lisp (i.e., Slime/ASDF don't scare you) I'd go with CL. If you don't know either - just pick what's more interesting to you (but be aware there's a steep learning curve either way).

On the CL side of things:

-You want to use Hunchentoot as your webserver

-CL-SQL for persistence

-CL-WHO if you want sexp => HTML, or html-template if you want pure HTML templates

-Parenscript is good for Javascript since code you write in Parenscript can run on either the server or browser (it makes it really easy to Ajaxify things, for example). But, if you're doing lots of really fancy JS and you're great at the language already, I'd stick with pure Javascript.

-For JSON, I personally prefer YASON to cl-json, but take your pick (they're both fine).

View on HN

I preferred Postmodern last year, for interacting with Postgresql. Around that time, I vaguely recall it was considered faster than CL-SQL as an Elephant backend; and I found it far easier to install than CL-SQL. (I recall during CL-SQL's installation, it kept signalling errors for each DB it supported which I hadn't installed. Someone at the office said I was supposed to just keep telling Slime to ignore the errors, prodding the install forward. That actually worked.)

Maybe things have changed in the interim?

If the OP chooses Clojure, then I'd note that the Java classpath really demands you respect its inflexibility. add-classpath is a second class citizen; I've had JDBC (the Java DB manager) swear up and down that it registered the MySQL driver I loaded via add-classpath. But come time to read from the DB, it only worked when I ensured that the MySQL driver was loaded at the beginning in the normal way. What that implies is that if I want to load a new DB driver, I'd probably have to restart the JVM. (Or do something absurdly tricky, or debug more deeply.)

I think your problem is more likely to be with class loaders than class paths. Clojure probably has to set up its own, to allow all the monkey patching it does, including dynamically setting the classpath. If JDBC was loaded already, it will be able to see Clojure objects passed as parameters, but not able to find the class by reflection on its name.

Experience with Java won't get you far with Clojure. They're about as different as two languages that share libraries and a VM can be.

I think it would be easier to go Java => CL because at least you still have mutable data, imperative style, and usually a low level interface to OS threads. The object system is different, but it's front-and-center.

Clojure treats objects as something you make for unavoidable interop. It has transactional references and snapshot values. It emphasizes functional style. It has a time semantic - something you can also say for Scala, Erlang, and Go, but not CL or Java.

My preference is for Clojure, but for a Java coder it will feel a lot more alien.

The object system [in CL] is different [than Java's], but it's front-and-center.

No, it's very much off to the side. I almost never use CLOS. While it's far better than static OO, it's still OO, which means you still get object spaghetti. The beauty of CL is that its object system is basically just a library and you don't ever have to go there.

Side note: it still surprises me how few people have figured this out about OO. Yesterday I was browsing through the source of an OO-style JS library and it didn't take 30 seconds before the old familiar frustration kicked in of having to wade through a morass of methods-type-declarations-and-constructors in order to find the simple line of code I was looking for.

People used to talk about learning to think in objects; unlearning to think in objects is way better.

Reply on news.ycombinator.com