6 ms·

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 diffi

by Crito 13y ago

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.

dimovich 13y ago
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-friederici.pdf http://www.letras.ufrj.br/poslinguistica/recursion/papers/17...
- thinkpad20 13y ago
  I don't see what that specifically has to do with Lisp. Virtually every programming language in use has a recursive hierarchical structure.
  - dimovich 13y ago
    The code itself is hierarchical in nature.
  - wonderzombie 13y ago
    The difference is that you end up with (e.g.) https://cs50.harvard.edu/resources/cppreference.com/operator_precedence.html https://cs50.harvard.edu/resources/cppreference.com/operator... versus the AST being integral to the language itself.
joe_the_user 13y ago
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. That is pretty much what I meant. But given that the language expressions people are exposed to in their lives before LISP inherently aren't going to look like LISP, this a "marketing problem" that isn't going to go away. LISP doesn't look like natural language, that won't change and will always be hard for people to get over.
cjo 13y ago
I always liked The Rise of Worse Is Better in explaining why C and its derivatives became the standard. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html
nilliams 13y ago
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 not alone in this feeling). I've heard Lisp described as an autistic language, and I think there's something to that. I don't think it's for everyone. I'm not on board that macros, homoiconicity and some of the other stated benefits of lisps are worth 'giving up syntax' for and I am far from convinced that lisps are the future of programming. I'm a huge fan of Rich Hickey and I want to love Clojure, I just can't. It's not for me and it's not a marketing thing. Rich is the best marketing a language could hope for.
- 6d0debc071 13y ago
  Are you using automatic indentation, parenthesis matching, and highlighting the current s-expression? Lisp environments have, or can be given, a lot of tools to make the syntax easier to follow at first. You may already have heard about those things - but I just thought I'd mention them on the off-chance you haven't. Personally I find the syntax a lot easier to read - less giving up syntax than eliminating what's always looked like a bit of a mess to me ^^ Though, horses for course maybe, as you say.
- brudgers 13y ago
  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.
skybrian 13y ago
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 understanding should be enough to see security bugs when they screwed up.
- Crito 13y ago
  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.
  - joe_the_user 13y ago
    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.
    - Crito 13y ago
      Nearly my entire professional career has been spent using languages other than lisps, but I am not really sure what you mean by use of syntax telling a story. Perhaps the subset of C++ used reveals something about the development team that wrote it I guess? But there are certainly analogous things in lisp. Is the code macro heavy or light? Was the developer trying to treat the language like an imperative language, or functional? Massive monolith functions, or many small almost mathematical functions? Comments, or no comments? I think that C++ and Lisp might actually be relatively unique in that respect. You typically don't see much variety in Java (beyond "This code was clearly written by a C developer who wishes he could just use C for this", which comes through loud and clear sometimes), and even less in Python.
AnimalMuppet 13y ago
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.
- Crito 13y ago
  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.
- hajile 13y ago
  In common lisp, a for loop is reduced to a goto internally via a macro which manipulates the syntax tree. In C, a for loop is internally reduced to a goto after the code is transformed into a syntax tree (manipulated by a non-standard and ad-hoc macro implementation). The difference here is that C must first make the syntax tree before it reduces the tree while CL reduces it immediately (since lisp code is already a tree). All languages must reduce to a limited ISA of primitives (or conversely, all HLL are built on small ISAs). Lisp does a lot of this conversion early on (because it can) while C does this much later (because it can't do it early). You're simply quibbling about how soon to do this conversion. LLVM does the same thing as lisp in that it reduces a seemingly large language into a small set of constructs (and then works to optimize this small core language). I would argue that a smaller core language is better because it is easier to reason about and easier to optimize. As to embedded, iRobot corporation created a lisp variant called L (based on a subset of common lisp) to use on their embedded processors via a bytecode VM. http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf Check out shen lisp (link below). It has (to my knowledge) the world's only Turing complete static typing system. Racket also has a static variant. Common lisp can be made into the equivalent of statically typed if you (declare) all variables and tell it to fully optimize. http://shenlanguage.org/ http://shenlanguage.org/

by Crito 13y ago

dimovich 13y ago

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-friederici.pdf http://www.letras.ufrj.br/poslinguistica/recursion/papers/17...

thinkpad20 13y ago
I don't see what that specifically has to do with Lisp. Virtually every programming language in use has a recursive hierarchical structure.
- dimovich 13y ago
  The code itself is hierarchical in nature.
- wonderzombie 13y ago
  The difference is that you end up with (e.g.) https://cs50.harvard.edu/resources/cppreference.com/operator_precedence.html https://cs50.harvard.edu/resources/cppreference.com/operator... versus the AST being integral to the language itself.

joe_the_user 13y ago

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. That is pretty much what I meant. But given that the language expressions people are exposed to in their lives before LISP inherently aren't going to look like LISP, this a "marketing problem" that isn't going to go away. LISP doesn't look like natural language, that won't change and will always be hard for people to get over.

cjo 13y ago

I always liked The Rise of Worse Is Better in explaining why C and its derivatives became the standard. http://www.jwz.org/doc/worse-is-better.html http://www.jwz.org/doc/worse-is-better.html

nilliams 13y ago

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 not alone in this feeling). I've heard Lisp described as an autistic language, and I think there's something to that. I don't think it's for everyone. I'm not on board that macros, homoiconicity and some of the other stated benefits of lisps are worth 'giving up syntax' for and I am far from convinced that lisps are the future of programming. I'm a huge fan of Rich Hickey and I want to love Clojure, I just can't. It's not for me and it's not a marketing thing. Rich is the best marketing a language could hope for.

6d0debc071 13y ago
Are you using automatic indentation, parenthesis matching, and highlighting the current s-expression? Lisp environments have, or can be given, a lot of tools to make the syntax easier to follow at first. You may already have heard about those things - but I just thought I'd mention them on the off-chance you haven't. Personally I find the syntax a lot easier to read - less giving up syntax than eliminating what's always looked like a bit of a mess to me ^^ Though, horses for course maybe, as you say.
brudgers 13y ago
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.

skybrian 13y ago

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 understanding should be enough to see security bugs when they screwed up.

Crito 13y ago
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.
- joe_the_user 13y ago
  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.
  - Crito 13y ago
    Nearly my entire professional career has been spent using languages other than lisps, but I am not really sure what you mean by use of syntax telling a story. Perhaps the subset of C++ used reveals something about the development team that wrote it I guess? But there are certainly analogous things in lisp. Is the code macro heavy or light? Was the developer trying to treat the language like an imperative language, or functional? Massive monolith functions, or many small almost mathematical functions? Comments, or no comments? I think that C++ and Lisp might actually be relatively unique in that respect. You typically don't see much variety in Java (beyond "This code was clearly written by a C developer who wishes he could just use C for this", which comes through loud and clear sometimes), and even less in Python.

AnimalMuppet 13y ago

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.

Crito 13y ago
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.
hajile 13y ago
In common lisp, a for loop is reduced to a goto internally via a macro which manipulates the syntax tree. In C, a for loop is internally reduced to a goto after the code is transformed into a syntax tree (manipulated by a non-standard and ad-hoc macro implementation). The difference here is that C must first make the syntax tree before it reduces the tree while CL reduces it immediately (since lisp code is already a tree). All languages must reduce to a limited ISA of primitives (or conversely, all HLL are built on small ISAs). Lisp does a lot of this conversion early on (because it can) while C does this much later (because it can't do it early). You're simply quibbling about how soon to do this conversion. LLVM does the same thing as lisp in that it reduces a seemingly large language into a small set of constructs (and then works to optimize this small core language). I would argue that a smaller core language is better because it is easier to reason about and easier to optimize. As to embedded, iRobot corporation created a lisp variant called L (based on a subset of common lisp) to use on their embedded processors via a bytecode VM. http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf Check out shen lisp (link below). It has (to my knowledge) the world's only Turing complete static typing system. Racket also has a static variant. Common lisp can be made into the equivalent of statically typed if you (declare) all variables and tell it to fully optimize. http://shenlanguage.org/ http://shenlanguage.org/