Re: Road to Clojure Survey

Pascal Costanza schrieb:
André Thieme wrote:

You don't need a "huge number" of libs. You need good libs.

In the CL world I find a tiny number of good libs.
In that regard CL has (for things I do) no chance against that what
Java/Clojure offers.


Libs are what boosts productivity more than anything else.

Not for the kinds of things I am interested in. I am several orders of magnitude more productive with Lisp than with Java for the kinds of things I am interested in. It all depends on context.

Yes, I agree.
If you talk about the core language CL vs Java, then it is easy for me
to believe that your productivity with CL is better.
Again, depending on what you do this experience could be worse with
Clojure (if you are doing mostly OOP), or better (if you want to do
functional programming).


+ Much more independend from the hardware it runs on. In a few years
people will want to run more and more apps on their mobile phones,
which will soon (some years) be as powerful as PCs were 3 years ago.

This can also be a disadvantage, for example if you want to make most out of the hardware resources at hand.

Yes, so this is one disadvantage of chosing the JVM as the target
plattform for Clojure.
But would a CL VM have been better for that? I don’t think so.
So, if the comparison is: Clojure for a CL VM vs the JVM, then I can not
count this as a disadvantage.


+ Less often recompilation is needed, or OS specific versions.

That's a myth, only true for vertical applications. But in reality, you need to recompile for each platform because of fine-grained adaptations, which are always necessary.

As we can see I said „Less often” recompilation is needed.
When an application reaches a certain level of complexity recompilation
and fine-grained adoptions may be needed.
I still see this point as an advantage. Enough non-complex programs need
no recompilation. For CL however it is likely that even the most trivial
programs require it.


+ Team members can much more likely use the OS of their choice.
Currently our CL product runs on Windows only (Lispworks Pro).
All devs use Windows. When we ported all our code to Clojure, then
the devs are free to decide if they wish to develop under Linux,
OSX or Windows. Even during the process of porting they can do it.
We just won’t allow mobile phones for development right now ;)

Huh?!? That's true for CL as well, of course!

No, we are not so free in choice. If our CL were SBCL for example, then
it would not make sense to try it under Windows. Not for serious development.
Lispworks or Allegro would be possible, if we were ready to buy these
specific licenses. Again another cost factor which is not good for
startups.
And if you say „true for CL” in such a general way, then one could think
that some team members could use Corman CL, others use clisp on OSX
while the next works with CMUCL under Ubuntu.


+ Greater set of tools. In c.l.l we basically suggest everyone to use
Emacs+Slime. I use this currently for Clojure development as well,
but I try NetBeans+Enclojure more and more often.
When Clojure gains more popularity I can imagine that plugins for
IDEA and Eclipse will show up. There are several different kinds
of tools to monitor the JVM. A profiler developed for clisp does
not necessarily work together with Allegro CL.

Neither does a profiler for Sun's JVM work with the Kaffe Virtual Machine, for example.

Yes, and nobody uses Kaffe.
No, I don’t mean this literally, but basically all installations are
either the official Sun JRE/JDK or OpenJDK.
The CL world is way more splitted up. Each CL needs their own profiler,
and they are not compatible with each other.


For example, reflection and metaprogramming capabilities are very restricted in Java. However, it is very common that, as soon as you grow your programs, you want to have some domain-specific means to express your solutions. Because of the limitations with regard to metaprogramming, Java solutions tend to end up in using a combination of design patterns and/or XML processing to achieve the same results. But note that XML processing is essentially building an interpreter, which at this level is inherently slower than using, for example, a DSL based on macros.

This may all be true for Java. But that still does not make the JVM a
worse target for Clojure.


The JVM (not only Java) is restricted to single dispatch and single inheritance. This leads to ugly workarounds like using visitor patterns and observer patterns all over the place, which again has an impact on code size and overall performance.

Also not interesting for a functional programming language, which leads
OOP behind, that now had 20 years to prove that it is the superior model
to write applications in. It’s nice for writing GUI frameworks.
We will now see if functional programming can do better. I think so, but
I am also curious to see what really will happen.


You may object that Clojure provides a clean slate and allows you to do better in some regards. However, by basing Clojure on top of the JVM, you essentially buy into the whole eco system. (Remember? You want to use all those huge amounts of existing libraries, right?)

Okay, so this is the first real disadvantage: it’s possible that the lib
I want to use is doing stupid things under the hood and that will also
slow down my application.
Though I still think it is better to have a not so performant lib than
having no lib at all :)


+ Easier and higher level low-level optimizations. When the profiler
tells us where the bottleneck is we can rewrite tiny parts of the
application in Java code. Java is much more high level than C, and
it is trivial to integrate code written in Java into Clojure apps.
No strange FFIs are needed for that.

They are typically also not needed for Common Lisp (or other Lisp dialects).

Still no argument against the VM.
Lisps run often fast enough. This is true for CLs and also for Clojure.


+ Way better chances to get a Lisp job.
I had to change the city I live in two times to get a CL job. One
time I even left Germany. Java companies however are present in
basically every city. 80 times.
Some smaller of those will accept a Clojure programmer. They will
trade that other devs in that company can’t understand the sources
for an increase in productivity. This btw does not contradict my
statement in a different post, where I doubted the 5x-20x boost in
productivity that Lisp brings. If it were Lisp vs Java only on the
language expressivity level, then these numbers may be reality.
Because Clojure has the same access to all libs that Java also has,
those libs will not be an advantage for Java. Note: I don’t say that
all Java companies will or should accept Clojure programmers. But
I know for sure that some will do. That means that it is now realistic
that thousands and thousands of Lispers can get a job where they
can use their favourite programming language: Clojure.

Unfortunately, that's not true. Many (most?) companies that require Java do not require it because it's such a "damn good" language, which it isn't, but only because it is an industry-accepted standard. Clojure is not an industry-accepted standard, so you will get the same acceptability problems as with any other "non-standard" language.

No, I must disagree. I know for sure such cases.
I restricted what I said to smaller companies. Some start ups, or
companies that only have 1-4 programmers will listen to you.
Of course, you can not walk in to Oracle, promise them 2x higher
productivity and next day get your Clojure job.
But when it is about smaller teams you can talk with them, you can
negotiate something. Some will listen. A tiny fraction out of a huge
number still has some value.
But telling them that you want to program in CL instead closes the
doors immediately.
Only because you did not experience such a situation (which is not
strange because you did not even work with Clojure, let alone trying
to get a Clojure job), you can not say that my statement is not true.


+ Better documentation. The ones from Edi Weitz are great. Franz has
really good material online for their libs. When I worked in my
previous CL company (with Allegro Enterprise) I always enjoyed to
read their well written docs.
But that’s not the standard. For stuff that runs on the JVM I find
vastly more and better documented software.

...which is much harder to use because of the poor abstraction capabilities of the Java language.

Uh, I probably did not work with the software that you tried.
Can you please list 3-5 libs that you used, and that suffered from the
abstraction capabilities of the Java language, and which are way easier
to use in CL?
And btw, I was talking about the documentation.
I just tried some random libs from cliki. I just clicked on some of the
links and checked what I can find.
Under http://www.cliki.net/RIPEMD-160 I clicked on http://kopkillah.com/software/
Okay, 403 error.
Tried http://www.cliki.net/CXML and did not find it obvious where the
documentation is.
I tried UncommenXML at http://alpha.onshored.com/lisp-software/
No webserver running there.
XMLisp at http://www.agentsheets.com/lisp/XMLisp/ lists some code. That
is the documentation. At least Alexander seems to be actively working
on this, last update from December 2008. I don’t know how many users
this lib has. Maybe 12.
http://code.google.com/p/cl-smugmug/ had its last updates some time in
2007. Let’s be nice and call this software stable. No downloads offered.
No wiki, no updates, nothing.



+ Greater coverage of clients. If you are a Linux guy and wrote this
cool app with SBCL you can’t sell it as easily to a Microsoft
customer. One can buy a commercial CL and port some parts... but
this adds to your costs. And if that customer likes to run it on
Android then...

It's also not that easy with Java, except for vertical applications.

I did not say complete coverage. It’s greater.
Another advantage.



These are 10 of the advantages that the JVM has and which came to my
mind right now.
I am curious to see the list of disadvantages, which, according to
you „outweigh its advantages by far” (scrolling up in this posting
brings up exactly what you wrote).
Can you list some? I am seriously interested in knowing it.

I have listed some above. I could go on, but I find this boring.

You listed mostly what you don’t like about Java.
I did not find the list I hoped for. I really thought I could learn
about some disadvantages here, and I would like to know them.
You brought up one valid point: some libs can slow down my application,
because the authors made it slow.
Against that I put that today the JVM outperforms easily all CLs for
most applications. And great improvements are currently being worked
on.
In the CL world maybe 20 people world wide are trying to improve CLs
performance. Perhaps 2 at Lispworks, maybe 3 guys at Franz. Sam works
on clisp I guess, Corman Lisp is dead. Don’t know how many devs OpenMCL
has (I think now called Clozure CL). SBCL probably has the biggest
number of devs, but all doing it as a hobby.
Sun puts some more money in. CL has not the slightest chance in that
regard, not with that amount of manpower and money.
All the decades did not help. Java catched up within just a few years
and now outperforms CL.


Java has (had) some very good points in favor: It made a different optimization model (JIT and HotSpot) acceptable in practice; it made garbage collection acceptable in practice (possibly the most important step forward); and it made certain forms of reflection and metaprogramming acceptable in practice (but to a lesser extent).

Hmm I see. Well, that is probably interesting for people interested in
language theory and history.


Java is currently still relevant in industry, yes. But it's legacy technology, which is starting to fall apart. It's too complex and too bloated, and needs to be replaced with something better.

http://java.sys-con.com/node/331264

Yes, evolution is happening. If the JVM is not fit enough in todays
environment others will eat its ressources. But still possible that
the JVM got enough momentum to survive another 10-40 years.
We will see.
What I found interesting in that article was:
"So Java has been around for 10 years and applets are not the primary way that we interact with the web. I think the main reason for this is the installation problem, another area of Java that wasn’t well thought-out. In fact, why do we like AJAX?

It’s clearly not because JavaScript is so easy to work with — JavaScript cross-platform problems are the reason people have avoided it in the past. AJAX is popular because we know that the necessary software for the client side is already installed. "
^^^^^^^^^^^^^^^^^
Sounds very true for me.
It is easier when a system already includes batteries.
All these arguments that CL in principle could implement all Clojure
goodies falls into that category. It would not help. People don’t want
to have complex installations. Clojure ships with all the nice stuff
already today. Greatly tested, accepted, documented. It was the next
logical step for Lisp.


André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
.

Quantcast