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.
> 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.
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.
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.
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
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.
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
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.
>when you do the same in other languages you get...
Your result should be unsurprising. Lisps have a minimal syntax that naturally entails high levels of nesting: (s-)expressions being used to represent functions, control structures, data, etc.
Why should a particular style convention appropriate for that kind of language necessarily transplant well to JavaScript-- a brace-delimited, Algol-inspired language with a lot of syntax?
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.
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.
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.
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))))
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.
Yet most Python code is written in the compact form I've showed you, where code indentation is significant. Lisp has the same model: the code indentation is significant. But Lisp has the structure encoded in nested lists. These nested lists are automatically formatted in the same space saving way as Python code. Due to the significant indentation, Python usually can avoid to have grouping characters/symbols.
I see also lots of Python code where data isn't written like you claim...
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.
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.
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.
It is very common for programmers who are new to Lisp to close their parentheses in the former style. However, it is a crutch that they soon do away with if they stick to the language for any length of time.
The first option has both opening and closing brackets on their own lines, while the second has neither. Note that I consider the function name to be part of the opening bracket since it's distinct from the parameters.
which looked really weird to me first but I’ve found it to improve legibility a lot. (Of course there’s a reason it’s idiomatic in Haskell and not elsewhere.)
That the expression is ended I can see in the typical Lisp expression because of the block structure. The single parentheses does make the layout very cluttered and visually ugly. It gets even worse in typically larger Lisp code or data.
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.