> 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".
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.
It's hard (if not impossible) to pick a single attribute of 'Lisp' that's shared by all the languages that are part of the Lisp family of languages. There are Lisps without macros, there are Lisps without the simple syntax, there are Lisps without dynamic typing, or lexical scope, or any of a dozen other features that are present in at least on Lisp.... so I think reducing Lisp to a handful of features and calling that 'basically it' is a good way to miss the point. (Not to belabor the obvious
In it, he describes through a though experiment what it means for a language to be defined by its community and how that impacts its development and use. It isn't as much about the specific features as it is the approach that led the language to get to have those features in the first place.
Just to illustrate, the simple syntax is a good example. It's not immediately obvious why simple syntax is a good thing... in fact, given the fact people prefer infix and a big part of the backlash against Lisp is due to the syntax, you might argue that it'd be better for Lisp to drop the syntax entirely. (As was tried in Dylan and Logo) That, you'd lose a lot that's not necessarily obvious. There's a real value in having a concrete syntax for your language's core data types and then defining the language in terms of those data types. The simple syntax isn't the point as much as what it enables you do accomplish.
> but lisp syntax... is less legible than TLA+ imho.
I've developed theorem provers with more natural syntax, and in retrospect simpler grammars are better. The stone cold truth is that most people aren't interested in using theorem provers directly; instead, they're programmatically generating queries. Simpler grammar = easier to generate, and that out-weighs direct usability.
In my next system I'll be supporting both types of grammars in the parser.
> It's all personal, of course, but I find that the typographical variety of "traditional" languages with syntax makes it way easier to me to read/parse them than LISP.
I wonder how much of that has to do with your familiarity with "traditional" language syntax. For example, when I started writing Lisp, I had a similar opinion. But I write Clojure professionally for a while, and that disappeared. Now I haven't written Lisp in probably 7 years, but I still have no problem reading it.
> Parens, parens, everywhere, nor a drop of structure.
On the other hand, in some sense it's all structure. There are certainly advantages to having everything be delimited.
The syntax criticism is a red herring in my opinion.
At least speaking personally from my opinion I see a lot of people claiming that lisp simple syntax and homoiconicity make it a simple language and in my opinion this misses completely the point of simplicity in a language.
I am not claiming that lisp is complex, just that that argument is faulty.
Simple syntax isn't about elitism. It's not like some evil Lisper, decades ago, figured ``I know! let's make simple syntax so almost nobody can understand or write it!''
The simple syntax of Lisp has only one purpose: easy programmatic manipulation (reading, writing, transformation). I.e., less boilerplate. Let me spell that out for you: EASIER MANIPULATION, LESS BOILERPLATE. Elitist much?
There isn't Yet Another Parser Toolkit Of The Week in the Lisp world, there isn't Yet Another Lexer Utility Of The Month in the Lisp world.
Seriously, writing a bunch of parentheses isn't much harder than writing intricate, complex C-like (C++, Java etc.) syntax structures. How the heck did simplicity became synonym of elitism in the subject of Lisp syntax?
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.
I'm not sure I understand why one would expect that any language that is meant to be created in physical space should aim for the most minimal syntax.
Regular folks who don't program in their daily life connect best with things they can read: presenting them with lisp is a bit like presenting them with mathmatical notation: even if those that are marginally familiar with them will say it's simple, it's exactly too difficult to be accessible for people who have _no_ familiarity with them at all. You actually want that verbosity of added syntax, because it lets people recognize something in what is inherently alien to them.
It's not so much that Lisp has no grammar, but that it's a VSO language (or it has the tail-first/head-final parameter set, if you prefer), where infix programming languages more closely resemble the SVO natural languages most of us in Europe or North America are used to. I'm sure that something more "normal" like Python, C, Pascal or BASIC would be as hard for uninitiated speakers of verb-first languages to wrap their heads around.
I never really bought the syntax simplicity argument, but what I eventually realized is it allows Lispy languages to implement any other paradigm or feature and it just naturally fits within the language.
>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.
Lisps are not write-only. They're easy to read precisely because there is no inscrutable syntax. Every pair of parentheses has a first element, which tells you what they're doing. The parentheses denote a scope in which to look for arguments.
Conventional style guides also make the readability practically a trivial issue because you end up indenting arguments such that the structure of the program is reflected in the indentation, because each S-expression within a parenthesized S-expression is itself an AST node. Writing readable Lisp is just a matter of reflecting the AST's structure in the indentation, which most people do in other languages anyway (to some degree).
> the advantages of lisp have long since been obtained by other languages.
Clearly not, since most other languages are still not S-expression-based. (Though, admittedly, some other advantages have been copied in other languages.)
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'd say this depends of the complexity of the I/O system.
This was the original claim, which you supported:
'Parsing Lisp in Lisp is so easy because it’s free.'
The example you were pointing to is explicitly calling a parsing engine of Racket via 'read-syntax'. Actually more complicated than the usual s-expression reader - which does only read s-expressions, but has no further idea about Scheme syntax.
Check the usual Scheme report / Racket documentation for the definition of Scheme syntax, syntax objects and its extension mechanisms (macros, ...). I'd say the whole thing is non-trivial. There is a grammar of Scheme, but it is not fixed, because there are extension mechanisms, which make parsing challenging.
It's 'free' because it's a provided language facility - but not free in terms of complexity of the concepts to understand.
And no, the syntax of s-expressions (-> data) is not the syntax of Lisp. It's just the syntax of s-expressions. Search the Scheme report for 'syntax'...
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).
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.
Syntax helps readability of structure. Lisp fails at this compared to other languages. Its simple, consistent syntax does help with some types of problems but those aren't the ones that dominate most people's daily programming needs.
Arguably, the syntax is the simplest thing one can change in a language, by creating a wrapper (like there are, as evoked in this thread, such wrappers around OCaml for instance.)
Francky, syntax has little to no incidence about how well a given language fits a domain problem, and in my experience the only thing syntax is really important to, is how attractive the language is to programmers who judge languages by their cover.
I remember having read somewhere that the initial versions of lisp where missing an actual syntax, and that it was planned to add one later, but that until then users would have to write directly the AST in an ugly syntax full of parentheses and devoid of familiar syntactic landmarks. Well, time passed, an nobody cared enough to add that user friendlier syntax :)
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".
reply