Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

181–190 of 201 posts

Re: An Intuition for Lisp Syntax

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

> Sexpr makes expressions easier for computers to parse. That is all there is to it.

I would _strenuously_ disagree with that claim, but as previously stated I find the explanation of why I disagree to be surprisingly difficult to articulate. Nonetheless, I find that in practice sexprs are an incredibly effective tool for the task of programming as a whole.

Re: An Intuition for Lisp Syntax

#182
post #17

I get the code is data thing, but I don't really find it that much useful. And there is a good reason most languages don't allow it - other people :) The unless example is a good one. So while you can trivially implement 'unless' in lisp, most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.

> most probably in a large code base, you'll en up with 'unless', 'if-not' and depending on how creative others are probably also 'negat-if'.

In Clojure, "if-not" is part of clojure.core (the equivalent of java.lang in Java), so a decent programmer would almost certainly be familiar with it; and if not, it would be pointed out at a code review.

People use Lisp for a while, so the obvious simple ideas were probably already noticed and implemented.

With less frequent things, implementing the same thing twice under two different names is a problem that happens regardless of the language.

Re: An Intuition for Lisp Syntax

#183
post #15

A simpler intuition. Opening parenthesis moves to the left, whitespace acts as colon. So, f(a, b, c) becomes (f a b c).

This isn’t the right intuition for the syntax, this is the right intuition for evaluation. Why move that bracket? The answer is simple: we want the syntax to also denote a serialized data structure: a tree of atomic elements. So (f a b c) represents a list of symbols F, A, B, C, and the interpretation of this list is a call of the function F on arguments A, B, C.

> Why move that bracket? The answer is simple: we want the syntax to also denote a serialized data structure: a tree of atomic elements.

In other words, to evaluate "f(a, b, c)", what you really evaluate is "a", "b", "c", and "f(a, b, c)". You never evaluate "a, b, c". If you move the bracket, then "what is in bracket" matches "what is evaluated".

Re: An Intuition for Lisp Syntax

#184

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.

I thought this in the back head when I wrote it xD. “hmm...it can’t be too easy changing marble around”. If you have a better metaphor lmk will change :}

Pottery might be better.

Re: An Intuition for Lisp Syntax

#185

Earlier quoted context omitted.

I thought this in the back head when I wrote it xD. “hmm...it can’t be too easy changing marble around”. If you have a better metaphor lmk will change :}

Pottery might be better.

updated! (should show up in a few mins)

Re: An Intuition for Lisp Syntax

#186

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…

I heard that before but i wonder how much is survivorship bias :D it reads just so awkward to me as a programming language, even though i 100% dig the beauty and everything that it allows.

I can only speak about Clojure, since it’s the only lisp I know. After just a few days of playing with it though, I started to see the parentheses as a warm and friendly hug, wrapping everything inside of them in its own scope that doesn’t affect its parents. Reading JavaScript, my main driver, became harder in comparison.

  function doSomething(a, b) {/* something! */}
is okay, since the “function” keyword is a simple indicator, and it’s clear that it’s a function declaration. The kids these days often use

  const doSomething = (a, b) => {/* whatever */}
and that is awful for readability. It’s much harder to scan for function definitions amidst value declarations. I’m nearly 20 chars in before I even know it’s a function. Worse yet is something like

  const doSomething = (a, b) => b => “some closure”;
This threatens to stretch my capability to understand the context I’m in when reading it. “b” is just kinda floating there amongst the infixed arrows, and I have to read on to know it’s an argument, and I have to run through the calculation of what “b” is every time. Compare:

  (defn do-something [a b] (fn [b] “some clojure”))
I can count the parens, there is no implicit scoping of the function body. My editor can too, which means I often don’t have to. It’s obvious that it returns a function. This part is Clojure-specific, but I also have strong guarantees that the returned function cannot pull the rug out from under me with whatever I pass to it by arbitrarily mutating some argument.

To me at least, (fn-name args) was both more readable and makes more sense than fnName(args) after a few days, and I never learned a lisp until I was 37. Maybe I just found a style preference later in life, marking me as a lisp survivor. Maybe we’ve just been doing it wrong for decades and have grown accustomed to it. I can’t say. But the power of the language itself coupled with the code editing features it enables makes me think that the whole field has been on the wrong track, or maybe even off the rails, for decades.

The JS code I write now is more flexible, more resilient, more testable, and more maintainable as a result of learning Clojure. I doubt anyone can say the opposite: that a C-style language improved their understanding of lisp. (Not addressing you with this part, dear poster, since your gripe is rooted in the syntax.)

[NaN] “kids these days“ is just friendly ribbing. I’ve got the grey beard now, so I‘m free to play the part. Language maintainers tend to be older, and we cause more problems.

Re: An Intuition for Lisp Syntax

#187
I dunno if it is appropriate to post a lisp joke here but anyway

---

In the 1960's the KGB was very interested in learning everything possible about the American space program, sending all sorts of spies to find every possible piece of information.

One afternoon, a breathless spy returned to headquarters with a page of paper in his hand, excitedly shouting to his superior, "Comrade! Comrade! The Americans are using Lisp to write their rocket launching software!"

The commander was skeptical. "How do you know?"

"I broke into their research lab and stole a page from the teletype machine! It's not the whole program, but it's the final page and contains the concluding logic of the program! See for yourself!!!!"

The commander looked at the page and smiled:

)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))))))))))))))))))) ))))))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))))) )))))))))))))))))))))))))))))))))))) ))))))))))))))))))))))))))) ))))))))))))))))))))))))) )))))))))))))))))))))) )))))))))))))))))))) )))))))))))))))) ))))))))))))))) ))))))))))) )))) ))) )) )) )

---

Jokes aside, I think s-exp is actually a very good way to describe a tree because each nested parenthesis is a nested level in a tree with respect to some, e.g. (a (b (c d)) (e f)) means (b (c d)) and (e f) being a node in a and (c d) in b -> d in c -> f in e

Re: An Intuition for Lisp Syntax

#188
post #42

(shameless plug) In Feb 2020, during the first Clojure meetup organized in Chennai, I gave a talk titled "I'm LisP, I'm inevitable" in which I spoke about the journey towards lisp/scheme in muvee's flagship automatic video editing product. http://sriku.org/posts/inevitable-lisp/ It may be helpful to some to understand the recurrent pattern here so they can detect it early when it happens to them.

Watched the talk. The Muvee/MuSE journey must have been fun.

Re: An Intuition for Lisp Syntax

#189

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…

Let’s talk about text over symbols and readability.

Return the maximum value of the array “numbers”. The languages are listed in descending order of text > symbol.

Clojure:

  (apply max numbers)
JavaScript:

  Math.max(...numbers);
APL (I couldn't find how to apply this to an arbitrary array):

   ⌈/ 4 3 2 7 5 1 3
Here’s a guess:

  ⌈ numbers
The most aymbol-focused is the least readable to me, and Clojure is the only one that returned good results from a Google search to figure out what was going on. Both “JavaScript ...” and “APL ⌈” gave me irrelevant results.

Furthermore, how is this

  (if a
      true-cond
      false-cond)
harder to read than this, aside from familiarity?

  if (a) {
    trueCond
  } else {
    falseCond
  }
In the latter case, the if/else requires a special syntactical structure. And since it cannot be used as an expression, the common desire to conditionally assign a result spawned the ternary operator: a whole separate syntax that only applies when you want to assign a result to something. In lisps, you just use “if” wherever you need a binary conditional.

Re: An Intuition for Lisp Syntax

#190
post #188
post #42

(shameless plug) In Feb 2020, during the first Clojure meetup organized in Chennai, I gave a talk titled "I'm LisP, I'm inevitable" in which I spoke about the journey towards lisp/scheme in muvee's flagship automatic video editing product. http://sriku.org/posts/inevitable-lisp/ It may be helpful to some to understand the recurrent pattern here so they can detect it early when it happens to them.

Watched the talk. The Muvee/MuSE journey must have been fun.

It was indeed. It was also nerve-racking in many ways. We were trying to do GPU-based automatic video editing at a time when the Microsoft OSes were evolving rapidly, so were the NVidia and other drivers, and OpenGL itself .. with varied support for "optional" features .. not to mention that machines+OSes weren't yet 64-bit by default. The testing team had a great setup to cover a lot of ground, but there'll usually be something stumping us. It was also a time when people were moving to slower and smaller machines - like mini notebooks - where they'd expect to run muvee on the Intel integrated graphics chip at full screen res. It was also a time when video was graduating to HD and codecs weren't fast enough and 320x240@15fps wouldn't satisfy people any more. We needed 720x480@30fps at least for the previews and taking the GPU route was a no brainer due to that.

It was a case where we'd raised people's expectations so high (what'd take an editor perhaps a week to do happens in about 5 seconds with muvee) that unreasonable performance expectations became the norm :) You can, in seconds, try variations that would cause an editor to pull her hair. To top this all, the "constructor" which is the heart of the product had to be tested against many variations in media and styles.

The details of that journey is probably worth another talk on its own.

muvee released muSE as open source btw and you can find it here - https://github.com/srikumarks/muse . .. and it is (I believe) still usable in the "Reveal Encore" product.

edit: ... and along the way, muvee also built the first mobile automatic video editor which shipped on the ROM of early Nokia camera phones such as the 6630 (https://mobile-review.com/review/nokia-6630-camera-en.shtml .. scroll down to the "Movie Director" section)

Post reply on HN