I would like to add just a few more arguments regarding the issue of notation.

There is a certain austerity tradition coming from the CS community (at least from the BEST part of it). Most people see syntactic sugar as a waste of time and energy. Furthermore everything is just trees and a linear representation with the root at the head is just fine to represent trees. Lisp embodies this tradition to the full. And for the most part is a great tradition.

This is all fine, and I would understand the defensiveness considered that we live in a world polluted with overly complex languages which just bring problems and no advantages to compensate.

But some level of syntactic sugar is important for humans. And while meta-programming is nice, I suppose most programming languages are still used by human programmers ;) .

It would suggest to have a look at the literature on human cognition, namely the strategies used to read text: it is messy. But I prefer to go in a different direction. I just want to expose how some subtle representation issues might have a massive impact: Have you ever tried to do basic arithmetic with roman numerals? Have a look here, namely “How can I use Roman numerals to do arithmetic problems?”. While this is a different problem, it serves to emphasize that representation matters in the most strangest ways.

Even if it doesn’t, humans are a conservative species, they are not ready to change everything at the same time. Having a to jump to imperative+heteroiconic+infix to functional+homoiconic+prefix is too much. Lisp derived languages loose potential to attract more people. And in this case is is really worth it? Is it really THAT IMPORTANT to be prefixed? Is that the main conceptual selling point of Lisp?

But most importantly there are solutions that are not dirty:.

First nobody is forcing infix notation, one can have both at the same time (check Prolog :- op – you can do BOTH +(1 2) and 1+2).

Second hard-coding operators is not necessary at all: again check the Prolog suggestion. You can have all infix operators that you want (including none)

It is easy to conceptualize a superset of Lisp with infix notation and ZERO INITIAL infix operators.

If I can shout something is this: Check Prolog’s :- op ! Simple, elegant. And fully coherent with the Lisp philosophy at its core.

Social network sharing
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • DZone
  • Reddit
  • Slashdot
  • StumbleUpon
  • Technorati
  • LinkedIn
  • connotea
  • FriendFeed
  • Twitter
  • Yahoo! Bookmarks

3 Comments

  1. Patrick Logan says:

    Apparently a number of people like Java’s syntax, yet there are very few infix operators in Java. Nor can they be extended. Lack of infix operators in Lisp does not seem to be the reason for fear of Lisp’s sexprs.

    Infix math expressions go back decades in Lisp… they’re easy to implement. Most Lisp programmers don’t give two hoots and a holler for them, though.

    Anyway Lisp is deep, deeper than syntax. I think people are generally taught imperative programming, not applicative.

    Lisps tend to have better support for various mathematics than the curly-braced languages to boot, when it comes to semantics, richness, and accuracy.

    Whatever.

  2. tiago says:

    Interestingly, I never use Java in my examples. I use Prolog, a language that can do what Lisp do without resorting to the “hack on top” which is macros.

    The argument that I try to make comes precisely from the opposite direction of imperative programming: Comes from logic programming.

    I don’t know where I fail to get that message across. But considering that I hardly refer Java, I am starting to suspect some people read what they want to read, and not what I trying to transmit.

    Lisp obviously suffers from the same problem as Prolog: As it is really a nice and elegant solution, it tends to breed some level of arrogance. Understandable, but self-destructive at the end.

  3. zzorn says:

    In the end, aren’t all programming languages basically just synthetic sugar, on top of machine code (from an engineering perspective), or on top of a Turing machine / lambda calculus / or equivalent (from a theoretical perspective).

    Every move to a higher level programming language is just a layer of syntactic sugar converting the language constructs back to a lower level language.

    So from this perspective, syntactic sugar is needed for all languages, the interesting problem is finding out what syntactic sugar is best suited for a given purpose.

Leave a Reply