Hacker News new | past | comments | ask | show | jobs | submit login

You're right - at the single element level it's not that different.

But the overall effect is very different. For instance, simple ergonomic things that help programmers read code, like the word "else" in an if statement/expression are elided because its AST is implicit in its position in Lisp. Similarly, you can't quickly scan a page of code for something like "=" to see what's getting assigned - you have to look for let pairs.

And even then, making local variables seems to be considered wasteful in Lisp if there's a way to structure it so that the value can be placed somehow directly into the AST as the evaluation of an expression. The result is that most Lisp code I've seen has a rigidity to it of deep expressions within expressions. Deep expressions are certainly possible to implement in other languages, but it's rare to see it done so thoroughly as Lisp developers seem to enjoy doing.

The result is "hard to read" in the sense that it's harder to scan syntactically (lisp having essentially no syntax) and harder to modify due to the carefully constructed expression nesting. These may both be seen as my own shortcomings wrt the language, but I think many others share them.




Hardly any different than hunting down for ?: on C derived languages, clever uses of LINQ inspired expressions, or why a bunch of ([{((}]]) distributed across function call, if, else, while expressions aren't nesting properly.


That's right. And style guidelines in those other languages tend to recommend against such things.


Yeah, and unless one is at a company that pretends to be like Google, largely ignored anyway.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: