4 ms·

LISP is powerful because its fundamental syntatic structure and data structure are the same- a list where the first element is the function-name or keyword. You

LISP is powerful because its fundamental syntatic structure and data structure are the same- a list where the first element is the function-name or keyword. You can basically write programs that extend themselves by writing out new functions and data. Other modern languages like html and json have the nested list as the fundamental data structure. But they arent self-executing like LISP. But having one main syntactic and data structure- the list- is what makes LISP annoying too. You have to translate other syntax and data structures into lists. Its always possible, but sometimes kludgey and unreadable. An advantage of LISP in the 1960s was that it was interpreted, i.e. relatively high speed feedback for short programs, compared to its competitors which where batch-compiled, and might take hours to see how they would run.

mordocai 10y ago
> But having one main syntactic and data structure- the list- is what makes LISP annoying too. You have to translate other syntax and data structures into lists. This is what macros (especially reader macros) are for. Just translate it once and then save the transformation as a macro and write it the natural way for you. Of course, that's a lot easier to do/maintain when it is just you working on the project.
TheLarch 10y ago
"But having one main syntactic and data structure- the list- is what makes LISP annoying too. You have to translate other syntax and data structures into lists. Its always possible, but sometimes kludgey and unreadable." I like everything but the quotation above. This is a higher-level version of the ubiquitous "the parens are ugly" objection. This objection misses the point because "Lisp is a building material, not language." In order to use Lisp effectively you design an intermediate language appropriate for the problem domain. This approach is fundamentally at odds with a language such as Java, whose premise is that it provides all the abstractions you need to solve the problem directly. With Lisp you literally have whatever language you want. Non-Lisps leak more and more as complexity increases. Two examples that jump to mind right away are lambdas in Python and generics in Java. In both cases the designers plugged holes in the abstractions they chose years before. Both are kludgey in my eyes, clear afterthoughts. Both features are trivial in Lisp. Lisp is so simple that the limitations never arose in the first place. Your language has made a compromise to simplify these things, but at the expense of flexibility. C++'s accretion disk is a marvel at this point. You can use macros to streamline elaborate data structure creation by the way.
junke 10y ago
As an example on non-list, literal data structure (atom), see: CL-USER> (ql:quickload :local-time) CL-USER> (in-package :local-time) LOCAL-TIME> (now) => @2016-08-05T17:41:54.492977+02:00 LOCAL-TIME> (enable-read-macros) LOCAL-TIME> (describe @2016-08-05T17:41:54.492977+02:00) @2016-08-05T17:41:54.492977+02:00 [standard-object] Slots with :INSTANCE allocation: DAY = 6001 SEC = 56514 NSEC = 492977000 LOCAL-TIME> (class-of @2016-08-05T17:41:54.492977+02:00) #<STANDARD-CLASS LOCAL-TIME:TIMESTAMP> And again, how your AST is encoded has nothing to do with the value you manipulate at execution: (make-hash-table) is a list with one symbol, but when evaluated, you obtain a good old hash-table.

mordocai 10y ago

> But having one main syntactic and data structure- the list- is what makes LISP annoying too. You have to translate other syntax and data structures into lists. This is what macros (especially reader macros) are for. Just translate it once and then save the transformation as a macro and write it the natural way for you. Of course, that's a lot easier to do/maintain when it is just you working on the project.

TheLarch 10y ago

"But having one main syntactic and data structure- the list- is what makes LISP annoying too. You have to translate other syntax and data structures into lists. Its always possible, but sometimes kludgey and unreadable." I like everything but the quotation above. This is a higher-level version of the ubiquitous "the parens are ugly" objection. This objection misses the point because "Lisp is a building material, not language." In order to use Lisp effectively you design an intermediate language appropriate for the problem domain. This approach is fundamentally at odds with a language such as Java, whose premise is that it provides all the abstractions you need to solve the problem directly. With Lisp you literally have whatever language you want. Non-Lisps leak more and more as complexity increases. Two examples that jump to mind right away are lambdas in Python and generics in Java. In both cases the designers plugged holes in the abstractions they chose years before. Both are kludgey in my eyes, clear afterthoughts. Both features are trivial in Lisp. Lisp is so simple that the limitations never arose in the first place. Your language has made a compromise to simplify these things, but at the expense of flexibility. C++'s accretion disk is a marvel at this point. You can use macros to streamline elaborate data structure creation by the way.

junke 10y ago

As an example on non-list, literal data structure (atom), see: CL-USER> (ql:quickload :local-time) CL-USER> (in-package :local-time) LOCAL-TIME> (now) => @2016-08-05T17:41:54.492977+02:00 LOCAL-TIME> (enable-read-macros) LOCAL-TIME> (describe @2016-08-05T17:41:54.492977+02:00) @2016-08-05T17:41:54.492977+02:00 [standard-object] Slots with :INSTANCE allocation: DAY = 6001 SEC = 56514 NSEC = 492977000 LOCAL-TIME> (class-of @2016-08-05T17:41:54.492977+02:00) #<STANDARD-CLASS LOCAL-TIME:TIMESTAMP> And again, how your AST is encoded has nothing to do with the value you manipulate at execution: (make-hash-table) is a list with one symbol, but when evaluated, you obtain a good old hash-table.