7 ms·

> I have to admit, that at the beginning using brackets was not easy for me. Once I’ve realized that the brackets are just on the other side of the function nam

> I have to admit, that at the beginning using brackets was not easy for me. Once I’ve realized that the brackets are just on the other side of the function name, everything was simple and I could code very fast. Yeah, having automated insertion of brackets/parenthesis is necessary to adopt, otherwise you find yourself annoyed very quickly. Once you've adopted to automatic insertion of that, it's hard to go back to language where you don't have that...

Swizec 7y ago
This is what drove me away from lisp. If everyone says you have to use a plugin to auto-insert parentheses, that means computers know where they go. So why are we writing them??
- azhenley 7y ago
  Try Forth :)
- wtetzner 7y ago
  The computer only knows where they go because the rest of the code already has the parens. Having the parens has advantages, like everything being explicitly delimited, which makes it really unlikely that you'll insert some code that you thought was part of a block, but really wasn't (think one-armed if without braces in C-like languages). It also makes it easy to have your editor help you navigate your code. Being able to jump around expressions conveniently can really speed things up.
- Skunkleton 7y ago
  The computer doesn’t know. It just knows that brackets need to go somewhere and makes it easier to edit them as a pair.
- mschaef 7y ago
  They make the extent of syntactic expressions more obvious to both people and tools.
- capableweb 7y ago
  Because they are not perfect and you need control of where they go. They don't always get it right and you might have to correct them. At least none of the solutions I've found been 100% perfect. So I much rather have the computer do as much as it can, then I correct if it gets it wrong. Collaboration with the machine is better in this case.
- tpfour 7y ago
  Not everyone uses plugins. I don't have autocomplete but my parens flash when they're paired. I like it. You write the parentheses because they have meaning. I can understand your frustration but I don't think you gave lisp a fair chance if you are asking "why parens". > '(this is a list) > this is a list These don't have the same meaning. The computer can't know what meaning you want to give to the code beforehand.
- lukifer 7y ago
  I've never spent any serious time with Clojure/Lisp, and the nested parens have been a pretty major impediment. I'm curious if anyone's ever experimented with dialects that replace brackets with significant whitespace (newline+tabs), similar Python? I could also see a drag-and-drop coding GUI being pretty powerful. I'm sure once one spends enough time with it, one starts to think in Lisp, and the desire to solve the "problem" disappears. :)
  - vnorilo 7y ago
    Indeed. I came from C++, but I quite like homoiconic syntax by now. There have been alternative syntaxes [1] but their lack of popularity seems to align with your hypothesis. 1: https://dwheeler.com/readable/ https://dwheeler.com/readable/
  - zdragnar 7y ago
    Significant whitespace typically denotes blocks of statements or expressions. How do you use whitespace to represent a data structure? After all, the whole point is that literally everything, code included, is a list. (Edit: if all you want is homoiconicity, grab prolog, rebol or julia) There are plenty of non-paren functional and OO languages (f#, haskell, python, java) to replace functional and OO lisps depending on the itch you want to scratch. JavaScript has babel / babylon to generate a full AST to rewrite source code, though you need to either fork babylon or use sweet.js if you want your own macros.
    - lvass 7y ago
      >How do you use whitespace to represent a data structure? SRFI-49[0] describes I-expressions, which can be mixed with S-expressions. I've tried it while learning Scheme, because parens didn't look good at first. My experience was that parens are an issue only until you get used to them, afterwards they're a boon. [0] https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html
  - tpfour 7y ago
    You never spent much time with it and the parens are a major impediment? If you cannot overcome the "parens" (non) issue, I suppose the language is not for you. It really is not an issue, _at all_. I don't say this to be demeaning! I would say there are far more chances you really enjoy the language than not. Give it a try and stop worrying about the parenthesis and start thinking in terms of an AST. (let ((x 0)) (+ x 1)) If you want Python that's fine but there is definitely no problem with parens in Lisp/Scheme :)
- ken 7y ago
  Lisp doesn't have more grouping characters than other languages. The primary difference is that it consistently uses prefix notation, so the cursor always immediately goes inside the parens, rather than needing to type one part of an expression (the function name) outside of it first. That's what modes like paredit help with. Programmers in languages like Ruby (optional parens for method calls) and Tcl (no parens for proc calls) might agree with you! Why does virtually every language require parens, when they're not needed? At least with Lisp, they serve a necessary purpose. Another one: almost every language uses commas to separate items in a list, including function arguments. In the vast majority of cases, the commas are useless. Lisp doesn't use commas to separate elements (though Clojure allows them if that's your druthers). Why can't I say f(x y) or [3 4 5] in, say, Python? There's nothing else it could possibly mean.
draw_down 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. 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.
Plugawy 7y ago
I'm not sure to be honest, I've been working with Clojure for 5 years now, and the only "help" I get from the editor I get is "highlight matching pair". I never got used to automatic paren insertion or things like paredit.
- yogthos 7y ago
  I really recommend just forcing yourself to use it for a week or so. You just have to switch your mindset to the opening paren being a control character for starting an expression. I just don't look at the parens at all when I work with Clojure.
- eigenhombre 7y ago
  To build on what yogthos writes here, Paredit was an absolute game changer for me. The ability to edit your code as a tree structure rather than just a sequence of characters lets you do many kinds of edits far faster than is possible in non-parentheses-laden languages. The following are all a single key combination in most editors that support Paredit or equivalents: - Kill an entire loop or data structure to the right of the cursor - Swap two deeply nested expressions to the left and right of the cursor - Absorb ("slurp") or expel ("barf") expressions to either side of your current expression, into that expression - Delete the entirety of the expression enclosing where your cursor is, leaving everything to the right intact but raised to the enclosing level (this one is amazingly common but you would never think to use it until someone shows it to you, after which you use it every day) It takes a couple of days to get these and many other shortcuts into your fingers, after which it's hard to live without them. http://emacsrocks.com/e14.html http://emacsrocks.com/e14.html is a good introduction. Structural editing is the first thing I miss going back to Python, Ruby, JavaScript, etc. That, and, of course, instant REPL evaluation of the expression under my cursor.
agumonkey 7y ago
true, as much as I like lisp, without automated pairs (not even asking for paredit) I go insane fast. that said paredit should have a statue on the moon or something

Swizec 7y ago

This is what drove me away from lisp. If everyone says you have to use a plugin to auto-insert parentheses, that means computers know where they go. So why are we writing them??

azhenley 7y ago
Try Forth :)
wtetzner 7y ago
The computer only knows where they go because the rest of the code already has the parens. Having the parens has advantages, like everything being explicitly delimited, which makes it really unlikely that you'll insert some code that you thought was part of a block, but really wasn't (think one-armed if without braces in C-like languages). It also makes it easy to have your editor help you navigate your code. Being able to jump around expressions conveniently can really speed things up.
Skunkleton 7y ago
The computer doesn’t know. It just knows that brackets need to go somewhere and makes it easier to edit them as a pair.
mschaef 7y ago
They make the extent of syntactic expressions more obvious to both people and tools.
capableweb 7y ago
Because they are not perfect and you need control of where they go. They don't always get it right and you might have to correct them. At least none of the solutions I've found been 100% perfect. So I much rather have the computer do as much as it can, then I correct if it gets it wrong. Collaboration with the machine is better in this case.
tpfour 7y ago
Not everyone uses plugins. I don't have autocomplete but my parens flash when they're paired. I like it. You write the parentheses because they have meaning. I can understand your frustration but I don't think you gave lisp a fair chance if you are asking "why parens". > '(this is a list) > this is a list These don't have the same meaning. The computer can't know what meaning you want to give to the code beforehand.
lukifer 7y ago
I've never spent any serious time with Clojure/Lisp, and the nested parens have been a pretty major impediment. I'm curious if anyone's ever experimented with dialects that replace brackets with significant whitespace (newline+tabs), similar Python? I could also see a drag-and-drop coding GUI being pretty powerful. I'm sure once one spends enough time with it, one starts to think in Lisp, and the desire to solve the "problem" disappears. :)
- vnorilo 7y ago
  Indeed. I came from C++, but I quite like homoiconic syntax by now. There have been alternative syntaxes [1] but their lack of popularity seems to align with your hypothesis. 1: https://dwheeler.com/readable/ https://dwheeler.com/readable/
- zdragnar 7y ago
  Significant whitespace typically denotes blocks of statements or expressions. How do you use whitespace to represent a data structure? After all, the whole point is that literally everything, code included, is a list. (Edit: if all you want is homoiconicity, grab prolog, rebol or julia) There are plenty of non-paren functional and OO languages (f#, haskell, python, java) to replace functional and OO lisps depending on the itch you want to scratch. JavaScript has babel / babylon to generate a full AST to rewrite source code, though you need to either fork babylon or use sweet.js if you want your own macros.
  - lvass 7y ago
    >How do you use whitespace to represent a data structure? SRFI-49[0] describes I-expressions, which can be mixed with S-expressions. I've tried it while learning Scheme, because parens didn't look good at first. My experience was that parens are an issue only until you get used to them, afterwards they're a boon. [0] https://srfi.schemers.org/srfi-49/srfi-49.html https://srfi.schemers.org/srfi-49/srfi-49.html
- tpfour 7y ago
  You never spent much time with it and the parens are a major impediment? If you cannot overcome the "parens" (non) issue, I suppose the language is not for you. It really is not an issue, _at all_. I don't say this to be demeaning! I would say there are far more chances you really enjoy the language than not. Give it a try and stop worrying about the parenthesis and start thinking in terms of an AST. (let ((x 0)) (+ x 1)) If you want Python that's fine but there is definitely no problem with parens in Lisp/Scheme :)
ken 7y ago
Lisp doesn't have more grouping characters than other languages. The primary difference is that it consistently uses prefix notation, so the cursor always immediately goes inside the parens, rather than needing to type one part of an expression (the function name) outside of it first. That's what modes like paredit help with. Programmers in languages like Ruby (optional parens for method calls) and Tcl (no parens for proc calls) might agree with you! Why does virtually every language require parens, when they're not needed? At least with Lisp, they serve a necessary purpose. Another one: almost every language uses commas to separate items in a list, including function arguments. In the vast majority of cases, the commas are useless. Lisp doesn't use commas to separate elements (though Clojure allows them if that's your druthers). Why can't I say f(x y) or [3 4 5] in, say, Python? There's nothing else it could possibly mean.

draw_down 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. 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.

Plugawy 7y ago

I'm not sure to be honest, I've been working with Clojure for 5 years now, and the only "help" I get from the editor I get is "highlight matching pair". I never got used to automatic paren insertion or things like paredit.

yogthos 7y ago
I really recommend just forcing yourself to use it for a week or so. You just have to switch your mindset to the opening paren being a control character for starting an expression. I just don't look at the parens at all when I work with Clojure.
eigenhombre 7y ago
To build on what yogthos writes here, Paredit was an absolute game changer for me. The ability to edit your code as a tree structure rather than just a sequence of characters lets you do many kinds of edits far faster than is possible in non-parentheses-laden languages. The following are all a single key combination in most editors that support Paredit or equivalents: - Kill an entire loop or data structure to the right of the cursor - Swap two deeply nested expressions to the left and right of the cursor - Absorb ("slurp") or expel ("barf") expressions to either side of your current expression, into that expression - Delete the entirety of the expression enclosing where your cursor is, leaving everything to the right intact but raised to the enclosing level (this one is amazingly common but you would never think to use it until someone shows it to you, after which you use it every day) It takes a couple of days to get these and many other shortcuts into your fingers, after which it's hard to live without them. http://emacsrocks.com/e14.html http://emacsrocks.com/e14.html is a good introduction. Structural editing is the first thing I miss going back to Python, Ruby, JavaScript, etc. That, and, of course, instant REPL evaluation of the expression under my cursor.

agumonkey 7y ago

true, as much as I like lisp, without automated pairs (not even asking for paredit) I go insane fast. that said paredit should have a statue on the moon or something