6 ms·

Most well-written Lisp code has its structure indicated primarily by the indentation. Some form of offset rule is the most commonly suggested alternative Lisp

• Jensson 4y ago
  > ))))) You could stack them like this in every language but only in Lisp do people actually do it. Lisps bad habbit of stacking all the parentheses like that is what makes it so hard to read. It is easier to write that way, but it is very hard to understand how many contexts up you just moved.
  • lvass 4y ago
    Not with proper indenting, or rainbow-delimiters/show-paren-mode.
    • Jensson 4y ago
      I don't buy that, when you do the same in other languages you get: for (var i = 1; i < 101; i++) { if (i % 15 == 0) { console.log("FizzBuzz");} else if (i % 3 == 0) { console.log("Fizz");} else if (i % 5 == 0) { console.log("Buzz");} else { console.log(i);}} Why do you think nobody other than lispers writes code like this? Is it really necessary to write code that way? If it is better, why not does nobody else do it? They can also use colored bracers and tooling, while lispers has written code that way forever. I'm sure a big reason people call lisp a "write only language" is because of this strange convention of stacking all parentheses in a big clump instead of formatting like normal.
      • aGHz 4y ago
        Do you want Python? Because this is how you get Python. Joke aside, this is why I never understood this problem. With proper indentation it looks essentially like Python with a generous helping of your-father's-parentheses.
      • na85 4y ago
        I used to feel the same way but lisp gets easier to read with practice, and unless you're writing code in notepad.exe or nano or something, your editor will show you the matching paren.
      • lvass 4y ago
        IMO, because C syntax sucks and makes people actually take time to read and interpret the brackets. In erlang and I think others people don't newline between closing delimiters either. In lisp the brain processes the parens automatically.
      • wtetzner 4y ago
        Who calls Lisp a "write only language" other than people who don't know Lisp?
        • lispm 4y ago
          There is the classic Minsky quote: “Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.”
      • lispm 4y ago
        Yet, for Python the layout is like above, with indentation being significant: for i in range(1, 101): if i % 15 == 0: print("FizzBuzz") elif i % 3 == 0: print("Fizz") elif i % 5 == 0: print("Buzz") else: print(i) It does not need the {} pairs then. Now, are we lost because the {} pairs are missing? In Lisp you need to learn to apply the same idea of indentation being significant: (loop for i from 1 upto 100 do (cond ((zerop (mod i 15)) (write-line "FizzBuzz")) ((zerop (mod i 3)) (write-line "Fizz")) ((zerop (mod i 5)) (write-line "Buzz")) (t (write-line (princ-to-string i))))) Just imagine the grouping parentheses are not there. The disadvantages of Lisps are basically two: a) there are more parentheses because of the nested lists being used to write code b) one now needs to understand when (sin a) is actually code and when it is data. The advantage of Lisp syntax: a) code is already a simple nested data structure b) the indentation&layout of code can be (and often is) computed from the data, while usually in Python the lines and indentation are significant
  • daptaq 4y ago
    But why would you care about those trailing parentheses?
    • Jensson 4y ago
      Readability. By properly indenting the parentheses and putting them on lines you will at a glance see which contexts you just closed, that is how people format code in every mainstream language.
      • CraigJPerry 4y ago
        With lisp is it not more common to use paredit or similar? I.e. you don’t edit code like in other languages. As you barf and slurp, you’re interested in the “shape” of code but you ignore the parens.
      • lispm 4y ago
        None of these 'mainstream' languages use a data structure for writing and manipulating code like Lisp. The use of Lisp is thus very different and Lisp programmers find a more compact notation more useful. > you will at a glance see which contexts you just closed the text editor does that for me > how people format code in every mainstream language Python code formatting looks different from Java code formatting. Python code: for h in range(0, height): for w in range(0, width): v = bw_image.getpixel((w, h)) if v >= avg: bm_image.putpixel((w, h), white) else: bm_image.putpixel((w, h), black) Lisp code just looks like that. Only with added parentheses (because Lisp expressions are written as nested lists) and prefix notation: (dotimes (h height) (dotimes (w width) (setf v (get-pixel bw-image w h)) (if (>= v avg) (put-pixel bm-image w h while) (put-pixel bm-image w h black))))
        • Jensson 4y ago
          Python also formats their parentheses the non lisp way. You typically format things like this: data = [ [1, 2, 3], [4, 5, 6], [7, 8, 9, [10, 11, 12]] ] Any language that uses closing symbols formats them that way, in Pyhton in Java, in C etc. Lisp is the only example where they don't properly indent closing symbols and instead just put them all together at the last statement.
  • lispm 4y ago
    It's not a bad habit. It's just more practical. Lisp lists are a data structure. One for example types code&data and computes with an interactive Read Eval Print Loop. That's what one would write: CL-USER 35 > (+ (expt 23 2.4) (sin (* 44 0.23 22))) 1854.5603 No one would type: CL-USER 36 > (+ (expt 23 2.4) (sin (* 44 0.23 22 ) ) ) Also when Lisp deals with s-expressions, the more compact notation is more useful: here Lisp does the layout itself: CL-USER 46 > (let ((*PRINT-RIGHT-MARGIN* 30)) (pprint '(+ (EXPT 23 2.4) (SIN (* 44 0.23 22)) (COS (+ 12 0.43 19.0)) (TAN (/ 1.4 0.77 3/4))))) (+ (EXPT 23 2.4) (SIN (* 44 0.23 22)) (COS (+ 12 0.43 19.0)) (TAN (/ 1.4 0.77 3/4))) It's not (+ (EXPT 23 2.4 ) (SIN (* 44 0.23 22 ) ) (COS (+ 12 0.43 19.0 ) ) (TAN (/ 1.4 0.77 3/4 ) ) ) Above is much harder to read and wastes a huge amount of space on the screen. Imagine that lists of are much longer and deeper nested. Finding the corresponding parentheses is usually done by using the editor (select a whole expression, have blinking or colored parentheses, etc.). The main difference between Lisp and most other programming languages is that programs are written as a data structure: nested lists. Not only that: they are not static lists, but we can compute with them - that's the main appeal. It's a programming language, where it's easy and common to manipulate lists, even programs as lists. Thus the notation has not only be useful for reading code, but also for input/output by humans and programs. There a compact notation is much more useful, since tools will often create huge amounts of nested lists. For example imagine a macro for some Lisp functionality, like a complex loop expression. The macro expanded code can often be ten times larger as the input expression, yet we may want to see it in a debugger -> write that expression in a compact way. I let Lisp indent my code and the system-wide standard indentation makes it easier to spot parentheses errors, since all code has the same shape rules. (progn (case foo (var (eval foo))) (fn (apply foo args))) Since all code gets indented during typing, I can easily see that there is one parenthesis too much in the first case clause... I wouldn't care to see the parentheses aligned and it makes the problem often more difficult to spot: (progn (case foo (var (eval foo ) ) ) (fn (apply foo args ) ) ) I want the expressions to use less vertical space, so that I can see that the opening parentheses of the CASE clauses align. Anything else is just visual clutter.
    • 4y ago
  • User23 4y ago
    Sounds like a good opportunity to oil up Chesterton’s fence. You may want to consider the possibility that the conventions Lispers have been using for considerably longer than C or whatever language you like to bikeshed style guides in has existed were actually settled on for pragmatic reasons. You’re not alone though. Many nascent Lispers go through the use reader macros to make Lisp look more like what they’re used to phase.
    • Jtsummers 4y ago
      Not just nascent Lispers. I inherited something like this in a C codebase before (several times, actually, only one that I had to actually edit though): #define BEGIN { #define END } #define INTEGER int ... Yes, they even did it with the types. Made for a weird Pasctran language that the dev was apparently more comfortable with. I think they actually got a C translation of another program almost "for free" doing this. The real thing was they didn't want to write new code and didn't want to learn C, so they subjected everyone after them to this horror. Moral of the story: If you can't be bothered to learn a language and its conventions, be honest and get another job.
      • retrac 4y ago
        Pasctran is an ancient cult. [1] Some say they're extinct. Others say its practitioners have just gone underground, now that society will no longer tolerate such things done in public. It's everywhere once you start looking though, insidiously contaminating our precious function bodies. From the source to the original Bourne shell: BEGIN REG BOOL slash; slash=0; WHILE !fngchar(*cs) DO IF *cs++==0 THEN IF rflg ANDF slash THEN break; ELSE return(0) FI ELIF *cs=='/' THEN slash++; FI OD END [1] https://research.swtch.com/shmacro https://research.swtch.com/shmacro
        • mikewarot 4y ago
          As an old Pascal programmer who never really liked C.... even I have to say NO!!!! What a horrible thing to do. I've never liked macros, and things like this are part of the reason why.
  • wtetzner 4y ago
    > Lisps bad habbit of stacking all the parentheses like that is what makes it so hard to read. How much Lisp have you written/read? Closing parens on separate lines would be a nightmare to read in any real-world code. Also, what makes Lisp hard to read is lack of familiarity. It's not like C is easy to read for someone who's only ever written Lisp. Lispers don't find Lisp hard to read.
  • zozbot234 4y ago
    There is a real drawback to stacking more than three or four closing parens like this, without spacing them out: it's hard and in fact impossible to count them at a glance. Not an issue if you have a code editor with auto paren matching, but it can be an annoyance when reading LISP-like code on the web or elsewhere.
    • actually_a_dog 4y ago
      > it can be an annoyance when reading LISP-like code Just mentally collapse any number of consecutive close parens into a thing that reads like "END."
      • lispm 4y ago
        In Interlisp one would write a super parenthesis, which closes all open parentheses, upto an opening [ or the top ( : (a (b c (d ] and also (z (a [b c (d] [e f (g]]
  • jimbokun 4y ago
    Nah, you just rely on the indentation to understand the structure, just like every other language.
  • kazinator 4y ago
    > but only in Lisp do people actually do it That is false. Do yourself a favor and run "git grep -F ')))))' in, oh, the root of the Linux kernel tree.
• amelius 4y ago
  To be consistent, I think the first part should be indented like this: define pos>? p1 p2 (p1 and p2 on separate lines)
• bryanlarsen 4y ago
  And if anybody is interested in a well developed alternative Lisp syntax in this manner: https://readable.sourceforge.io/ https://readable.sourceforge.io/
  • bmitc 4y ago
    I have always felt SML and F# are basically statically typed Lisps/Schemes without parentheses.
  • retrac 4y ago
    Unfortunately, as with all standards, there's so many wonderful alternatives to choose from. I rather like Wisp: https://www.draketo.de/software/wisp https://www.draketo.de/software/wisp I wish all languages had the : operator that Wisp has. It's $ in Haskell. It simply says that what follows to the end of line is wrapped in brackets. So: putStrLn $ somefunc $ process val = putStrLn (somefunc (process val)) Like a UNIX pipe, but moving to the left.
    • amelius 4y ago
      Instead of $ they could have used ¢, since it looks more like an opening bracket.
      • ablob 4y ago
        There aren't too many keyboards with a ¢ key included, so I suppose that alone could be a show stopper.
        • 3836293648 4y ago
          They definitely didn't care about that. No language that uses ` , the most painful common character to write on most non-US keyboards put any consideration into that.
          • Eavolution 4y ago
• actually_a_dog 4y ago
  > The left looks a lot like a typical AST for many languages.... Right, and this is what's meant by the oft-repeated statement "LISP has no syntax." Of course it has syntax in the sense that if you were to go in and delete one of those parens, the whole thing wouldn't compile, but the syntax it does have is 100% regular.
  • Banana699 4y ago
    Who cares? Assembly is regular*, very much so. There is a single control flow construct, in conditional and unconditional flavors. There is a single language construct, of which the single control flow construct is but a special case. Code is Data and Data is Code. Everything is possible. You don't need regularity or simplicity, you need automation. Programming Languages are tools to under-specify a problem\process\pattern\solution\structure and still get an executable that does something useful, meaning the parts that weren't specified were filled in by the machine (in any way necessary), meaning automation. In other words, "A low level programming language is that which requires attention to the irrelevant", per Alan Perlis. In that light, lisp's syntax is awful, you're laying down the AST yourself instead of making a parser figuring it out from program text. You're paying precious attention to the extremely irrelevant, the fact that a function's body is nested under its name, the fact that a control construct wraps its code, instead of letting those trivial facts fade into the background of a nicely-designed grammar and actually focus on the code itself. There is literally 0 need for making code-as-text reflects code-as-tree, Mathematica represents every single language construct as a nested list underneath, and yet it has an extremely rich and pleasant syntax, full of sugar and shortcuts and alternate forms. It can do this because it understands a very fundamental point that lisp syntax fans too often miss : text is irrelevant. The string "(+ (* 4 10) 2)" is not an S expression, its the textual form of an S expression, the serialized form. You can't do anything useful with it without parsing, the actual S expression is a hierarchical object graph in memory, you can either get it from the text by quoting the text, or immediately evaluate it by entering the text directly into an interpreter (which gets the tree first). In all cases, there is no reason why quoting `while (cond) {exprs}` can't evaluate to the list (while cond (exprs)). You are already parsing the text anyway, quote is nothing but invoking the parser from within a program, so make the textual form convenient to humans while you're at it, a simplistic form benefits no one but the parser (a machine, the very thing that needs to work hard). Lisp's big idea is just making the compiler's services available through an easy API, this has absolutely nothing to do with its crippled syntax, it can be done by any language of any syntax whatsoever, much better than the 1960s hack lisp fans has stockholm-ed themselves into loving. To the extent it's rarely done in mainstream languages, it reflects the designers' choice. * : I'm assuming a remotely sane ISA, not the excrement known as x86.