
Thoughts on Clojure - fogus
http://programmingzen.com/2010/07/09/thoughts-on-clojure/
======
francoisdevlin
For the inevitable "Where do I start" questions, read this previous comment:

<http://news.ycombinator.com/item?id=1033503>

~~~
twism
... and an example of web development in Clojure:

[http://mmcgrana.github.com/2010/03/clojure-web-
development-r...](http://mmcgrana.github.com/2010/03/clojure-web-development-
ring.html)

Just install leiningen, whip out your favorite text editor, and you don't have
to worry about downloading/installing clojure, libraries and deps.

~~~
dpritchett
... provided you have java installed.

~~~
swannodette
... which is likely if you use an Apple laptop and trivial if you don't

~~~
dpritchett
When I first started out with Clojure on Ubuntu I honestly had no idea which
packages to start out with. It's not a huge deal and I was able to get it
right through trial and error but it's one more step where a potential user
could get lost.

I wouldn't mind contributing to some official getting started documentation if
that was possible. Seeing an HN comment as the go-to source for getting
started upthread disappointed me.

~~~
hga
Sorry to disappoint.

What you're asking wasn't the intended scope of my comment, but it is covered
by the 4th item: <http://en.wikibooks.org/wiki/Clojure_Programming>,
specifically:
[http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Sta...](http://en.wikibooks.org/wiki/Clojure_Programming/Getting_Started)

To a great extent the previous items are intended to convince you to give
Clojure a try/orient you before you start typing in a REPL.

Learning a functional language is not necessarily hard but many people say
it's harder than programmers who are experienced in imperative programming
expect. The latter are used to picking up new imperative languages and the
change to the functional paradigm is not as easy. On the other hand, the more
scars they have from side effect induced bugs the more they appreciate it.

------
aphyr
I really want to get into Clojure, but everything I've read suggests that I'll
have to learn Emacs to do it. Does anyone think giving up Vim for a few months
is worth it?

~~~
TallGuyShort
I still use exclusively Vim for all my clojure coding. I have Vim in one
window (with VimClojure for syntax highlighting and some other features), a
REPL in another (for quick experimenting), and my ant script in another for
compiling and testing the whole thing. It's not as integrated as SLIME and
emacs, but I don't feel like my tools are slowing me down significantly.

~~~
jgracin
With Emacs(w/paredit)+SLIME you would be doing "interactive development" which
is really a fundamentally different and better way of using Lisp. I cannot
recommend it enough.

------
d0m
In the middle of the article, the author talks about three advantages that
clojure has over ruby. Simply put, speed, easy concurrence and functional.

I don't find these to be really good advantages.. First, "functional" isn't an
advantage.. I mean, the advantage of functional code might be easier
maintenance, concise code, easier to concurrence etc.. but "functional" isn't
an advantage. It's like saying C++ is better than ruby because it is
imperative or OO.. "Why is imperative or OO better?", that's the interesting
part.

In my opinion, the advantage of clojure by comparing it with Ruby are:

\- You get the best of Java (lots of library, OO) \- You get the best of Lisp
(macro, high level function)

~~~
funcall
For a certain (large) class of programs, being "functional" is an advantage.
Interestingly, you made the point that being functional means easier
maintenance etc., but fail to attribute those advantages to being functional.
If your argument is that there can be bad functional code which performs worse
than non-functional (imperative or OO) code, I don't disagree. However, in the
multicore future that our semiconductor overlords have in store for us,
functional programming has a demonstrable advantage in helping build
understandable and robust programs.

~~~
cageface
From an interview with the father of Haskell:

[http://www.infoq.com/interviews/armstrong-peyton-jones-
erlan...](http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-
haskell)

 _But it turned out to be very hard to turn that into actual wall clock
speedups on processes, leaving aside all issues of robustness or that kind of
stuff, because if you do that style of concurrency you get lots of very tiny
fine-grained processes and you get no locality and you get very difficult
scheduling problems. The overheads overwhelm the benefits, in short._

It may be true that FP does make concurrency easier, but I don't think this
has been demonstrated to be generally true yet and it's certainly not as
simple as just eliminating side effects from your code.

~~~
lukev
While true, this is somewhat disingenuous. When people speak of concurrency in
functional languages, they don't mean that each function executes in its own
thread (even if it _can_ , according to the semantics of the language). As
this quote points out, the overhead of that is absurd, though maybe we'll get
there someday with specialized hardware.

What functional programming _does_ mean right now is that it's much easier to
chop your program up into reasonable-sized chunks: big enough that it's worth
the overhead, small enough that you can distribute as widely as possible.

In other words, if you think of a functional program as a tree and then expect
to run each leaf in its own thread, the overhead will vastly outweigh the
benefits. But the functional semantics also allow you to run each of the dozen
main branches in separate threads with little effort.

I do this in Clojure all the time.

~~~
cageface
Sure but this is also what you generally do in an imperative threaded app.
Break the work up into discrete jobs and use a producer/consumer model to
parallelize it. This has to be done carefully and usually requires an intimate
understanding of the flow of the computation. It _might_ be easier to do this
in a functional language but their advantages tend to be mostly at the micro
level and the hard stuff tends to be at the macro level.

I honestly think that the advantages of FP for concurrency will turn out to be
relatively minor and that FP is more interesting as a means of improving code
reuse and reducing bug counts. I'm not convinced that the current crop of FP
languages are a win in those respects either though, taken as a whole.

~~~
lukev
Well, yeah. There's no silver bullet. But it's much easier to start lopping
off branches from the tree if there are no unmanaged side effects.

Programming languages of the future need to enforce thread safety and mutation
semantics as well as they do type safety. Functional programming is a step in
that direction.

Nobody's necessarily claiming that a concurrent Clojure/Erlang/Haskell app is
_faster_ than concurrent C++/Java one, but they're definitely safer and easier
to write.

~~~
cageface
I wonder if the kind of concurrency people have been focused on in these kinds
of conversations is really going to turn out to be that important. It seems to
me like a lot of the really cpu-intensive problems people are trying to solve
are way beyond the scale of a single machine - the kinds of problems you need
a big hadoop-style farm to tackle. How many apps are there left that really
need maximum throughput in a shared memory architecture?

------
fbcocq
If it gets added to SPOJ (<https://www.spoj.pl/>) I'll give it another shot.
The JVM is just a frustrating platform when it comes to experimenting with new
languages.

