So many brackets. Resolving mismatched brackets seems to be just about the most pointless developer activity possible.
If you edit s-expressions as data structures using something like paredit you'll actually code very quickly, and it'll also be impossible to have unbalanced parens.
Say you have this (| = cursor): (a b |c d)
If you type ( you get balanced parens: (a b ()| c d)
If you press Ctrl+Right twice you slurp in c and d: (a b (c| d))
If you then press Alt+Up you get back to: (a b c| d)
As you can see, you manipulate code on the level of data structures instead of manually placing parentheses, and you are actually prevented from making unbalanced parens in paredit. You can likewise move through code in ways similar to moving by word or paragraph in vim vs moving by character, but I only showed basic editing above.
I won't downvote you because I understand your complaint. But the problem is that you are unaware that you are using the wrong mode of editing for s-expressions. :) It's like editing photo using a hex editor: possible, but very much suboptimal.
Let's all just use Forth, and implement washing machines as simply as:
: WASHER WASH SPIN RINSE SPIN ; (print "hello")
print("hello")
main = putStrLn "hello"
And that's just talking about syntax. The type system complicates matters further.
(-b + sqrt(b*b - 4*a*c)) / (2*a)
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a))
Nobody in their right mind uses this stuff in production code.
It just overcomes objections. "Oh, if I start using Lisp, there is be a way to use infix, should I really need it". Ten years and six Lisp project later, you still haven't used the infix stuff; the situation never comes.
You sure about that? I thought the lispy approach was generally pragmatic - you use what you deem handy for your application. It this weren't the case, there would be little need for macros in the first place. I can very well imagine, say, a scientific or engineering application that would share a common infix parser for both user-provided expressions (in the UI, to be more friendly to non-lispers) and heavy math lifting in the source code.
{-(b) + {sqrt((b * b) - (4 * a * c)) / (2 * a)}}Yes, and the first line's use case depends on the language built-in operator precedence rules to reduce the number of parens.
If you are using math formulas as an example of minimal paren usage, go with APL and have even fewer since all operators are equal precedence and associate to the right.
If you really wanted to write the quadratic formula (or math formulas in general) you could use APL and use even fewer.
b fnegate b b f* 4 a c f* f* f- fsqrt f+ 2 a f* f/1.
(/ (+ (- b) (sqrt (- (* b b) (* 4 a c))))
(* 2 a))
(/ (+ (- b)
(sqrt (- (* b b) (* 4 a c))))
(* 2 a))
(/ (+ (- b)
(sqrt (- (* b b)
(* 4 a c))))
(* 2 a))
(/ (+ (- b)
(sqrt (- (* b
b)
(* 4
a
c))))
(* 2
a))
Infix turns into a mess breakfast when it's too long for one line.
For this particular expression, I'd probably go with variant (3) in production code. Compared to the beauty of (3), the original one-liner is basically a strawman. In terms of clarity of structure, it trumps the infix also.
This is actually a very important point that is overlooked by Lisp noobs. In real Lisp code, expressions are not written all out in one line, whereby the human reader must mentally match the parentheses. Even numeric expressions that might be one-liners in Fortran or C, are split across several lines to make at least the major constituents clear in relation to the major operator.
Indeed. If you want less parens, use Haskell or Forth.
Furthermore, Lisp uses zero parentheses for grouping in order to override precedence. These parentheses don't exist in Lisp.
In print(2/(2+4)), we actually have two kinds of parentheses, because two different grammar rules use the same token.
C has even more parentheses. The parentheses in for (;;) are not the same as those in 2/(2+4) which are not the same as those in (double) p, which are not the same as those in p(42).
Lisp has parentheses that do one darn thing in the read syntax---at least when they are not literal as in "(" or #\(.
It's precisely the other way around: finicky syntax issues consume far less time in Lisp. This isn't just a surface thing—when syntax occupies a block of resident memory in your head, you have that much less capacity to spend on the problem at hand.
It takes a while to adjust to a more regular notation, but that's true of anything unfamiliar. And what you get in return is astonishing.
Indentation or delimiter based languages are much easier for me to parse than lisps.
Brackets, yes, but not nearly as bad.
Also, in C/C++/Java/C#/whatever code, you can run into the same kind of problem on a smaller scale when editing deeply nested blocks and expressions, especially when dealing with complex arithmetic/logic expressions.
(I basically only use Lisp when messing with Emacs, so I would not call myself a Lisp hacker, but when learning Lisp, the braces cease to be a problem after a month at most.)
After a lot of refactoring by someone inexperienced in python, something was indented inside of a loop that should have been outside it.
8 hours work for de-denting one line of code.
Just don't expect anyone to all that interested when you start blubbering about it.