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

21–30 of 84 posts

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

#21

Post by joe_the_user »

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…

I have to say I'm not impressed by the link.

Intuitiveness is indeed highly correlated to previous human experience. But aside from pre-existing interfaces, an interface designer has available the whole of an average person's real world experience - the mouse is intuitive because it mimics a person's experience of moving a physical object - it doesn't mimic exactly but closely enough that a person can use their existing experience to extrapolate. And an interface designer who wanted to improve a standard interface may be able to find a different facet of human experience analogous to the task at hand and thus (contrary to the link) it is possible to create interfaces which are new and intuitive (but I'll admit it's damn hard and you should have a reason).

Most computer languages leverage human experience with natural language - not exactly, but partly. That's why Ruby's "return 5 if done" syntax seems really nice. Thus I'd argue you can make a reasonable study of what constitutes an intuitive interface.

So I claim the intuitiveness of Lisp's parentheses is a valid question for debate.

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

#22

Post by python_padawan »

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

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

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

#23

Post by derefr »

sedachv wrote: post #19
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's just stupid. If the programmer doesn't understand English and the program is written with English identifiers, does that fail the test? What a…

> 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 fully absorb the code), and then the references are removed and they are given tests on the properties of sample_A and sample_B (again in random order.) The score is not a measure of either A or B individually, but rather the ratio A:B, derived by the ratio of correct questions in sample_A:sample_B. A:B is then handed to a Bayesian neural network as a confidence score.

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

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 increase, or comparatively decrease comprehension.

> And you seem to be a theoretician who has never had to maintain any Lisp code.

For the last eight months, I've been writing Clojure for a living. I've written quite a bit of CL before that. I still find it harder to come back to any Lisp project after a month or two than to come back to code in any other language.

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

#24

Post by derefr »

alec wrote: post #20
angrycoder wrote: post #16

Earlier quoted context omitted.

This is a valid argument with several points worth discussing. To the people downvoting, that is not what downvoting is for.

It really isn't. Replace "Lisp" with "Perl" and "theoreticians" with something evocative of the stereotypical Perl programmer and you have the exact same nonsubstantive rant that adds little to the discussion of what a good programming language should look like or why a particular one is bad. I've been a "working programmer" who happens to write Common Lisp for a few years. Common Lisp is a programming language like…

> Common Lisp is a programming language like any other: people who write good code in other languages can write good code in Common Lisp, and people who write bad code can make everyone's life just as miserable.

We're not talking about the extremes, here, though; we're talking about completely average code, written by completely average programmers, and the comparative number of extra milliseconds it takes these programmers to comprehend, or recall, the correct syntax in one language vs. another.

Milliseconds matter; when Google shaves milliseconds off their page load times, they earn millions of dollars. This isn't because every user is slightly better off, but because some discrete number of users switched from "eh, this is taking too long, I'm outta here" to "alright, I'll put up with that." People get fed up with programming languages all the time, but no one bothers to find a formal reason for it. Has anyone ever done an eye-tracking study on people programming?

> I am of the opinion that anyone who calls Common Lisp a "theoretically-pure" language

No one's doing that. "Lisp" as a general term does not mean "Common Lisp"; it refers to the feature intersection of all popularly-implemented Lisps—the "Lisp" that Greenspun's rule refers to getting implemented everywhere. That "Lisp" is very pure.

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

#25

Post by p_nathan »

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…

Lisp is considered a language with a high strength in prototyping. I'm not sure why you think it's a write-only language.

I like Lisp because it is wholly unambiguous in visual syntax. That is not something I find in languages such as Perl, Python, Ruby, C++, Haskell, or C. I do find unambiguity in assembly as well.

I've also found that the general idea of "build your own Lisp" as a reason for lack of comprehension is specious when stacked up against the Java or .NET frameworks. You have to know the framework calls to understand what's going on. The same applies for C++ template metaprogramming.

I don't consider that a criticism; I consider that an acknowledgement of the ability of programming languages to provide abstraction.

I am a working programmer, and I like Lisp.

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

#26

Post by sedachv »

derefr wrote: post #23
sedachv wrote: post #19

Earlier quoted context omitted.

"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's just stupid. If the programmer doesn't understand English and the program is written with English identifiers, does that fail the test? What a…

> 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 increase, or comparatively decrease comprehension."

This is still meaningless if you're testing it on someone who doesn't know APL. Having an "unless" statement in your example is exactly like testing for English comprehension. This technique would make sense if you're testing proposed design choices for changes to APL on APL programmers (here's 60 seconds to read this program; what do you think it means?), it would make sense if you have equivalent programs in different languages being tested on users of those languages ("users of Perl understood program X 10% better than users of APL given 60 seconds to examine it"), but it is meaningless in the context you provide.

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

#27

Post by p_nathan »

python_padawan wrote: post #22
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

"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 l…

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.

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

#28

Post by gruseom »

p_nathan wrote: post #27
python_padawan wrote: post #22

Earlier quoted context omitted.

"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 l…

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

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

#30

Post by erikb »

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!

Post reply on HN