5 ms·

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author

by j_baker 16y ago

> Lisp seems to be optimized for writing code; Python seems to be optimized for reading it. Urgh... A hundred times no. I really do appreciate that the author seems to have given Lisp a try. But this is simply wrong. Why does Lisp provide macros? Because they make code easier to read. I say stop focusing on what language abstraction (f x) represents and focus on figuring out what the code is doing. Oh well, at least he didn't complain about lisp having too many parenthesis.

Teckla 16y ago
"Oh well, at least he didn't complain about lisp having too many parenthesis." Humans are visual creatures. It really is easy to get lost in Lisp's parentheses. Languages whose blocks are easier to identify at a glance really are easier to read. The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great Lisp is. If Lisp hasn't dominated by now, rather than arrogance and superiority, it would be better to think about why Lisp continues to fail to dominate. By the way, I'm not suggesting you're one of those people.
- silentbicycle 16y ago
  > Languages whose blocks are easier to identify at a glance really are easier to read. Which is why conventions for indenting Lisp code to show block structure have been established for decades. This problem has been solved for longer than Python has even existed. I don't know why people keep bringing it up. Lisp isn't perfect, sure, but this is a very weak criticism. Besides, what about mismatched delimiter problems in languages like C that have shift-reduce conflicts? Dangling else problem (http://en.wikipedia.org/wiki/Dangling_else http://en.wikipedia.org/wiki/Dangling_else), anyone? It seems disingenuous to complain about mismatched parens in Lisp when those are trivially handled by most decent editors, and the problem is in no way unique to Lisp.
  - Locke1689 16y ago
    Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation as a mandatory part of the language and then remove cruft which is no longer necessary.
    - silentbicycle 16y ago
      I'm not convinced that block structure and indentation are primary readability factors, just noting that Lisp programmers established conventions to address that problem long ago.
      - Locke1689 16y ago
        That's fair. I'm not saying Python's way is better or Lisp's way is better. I'm a long-time Python programmer but I'm also working on the Racket code base. I was simply pointing out a difference in philosophy, not taking sides. I mostly believe that the debate is a minor stylistic one and there are trade-offs in both directions. This is fundamentally similar to the way I see arguments for and against Python syntactical whitespace vs. Ruby-esque blocks.
    - euccastro 16y ago
      Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. I'm very familiar with Python and hack occasionally in Scheme. After a really short time, parens really are no problem. They are an asset. In big functions where indentation stops being obvious at a glance (and in smaller ones, what's the problem?), I can more easily see/check the extent of a block in Scheme (with editor paren matching) than in Python. The editor is better able to help me select and operate on such blocks. Moving blocks around (e.g. for refactoring) is easier, faster and feels safer. If I still use Python more often than Scheme it has nothing to do with parens. Much on the contrary, that's one of the reasons I wish I could spend more time in Scheme.
      - 16y ago
- stcredzero 16y ago
  Languages whose blocks are easier to identify at a glance really are easier to read. IMO, it's really pointless to toss about theories having to do with readability for this reason or that. Programming languages are also (sub)cultural entities. It doesn't matter how many clever reasons we come up with explaining why people don't like this or that about whatever language. Most of those things are unsubstantiated, so who gives a flying expletive? What matters is that languages attract audiences of the size they attract. It's a fact of life. It's all we know until some serious psychological/linguistic research happens. Frankly, I'm not sure if enough people care enough about what coders think for it to happen. Maybe they should. In the meantime, we should just shut up and code. (Starting with me. Why did I write so many comments today?)
- cesarm 16y ago
  in lisp one ends up reading code by indentation - much like python. the parenthesis fade into the background after just a couple of days of using lisp. matter of fact i use a light blue background in emacs, and make the parenthesis a light gray. barely see them.
lwat 16y ago
Why does Lisp provide macros? Because they make code easier to read. To the person writing the code, yes. To the next coder maintaining the code, not likely.
- rayiner 16y ago
  Look through some really old Lisp code sometime. SBCL is highly readable despite being: 1) 25 years old and touched by tons of different people since then; 2) a program that does some really complicated things in a pretty small space (~60 KLOC for the arch-independent portion). When you see (def-ir1-transform ...) in the SBCL source, it's immediately obvious what is about to come along (at least if you know about compilers). Similarly old C code (eg: GCC) is completely incomprehensible in comparison.
- gnosis 16y ago
  Have you ever actually programmed in Lisp? Macros can and often do hide all sorts of ugliness that would otherwise make the code a hundred times more unreadable. Much of Lisp's syntax sugar is built with macros.
- pavelludiq 16y ago
  Do you have any data(even if anecdotal) to back up your claim? My experience is that macros don't obfuscate code at all(unless misused, I'm talking about idiomatic use of course). If i have the code loaded i just type (documentation 'macro-or-function-name 'function) to get its docstring. Slime can also show me its documentation and its argument list. Not to mention that a good macro(like any other well written code) is obvious. On the internet Lisp is the most unmaintainable language, in practice its pretty maintainable.
  - lwat 16y ago
    Here's an anecdote from the other day: http://news.ycombinator.com/item?id=2240461 http://news.ycombinator.com/item?id=2240461 On another note, why do you think lisp isn't more widely used?
    - 16y ago

by j_baker 16y ago

Teckla 16y ago

"Oh well, at least he didn't complain about lisp having too many parenthesis." Humans are visual creatures. It really is easy to get lost in Lisp's parentheses. Languages whose blocks are easier to identify at a glance really are easier to read. The attitude of far too many Lisp developers seems to be that Lisp has failed to dominate after all these many decades because people are just too stupid to realize how great Lisp is. If Lisp hasn't dominated by now, rather than arrogance and superiority, it would be better to think about why Lisp continues to fail to dominate. By the way, I'm not suggesting you're one of those people.

silentbicycle 16y ago
> Languages whose blocks are easier to identify at a glance really are easier to read. Which is why conventions for indenting Lisp code to show block structure have been established for decades. This problem has been solved for longer than Python has even existed. I don't know why people keep bringing it up. Lisp isn't perfect, sure, but this is a very weak criticism. Besides, what about mismatched delimiter problems in languages like C that have shift-reduce conflicts? Dangling else problem (http://en.wikipedia.org/wiki/Dangling_else http://en.wikipedia.org/wiki/Dangling_else), anyone? It seems disingenuous to complain about mismatched parens in Lisp when those are trivially handled by most decent editors, and the problem is in no way unique to Lisp.
- Locke1689 16y ago
  Python would argue that if the primary operating factor in readability is block structure and indentation one should simply add block structure and indentation as a mandatory part of the language and then remove cruft which is no longer necessary.
  - silentbicycle 16y ago
    I'm not convinced that block structure and indentation are primary readability factors, just noting that Lisp programmers established conventions to address that problem long ago.
    - Locke1689 16y ago
      That's fair. I'm not saying Python's way is better or Lisp's way is better. I'm a long-time Python programmer but I'm also working on the Racket code base. I was simply pointing out a difference in philosophy, not taking sides. I mostly believe that the debate is a minor stylistic one and there are trade-offs in both directions. This is fundamentally similar to the way I see arguments for and against Python syntactical whitespace vs. Ruby-esque blocks.
  - euccastro 16y ago
    Python doesn't mandate block structure and indentation in lines within brackets and parens. Ask yourself why is that and you'll have the reason why it makes sense in Lisp. I'm very familiar with Python and hack occasionally in Scheme. After a really short time, parens really are no problem. They are an asset. In big functions where indentation stops being obvious at a glance (and in smaller ones, what's the problem?), I can more easily see/check the extent of a block in Scheme (with editor paren matching) than in Python. The editor is better able to help me select and operate on such blocks. Moving blocks around (e.g. for refactoring) is easier, faster and feels safer. If I still use Python more often than Scheme it has nothing to do with parens. Much on the contrary, that's one of the reasons I wish I could spend more time in Scheme.
    - 16y ago
stcredzero 16y ago
Languages whose blocks are easier to identify at a glance really are easier to read. IMO, it's really pointless to toss about theories having to do with readability for this reason or that. Programming languages are also (sub)cultural entities. It doesn't matter how many clever reasons we come up with explaining why people don't like this or that about whatever language. Most of those things are unsubstantiated, so who gives a flying expletive? What matters is that languages attract audiences of the size they attract. It's a fact of life. It's all we know until some serious psychological/linguistic research happens. Frankly, I'm not sure if enough people care enough about what coders think for it to happen. Maybe they should. In the meantime, we should just shut up and code. (Starting with me. Why did I write so many comments today?)
cesarm 16y ago
in lisp one ends up reading code by indentation - much like python. the parenthesis fade into the background after just a couple of days of using lisp. matter of fact i use a light blue background in emacs, and make the parenthesis a light gray. barely see them.

lwat 16y ago

Why does Lisp provide macros? Because they make code easier to read. To the person writing the code, yes. To the next coder maintaining the code, not likely.

rayiner 16y ago
Look through some really old Lisp code sometime. SBCL is highly readable despite being: 1) 25 years old and touched by tons of different people since then; 2) a program that does some really complicated things in a pretty small space (~60 KLOC for the arch-independent portion). When you see (def-ir1-transform ...) in the SBCL source, it's immediately obvious what is about to come along (at least if you know about compilers). Similarly old C code (eg: GCC) is completely incomprehensible in comparison.
gnosis 16y ago
Have you ever actually programmed in Lisp? Macros can and often do hide all sorts of ugliness that would otherwise make the code a hundred times more unreadable. Much of Lisp's syntax sugar is built with macros.
pavelludiq 16y ago
Do you have any data(even if anecdotal) to back up your claim? My experience is that macros don't obfuscate code at all(unless misused, I'm talking about idiomatic use of course). If i have the code loaded i just type (documentation 'macro-or-function-name 'function) to get its docstring. Slime can also show me its documentation and its argument list. Not to mention that a good macro(like any other well written code) is obvious. On the internet Lisp is the most unmaintainable language, in practice its pretty maintainable.
- lwat 16y ago
  Here's an anecdote from the other day: http://news.ycombinator.com/item?id=2240461 http://news.ycombinator.com/item?id=2240461 On another note, why do you think lisp isn't more widely used?
  - 16y ago