"Oh god, syntactically significant white space!"
Python feels a bit like a toy Lisp with all the adult parts hidden.
I'm not really speaking for LISP, but in my projects what really bothers me are people that don't have common sense when indenting / formatting their code and so they start using IDE or build plugins, using common conventions and formatters that will never be able to understand the meaning of the code being formatted, making a total mess of other people' carefully crafted code. And we go round and round on this.
I don't advocate writing cryptic code. Of course I prefer code that is easy to read. That's a major basis for my opinions on syntax.
Do you think Python's syntax is cryptic and hard to read, because of the lack of end parens? Or did you just misunderstand my point completely?
If a lisp dialect had a large, vibrant ecosystem on the scale of Python or Javascript, then a lot of people would see the parens, see the advantage of having them, work their way through it and eventually get used to them and even embrace them because they see a real payoff.
That's not the case with lisp dialects. The major payoff with lisp dialects is macros. But for most people, it isn't obvious why they are important. They are something you have to use to really get.
So the intellectually reasonable position for most people is to either ignore lisp or laugh at it. Meanwhile, you see endless articles like this posted over the years (not knocking the article itself), trying to explain lisp in a kind of reverence and terminology usually associated with religious texts. "Hey, brother, you just need to see the light".
I've been doing quite a bit of Clojure coding lately and I love it. I just can't see a lisp ever catching on. Actually, the project I'm working on is a lisp that does not look like a lisp but compiles down to Clojure. The parens aren't really necessary for lisp's best feature, as seen by Elixir. Here's a bit of my language:
" " join([1, 2, 3]) count println"the intellectually reasonable position for most people is to either ignore lisp or laugh at it"
I said that such a position has nothing to do with "intellectual reasonableness" because it's barely an intellectual position at all. There is no propositional content; there is very little thought involved at all; it's a default "meh" position that is more accurately labelled "laziness."
I used to be a HUGE Perl fan, and discounted Python for years. I figured that I already knew Java, and since Python and Perl were effectively similar, it was a waste of my time to study both. I now regret that. As formative as that was for my growth as a programmer, I've loved coding in Python more than almost any other language -- and I delayed that discovery by a decade because I wrote it off as "effectively the same as" Perl.
Sure, it was pragmatic to focus on one language that I was learning and using. But the reasons I did so were flawed, IMO.
it's joining the vector 1,2,3 with a space to make "1 2 3 ", right? so what is that count doing there? I'm not saying that lists are the end all be all of syntax (clojure has vectors for a lot of things specifically to reduce the parens), but you need something there to make it clearer
If you are familiar with Python, it more or less is equivalent to something like:
" ".join([1, 2, 3]).count().println()
Which, imo, reads much better than: (println (count (join " " [1 2 3])))
Of course, Clojure has the threading macro, but this language emphasizes it. f(x).sin().log()
instead of log(sin(f(x))). x.f().sin().log()
and that is exactly what they type on their calculators:[3] [1/x] [sin] [log]
(either that, or I am getting old. Modern graphing calculators may have different input modes)
log(sin(f(x)))) -> (log (sin (f x)))
They don't have to evangelize function composition being indicated by nesting.too easy languages to conflate a lot of logic into large side effectful statements. FP forces you to separate layers, and deforestation (when available) helps reclaiming space/time costs.