Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

71–80 of 201 posts

Re: An Intuition for Lisp Syntax

#71
post #62

Earlier quoted context omitted.

If you buy into the argument that less code, that writing code at a higher level of abstraction results in less time to market, less maintenance overhead, more responsiveness to change in future, less bugs etc. Etc. If you believe a 1000 line program is worse than a readable 100 line program that both do the same thing, then lisp with its macros is that thing. Super expressive and readable. I went from not being able…

The argument isn't whether less, readable, higher-abstraction code is better than its opposite, it is. It's whether or not a real-world LISP code-base espouses these qualities. Which I don't believe it does, IMO the primary reason LISP isn't mainstream is because it results in less readable code for humans (i.e. the primary objective of programming languages), it's semantically the perfect minimalist language for a m…

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 language and more to learn about conventions, while C-like languages always have bunch of extra syntax you have to learn, otherwise the compiler cries.

> Other disadvantages include lack of typing & poor tooling support

Not sure these are inherent to Lisps. There are plenty of typed lisps, and even the ones that don't have types, can have types added to them after the fact, just because they are Lisps.

Regarding tooling, I'd say that the entire C-like ecosystem is far behind any Lisp language regarding tooling. I mainly see people using "println"'s for debugging, and sometimes using a "line debugger", while Lisp developers modify their code at runtime and have a far more advanced debugger, something C-like languages will probably never do as well as Lisp-like languages does it, again because of s-expressions and the code they make you write.

Re: An Intuition for Lisp Syntax

#72
post #62

Earlier quoted context omitted.

If you buy into the argument that less code, that writing code at a higher level of abstraction results in less time to market, less maintenance overhead, more responsiveness to change in future, less bugs etc. Etc. If you believe a 1000 line program is worse than a readable 100 line program that both do the same thing, then lisp with its macros is that thing. Super expressive and readable. I went from not being able…

The argument isn't whether less, readable, higher-abstraction code is better than its opposite, it is. It's whether or not a real-world LISP code-base espouses these qualities. Which I don't believe it does, IMO the primary reason LISP isn't mainstream is because it results in less readable code for humans (i.e. the primary objective of programming languages), it's semantically the perfect minimalist language for a m…

First rule of macros is: do not write macros. At least in clojure, it's rare that I stumble upon macros in the wild. But when they're needed (someone else wrote about core.async in this thread) they are very useful.

After one year of clojure, it's annoying for me to read classic C-like languages. There's also people who prefer reading code without syntax color, so clearly this is a subjective matter.

I find clojure tooling really good, and it's hard to go back to a non-repl oriented workflow (this is not at all the same as something like python or javascript repl). But this is admittedly a gray area, there's areas where it's immature compared to other languages, and others where it shines because of it's repl-oriented nature.

The lack of typing is certainly a sound argument, although my personal opinion is that for many use cases it isn't required. This is going to be a contentious opinion, I'm sure.

Note that clojure has an advantage on this over other dynamic languages: idiomatic clojure code means that pretty much everything is pure data, in basic structures: maps and vectors. So the functions that you use to operate on your data are always the same. Over time you'll learn them, and they won't change between domains nearly as much as, say, if you were coding in OOP oriented python.

Re: An Intuition for Lisp Syntax

#73
post #32

Earlier quoted context omitted.

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.

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.

Re: An Intuition for Lisp Syntax

#74

Can anybody recommend resources for the "next level"? I get that "code is data", the "unless" example is nice, but what I don't get is: why would I want to do that? As a non-LISP developer I get by without macros and all the fancy things that are possible with LISP. I would like to see a strong case of daily tasks that are much easier with LISP macros. Anybody?

They're great for implementing complex language semantics like cooperative multitasking (using macros to expand yield/resume points into a state machine for stackless coroutines, for example). Or cool object systems like type classes and multi methods.

Smaller stuff like hand rolled parsers and serializers are much easier to get working fast (both time to write and time to run) using macros. Since a good chunk of my work is data flow in one form or another, I miss LISP macros a lot.

Re: An Intuition for Lisp Syntax

#75

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 supposed to be better than paper...".

The text editor handles indenting and matching. After a while it is completely transparent.

Re: An Intuition for Lisp Syntax

#76

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 wonder how much is survivorship bias

Here is one anecdata. When my daughter was 14 I taught her a Lisp and then a traditional programming language. She found the random syntax of the trad formatted language bizarre.

Re: An Intuition for Lisp Syntax

#77

Earlier quoted context omitted.

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.

It's just a different paradigm than what most developers are familiar with so there is a learning bump, same as functional programming if all you've done is object-oriented stuff. The awkwardness is only temporary. If you can already see the beauty of Lisp code, then you just need to build a little project in it to make the awkwardness fade away. I recommend Clojure/ClojureScript. It's quite practical for web develop…

I used Common Lisp as my main language for about 6 years (long time ago now) - yes for the first few days the syntax is a bit jarring but I've found that any new language is fundamentally different in approach to what you are used to has that effect (pretty much the same happened the first time I saw C, Lisp, PostScript etc.)

Re: An Intuition for Lisp Syntax

#78

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…

> it would be cool if we could generate them from more readable syntax There are a few options out there; maybe take a look at Sweet Expressions? Some Lisp implementations have native support for different syntax, but the nice thing about these formats (which are essentially just serialisations of concrete syntax trees) is that we can convert them into the expected format automatically, e.g. using a pre-processor. I…

Syntaxen?

Re: An Intuition for Lisp Syntax

#79

Can anybody recommend resources for the "next level"? I get that "code is data", the "unless" example is nice, but what I don't get is: why would I want to do that? As a non-LISP developer I get by without macros and all the fancy things that are possible with LISP. I would like to see a strong case of daily tasks that are much easier with LISP macros. Anybody?

Macros are in practice a tool to reduce boilerplate. Which is why they are typically written for libraries and used in application code.

For example parametrization and modularization are used to keep code DRY and separated at a functional level.

However this can only get you as far as you still write ceremonial repetition around using those functions/modules/objects. Macros can get your code to that extra level of brevity and clarity.

Re: An Intuition for Lisp Syntax

#80

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 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 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! You want outsiders to participate (think: new employees)? Write all documentation yourself, too!)

[1] http://www.paulgraham.com/avg.html

Post reply on HN