I tend to struggle with other people's indentation rules for code and other programming languages, like nobody liked my article that said you should carry indentation into embedded strings that represent other programming laguages like SQL
result = sql.execute("""
SELECT someColumn
FROM thatTable
WHERE anotherValue>55
AND state='pending'
ORDER BY createdDate
""")
Ultimately the idea is that indentation should be influenced by semantics, the intention of the code, and not just the syntax. Of course that is against the "one way to indent" philosophy of Go, Biome, and such... But I might accept less than optimal indentation to put an end to tab wars once and for all.
I find indentation of Lisp always seems to fail at communicating in the semantics, much worse than other languages. Things like
(if condition truePath falsePath)
are scrambled when your eye skips over something. If the Lisp community got over its respect for tradition perhaps they'd develop some kind of syntax highlighting or tooltips or something that would clarify this sort of structure.
About 90% of real language have subject-verb-object or subject-object-verb orders
and build something like S-expressions (not so nameless tuples) when you functions like the above, nested inside each other. You then can then write code to eval those expressions or write out Java code during a code generation phase —- it is fun on some level but if somebody else thought it combined the worst of Common Lisp and Java I woulsn’t blame them. Build a system like that and you will realize Expression<Expression<Number>> is a thing, you have to introduce a quote() operator, etc.
And that quoting is also part of the Lisp problem. You have to not only decode your code relative to distant parenthesis but you also need to know the quoting state of the code you’re looking at which could agin involved involuntary nesting. Burns up precious working memory, just as multi-line if requires cognitive effort because your eye is not guided by if/then/else. It’s another one of those languages like C++ that seduces smart people into burning up their IQ on trivia and you can’t get them to listen about it because they think they are smart.
One reason why our tools suck is that we are stuck representing programs as trees when they are really graphs.
PaulHoule · · focus · HN ↗
I find indentation of Lisp always seems to fail at communicating in the semantics, much worse than other languages. Things like
are scrambled when your eye skips over something. If the Lisp community got over its respect for tradition perhaps they'd develop some kind of syntax highlighting or tooltips or something that would clarify this sort of structure.About 90% of real language have subject-verb-object or subject-object-verb orders
<a href="https://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%93verb_word_order" rel="nofollow">https://en.wikipedia.org/wiki/Subject%E2%80%93object%E2%80%9...
verb-subject-object and verb-object-subject are more Lisp-like and represent 10% of languages including Standard Arabic, Finnish and Fillipino.
I like extreme parsimony, like I'd love to write stuff like
but I think as complexity goes up depending on the meaningful order of elements breaks down in many ways and you need to give things meaningful names.wat10000 · · focus · HN ↗
PaulHoule · · focus · HN ↗
That said, you can build data structures in Java with functions like
and build something like S-expressions (not so nameless tuples) when you functions like the above, nested inside each other. You then can then write code to eval those expressions or write out Java code during a code generation phase —- it is fun on some level but if somebody else thought it combined the worst of Common Lisp and Java I woulsn’t blame them. Build a system like that and you will realize Expression<Expression<Number>> is a thing, you have to introduce a quote() operator, etc.And that quoting is also part of the Lisp problem. You have to not only decode your code relative to distant parenthesis but you also need to know the quoting state of the code you’re looking at which could agin involved involuntary nesting. Burns up precious working memory, just as multi-line if requires cognitive effort because your eye is not guided by if/then/else. It’s another one of those languages like C++ that seduces smart people into burning up their IQ on trivia and you can’t get them to listen about it because they think they are smart.
One reason why our tools suck is that we are stuck representing programs as trees when they are really graphs.
pasc1878 · · focus · HN ↗