Live data from Hacker News

Lisp is Abstract Syntax

michaelrbernste.in

31–40 of 55 posts

Re: Lisp is Abstract Syntax

#31
post #5

Earlier quoted context omitted.

Is grokking Lisp's parenthesized s-expressions actually difficult though? I think that the real problem is that developers believe that they will find it difficult before they try it, rather than actually finding it difficult when they eventually do try it. I don't think I've ever picked up another class of languages faster; even python took more effort from me. Basically, I think it's a marketing problem.

I have to respectfully disagree. I have coded for years in a lot of C-style languages, mainly C, Java, Python, Ruby & JavaScript and I've been struggling with the Clojure book (and various tutorials) for over a year. It's not just marketing, it's a very different mindset and one I'm not convinced is ever going to appeal to a large class of smart programmers (yes I guess I'm saying I don't think I'm dumb and hope I'm…

I'm a fan of Rich Hickey, too. And I think Clojure is a solid language. But I wouldn't suggest Clojure as the entry point when seeking a overall understanding of Lisp. There's too much baggage and history swirling around it for explanations ever to be comfortable - e.g. even if Rich Hickey always makes convincing arguments, it's important to note that they are always arguments.

That is there always seems to be at least as much of a subtext of Clojure defining itself by what it isn't as an explicit statement of what Clojure is. So much of what is said about it is said in the context of "Clojure is not Java, or Haskell, or Scala, or Scheme, or Common Lisp" and because that is so much a part of its culture, it has details drawn from 'the best parts' of each and mashed up.

Like Common Lisp, it is a language for working programmers and will trade practical accretion over striving for internal conceptual consistency. Unlike Common Lisp or Scheme, it doesn't have the sort of simple core that lends itself to tutorials from first principles and even if it did, the community tends to be experienced where just jumping into the middle is more the norm.

That's nothing against Clojure. It's just that any sort of gentle introduction to Lisp is probably better sought in those places where it already exists - SICP or the Racket ecosystem or Practical Common Lisp or PG's On Lisp are probably better introductions to what makes Lisp different. Clojure is probably a better second Lisp dialect for many people once they are ready for full tilt production code.

Re: Lisp is Abstract Syntax

#32
post #25

Earlier quoted context omitted.

Huh. I was around the AI Lab in the late 1970s -- as an undergrad -- and I don't recall hearing anyone talk about Chomsky in the way you imagine. DARPA funding was still flowing rather freely, it seemed to me, well into the mid-1980s. I don't recall anyone suggesting that there would have been yet more DoD money if it hadn't been for Chomsky. And the grad student I did some work for, who was working on natural langua…

Was Sussman talking about the syntax, or things like lexical scope, which he and Steele introduced to the LISP world with Scheme in the mid-70s? About the only relevant negative thing I remember being said about Chomsky in a period just after your's was Marvin Minsky saying he saved someone from going down a rabbit hole following Chomsky's work. But that was a judgement of merit of his linguistics work, not his polit…

Well, the lexical scope, certainly, but I don't recall him disparaging the syntax.

I don't recall any burning of Dragon Books. Nor was Vaughan Pratt tarred and feathered for releasing CGOL, which allowed one to write Lisp in infix syntax. People were aware of it, and a few people used it, but it didn't catch on in a big way. I don't think this was for ideological reasons; I think it was simply that most people writing Lisp (myself included) found that with proper editor support, editing fully parenthesized code is easy and pleasant -- more so, in many cases, than editing infix code. That is the fact that many non-Lispers cannot believe could possibly be true. And yet over and over again, people who learn Lisp report that it is.

Re: Lisp is Abstract Syntax

#33

I have yet to hear a good explanation why homoiconicity is a good thing or in any way easier to learn. My main problem is that you have to know all the same things, but they become unknown unknowns. Not being able to tell at a glance that the argument list in a lambda expression, as one of the most common examples, is doing something other than execute code is very confusing if you're expecting everything to follow t…

I don't think I've heard anyone argue that homiconicity makes Lisp easier to learn. I would characterize that as an advanced concept— it only becomes relevant once you start learning about macros.

As far as Lisp's syntax itself, the lack of special cases means there's less to learn. Myself, I like some of the sugar you get in Clojure for hashes, vectors, sets, etc.

As for macros themselves, ostensibly you don't need to know the implementation details of every macro any more than you need to understand what executing a Java method does in terms of JVM bytecode. In practice sometimes you'll goof up and try to map a macro over a list. Depending on your Lisp implementation, the mistake should be obvious. And depending on your editor, it may even highlight some or all macros differently.

Also, Racket also has a different approach than some of the Lisp reader manipulation you see in Common Lisp. We're getting outside my familiarity here though.

Re: Lisp is Abstract Syntax

#34
post #5

Earlier quoted context omitted.

Is grokking Lisp's parenthesized s-expressions actually difficult though? I think that the real problem is that developers believe that they will find it difficult before they try it, rather than actually finding it difficult when they eventually do try it. I don't think I've ever picked up another class of languages faster; even python took more effort from me. Basically, I think it's a marketing problem.

I have to respectfully disagree. I have coded for years in a lot of C-style languages, mainly C, Java, Python, Ruby & JavaScript and I've been struggling with the Clojure book (and various tutorials) for over a year. It's not just marketing, it's a very different mindset and one I'm not convinced is ever going to appeal to a large class of smart programmers (yes I guess I'm saying I don't think I'm dumb and hope I'm…

FWIW, you're learning two major paradigms at once: the immutable/functional paradigm and a Lisp, and Clojure itself has very strong opinions about the former. You'll get a very different feel from, say, Racket.

Is there something in particular you're having a hard time with, out of curiosity? I don't consider myself particularly brilliant but I didn't have a year's worth of trouble with Clojure.

Re: Lisp is Abstract Syntax

#35
post #6

Earlier quoted context omitted.

We're hard-wired for Lisp. Broca's area 44,45 and 47 are responsible for processing hierarchical structures.[1] That's why it's so easy to reason about Lisp code. [1] http://www.letras.ufrj.br/poslinguistica/recursion/papers/17...

I don't see what that specifically has to do with Lisp. Virtually every programming language in use has a recursive hierarchical structure.

The difference is that you end up with (e.g.) https://cs50.harvard.edu/resources/cppreference.com/operator... versus the AST being integral to the language itself.

Re: Lisp is Abstract Syntax

#36
post #16

What I think this is missing which was a huge part of the SICP course is that Lisp is probably the best language to write your own language in with a custom syntax tailored for the problem space you're working on. Even if it isn't trivial to do. An example is Clojure's Hiccup[0] where there's a whole new syntax for dynamic HTML generation. It's not a full new Turing-complete language, but it's a custom syntax and voc…

This one of the reasons why, as a Lisp programmer, I don't care much for Clojure. Three different bracketing constructs when one would do just fine. Now I have to go look up the difference between () and {} and [] just to emit some HTML.

That's funny. This is one of the reason why I don't care much for Common Lisp. Hashtables in particular are common as mud in programming, but I have to work with a clunky interface specific to each abstraction. Ironically this puts CL closer to Java and C++ than the likes of Python and Ruby.

Re: Lisp is Abstract Syntax

#37
post #5

The abstract syntax was intended to be used writing programs until designers could get around to creating a concrete syntax with human-readable punctuation (instead of Lots of Irritating Silly Parentheses), but programmers soon got used to programming directly in abstract syntax. That's some programmers who got used to the syntax. It may be absolutely true that once you get used to LISP's syntax, it is better than an…

Is grokking Lisp's parenthesized s-expressions actually difficult though? I think that the real problem is that developers believe that they will find it difficult before they try it, rather than actually finding it difficult when they eventually do try it. I don't think I've ever picked up another class of languages faster; even python took more effort from me. Basically, I think it's a marketing problem.

I'm a C/C++/Java guy. I didn't find the idea of Lisp or the basic syntax that hard.

Where I ran into trouble was not the strangeness of the syntax, but the sparseness: "It takes a macro to write a decent loop? Isn't that telling you that your basic syntax is ridiculously impoverished?" I mean, yes, you can implement absolutely anything, but in the bare syntax, you're given absolutely nothing.

Second trouble spot: Lack of static types. It makes it hard to reason about a function if I don't know what's passed into it. I have to read the code and guess, from what it does, what the form of the arguments were supposed to be. And every caller has to know it, and to follow it. If they don't, chaos will ensue, unless the function defends itself by checking the arguments. But that means verifying, by examination, that what got passed in is what was expected - not the easiest task.

Now, Lisp people say that this isn't a problem in practice, because as you play with the code, if the wrong thing happens it will throw you into the debugger. But different code paths wind up getting exercised in the wild, and I've spent most of my career in embedded systems. Dropping into a debugger is not an acceptable bug-handling strategy in my world. I'd rather have the compiler catch them.

Re: Lisp is Abstract Syntax

#38
post #16

What I think this is missing which was a huge part of the SICP course is that Lisp is probably the best language to write your own language in with a custom syntax tailored for the problem space you're working on. Even if it isn't trivial to do. An example is Clojure's Hiccup[0] where there's a whole new syntax for dynamic HTML generation. It's not a full new Turing-complete language, but it's a custom syntax and voc…

When I look at that sample, what strikes me is how much the "custom syntax" still looks like a bunch of S-expressions. How much flexibility does LISP really give you here? For example, say I wanted my DSL to use Python-style significant whitespace instead of brackets. Does LISP make that easy, or is my DSL restricted to using stuff that looks like S-expressions?

It might not be easy, depending. Without too much trouble you could write a macro for this:

    (my-macro "
    foo
       bar
    baz beez
       zang
          dang
          bang")
and have the macro parse the string manually into something the eval/apply loop understands. But I think it might get funky pretty quick, and you'll likely lose a lot of power in the process.

The example of Hiccup above doesn't add anything new to Clojure's syntax, the DSL is all legal Clojure data structures. That way it inherits all of the power of the underlying language, like if you want to dynamically generate new HTML - that functionality comes from Clojure. But doing that while modifying the syntax for meaningful whitespace wouldn't be easy.

Re: Lisp is Abstract Syntax

#39
post #5

Earlier quoted context omitted.

Is grokking Lisp's parenthesized s-expressions actually difficult though? I think that the real problem is that developers believe that they will find it difficult before they try it, rather than actually finding it difficult when they eventually do try it. I don't think I've ever picked up another class of languages faster; even python took more effort from me. Basically, I think it's a marketing problem.

I'm a C/C++/Java guy. I didn't find the idea of Lisp or the basic syntax that hard. Where I ran into trouble was not the strangeness of the syntax, but the sparseness : "It takes a macro to write a decent loop? Isn't that telling you that your basic syntax is ridiculously impoverished?" I mean, yes, you can implement absolutely anything, but in the bare syntax, you're given absolutely nothing. Second trouble spot: La…

You don't need to write macros to write a loop. What you probably do need is macros to create a new looping construct of your own... but it's not practical or idiomatic to do that in the first place in other languages.

If you want an "until" construct in Lisp, you can create one with macros easily and doing so would be considered fairly kosher. If you want an "until" in C, you could swing it with macros, but you'd be told to buzz off when it came time to receive code reviews for it.

Re: Lisp is Abstract Syntax

#40
post #18

Earlier quoted context omitted.

That's the wrong metric. I learned Scheme over 20 years ago and it wasn't that hard to use it for small college projects. But that's different from being comfortable working with large code bases full of unfamiliar code. Languages shouldn't be judged by how easy it is to write code, or read your own code, but rather how easy it is to jump into someone else's project and figure out what they did. The level of understa…

I think those problems stem from the embrace of metaprogramming, the creation of DSLs, and language oriented programming. I don't think that Lisp's typical lack of syntax is to blame there.

Well, Lisp's lack of syntax stands in the way of using syntax to tell a story.

Horrible as c++ might be in many respects, the elaborate and somewhat stereotyped syntax of the code some random person wrote does tell a story.

If the code uses the horrific "one big loop" convention, it's fairly easy at least to get that that is what's going on.

I've only occasionally scanned Lisp code but in my experience of this, it seems like the formatting of the code doesn't a clue about the programming idiom being used. Admittedly, part of this is that Lisp allows more and more powerful idioms. This part seems really cool by itself.

Despite that coolness, I think one has to admit there's a cost here, the cost of a large block of code not being graspable by an outsider.

Post reply on HN