
Lisp in Small Pieces of Clojure, part 3 - ghosthamlet
http://gmorpheme.net/lisp-in-small-pieces-of-clojure-part-3.html
======
globuous
Slightly unrelated, but to those who have never tried Lisp because of the
parenthesis (like me until recently), here's my take:

I've recently started hacking with Elisp, and I really like it. Parenthesis
are obviously pretty awkward at first. But now I wouldn't leave them for
anything else. As it turns out, the brackets make it easy for your _editor to
understand the semantics of your code_ , to a whole new level. So your editor
is now actively helping you navigate and edit your code. You go from
expressions to expressions, add one after an other, transpose them and their
parameters, absorb other expressions, insert them etc. It's true magic. I
thinks that's why some don't like the fact that CL-loop is not "lispy" enough:
you lose your editor's help inside a CL loop.

So the parents are actually really cool: you can basically tell your editor to
move code around and insert / delete it instead of doing it yourself. With
these tools (smart parents and paredit on emacs), your parenthesis are always
matched ! And because it's lisp, you're actually forced to use these tools
because it's a nightmare otherwise (which makes it kinda hard to learn at
first), so you actually do learn them. I haven't used smartparents with other
languages, but I hear it works pretty well.

Finally, it seems that lisp dialects compile to almost anything. Which means
that you can use a lisp editor and get all its benefits even when working in
clojure on the JVM or clojurescript on the browser etc. And once you're good
at lisp, you can pretty much make Emacs do anything.

Conclusion: Lisp Is Pretty, give it a try when you get a chance ;)

[0]
[https://github.com/Fuco1/smartparens](https://github.com/Fuco1/smartparens)

EDIT: fixed some sentences so they make sense...

~~~
JackCh
My biggest complaint about lisp (which I love dearly) is that the overwhelming
majority of the lisp community (or lisp communities) have already settled on
Emacs as the obvious choice in editors. And for good reason, the emacs tooling
is unparalleled. And because everybody is using Emacs, non-emacs tools are
neglected at best. It seems quite common for stand-alone REPL's (let alone
extensions for other editors) to be neglected and shoddy because everybody
influential in the language's development are already using emacs and have no
use for a stand alone REPL.

It's great for people who already use Emacs. But a lot of people have deep
personal investment in other editors because they got started years ago
programming in some non-lisp language for which Emacs was virtually a
footnote. And sure, learning Emacs is possible for established programmers who
are new to lisp, but learning a new editor in addition to a new language is a
hurdle most languages don't have (or if they do, it's often a reasonably
simplistic GUI IDE.) It's amazing how many books, manuals, etc start off on
the first page saying something to the effect of _" You don't have to use
Emacs... but seriously go learn Emacs."_

This all said, there are a few ways to get psuedo-SLIME behavior out of Vim
but they all seem to suffer from lack of TLC and established lisp users
usually look at you strange and question why you're not just using Emacs.
(Also the s-exp structure of lisp code still makes it easier to manipulate in
Vim (sans plugins) than other languages. The % movement really gets a workout
when editing lisp code)

~~~
eadmund
… but seriously, go learn emacs!

After using it long enough, you'll realise that no editing environment even
comes close. emacs really is superior to everything else out there: org-mode,
magit, notmuch, gnus, slack-mode, all the different programming language
modes, eshell &c. combine to form the best editing & development environment
out there. From that first moment you write a little bit of elisp to make your
life better and for the rest of your life (or at least as long as your eyes &
hands permit you to use a computer), emacs really is worth it.

 _Not_ using emacs is a bit like trying to walk from Mexico to Canada, with
one leg in a splint: possible, but why hobble yourself?

~~~
JackCh
I hear you, and it's not like I haven't dipped my toes in to test the waters.
But after 20+ years of vim usage it's not so easy to turn on a dime.
(Particularly when Vim is more than sufficient for the work I'm actually
getting paid for.)

~~~
eadmund
FWIW spacemacs is a pretty decent vim-alike. Not perfect, but still pretty
awesome. It's tougher, though, if you've been using a lot of extensions to
vanilla vim.

------
gnl
For anyone who'd be interested in trying a Lisp (with Clojure probably being
the most mainstream one at the moment) and who's been put off by the parens,
paredit and/or Emacs:

\- Parinfer
[[https://shaunlebron.github.io/parinfer/](https://shaunlebron.github.io/parinfer/)]
- makes the parens follow indentation and vice versa and effectively makes
them a non-issue at worst and a great advantage at best (you can combine it
with paredit later on to perform all kinds of ninja magic when editing code)

\- Cursive [[https://cursive-ide.com/](https://cursive-ide.com/)] - a Clojure
plugin for IntelliJ IDEA for a more 'just works' experience. Integrates
parinfer, among other things, and is generally pretty great (I'm a happy
customer).

And last but not least - rainbow parens to keep nested expressions readable.
Pretty much every Lisp editor has them more or less out of the box.

~~~
AlainPicard
I would very much NOT recommend using something like parinfer; IMO if one is
learning lisp, one ought not to try to avoid the parentheses, but rather learn
the advantages of using them. So instead of parinfer, use paredit and learn
the key bindings for moving up/down/formard one sexpr at a time. It's
frustrating at first, but after a few days, you will never want to go back to
line oriented languages.

~~~
gnl
Well, first of all let me emphasise again that it's not an either/or
proposition, they work together perfectly fine. Personally I use paredit
extensively and yes, going back to a language/environment without it feels
like having to work with my hands tied behind my back, but I still make use of
parinfer as well.

Sometimes just deleting a couple of lines in Vim (IdeaVIM in my case) and
knowing that parinfer will take care of the parens feels faster and more
comfortable to me than using paredit. YMMV.

And as far as beginners are concerned - for someone coming from an
OOP/imperative programming/C-style syntax background, a LISP will seem very
foreign and weird for many reasons, the parens being just one of them.

I think having the ability to get your feet wet and start dabbling without an
upfront investment is a good thing and the "jumping into the deep end"
approach isn't for everyone, especially not for many beginners who at this
point have only a very vague idea that a LISP might be for them and are
already facing a number of new concepts that they need to get their heads
around.

Parinfer requires no investment, Paredit requires some. Not much, but still.
And going from one to the other as one feels drawn to explore the language is,
I think, a perfectly natural transition, which requires no unlearning or
changing of habits whatsoever, and as such it's also a more accessible path to
getting into LISP. In my book, that's a good thing.

But here we're beginning to move into a general attitude/philosophy territory
that's hard to argue about, so I'd be perfectly comfortable with agreeing to
disagree and leaving it at that.

------
taeric

        While deep inheritance hierarchies 
        may seem like a great way of 
        modelling your concepts when you 
        have a blank slate, it’s a 
        recipe for some extremely tight 
        and non-obvious coupling that 
        can deadlock refactoring attempts
        in later phases once those concepts
        have shifted and the original 
        model is no longer a good fit.
    

This is probably the best critique of nominal inheritance I've read. It really
does capture the problem and nicely alludes to the struggle of arguing against
an inheritance structure. That it usually starts with many benefits but can
easily grow to a constraint.

~~~
itwy
I kept trying reading this as a haiku.

~~~
taeric
Ha! Apologies. I gave a somewhat vain attempt at quoting so it would show on
phones ok.

------
laxentasken
This is part three.

Part one: [http://gmorpheme.net/lisp-in-small-pieces-of-clojure-
part-1....](http://gmorpheme.net/lisp-in-small-pieces-of-clojure-part-1.html)

Part two: [http://gmorpheme.net/lisp-in-small-pieces-of-clojure-
part-2....](http://gmorpheme.net/lisp-in-small-pieces-of-clojure-part-2.html)

~~~
benjaminsuch
That's whats mentioned right at the start of the article?

    
    
      This continues a translation of various parts of Lisp in Small Pieces into Clojure. For earlier chapters, see:
    
      Lisp in Small Pieces of Clojure - part 1.
      Lisp in Small Pieces of Clojure - part 2.

------
cup-of-tea
Oh this looks great. I loved L.I.S.P. I did plan to dust off my French and try
the second edition. But I'm sure I'll enjoy this just as much.

~~~
nextos
A testament about the quality of Lisp is the breadth and depth of its
literature: SICP, PAIP, On Lisp, Lisp in Small Pieces, CLtL...

The only great book I'd like to see written in Lisp is CTM.

~~~
cylinder714
"CTM"?

~~~
sigjuice
[https://mitpress.mit.edu/books/concepts-techniques-and-
model...](https://mitpress.mit.edu/books/concepts-techniques-and-models-
computer-programming)

------
agumonkey
I applaud joyfully.

------
grzm
(2015)

