Most of the SQL grammar shown is, in practical terms, semantics more than syntax. Sure, there’s syntax woven into it, so that the points being made are quite valid, but I mean that to cover the scope of that grammar would take just as much space in Lisp, just in the form of things like function and parameter definitions (probably just as complex) instead of syntax. So it’s not just 118 lines of stuff Lisp wouldn’t need at all, which is a way I can see some people misinterpreting that section. SQL puts a lot of its complexity into syntax-space, a similar Lisp system puts it into library-space, but the complexity is still there (just probably easier to work with programmatically).
I agree I don't get the syntax argument. I am sure that as one of the other posters mentioned that one is more favored than the other, but once you know the limited syntax of a Lisp it becomes fairly readable. For me it's all about figuring out scope, once I know what denoted scope, it is fairly easy to format the code into a readable format for my mind. The thing about the Lisp dialects is the rules for syntax are so simple that once understood they become perfectly readable, at least to me they do.
>that indentation only would be sufficient to write many Lisp structures?
Lisp's syntax is just a textual representation of the internal abstract syntax tree, so you could represent it any number of ways: s-expressions, indentations, even something like json.
I think s-expressions were just the absolute simplest way to represent them with the smallest parser required. It's really really not much.
> The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?"
A more useful question is the following: "is a simple grammar the be-all and end-all of programming language design?". I think the answer is "no". Ceteris paribus, a simpler grammar is of course to be preferred to a complex grammar. But, ultimately, people write programs for what they do (so that they can be useful) and for what they mean (so that they can be maintainable), not for how they look like. So a simple semantics takes precedence over a simple syntax.
> Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax.
That is precisely what languages like Haskell (and to a lesser extent ML) give you: a typed lambda calculus (semantic simplicity) with infix operators (syntactic eye candy) for convenience. The type system reduces the universe of valid programs to those that typecheck, so you do not have to worry about stuff like the meaning of 2 + "potato".
> lisp's major weakness is that it makes everythign unergonomic in order to make macros very ergonomic.
That is simply false. The ergonomics of editing Lisp is also superb.
There is a consistent, logical way to break any Lisp expression into any number of lines of text. The more you break Lisp into multiple lines, the more clearly the tree structure of the code is revealed.
The absence of ambiguity helps readability: not having to guess which expressions are children of what operator.
Lisp code sometimes makes up for the parentheses by omitting superfluous punctuation like commas and semicolons. To add two terms, we need ( ) and +. But that's all we need to add 17 terms also.
Imagine if the Unix shell required commas between arguments:
ls, -l, *.c
that's how Lisp programmers feel when back in a non-Lisp.
The real question here is "do I need syntax?", or, more precisely, "do I really need a [complex] grammar?" Any given Lisp is still a programming language--it has some syntax and it has semantics. But it does have a much simpler grammar than any language (save Forth).
The grammars exist because programs are made to be read by people, not just computers. A more heterogeneous notation can make for more concise code that's easier to scan and easier to read.
Of course, this is not to say that Lisp is unreadable. I actually rather like reading and writing (paredit is awesome) Lisp code. But, after quite a bit of Racket, I've found that I still heavily prefer having infix operators and a bit more syntax. At the same time, I also often want less noise--ie no parentheses. I want all this so that I can quickly scan and comfortably read my code. That's why we need grammars.
I disagree about Lisp's syntax being "just the syntax tree", it is instead as you say a little later on, one specific way of writing linear strings of characters that correspond to syntax trees. Of course any other unambiguous grammar is also just one specific way of doing that. Lisp's syntax is not special because it somehow magically corresponds to parse trees where other syntaxes do not; rather in the case of Lisp the correspondence is simpler than for other languages. You make it sounds like Lisp does not need to be parsed, which is clearly false, it's just easier than most (but not all) other languages.
Nah, I really wasn't making any claims. I just didn't buy the argument.
Personally, I find Lisp easier to write but much harder to read. The syntax certainly plays some role in that, but I don't think it's the key. The problem, I think, is that it's just too dense. When you use a lot of intermediate variables, you get to name them something relevant. But Lisp code (or at least my Lisp code) usually doesn't have all of this context floating around, so it's harder to figure out what's going on.
But Lisp has rather less syntax than most other programming languages - and that's possibly a weakness rather than a strength when it comes to anyone new to the language.
I suspect there is a sweet spot when it comes to the syntactic complexity of programming languages - too little and people get lost in the generality and abstractions, too much and its difficult to remember it all and you end up with coding standards desperately trying to close down on the features that should be used (e.g. banning the ternary conditional operator).
Why not Lisp? I never understood why would people need any other programming/query/markup language syntaxes in the first place. The only part of Lisp that seems ugly are the ending stacks of closing parentheses at the ends of big code blocks.
I don't have a lot of experience writing Lisp-y code, so perhaps I'm speaking from ignorance, but I think there is a reason that syntax never gained huge traction. Imho a syntax that's concise and expressive is important for effective coding. Having operators for the most common operations is just a small complication that yields a big reward.
Having said that, the amount of keywords and operators that you see in Preql right now, isn't likely to grow by much. I have the basic and common operators covered, and for the most part, the rest can be done with regular functions.
I agree about introspection, which is why in Preql you can ask for the type of any value, list the columns of a table, get the resulting SQL of an expression as a string, and so on. And certainly more can and should be done towards that.
There aren't actually more parens in a Lisp program than a program written in a C-like syntax (which is really an algol-like syntax). They just stand out more for two reasons:
1. There is less punctuation in general, so the parens are more obvious. Instead of f(x, y, z) you write (f x y z). Without the commas, the parens stand out because that's all that is left.
2. There is only one kind of parens in Lisp whereas C-like languages use at least three: (), [], and {}, so that makes any particular kind of paren less prominent.
reply