Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

111–120 of 201 posts

Re: An Intuition for Lisp Syntax

#111
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 }…

Going with the example in the article and the nominal purpose of it... how would you take what you’ve written above and parse/execute it without using eval.

I’m with you, generally. I have used CL off and on for the last 20 years, and when I come back to it it takes a solid week before I start “reading in Lisp”. It definitely doesn’t come naturally when you spend most of your time reading “C-type” syntax all day. But for some tasks it is an absolutely fantastic tool and doesn’t take that long to get back into.

Re: An Intuition for Lisp Syntax

#112
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 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 library routines/components that I then process to use to build my application logic out 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?

Re: An Intuition for Lisp Syntax

#113

Earlier quoted context omitted.

It is and it isn't :) Obviously opinions on the language shouldn't be given too much weight if a person hasn't spent too much time investigating/ using it. As a non-JavaScript person, all the JavaScript examples looks like gobbledygook unless I sit down and consciously think about what the examples are showing, and it kinda hurts my head a bit, but I can slowly force myself through it. But as someone with a few years…

> and then something just clicks over in your brain and you don't even see the brackets any more In my experience, the Lisp enlightenment comes in stages, two big ones are 1) s-expression parsing you describe here, and 2) grokking "code is data". WRT. s-expressions enlightenment, I vividly remember when it happened to me. Few months into learning Lisp, I bought a hardcover SICP and, for some reason, decided to do exe…

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 character matrix and directly see logical constructs, moreover this will always apply cross-language to other languages with similar syntax. Fit example, I primarily work in TS, I have decent amount of experience in other C-style, and to me Rust is easily readable with very little experience actually using it.

Re: An Intuition for Lisp Syntax

#114

Earlier quoted context omitted.

Seems you're arguing for using all the powers a programming language gives you, nothing in particular about Lisp there. As with many things, it depends mostly on the people writing the code and their process, rather than what programming language they are using. I never inherited a Clojure-codebase that has been written during long duration, but I have digged around in a fair amount of Clojure-codebases that are open…

I'm mostly arguing against extensive use of meta programming, which is promoted as one of the main reasons to view data as code, as meta programming is inherently disadvantaged for automated tooling. Formulated as a trade-off: When I have to choose, I prefer richness of IDE (and other tooling) automation to program creation automation that I write myself (i.e. meta programming). This trade-off is not restricted to Li…

> I'm mostly arguing against extensive use of meta programming, which is promoted as one of the main reasons to view data as code, as meta programming is inherently disadvantaged for automated tooling.

Which is weird, because in most Lisps meta programming happens at compile time. It should be possible for tooling to just show you the expansion of any given macro invocation. In fact, when I used Clojure a decade ago, there was an Emacs command that would expand the macro invocation under your cursor, so you could see what code was actually being generated.

So I don't really think that's a fundamental limitation. I suspect it's more related to the fact that Lisps aren't especially popular, and don't get the attention from tooling that other languages do.

> Codifying the features the meta programming supplies in the language itself or in well supported libraries

But without the meta programming, those libraries might not actually be possible to write. You will either end up with a more dynamic interface (doing meta-stuff at runtime), or a clunkier and more verbose interface. I think being able to expand a macro invocation to see what it turns into is enough for all but the hairiest of macros.

Re: An Intuition for Lisp Syntax

#115

Earlier quoted context omitted.

> 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 . So many people start out thinking like this when they learn Clojure or some other Lisp and then after like 2-4 weeks of reading Lisp code, any C-like code starts to look co…

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…

I have experience with tons of languages, lisps and non-lisps.

I don't really get this argument. It's not any harder to read `(if foo` than it is to read `if (foo)`. It's purely a matter of what you've gotten used. I don't think it's an objective measure, it's purely about what you've already trained your brain to pattern-match on.

> and has much more focus on text over symbols than other languages

Funny how you get the exact opposite complaint about languages like Perl.

Re: An Intuition for Lisp Syntax

#116
a) great article b) "It can help you move with the speed of a sculptor"... This person has obviously never watched a sculptor. They are so slow compared to basically every other form of artistic visual representation.

Re: An Intuition for Lisp Syntax

#117
post #99

Earlier quoted context omitted.

> 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 is (map foo '(1 2 3)) that more difficult than: [1, 2, 3].map(foo) ? Or: (let ((array #(1 2 3 4 5))) (vector-set! array 0 3) (vector-ref array 0)) that more difficult than: let array = [1, 2, 3, 4, 5]; array[0]=3 array[0]

Yes. 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. Parens, parens, everywhere, nor a drop of structure. And when it comes to macros and (pseudo)-quoting, the LISP is hands down more obnoxious (again, for me) than, say, Python's f"{}".

> 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 written Lisp in probably 7 years, but I still have no problem reading it.

> Parens, parens, everywhere, nor a drop of structure.

On the other hand, in some sense it's all structure. There are certainly advantages to having everything be delimited.

Re: An Intuition for Lisp Syntax

#118
post #113

Earlier quoted context omitted.

> and then something just clicks over in your brain and you don't even see the brackets any more In my experience, the Lisp enlightenment comes in stages, two big ones are 1) s-expression parsing you describe here, and 2) grokking "code is data". WRT. s-expressions enlightenment, I vividly remember when it happened to me. Few months into learning Lisp, I bought a hardcover SICP and, for some reason, decided to do exe…

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.

Re: An Intuition for Lisp Syntax

#119

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.

Re: An Intuition for Lisp Syntax

#120

Earlier quoted context omitted.

Yes. 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. Parens, parens, everywhere, nor a drop of structure. And when it comes to macros and (pseudo)-quoting, the LISP is hands down more obnoxious (again, for me) than, say, Python's f"{}".

> 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, but I just cannot justify the hassles I have to fight with everyday, compared to if my co-workers just picked up Clojure instead.

Post reply on HN