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

161–170 of 201 posts

Re: An Intuition for Lisp Syntax

#161

Post by bbbobbb »

tonyarkles wrote: post #111
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 }…

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…

Genuine question since I might be missing something: how would you take the lisp version and parse/execute it without using something like eval?

Re: An Intuition for Lisp Syntax

#162

Post by memling »

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…

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

Shouldn't you be doing this anyway? Not trying to be snarky: it's that every job I've worked at has a classic underdocumentation problem. Tribal knowledge dominates, and the practicalities of shipping product overrun the need for teaching employees, new and old, about the idiosyncrasies of the system. [edit] This seems hardly an issue with LISPs or DSLs in particular.

Re: An Intuition for Lisp Syntax

#163

Post by flavio81 »

TeMPOraL wrote: post #95
Perseids wrote: post #80

Earlier quoted context omitted.

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…

Having worked in a Common Lisp startup, I'll only agree with half of your counterarguments :). > You want advanced syntax highlighting, linting, automatic refactoring for your special features? Write it yourself! That's true to an extent. Simple things are simpler in Lisps, because the syntax is trivial. So highlighting and structured editing are easy. The rest, is near impossible, at least for a full-featured Lisp l…

>in general, you can't know what the program will do until you run it

It needs to be added that in Common Lisp, once the program is running you can do everything with it while it's running: Inspect the stack frames, change variable values, rewrite/recomiple/update functions, update class definitions, update objects to said new class definitions, save the current program state to disk,etc.

So it's programming that is geared to RUNNING the program and modifying it while its running.

Re: An Intuition for Lisp Syntax

#164

Post by flavio81 »

wtetzner wrote: post #114
Perseids wrote: post #110

Earlier quoted context omitted.

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,…

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

Exactly. On common lisp, for example, it's just a keypress, and it has a "macro stepper" so it shows the first expansion possible, then the second expansion, and so on and so on... until you end up with compiler primitives!

Re: An Intuition for Lisp Syntax

#165

Post by flavio81 »

maximilianroos wrote: post #45
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…

Greenspun's tenth rule [0]: "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." Also: > Hacker Robert Morris later declared a corollary, which clarifies the set of "sufficiently complicated" programs to which the rule applies "...including Common Lisp." [0] - https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

>Hacker Robert Morris later declared a corollary, which clarifies the set of "sufficiently complicated" programs to which the rule applies "...including Common Lisp."

This is referring to CL implementations that depend heavily on C.

Many CL implementations now are almost 100% Lisp code.

Re: An Intuition for Lisp Syntax

#166

Post by kyberias »

pgt wrote: post #103
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…

Lisp has only one rule called the Operational Form: (operator arg1 arg2 arg3 ...) The Operational Form is just a list denoted by parentheses. The operation or 'function' comes first, followed by its arguments or operands, e.g. (+ 1 2 3) => 6 The + symbol resolves to the plus function and is passed in the arguments 1, 2 and 3. Nested forms are evaluated inside-out: (+ 5 (- 10 6)) => 9 Traditionally, Lisp only has one…

> If you come from a traditional OO-background, my condolensces

Is this condescending attitude really necessary or useful?

Re: An Intuition for Lisp Syntax

#167

Post by flavio81 »

Reelin wrote: post #37
trevyn wrote: post #16

So what does Lisp make harder to implement than today's programming languages? It seems like large-scale composition relies on a well-structured way to define and enforce APIs, and oh wow, typing facilities. Performance has historically been an issue for Lisp because its model is tightly tied to interpretation, but perhaps modern JIT-style compilation can address this. Others? What type of issues do large Lisp projec…

> a well-structured way to define and enforce APIs I don't see the issue here? What do you think is stopping you from doing this in, for example, Common Lisp? > and oh wow, typing facilities Common Lisp isn't typed, but there's no reason a Lisp dialect can't be. In fact, Typed Racket is just such a language.

>Common Lisp isn't typed

It is heavily typed. Very strongly typed for the most part (except numbers). So typed that it won't accept a "character vector" in the place of a string.

But type checking is mostly at runtime, not at compile-time.

The good part is that you can edit your program at runtime and restart it at the exact point the error happened, very easily.

Re: An Intuition for Lisp Syntax

#168

Post by kgwgk »

jakear wrote: post #122
capableweb wrote: post #118

Earlier quoted context omitted.

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.

This was on a blackboard. And GJS advised Guy Steele in creating Scheme and coauthored SICP with him.

> coauthored SICP with him

Not with him.

Re: An Intuition for Lisp Syntax

#169

Post by PopsiclePete »

To me the problem with LISP's was never the syntax, I understand s-expressions and homoiconicity and all that, the problem was also....this is embarrassing...the dev setup/environment.

In every single non-LISP language/environment - whether it be C, C++, Rust, Go, C#, Java - I can sit down comfortably in VIM or Vscode+VIM and just start hacking away.

With LISPs, I always feel like I'm fighting my editor - and I am. I know about Emacs+SLIME, I know about paredit, I've seen it in action and it's impressive, I just can't force myself to expand the energy to dive into the Emacs eco-system.

And yes I've tried vim fireplace and Cursive and VSCode's latest ...whatever.....but they all just feel "wrong" in a way, like a square peg in a round hole.

I feel if I could just spend enough time to really understand Emacs and all of it's LISP-yness goodness, I'd enjoy LISPs a lot more and use them more in daily work

Re: An Intuition for Lisp Syntax

#170

Post by nojvek »

One of my algorithmic interview questions is to evaluate mathematical expressions in array of array json (like S expressions). Then add variables and conditions. If time persists, add function declarations.

I love the idea of data is code is data.

Post reply on HN