When I tried to introduce s-expressions to a DSL my co-workers nearly lynched me. The parenthesis were so violently hated I sunk into a deep hole and still haven’t came back out of it.
It really is kind of frustrating isn't it? Because anyone who's put any real effort into learning Lisp knows that the parentheses are not what's hard to understand, actually. You don't even have to read them, really.
So when people complain loudly about parentheses in Lisp that just tells me they probably never made any real effort to learn it, and are actively opposed to trying.
It's not a productive starting point for a discussion.
They're not. But they're also not required to flaunt their own ignorance as though it's a well-formed opinion. Also, in a professional setting, I find it a bit unprofessional and rude to poo poo technical ideas over trivialities.
> But they're also not required to flaunt their own ignorance as though it's a well-formed opinion.
I don’t like the parenthesis. I’m not flaunting anything. Is it “flaunting” to calmly and respectfully share an opinion? To you it’s trivial, to me it’s not.
It seems like you’re interested in creating conflict with people that don’t like a thing that you like. Which, I would cast this behavior as unprofessional, tbh.
I'm not a fan of the parenthesis either, but when I learned about s-expressions and how lisp programs are also a data structures that piqued my interest and helped me look past them.
I question people's judgement who can't look past the syntax when there is a very good, and interesting technical reason behind them.
Code as data is interesting, but mostly orthogonal to S expressions. For example, Prolog code has the same property without S expressions, and more esoterically TeX (which is succinctly explained to a lisper as programming with defmacro but not defun).
> I question people's judgement who can't look past the syntax when there is a very good, and interesting technical reason behind them
The list of things that are interesting is endless, though. I see something I’m turned off by, I move on. There are plenty of valuable things to spend time on.
Yeah it is a personal issue, there are people who really like Lisp syntax (I'm one of them). That doesn't mean anything bad, of course, some people like dark text on a light background, others light text on a dark background. Everyone is different and that's what makes the world so awesome.
I see something like:
some-var: I64 := a * b - c ^ d ^ e;
...and my brain gives out, while I find:
(let ((some-var (- (* a b)
(^ c d e))))
(declare (type I64 some-var))
...)
How do you look at the latter and know the code structure? Are you counting parentheses? Or are you relying on conventions around white space indentation. If the latter, are you not concerned a misplaced parentheses might make the code different from it appears? There could be bugs not shown in the indentation.
Most lispers I know code in eMacs or other smart editors that provide auto code formatting and colored parens. But why not just make the indentation (or whatever that you really rely upon) the actual syntax, so there CANNOT be hidden bugs of that sort?
Edit: to expand on this, I think it is no coincidence that most lisps remain untyped to this day. Strong typing is about having the compiler enforce type rules so you the developer can’t fuck it up. Weak typing is more convenient, but ultimately a source of bugs. Lisp has, effectively, weak syntax. I don’t like weak syntax for the same reasons I don’t like weak typing.
You're clearly the exception though. It's almost always just ignorance in my experience. That's why I used the word probably. I assume if someone asked you what you thought about Lisp, you'd have a lot more interesting stuff to say than just "ew, parentheses", right?
That's my point, is all.
As for readability, I don't think it's trivial at all. I just don't think syntax has all that much to do with it. It plays a role, but a very minor one compared to overall code quality. In other words it's syntax that's mostly a trivial point, not readablity.
One undeniable advantage of Lisp in terms of syntactic readability though is that other languages always end up piling on more syntax over time as the language gets older. That's by far my least favourite thing about Rust for instance, even though I do love the language. There's always some new syntax, keyword, or position that an existing keyword can suddenly go in. The longer I go without actively using Rust, the more work it is to start again, because I have to go learn all this new stuff now. And syntax always takes a while to feel intuitive, at least for me. But it's still a lot easier than grokking new semantics and paradigms. I still don't have a good handle on async rust.
If someone told me to go read some ALGOL 68, I could probably do just fine because there's nothing semantically unfamiliar about it compared to something like C. But if someone gave me some Haskell written as sexps I would be utterly lost despite the syntax being perfectly comfortable to me. Because I never quite grokked typed FP.
No, the horrible syntax of lisp is pretty much all I have to say on it, honestly. I don’t care for lisp for the same reason I don’t care for perl: write-only languages are a bigger hinderence to software maintenance than whatever advantage might be obtained. And the advantages of lisp have long since been obtained by other languages.
I did it once in an internal UI because we needed to rapidly expose some functionality that could be composed/piped in complex ways and it would take a while to implement a normal UI
Was met with skepticism, esp around the engineering/maintenance overhead, until I told them the parser took me a couple hours to write and was only a hundred lines of code or so
It is really fun (sad) to see this, I've seen it so many times myself too. You show how something would be with s-expressions, compared to something, and all they can focus on is how many parenthesis there are. But when you sit down and count, they're the same amount as the code was when it wasn't s-expressions, just in different locations. And when you remove the parenthesis, they can kind of understand the code, kind of.
One option that might be suitable for a DSL, is implicit parens based on whitespace. A newline opens a new paren, and the paren closes when it reaches another line with the same indentation e.g:
(defun factorial (x)
(if (zerop x)
1
(* x (factorial (- x 1)))))
could be rewritten as
defun factorial (x)
if (zerop x)
1
* x (factorial (- x 1))
I doubt that SRFI 49, or any other proposal I've seen online, has been battle-tested.
I've written thousands of lines of Scheme using my own preprocessor, and it's my favorite code to look at. I prefer Haskell, for incredible ease of parallelism and a deeper mathematical foundation.
The two features I look for in a reduced parenthesis syntax (like looking for the bone marrow in a beef stew recipe) are:
1. Some constructions begin doubly parenthesized. One needs a symbol to represent the missing object one parenthesis in. I use $.
2. One can write more expressive lines with a flavor of open paren that autocloses at the end of the line. I use |.
Whitespace significance might be the choice even more controversial than Lisp parens. For myself, I appreciate both, but those that do not, really do not.
Probably there are more Python users out there than combined users of all lisp-like languages, which I guess would mean people are less scared of white-space significance than s-expressions :)
The things I'm looking for in language syntax these days are
1. That it's unambiguous enough that my editor can format it correctly every time (provided the code is correct, obviously). Indentation-based languages like Python fail this.
2. That its elements and keywords are distinct enough that my editor can apply colours on it. I sometimes feel that S-expression languages fail at this because of their small number of distinct keywords, but that might not be true.
Besides these two points, if the language is not a joke language, it's probably fine.
But it's what ambiguous about Python's syntax. And I can make it a bit worse:
if a:
print("foo")
if b:
print("bar")
This is not a huge problem, but problems with syntax never are (in non-joke relatively modern languages). But it's still something I prefer that languages fix in their syntax if I get to have a choice.
The example you just posted is a syntax error, as it should be. And I still don’t get what is ambiguous about the syntax, the specification clearly states how indentation corresponds to a syntax tree.
So when people complain loudly about parentheses in Lisp that just tells me they probably never made any real effort to learn it, and are actively opposed to trying.
It's not a productive starting point for a discussion.