
Clojure from the ground up - kercker
https://aphyr.com/tags/Clojure-from-the-ground-up
======
susi22
I've been doing Clojure full time for a few years. Here a recommendation on
editor setup if you're new to the parentheses:

1\. Setup Cursive ( [https://cursive-ide.com/](https://cursive-ide.com/) ) 2\.
Start a REPL on the command line with `lein repl :start :port 38123` and
connect to that repl with cursive, a remote REPL. 3\. Bind and learn the
following structural editing commands:

a) Grow selection (this will be by FAR the most used in the beginning)

b) Slurp.

c) Send top form to REPL.

d) Join lines

Don't ever select by line, only use "grow selection". Don't ever break any
parens ("[({") imbalance. Shouldn't happend if you use "grow selection".

Editing like this will get you pretty darn productive. I used it for probably
6-7 months before I introduced more structural editing commands (Next in line
is IMO "Move Forward").

~~~
keymone
the biggest leap in productivity i've experienced is after i tried parinfer
([https://shaunlebron.github.io/parinfer/](https://shaunlebron.github.io/parinfer/)).
seriously, just find the plugin for your editor, it is amazing, the cognitive
load of balancing is simply gone.

~~~
markc
Coded Clojure for years, including w/ Paredit and I find Parinfer extremely
frustrating as it fights my edits and sometimes creates syntax errors - in the
Atom Parinfer in indent mode anyway. Maybe other implementations are better?
Or do I just have to "unlearn" a bunch before I can relax and let the magic
flow? Cuz as it is, Parinfer makes me nuts.

~~~
keymone
the only issue i've seen with parinfer is that i can get confused when you
have multiple forms within single line, it can sometimes inadvertently slurp
the rightmost forms and i have to go and insert closing parens manually. that
doesn't happen often though, otherwise it's been very smooth for me. i imagine
that when one is fluent with paredit and structural editing, parinfer can feel
like a step back, but for newbies it is the first thing i will always
recommend.

------
markc
Btw, this tutorial is by the author of the esteemed Jepsen
[https://jepsen.io/](https://jepsen.io/) and Riemann
[http://riemann.io/](http://riemann.io/) . He really knows his stuff, yet this
material is very approachable.

It should be noted however, that the project was put on hold several years
ago, with the intent to eventually tackle: Polymorphism, Modularization and
refactoring, object state, JVM interop, Clojure type system, Compiler at
runtime, Build your own language, Performance analysis, Parsers and protocols,
Storage and persistence, Networks and messaging, and Concurrency and queues.

Consider [http://www.braveclojure.com/](http://www.braveclojure.com/) as
another free and well-written Clojure learning resource, that's more complete.

------
hacker_9
I like Clojure but ended moving away from it to Racket instead. The error
messages and debugging story in Clojure just plain suck, and have for a long
time now.

Error output is just java stacktraces, which for a newcomer make zero sense. I
got stuck for two days on something before realising the problem was because
of a lazy list elsewhere in the program. The CIDER debugger is pretty good,
but I can't help feel that people who sing it's praises haven't been exposed
to graphical debuggers like in Visual Studio, which offer a far superior
experience. Additionally there is no break on exception functionality, and you
have to actually commit a debuggable version of a method before you can step
through it. Combined with the nonsensical erro output, you can be looking for
hours for the actual location an error occurs. Which is bizzare because
functional languages usually make error finding a breeze because mutable state
is so locked down.

I'll mention Cursive too, which is an intelliJ plugin, that does actually
offer a really good editing experience, and more importantly a modern
graphical debugger that makes sense. But it's only a 30 day trial before you
need to pay, and because Clojures error messages are still useless I just
can't see a reason to pay for something I get for free with any other
language. It's a shame because otherwise the Clojure library comes across as
really well designed.

Since moving to Racket, I've been a lot more productive because of the out of
the box editor it ships with, which along with its built-in package manager,
really make it feel like you can hit the road running.

~~~
jstewartmobile
That's the fatal flaw--being a layer over the JVM. It's a shame since the rest
of it, as well as the community, is top-notch.

~~~
markc
Yes, stack traces suck, but being on the JVM is also a gigantic win for its
runtime ecosystem and vast collection of solid libraries that you can access
almost seamlessly. I.e. it's a flaw, but hardly a fatal one for large numbers
of enthusiastic Clojurists.

~~~
cle
It's not _just_ being on the JVM that causes the annoying stack traces. It's
certainly possible for Clojure to inspect errors and provide better ones. But
then it needs to know a lot more about its hosting VM. The crappy stack trace
situation was a design decision to keep Clojure loosely coupled to its VM,
allowing it to be more easily ported to JS (ClojureScript), .NET (Clojure-
CLR), etc.

------
BWStearns
The modeling chapter is really fun (for those with some clojure chops already
looking for a fun random place to assess the work).

------
ranit
Chapters do not appear ordered. Is this intentional?

~~~
Dangeranger
Yes, they are in reverse order, start from the last post and work up.

~~~
john2x
From the ground up :)

