15 ms·

Does anyone find Lisp readable? I haven't used Lisp professionally, but find the code terribly confusing to read (mostly due to the look of it, I assume), whil

• stray 6y ago
  Yes. Lisp is easy to read.
• sanxiyn 6y ago
  Yes I find Lisp very readable.
• abhinav22 6y ago
  You get used to it pretty quickly. Just need a bit of practice. I used to say that proper indenting helps readability but these days I have departed from the standard indenting and do my own thing. That said, this guide on formatting lisp is very useful IMO if you want to learn to read lisp code better: https://link.medium.com/idMRZk93Fdb https://link.medium.com/idMRZk93Fdb I actually wrote it, but now I don’t follow many of its principles :D perhaps because I got a deeper understanding of it. Check it out if and see if it helps
  • blackrock 6y ago
    What is the reason why Lisp allows you to use the hyphen for an identifier name? This overloads the subtraction operator. And it makes the code very confusing to read. And plus, Lisp also uses the hyphen as the subtraction operator.
    • deleted 6y ago
      [deleted]
    • moonchild 6y ago
      It doesn't. Common lisp is a lisp-2, which means that there are 2 namespaces: one for functions and one for variables. (Technically there are quite a bit more, but that's beside the point.) Which means that you can do this: (let ((- 5)) ; bind the '-' variable to 5 (- ; call the '-' function - ; on the '-' variable 17)) ; and the number 17 ; this evaluates to -12
      • ScottBurson 6y ago
        You can. But you shouldn't :-)
        • lispm 6y ago
          this is also possible... CL-USER 5 > (- 1 2 3 4 (third -)) -10
      • kazinator 6y ago
        This is a non-issue for all Lisps, not all of which are Lisp-2. Your code doesn't seem like a very good idea, even though it is legal.
        • moonchild 6y ago
          > Your code doesn't seem like a very good idea Why not? I usually use an 'anaphoric if' macro that binds - to the given value. It seems more clearly 'special' than a name like 'it'—which seems like the canonical name—closer to the perl/raku $_.
    • kleiba 6y ago
      That's more of an issue for languages that use infix notation for operators. Lisp uses prefix notation, that's why a-b is not a problem. As a practitioner, you don't get confused at all when you encounter a variable name that contains a dash, because you don't even read it as a subtraction. Your brain is trained to match only the (- a b) pattern for that.
    • kazinator 6y ago
      C programmers on Unix somehow don't get confused by the POSIX shell: $ foo-bar() > { > echo 42 > } $ foo-bar 42 or Make: OBJ_COMMON := common.o OBJ-$(CONFIG_FOO) += foo.o foo-tab.o OBJ-$(CONFIG_BAR) += bar.o OBJS := $(COMMON_OBJS) $(OBJ-y) even though foo-bar and OBJ-y look like a C subtraction. C programmers on Unix came up with this stuff themselves.
    • lispm 6y ago
      in a more traditional sense Lisp does not have operators by default. Operators which have a special syntax (infix ...) and precedence rules. Operators like + and - are written as normal functions -- thus these characters are allowed in function names. Actually more characters incl. whitespace and returns are possible -> one can escape characters in symbols or whole symbols. There are a bunch of conventions for naming things: +foo+ ; convention for naming a constant *foo* ; convention for naming a special/global variable foo-bar ; convention for a compound name Other programming languages use FooBar, foo_bar or similar, instead of foo-bar. More naming conventions in Lisp are collected here: https://www.cliki.net/Naming+conventions https://www.cliki.net/Naming+conventions
      • abhinav22 6y ago
        Thanks for the link - very useful
    • abhinav22 6y ago
      In my non verified view, it’s easier to type with dashes and looks better than camelCase. Also spaces are used as delimiters, so can’t use them. It’s all preference though. I used to like camelCase when I was learning Java, now I like hyphens. I program both in JavaScript and Lisp and have no issues with both
    • abhinav22 6y ago
      I may be wrong, but one of the benefits of NOT allowing hyphens in names in languages like JavScript is code can be minified (you can remove spaces and use operators as delimiters, which only works if “-“ only stands for subtraction). I think. Haven’t verified this, but the thought came to my head the other day.
      • colonwqbang 6y ago
        There is not a great need to minify many languages other than Javascript. The way I see it, the need arose mainly because it took such a long time to agree on a bytecode representation of JS. I would say that Javascript was not at all designed to be delivered the way that it is. The design characteristics of JS that allow minification, I think are just happy coincidence. Consider that Javascript early on was marketed as a companion to Java (applets). Java, of course, used a bytecode representation to deliver programs on the Web from square one. If Javascript had been designed for efficient delivery of "compiled" programs, bytecode would have been the obvious choice. I think my point is, languages are not generally designed to minify well, because minification is the technique of last resort for efficient delivery.
        • abhinav22 6y ago
          Thanks - this helps expand my knowledge on this topic :)
      • tsimionescu 6y ago
        I think a much bigger consideration would be the utter difficulty of reading something like this: a-b - a - b Even though I personally love hyphenated-identifiers in Lisp, I would not want them in any language that has infix operators, whether it cares about minification or not.
        • kazinator 6y ago
          That could be English written in ASCII, with the same hyphen serving as a dash: Example sentence: "Examples of sado-masochism - such as Java-influenced languages - are rampant in the field of computing." Quite readable.
    • tsimionescu 6y ago
      > What is the reason why Lisp allows you to use the hyphen for an identifier name? Lisp has only ~7 special characters: (, ), #, ', ", ` and wite-space. All others are valid as part of an identifier, alone or together. So for example "---" is a valid Lisp identifier, just as much as "aaa". There is no subtraction operator in lisp. "-" is simply the name of a function in the standard library that implements addition (technically, it might be a special form and not a function, but that's beside the point). > This overloads the subtraction operator. And it makes the code very confusing to read. a-b-c in Lisp is unambiguously an operator. Subtraction would be (- c b a) - you can't really confuse these two. Subjectively, I happen to think that hyphenated-names are much easier to read and type than camelCase or snake_case. I think most of the world agrees as well, since this is one of the more common typographical roles of the hyphen: joining words, such as 'pre-approved' or 'ill-defined'.
    • cat199 6y ago
      Haven't seen anyone mention that "-" is not a function at all. it is a symbol. A symbol which bound to the function which does subtraction. Users are free to redefine it outright, or to redefine it it multiple ways in different scopes of their application. (Not sure how wise this would be, but not really the point ...) Not to be offensive, but the question as written seems to imply looking at lisp from preconcieved notions from other languages that probably don't make sense to carry over in understanding lisp.
• sillysaurusx 6y ago
  One thing about Lisp: it's a set of languages within a language. Whether you understand it depends on which of the sublanguages you're reading. `loop` has its own special conventions. People write macros. And so on. I recommend giving it a shot solely for the fun of it. It's worth the payoff, even if it takes awhile.
• pjmlp 6y ago
  Yes, func(arg) becomes (func arg). Yes there are lots of parentheses, just like there are lots of ampersand, asterisks, curly and square brackets on C derived languages.
• tsimionescu 6y ago
  Yes, I personally find it pretty easy to read, even though I've only used it as a hobby. The only problems I have are when I'm trying to debug something in macro code, where it becomes too hard to intuitively follow the layers of quoting and unquoting to understand what's going on.
• brabel 6y ago
  I find it very hard to read. The reason is that it almost completely lacks demarcation between different things. Expressions should be readable in a single flow. Lisp breaks that. For example: (+ (* 5 3) (* 3 2)) This is not easily readable because there are breaks in the "flow". You need to go like: * `+` is going to add things together * oh, there's a nested expression here, pause... * `` is multiplying 5 and 3 - cool, back to the previous thing. oh, another nested thing. * `` is multiplying 3 and 2 - back again... done... so where were we? Here's how a readable expression would look like IMO: (5 * 3) + (3 * 2) This reads very naturally: * 5 times 3 - 15, ok go on... * nested expression... hm, ok. * 3 times 2 - 6, let's go back now... * ah right, 15 + 6 is 21... done. Alternatively: 5 3 * 3 2 * + * take 5 and 3, multiply: 15 * take 3 and 2, multiply: 6 * add them together: 21 Which is what FORTH does. This is almost perfect, but a little hard for humans to follow (though this is exactly what machines want to do) because you still need to keep the stack of values in your head. I've been studying about this and came up with something in the middle: (5 * 3) (3 * 2) + This has the advantage that you the distance from the values in the stack to the point of reading when going left-to-right is optimal: there is no better way to represent this if your objective is to avoid intermediate values. It is similar to FORTH, but optimized for humans to read instead of machines: * `5 * 3` is 15. * `3 * 2` is 6. * `+` the values, which are 15 and 6: 21. The parens are not required if you use some alternative syntax to mark boundaries, for example: 5 * 3 >> 3 * 2 >> + ; The `>>` is used to "pipe" the value to the next expression, while `;` is used to terminate the expression. This also has the benefit of showing the reader the direction of the flow.
  • lispm 6y ago
    (5 * 3) + (3 * 2) That's not that great, since it uses infix precedence - either explicitly (here) or implicitly. I need to read into it to understand that a sum is computed and I need to then find out the boundaries of the subexpressions. But the brain can be trained for that, just as it can be trained to read Lisp, Erlang, or even APL code. Nested lists are the base for Lisp syntax. Thus numeric code is just like other ordinary code. Lisp was developed to also do symbolic computations: computing with expressions with symbols. Thus to read Lisp you need to learn to read syntax based on nested lists and then numeric expressions are just an application of that. Still one is trained to do math with lot's of fancy syntax - fancy syntax you won't find in normal code anyway. For example the typical graphical root notation is mostly not found in programming languages. If I (as a Lisp programmer) had problems understanding numeric expressions, I'd reformat them: (+ (- a b) (* 100 (sqrt y) x) (* 50 (expt x 2))) as (+ (- a b) (* 100 (sqrt y) x) (* 50 (expt x 2))) That's just another way to format a nested list. The main problem is mapping that back to existing external forms which uses mixed infix/prefix/postfix syntax. (a - b) + (100 * y^1/2 * x) + (50 * x^2) Lisp allows one to compute this stuff: CL-USER 18 > '#i( (a - b) + (100 * y^^(1/2) * x) + (50 * x^^2) ) (+ (- A B) (* 100 (EXPT Y (/ 1 2)) X) (* 50 (EXPT X 2))) CL-USER 19 > (let ((*print-right-margin* 30)) (pprint *)) (+ (- A B) (* 100 (EXPT Y (/ 1 2)) X) (* 50 (EXPT X 2)))
• eska 6y ago
  I use a rainbow parentheses addon for my editor. Makes stuff readable even when on a single line.
• jonathanstrange 6y ago
  Readability and maintainability are pretty much the only reasons why I wouldn't recommend Lisp for everything. Other than that, Common Lisp has had practically all features you could desire for decades already. It's not a problem with the syntax, though. The problem is that Lisp is so powerful that programmers can and will create very high level abstractions, the language and conventions encourage it, but a side effect of this is that every part of a program has its own DSL. If in addition there is not good enough documentation or a programmer has a knack for obscure elegance over KISS, then this becomes problematic. In a nutshell, it's perfectly possible to write clean and easy to read Lisp but not many people do it. Edit: I forgot to say that the code from Mezzano looks like a positive example of readable and clear-cut Lisp code.
  • nonsince 6y ago
    I completely agree, and it’s also a problem that other immensely powerful languages like Ruby and C++ have but Lisp has it far worse since A) the more arcane abstraction features are more immediately accessible from day one of writing Lisp code and B) the culture of Lisp code is far more obsessed with elegance and with twee little tricks than with readability or simplicity. It’s not a necessary issue that Lisp dialects have though: Common Lisp seems to be better as far as culture goes, and Racket has both a more simplicity-focussed code culture and the tools to make the arcane and elegant abstractions easier to understand.
• Jach 6y ago
  Yup. Time to refer to this image again I guess: https://www.thejach.com/imgs/lisp_parens.png https://www.thejach.com/imgs/lisp_parens.png (Though that's technically Scheme -- I find Common Lisp more readable and encouraging of smaller functions and modularity. The clean code culture of tiny functions and unit tested everything is not there, though, and a lot of stuff is done by individuals so the benefits of code review aren't often captured.)
• tartoran 6y ago
  After spending about a year toying with LISPs I find lisp prefix notation much more readable, intuitive and useful. Think about adding a bunch of numbers using infix a+b+c+d In prefix it’d look like (+ a b c d) You could as many terms in that list. And as far as the - in indentifiers, it’s called kebab case and I find it very readable and natural to type as well. Also since identifiers are a lot more flexible than other languages you could have predicates such as empty? Rather than isEmpty and so on. Very very friendly and useful. Not trying to convince you or anything but if you give it a chance it’ll click for you.
  • ape4 6y ago
    Well, I can understand (+ a b c d) Its the next level where it gets hard.
    • tartoran 6y ago
      What is that, macros? Hygienic macros? Higher order functions? Recursion? I find that having such a simple syntax everything is grokkable much easier than in other languages. Having said that, I prefer scheme and racket which are much more simplified than common lisp and don’t contain so many warts.
      • MaxBarraclough 6y ago
        To someone who isn't immersed in the Lisp world, Lisp syntax often looks ((((something (like) this) and) seems)) utterly impenetrable compared to a more 'conventional' syntax. It's the reason for the snarky backronym, Lost In a Sea of Parentheses. Forth, another language with a spartan approach to syntax, gets similar criticism.
        • betterunix2 6y ago
          Kind of like saying C often(looks{something{like->this;}});
          • 6y ago
• betterunix2 6y ago
  I find Lisp to be at least as readable as anything else, and much more readable than C++. The syntax is different from other languages but that is not a problem once you are comfortable with Lisp syntax. Lisp syntax and semantics almost always mean that there is less need to work around annoying and brittle aspects of the language, and so the code you are reading tends to be more relevant.
• word8 6y ago
  Readability in any language basically comes down to whether the programmer formatted his code in a non-malicious way (which is the case 99% of the time) and used variable names you are familiar with. I'd be more worried about the meta constructs in Lisp (and whether they are sound). To be able to reason semantically about a program is something that is made easier by static typing and static name resolution. Instead of constantly worrying that X is not defined where you think it is (because some dynamic binding system has yet another edge case you forgot to think about or discover), you just always know where it's defined.