Introduction to Clojure (2013)
creativeapplications.net
creativeapplications.net
I encourage others to learn lisp. It’s really not a hard language, and the parentheses don’t get in the way after a brief period of acclimation. It also opens up the real power of Emacs customization and programming, which is done in Lisp.
The first is a quote bathed in absurdity from an actual LISP manual:
> setf can also be used with any of these functions to change an existing component of x, but setf will not make new components. So, for example, the car of a cons can be assigned with setf of car, but the car of nil cannot be assigned with setf of car. Similarly, the car of the car of a cons whose car is a cons can be assigned with setf of caar, but neither nilnor a cons whose car is nil can be assigned with setf of caar.
I think this sums up the aesthetic horror that LISP is to me. Pretty sure it was written by Dr. Seuss.
But a far more important factor exists: There are no decent paying jobs for LISP programmers outside of the browser which is a personal hell to me. Besides Clojure, I know of no real foothold in the professional world. I have no doubt there are outliers, but, that's just not the kind of thing to bet on.
So no, not bothered by the parentheses. Bothered by lack of real words with real meaning and lack of motivation to tolerate the ugliness.
There is no need to set a high bar to filter a language from my attention. There are thousands of them.
Anyway, the point is that there are reasons to dislike LISP besides the parentheses. It's all subjective in the end.
It's not from a LISP manual, it's from the language specification of ANSI Common Lisp.
You'll probably find non-obvious wordings in many programming language specifications. Don't learn a language from a spec and don't try to understand everything in a language spec, if you don't know the language.
Every time I try this, like twice a year, I get annoyed while setting up a development environment that supports the particular Lisp (usually Clojure), its syntax and the REPL. Last time I tried it was Spacemacs that didn't work as announced, on both Linux and macOS.
I am a Vi user and I would prefer to use that instead of learning a new environment such as Emacs. I want to set this up and have it work as frictionless as possible because learning a new programming language and its ecosystem is already enough work. However the Vim plugins (e.g. fireplace) also didn't "just work".
The whole project was developed using Vim.
Vim supports normal Common Lisp out-of-the-box. Just save your file under a .cl or .lisp suffix.
In 18 years of working with Lisp in Vim, I never had a problem. Never installed a plugin or did anything special (other than developing that syntax file for TXR Lisp). At most I played with the content of :lispwords; that's about it.
https://github.com/thi-ng/geom/
Check out the examples, it's very pretty. The little I've played with it it's been incredibly ergonomic and fun, in the hiccup-style you see in Clojure. Haven't come across anything like it in other languages
The project was written in a Literate Programming style. These turned out to be an obstacle for contributions, so there is an ongoing effort to migrate the code out of that. You can find the latest version on this branch: https://github.com/thi-ng/geom/tree/feature/no-org
Is this really true? It's by far the most off-putting thing about Lisp dialects to me. Trying to get nested parentheses to match is extremely tedious when I have to do it in non-Lisp languages. It seems horrific if my whole programming experience is one long exercise in "why doesn't this bracket match!?!?!!". I know it can't be this bad because too many people have no problem with it, but it's the only thing I can think when I see some Lisp source code with 50 nested parentheses ...
(And code with 50 nested levels of parens is Bad Code, just like too much nesting in a C-like language)
When using Emacs, the editor can ensure the parenthesis always match. It can also show you which parenthesis match, and if you insist on allowing having non-matching parenthesis, it can show you exactly where they don't match. So even in that case you don't have to worry about it because the editor will point it out to you.
Parenthesis are probably the most trivial and unimportant thing about Lisp, and people get way too hung up about them.
What's far more important is the power that Lisp gives you, how easy it is to program what you want in it, and how elegant and easy to understand the solutions you come up with are.
Instead of having some kind of spaghetti code monstrosity full of ridiculous boilerplate as you would in other languages, you could have a nice and simple solution in Lisp. Isn't that worth allowing some extra parenthesis in to your code?
func Foo(s string) string {
println("hello")
}
(defn foo [s]
(println s))
There are some cases where you do get a few more parens, e.g. with mathematical operators, but overall it's not that different, it's almost completely user perception.
I don't want to have to think about which delimiter I need where. Knowing that it's always going to be a parenthesis makes my life so much easier.
(let ((x 1)
(y 2))
(+ x y))
(let [x 1
y 2]
(+ x y))Granted, it's a bit easier to pick them out with square brackets, but for my taste I'd rather just have homegenous delimiters everywhere.
How often do you want to do that? Wouldn't you be more interested in what the variable is called or who it's passed to?
Yes. There comes a moment in which you suddenly stop minding parentheses. For me it was when I started reading SICP and doing its exercises on paper. After writing a couple Lisp expressions by hand, something clicked in my brain, and since then I don't need to count parentheses anymore.
I strongly suspect following the Lisp style of indentation and placing parens (closing parens go together, instead of one per line like in Algol-derived languages) is vital to achieving that.
After working with mostly Python and Clojure since 2015, I now have a similar gut reaction to curly brace languages that most people have to lisps. I find ClojureScript much more readable and aesthetically pleasing than Javascript.
Definitely - I have started writing JavaScript braces for nested callbacks in that style as well because it makes much more sense.
The style in lisp is to keep all the closing paren on the same line: ))))
But in java or C you’ll sometimes see a function that ends like: } } } }
(Hmm my newlines didn’t cone thru on those braces)
Not exactly apples to apples comparison, but it illustrates how you can start to unsee those parens.
}
}
}
}
}
}
}
}