I have never really understood people‘s aversion to parentheses. Many languages require them in ad-hoc ways to groups expressions. For S-expressions, you give up some mild convenience and looks for extremely consistent semantics.
On the one hand it is important to have discussions on the benefits and drawbacks of different approaches in language design, and some people will change their minds based on that, but it's also an illusion that one single approach will ever suit everyone.
I do agree with the sentiment to some degree though that it all looks the same. In an aesthetic sense, there is something I do like about it though.
Being a fan of both ML and Scheme, I have actually been experimenting with a syntax that is a hybrid of the two. I’m still in the experimentation phase, but it’s an interesting exercise.
Yes, but those are effectively library conventions, not fixed properties of the language. Maybe more importantly, names aren’t a structural construct, like a for loop or a class definition. And, arguably, you can have similar syntax in other languages, like e.g. `!` in Rust or the type sigils ($, @) in Perl, except that here you can be sure of their semantics.
A common refrain from Lisp family language enthusiasts. (Personally I prefer Smalltalk-style "conversational" syntax to Lisp-style or C-style syntax, yet it's similarly unpopular.)
For better or for worse, the vast majority of programmers seem to have voted with their feet for C-style syntax (C/C++/Java/JavaScript/etc.) and its variants (Python). In a C/C++/Java/JavaScript world, C syntax has a fair amount of leverage.
It's a shame that Dylan didn't continue, as it seems to have taken a decent crack at adding algebraic syntax to Common Lisp - arguably realizing McCarthy's original vision of infix M-expressions as a more programmer-friendly syntax. I wonder how hard it would be to add a Dylan-style syntax layer to modern CL?
Be that as it may, one can readily write Lisp/Scheme-style programs in JavaScript. See Crockford's "The Little JavaScripter."[1] The major omission/deficiency being macros for JavaScript syntax.
I actually learned about Lisp/Scheme after I had learned about several other languages.
What do people not like about parentheses? It’s normally along the lines of “well, I just don’t like them”, which can be read as “it’s not what I’m used to”. Yet, these same programmers will freely throw parentheses around expressions in an ad-how manner to communicate with the compiler in their given language. In some ways, one can back Lisp/Scheme out of popular languages by stating that instead of letting parentheses be used to frequently but not always clarify precedence and grouping and function application, they are going to be required to enforce these. Such a thing is not such a radical or unreasonable stance.
McCarthy’s original M-expressions are somewhat irrelevant. He wasn’t trying to make a programming language for software development. He was investigating it as a tool for his research.
My primary complaint about popular languages like Python, C++, C#, etc. are their irregularities. There a lot of syntax, semantics, and little quirks in the languages that make it very hard to just know the language and move on solving problems. My favorite thing about Schemes are their regularity. The social popularity of languages can’t be explained by their technical merits. It’s more due to social and historical phenomena than a technical reason.
For what it’s worth, I also like Smalltalks.
There is power and elegance in syntactic uniformity, but Lisp in particular is hard to read until you train your eye to see through the nest of parentheses, and it's hard to write without something like Paredit assisting you.
Meanwhile I don't think anyone finds Haskell/ML syntax hard to read. The problem is more that, with idiomatic Haskell in particular, too much abstraction, currying, and un-descriptive variable names can obfuscate what a piece of code actually does.
Lisp doesn't have programmer-unfriendly syntax. It's just tailored to a different use case: built-in ever-present meta-programming. The language was designed to compute with symbolic expressions as data and it was early discovered that Lisp programs itself could be treated as symbolic expressions. Code as Lisp data. People found it easier to do it all in s-expressions, compared to the mixed syntax of the early design: m-expressions for programs and s-expressions for data. This was shown over and over.
In that space it has some local optimum of programmer friendliness. It's just that most programmers don't have that use case. Some get the ideas of list processing as a practical programming interface.
Alternatives were spawned, though: LOGO as a beginner's Lisp, ML as a functional programming language, Dylan as an Scheme+CLOS targeting the same audience as Swift nowadays, ...
I've checked it a few minutes ago and Open Dylan's ./configure says to download a bootstrap compiler from https://opendylan.org/download/index.html first -- but there's no such bootstrap compiler there.
Do you have some hints on how to package it?
I wouldn't call Dylan thriving, unless you're a Windows user that really doesn't care about bootstrapping your language.
It's alive though, in the same sense that Miles, the dog that Segall froze and then brought back to life in 1987, was alive. Brain damaged, but alive.
I know what I was doing, and if you look elsewhere in the thread, I was right about what the GUIX maintainer wanted. Not to get egg on your face.
So for Dylan, we'd like to have a compiler for Open Dylan, not written in Dylan. (it can also require multiple steps to get up to Open Dylan--that would be fine)
It's not in the interest of our users to use binary blob compilers for bootstrapping.
We would also unbundle LLVM, clang and the bdw gc and use the ones from Guix.
I, for one, welcome my whitespace-surrounded operator overlords, but if you really don't want that you're welcome to use function-call syntax for them.
(if (condition) ;; <- must be when, not if!
(do-this)
(do-that))
There are similar problems in other languages; no notation is perfect, and attempted cures for some of these problems can be worse than the diseases.
GCC's relatively recent "misleading indentation" warning is a good example of a cure that has no downside (that I can quickly think of). It can catch code like:
if (condition)
do_this();
do_that(); // not part of the if statement, but indented deceptively
(if (condition) ;; <- must be when, not if!
(do-this)
(do-that))
(if (condition)
(do-this)
(do-that))And for most people, the mild convenience of readability is preferable to the consistent semantics.
Because the human brain is a pattern-matching organ and sometimes redundancy in a signal is useful. I've never understood the lispers' insistence that saving "screen real estate" is a primary concern. Source code is meant to be read, and the more easily code is read, the more utility is has.
You can think of Lisp's paren syntax as the syntactic analogue of Lisp's very simple static type system. To get macros to work with a conventional grammar's complexity is much more annoyingly complex.
Yes it does; doing it any other way is strictly worse regardless of where you stand on parentheses as such.