61–70 of 81 posts
*Except also that Haskell is typed and does not include code quoting/eval. But that's what Template Haskell is for :)
This argument/response comes up every time.... Argument: "Lisp has too many parentheses. It's unreadable." Response: "It's conceptually elegant that everything is parentheses." This doesn't address the real point -- you can't read it well. You do get advantages for macros and symbolic processing. But the cost in readability is still there.
I've posted this here before, I'll post it again: http://img264.imageshack.us/img264/1397/lispnd7.png In practice, I don't find it has many more parens or angle-brackets than, say, C++ or Java. Considering (), {}, and in those two languages, I'd bet Lisp wins.
Anyone manage to build a Lisp that used semantic indentation (like Python)? You could make it optional and just have it function as a preprocessor that generates the real thing.
You can play around with significant whitespace all you like, but you have lost the simple representation of a list. How many hideous grammar hacks will you add to get this back?
Those who keep going on and on about parentheses in Lisp should try Haskell, which is basically* Lisp, except everything has one argument and is left associative. This simple rule removes a TON of parens. Add in the $, . operators and a bunch of other potential parentheses are eliminated. *Except also that Haskell is typed and does not include code quoting/eval. But that's what Template Haskell is for :)
Earlier quoted context omitted.
My guess is that what people complain about isn't really the parentheses, but rather heavy nesting of Lisp programs compared to other languages. If parentheses were replaced with something else, they'd probably complain about that something else.
Except that most modern lisps don't even nest that deeply anymore. At least, not anymore than every functional language that uses nesting to offer new immutable lexical scopes does. Seriously, the average nesting depth of a C program is maybe 3-4 (function, conditional, loop, etc), and C programs are simple . More complex languages like Java and C++ will easily have 4-7 levels of nesting on average. Clojure and Arc c…
http://stackoverflow.com/questions/105852/conditional-loggin...
I've posted this here before, I'll post it again: http://img264.imageshack.us/img264/1397/lispnd7.png In practice, I don't find it has many more parens or angle-brackets than, say, C++ or Java. Considering (), {}, and in those two languages, I'd bet Lisp wins.
BTW, while Halstead metric predict various things about imperative languages like Algol/PL/1/C/C++/Java quite well, it fails when applied to Haskell: http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf
And fail spectacularly - they have to introduce special "invisible apply" operator to make Haskell to be closer to imperative languages, just to do not look like they are cheating.
This is attributed to juxtaposition as application (as it reduces number of lexems) and to definition of functions by pattern matching. I think other languages with those two features would have same effect over predictive force of Halstead metric.
Earlier quoted context omitted.
For things like cadadr, I just chop off the "c" and "r", and use the middle part to figure out the sequence of car and cdr calls. (cADADr x) = (cAr (cDr (cAr (cDr x)))), which would be (first (rest (first (rest x)))) in Clojure.
I suppose CL/Scheme programmers just learn by heart what those combinations do (ie. what kind of structure they work with), because to me both cadadr and the (first (rest ...)) sequence are equally meaningless at first glance. It's not easy to see what the data structure looks like. In Clojure it's usually more idiomatic to use destructuring, which I think is much more understandable since the form follows the struct…
http://groups.google.com/group/clojure/browse_frm/thread/11a...
Money quote for the non-lisper: > For simplicity, let’s use the notation Yes, let's! Except in lisp, you can't. ;) (Yes, feeling snarky.)
Except you can, just use reader macros.
defun diff(expr, x){
if(expr == x) 1
else if(car(expr) == 'plus') ['plus', diff(cadr(expr), x), caddr(expr), x]
else if(car(expr) == 'times')[
'plus',
['times', cadr(expr), diff(caddr(expr), x)],
['times', diff(cadr(expr), x), caddr(expr)]
]else 0
}Earlier quoted context omitted.
Paul Graham says: > We can get rid of (or make optional) a lot of parentheses by making indentation significant. That's how programmers read code anyway: when indentation says one thing and delimiters say another, we go by the indentation. Treating indentation as significant would eliminate this common source of bugs as well as making programs shorter. http://www.paulgraham.com/popular.html
By requiring parenthesis, indentation becomes so much simpler, the programmer doesn't even have to do it. It's done automagically.
Because the Lisps have such a canonical way to indent them, in practise it feels very similar to significant whitespace with a funny input method.