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

91–100 of 201 posts

Re: An Intuition for Lisp Syntax

#91

Post by TeMPOraL »

drran wrote: post #84
maximilianroos wrote: post #45

Earlier quoted context omitted.

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

JavaScript (which is based on Scheme dialect of Lisp) is formally specified, well-developed, and fast, so quote above is outdated.

JavaScript isn't based on Scheme, it's what would have been Scheme if deadlines and marketing needs didn't make Netscape use a hacky toy language instead.

The place where JavaScript contains "an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" is Babel.

Re: An Intuition for Lisp Syntax

#92

Post by chriswarbo »

username90 wrote: post #73
Reelin wrote: 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.

Lisp and s-expressions are two different things. In particular, there are various alternative syntaces for Lisp, which we can automatically convert between (e.g. via a pre-processor, or a reader macro), e.g

https://readable.sourceforge.io

https://www.dwheeler.com/readable/sweet-expressions.html

https://srfi.schemers.org/srfi-49/srfi-49.html

https://srfi.schemers.org/srfi-119/srfi-119.html

Re: An Intuition for Lisp Syntax

#93

Post by Perseids »

username90 wrote: post #81
simongray wrote: post #44

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…

While I agree with your statement, I would probably downvote your comment if it wasn't grey already. The reason is that you mostly state your opinion (aggressively so), but fall short on arguing why your opinion is true. If you can extend your argument / extend the list of arguments, I think your comment would find more appreciation.

Re: An Intuition for Lisp Syntax

#94

Post by chriswarbo »

modernerd wrote: post #51

Is structural editing a genuine advantage over line-based editing? The author presents it as such, but their structural editing example shows that it takes three operations to negate a condition (create array, write “not”, slurp forwards). That would be one operation in most line-based languages (write “!”), and it also introduces less line noise.

Structural editing can be used in many languages, not just Lispy ones (although it's most powerful in Lispy languages).

I use Emacs to write Haskell, Scala, Python, Bash, etc. and use at least some structural editing operations all the time, e.g. ctrl-right turns '(a, b), c' into '(a, b, c)' and ctrl-left goes the other way.

Re: An Intuition for Lisp Syntax

#95

Post by TeMPOraL »

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…

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 like Common Lisp. That's a consequence of being an extremely dynamic language, that ships a compiler and intertwines parsing, compiling and execution. The flip side of being able to run arbitrary computation at compile time is that, in general, you can't know what the program will do until you run it. The dominant free CL IDE, SLIME, does just that: it queries your running Lisp image for its current state, to provide you with formatting and autocomplete and other hints.

That said, "near impossible" is a function of community size. Had CL anywhere near as much popularity as Java or Python does, I'm sure folks at IDEA would make automatic refactoring work for CL as well :).

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

That I strongly object to. Code generation and compile-time execution aren't magic, or even particularly hard concept. They're just another flavor of code. You manage it the same way as regular code - you package it into modules with well-defined interfaces, and document them. I've worked with CL in a team settings, and I've worked on legacy CL code that's as old as I am; it's not harder than "regular" legacy code. And you always have to write your documentation yourself, there's no escape from that, no matter what language you use.

Re: An Intuition for Lisp Syntax

#96

Post by username90 »

capableweb wrote: post #71
mythz wrote: post #62

Earlier quoted context omitted.

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 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 much time you spend with brainfuck.

Re: An Intuition for Lisp Syntax

#97

Post by ACow_Adonis »

username90 wrote: post #85
wavegeek wrote: post #75

Earlier quoted context omitted.

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

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 of lisp under my belt, even the closure examples (and I've never used clojure) parse pretty close the speed of thought.

It really is hard to explain to someone who hasn't used lisp for 6-12 months, but there really is a lisp "enlightenment" experience, which is totally unlike anything I've experienced with any of my other languages. I'm not saying this makes it better or worse than other languages, but I am saying it's real, and that lisp code is not only parsable, but exceptionally so to an experienced lisp programmer. One day you're sitting there thinking there's a whole lot of brackets, balancing and indentation in this godforsaken language, and then something just clicks over in your brain and you don't even see the brackets any more and it's all just data structure, and you see the shape of it, and you say to yourself "well that was pretty fucking cool" and from that day on you don't really see the brackets any more, it's all just names, indentation and data structures.

edit: and it should also be recognised that an editor implementing parentheses balancing, indentation options, and keyword lookup/ completion also becomes a relatively trivial exercise when your code consists of variable names and structured data.

Re: An Intuition for Lisp Syntax

#98

Post by mythz »

monsieurbanana wrote: post #72
mythz wrote: post #62

Earlier quoted context omitted.

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

I've also spent a bit of time with LISPs, when learning Clojure I ported the Clojure 101 LINQ Examples [1] and did appreciate a lot of niceties that Clojure brings with it where the additional syntax actually added to its readability, e.g. the usage of vector syntax for function params provided a welcomed visual separator from its implementation body. Basically all its additional syntax improves readability over a LISP's typical clumped sea of parens where you can more quickly discern different constructs from a glance which would otherwise take me a lot more time & effort trying to determine the boundaries of each expression whilst evaluating them in my head, effectively conveying that the minimal s-expression syntax that's optimal for the compiler isn't optimal for humans.

So when it came time to implementing a .NET LISP [2], I adopted much of Clojure's additional syntax for improved readability & interop with .NET APIs [3]. But you can only improve LISP's syntax so far, e.g. its Template libraries for HTML generation [4] make for horrible HTML DSL's which looks nothing like the HTML it's supposed to generate. The solution to overcome this was basically to not to use LISP for templates, instead create a multi-language scripting language [5] that embeds lisp into it allowing it to Combine strength's of all languages [6], e.g. use LISP for algorithms and Handlebars / JS Expressions for templating.

The REPL is definitely one of its super powers which is one areas where it shines & basically the primary use-case where I still use it. I've created a live "watch" mode & deep integration with .NET libs that I use for discovery, e.g. run DB queries, call HTTP APIs, execute shell scripts, etc. [7]. It especially shines for being able to open a REPL session with a remote production .NET instance letting me inspect its live running state & invoke system functionality like querying its configured RDBMS, executing redis commands, send tweets, emails, etc [8], I've even got it to Live Script Unity objects in-game :) [9], which speaks to the power & elegance of LISP that's able to achieve so much with so little code.

At the same time I don't think REPL-based programming is all that useful during normal development, you can execute encapsulated code fragments fine, but most of the time I'll need my whole environment constructed before being able to inspect it as I would when debugging, so I find it useful for opening a REPL session into a live running instance, but not using the REPL to construct the live instance. So for my dev workflow, static analysis & typing, great IDE, tooling + debugging is a lot more useful.

[1] https://github.com/mythz/clojure-linq-examples

[2] https://sharpscript.net/lisp/

[3] https://sharpscript.net/lisp/#net-interop

[4] https://www.cliki.net/HTML%20template

[5] https://sharpscript.net/docs/syntax#language-block-modifiers

[6] https://sharpscript.net/docs/syntax#combine-strengths-of-all...

[7] https://sharpscript.net/lisp/#run-and-watch-lisp-scripts

[8] https://sharpscript.net/lisp/#techstacks-tcp-lisp-repl-demo

[9] https://sharpscript.net/lisp/unity

Re: An Intuition for Lisp Syntax

#99

Post by coldtea »

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]

Re: An Intuition for Lisp Syntax

#100

Post by capableweb »

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…

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 source, both user focused and libraries. Same with JavaScript. And I can say, as someone with more JS experience than Clojure, that the Clojure projects tend to be a lot easier to understand than the JS ones, probably not because of the language, but because of the habits that the language "forces" you into.

Post reply on HN