[pjc50]

I would like to make the controversial claim that homoiconicity counts against adoption; the single representation carries little structural information and the meaning of a symbol is highly dependent on its containing context. Whereas the ALGOL-derived languages use different types of bracket or other means to indicate visually what the semantics are.

Ironically modern Javascript often replicates the bracket pileup, just with "})" instead. Python does away with it by having "nonindented newline" as an invisible semantic character that closes any number of scopes.

[kazinator]

> the meaning of a symbol is highly dependent on its containing context

That being a problem is pretty much solved by not writing 1000 line top-level expressions with thirty nesting levels.

People who actually write Lisp are engaging their imagination for the program itself. Thus their imagination is too busy to come up with scary reasons how things could go wrong that would spook them out of continuing.

[AnimalMuppet]

Hmm. I've been thinking for a while now that Lisp (and also FP) matches how some peoples' minds work, and doesn't match how other peoples' minds work. For those who match Lisp and/or FP, it's like a revelation, and it's very freeing. For others, not so much - it's a new way of programming, and you can do it that way, but why would you want to?

You said:

> ... the single representation carries little structural information and the meaning of a symbol is highly dependent on its containing context.

That makes me wonder if the difference is abstract vs. concrete thinking - those who by nature prefer abstract thinking will find Lisp more natural, and those who prefer concrete thinking will find it clumsy and unsettling.

Choosing the "right" programming language is not just finding the right language for the task (though it is that). It's also finding the right language that fits our minds - and our minds are not identical.

[lispm]

I think it can be learned - but one needs to have an open mind. If one has learned how a specific program look like in something like PASCAL and then later learns Lisp, there are a bunch of concepts which need to be adjusted...

I started with BASIC, various Assembler variants, PASCAL, UCSD PASCAL, MODULA 2, ... and then learned Lisp variants and Scheme - and also learned basics of some other languages like ObjectPascal, SAIL, Prolog, Postscript, Smalltalk, ...

[sumnole]

I'll also add that its powerful and easily deployable macro facilities due to its homoiconicity hurts adoption as well. Macros and dsls can make for increased productivity /decreased loc for individuals and small teams, but the same features can be not so good for large teams and communities, as each program may tack on more and more macros to keep in mind before fully understanding the code being read. I find it easier to read through even a lengthy file of c code using the same old familiar primitives, ymmv.

[lispm]

That's not how code reading works. There are at least two levels of code reading: understanding WHAT the program does and understanding HOW it works.

Most of the time a Lisp programmer wants to read WHAT the program does and that in a very descriptive notation.

Any Lisp has a lot of macros. The base Common Lisp language is full of macros. Any defining operator - functions, macros, variables, classes, structures, methods, ... - is already a macro.

For example a structure - a record - is defined like this:

  (defstruct ship
    (x-position 0.0 :type short-float)
    (y-position 0.0 :type short-float)
    (x-velocity 0.0 :type short-float)
    (y-velocity 0.0 :type short-float)
    (mass *default-ship-mass* :type short-float :read-only t))

This is using the macro DEFSTRUCT.

It's easy to see that it defines a structure type called SHIP with 5 slots. Each slot has a default value and named options.

A programmer will NEVER need to see what the expansion looks like. The code the macro generates is twenty times larger than the source code. What the programmer actually needs is a documentation of what effects the macro has: defining a type, defining accessors for the slot, defining a type constraint for the slots, making one slot read only, ... This is better read from the documentation of this macro operator, instead of trying to see it from reading low-level operator code implementing them.

Every programmer will be happy to read this macro form - no one wants to see the expanded code, how structures are actually defined in terms of low-level operators.

Thus MACROS increase the readability of programs a lot - independent of the team size. Really no one would want to define a structure type by manually creating all the definitions for it (a type, an allocation function, slot accessors, type predicate, compile time effects, ...).

What they can make more difficult is some maintenance tasks - where bugs appear on a meta-level where programs transform code.

[mcguire]

One word: loop :-)

(It's a bizarre, mini language for looping constructions and terrifying animals and small children.)

[lispm]

  (loop for i from 10 upto 20
        do (print i))

what does it do? Maybe it prints the numbers from 10 upto 20?

    (loop for element across vector
          sum element)

Hmm, what does it do? Maybe it sums all the elements of a vector?

Ada:

  for E of The_List loop
     if Is_Prime(E.P) then
        E.Q := E.Q + X;
     end if;
  end loop;

Lisp:

  (loop for e in the-list
        if (primep (p e))
          do (incf (e q) x))

Totally weird and bizarre how it looks similar.

Even stranger:

  (
  loop for e in the-list
       if (primep (p e))
          do (incf (e q) x)
       ; end if
  ; end loop
  )

[mcguire]

"The Anatomy of a Loop", Olin Shivers. http://www.ccs.neu.edu/home/shivers/papers/loop.pdf

And that's in Scheme, so it doesn't look like someone dropped a chunk of Algol in your coffee.

[lispm]

Which explicitly mentions loop systems for Lisp as its inspiration: Yale Loop and Jonathan Amsterdam"s excellent ITERATE.

[dreamcompiler]

I use simple loop constructs like the above all the time; it's especially useful for collecting. But elaborate loop constructs in their full glory are impossible to understand and IMHO should be banned from use on any software engineering team.

[TeMPOraL]

Seen pretty elaborate loop constructs in large Common Lisp code bases I was working on, and my conclusion is that the only thing that should be banned is lack of willingness to spend 30 minutes at some point learning the loop syntax. Seriously, after you write few loops on your own e.g. collecting over several hash tables in parallel, you won't have much problem anymore.

I still feel current generation of programmers has a learning phobia.

[gumby]

Yeah, LOOP is super un-lispy. Dick waters is a great guy but I never liked LOOP and never use it.

[lispm]

What does it have to do with him?

The basic idea comes actually from Interlisp and Warren Teitelman‘s ‚Conversational Lisp‘ and its FOR macro.

The main purpose of LOOP is to question ones assumption what is Lispy and what not. ;-)