Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

151–160 of 201 posts

Re: An Intuition for Lisp Syntax

#151
post #146

Earlier quoted context omitted.

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 (includ…

I believe it's also 1 or 2 shortcuts, thanks to the IDE's understanding of the language syntax, unless I misunderstood your scenario?

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

Besides, another languages can throw away the parentheses entirely so neither users nor editors don't mentally or visually have to.

Re: An Intuition for Lisp Syntax

#152

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…

You can get some of the interactivity through unit tests. Admittedly, the feedback loop is not always that tight as with the repl.

Re: An Intuition for Lisp Syntax

#153
post #32

Earlier quoted context omitted.

For someone who hasn't used sexprs or looked at an AST before, it might not be clear why a data structure and atomic elements are goals in the first place. I tried to write an explanation but found it surprisingly difficult to articulate. In short, there's almost certainly other ways to accomplish the same thing but sexprs are dead simple and they work _really_ well in practice. Just go use them and it will make sens…

Sexpr makes expressions easier for computers to parse. That is all there is to it. Other languages focuses more on making code easier for humans to parse. Both are good for different things.

But your editor is also a "computer". Editing lisp code with an editor tuned to s-expressions can be pure joy. Most programmers work at the character level of text files, many lispers work much closer to the abstract syntaxt tree (AST).

Re: An Intuition for Lisp Syntax

#154

Earlier quoted context omitted.

Common Lisp has long been a compiled language. Its performance is quite competitive when set against Fortran and C. The idea that it's interpreted (and consequently slow) is a very old myth. Of course, it helps to use the right data structures if you want fast Lisp code (using lists for everything is not the right choice).

> Its performance is quite competitive when set against Fortran and C. No, not at all. It is the same level as Java, a bit slower but I guess that is because there is more work done on Java. Just because you compile a language doesn't mean it is as fast as other compiled languages. You can compile python down to a binary but it will still be super slow.

Where do you get your information? SBCL has been shown to be, when optimized, within the same order of magnitude as C.

https://news.ycombinator.com/item?id=2192629

Re: An Intuition for Lisp Syntax

#155
My word. Please people, if you haven't programmed a decent sized program in Lisp using an editor tuned to the task, please don't spout off like you know what you're talking about. Just do the work first, it's worth it, just for the understanding.

Re: An Intuition for Lisp Syntax

#156

Earlier quoted context omitted.

That becomes a no true Scotsman fallacy though. People argue "Either you like lisp syntax or you haven't used it enough to have a valid opinion". That is a bullshit argument.

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…

Hey :)

You wrote a really nice comment ages ago, which partly inspired me to learn lisp and also it’s formatting.

I still want clean it up a fair bit, but here’s the draft article:

https://ashokkhanna-530.medium.com/formatting-lisp-5e28020b8...

Hope it’s okay to use your quote! And if not, I’ll take it down

Re: An Intuition for Lisp Syntax

#157
The problem I'm having with Lisp isn't the syntax or the language, but the ecosystem. Or rather learning about the ecosystem. There's not much information, from what I've found, about best practices for creating a production ready application. A lot of Lisp tutorials and books extoll the virtues of the language and REPL based development but stop there. For example, I want to figure out how to use Lisp in a CI/CD environment to deploy binaries. Or learn the best practices for creating a project with multiple modules with dependencies.

Edit: Is this being downvoted because I'm hijacking the thread?

Re: An Intuition for Lisp Syntax

#158
post #146

Earlier quoted context omitted.

> 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 (includ…

I believe it's also 1 or 2 shortcuts, thanks to the IDE's understanding of the language syntax, unless I misunderstood your scenario? > Besides, a Lisp editor can blur the parentheses so users don't mentally have to. Besides, another languages can throw away the parentheses entirely so neither users nor editors don't mentally or visually have to.

> I believe it's also 1 or 2 shortcuts, thanks to the IDE's understanding of the language syntax, unless I misunderstood your scenario?

I have not seen transposing, merging, splitting, annexing (moving a block into the inside another block), and de-annexing (the opposite of annexing) 2 blocks of codes in JS without using the mouse yet, so I just want to check.

> Besides, another languages can throw away the parentheses entirely

JS uses parentheses for grouping complex arithmetics and for function's argument lists (eg. func(arg) in JS vs. (func arg) in lisp). JS also uses curly braces to mark code blocks, which is similar to Lisp parentheses but at the cost of more complex parsing for the compiler and the mental distinguishing between functions' argument lists and code blocks on the coder (they are just lists).

JS statements use semi-colons, which makes editing them feel like editing lines of codes while editing Lisp statements is editing nodes of a tree, which is a very different experience.

Re: An Intuition for Lisp Syntax

#159
This is very similar to how I "came to lisp". I was attempting to come up with a more uniform smalltalk/ruby syntax and slowly talked my way into s-expressions. I had tried emacs lisp and scheme so I was aware OF the syntax but the pedagogical experience of WHY the syntax was a lot more profound. After that reading ANSI common lisp, let over lambda, etc. cemented my love for macros and I've never looked back. Actually given that I settled on clojure which still lacks the self-hosted qualities of common lisp I DO look back but only at common lisp.

Re: An Intuition for Lisp Syntax

#160
post #146

Earlier quoted context omitted.

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 (includ…

> It usually takes me at most 2 key combinations with a Lisp editor (including navigating the cursor to the right place)

Is that in emacs/slime or another editor?

Post reply on HN