Hacker News Reader

Comment by maxpert | Hacker News Reader

I have honestly tried many many times to read books/tutorials for getting started in LISP. I know there are many LISP inspired languages and Clojure is one of them. Where LISP throws me off is the excessive use of parenthesis, up-to the point my mind can't keep track of them anymore and IMHO language uses it's comprehension abilities. I am still struggling and pushing hard to learn it; hopefully I can get over it and experience the most powerful language. Any good starting projects/ideas I should try doing in LISP/Clojure etc. to help me out?

View on HN

Try once more. Pick a small project and just try and try again until you get it written.

Tip #1 - spend more time in the repl than in the editor. The repl lets you figure out and grok the small things.

Tip #2 - compose the small things into bigger things. (And if you find yourself composing too many semi-complex expressions into on big expression, feel free to take any smaller grouping of expressions and turn them into a function.

You may start out very disoriented; but if you keep trying, at some point after trying (perhaps for a few evenings, consistently) it will just suddenly click. It's a wonderful feeling to suddenly get it.

One last tip - Everything is really just this pattern: open paren, operator, some number of parameters/data, close paren. I'm not a Lisp teacher, so I may be stating this inaccurately, but it's just that simple. The pieces may look like more than what I just described, but they are really that simple.

And on the topic of "too many parens", compared to Javascript, C/C++, Java and many other languages, you'll find about the same number of them. They're just arranged differently (and more uniformly in Lisp). Better yet, because they're so uniform, you can completely ignore/forget about the end of big expressions with their )))). Ignore it. Use an editor that matches braces, (I like rainbow color matching).

And now, a warning. If you take the time to really learn Clojure, there's a good chance you'll love it. Then you will find that in most companies, you won't be able to use it unless you sneak it in. Then you'll end up in Elixir because it "looks like" Ruby, and because everyone bought into Rails. But you'll still wish you were using Clojure.

> And on the topic of "too many parens", compared to Javascript, C/C++, Java and many other languages, you'll find about the same number of them.

Exactly. Even more, if you start counting {}, <> and []...

Also, before someone says "but prefix notation!", all mainstream languages are prefix too everywhere except math. That is,

  frob(barify(foo, bar))

is prefix notation, and equivalent Lisp is achieved by just shifting the opening paren to the left of the operator name (and dropping commas, thanks to the uniform syntax):

  (frob (barify foo bar))

Adoption of Elixir is no higher than Clojure. Slightly lower, I'd say. The bigger danger of loving Clojure is going back to working with OOP. Clojure can seriously damage your tolerance for OOP and in today's job market that's a real handicap.

For me, Elixir is a way to do Rails-like web development with much better runtime performance, plus the big bonus of functional programming. And because Rails was such a success (I still get recruiter spam constantly for Rails positions, even after 10 years), I think Phoenix+Elixir will gradually come out on top. It's just a shame that I fell in love with the Lispiness of Clojure. Do...End...sigh.

Beyond the superficial syntax similarities how can developing in a functional language possibly be Rails-like? Mutable OO and immutable FP are opposite ends of the spectrum. I never bought this Elixir for Rubyists sales pitch. Phoenix does't even use an ORM. That said, I really like Phoenix.

I too get a lot of Rails spam from recruiters which I find hard to fathom since Rails usage is on the decline. What's your take on this? Is it that Rails shops will only settle for senior developers?

Syntax similarity probably reduces the "fear of new" (different) that prevents some people from making the transition. But the biggest factor is that the creator of Elixir, José Valim, is a well respected Rails contributor.

But indeed, Elixir is so different from Ruby that one doesn't just casually move to it from Ruby without learning to think functionally.

To your question about Rails, I'm not sure I can say whether it's in decline or not. But I do know that many hiring managers are not technical enough to know what's important, so they try to replace exiting employees with people who have the same skills. And probably there are one or more Rails apps that still need dev/maintenance. As far as money goes, Rails is still a very lucrative career focus, at least in the US.

Rails adoption in the U.S. relative to it competitors - Laravel, Node and Django - is much higher than anywhere else. Outside London Rails adoption is very low in Europe.

It is a handicap but anyone paying attention can see that reactive ui and concurrency are becoming mainstream . Functional / immutable languages seems like the only sane way to tackle these issues. I started writing some Reactive JS code and wanted to barf when I saw what the code looks like .

Hi :)

I feel your pain here and just wanted to let you know how common this is for programmers who initially try out Lisp for the first time. As others have alluded to, I promise this initial "parenthesis shock" goes away rather quickly as you read and write Lisp code. In my direct experience, I have hired junior developers straight out of a coding bootcamp who were able to pick up ClojureScript in their first week using Sublime Text with no editor extensions. In other words: you can definitely do this; it's not magic.

I would strongly encourage you to check out Parinfer [1]. Parinfer makes indentation "significant" so you never have to worry about "closing the parens". Basically, if you can handle Python or CoffeeScript indentation, you can handle Lisp. There are no hotkeys to learn and it is available in most common editors today.

For a first project I would recommend rewriting something you have already written and are familiar with. That way you can focus on just the language and not worry about the problem domain or "how to solve it". Just do a 1-to-1 port of something you've already done and compare how the two solutions are the same or different.

I'm sorry you are being downvoted and being told to "just use emacs" or "use the REPL more". IMO, these are not helpful suggestions for someone new to the language.

Good luck. You won't regret learning Clojure. One of the best things I have ever done for my career.

[1]:https://shaunlebron.github.io/parinfer/

Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages.

If you need the visual differences between those various kind of parentheses, many lisps and schemes allows to use and mix any of those.

If you are confused because the parentheses are not in the usual place, then I think you are trying to solve problems that are too trivial if such a tiny bit of syntax get all the attention. Or, that you are trying Lisp on problems that are not a good fit. Obviously, lisp (or ML, for that matter) shines at manipulating symbols, not bytes.

I do not personally believe that lisp is, in general, "the most powerful language", but there is a problem where it can be said that it is the most powerful language: it's to write a Lisp interpreter.

Maybe that's the good starting project you are looking for? If so, I can't recommend enough the book "lisp in small pieces".

> Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages.

This is true a lot of the time. Also, commas don't exist in Clojure.

So you might have this in a C-like language:

     if ((foo > bar) && (bar > boo)) {
        doSomething(a,b,c);
     } else {
        doSomethingElse(d,e,f);
     }

And in Clojure:

     (if (> foo bar boo)
         (doSomething a b c)
         (doSomethingElse d e f))

Another interesting side effect is that in C-like lang, one my say that due to precedence rules, (foo > bar) does not need the parenthesis since && is lower precedence. Yet, if you weren't sure, you'd have to take a short break and go look that up to be certain. Most devs will just keep the parenthesis instead of take that little break, or they will write them in anyway for readability. In Lisp, precedence rules are never an issue because all operators and functions are applied the same way. So the parenthesis might seem cumbersome at first, but they quickly make syntax quite a lot simpler.

Commas are whitespace in Clojure. You can use them if you want to, it's just not idiomatic.

It's also not idiomatic to write "doSomething" instead of do-something, but I thought those mentions detracted from the point.

And in Scala:

    if(foo > bar && bar > boo) doSomething(a, b, c)
    else doSomethingElse(d, e, f)

> Yet, if you weren't sure, you'd have to take a short break and go look that up to be certain.

If you don't know how logic works then why programming? Also, this is not a "complex rule", this is just BASIC LOGIC. As obvious as it can be: read it aloud and you have it.

Also, what would this even mean:

    (> foo bar boo)

THIS is what we need to check out because it's everything but obvious.

> So the parenthesis might seem cumbersome at first, but they quickly make syntax quite a lot simpler.

It won't, it'll just make the code monoton and harder to look at.

> If you don't know how logic works then why programming?

Logic and precedence rules are two different things. I know plenty of Haskell devs who frequently consult not just the precedence but also the associativity (right/left) or operators or functions when reading or writing their code. C++ also has a very long list of precedence rules. It's not trivial and many find the lack of these added complexities an advantage in the simple lisp syntax.

> It won't, it'll just make the code monoton and harder to look at.

True, only if you haven't written much lisp.

I suspect you are trolling here, possibly, so maybe my feedback won't matter.

> Also, what would this even mean:

> (> foo bar boo)

>THIS is what we need to check out because it's everything but obvious.

Any symbol or word in Clojure (or another Lisp) following an open parens is a function call. You literally learn this in the first 2 minutes during the explanation of prefix notation, e.g. (+ 1 2 3) equals 6 or (- 10 1) equals 9. The great thing about Clojure is that > is just a function, not some special notation, so if you are in doubt you can use your editor to click through to the get the function definition (and the actual code). It isn't very hard to train your mind to treat any sequence of (foo x y z) as a function call.

Ok. Function call. Got it.

So what does (> foo bar boo) mean?

foo is greater than bar is greater than boo

or, put another way, the arguments must be in descending order

It's like instead of writing 1 + 2 + 3 + 4 in Clojure, you write:

    (+ 1 2 3 4)

Less characters to type. Because operators are functions, which are always first in a list, normal binary operators like + can take many arguments.

Another benefit of this is function application. If you have a vector/array of numbers and you want to add them all up, just apply them as arguments to +:

    (apply + [1 2 3 4 5 6 ...])

If you had an array some-array that had hundreds of numbers, this would be trivial without doing anything other than using the same basic + function:

   (apply + some-array)

And since you are expressing the arguments as a single piece of data here, and you can have functions that are much more interesting than +, you can see where this leads.... building up arguments as data, using them in function application. It gets very interesting very fast and the language unlocks a lot of ideas you just don't get in other languages.

I suppose my original point was that its not obvious, because (+ 1 2 3) behaves differently than (> 1 2 3). Mapping a binary operator to a list is obvious if the type of the result is different than the type of the operands.

I also find 'Less characters to type' a weak argument at the level of a handful of plus signs, but I grant that once you've made the mental leap there is less cognitive overhead. In the '(> x y z)' if I knew to read '>' as 'is descending' the meaning would have been obvious, but reading it as 'greater than' didn't make sense to me.

If you can agree that (> a b) makes easy sense, that a is greater than b (it's the same symbol as a > b, just in a different place), then I don't see how that's any more difficult than (> a b c), which means that b is also greater than c. But then I've been staring at lisp code for years.

Since `>` is a function, you can just read the function doc (you can do this by calling (doc >) in the repl):

    user=> (doc >)
    -------------------------
    clojure.core/>
    ([x] [x y] [x y & more])
      Returns non-nil if nums are in monotonically decreasing order,
      otherwise false.

So (> foo bar boo) essentially checks if bar is between foo and boo.

'nums'? Where did that come from? I assume x and y do not have to be nums?

> and < are for numbers, so yes x and y are nums.

If you instead want to compare or sort other values, Clojure offers other functions for that purpose where you can specify in great detail how things should be compared. If > could operate on strings, for example, what would be the expected result? The shorter the string, the "lesser" the value, or the string that starts with the "lower" letter, etc... it's quite ambiguous. You need more than < or > for that kind of comparison.

It means, literally: call a function named '>' and pass it the three arguments specified. That's it.

You may ask what does the function > do when called, but that's a different question and has nothing to do with a language's syntax and semantics.

Also, it's exactly the same with non-Lisp languages. If you don't know Python and see a fragment of code like this:

    2 ^ 3 ** 3

wouldn't you have to ask the same question, ie. what do the operators `^` and the other one do when used? However, in this case, you need to also ask about the precedence of the operators, which doesn't exist in Lisp.

Is there no HN rule about making a fresh account just to incessantly troll a single comment section?

You're trolling.

You never "use your mind" to keep track of parentheses in any language - you use the editor's features for this, and read code structure by indentation like any sane human being does (also, it helps that I touch mostly Python ;) ...but for other languages you just configure your editor to reformat you code on every save or on linting). Everyone can get over "parenthesis madness" after configuring their editor properly and a few days of habit. Also, once you learn about "paredit mode" editing, if you like it, parens become a superpower, because you're not "typing code" anymore, you're just using your editor's shortcuts to edit the abstract syntax tree as a tree object that it rightfully is, not an ugly bucket of "code text"...

If you're sincerely not trolling, then Lispers will be glad you don't join in and come and soil their codebases with miss-indented or unnecessarily over-nested because of bad structure code...

The parenthesis disappear from your thoughts after a few days, especially if you are using a proper editor with a feature like paredit.

Clojure improves on this compared to other lisps because it uses brackets and squiggly braces instead of parenthesis for a lot of its syntax, making that aspect much easier to read.

Just stick with it, you will see it is a non-issue after you get started in earnest.

Use an editor that helps balance parentheses and automatically indents Lisp code. If the indentation is consistent with the parentheses (very easy to maintain with a decent editor) then you can mostly ignore the parentheses and just look at the indentation.

Break big functions with deep nesting into smaller functions. (Like in any language). If you have to page up and down several screenfuls to check whether multiple blocks are at the same indentation level and under the same parent, maybe the function is too big.

I wrote a blog post on the issue: https://klibert.pl/posts/tools_for_lisp_syntax.html

I'm linking it because it has a couple of screenshots, which I think works better than just reading a description of how it should look like.

> Where LISP throws me off is the excessive use of parenthesis

There's a standard way to indent lisp (the emacs way, which everybody copies) and as long as it's indented properly you read it like a whitespace significant language (Python, F#, etc).

Clojure is a bit easier to read than other lisps because it uses [] for vectors, arguments, and assignment blocks and {} for maps and sets. Gives the code a bit more texture.

People writing lisp day to day use an editor feature to automatically keep parens balanced (Paredit, Parinfer). Not required since there's a learning curve but it makes editing smoother if you're going to write lisp full time. A text editor that highlights the opening paren when the cursor is on the closing one (pretty common feature) is all you really need.

It also uses fewer parens than other lisps. Clojure let statement (let [foo "bar" baz "qux"] foo) => "bar" Scheme (let ((foo "bar") (baz "qux")) foo) "bar"

So in addition to additional symbols for notating vectors, map, etc, it uses fewer parens in general.

that was literally my story as well until i tried Clojure. i think convenient data literals is the top reason i could stick with it and properly learn a LISP. immutable to the core, nice concurrency primitives, trivial access to the whole java ecosystem - those are just cherries on top.

try using Atom with Parinfer plugin. i vehemently disagree with people trying to push emacs on Clojure/LISP newcomers. having to learn a possibly completely alien editor to be effective programming LISP is another big thing that pushes people away.

If you've done lisp for a while, you don't try to match the parentheses.

Firstly, you have an editor that matches them up for you.

Secondly, you read via indentation and whitespace. And since just about the only thing defining the syntax of lisps is the list structure, the editor also parses and can take care of that relatively automatically too.

I found it took about 6-12 months of exposure, and then your brain just tweaks/snaps/breaks magically one day, they all disappear, and then you no longer see them :P

I read 2 books, watched a training video, and watched a Rich h. Video if I needed inspiration, but it didn’t completely click until I just wrote a small app in it. Just build a script in it to learn. Break your code up into defs and tiny functions to understand what you are trying to do and then put it all together into a function. The only parallel I have professionally is when I try to write very complex sql

Clojure code actually ends up having less parens, and others symbols than most languages. Here's an example comparison with Java https://labs.ig.com/lines-of-code-matter

>The only difference in readability is that the Java version has a lot more parentheses.

Parentheses aren't an issue if you write Lisp in Emacs.

You don't need emacs for good parenthesis control. The same tools emacs uses for this are available in about a dozen editors at least. Vim, Atom, Cursive/IntelliJ, Eclipse, Sublime Text, it's pretty common in most good editors.

Understanding programs with recusion requires actually programming with recusion that many devs just aren't exposed to. It's just not the dominant paradigm

Explicit recursion is rarely used in FP, and it's often a code smell. It's almost always better to use higher order functions instead. The advantage is that you can implement a particular transformation once, check for edge cases, and reuse it from there on. You also end up with declarative code that talks about what it's doing without distracting your with implementation details.

Clojure has a rich set of functions for manipulating data such as map, filter, reduce, and so on. There are also libraries such as Specter https://github.com/nathanmarz/specter that allow you to declaratively transform complex data. I highly recommend watching this https://youtu.be/rh5J4vacG98 short video to see how it works.

You misinterpret my comment thinking it is a statement about myself, when it is a statement about the wider programming community.

My point is that you don't really program with recursion in Clojure, so it's not an actual problem for people using the language.

My point is that there is a learning curve no matter which way you slice it, as one must also learn to use higher-order functions effectively (I do not believe mainstream devs know this innately) and this is an obstacle for newcomers.

Pretty much all mainstream languages use higher order functions nowadays, it really shouldn't be a foreign concept at this point.

The basics of HOF are not foreign concepts at this point (e.g. map, filter). But FP amplifies the degree and nature in which they are used.

for example learning to use folds or transducers. Learning to avoid mutation etc

Why is learning a few FP concepts considered more taxing than the all the cruft which accompanies OOP? My experience is that FP concepts and idioms are a breath of fresh air compared with OOP design patterns.

It is not 'more taxing'. It is less familiar and implies an effort to learn for an existing dev. (I am talking about existing devs, not those learning their first language). The issue for those folks is not absolute difficulty but motivation.

All I can say here is that my team has been using Clojure for over 7 years now, and hiring devs hasn't been a problem. At this point, my view is that if somebody has problems learning these concepts, I probably wouldn't want to hire them to work with any language.

I have no doubt you've had great success with clojure.

However I question generalizing from 'this was not an issue for my team at my company' to 'this should not be a concern for any company under any given constraints'.

I don't doubt most devs wouldn't have problems learning these concepts. It's whether business have capacity to allow those devs to onboard in such a fashion, knowing that different business are subject to different constraints.

There are many companies using Clojure large and small, nobody actually using the language has problems hiring people for it. This is not a theoretical debate, there's no evidence to support the notion that Clojure is hard to hire for.

In practice, the language is a small part of what a new hire has to learn. Each company has different processes, tools, workflows, frameworks, and so on. A language is only a small part of that.

While there are obviously companies where Clojure wouldn't be a good fit, the reasons wouldn't be that it's hard to train new people to work with it.

You don't even have to use Emacs nowadays. Atom has lisp-paredit and parinfer package, VS Code has paredit, Cursive has a structural mode, and so on.

An editor plugin which supports color-coded parens makes the parens problem disappear.

You should try parinfer for your editor, that should help with the parens

function.(x,y,z)

(function x y z)

I happen to like Lisp (well, Scheme at least), but I think a better comparison would be:

    let a = 123, b = 456, c = 789;
    # more code

vs:

    (let ((a 123)
          (b 456)
          (c 789))
          ; more code
     )

In many cases outside of function calls, there are more parens.

Well, a more accurate comparison would be like this:

  {
    let a = 123, b = 456, c = 789;
    # more code
  }

Because Lisp let explicitly defines its scope, while the first example inherits the scope from whatever it is embedded in.

And in Clojure:

     (let [a 123
           b 456
           c 789]
        ...)

Clojure syntax was designed with a clear and deliberate attempt to remove many of the parenthesis from lisp syntax. This is just a part of the greater design goal of offering very concise and elegant syntax in general, which is one of the reasons I keep coming back to it.

Speaking as a beginner, I find the pure lisp example easier to read than the one with the clojure literal syntax. I actually don’t like the []. I’m sure I’ll get used to it tho

Yep, Clojure made some nice improvements (still 4 parens, however), but I just can't get excited about the JVM.

The JVM does solve the distribution problem that's heavily frustrated me with other platforms.

I can create a great tool in Ruby for example, but asking a computer illiterate to run it in Windows isn't going to happen.

You can however hand that person a .jar from Clojure and ask them to run it.

Assuming they have Java installed. Which, in my experience, is less and less likely as time goes on, for random samplings of non-developer Windows boxes.

Not anymore! Java now can link JVM, runtime, and your own modules into a bundle that just works and runs everywhere.

On Linux, you’re even able to compile most of it into a single binary.

Good to know. Does it tree-shake to cut down irrelevant stuff out of thefinal package?

That’s exactly why Jigsaw and jlink were so important, because they provide exactly that.

> (still 4 parens, however)

My example has 2 parens.

Even if you're not excited about the JVM, ClojureScript is particularly productive for front end development, where I genuinely love it tremendously.

well, ok but the comparison is moot when you consider that dense lets are rare in Lisp

that should have been object.function(x,y,z) or function(x,y,z) - typo and it's too late to edit

You just have to indent them the same way you'd indent curly braces.

The harder part about lisp is actually recursion. Surprisingly, there aren't a lot of programmers who can follow recursion naturally.

(loop exists in lisp but recursion seems to be the common idiom)

>"The harder part about lisp is actually recursion. Surprisingly, there aren't a lot of programmers who can follow recursion naturally."

All examples of recursion I've ever seen in Lisp follow a similar structure...

* First section checks if recursion is finished. If so, return final result (or final element of full result if returning a list).

* Second section performs an action or two on the inputs.

* Third section calls the function again with revised inputs.

In many ways it's just a do while loop with different syntax.

Not true; loops exist (as a macro) because recursive functions(that naturally correspond to loops and iterations) are harder to read because they hide the logic of termination conditions. Fortunately we are using a powerful language, that lets us transform natural loop syntax to a recursive function.

In my experience you rarely need recursion in Clojure, to the point that it's unidiomatic to use it. For 95% of your looping needs you use combinators, and for the rest there are the loop macros.

I would say nearly all my loops are either map or reduce. That's it.

Downvotes for asking? :/

I'm sorry your original question has been downvoted. I think it's a perfectly reasonable experience report and question. I replied here: https://news.ycombinator.com/item?id=15527041

Reply on news.ycombinator.com