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

An Intuition for Lisp Syntax

stopa.io

Post reply on HN
Print view View original

141–150 of 201 posts

Re: An Intuition for Lisp Syntax

#141

Post by wtetzner »

capableweb wrote: post #120
wtetzner wrote: post #117

Earlier quoted context omitted.

> It's all personal, of course, but I find that the typographical variety of "traditional" languages with syntax makes it way easier to me to read/parse them than LISP. I wonder how much of that has to do with your familiarity with "traditional" language syntax. For example, when I started writing Lisp, I had a similar opinion. But I write Clojure professionally for a while, and that disappeared. Now I haven't writte…

> Clojure professionally for a while, and that disappeared. Now I haven't written Lisp in probably 7 years, but I still have no problem reading it. Slightly off-topic but interesting none-the-less. After starting to program with Clojure both as an hobby and professionally, how do you go back something that is not lisp/repl driven? I've tried time and time again to go back to JavaScript, as I used to be OK with it, bu…

Going back to something that's not REPL-driven takes some adjustment, but I try to find and focus on the advantages the other language has, instead of on what it's missing. For example, when using OCaml (which incidentally does have a REPL, but I don't use it often), I get a lot of value from the type system and the module system.

Even Java has advantages in terms of tooling, and from Java 8 on, you can write code using some Clojurish idioms with streams. Though for immutable data, you need something like Lombok + pcollections.

JavaScript, on the other hand, really doesn't offer anything over Clojure, so I can see why you'd struggle going back to it. It's just a downgrade.

Re: An Intuition for Lisp Syntax

#142

Post by githubalphapapa »

jmiskovic wrote: post #89
wavegeek wrote: post #75

Earlier quoted context omitted.

> s-expressions are kind of hard to read and reason about for my brain I think it's likely this is just a matter of familiarity. Like the way that people think the Windows (/ whatever) GUI is intuitive - but when you test this by putting someone who has never used it in front of a screen, it actually isn't. "What do you mean if I write something and don't also 'save' it, whatever that is, it will disappear? This is s…

Maybe the last sentence needs a bit expanding, I think most readers already use a powerful text editor and don't see how standard features would help with lisp. The thing is, you don't really edit Lisp as text. Two commonly used extensions (for emacs, vim, vscode, sublime...) are paredit and rainbow. Those extensions kick in when lisp code is detected. It then feels more like tree manipulation than like writing code.…

> Two commonly used extensions (for emacs, vim, vscode, sublime...) are paredit and rainbow.

In Emacs, you may find Lispy and Prism even better.

Re: An Intuition for Lisp Syntax

#143

Post by wtetzner »

Joker_vD wrote: post #112
culturedsystems wrote: post #64

Earlier quoted context omitted.

Indeed, I think this post ends up being a good argument against Lisp. The supposed negative for JS, as opposed to Lisp, is that "We’d need something like Babel to parse our file, and work on top of the AST to make sure we rewrite our code safely." And? Computers are good at parsing, and adding syntax to a language should be comparatively rare, so why would I choose a language that optimizes for this case, rather than…

> Computers are good at parsing, And humans are even better at it, and actually seem to cope with typographically diverse syntax better than the uniform ones. So it absolutely makes sense to have a nice, heterogeneous, human-friendly syntax. As for writing custom DSLs... I always feel vaguely uneasy when I find myself writing, essentially, an interpreter/VM for a simplistic programming language in a form of a set of…

> After all, I am already writing code in a rich programming language, why don't I just use it for my application logic in the first place?

I'd assume it's because that rich language isn't as well-suited to the problem domain as the DSL. I think one solution might be to come up with a more principled way of writing DSLs, that don't require you to revert to writing an interpreter or compiler "from scratch".

Re: An Intuition for Lisp Syntax

#144

Post by wtetzner »

culturedsystems wrote: post #64
wwosik wrote: post #60

I don't think I like it. I find it hard to quickly skim and find out what each of the elements is, since it can be anything. The example amounts to: function drawTriangle(left, top, right, color) { drawLine(left, top, color); drawLine(left, right, color); drawLine(top, right, color); } drawTriangle({ x: 0, y: 0 }, { x: 3, y: 3 }, { x: 6, y: 0 }, "blue" ); drawTriangle({ x: 6, y: 6 }, { x: 10, y: 10 }, { x: 6, y: 16 }…

Indeed, I think this post ends up being a good argument against Lisp. The supposed negative for JS, as opposed to Lisp, is that "We’d need something like Babel to parse our file, and work on top of the AST to make sure we rewrite our code safely." And? Computers are good at parsing, and adding syntax to a language should be comparatively rare, so why would I choose a language that optimizes for this case, rather than…

> Computers are good at parsing, and adding syntax to a language should be comparatively rare, so why would I choose a language that optimizes for this case, rather than one which optimizes for human readability?

Having everything be uniform has other advantages, but I think they end up being more subjective. Some people like the regularity, because they don't have to remember so many different kinds of syntax. Other people prefer different kinds of syntax, because they find it easier to read. I don't think there's an object measure here, because it all depends on your past experience and your preferences.

Re: An Intuition for Lisp Syntax

#145

Post by wtetzner »

wwosik wrote: post #60

I don't think I like it. I find it hard to quickly skim and find out what each of the elements is, since it can be anything. The example amounts to: function drawTriangle(left, top, right, color) { drawLine(left, top, color); drawLine(left, right, color); drawLine(top, right, color); } drawTriangle({ x: 0, y: 0 }, { x: 3, y: 3 }, { x: 6, y: 0 }, "blue" ); drawTriangle({ x: 6, y: 6 }, { x: 10, y: 10 }, { x: 6, y: 16 }…

I think this actually gives a better intuition for Lisp syntax: https://www.defmacro.org/ramblings/lisp.html

Re: An Intuition for Lisp Syntax

#146

Post by minhm »

Joker_vD wrote: post #129
wtetzner wrote: post #117

Earlier quoted context omitted.

> It's all personal, of course, but I find that the typographical variety of "traditional" languages with syntax makes it way easier to me to read/parse them than LISP. I wonder how much of that has to do with your familiarity with "traditional" language syntax. For example, when I started writing Lisp, I had a similar opinion. But I write Clojure professionally for a while, and that disappeared. Now I haven't writte…

Yes, it's just that it's the useless (unless you write an AST-rewriting macro) structure that gets in my way. Say, naming a thing, a function definition, and a function invocation are all very visually different in, say, JS, while in LISP it's just a slightly different pattern of parens and two keywords ("let" and "lambda") that are, of course, not actually keywords but just happen to be interpreted in that way by th…

> it's the useless (unless you write an AST-rewriting macro) structure

In a good JS editor, how many key combinations and mouse clicks are required to jumping into, jumping out of, and cutting a block of code (eg. a function definition or a conditional expression), or transposing, merging, splitting, annexing, and de-annexing 2 blocks of codes? It usually takes me at most 2 key combinations with a Lisp editor (including navigating the cursor to the right place), thanks to Lisp's uniform structure.

> Say, naming a thing, a function definition, and a function invocation are all very visually different in, say, JS

Aren't these also visually highlighted in a Lisp editor as well?

Besides, a Lisp editor can optionally blur the parentheses so users don't mentally have to.

(edit: formatting, recounting the key presses required)

Re: An Intuition for Lisp Syntax

#147

Post by athenot »

masukomi wrote: post #119
jFriedensreich wrote: post #34

This is maybe the best introductions to Lisp i have seen, especially for a js dev like me it could hardly get more approachable and convincing. I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain, it would be cool if we could generate them from more readable syntax, maybe something like javascript :D . Unfortunately the standard js…

There's a curly-brackets based infix formatting you could use if you'd prefer. https://srfi.schemers.org/srfi-105/ Or, you could use T-Expressions if Python style whitespace indentations to represent code nesting is easier on your brain. https://srfi.schemers.org/srfi-110/srfi-110.html Scheme and Lisp are VERRRRY Flexible.

Thank you! I'm in the camp of "Curious about Lisp but never jumped into it" and was wondering if indentation could reduce some of the bracket-noise.

This is VERY elegant!

Re: An Intuition for Lisp Syntax

#148

Post by bear8642 »

capableweb wrote: post #118
jakear wrote: post #113

Earlier quoted context omitted.

I’ve literally seen first-hand GJS lose track of paren matching while lecturing on Sceme/SICP. It happens very rarely sure, but certainly not never. Probably about as often as experts in any other language/profession make silly mistakes. Perhaps you’re a better schemster than him, but I have my doubts :) I think no matter the language the syntax will disappear over time and your brain will learn to look at the charac…

I'm not sure who GJS is but if you see any lisper editing text instead of operating on structures (with auto-balancing parenthesis and so on), it's 99% certain it's in an environment they are not familiar with, so they will make mistakes. I don't think anyone who write Lisp-like languages professionally doesn't use tools like parinfer/paraedit, where balancing parenthesis is not something you have to do.

>I'm not sure who GJS is…

Gerald Jay Sussman

Re: An Intuition for Lisp Syntax

#149

Post by minerjoe »

username90 wrote: post #83
username90 wrote: post #81

Earlier quoted context omitted.

Everything is so extremely context sensitive and has much more focus on text over symbols than other languages, which isn't a problem for computers but is a huge problem for humans. Therefore lisp is objectively harder to read for humans. If you have never read other code and is super familiar with lisp it is easier to read, but anyone with experience with both will find other languages much much much easier to read…

People saying that Lisp is as easy to read since you get used to it is like people saying that salad is as tasty as cake since you get used to it. Sure someone eating cake for the first time after having only eaten non sugary stuff for a long time will find it a bit jarring, but anyone eating both will find cake so much tastier, which is why people overeat cake so much. Yet many people will still adamantly say that t…

Why say lispers are "reality destorted"? Maybe they have learned something you have yet to understand?

Have you ever programmed a decently sized lisp program using an editor that allowed you to work at the AST level?

Until then, there's just a large probability, regardless of how tasty cake is, that your displaying classic ignorance.

Re: An Intuition for Lisp Syntax

#150

Post by minerjoe »

fao_ wrote: post #136
jFriedensreich wrote: post #34

This is maybe the best introductions to Lisp i have seen, especially for a js dev like me it could hardly get more approachable and convincing. I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain, it would be cool if we could generate them from more readable syntax, maybe something like javascript :D . Unfortunately the standard js…

> I could not help but thinking at the end, this is really awesome but s-expressions are kind of hard to read and reason about for my brain, it would be cool if we could generate them from more readable syntax, maybe something like javascript :D Little known fact: The people who came up with lisp wanted to do this, too. https://www.wikiwand.com/en/M_expressions

I think the story continues to where, in the beginning, they thought a change would be good, but after seeing the benefits that s-expressions gave, changed their minds.
Post reply on HN