Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dwheeler.com

Post reply on HN
Print view View original

31–40 of 84 posts

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

#31

Post by p_nathan »

gruseom wrote: post #28
p_nathan wrote: post #27

Earlier quoted context omitted.

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.

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 pr…

Agreed.

I tend to make sure that side-effects are limited to some "block" of code (function/class/module/whatever).

I just don't see the problem with syntax much anymore - Python syntax bugs me - a language's usability for the practitioner of the language works around the axis of semantics and maintainability far more than syntax. Obviously J, APL, and egregarious abuses of Perl are examples of syntactical issues, but, as was once said, one can write COBOL in any language....

I'd rather go with the powerful semantics and boring syntax of Lisp. I like this image- http://img264.imageshack.us/img264/1397/lispnd7.png.

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

#32

Post by derefr »

sedachv wrote: post #26
derefr wrote: post #23

Earlier quoted context omitted.

> That's just stupid. If the programmer doesn't understand English and the program is written with English identifiers, does that fail the test? What about APL and Perl? It's called a comparative usability study. The same person looks at the same code sample written in two different languages, A and B (in random order), given time T to absorb each one (where T is much less than the time it would actually take to full…

"Also, you wouldn't be comparing, say, Java to APL. You'd be comparing Java to Java + "an unless statement", or APL to APL + "enforced whitespace." You want to see the relative worth of language features, not the relative worth of our current languages, which have mostly been slapped together with no concern for UX. The result of such a study would be a set of UX suggestions, of language features that comparatively i…

You ignored the most important part of what I said.

> Thus, if the test-taker doesn't know English, they get the same (low) score on both tests—to the BNN, that is the same as "no new evidence."

So, of course, you wouldn't test APL vs. APL+whitespace on someone who doesn't know APL, because your test results would always, predictably, be 1:1. But you wouldn't be testing APL vs. anything—because APL is a set of design choices that have already been made, and anyone who knows APL would already have taken the time to absorb those design choices. It would be most scientifically rigorous, as I said, to start with a made-up programming language (a random combination of language features that has no overarching design principle which users could recognize to reduce cognitive load), teach it to the users, and then do the tests on that language, vs. that language w/ modifications.

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

#33

Post by euccastro »

raganwald wrote: post #12
derefr wrote: post #7

Earlier quoted context omitted.

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 wi…

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 is just one axis of usability, optimizing for comprehension by someone unfamiliar with the language. Usability is also optimizing for the experien…

Also, people with 'no experience in the language', but with 'general programming experience' will be primed with the conventions of mainstream languages and biased against s-expressions.

(Btw, it's Jef Raskin.)

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

#35

Post by ohyes »

derefr wrote: post #7
Zak wrote: post #3

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

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 wi…

I am by no means a theoretician and I 'get' lisp. I do maintenance and extension on a code base that stretches back to the late 80s. It is a product that runs on windows, has a large user base, and is still gaining customers (though in a decidedly niche market).

It appears to me that you do not have very much practical experience writing code in lisp. You are understanding the 'code is data' statement in completely the wrong way.

I store and treat my 'data' in exactly the same way that anyone would in perl or python or ruby. I don't think I've ever had a problem distinguishing code from data, when I had the desire. (I keep it in config files, or data files, or in variables).

Code is data, to me, means that I can take some data, and transform it into code. Code is a description of how the world is, at some level, and so is data.

(For example, I could take a description of the hierarchy of a website's rest service, and write a function to transform it into a series of functions that do the proper requests, in the proper formats, with the proper parsers).

How can you argue that lisp does not obey any principles of HCI simply because HCI wasn't invented when Lisp was? It doesn't make sense as an argument. If I don't have a name for something, does it not exist? Gravity didn't exist until Newton described it?

What HCI principles does lisp violate? (I find the idea of HCI principles dubious. Isn't good HCI 'whatever scores well in usability tests').

Lisp is not theoretically pure. It is theoretically empty. It makes no assumptions about what the 'proper use' of it is. The whole point of abstraction, to a programmer, is to 'paper over' the actual language and make the program a description of itself. Lisp is amazing at abstraction. (By amazing I mean the unqualified very best).

----

As an addendum. Your comparative usability study[1] is horribly flawed, because you assume programming experience. You should assume no programming experience. The majority of programmers have experience in an Algol derived language. This introduces a huge bias into any study that you would decide to do. Anything that looks and acts like Algol will be easily deciphered, anything else will not be.

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

#36

Post by silentbicycle »

derefr wrote: post #32
sedachv wrote: post #26

Earlier quoted context omitted.

"Also, you wouldn't be comparing, say, Java to APL. You'd be comparing Java to Java + "an unless statement", or APL to APL + "enforced whitespace." You want to see the relative worth of language features, not the relative worth of our current languages, which have mostly been slapped together with no concern for UX. The result of such a study would be a set of UX suggestions, of language features that comparatively i…

You ignored the most important part of what I said. > Thus, if the test-taker doesn't know English, they get the same (low) score on both tests—to the BNN, that is the same as "no new evidence." So, of course, you wouldn't test APL vs. APL+whitespace on someone who doesn't know APL, because your test results would always, predictably, be 1:1. But you wouldn't be testing APL vs. anything—because APL is a set of design…

> because APL is a set of design choices that have already been made

Compare J, Q, and Dyalog. Three modern APL dialects, very different in feel.

You might protest that J or Q aren't APLs (they only use ASCII! Q has ragged arrays!), but that's like arguing Scheme isn't a Lisp.

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

#38

Post by silentbicycle »

shaunxcode wrote: post #34

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.

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.

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

#39

Post by aufreak3 »

paulitex wrote: post #15
evanrmurphy wrote: post #8

Earlier quoted context omitted.

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…

Shriram Krishnamurthi (author of PLAI http://www.cs.brown.edu/~sk/Publications/Books/ProgLangs/ ) recently suggested one: 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...)

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/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

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

#40

Post by ohyes »

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

Post reply on HN