
Getting started with Clojure - ColinWright
http://aheusingfeld.github.io/2013/08/06/getting-started-with-clojure.html
======
StevePerkins
I wish the Clojure guys would come up with some clear and direct messaging
around its license. When I started exploring Clojure one weekend a few months
back, I found that it's the only _language_ I've ever seen that uses the
Eclipse Public License. In turn, the EPL is the only license I've ever seen
where the FAQ is even more ambiguous and confusing than the license text
itself!

I did some sniffing around to see what the practical effects (if any) are for
applications written in Clojure, and on their own mailing list the topic is a
bit of a mess:

[https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8](https://groups.google.com/forum/#!topic/clojure/bpnKr88rvt8)
[https://groups.google.com/forum/#!topic/clojure/mGf_SuHsSGc](https://groups.google.com/forum/#!topic/clojure/mGf_SuHsSGc)

Everyone seems to agree that forking or modifying Clojure _itself_ would
trigger all sorts of license requirements (e.g. GPL-incompatibility, you might
need to use the EPL, etc).

However, nobody on their mailing list seems to agree on what the licensing
means for normal applications that happen to be written in Clojure and use its
library at runtime. Is _that_ a "derivative work", or not? Does the fact that
you write applications in Clojure have any bearing on the licenses that you
may choose?

I know that it's somewhat possible to mix the EPL with almost anything...
because I've worked with some Aptana IDE's that are based on Eclipse, yet use
GPL v3 with several paragraphs of caveats and exceptions.
([http://www.aptana.com/legal](http://www.aptana.com/legal) ,
[http://www.aptana.com/legal/aplgplex](http://www.aptana.com/legal/aplgplex))
Not sure about GPL v2.

I just don't want to have to think about this stuff AT ALL as an application
developer who isn't making changes to the programming language or core runtime
library. The murkiness on their own mailing list has definitely been a
deterrent from my exploring Clojure more seriously.

~~~
hga
Hmmm, when looked into this a few days ago with an eye towards a Clojure port
(in part a fork) what I remember finding is that the EPL allows separate
"modules" to have a different license, although of course that couldn't be an
incompatible one like the GPL based on the latter's linking requirements. The
Aptana legal link looks pretty clear at first glance, "the EPL is not
particularly compatible with the GPL".

I think we would have heard by now if there were any viral problems with
normal applications built on top of it, Clojure has been a very big thing in
the Lisp world for years.

------
gw
For what it's worth, I am actively improving Nightcode, an IDE written in
Clojure that bundles Leiningen. Last night I released 0.0.6. We have a long
way to go before it's stable, but more feedback from users is the best way to
get there.

[http://nightcode.info](http://nightcode.info)

~~~
tonetheman
I have only used nightcode a little but it is a wonderful idea. And works for
clojure stuff.

------
Mikeb85
Easiest way to get started:

1) Install Leiningen (download script, place in usr/local/bin), then "lein new
project".

2) Download Clooj (standalone .jar), run with "java -jar clooj"
[https://github.com/arthuredelstein/clooj](https://github.com/arthuredelstein/clooj)

3) Open project directory in Clooj.

It will automatically set up the REPL, and you can run expressions just like
in EMACS/Light Table, it has code completion, source browsing, etc... Super
easy to set up and run, much easier than any of the alternatives.

This Clojure environment is by far the easiest programming environment I have
ever set up. Far easier than even Python or Ruby on Linux, definitely easier
than anything EMACS-related. Leiningen is super easy to use from the terminal,
and Clooj is super easy to set up and use.

~~~
andrewflnr
Even having to build clooj from source (because the mediafire link didn't
work) was super easy. I can't get the REPL to load the symbols in my project,
but that's probably my fault.

~~~
Mikeb85
Strange, download seems to work now.

Yeah, the REPL isn't perfect (sometimes it needs to be restarted if you mess
with it too much), but it's a heck of a lot easier to set up than EMACS with
nRepl, or even Light Table (which itself is a great editor).

Another good one is Catnip, which is an add-on to Lein which launches an
editor/REPL in your browser...

It never ceases to amaze me the kinds of things that people have already done
with Clojure - games on Google Play store for Android, awesome IDEs, Pedestal
is looking like a great web framework, Datomic, Clojurescript and now Clojure
that compiles to C. Not to mention all the private enterprisey things being
done, I know of at least a few banks/hedge funds which use Clojure internally,
a robotics company, and likely many others...

------
coolsunglasses
IntelliJ + LaClojure isn't great.

I'd recommend Emacs + nRepl or Eclipse + CounterClockWise instead.

I realize IntelliJ is better typically but in this case it's not.

~~~
hhariri
What are the issues you've found with IntelliJ? Have you reported them? We'd
love to know how we can improve it. Please feel free to ping me (hadi at
jetbrains)

~~~
hansg
> What are the issues you've found with IntelliJ?

> Have you reported them?

Most issues are in your tracker since ages.

> We'd love to know how we can improve it.

merge the lein plug-in into laClojure, or keep it synced all the time.

And implement those requests there in your tracker.

~~~
reeses
The gradle/groovy integration is of only slightly better harmony. It's very
obviously a plugin and the lack of analysis makes for an awkward dynamic
programming experience.

For example, I dislike the yellow warning lines that abound when it can't
infer a type that has previously been assigned on all call paths.

------
dominotw
When ruby hit the mainstream we would see these kind of 'getting started'
atricles once in a while but very very rarely. Would it be safe to assume that
since functional thinking is such a departure from traditional OO that it
warrants more 'getting started' ?

~~~
marshray
Seems to me that installing a basic toolchain is not the hard part of
functional programming for most folks.

------
edem
The fonts on this page are very hard to read. You may change them to something
les blurry?

~~~
iooi
They're downright unreadable on my Chrome

[http://i.imgur.com/p60vLFv.png](http://i.imgur.com/p60vLFv.png)

~~~
ColinWright
Crystal clear on my Firefox.

Lesson for everyone. Beware! Cool, funky, gorgeous fonts on your machine may
be downright unreadable for others.

Stupid question - as a temporary measure, have you tried increasing the font
size? Something like Ctrl-+ should do that.

------
dschiptsov
It is advisable to begin with Scheme (SICP) or Racket (HtDP2) to internalize
the underlying ideas behind Lisps, because in Clojure everything is messed up
due to kitchen sink syndrome.

After proper Scheme training (CS61A) Clojure looks awkward and messy but very
useful, as it supposed to be due to its "productivity beats
clarity/conciseness" philosophy of scripting languages, such as Ruby.

~~~
SCdF
For someone who doesn't have enough hours in the day to receive "proper Scheme
training" and already (sort of) knows Clojure could you go into detail about
what you mean when you talk about it being "messed up due to kitchen sink
syndrome."?

~~~
dschiptsov
Gladly. Some languages does not emerge all of sudden as a product of one sharp
mind (there is no doubts about that) but are time-selected mix of (ideally
very few) basic concepts and syntactic constructs which form a well-balanced
set of features.

The examples of well-chosen set of basics is Scheme R4RS, or pg's Arc. The
examples of so-called natural selection are CL (an attempt to put together the
best ideas and syntactic sugar from various implementations) and, surprise!
Haskell, which is a product of a merge of efforts of ML/Lazy languages world.

On the other hand, there are languages created by one individual, according
their own preferences, such as Perl, Ruby and Clojure.

Ruby, for example, it is a mix of features from Perl and Smalltalk, its author
liked, but, of course, the resulting language is neither a dialect of Perl or
Smalltalk. It is a language of its own.

Similarly, Clojure is a mix of features from various languages, notable Common
Lisp, Smalltalk, ML, plus various Python-like comprehensions for vectors or
hashmaps.

There are many other clever tricks, like simplified pattern matching, at the
cost of sacrificing uniformity and announcing vectors as parameter lists for
binding constructs, apparently from ML, and multi-method function
declarations, also from ML.

The result is a language of its own, and cannot be called a Lisp, the same way
Ruby cannot be called Smalltalk. The design decisions, while mostly clever,
broke the uniformity and clarity of classic Lisps.

So, in my opinion, Clojure is closer to Ruby in its ideology, than to Lisp.

~~~
rsamvit
Clojure is most definitely a Lisp. The biggest difference from more
traditional lisps is that it has literals for a wider variety of data
structure types. Apart from that, it has every single characteristic that
defines a lisp.

> After proper Scheme training (CS61A) Clojure looks awkward and messy but
> very useful, as it supposed to be due to its "productivity beats
> clarity/conciseness" philosophy of scripting languages, such as Ruby.

As someone with "proper Scheme training" (CS61A), I've found that Clojure is
actually much more clear than Scheme in most cases. The code is less beautiful
from a purely visual perspective because there is more syntax, but a lot of
complexity gets removed when you add literals for sets, vectors, and maps.

~~~
hga
Well, I don't think it can be called a LISP, as in LISt Processing, which I
pedantically use to describe the Lisps that came before it, because in
addition to making those additional data structures first class syntactic
citizens and their widespread use by programmers, it as dschiptsov notes
modified some standard LISP syntax to use vectors where you have a list
that'll never be modified, extended, etc.

E.g. (defn name [arg1 arg2] body). Lists are not the alpha and omega like they
are in LISPs.

But I agree it has "every single characteristic that defines a lisp", even if
it looks funny to experienced Lispers like myself.

Aesthetically I much prefer standard LISP syntax + indentation , but 100%
support the use of literals for the non-list data structures. Many disagree on
the syntax, and if no longer having a sea of pure parens brings more
adaptation I'm willing to live with it. I got the impression the syntax
changes were due to that reason vs. inspiration from ML, but I'm not at all
sure about that. Still, Rich Hickey is an experienced Lisper with exquisite
taste below the level of syntax, so I'm pretty sure he was aware of the
implications of his syntax changes.

~~~
regularfry
My understanding is that the square-bracket notation is just a reader macro to
provide syntax sugar. Now, I know Clojure doesn't expose reader macros to the
end user, but you could achieve the same syntax in CL without too much hassle
([http://dorophone.blogspot.co.uk/2008/03/common-lisp-
reader-m...](http://dorophone.blogspot.co.uk/2008/03/common-lisp-reader-
macros-simple.html) for something similar). I don't think it's necessarily
reasonable to criticise it for baking in a choice you could quite happily make
in CL.

EDIT: "Criticise" is clearly the wrong word, since your description isn't
perjorative. "Distinguish" would be better.

~~~
hga
Indeed, and I'm not really criticizing it, it's a matter of taste, and arguing
over that is generally fruitless.

However, while I could make such a choice in CL, or modify Clojure, the
standard including indentation for such a fundamental part of a language is
controlling, and if I want to be part of the community I have to follow it.

