Sweet-expressions: A readable format for Lisp-like languages
1–10 of 84 posts
Re: Sweet-expressions: A readable format for Lisp-like languages
#2Almost like haml for Lisp. Cool.
Re: Sweet-expressions: A readable format for Lisp-like languages
#3Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them.
People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp.
[0] For large values of nobody
Re: Sweet-expressions: A readable format for Lisp-like languages
#4Sweet-expressions is for LISP as CoffeeScript is to Javascript :-)
Re: Sweet-expressions: A readable format for Lisp-like languages
#5Almost like haml for Lisp. Cool.
Yea, though you know I'm still attracted to Scheme b/c of its sweet sweet parens.
Re: Sweet-expressions: A readable format for Lisp-like languages
#6Sweet-expressions is for LISP as CoffeeScript is to Javascript :-)
This touches on the core of my enthusiasm about sweet-expressions. I'd like to make a "SweetScript" that compiles to JavaScript (via some lightweight lisp) and could essentially serve as a CoffeeScript with macros.
Would you find such a tool useful? What challenges would you foresee facing such a project?
Re: Sweet-expressions: A readable format for Lisp-like languages
#7Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them. People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp. [0] For large values of nobody
Because the people who "get" Lisp are almost always theoreticians who know what they want to code before they code it. They use Lisp as a write-only language. Meanwhile, working programmers avoid it, because it's very hard to step into someone else's Lisp codebase and understand it (and not just because of the fact that anything could mean anything due to macros—code is already visually indistinguishable from data without them.)
Languages, just like any other computer software, have a User Experience: the experience of programming in them. For example, the usual justification people give for why they like Ruby is that it has a good UX. There's no theoretical purity there, they just say it's "fun to code in."
Lisp, meanwhile, does not obey any of the principles of HCI that have been discovered in the last 30 years (how could it? It was invented before them!) There's a large gulf of evaluation stopping a programmer new to a Lisp codebase from understanding what their changes will do to it. UI design is about human psychology, not theoretical purity; solving this problem might seem like "papering over" the purity of the language from a theoretical perspective, but when doing actual comparative usability studies[1], it would be clear that the "papered-over" version would have something going for it that the theoretically-pure version does not.
[1] A comparative usability study on a language is very simple to perform: you basically print out some code samples, let people with no experience in the language (but general programming experience) read them for a set time period, and then evaluate their comprehension.
Re: Sweet-expressions: A readable format for Lisp-like languages
#8Somebody has invented a more conventional-looking syntax for Lisp every couple years since John McCarthy first suggested M-expressions. Nobody[0] has ever cared enough to use any of them. People who "get" Lisp get over any aversion to the syntax, and usually even come to appreciate it. People who can't get over the syntax never actually get Lisp. [0] For large values of nobody
I would really like to know more about these past proposals for conventional-looking syntax. I already know of a few, including the OP and SRFI 49 [1]. Could you offer any additional reading on the subject?
Some quotes from a different page on the OP's site [2] suggest that even some experienced lispers can see value in conventional syntax:
> I've used Lisp my whole programming life and I still don't find prefix math expressions natural. - Paul Graham
> After 13 years of doing Lisp and 3 or 4 years of Python, I agree: I prefer writing Lisp, but Python is easier to read. - John Wiseman
Personally, I hold no aversion to the parentheses. But I can see some advantages/uses for a more conventional syntax. Also, it's a fun problem. :)
---
Re: Sweet-expressions: A readable format for Lisp-like languages
#9I think that, for those of us who like Lisp, one of the things that draws us is the elegant simplicity of it all. There are lots of other languages that distinguish between expressions and statements, function calls and primitive operations, and all the rest of it.
It is undeniable that there are certain readability advantages to conforming a little more closely to the conventions from arithmetic notation, or just looking like C, which is the course most languages take.
But I believe that there are also very different readability advantages to a very simple, elegant, and consistent notation for representing a computation. There are fewer things you need to remember and translate in your head to express the program you want to write, or to understand the program you want to read.
For the record, I favor the approach Clojure took of making access to the reader out of bounds for the Clojure programmer, and assigning distinct semantics to the various paired characters on the keyboard: [] {} (). This breaks up the visual monotony of traditional S-expressions and improves readability. But remains simple, elegant, and consistent, in my opinion.
Re: Sweet-expressions: A readable format for Lisp-like languages
#10It's a clever design, and Wheeler makes a good case for it. Certainly my first reaction is "you'll have to pry my parentheses from my cold, dead fingers", but it's unarguable that a lot of people are repulsed by the syntax, even if the enlightened among us know it's actually beautiful.
He's right about the requirements for such a syntax: it has to mix well with the existing syntax, meaning, among other things, it must impose no semantics and it must not be necessary to write the operands of an infix expression in infix. I don't recall CGOL etc. getting the latter right. I also agree with him about the lack of a precedence scheme.
I have to admit, I can see making light use of the curly infix syntax in my own programs. I'm less sure what I think about the modern-expressions; I'd have to try them to see. I guess I can see some advantages. But I'm afraid I draw the line at significant whitespace. I know it works for Python, but Python was designed for it from the ground up. Looking at Wheeler's example, I'm not persuaded that it works as well for Lisp, though I commend him for his effort in designing it.