What is Clojure NOT good for?

[Joshua Fox]

Is it fair to say that Clojure shines in algorithmic processing, string processing, concurrency management, but that there are better choices in other areas:

- "Application" programming , where the key challenge is fitting a standard three-tier application to the business domain.

- "Enterprise" programming, where the challenge is gluing together overweight and fragile libraries, and one should always use exactly the set of software which the API creators envisioned?

Rich himself has suggested something along these lines, but I wonder what others think.

Joshua

[Rich Hickey]

I don't recall suggesting that. I would certainly consider application
programming a prime domain for Clojure. OTOH, if that's the definition
of "enterprise" programming, I'm not sure any language is going to
produce a satisfying result.

Being a Lisp, and having the ability to generate primitive math ops
that map to machine instructions, Clojure can scale high and low. I
wouldn't count it out in many domains just yet, as we're just starting
to see it applied to a wide array of problems. Often its applicability
will just be a matter of libraries and macro packages.

I think it is unlikely to end up with less applicability than Java.
Even what seems like a categoric absence, like static typing, may be
filled with a la carte typing and constraint systems built on logic
programming extensions like the Datalog work.

Of course, I'm biased, but wide applicability is certainly the intent
of Clojure. I'm interested in what others think as well.

Rich

[lprefo...@softaddicts.ca]

"Application" programming is exactly what we do with Clojure,
we are not using it in a bubble, it's there to implement all
the complex logic we need.

We use over 130 jars (Spring,...) and we use them from both Clojure and
some Java components. We are replacing with Clojure code
the Java high level components inherited from our product V1.0.

"Enterprise" programming is restricted to Java APIs however
we share data between Java, Clojure and Ruby transparently
through YAML and messaging.

Cobol/Fortran does not support maps as far as I can remember so
adding Cobol/Fortran components in our product would be a challenge :))))))

If Clojure was another "better" LISP without any access to
Java that would restrict its utility severely.

To us it would not had any sex appeal at all without Java access.
It was a major factor in our decision to use Clojure even
V1.0 is not finalized yet an go live with it.

We needed a fast delivery approach and Clojure allowed us to reuse
Java components with minimal changes while allowing us to code
complex logic much more faster in Clojure.

For us Clojure = less useless code lines = fast delivery
= less test headaches = major success :))))

Luc

[Luke VanderHart]

The biggest barrier to using Clojure in an "enterprise" environment is
that enterprise projects are typically built and maintained by 100s of
replaceable code-monkeys and consultants, all of which understand Java
and almost none of which understand Lisp of any kind, let alone
Clojure.

To be honest, even if I could get away with it, I wouldn't want to
inflict hell on the next person who has to fix something in my Clojure
code. Even if they're a good developer, they are very unlikely to care
about Clojure or functional programming. I heard of one guy in our
company who wrote some web services in Scala on the grounds that they
were one-off services that wouldn't need to be modified - until they
were, and everyone was roundly cursing him for it. They were small
enough that it turned out to be easier to redo them in Java rather
than to learn Scala and understand his code.

Like it or not, enterprise development = Java or .NET until the
language landscape has some radical changes.

[lprefo...@softaddicts.ca]

I agree about "consultants" (these days it's not anymore an synonym for
expert) and the state of the market but...

If you write a new software product and
you are concerned with deadlines and speed in general, Java is not
the way to go anymore considering the pile of code you need to do
anything significant these days. More code = more people = inefficiencies.

I know some business where HR and IT managers come back with this mantra
that they can find Java and .Net coders, anything else is too risky or
too scarce on the market.
It reminds the time when you could not get fired when buying IBM mainframes.

Many HR departments do not understand anything about
software development in general and the profile of individuals needed.
They go for the "standard" available bodies with a single fit all projects
skill set and their batteries of psychological tests.
That explains a lot why productivity is low on most projects.

The landscape will change when HR changes (and managers)...
seeking intelligence and initiative instead of a single static fit.
(looks like StarTrek quest...)

The day they will understand that software development is not
a Taylor assembly line (less the efficiency), the situation will improve.

You cannot get more from people that what you are asking for...

I am not generally optimistic about the state of things in the software
industry but we need to bring in tools that are more accessible to the
masses. Clojure is one if you compared it to CL...

Luc

[Jeffrey Straszheim]

If these theories are correct (and I believe they are) then this is an opportunity to beat the crap out these guys in head-to-head competition.  The Rails guys seem to have successfully broken into industry by being better (relatively compared to Java/VB/C#).  We can do the same thing if we don't wait for others to do it instead.

(I know this sounds like a PG essay, but it is true.)

[Mark H.]

On Mar 6, 7:46 am, Luke VanderHart <luke.vanderh...@gmail.com> wrote:
> The biggest barrier to using Clojure in an "enterprise" environment is
> that enterprise projects are typically built and maintained by 100s of
> replaceable code-monkeys and consultants, all of which understand Java
> and almost none of which understand Lisp of any kind, let alone
> Clojure.

That's why Clojure has JVM interoperability ;-P

Think of Clojure as an embedded higher-level language running within
Java. You can hide it completely with a Java wrapper so that nobody
has to read or write Clojure code but the local Clojure expert(s).

We do this all the time with C and Fortran: we only require our
libraries' users to know C or Fortran, but we embed Lua and ANSI
Common Lisp (via ECL) in our libraries to do harder coding tasks, and
use other scripting languages to generate code. All those other
languages are hidden from the users.

A well-written library treats other programmers on the team as "users"
who don't have to know the internals of the library.

mfh

[Konrad Hinsen]

On Mar 6, 2009, at 14:15, Joshua Fox wrote:

> Is it fair to say that Clojure shines in algorithmic processing,
> string processing, concurrency management, but that there are
> better choices in other areas:

I'd say that Clojure is probably suited for anything that the JVM is
suited for. Its Lisp nature makes it much more flexible than
"ordinary" languages, and there seem to be few limits to what it can
do with the JVM, considering that it is even possible to generate low-
level maths primitives.

As for what JVM languages are not good for in general, there is the
obvious domain of systems-level programming, and there are other
domains such as number crunching, where there is a severe lack of
good libraries in the Java world. Real-time programming tasks may
also be difficult, considering that garbage collection can introduce
a delay at any time, but I am not really competent to talk about this.

Konrad.

[Luke VanderHart]

Oh, I agree with you 100%.

I outlined why I wouldn't use Clojure in a project self-described as
"enterprise", but at risk of ranting I didn't get into how I consider
the word "enterprise" synonymous with "bloated, bureaucracy-bound,
over-engineered, unoriginal and above all /expensive/ ball of tar".

Ironically, "enterprise" has nothing to do with actual size or
significance of the project. I've seen very small projects that are
infected with "enterprise", whereas I don't think there is anything
enterprisy about, say, Google.

-Luke

[.Bill Smith]

My wife and I both write software. She think's I'm insane to use
Clojure because the poor sucker who has to maintain what I've written
will be uncomfortable with anything other than Java. (She may also
think the poor sucker won't want to deal with my dubious programming
skills, but that's another story.)

Sometimes it takes a killer app to kick-start a technology's
popularity. Other times, a new technology establishes its beachhead
in an area that no one cares about and then migrates into more
glamorous and mission-critical places. I think a beachhead for
Clojure could be automated testing for Java code. Having spent a few
years writing automated tests, I don't believe Java is the best
language for testing Java applications. That may sound bizarre or
unintuitive, and I was skeptical the first time someone suggested the
idea to me, but Java's syntactic constraints can make it cumbersome to
write test code.

Bill

[lprefo...@softaddicts.ca]

Usually if has mustaches, 4 legs, oval shaped eyes, fur and
makes prrrr ! prrr ! when I touch it, I call it a cat :)))

Most of my customers are accustomed to my crude language.
Since they have results when they deal with me compared to what
they get internally and from other suppliers, they forgive me :)))

This "enterprise" mindset translates most of the time into
bureaucracy at the expense of results.

It's understandable, delivering significant work (real stuff that runs
and helps the business) is harder to create than say, heating a chair with
your b... or calling endless meetings to discuss the latest
buzzword on the market that "should be the next killer tool" :))))

Crude ? Me ? No... just tired of putting my hands down to the shoulders
in the mud left by others :)))


Luc

[Phil Hagelberg]

Konrad Hinsen <konrad...@laposte.net> writes:

> As for what JVM languages are not good for in general, there is the
> obvious domain of systems-level programming, and there are other
> domains such as number crunching, where there is a severe lack of
> good libraries in the Java world.

The only other thing I can think of is short-lived command-line tools
that need subsecond launch times.

-Phil

[Meikel Brandmeyer]

Hi,

Am 06.03.2009 um 19:21 schrieb Phil Hagelberg:

> The only other thing I can think of is short-lived command-line tools
> that need subsecond launch times.

Even this can be addressed via Nailgun as I use
it now for dynamic VimClojure (aka Gorilla). A
server runs in the background and invoking the
cli tool just talks to the server, taking care of startup
times. Not perfect, but for certain uses (eg. making
Clojure with Vim more fun) it is sufficient. :)

Sincerely
Meikel

[Dimiter "malkia" Stanev]

Clojure is not good for:
- Real time application development, due to the JVM being soft-real
time. For example it can't be used for high-performance video pc/
console games, but it could be used for lots of turn-based games. Then
again anything done with XNA on the XBOX could be done with Clojure :)
(XNA is some form of Compact .NET for the XBOX).
- Writing small utility programs, as it requires certain things to
be installed properly (For example using "java -serever" with the
correct JVM). For example I can't see myself deploying small utility
application at work written with Clojure, as it would make people
screaming, why they have to install this and that. That won't be the
case with big and important application (noone would mind the hidden
JVM that I might put along with it).

[Eric]

> - Writing small utility programs, as it requires certain things to
> be installed properly (For example using "java -serever" with the
> correct JVM). For example I can't see myself deploying small utility
> application at work written with Clojure, as it would make people
> screaming, why they have to install this and that. That won't be the
> case with big and important application (noone would mind the hidden
> JVM that I might put along with it).

Couldn't clojure compiled binaries be put into an executable (self-
contained) jar file?

[Luc Prefontaine]

Real time is a special application domain. I am not sure that most people want to work
in this domain (I did for several years with VMS and a power utility).

As for start up time  for small utility commands I disagree, this is something that
could change if we start to use the hardware a bit more wisely one day.

I work with Ubuntu and all my frequently used tools are copied to RAM (/tmpfs) at
boot time. My Java environment is there, Clojure, Eclipse, frequently used librairies...
On top of that there's a daemon running to spot my frequently accessed files and serve
them from RAM transparently.

It takes me less than 1.3 secs to get the REPL prompt.

Combine that with the approach of having a Clojure server in the background and that's it.
Server is not there ? It gets started automatically in less than 2 sec. and runs your stuff,
it's already started ? Well, it runs your commands immediately.

Ok, I have 6 gigs of RAM and a quad core (Q6600) and disk mirroring but I cannot consume
more than 60% of the RAM and 10% of the swap space.

I run Oracle server, ActiveMq, Terracotta2, two copies of Eclipse most of the time and
our application services on my desktop concurrently.
As to how I can get this machine down on it's knees begging me to stop, well I did not find a way
in my day to day work yet.

With a dual core and 3gig of RAM at entry level prices, there are no excuses to have a slow
environment. You just have to figure a nice way to use the power at your disposal.

I am always ashamed when I see the kind of desktops developers get from their employers.
I saw many sites where developers have desktops not more powerful than the average office user.
That's poor planning. The time spent waiting by the developer after the hardware is a significant
hidden cost but it seems that no manager wants to tackle this issue and defend a wiser
buying strategy to get power where it's needed... no top executive needs a quad core desktop
with tons of RAM.

On one project just by changing to this Ferrari, I shrank the build->restart-application->ready to test
cycle from 90 seconds to 8.

When I started to code, computers were less powerful than the standard pocket calculator but
we were doing a lot my designing accordingly. It's far more easier today given the amount
of resources we have....

Luc

-- Luc Préfontaine Off.:(514) 993-0320 Fax.:(514) 993-0325 Armageddon was yesterday, today we have a real problem...

[Phil Hagelberg]

Luc Prefontaine <lprefo...@softaddicts.ca> writes:

> I work with Ubuntu and all my frequently used tools are copied to RAM (/tmpfs) at
> boot time. My Java environment is there, Clojure, Eclipse, frequently used librairies...
> On top of that there's a daemon running to spot my frequently accessed files and serve
> them from RAM transparently.
>
> It takes me less than 1.3 secs to get the REPL prompt.

That's great for a REPL, but if it took me that long to get (for
example) "git diff" to return, it would be *really* annoying.

If it's a tool you use occasionally, keeping a server running all the
time may not be an wise solution.

-Phil

[Luc Prefontaine]

Excuse my ignorance but these expressions "occasionally" and "not wise"
together are just opaque to me.

If my desktop was crawling because of the load, I might understand the goal
of manually managing services but it's not the case at all.
Services not used are simply swapped if the system needs  physical memory. Here it's obviously not the case...

Can you be more precise about your thoughts ? Personally I consider my time invaluable,
starting/stopping services on demand is not a good use of my time. Hardware does not
resent fatigue and is much more powerful these days so why not ask it to save us time and pain ?

BTW our internal git repositories (hosted on an XServer) respond pretty fast on our gigabit LAN :)))
but not as fast a starting a REPL :)))

Luc

-- Luc Préfontaine Off.:(514) 993-0320

[Stuart Sierra]

On Mar 6, 9:47 am, lprefonta...@softaddicts.ca wrote:
> For us Clojure = less useless code lines = fast delivery
> = less test headaches = major success :))))

I agree 100%, although I have the unusual advantage of working alone.
The succinctness of Lisp with Java's library support is a perfect
combination.

-Stuart Sierra

[Jay Fields]

I've lived through this discussion for the past 3 years while writing web applications using Ruby and Rails. Here's what I've learned:

- Using a language that the average stupid programmer can't understand virtually guarantees that you'll increase your success chances, since you and your team-mates will be of a higher caliber.
- The world is always going to tell you that using Clojure is a bad idea.
- If you think using Clojure is a good idea and you and your team are excited about using Clojure, it's probably a good idea.
- If you think using Clojure is great for your application, but bad for your company, look for a new company.
- You aren't going to find a job in your favorite city using your favorite language in your favorite domain. Decide what you value the most and go from there.
- Don't hire consultants when using bleeding edge technology.

I could probably go on for hours. The bottom line is, it's entirely contextual, and you're smart enough to look at Clojure, so make the smart choice on whether it's right for your situation.

Cheers, Jay

[bOR_]

I'm not from the software engineers field, but how difficult is it for
some non-lisp, but java-savvy software writer to pick up a 600-line
clojure program and learn to understand it? I mean, everyone in this
forum managed to learn clojure to some degree without too much
trouble.. including me. If there is a function the poor software
engineer doesn't know about, there is excellent documentation
available (unlike, for example for K, where your documentation is the
source code in Q), there's this google group, and there is irc.

I am a scientist, and I seem to manage fine. Someone who programs for
a living should be able to fix a program that is broken in whatever
language relatively easy.

[Phil Hagelberg]

bOR_ <boris....@gmail.com> writes:

> I'm not from the software engineers field, but how difficult is it for
> some non-lisp, but java-savvy software writer to pick up a 600-line
> clojure program and learn to understand it?

I suspect it has more to do with people thinking they can't do it than
any actual lack of ability to comprehend. Many people are intimidated by
new ideas and think to themselves, "I'm a Java programmer. I shouldn't
have to learn a new language." Other people would see it as an
opportunity rather than a burden, even if they are otherwise both
equally capable programmers, the second person will be able to pull it
off. But unfortunately this kind of person is much rarer.

> I mean, everyone in this forum managed to learn clojure to some degree
> without too much trouble.. including me.

Membership to this group is _very_ self-selecting; you can't expect
things that are true here to be true across the board.

-Phil

[Jeffrey Straszheim]

Well, there is no real replacement for raw intelligence, but I hope we'll all agree that attitude and curiosity are also critical.

[Dan]

> Membership to this group is _very_ self-selecting; you can't expect
> things that are true here to be true across the board.
>
> -Phil

I expect membership will increase once Stu's book is released. It will
give people a much more structured way to get familiar with the
language.

[Christian Vest Hansen]

On Tue, Mar 10, 2009 at 12:17 AM, bOR_ <boris....@gmail.com> wrote:
>
> I'm not from the software engineers field, but how difficult is it for
> some non-lisp, but java-savvy software writer to pick up a 600-line
> clojure program and learn to understand it?

I think the majority of Java programmers will be able to pull that
off, but it will take a good deal longer than the equivalent 2000-line
Java program.

Also, how do you think this increase in required effort grows? What if
we are talking about a +10.000-line Clojure program? Now add schedule
pressure, deadlines and the cost of missed oppotunities and you will
find that many companies sees the introduction of a new programming
language - especially if it is uncontrolled or happens without their
knowledge - as a significant risk.

> I mean, everyone in this
> forum managed to learn clojure to some degree without too much
> trouble.. including me. If there is a function the poor software
> engineer doesn't know about, there is excellent documentation
> available (unlike, for example for K, where your documentation is the
> source code in Q), there's this google group, and there is irc.
>
> I am a scientist, and I seem to manage fine. Someone who programs for
> a living should be able to fix a program that is broken in whatever
> language relatively easy.

"Relative" as in opposed to someone who does not program at all? ;)

You may find it hard to pursuade an off-the-street VB hacker to fix
bugs in your K code :)

>
> On Mar 9, 6:08 pm, Jay Fields <j...@jayfields.com> wrote:
>> I've lived through this discussion for the past 3 years while writing web
>> applications using Ruby and Rails. Here's what I've learned:
>>
>> - Using a language that the average stupid programmer can't understand
>> virtually guarantees that you'll increase your success chances, since you
>> and your team-mates will be of a higher caliber.
>
> >
>

--
Venlig hilsen / Kind regards,
Christian Vest Hansen.

[bOR_]

> Also, how do you think this increase in required effort grows? What if
> we are talking about a +10.000-line Clojure program? Now add schedule
> pressure, deadlines and the cost of missed oppotunities and you will
> find that many companies sees the introduction of a new programming
> language - especially if it is uncontrolled or happens without their
> knowledge - as a significant risk.
>

Haven't written anything larger in clojure than 600 lines yet, and I'm
tempted to clean that one
up to reduce it back to 400'ish. Isn't 10.000 lines in a clojure
program an indication that something
is going wrong and you might need to look for a better way of solving
your problem?

K is a disaster :), but I just looked at it as something fun to toy
with.. not much unlike a new computer game or something.

[e]

- You aren't going to find a job in your favorite city using your favorite language in your favorite domain. Decide what you value the most and go from there.

 

nice post!  but only the cities and domains are fairly well enumerated.  I guess 2 out of 3 ain't bad.

[Luc Prefontaine]

That's the whole idea, if your current "coding" habits are not efficient well
changing them involves taking a risk... otherwise everyone would do it.

Humans have a tendency to stay within their comfort zone. Stretching
that bubble takes time. No change however = stagnation and eventually
obsolescence.

I have never believed in the single hammer approach to all problems
in a single project. However most customer projects I dealt with had this
disease, the main reason being that was the "comfort" zone issue showing up
in most of the technical decisions taken in the project.

The day managers will stop looking at their developer's skills
as something fixed and "immutable", projects will deliver with
better quality and faster because there will be a choice of tools available
for different parts of the same project and more flexibility resource wise.

When my shop was working solely on custom components for our customers,
I used to change people from one project to other according to the
workload state at a couple of hours notice. New project, new technology...

It's like moving a plant from one spot to a different one.
It might be hard at first but at some point the plant gets stronger.

This approach beats the hell out of people at first but as they are moved from one
project to the other they see the light. They understand how to adapt and shift
because of the constraints (time line, learning curve, ....)

One big advantage of my employees versus plants: they were able to speak when
they did needed some guidance. I must say that what I did was not a benefit for most
that left for other companies since we stopped the custom software business.

They found most of the time that their liberty was severely restricted in their new job
compared to what they could do in my shop...

Today, we can choose the appropriate technology for the task to do since we
are now working on our own products. Our approach has not changed except that
we have greater latitude in what we decide to use (and of course greater potential to hang ourselves).

Luc

On Tue, 2009-03-10 at 09:53 +0100, Christian Vest Hansen wrote:

Also, how do you think this increase in required effort grows? What if
we are talking about a +10.000-line Clojure program? Now add schedule
pressure, deadlines and the cost of missed oppotunities and you will
find that many companies sees the introduction of a new programming
language - especially if it is uncontrolled or happens without their
knowledge - as a significant risk.

[Howard Lewis Ship]

I ran into a bit of the "but we can hire Java coders" mentality when I
presented Clojure at a local JUG.

Due to time constraints, I didn't get into it at the time, but my
basic thought is:

"I don't care what you know, I care what you can learn!"

Also, there's the myth of the "immediately productive programmer",
i.e., I can hire this guy and he'll be productive because
he already knows Java and Struts (for example):

Faults with this reasoning:
- Nobody is productive on day 1, few in week 1
- Your internal processes, code libraries, version control, etc. will
get in the way as much as coding language
- I might be productive with a hammer, but that won't help me fix this watch!
- If you hire someone with limited initiative/ambition, don't be
surprised if they're contribution is not stellar
- Why set the stage in terms of the *lowest* level of contribution?

--
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

[Stuart Sierra]

Ok, here's a real one: if you need to use a lot of C/C++ libraries,
for which there are no Java replacements, Clojure won't be much fun,
because C/C++ interop with Java is not fun. You'll probably be
happier with a Lisp/Scheme implementation that compiles to C; several
such languages exist.

-Stuart Sierra

[Korny Sietsma]

Agreed.
An interesting parallel is getting Java developers to use Javascript
well - sure, anyone can look at javascript code and probably work it
out - it's a much smaller jump to javascript syntax than clojure
syntax.

But even so, I know lots of Java coders who never really "get"
javascript stuff like prototypes, meta-programming, and the like. They
hack out procedural code in javascript when they have to, but never
come to terms with things like proper unit testing, oo design, or the
like, because it is (a) different, and (b) doesn't interest them. It
doesn't help of course that javascript, despite being a good basic
language in many ways, has a lot of "broken windows" - ugly browser
issues or language problems that discourage people from learning more.

The places I see clojure getting traction in larger workplaces is
where it might provide solutions that are hard to do with other
languages - i.e., mostly stuff to do with concurrency and performance.
It'd be interesting (say) to write something like Kestrel (formerly
Starling), Twitter's message queueing system - this used to be Ruby,
got ported to Scala - I'm sure it'd be a good candidate for clojure.

- Korny

--
Kornelis Sietsma korny at my surname dot com
kornys on gmail, twitter, facebook, etc.
"Every jumbled pile of person has a thinking part
that wonders what the part that isn't thinking
isn't thinking of"

[e]

this could make it survivable: http://nestedvm.ibex.org/

also, there used to be something called "NoodleGlue", but maybe it was so good, it is no longer open source . . . .or maybe it just died.  Anyone know?

[Jason Warner]

This is almost exactly my experience in PHX at our user groups.
Unfortunately I am also trying to hire people and I find the people
here have no interest in learning something new because they "already
know java" (at least the ones I've seen on interviews).

[Colin Walters]

On Mar 11, 11:11 pm, e <evier...@gmail.com> wrote:
> On Wed, Mar 11, 2009 at 6:28 PM, Stuart Sierra

> <the.stuart.sie...@gmail.com>wrote:

>
>
>
> > Ok, here's a real one: if you need to use a lot of C/C++ libraries,
> > for which there are no Java replacements, Clojure won't be much fun,
> > because C/C++ interop with Java is not fun.  You'll probably be
> > happier with a Lisp/Scheme implementation that compiles to C; several
> > such languages exist.
>
> this could make it survivable:http://nestedvm.ibex.org/

Ahhh...nestedvm is not going to be a good idea for most of the cases
that come up when discussing C/C++ integration. There's:

* JNA: https://jna.dev.java.net/
* gluegen: https://gluegen.dev.java.net/

Those are the two that I have some experience with, but I'm sure there
are more. It's definitely an area that could be a lot better, but
tools do exist.

[knubee]

> Is it fair to say that Clojure shines in algorithmic processing, string
> processing, concurrency management, but that there are better choices in
> other areas:

not an answer, but a follow-on question: how well does clojure
currently support multimedia programming? i realize it supports it to
the extent that java does, but i am curious about the existence or
plans for clojure libraries for graphics, animations, audio, gui
widgets, etc.

i see there is a clojure wrapper for the processing language, but a)
that means an additional layer between clojure and java, and b) the
library examples suggest that there is still some amount of directly
invoking java (rather than having clojure-level procedures).

[opus111]

Here's my experience...

I was primarily interested in Clojure as a scripting language. I
wanted a nice layer to control code written in Java. I had used
Groovy successfully, but missed macros and an extensible syntax. I
used to work at Lisp Machines, so I jumped on a LISP that compiled to
the JVM.

Unfortunately, while I love Clojure for algorithms and stretching my
brain, it is not very good for scripting. This is because it is
really too different from Java. Clojure programming requires that you
do things the "Clojure way". Therefore, a Clojure wrapper does not
map very well to a set of Java objects; calling Clojure from Java is
clunky; and debugging lazy code that invokes Java is difficult.
Clojure is best when everything is written in Clojure.

Some day Clojure programs will be able to take advantage of parallel
hardware. Then there will be a performance reason to write core
algorithms in Clojure. Unfortunately Java is still significantly
faster this year.

So for me, Clojure is beautiful, coding is a joy, and Clojure is the
future... but I can not use it for work yet.

Peter

[e]

not knowing much about it, what role could ANT play to satisfy your scripting needs.  it seems like it could be a good way to glue together bits of code ... but maybe that way too high level ... like on the level of batch files in dos.
 

[André Thieme]

On 6 Mrz., 17:07, lprefonta...@softaddicts.ca wrote:

> I know some business where HR and IT managers come back with this mantra
> that they can find Java and .Net coders, anything else is too risky or
> too scarce on the market.

Right. I am sure a lot of those managers really think that way.
If they go the Java route, then it will be no problem to hire
more developers.

They just overlook that when they write their programs in Lisp,
then they won’t need as many devs.
I don’t want to go into numbers, as it depends on the specific
requirements. But in general it is true that a good bunch less
developers can do with Lisp what more programmers can do with
Java.

> Many HR departments do not understand anything about
> software development in general and the profile of individuals needed.

It’s always good to have a Lisper as the head of the
software department.

[André Thieme]

On 6 Mrz., 19:21, Phil Hagelberg <p...@hagelb.org> wrote:

> The only other thing I can think of is short-lived command-line tools
> that need subsecond launch times.

The Lisp repl is the command-line. There is no starting time
of the JVM involved.

[knubee]

i really am curious about how good clojure can be as a language for
prototyping new *languages* (and new paradigms). this has always been
a strength of lisp and scheme, but they both support imperative as
well as functional programming. as an example: how easy would it be to
implement a language like Processing in clojure?

i am not saying it is impossible (or even hard). i just honestly do
not know. and would be very helpful to hear what others think.