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

61–70 of 201 posts

Re: An Intuition for Lisp Syntax

#61

Post by zozbot234 »

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.

> Is structural editing a genuine advantage over line-based editing?

A full-featured editor should support both. Line editing is convenient for some editing operations/workflows where you don't necessarily have a well-formed AST at all times. But for many other workflows, structural editing is preferable.

Re: An Intuition for Lisp Syntax

#62

Post by mythz »

CraigJPerry wrote: post #54
blackbear_ wrote: post #53

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?

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 machine but I don't believe it's optimal readability for humans. Other disadvantages include lack of typing & poor tooling support. There's certainly domains it excels at due to its intrinsic qualities but I don't see it ever becoming a popular mainstream general purpose programming language.

Re: An Intuition for Lisp Syntax

#63

Post by kreetx »

roenxi wrote: post #52

The article and the heading seem to diverge a bit. "An Intuition for Lisp Syntax" is much simpler than all the pages: in lisp, the syntax for control structures like a loop is the same as the syntax for everything else. The reason for that is because introducing special syntax disrupts useful patterns that could be used for writing completely new control structures. Threading macros, for example, are pretty much impo…

Also, haskell has "only" expressions and no statements.

Re: An Intuition for Lisp Syntax

#64

Post by culturedsystems »

wwosik wrote: post #60

I don't think I like it. I find it hard to quickly skim and find out what each of the elements is, since it can be anything. The example amounts to: function drawTriangle(left, top, right, color) { drawLine(left, top, color); drawLine(left, right, color); drawLine(top, right, color); } drawTriangle({ x: 0, y: 0 }, { x: 3, y: 3 }, { x: 6, y: 0 }, "blue" ); drawTriangle({ x: 6, y: 6 }, { x: 10, y: 10 }, { x: 6, y: 16 }…

Indeed, I think this post ends up being a good argument against Lisp. The supposed negative for JS, as opposed to Lisp, is that "We’d need something like Babel to parse our file, and work on top of the AST to make sure we rewrite our code safely." And? Computers are good at parsing, and adding syntax to a language should be comparatively rare, so why would I choose a language that optimizes for this case, rather than one which optimizes for human readability?

I think some people will argue that macros shouldn't be rare, that you should define a custom DSL for each application so you can work at a higher level of abstraction. However, macros themselves operate at a fairly low level of abstraction (operating on the AST, rather than closer to the problem domain). I would argue that if you find yourself using macros frequently, that's a sign your language is lacking in higher-level abstraction capabilities.

Re: An Intuition for Lisp Syntax

#65

Post by agumonkey »

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…

now you can go read norvig lisp in python

very similar, build out of python []

Re: An Intuition for Lisp Syntax

#68

Post by Reelin »

brabel wrote: post #48
javajosh wrote: post #14

Earlier quoted context omitted.

First of all, a map can be defined as a list where the even elts are labels and the odd ones are values. So it would be a lot like lisp but every elt in every list would have an extra before it, a short string name.

It's the other way around, actually. If you define a map as a list, it will have none of the properties of a map: you can't lookup a key in constant time. But if you start with maps, then you can represent a list as a special case of a map in which the keys are integers that get incremented, starting at 0.

GP isn't talking about the runtime implementation but rather the serialization format. You can serialize a map as a list. Therefore, a hypothetical Lisp-like language based around maps could simply end up consisting of lists that contain key value pairs.

Re: An Intuition for Lisp Syntax

#69

Post by ywei3410 »

wodenokoto wrote: post #67

> What if we let our remote user define their own functions? Aren't we then back at the problem with using eval?

No, because you control the base primitive functions by passing in fns. In more formal terms, you can control the context.

If we really cared, it would be trivial to extend this to a typed variant or change the evaluation semantics. Here's an example in another language [1].

[1] https://www.youtube.com/watch?v=YxhBxHl76vc

Re: An Intuition for Lisp Syntax

#70

Post by username90 »

Jtsummers wrote: post #21
trevyn wrote: 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).

> Its performance is quite competitive when set against Fortran and C.

No, not at all. It is the same level as Java, a bit slower but I guess that is because there is more work done on Java. Just because you compile a language doesn't mean it is as fast as other compiled languages. You can compile python down to a binary but it will still be super slow.

Post reply on HN