Hacker News Reader

Comment by joe_the_user | Hacker News Reader

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 any other. The problem is that since one is dealing with human beings, and with human beings you have the power of first impression and the tendency to make snap decisions based on these, people initial difficulty in grokking LISP's syntax is always going to be a hurdle for the language.

View on HN

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.

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 code itself is hierarchical in nature.

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.

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.

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

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.

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.

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.

In learning Clojure first then Racket, it struck me how many good ideas came from racket.. and now how many are still being mined - typed racket being the obvious one.

I don't know how much Rich Hickey used Racket, but he used Common Lisp for several years and wrote some complex libaries for it. There is also a sketch of Clojure early on written in Common Lisp.

Racket started out as a Scheme, and Clojure has mined quite a bit from Scheme. Both are Lisp-1s, loop/recur, not accepting a lot of mainline LISP (e.g. Common Lisp nowadays) baggage, etc.

Actually there is not much Clojure got from Scheme. Lisp 1 is not tied to Scheme. loop/recur is much less powerful than Scheme's TCO.

Lisp-1 is pretty firmly tied in most people's minds to Scheme: at the very least the paper that coined the terms (http://www.nhplace.com/kent/Papers/Technical-Issues.html) ascribed it to Scheme, and as far as I know it first came from Scheme (although it's so easy to create a low performance Lisp I wouldn't be surprised if that had been tried before).

loop/recur is of course much less powerful than TCO, because the JVM doesn't natively support it (it's not trivial, security wise). There are three other Lisps on the JVM that I know of: SISC Scheme is mostly dead but does TCO at a cost in speed, Kawa Scheme has as of late added fine grain control over TCO, and Armed Bear Common Lisp doesn't try, as Common Lisps are not required to.

But loop/recur sure looks to be ultimately inspired by Scheme style use of TCO; I just did a set of functions using it for the first time and everything I learned from SICP/6.001 applied and made that part of it trivial.

Haskell also has only one namespace. I propose that Clojure took it from there, including persistent data structures, lazy data structures, ...

> But loop/recur sure looks to be ultimately inspired by Scheme style use of TCO;

To me it looks more like ancient Lisp with prog and goto.

    (defun foo ()
      (prog ((a 1))
        start
        (print a)
        (when (< a 10)
          (incf a)
          (go start))))

Old Lisp code is full of that. It's basically what LOOP/RECUR provides.

That's the advantage of Racket's close relationship with academia...'Implementing x in Racket' is publishable and 'A y Library for Racket' is a Master's Degree project.

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.

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.

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.

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.

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.

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.

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

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/

Kind of funny that people in the embedded area use C, which has a very weak type system and the result of using C is usually unsafe (no matter how programmers try) - even though its supposed to be compiled with static type checking.

> "It takes a macro to write a decent loop?"

That's the usual way to introduce a LOOP. As most Lisp implementations are written in Lisp, most syntactic constructs are macros anyway - whether they are at the language or the user level. For many Lisp systems there is really no distinction between both.

> Dropping into a debugger is not an acceptable bug-handling strategy in my world.

For embedded programming Lisp can have a lot of problems:

* lack of compile time safety

* the need for Garbage Collection

* no low-level machine types

* more...

Since the nature of 'embedded' is changing, some of that might no longer be such a big problem. In some areas 'embedded' systems are suddenly actually full-blown connected computers.

Reply on news.ycombinator.com