7 ms·

Sweet-expressions: A readable format for Lisp-like languages

85 points by evanrmurphy 16y ago

steveklabnik 16y ago
Almost like haml for Lisp. Cool.
- nickpinkston 16y ago
  Yea, though you know I'm still attracted to Scheme b/c of its sweet sweet parens.
Zak 16y ago
Somebody 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
- derefr 16y ago
  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.
  - neptun 16y ago
    >> Because the people who "get" Lisp are almost always theoreticians who know what they want to code before they code it. Nope, actually it's the other way around. People write a lot of prototypes which they rapidly evolve.
  - arethuza 16y ago
    Your "comparative usability study" is like sending someone with general familiarity of European languages to China and them concluding that Chinese is a "worse" language because it doesn't look like anything they have seen before. Most languages that have syntactic structures descended from Algol do all look the same so of course they are easier for someone with experience of one language in the family to understand than something else from a completely different heritage. I did a lot of programming in Common Lisp, so Scheme looks fairly sensible. Similarly I did a fair bit in PostScript - so I can sort of work out what is going on with Forth and other RPN languages. As for understanding large codebases in Lisp written by other people - a good Common Lisp environment (we used LispWorks) is about the best tool to dig around in other peoples code (largely because of the excellent REPL).
  - philwelch 16y ago
    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. There is a fairly prominent Lisper who argues the exact opposite; that Lisp is the ideal language for coding before knowing what you really want to code. I'd suggest reading Paul Graham's essays on the subject as a basis for discussing this particular point before going any further. 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." Ruby's usability is pretty nice, but it has some seriously cool theoretical ideas, too. It's a few steps beyond just putting a prettier interface on i.e. Java. It may not be the most original language, but it's popularizing a lot of things most "working programmers" haven't encountered. 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. That seems like a questionable metric for the quality of a programming language.
- evanrmurphy 16y ago
  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. :) --- [1] http://srfi.schemers.org/srfi-49/srfi-49.html http://srfi.schemers.org/srfi-49/srfi-49.html [2] http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/
  - paulitex 16y ago
    Shriram Krishnamurthi (author of PLAI http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/ http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/) recently suggested one: http://shriram.github.com/p4p/ http://shriram.github.com/p4p/ I've been meaning to go through it in detail, but to be honest I really like s-expressions, really really. I'd even say the regularity of syntax is one of lisp's greatest features (even Clojure's [] and {} literals are going too far for my taste...)
    - aufreak3 16y ago
      Thanks for that pointer. I never expected Shriram to propose one :) The parens are quite acceptable if you use syntax coloring options in DrRacket to make them light grey, which is what I do. Imo, P4P is just not worth the learning delta .. particularly because it doesn't solve the single biggest readability issue - math expressions - which exists even if you make all parens invisible. In my company, I came up with one myself (http://code.google.com/p/muvee-symbolic-expressions/wiki/TabSyntax http://code.google.com/p/muvee-symbolic-expressions/wiki/Tab...) when some aesthetic objections arose to the use of (paren (laden (scheme))) as a scripting language for our product. It is quite telling that we ended up not using the tab syntax in the end, though it is still available in the product :D
- lispm 16y ago
  The code as data as code as data ... idea is a feature of core Lisp. Not everybody 'gets' this feature and not everybody 'needs' this feature. Other than that there have been many conventional syntaxes derived from Lisp: Logo, ML, Dylan, ... What most of these don't have is the code as data as code as data ... support or at least it gets more difficult. If the representation via s-expressions is not needed, other syntaxes are not that difficult to implement...
- cageface 16y ago
  People who can't get over the syntax never actually get Lisp. So tired of hearing this from Lisp zealots. There are actually many intelligent people that understand lisp but don't think the plusses of the syntax outweigh the minuses.
  - cmiles74 16y ago
    I took this as meaning that the people who are really interested in reading and writing Lisp code eventually get over or even grow to appreciate s-expressions. Given that's the case, who are these people that would like to read and write Lisp but can't get past the parenthesis? Is there really a market for an alternate Lisp syntax? I think there probably is not. As you point out, there are many solid language choices that do not have Lispy syntax and a lot of very smart people being very productive with them. If the syntax bothers a person enough, this alternate syntax probably won't help.
    - merijnv 16y ago
      I agree with the grandparent that (contrary to the vague group of Lisp zealots mentioned) understand Lisp and hate the parentheses. On the other hand I also agree with you that there is probably not market/interest in this group of people to learn "Lisp with an alternate syntax". As someone with an interest in programming languages I do feel I have reasonable grasp on Lisp's s-expressions, but I dislike the parentheses syntax. However I don't think an alternate syntax would help me, most Lisp would still be parenthesis Lisp... I think most of people like me instead flock to functional languages like Haskell. As I mentioned in an earlier Haskell discussion I think Lisp's macros are probably more powerful (in the sense that they can express more then Haskell code), but like a lot of Haskell coders I just don't agree with the Lispers that this (slight?) increase in expressibility is worth the loss of readable Haskell syntax.
      - aerique 16y ago
        Are you from a maths background? I'm not and having played with Haskell a little the syntax is a real turn-off for me. For me Lisp is a lot more readable.
- python_padawan 16y ago
  "Well, all true Scotsmen like haggis." Or, for those who cannot draw the correlation: "Well, all true Lispers like parentheses." Never mind that pure functional programming is an ideal that even Lisp does not live up to. Think I'm throwing B.S. around? Try doing I/O in Lisp without side-effects. Now that we've established that Lisp is not at the top of the blub-curve, maybe we can get on with: 1. Writing functional languages people actually use. 2. Advancing the state-of-the-art in programming languages from being mired in a single-threaded monolithic server past. With respect to my second point, much progress has been made; but it is still underpinned by single-threaded programming language design. What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment.
  - p_nathan 16y ago
    I'm not convinced that Common Lisp is designed to be side-effect free (nor am I convinced that side-effects are an ideal to attain^H^H^H avoid, oops). Even Haskell has side-effects - just pushed into Monads.
    - gruseom 16y ago
      I'm not convinced that Common Lisp is designed to be side-effect free It certainly isn't! nor am I convinced that side-effects are an ideal to attain I assume you mean avoiding side-effects? I tend to agree. The style I favor is pretty free-wheeling with side-effects in small scopes (within a function or something smaller) and gets progressively more disciplined as the composed pieces get larger and larger. I find programming this way strikes a nice balance between the two styles (imperative and functional). It lets one write most algorithms in a straightforward, efficient way while providing much of the advantages of strictness. To sum up: side-effects within black boxes, side-effect-freeness outside them, and a lot of small, atomic, composable black boxes. This is a natural way to use Common Lisp. (Especially if you avoid CLOS like I do.)
      - p_nathan 16y ago
- loup-vaillant 16y ago
  People who actually get Lisp understand that S-expressions and surface syntax⁰ are orthogonal. "Ubiquitous parentheses" are one way to represent them. Sweet expressions are another. There is zero Lisper on this planet that think about "Ubiquitous parentheses" as the best possible syntax. Not even the seemingly fanatics of Lisp's "regular syntax". Proof: no one in her right mind (not even you) would prefer (quote X), or even (' x) over 'x. 'x is an irregularity that makes the whole thing terser, while using up less cognitive power. In other words, it's better. Now why stop there? You could try and remove more parentheses by using a tab syntax, or introduce a few other irregularities, or both. There's a good chance that we could come up with something better than the currently widely accepted surface syntax. Conclusion: it's perfectly possible to get Lisp and not surrender to it's standard syntax, because it may just not be the best. Besides, I'd think twice before suggesting that David A. Wheeler don't deeply understand Lisp. Now, knowing that the standard syntax is the only widely used one, one of course have to get over it to have a chance of understanding lisp. But if you only meant that, You hardly said anything at all¹. [0] When you wrote "syntax", I assumed you talked about surface syntax. [1] http://lesswrong.com/lw/jb/applause_lights/ http://lesswrong.com/lw/jb/applause_lights/ Edit (addendum): By the way, I'm surprised this issue isn't settled yet by structure editing. With a structure editor, programmers could choose the surface syntax they like independently of the underlying S-expression tree. (Incidentally, this could apply to any language, though with more difficulties.)
  - Zak 16y ago
    I'm sure David A. Wheeler gets Lisp - probably more than most of us. The creators of alternate syntax proposals almost always do, but they're usually not the intended market for their own proposals. Alternate syntax proposals are almost always written by Lisp proponents who want to make Lisp more accessible to others. In the article, Wheeler says the goal is to "provide a better notation that others can read". To quote pg: "Historically, languages designed for other people to use have been bad"[0]. I've found that to be true with most alternate syntax proposals I've read, including this one. I do not find it as readable as the original Scheme, nor is it as readable as Python. [0] http://www.paulgraham.com/javacover.html http://www.paulgraham.com/javacover.html
  - 16y ago
- dfox 16y ago
  As for nobody: Cadence SKILL is Lisp/Scheme that uses syntax that reasonably looks like M-expressions (+ some infix hacks). And I think that that counts as pretty substantial body of Lisp code.
woid 16y ago
Sweet-expressions is for LISP as CoffeeScript is to Javascript :-)
- evanrmurphy 16y ago
  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?
limmeau 16y ago
I liked the somewhat elegant heuristic for general infix-to-prefix conversion: <quote> {...} contains an "infix list". If the enclosed infix list has (1) an odd number of parameters, (2) at least 3 parameters, and (3) all even parameters are the same symbol, then it is mapped to "(even-parameter odd-parameters)". Otherwise, it is mapped to "(nfx list)" — you'll need to have a macro named "nfx" to use it </quote> That being said, (still-prefer 'I (using 'parentheses :in 'Scheme)). Now, if someone added mix-fix syntax to Scheme...
neptun 16y ago
Well, that's just plain stupid. When will people who don't get Lisp acknowledge, that the syntax is that way on purpose, to allow easy metaprogramming? It's not a bug, it's a feature!! When I program in other languages, I see just a bunch of rubbish useless noise, stupid operator preference issues, and very inelegant lambda lists. With Lisp, all the syntax issues goes away, and the code looks absolutely lovely.
jpr 16y ago
It's funny that Lisp's "syntax" draws so much attention when it is pretty much the simplest and most unambiguous syntax possible, and that messes like C++, Python and Perl don't seem to bother anyone enough to propose alternatives.
- silentbicycle 16y ago
  It's yet another case of people getting hung up on the first obviously different thing they notice about a language. If somebody is still griping about the parens in Lisp, the significant whitespace in Python, the glyphs in APL, etc., they haven't gotten to the differences that actually make the language interesting - either they'll get used to it like the other X programmers (and realize it wasn't as big an issue as they thought), or they'll find deeper issues in the language design to complain about (and probably give up on it).
yason 16y ago
The new and "readable" syntax looks truly ugly compared to the S-expression counterparts. Why is it that some people dread parentheses so badly and other people just never mind and choose to spend the time working with them? The main reason I consider parentheses and S-expressions superior to other syntax is that it allows for flexible navigation in the source code. I can move forward and backward, upward and inward in the tree, unit-by-unit and the unit can be a literal or a compound S-expression or anything and it just works the same. (At least in Emacs.)
- gruseom 16y ago
  Why is it that some people dread parentheses so badly Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together: 1. the human brain craves familiarity; 2. people love bike sheds. (Bike shed = something anybody can have an opinion and argue about irrespective of knowledge or effort. Since their purpose is to jump into the argument, these opinions tend to be strong ones, diminishing the likelihood of any resolution. Indeed, a feature of such discussions is that they are argument for argument's sake, and thus no resolution is possible or even desirable.)
  - evanrmurphy 16y ago
    > Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together Parentheses (and along with them s-expressions and macros) are one of the few characteristics still unique to Lisp. Most of the other features - including GC, dynamic typing, first-class functions and lexical scoping - are now shared with other programming languages as well.
jimbokun 16y ago
I 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.
ScottBurson 16y ago
It'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.
- ScottBurson 16y ago
  Having the infix expression reader fall back to emitting calls to a user-provided `nfx' macro seems clever at first glance, but it's insufficient. Different programs/libraries are likely to likely to implement `nfx' in different ways, and thus step on each other. I think (for Common Lisp) it will be necessary to do something like this: create a generic function `translate-nfx' which uses `eql' dispatching on the first operator, and set up the `nfx' macro to call it: (defmacro nfx (&rest stuff) (translate-nfx (cadr stuff) stuff)) (defmethod translate-nfx ((op (eql '+)) stuff) ...) This creates an extensible framework where packages can supply `translate-nfx' methods for their operations. It would probably be worth predefining methods for CL arithmetic operations, so that users don't wind up doing that in incompatible ways. I'm afraid that means choosing a precedence scheme, which Wheeler was trying to avoid (for good reason); I don't see a way around it, though.
dish 16y ago
Is it just me, or does that look like Python?
sedachv 16y ago
I've worked with programs in half a dozen Lisp dialects and everyone who claims Lisp is hard to understand because of the syntax is wrong. The only reason I could work with so many dialects and so many programs is because the syntax is uniform. If you think you have an idea for how to "improve" Lisp syntax that involves an ambiguous infix grammar, please stop trolling and go write some Python.
- silentbicycle 16y ago
  Some people seem to have a hard time with deeply nesting languages. Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". I'm fine with heavily nested Lisp-y code, but chaining code feels very awkward to me. Self and Prolog both have well-designed, completely unambiguous grammars. People interested in syntax design (or "fixing" Lisp) would do well to look at those, rather than trying to force a pseudo-Python syntax on Lisp. Python's grammar has too many edge cases. (Lua's syntax is also quite simple, though not as much as Self's.) In the end, clear semantics are at least as important as a good syntax. Lisp has very clear semantics. So do ML and Erlang, another language which has a bit of a quirky syntax.
  - sedachv 16y ago
    "Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". " The thing with fluent interfaces is they're identical to nested Lisp code, except they read left to right instead of right to left. I suspect writers of Hebrew and Arabic would find chaining to be more confusing than nested Lisp code for that reason. Also worth noting is that a popular style of indenting chained fluent calls is by splitting them by lines, like: someObj.method(arg) .otherMethod(arg2) .om3(a4) .om4(a5); That's not that different from formatting Lisp code.
evanrmurphy 16y ago
Update: The page at http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/ appears to be the project's homepage.
erikb 16y ago
I am not a big fan of lisp, but u can not really change the lisp syntax and have lisp anymore. (+ 1 2) has more features included then '1+2', because u can for example add 3 numbers easily like (+ 1 2 3) and you can treat all that as a list and parse it to whatever u need, recurse over it and so on. With a "better" syntax u just don't have these features anymore. Someone who would use sweet-expressions actually has not understood lisp yet. But like the mouse mode in Vi, it might be a useful tool to make new lispers more comfortable. So I still like the idea!
- Kliment 16y ago
  I think you've misunderstood. This does not take away any of those issues. With this setup, you can write (+ 1 2 3) or +(1 2 3) or (1 + 2 + 3) and they would all translate into (+ 1 2 3). You can treat any of them as a list. You can still parse, transform, do anything with it. There is no loss of functionality here. Think of it as a macro that aliases "plus" to +. There is no difference between (plus 1 2 3) and (+ 1 2 3) in a macro defined in this way. They are S-expressions under an invisibility cloak. But they're still S-expressions within.
  - erikb 16y ago
    I understand your point and how this macro works. My point is, that you still have to think in this (+ 1 2 3) way to be able to write meaningful, recursive, 'code is data' like functions. If u think (func_name param_1 param_2 param_3) you will easily get a recursive solution for a recursive problem. And if you think that way anyway, what's the point in writing (1 + 2 + 3) in your code? It will just confuse the lisp mode in your brain. I also think it is hard to get into this mode. But like this way of writing is not basically intuitive, so is recursive thinking and 'code is data' to me (and so I guess it will be the same for other people). It needs some time of meditating to get into lisp mode and it also needs some months of training. But when you are there, everything works together, because it works in the same way. Or to say it like Bruce Lee: You must be water my friend. When you fill water into a bottle, it becomes the bottle. If you fill water in a cup, it becomes the cup. (And if u put it in braces it becomes a lisp expression: (begin (water) (q_e_d))).
shaunxcode 16y ago
once you "get" lisp anything beside s-expressions/prefix notation feels "inside out" and asymmetrical. I think [ ] and { } should be reserved for things like dicts, vectors or lambdas.
- silentbicycle 16y ago
  Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird. My personal preference is infix without operator precedence (like APL and Smalltalk) or postfix (like Forth). All-prefix, all-postfix, or all-infix consistently make sense. Infix with arbitrary transposition due to historical "order of operation" doesn't, but it's the common convention, and minor changes to it (e.g. +. for floating-point-addition in OCaml) seem to really piss people off. Most other function calls are already in prefix notation, people just think (f x y) is totally weird, while f(x, y) is normal. Cognitive dissonance. Also, I think it's cute that Prolog sticks all arithmetic under an "is" operator ("X is Y+Z*3"), rather than letting it dominate the language the way it usually tends to.
  - zephyrfalcon 16y ago
    "Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird." But that is just because you learned the conventional notation from a very young age, right? We all did, hence the name "conventional". When we learned to add and subtract, we also learned that the notation was 2+3, not (+ 2 3). That's why any other notation feels "unnatural". I do wonder if it would be possible to teach kids prefix notation instead, and whether such notation would seem completely natural to them. (I suspect the answer to both is yes.)
    - silentbicycle 16y ago
      I learned arithmetic at a young age, yes (and I taught myself BASIC when I was 5-6ish). My main objection to prefix notation for arithmetic is that it's cumbersome. Mostly because if the arity of ops aren't predefined (e.g., + isn't limited to 2 arguments), parenthesis are needed for grouping. Infix, w/ order of op: y^2*(6x^3 - 3x^2 + 2x - 9) Prefix: (* (^ y 2) (+ (* 6 (^ x 3)) (* -3 (^ x 2)) (* 2 x) -9)) Infix, no order of op: y^2*((6* x^3) - (3* x^2) + (2* x) - 9) But as long as we're talking polynomials, J wins, IMHO: (y^2)*+/_9 2 _3 6*(x^i.4)
Vivtek 16y ago
Wow. Speaking as somebody who's bounced off Lisp more than once, I find this really attractive.
ohyes 16y ago
The parens are a cue so that the editor indents my code properly. How do you propose to make emacs auto-indent sweet expressions? It seems that I would have to manually do that as indentation would convey meaning. Whitespace is a notorious pain in the ass to get right, parens are visible, countable, and highlight-able. Infix is stupidly ambiguous and is the cause of multitudes of errors; a 'natural' way to describe math or not. (There is a reason some prefer the reverse polish calculator). Anyway, I don't 'get' the 'aversion' the syntax is trivial to explain and it keeps me from having to remember fiddly rules. Use a proper editor to indent/highlight/reformat, and it is as good as any other syntax. (If you want Lisp to be popular, just get Justin Beiber to write a song about it).
- Xuzz 16y ago
  People claim the same issue with Python, but I don't think it's really hurt anyone much. It's usually very obvious and auto-indent is surprisingly possible on a lot of it.
- cturner 16y ago
  I agree that sexpr are the best syntax out there for a language because it's consistent and simple. However, this expression thing is a good idea. I've been waiting for something like this for a while. Anyway, I don't 'get' the 'aversion' the syntax is trivial to explain [etc] Although you mightn't get it, I'm sure you have run into it a bit and realise it's widespread. Perhaps nine in ten people who identify as programmers would dislike it. The practice of ignoring that hasn't done any favours for lisp takeup. It's still a fringe language. Like the author says, But most software developers have abandoned Lisp precisely because of Lisp's hideous, inadequate notation This syntax is a gateway that allows you to smuggle lisp into a workplace. It looks like python. When people ask about what you're doing you say "Oh, that's this cool language called Racket. As you can see, it reads a lot like python, but I've found it allows me to do xyz nicely. Here, let me show you how this script works." Then you would show them the script, perhaps show them a repl tool that appears to work just like python's and they'd be able to get around your your scripts as much as they can around your existing python code. Sweet! How do you propose to make emacs auto-indent sweet expressions? You could have emacs auto-transform into sexpr when you loaded a file, and save to sweet expressions when you saved. Should be trivial. From your perspective, you could like in a sexpr world. Except when you were stepping your colleague through the code - remember to vi for that bit. Otherwise the game will be up.
ses 16y ago
Well from the perspective of a programmer that doesn't know lisp, and has been put off in the past due to its syntax: I find this dialect much more appealing. Nested round brackets are pretty horrible to read / parse. Whether it destroys the essence of what lisp is all about is another matter, but I suspect it doesn't at all.
agentultra 16y ago
Isn't Lisp awesome? It's flexible enough that you can write an alternate syntax, develop your own semantics and grammar, and build the language you work best in on top of it. I don't think I've come across another language that can actually do these sorts of things so well (or at all for that matter). Viva Lisp!
bitwize 16y ago
"Ugly" s-expressions? I find them to be quite beautiful, like matryoshka dolls. I am a bit disappointed when I have to work on code that doesn't manifest its own structure so explicity, looking like a tangle of words and punctuation down the page, like what becomes of balls of yarn after a kitten has gotten through with them.

85 points by evanrmurphy 16y ago

steveklabnik 16y ago

Almost like haml for Lisp. Cool.

nickpinkston 16y ago
Yea, though you know I'm still attracted to Scheme b/c of its sweet sweet parens.

Zak 16y ago

Somebody 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

derefr 16y ago
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.
- neptun 16y ago
  >> Because the people who "get" Lisp are almost always theoreticians who know what they want to code before they code it. Nope, actually it's the other way around. People write a lot of prototypes which they rapidly evolve.
- arethuza 16y ago
  Your "comparative usability study" is like sending someone with general familiarity of European languages to China and them concluding that Chinese is a "worse" language because it doesn't look like anything they have seen before. Most languages that have syntactic structures descended from Algol do all look the same so of course they are easier for someone with experience of one language in the family to understand than something else from a completely different heritage. I did a lot of programming in Common Lisp, so Scheme looks fairly sensible. Similarly I did a fair bit in PostScript - so I can sort of work out what is going on with Forth and other RPN languages. As for understanding large codebases in Lisp written by other people - a good Common Lisp environment (we used LispWorks) is about the best tool to dig around in other peoples code (largely because of the excellent REPL).
- philwelch 16y ago
  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. There is a fairly prominent Lisper who argues the exact opposite; that Lisp is the ideal language for coding before knowing what you really want to code. I'd suggest reading Paul Graham's essays on the subject as a basis for discussing this particular point before going any further. 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." Ruby's usability is pretty nice, but it has some seriously cool theoretical ideas, too. It's a few steps beyond just putting a prettier interface on i.e. Java. It may not be the most original language, but it's popularizing a lot of things most "working programmers" haven't encountered. 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. That seems like a questionable metric for the quality of a programming language.
evanrmurphy 16y ago
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. :) --- [1] http://srfi.schemers.org/srfi-49/srfi-49.html http://srfi.schemers.org/srfi-49/srfi-49.html [2] http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/
- paulitex 16y ago
  Shriram Krishnamurthi (author of PLAI http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/ http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/) recently suggested one: http://shriram.github.com/p4p/ http://shriram.github.com/p4p/ I've been meaning to go through it in detail, but to be honest I really like s-expressions, really really. I'd even say the regularity of syntax is one of lisp's greatest features (even Clojure's [] and {} literals are going too far for my taste...)
  - aufreak3 16y ago
    Thanks for that pointer. I never expected Shriram to propose one :) The parens are quite acceptable if you use syntax coloring options in DrRacket to make them light grey, which is what I do. Imo, P4P is just not worth the learning delta .. particularly because it doesn't solve the single biggest readability issue - math expressions - which exists even if you make all parens invisible. In my company, I came up with one myself (http://code.google.com/p/muvee-symbolic-expressions/wiki/TabSyntax http://code.google.com/p/muvee-symbolic-expressions/wiki/Tab...) when some aesthetic objections arose to the use of (paren (laden (scheme))) as a scripting language for our product. It is quite telling that we ended up not using the tab syntax in the end, though it is still available in the product :D
lispm 16y ago
The code as data as code as data ... idea is a feature of core Lisp. Not everybody 'gets' this feature and not everybody 'needs' this feature. Other than that there have been many conventional syntaxes derived from Lisp: Logo, ML, Dylan, ... What most of these don't have is the code as data as code as data ... support or at least it gets more difficult. If the representation via s-expressions is not needed, other syntaxes are not that difficult to implement...
cageface 16y ago
People who can't get over the syntax never actually get Lisp. So tired of hearing this from Lisp zealots. There are actually many intelligent people that understand lisp but don't think the plusses of the syntax outweigh the minuses.
- cmiles74 16y ago
  I took this as meaning that the people who are really interested in reading and writing Lisp code eventually get over or even grow to appreciate s-expressions. Given that's the case, who are these people that would like to read and write Lisp but can't get past the parenthesis? Is there really a market for an alternate Lisp syntax? I think there probably is not. As you point out, there are many solid language choices that do not have Lispy syntax and a lot of very smart people being very productive with them. If the syntax bothers a person enough, this alternate syntax probably won't help.
  - merijnv 16y ago
    I agree with the grandparent that (contrary to the vague group of Lisp zealots mentioned) understand Lisp and hate the parentheses. On the other hand I also agree with you that there is probably not market/interest in this group of people to learn "Lisp with an alternate syntax". As someone with an interest in programming languages I do feel I have reasonable grasp on Lisp's s-expressions, but I dislike the parentheses syntax. However I don't think an alternate syntax would help me, most Lisp would still be parenthesis Lisp... I think most of people like me instead flock to functional languages like Haskell. As I mentioned in an earlier Haskell discussion I think Lisp's macros are probably more powerful (in the sense that they can express more then Haskell code), but like a lot of Haskell coders I just don't agree with the Lispers that this (slight?) increase in expressibility is worth the loss of readable Haskell syntax.
    - aerique 16y ago
      Are you from a maths background? I'm not and having played with Haskell a little the syntax is a real turn-off for me. For me Lisp is a lot more readable.
python_padawan 16y ago
"Well, all true Scotsmen like haggis." Or, for those who cannot draw the correlation: "Well, all true Lispers like parentheses." Never mind that pure functional programming is an ideal that even Lisp does not live up to. Think I'm throwing B.S. around? Try doing I/O in Lisp without side-effects. Now that we've established that Lisp is not at the top of the blub-curve, maybe we can get on with: 1. Writing functional languages people actually use. 2. Advancing the state-of-the-art in programming languages from being mired in a single-threaded monolithic server past. With respect to my second point, much progress has been made; but it is still underpinned by single-threaded programming language design. What we need is someone who truly groks multiprocessor, multi-threaded, heterogeneous run-time environments; and from that knowledge can write a language to take advantage of such an environment.
- p_nathan 16y ago
  I'm not convinced that Common Lisp is designed to be side-effect free (nor am I convinced that side-effects are an ideal to attain^H^H^H avoid, oops). Even Haskell has side-effects - just pushed into Monads.
  - gruseom 16y ago
    I'm not convinced that Common Lisp is designed to be side-effect free It certainly isn't! nor am I convinced that side-effects are an ideal to attain I assume you mean avoiding side-effects? I tend to agree. The style I favor is pretty free-wheeling with side-effects in small scopes (within a function or something smaller) and gets progressively more disciplined as the composed pieces get larger and larger. I find programming this way strikes a nice balance between the two styles (imperative and functional). It lets one write most algorithms in a straightforward, efficient way while providing much of the advantages of strictness. To sum up: side-effects within black boxes, side-effect-freeness outside them, and a lot of small, atomic, composable black boxes. This is a natural way to use Common Lisp. (Especially if you avoid CLOS like I do.)
    - p_nathan 16y ago
loup-vaillant 16y ago
People who actually get Lisp understand that S-expressions and surface syntax⁰ are orthogonal. "Ubiquitous parentheses" are one way to represent them. Sweet expressions are another. There is zero Lisper on this planet that think about "Ubiquitous parentheses" as the best possible syntax. Not even the seemingly fanatics of Lisp's "regular syntax". Proof: no one in her right mind (not even you) would prefer (quote X), or even (' x) over 'x. 'x is an irregularity that makes the whole thing terser, while using up less cognitive power. In other words, it's better. Now why stop there? You could try and remove more parentheses by using a tab syntax, or introduce a few other irregularities, or both. There's a good chance that we could come up with something better than the currently widely accepted surface syntax. Conclusion: it's perfectly possible to get Lisp and not surrender to it's standard syntax, because it may just not be the best. Besides, I'd think twice before suggesting that David A. Wheeler don't deeply understand Lisp. Now, knowing that the standard syntax is the only widely used one, one of course have to get over it to have a chance of understanding lisp. But if you only meant that, You hardly said anything at all¹. [0] When you wrote "syntax", I assumed you talked about surface syntax. [1] http://lesswrong.com/lw/jb/applause_lights/ http://lesswrong.com/lw/jb/applause_lights/ Edit (addendum): By the way, I'm surprised this issue isn't settled yet by structure editing. With a structure editor, programmers could choose the surface syntax they like independently of the underlying S-expression tree. (Incidentally, this could apply to any language, though with more difficulties.)
- Zak 16y ago
  I'm sure David A. Wheeler gets Lisp - probably more than most of us. The creators of alternate syntax proposals almost always do, but they're usually not the intended market for their own proposals. Alternate syntax proposals are almost always written by Lisp proponents who want to make Lisp more accessible to others. In the article, Wheeler says the goal is to "provide a better notation that others can read". To quote pg: "Historically, languages designed for other people to use have been bad"[0]. I've found that to be true with most alternate syntax proposals I've read, including this one. I do not find it as readable as the original Scheme, nor is it as readable as Python. [0] http://www.paulgraham.com/javacover.html http://www.paulgraham.com/javacover.html
- 16y ago
dfox 16y ago
As for nobody: Cadence SKILL is Lisp/Scheme that uses syntax that reasonably looks like M-expressions (+ some infix hacks). And I think that that counts as pretty substantial body of Lisp code.

woid 16y ago

Sweet-expressions is for LISP as CoffeeScript is to Javascript :-)

evanrmurphy 16y ago
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?

limmeau 16y ago

I liked the somewhat elegant heuristic for general infix-to-prefix conversion: <quote> {...} contains an "infix list". If the enclosed infix list has (1) an odd number of parameters, (2) at least 3 parameters, and (3) all even parameters are the same symbol, then it is mapped to "(even-parameter odd-parameters)". Otherwise, it is mapped to "(nfx list)" — you'll need to have a macro named "nfx" to use it </quote> That being said, (still-prefer 'I (using 'parentheses :in 'Scheme)). Now, if someone added mix-fix syntax to Scheme...

neptun 16y ago

Well, that's just plain stupid. When will people who don't get Lisp acknowledge, that the syntax is that way on purpose, to allow easy metaprogramming? It's not a bug, it's a feature!! When I program in other languages, I see just a bunch of rubbish useless noise, stupid operator preference issues, and very inelegant lambda lists. With Lisp, all the syntax issues goes away, and the code looks absolutely lovely.

jpr 16y ago

It's funny that Lisp's "syntax" draws so much attention when it is pretty much the simplest and most unambiguous syntax possible, and that messes like C++, Python and Perl don't seem to bother anyone enough to propose alternatives.

silentbicycle 16y ago
It's yet another case of people getting hung up on the first obviously different thing they notice about a language. If somebody is still griping about the parens in Lisp, the significant whitespace in Python, the glyphs in APL, etc., they haven't gotten to the differences that actually make the language interesting - either they'll get used to it like the other X programmers (and realize it wasn't as big an issue as they thought), or they'll find deeper issues in the language design to complain about (and probably give up on it).

yason 16y ago

The new and "readable" syntax looks truly ugly compared to the S-expression counterparts. Why is it that some people dread parentheses so badly and other people just never mind and choose to spend the time working with them? The main reason I consider parentheses and S-expressions superior to other syntax is that it allows for flexible navigation in the source code. I can move forward and backward, upward and inward in the tree, unit-by-unit and the unit can be a literal or a compound S-expression or anything and it just works the same. (At least in Emacs.)

gruseom 16y ago
Why is it that some people dread parentheses so badly Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together: 1. the human brain craves familiarity; 2. people love bike sheds. (Bike shed = something anybody can have an opinion and argue about irrespective of knowledge or effort. Since their purpose is to jump into the argument, these opinions tend to be strong ones, diminishing the likelihood of any resolution. Indeed, a feature of such discussions is that they are argument for argument's sake, and thus no resolution is possible or even desirable.)
- evanrmurphy 16y ago
  > Two tendencies combine to make "parentheses" the Lisp topic that in sheer quantity dwarfs all other Lisp topics added together Parentheses (and along with them s-expressions and macros) are one of the few characteristics still unique to Lisp. Most of the other features - including GC, dynamic typing, first-class functions and lexical scoping - are now shared with other programming languages as well.

jimbokun 16y ago

I 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.

ScottBurson 16y ago

It'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.

ScottBurson 16y ago
Having the infix expression reader fall back to emitting calls to a user-provided `nfx' macro seems clever at first glance, but it's insufficient. Different programs/libraries are likely to likely to implement `nfx' in different ways, and thus step on each other. I think (for Common Lisp) it will be necessary to do something like this: create a generic function `translate-nfx' which uses `eql' dispatching on the first operator, and set up the `nfx' macro to call it: (defmacro nfx (&rest stuff) (translate-nfx (cadr stuff) stuff)) (defmethod translate-nfx ((op (eql '+)) stuff) ...) This creates an extensible framework where packages can supply `translate-nfx' methods for their operations. It would probably be worth predefining methods for CL arithmetic operations, so that users don't wind up doing that in incompatible ways. I'm afraid that means choosing a precedence scheme, which Wheeler was trying to avoid (for good reason); I don't see a way around it, though.

dish 16y ago

Is it just me, or does that look like Python?

sedachv 16y ago

I've worked with programs in half a dozen Lisp dialects and everyone who claims Lisp is hard to understand because of the syntax is wrong. The only reason I could work with so many dialects and so many programs is because the syntax is uniform. If you think you have an idea for how to "improve" Lisp syntax that involves an ambiguous infix grammar, please stop trolling and go write some Python.

silentbicycle 16y ago
Some people seem to have a hard time with deeply nesting languages. Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". I'm fine with heavily nested Lisp-y code, but chaining code feels very awkward to me. Self and Prolog both have well-designed, completely unambiguous grammars. People interested in syntax design (or "fixing" Lisp) would do well to look at those, rather than trying to force a pseudo-Python syntax on Lisp. Python's grammar has too many edge cases. (Lua's syntax is also quite simple, though not as much as Self's.) In the end, clear semantics are at least as important as a good syntax. Lisp has very clear semantics. So do ML and Erlang, another language which has a bit of a quirky syntax.
- sedachv 16y ago
  "Anecdotally, they seem to prefer "chaining" constructs, like "someObj.method(arg).otherMethod(arg2).om3(a4).om4(a5)". " The thing with fluent interfaces is they're identical to nested Lisp code, except they read left to right instead of right to left. I suspect writers of Hebrew and Arabic would find chaining to be more confusing than nested Lisp code for that reason. Also worth noting is that a popular style of indenting chained fluent calls is by splitting them by lines, like: someObj.method(arg) .otherMethod(arg2) .om3(a4) .om4(a5); That's not that different from formatting Lisp code.

evanrmurphy 16y ago

Update: The page at http://www.dwheeler.com/readable/ http://www.dwheeler.com/readable/ appears to be the project's homepage.

erikb 16y ago

I am not a big fan of lisp, but u can not really change the lisp syntax and have lisp anymore. (+ 1 2) has more features included then '1+2', because u can for example add 3 numbers easily like (+ 1 2 3) and you can treat all that as a list and parse it to whatever u need, recurse over it and so on. With a "better" syntax u just don't have these features anymore. Someone who would use sweet-expressions actually has not understood lisp yet. But like the mouse mode in Vi, it might be a useful tool to make new lispers more comfortable. So I still like the idea!

Kliment 16y ago
I think you've misunderstood. This does not take away any of those issues. With this setup, you can write (+ 1 2 3) or +(1 2 3) or (1 + 2 + 3) and they would all translate into (+ 1 2 3). You can treat any of them as a list. You can still parse, transform, do anything with it. There is no loss of functionality here. Think of it as a macro that aliases "plus" to +. There is no difference between (plus 1 2 3) and (+ 1 2 3) in a macro defined in this way. They are S-expressions under an invisibility cloak. But they're still S-expressions within.
- erikb 16y ago
  I understand your point and how this macro works. My point is, that you still have to think in this (+ 1 2 3) way to be able to write meaningful, recursive, 'code is data' like functions. If u think (func_name param_1 param_2 param_3) you will easily get a recursive solution for a recursive problem. And if you think that way anyway, what's the point in writing (1 + 2 + 3) in your code? It will just confuse the lisp mode in your brain. I also think it is hard to get into this mode. But like this way of writing is not basically intuitive, so is recursive thinking and 'code is data' to me (and so I guess it will be the same for other people). It needs some time of meditating to get into lisp mode and it also needs some months of training. But when you are there, everything works together, because it works in the same way. Or to say it like Bruce Lee: You must be water my friend. When you fill water into a bottle, it becomes the bottle. If you fill water in a cup, it becomes the cup. (And if u put it in braces it becomes a lisp expression: (begin (water) (q_e_d))).

shaunxcode 16y ago

once you "get" lisp anything beside s-expressions/prefix notation feels "inside out" and asymmetrical. I think [ ] and { } should be reserved for things like dicts, vectors or lambdas.

silentbicycle 16y ago
Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird. My personal preference is infix without operator precedence (like APL and Smalltalk) or postfix (like Forth). All-prefix, all-postfix, or all-infix consistently make sense. Infix with arbitrary transposition due to historical "order of operation" doesn't, but it's the common convention, and minor changes to it (e.g. +. for floating-point-addition in OCaml) seem to really piss people off. Most other function calls are already in prefix notation, people just think (f x y) is totally weird, while f(x, y) is normal. Cognitive dissonance. Also, I think it's cute that Prolog sticks all arithmetic under an "is" operator ("X is Y+Z*3"), rather than letting it dominate the language the way it usually tends to.
- zephyrfalcon 16y ago
  "Mostly agreed, but I've used Lisps for years, and prefix for arithmetic still feels weird." But that is just because you learned the conventional notation from a very young age, right? We all did, hence the name "conventional". When we learned to add and subtract, we also learned that the notation was 2+3, not (+ 2 3). That's why any other notation feels "unnatural". I do wonder if it would be possible to teach kids prefix notation instead, and whether such notation would seem completely natural to them. (I suspect the answer to both is yes.)
  - silentbicycle 16y ago
    I learned arithmetic at a young age, yes (and I taught myself BASIC when I was 5-6ish). My main objection to prefix notation for arithmetic is that it's cumbersome. Mostly because if the arity of ops aren't predefined (e.g., + isn't limited to 2 arguments), parenthesis are needed for grouping. Infix, w/ order of op: y^2*(6x^3 - 3x^2 + 2x - 9) Prefix: (* (^ y 2) (+ (* 6 (^ x 3)) (* -3 (^ x 2)) (* 2 x) -9)) Infix, no order of op: y^2*((6* x^3) - (3* x^2) + (2* x) - 9) But as long as we're talking polynomials, J wins, IMHO: (y^2)*+/_9 2 _3 6*(x^i.4)

Vivtek 16y ago

Wow. Speaking as somebody who's bounced off Lisp more than once, I find this really attractive.

ohyes 16y ago

The parens are a cue so that the editor indents my code properly. How do you propose to make emacs auto-indent sweet expressions? It seems that I would have to manually do that as indentation would convey meaning. Whitespace is a notorious pain in the ass to get right, parens are visible, countable, and highlight-able. Infix is stupidly ambiguous and is the cause of multitudes of errors; a 'natural' way to describe math or not. (There is a reason some prefer the reverse polish calculator). Anyway, I don't 'get' the 'aversion' the syntax is trivial to explain and it keeps me from having to remember fiddly rules. Use a proper editor to indent/highlight/reformat, and it is as good as any other syntax. (If you want Lisp to be popular, just get Justin Beiber to write a song about it).

Xuzz 16y ago
People claim the same issue with Python, but I don't think it's really hurt anyone much. It's usually very obvious and auto-indent is surprisingly possible on a lot of it.
cturner 16y ago
I agree that sexpr are the best syntax out there for a language because it's consistent and simple. However, this expression thing is a good idea. I've been waiting for something like this for a while. Anyway, I don't 'get' the 'aversion' the syntax is trivial to explain [etc] Although you mightn't get it, I'm sure you have run into it a bit and realise it's widespread. Perhaps nine in ten people who identify as programmers would dislike it. The practice of ignoring that hasn't done any favours for lisp takeup. It's still a fringe language. Like the author says, But most software developers have abandoned Lisp precisely because of Lisp's hideous, inadequate notation This syntax is a gateway that allows you to smuggle lisp into a workplace. It looks like python. When people ask about what you're doing you say "Oh, that's this cool language called Racket. As you can see, it reads a lot like python, but I've found it allows me to do xyz nicely. Here, let me show you how this script works." Then you would show them the script, perhaps show them a repl tool that appears to work just like python's and they'd be able to get around your your scripts as much as they can around your existing python code. Sweet! How do you propose to make emacs auto-indent sweet expressions? You could have emacs auto-transform into sexpr when you loaded a file, and save to sweet expressions when you saved. Should be trivial. From your perspective, you could like in a sexpr world. Except when you were stepping your colleague through the code - remember to vi for that bit. Otherwise the game will be up.

ses 16y ago

Well from the perspective of a programmer that doesn't know lisp, and has been put off in the past due to its syntax: I find this dialect much more appealing. Nested round brackets are pretty horrible to read / parse. Whether it destroys the essence of what lisp is all about is another matter, but I suspect it doesn't at all.

agentultra 16y ago

Isn't Lisp awesome? It's flexible enough that you can write an alternate syntax, develop your own semantics and grammar, and build the language you work best in on top of it. I don't think I've come across another language that can actually do these sorts of things so well (or at all for that matter). Viva Lisp!

bitwize 16y ago

"Ugly" s-expressions? I find them to be quite beautiful, like matryoshka dolls. I am a bit disappointed when I have to work on code that doesn't manifest its own structure so explicity, looking like a tangle of words and punctuation down the page, like what becomes of balls of yarn after a kitten has gotten through with them.