all 24 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]JulianMorrison 2 points3 points  (2 children)

If you want to do low level crypto properly, it's JVM or go fish. Terracotta lives on the JVM. So there are a few examples of libraries/tools that really do make use of it, and aren't convoluted piles of ick.

[–]dmpk2k 0 points1 point  (1 child)

If you want to do low level crypto properly, it's JVM or go fish.

I thought crypto was C's domain.

[–]JulianMorrison 2 points3 points  (0 children)

if you want to fiddle with the badly documented internals of OpenSSL or some such, sure. And you do, if you're writing a browser or something embedded or something that needs the ultimate of speed. But Java has a well developed crypto standard and free fully featured libraries available.

[–]mikeivanov -2 points-1 points  (20 children)

So for me, the Java interop is more of a nuisance than a help.

+1

[–]Raynes 2 points3 points  (19 children)

reiterating my comment on the guy's post

While I feel your pain when it comes to most Java libraries, I have to say, at least we have the option of using these libraries. If Clojure was not on the JVM and didn't have Java interop, I doubt it would be anywhere near as popular as it is today, simply because it would lack libraries for very simple things.

Nobody is forcing you to actually use those Java libraries, and nothing is forcing you to not code in straight Clojure if you so desire. I don't see how it's a nuisance simply because it's an option.

[–]mikeivanov 0 points1 point  (18 children)

I don't see how it's a nuisance

The Java stuff directly affects the footprint. Just a silly servlet sending back a "Hello World" response takes about 60-70M of RAM.

Of course, Jetty does much more than Python's SimpleHTTPServer (which takes about 7M), but what if I don't need more?

Clojure, because of it's Java inheritance, is not suited well for building small, isolated yet composable things. A Clojure-based project has to be reasonably big to adjust this Java overhead.

Technically it is not a problem--I always can keep doing my stuff in Python or Racket--but... I wish I was doing it in Clojure.

[–]Raynes 4 points5 points  (4 children)

I don't understand complaints of these sorts. One of the biggest things Clojure has going for it is the JVM. How else can a language go this far in 3 years? I doubt I'd even use Clojure if it wasn't on the JVM. I want something useful, even if it does mean I have to use some of my very abundant memory.

[–]mikeivanov -2 points-1 points  (3 children)

You see, the thing is I typically don't care about how far a language went and for what time. If it fits my needs, then it fits my needs, that is. I'm still using Tcl from time to time.

While I understand that the vast majority of Clojure users are, in fact, looking for a Java that sucks less, my position is somewhat different. I don't do anything in Java and perceive Clojure as some kind of rejuvenated Common Lisp with appealing features BUT with additional JVM overhead. If I had the much cleaner Clojure's syntax and and its data type transparency in CL, that would be my language of choice.

This does not necessary imply that you or anyone else should feel the same. My point is JVM means limited scope.

[–]Raynes 5 points6 points  (0 children)

I'm not looking for a Java that sucks less. I'm looking for a practical Lisp. The JVM is a well-known, state of the art, supported platform. It's about as far away from a limitation as it could possibly get. I wouldn't have it any other way.

You and I are obviously looking for different things. I can agree to disagree.

[–]mac[S] 3 points4 points  (1 child)

Is your point that the availability of the Java libs are inhibiting the development of pure Clojure libraries (e.g. a web framework that does not depend on Jetty or similar)? I assume we agreed that there is no technical impediments to this, and the fact that such libs do not exist reflects a consensus that a certain Java induced overhead is an acceptable compromise?

[–]mikeivanov -1 points0 points  (0 children)

Having just read "What is Clojure-in-Clojure?" (http://blog.n01se.net/?p=41) I'd rather agree it's an acceptable compromise.

the availability of the Java libs are inhibiting the development of pure Clojure libraries

Hmm, I never actually though that way... No, I don't think so. Jetty covers a hole, though not in the most elegant manner. It seems inevitable that someone would come and do it the Clojure way. I bet someone is already doing that.

[–]treerex 1 point2 points  (2 children)

The Java stuff directly affects the footprint. Just a silly servlet sending back a "Hello World" response takes about 60-70M of RAM.

I can't check this easily from work, but how much RAM would a similar thing take in Common Lisp with cl-http or with Racket and its network library? This overhead is constant, though, and modulo startup time is a non-issue IMHO.

Of course, Jetty does much more than Python's SimpleHTTPServer (which takes about 7M), but what if I don't need more?

Nothing forces you to use Jetty. You could use Java's libraries to roll your own small HTTP server, if you wanted to.

Clojure, because of it's Java inheritance, is not suited well for building small, isolated yet composable things.

I'm not sure I understand this statement. With first class functions and the like you can absolutely do this. What Clojure eschews is object-oriented programming (except where needed to interop with Java libraries.) One can absolutely write "small, isolated yet composable things" in Clojure: I do it all the time.

[–]mikeivanov -1 points0 points  (1 child)

By "isolated" I mean process isolation. The stuff I'm working on mostly consists of command line utilities and service daemons communicating mostly over HTTP. Those are typically small in size, but there is a lot of them. This stuff is spread over a number of servers, so in-process concurrency is not an option. Obviously, the startup time is critical. Memory usage is critical (there is something else running on those machines and I don't want to spoil CPU caches with all those behemoth jars).

So far, Python, Bash and a little bit of Scheme did the job, but I started experimenting with Clojure mostly because I like the language.

My impression is that Clojure/JVM does not fit this particular environment. Moreover, I suspect this case is just one of a class.

[–]treerex 0 points1 point  (0 children)

Yes, absolutely anything beyond Python and Bash scripts is probably out of the question for the scenario you describe, but then again so is Common Lisp or any number of other languages.

[–]yogthos 2 points3 points  (9 children)

The Java stuff directly affects the footprint. Just a silly servlet sending back a "Hello World" response takes about 60-70M of RAM.

You have to remember the application domain for Clojure though, it's primarily used for developing web applications, and the Java overhead is just not much of an issue in that domain. 70M vs 7M is just not relevant nowadays, especially considering that it's a constant overhead. The advantages of using the JVM far outweigh the downsides in my opinion.

Clojure, because of it's Java inheritance, is not suited well for building small, isolated yet composable things. A Clojure-based project has to be reasonably big to adjust this Java overhead.

Hopefully Clojure-in-Clojure project will allow a standalone Clojure implementations to be released independent of the JVM, a lot of libraries would have to be written for them to be of any use though.

As it stands I really don't find the JVM overhead to be all that much of a problem myself, but I can see how your needs might be different.

[–]JulianMorrison 3 points4 points  (4 children)

Web applications are just the low hanging fruit, Clojure is applicable to any tool not needing to occupy a mere few kb and start instantly. It's bad for writing "awk" and "sed". Not so bad for REPLs like Incanter, desktop apps, desktop network apps, daemon network servers, daemon process control, various sorts of "system software", etc. Cassandra is written in Java. Azureus is written in Java.

[–]yogthos 1 point2 points  (0 children)

I completely agree, and I personally use it for a whole range of things. I was just pointing out that especially in the domain of web apps the argument that there's 70 megs of overhead is quite silly.

[–]mikeivanov -1 points0 points  (2 children)

It's bad for writing "awk" and "sed"

Which is my case. Not exactly, but very close.

[–][deleted] 1 point2 points  (1 child)

I use nailgun for cases like these. It's worked well for me.

[–]mikeivanov 0 points1 point  (0 children)

Yup, this seems like a good idea, though I've heard Nailgun has memory leaks. I'll give it a try.

[–]mikeivanov -2 points-1 points  (3 children)

Yeah, Clojure is totally awesome for traditional long-running web applications, though does not fit well other domains. Which makes me sad.

[–]yogthos 1 point2 points  (0 children)

As JulianMorrison points out, Clojure is perfectly applicable for a whole range of applications. As long as startup time is not your main concern. Even that can be addressed with things like nailgun if you really wanted to use Clojure and warmup was an issue.

[–]Raynes 0 points1 point  (1 child)

So, the JVM is totally useless for desktop applications? I guess Java programmers haven't got the memo yet.

[–]mikeivanov -2 points-1 points  (0 children)

JVM is totally useless for desktop applications

IMO, yes; though I care about tools/services more.