6 ms·

I think because it is a powerfull language - and once you learn to look past the parentheses it actually has some pretty cool features. For example, it is a ho

I think because it is a powerfull language - and once you learn to look past the parentheses it actually has some pretty cool features. For example, it is a homoiconic language, so any piece of data can be evaluated as if it is code. The only way to really understand it is probably to learn it :)

pjc50 8y ago
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.
- AnimalMuppet 8y ago
  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 8y ago
    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, ...
- kazinator 8y ago
  > 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.
- sumnole 8y ago
  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 8y ago
    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.

pjc50 8y ago

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.

AnimalMuppet 8y ago
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 8y ago
  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, ...
kazinator 8y ago
> 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.
sumnole 8y ago
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 8y ago
  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.