3 ms·

That’s just for writing though, not reading. I still find lisp code very difficult to read, perhaps not due to parens specifically but more because there is no

That’s just for writing though, not reading. I still find lisp code very difficult to read, perhaps not due to parens specifically but more because there is no syntax. Like just the very simple test assertion in this article is not particularly easy to parse. Obviously I realize that it calls a function and asserts the return value is equal to the expected value because that’s how tests work, but it’s so much less readable than what I’m used to.

User23 7y ago
Lispers read code by indentation, not by scanning parenthesis. Properly formatted Lisp, which is trivially automated thanks to the code being so easily parsed and manipulated, reads pretty much the same as Python. A good editor will shuffle things through the parenthesis based on indentation too, so the experience of writing it is keystroke for keystroke pretty close to Python as well if that's what you want.
iLemming 7y ago
> That’s just for writing though, not reading. I still find lisp code very difficult to read, perhaps not due to parens specifically but more because there is no syntax. Most of us are too familiar with the infix notation. It is deeply ingrained on the subconscious level of our assumptions about programming languages. It is indeed tricky to quickly parse a snippet written in a Lips with an untrained eye. Many software developers with prior experience in programming, at their very first encounter with a Lisp dialect, instinctively try to reject it. It looks unnatural and doesn't feel right. In comparison - most people who never wrote a single line of code ever before, usually don't struggle with Clojure or Racket. However, if one ignores the instinct, persists, and gives it some more time, they may find an incredible world of possibilities. There is a way to speed up the process of adapting to reading and writing Lisp code. The trick of learning to read Lisp code efficiently, is simply refactoring code on the go. Don't try to learn a Lisp dialect by merely staring at code - in books, on web pages, etc. Pick up an IDE or editor that supports Structural Editing. Structural Editing is a way to navigate and refactor your code without breaking parenthesis or other characters that define the structure of your code. Learn basic structural editing commands - slurp, barf, raise, transpose. And modify the code, pick up functions, and try to dissect them. With a connected REPL, Lisp allows you to evaluate any expression without any prior ceremony (a feature that most other languages don't have). You can try every single piece, break up functions into smaller ones, or compose multiple small functions into a bigger one. It doesn't take too long until you see the benefits of this approach. Sadly, for some people going back to normal life, after discovering powers of Lisp becomes like going back to drugs after detoxification. Almost every discussion oh HN about Lisp-dialect results in at least one comment of someone claiming that they've tried writing Lisp for many years but never have "discovered" its powers or even after years it still feels "unreadable" to them. Most of the time, those comments are disingenuous. Lisp does not require anyone to have a "differently wired brain." Nobody comes into this world with the innate ability to read and understand Mandarin better than English or with the ability to be able to learn Python and Javascript but not Clojure. Most people don't realize that very often, path to simplicity lies through the thorns of breaking existing habits. They choose an "easy" way. The "way of familiarity." And without even realizing, they usually create more work for themselves.
mnm1 7y ago
If you're learning Chinese, it'll be much less readable than your native language too. This is simply not an argument at all. Once you get used to it, reading clojure is easy. I'd say it's easier than any other language by far. Not only that, once you've worked with clojure you may wonder why all the other languages even bother with their superfluous syntax. At this point, if I had a choice, I would program mostly in clojure. The unnecessary, superfluous, verbose, and often boilerplate of other languages always makes me question why I would use them, write four times the amount of code, and still not get nearly the experience and software quality clojure can provide. I highly encourage you not to judge a language, and language, before actually learning and using it.

User23 7y ago

Lispers read code by indentation, not by scanning parenthesis. Properly formatted Lisp, which is trivially automated thanks to the code being so easily parsed and manipulated, reads pretty much the same as Python. A good editor will shuffle things through the parenthesis based on indentation too, so the experience of writing it is keystroke for keystroke pretty close to Python as well if that's what you want.

iLemming 7y ago

> That’s just for writing though, not reading. I still find lisp code very difficult to read, perhaps not due to parens specifically but more because there is no syntax. Most of us are too familiar with the infix notation. It is deeply ingrained on the subconscious level of our assumptions about programming languages. It is indeed tricky to quickly parse a snippet written in a Lips with an untrained eye. Many software developers with prior experience in programming, at their very first encounter with a Lisp dialect, instinctively try to reject it. It looks unnatural and doesn't feel right. In comparison - most people who never wrote a single line of code ever before, usually don't struggle with Clojure or Racket. However, if one ignores the instinct, persists, and gives it some more time, they may find an incredible world of possibilities. There is a way to speed up the process of adapting to reading and writing Lisp code. The trick of learning to read Lisp code efficiently, is simply refactoring code on the go. Don't try to learn a Lisp dialect by merely staring at code - in books, on web pages, etc. Pick up an IDE or editor that supports Structural Editing. Structural Editing is a way to navigate and refactor your code without breaking parenthesis or other characters that define the structure of your code. Learn basic structural editing commands - slurp, barf, raise, transpose. And modify the code, pick up functions, and try to dissect them. With a connected REPL, Lisp allows you to evaluate any expression without any prior ceremony (a feature that most other languages don't have). You can try every single piece, break up functions into smaller ones, or compose multiple small functions into a bigger one. It doesn't take too long until you see the benefits of this approach. Sadly, for some people going back to normal life, after discovering powers of Lisp becomes like going back to drugs after detoxification. Almost every discussion oh HN about Lisp-dialect results in at least one comment of someone claiming that they've tried writing Lisp for many years but never have "discovered" its powers or even after years it still feels "unreadable" to them. Most of the time, those comments are disingenuous. Lisp does not require anyone to have a "differently wired brain." Nobody comes into this world with the innate ability to read and understand Mandarin better than English or with the ability to be able to learn Python and Javascript but not Clojure. Most people don't realize that very often, path to simplicity lies through the thorns of breaking existing habits. They choose an "easy" way. The "way of familiarity." And without even realizing, they usually create more work for themselves.

mnm1 7y ago

If you're learning Chinese, it'll be much less readable than your native language too. This is simply not an argument at all. Once you get used to it, reading clojure is easy. I'd say it's easier than any other language by far. Not only that, once you've worked with clojure you may wonder why all the other languages even bother with their superfluous syntax. At this point, if I had a choice, I would program mostly in clojure. The unnecessary, superfluous, verbose, and often boilerplate of other languages always makes me question why I would use them, write four times the amount of code, and still not get nearly the experience and software quality clojure can provide. I highly encourage you not to judge a language, and language, before actually learning and using it.