Live data from Hacker News

An Intuition for Lisp Syntax

stopa.io

21–30 of 201 posts

Re: An Intuition for Lisp Syntax

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

Common Lisp has long been a compiled language. Its performance is quite competitive when set against Fortran and C. The idea that it's interpreted (and consequently slow) is a very old myth.

Of course, it helps to use the right data structures if you want fast Lisp code (using lists for everything is not the right choice).

Re: An Intuition for Lisp Syntax

#22
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'.

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 doesn't get created and widely used when an existing solution already exists.

Re: An Intuition for Lisp Syntax

#23
post #13

Earlier quoted context omitted.

It would look like smalltalk: [sendMessage with:arg1 to:arg2]

Common Lisp has keyword args too.

To be clear this is something I’ve thought a bit about. I think the interesting analog is not maps per se, but relational tuples. Instead of “everything is a list”, it would be “everything is a tuple”, and the environment is a table. Evaluate a tuple to execute, evaluate a table to execute in parallel.

Re: An Intuition for Lisp Syntax

#24
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

imo this is not only a problem in a singular large code base, but also libraries.

I know not everyone likes Go, but I've noticed that i find it super easy to dig into some open source dependency and navigate it, because in some ways Go is the exact opposite of lisp. In terms of the language not allowing a lot of flexibility at least.

I never found navigating foreign java code bases that easy because this project uses spring for dependency injection, that one does some other class loader magic etc, streams, no streams etc. pp.

That said, I do think LISP is cool, but I think it ends up being a right tool for the job kind of thing. I could imagine LISP being nice for things like game engine scripting etc.

Re: An Intuition for Lisp Syntax

#25
post #20
post #8

Earlier quoted context omitted.

The formal Scheme syntax spec is, what?, a few pages. Far smaller than any other "real" language I'm aware.

I'm not too familiar with scheme, but syntax seems to be at least a few dozen pages here? www.r6rs.org/final/r6rs.pdf Also compare https://people.csail.mit.edu/jaffer/r5rs_9.html and e.g. https://docs.python.org/3/reference/grammar.html which I would consider a relatively syntactically rich language.

R6RS was the largest Scheme spec ever, and because of it the next one was actually reduced into two: R7RS-small (core-language) and R7RS-big (extended).

The R7RS-small standard [0] has already been ratified. It is a similar size to R6RS as a document size, but the semantics are about 8 pages, and include a bunch of macros that you don't need to implement, but just copy and paste into your implementation.

I'd say it's a similar sized grammar to Python's.

[0] https://small.r7rs.org/attachment/r7rs.pdf

Re: An Intuition for Lisp Syntax

#26
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'.

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 to solve systemic organizational or educational issues with it is probably counterproductive though.

Re: An Intuition for Lisp Syntax

#27
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'.

'unless vs 'if-not vs 'negat-if is "just" a naming issue, it's the same in any other language wrt functions. IME a bigger issue is jumping between code and data, both for the writer of the macro (viz macros to ensure that a form is evaluated at most once) and the user (is this thing a macro? Is this form going to be evaluated or quoted?).

The benefit is being able to extend the language. Context managers in Lisp are just macros. Clojure's spec and async are macros.

For sure, the joke about blowing your whole leg off (as opposed to just your foot) applies, but it's the same for concurrency, distributed systems, cryptography, etc. The answer isn't to ban it, it's to exercise more care in the construction of these abstractions so that mere mortals can use them safely.

Re: An Intuition for Lisp Syntax

#28
post #10

I've never really bothered to learn lisp, but this is incredible. I get it now. That being said, I wonder how data types would work as opposed to lists. What would a language based around maps look like?

Indeed - I have also wondered what a “struct processor” rather than “list processor” would look like.

I keep thinking code blocks and the struct/map definition could possibly both use `{ ... }`, which might appear a bit like some other languages? What about function calling and definitions?

The S-Expr thing seems to indicate you’d still need a “head” then a list of key-value pairs?

Re: An Intuition for Lisp Syntax

#30
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'.

'unless vs 'if-not vs 'negat-if is "just" a naming issue, it's the same in any other language wrt functions. IME a bigger issue is jumping between code and data, both for the writer of the macro (viz macros to ensure that a form is evaluated at most once) and the user (is this thing a macro? Is this form going to be evaluated or quoted?). The benefit is being able to extend the language. Context managers in Lisp are…

Julia seems to get around this by making macro syntax explicit [1]: e.g. the macro "code_native" is used as @code_native (expr)

This makes macro wizardry easier to spot, but restricts how "plastic" the language is somewhat.

https://docs.julialang.org/en/v1/manual/metaprogramming/

Post reply on HN