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

191–200 of 201 posts

Re: An Intuition for Lisp Syntax

#191

Post by reegnz »

abhinav22 wrote: post #156
ACow_Adonis wrote: post #97

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…

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

I'd just use parinfer/paredit and forget about the whole formatting 90% of the time.

Re: An Intuition for Lisp Syntax

#192

Post by dunefox »

Joker_vD wrote: post #151
minhm wrote: 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.

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

Which mainstream languages have no brackets?

Re: An Intuition for Lisp Syntax

#193

Post by dunefox »

minhm wrote: post #146
Joker_vD wrote: post #129

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…

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

How do I do that with spacemacs?

Re: An Intuition for Lisp Syntax

#194

Post by kd0amg »

Perseids wrote: post #80
TeMPOraL wrote: post #43

Earlier quoted context omitted.

> 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. The classical one is "The Nature of Lisp"[0], which introduces data-as-code through XML and Java build tools. Same idea, just with examples more relevant at the time of writing. Still worth a read for non-webdev programmers. Having learned Lisp, it's half funny, half dishea…

I think that should be the marketing of Lisp: A necessary evil ;) But seriously speaking, for me Lisp would be much more appealing if it had been introduced to me as a specialized niche language, though for an important niche nonetheless, instead of as the be-all-and-all language for your superpowered startup [1]. (For those that don't already have a goto list of counterarguments to "Lisp all the things": My main con…

> My main contra-point to Lisp is that with all the meta programming powers you get, you write yourself into your own little corner where no-one but you and your friends live. You want advanced syntax highlighting, linting, automatic refactoring for your special features? Write it yourself!

This is contrary to my experience (though I've mostly used Racket rather than Common Lisp). Tracking what's a function vs macro, where an identifier is introduced/used, etc., is all baked into the underlying language and not something I have to write myself for every language extension I make.

> You want outsiders to participate (think: new employees)? Write all documentation yourself, too!

Were you planning to not document your internal-use utility code?

Re: An Intuition for Lisp Syntax

#195

Post by TheRealKing »

minerjoe wrote: post #154
username90 wrote: post #70

Earlier quoted context omitted.

> 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

If you read the discussions to end, you will notice many objections to the benchmark that you have posted here. Even I have objections. -O3 is not the end of all possible optimizations in C and Fortran.

Re: An Intuition for Lisp Syntax

#196

Post by User23 »

garmaine wrote: post #23
User23 wrote: post #13

Earlier quoted context omitted.

Common Lisp has keyword args too.

To be clear this is something I’ve thought a bit about. I think the interesting analog is not maps per se, but relational tuples. Instead of “everything is a list”, it would be “everything is a tuple”, and the environment is a table. Evaluate a tuple to execute, evaluate a table to execute in parallel.

Objectively speaking table oriented programming is a very interesting topic. Sadly the incredibly effective anti-evangelist calling himself topmind over at the c2 wiki convinced me to completely ignore it for over a decade.

The relational calculus is an incredibly powerful formalism though, and it's definitely one that has an important place in serious software development.

Re: An Intuition for Lisp Syntax

#197

Post by minerjoe »

TheRealKing wrote: post #195
minerjoe wrote: post #154

Earlier quoted context omitted.

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

If you read the discussions to end, you will notice many objections to the benchmark that you have posted here. Even I have objections. -O3 is not the end of all possible optimizations in C and Fortran.

I hear you, but I was lazy and only gave one reference. There have been, over the years, many demostrations of optimized SBCL being on the same order as C.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

https://drmeister.wordpress.com/2015/07/30/timing-data-compa...

https://groups.google.com/forum/?_escaped_fragment_=topic/co...

Re: An Intuition for Lisp Syntax

#198

Post by igouy »

minerjoe wrote: post #154
username90 wrote: post #70

Earlier quoted context omitted.

> 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

> within the same order of magnitude

That could mean 9x slower?

990 seconds instead of 110 seconds.

Re: An Intuition for Lisp Syntax

#199

Post by minhm »

dunefox wrote: post #193
minhm wrote: 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…

> Besides, a Lisp editor can optionally blur the parentheses so users don't mentally have to. How do I do that with spacemacs?

Try:

===

(package-install 'paren-face)

(global-paren-face-mode 1)

(custom-set-faces '(parenthesis ((t (:foreground "gray50"))))))

===

(edit: formatting)

Re: An Intuition for Lisp Syntax

#200

Post by minhm »

kagevf wrote: post #160
minhm wrote: 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…

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

Emacs/slime.
Post reply on HN