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

101–110 of 201 posts

Re: An Intuition for Lisp Syntax

#101

Post by capableweb »

username90 wrote: post #96
capableweb wrote: post #71

Earlier quoted context omitted.

What is or isn't readable can be judged by two qualities. The first one is if it's being familiar to what you're used to and the second one how long it takes to learn if you're not familiar with it. Now I learned C-like language before I learned Lisp-like languages, so that might be the reason I felt I understood Lisp way faster than I felt I understand C-like languages. There is simply less to learn about the langua…

> What is or isn't readable can be judged by two qualities. The first one is if it's being familiar to what you're used to and the second one how long it takes to learn if you're not familiar with it. So your argument is that all code is as easy to read as long as you have done the work to get familiar with it? I hope you understand that it is bullshit. Brainfuck isn't easier to understand than python no matter how m…

No, that is not my argument. I'm sorry if I didn't explain myself well enough for everyone to understand.

My point is that "readability" is composed by many factors, not just one. What is "readable" to some will not be "readable" by others. It depends.

For someone who knows Fortran, learning a Fortran-like language is easy (like C or JS). For someone who knows Common Lisp, Clojure is easy. But for someone who knows Fortran, Clojure is less familiar, hence the code will, on a glance, look less "readable".

The other factor is if something is "simple" by itself.

Most of this view comes from Rich Hickey, who wrote Clojure. He discusses "readability" or "simplicity" rather, in his talk "Simple Made Easy". If you haven't seen it before, do yourself a favor and watch it: https://www.infoq.com/presentations/Simple-Made-Easy/

He'll explain it much better, and with further points, much better than I ever can.

Re: An Intuition for Lisp Syntax

#102

Post by miki123211 »

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…

This is exactly what Elixir is doing!

It has nice, readable, ruby-like syntax, but it's a Lisp at the core. Really powerful macros (see Ecto), and a syntax that isn't off-putting to the majority of programmers.

Most things in Elixir, including constructions like if and def, operators and even module accesses (`Module.function`) are compiled to a simple AST based on function calls.

Because that AST isn't usually written by humans, besides the function and the arguments, each node might contain additional context information, like the file and line number the call appeared in. That lets you do some really cool stuff, like distinguishing x (a variable you define) from x (defined by a macro), which is a frequent source of bugs in other languages that support macros.

99% of Elixir is syntax sugar over function/macro calls, and its true AST is smaller than Clojures.

You can read more here: https://hexdocs.pm/elixir/syntax-reference.html#the-elixir-a...

Re: An Intuition for Lisp Syntax

#103

Post by pgt »

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 data literal: `(linked lists)`, but Clojure adds `[square brackets for vectors]` and `{:curly brackets}` for hash maps. The colon denotes a keyword, which is a symbol which only ever resolves to itself and is commonly used for labeling things, e.g. keys in a map.

Notice how the operational form is just a list with some symbols and data literals. In Lisp, the syntax for writing data structures and the syntax for writing code is the same syntax. And since a function operates on data and produces new data, what if a function could operate on code and produce new code, since code is just data?

We call such a function a macro (and I don't mean Excel macros). Macros run at "compile-time" (technically 'read time') and the code output is executed at "run-time" (or during 'evaluation'). The benefit of macros is that if your language is missing a feature, you can add it.

You can see this in practice by looking at the source code for the `and` and `or` logic functions in Clojure, which are typically built-ins, but in Clojure they are just macros bootstrapped on top of the special forms `if` and `let`: https://github.com/clojure/clojure/blob/38bafca9e76cd6625d8d...

Clojure only has 13 special forms:

    [fn let let loop do while . if def recur
     try catch throw quote var
     monitor-enter monitor-exit]
Everything else is built on top of that.

When I started learning Clojure, I found the ClojureScript Koans to be very helpful in getting a feel for the semantics and to become familiar with the argument placement: http://clojurescriptkoans.com/

If you come from a traditional OO-background, my condolensces and I recommend starting with Rich Hickey's 2-hour talk, "Clojure for Java Programmers": https://www.youtube.com/watch?v=P76Vbsk_3J0

Re: An Intuition for Lisp Syntax

#104

Post by webreac »

wavegeek wrote: post #75
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…

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

I have learned scheme before camllight (the ancestor of ocaml). The syntax was a pleasure compared to scheme.

Re: An Intuition for Lisp Syntax

#105

Post by TeMPOraL »

ACow_Adonis wrote: post #97
username90 wrote: post #85

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…

> 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 exercises in it on paper. Few exercises in, as I was writing Lisp code with a pen in hand, suddenly something clicked in my head - like my brain JIT-compiled a new processing module - and from then on, I no longer needed to mentally count or track the parens. I just knew how many and where they were, it dropped to semiconscious level. Ever since, I'm very comfortable with s-expressions; in fact, I prefer them as a notation to Algol/C-like code.

Re: An Intuition for Lisp Syntax

#106

Post by emmelaich »

tutfbhuf wrote: post #40

Since parenthesis are just an arbritary sign, it's possible to replace it with something different that fulfills the same role in Lisp. An example for Lisp without parenthesis: https://dustycloud.org/blog/wisp-lisp-alternative/

Another one:

https://chrisdone.com/posts/z/

Re: An Intuition for Lisp Syntax

#107

Post by cloogshicer »

Reelin wrote: post #26
Jtsummers wrote: post #22

Earlier quoted context omitted.

You have the same problem in any language when you start scaling up to larger team sizes (or multiple teams). If they don't bother reading the docs or existing libraries, they're likely to reinvent the wheel over and over. The solution is, unfortunately, more social than technical. You have to be deliberate in selecting what goes into the common libraries, and be deliberate in code reviews to make sure junk like that…

Agreeing, I'd point out that C++ templates are Turing complete (and now they've added constinit and friends). That can certainly result in bad code, but it also enables very good code as well (ex the Eigen library). Python objects can be monkey patched at runtime - a powerful ability, but trivial to misuse. Certainly the design of a language should facilitate and even actively encourage writing good code. Attempting…

Since you mentioned the Eigen library: I'm sure it's an extremely elegantly designed library, and I know it's super powerful and efficient. But for someone like me, with fairly limited C++ experience, it was absolutely painful to learn and understand how to use it. Even though it's fairly well documented, I had to really dig through the sources whenever bugs arised. Understanding all these templating abstractions was a huge pain.

Re: An Intuition for Lisp Syntax

#108

Post by dualscyther »

I couldn't figure out how to email the author and I don't have twitter, but I found a few mistakes in the "More power" section that tripped me up a bit as I followed along, so just posting here in case it helps anyone else:

The end of the second last code block should be:

`data.instructions.forEach(...args.map(parseInstruction));`

And the full definition of `data.instructions` that demonstrates the use of this modification would be something like:

`[["rotate", ["rotate", ["drawLine", { x: 0, y: 0 }, { x: 1, y: 1 }], 90], 45]]`

Re: An Intuition for Lisp Syntax

#109

Post by Joker_vD »

coldtea wrote: post #99
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 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"{}".

Re: An Intuition for Lisp Syntax

#110

Post by Perseids »

capableweb wrote: post #100
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…

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 Lisp, but also applies to e.g. C++ template meta programming. Compilers have gotten betters with templates, but still debugging the more advanced usages of templates can become hellish. Codifying the features the meta programming supplies in the language itself or in well supported libraries means that error messages get better and many usage scenarios are documented on Stackoverflow.

I don't doubt your experience regarding Clojure vs JavaScript code bases, but this probably has to do with other reasons than the meta programming the original blog post is about?

Post reply on HN