Talk:Greenspun's tenth rule/Archives/2014
 | This is an archive of past discussions about Greenspun's tenth rule. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Backwards interpretation
The "Meaning" section is completly off the mark; it for some reason starts off talking about Lisp syntax and macros... whereas any recovering C++/Fortran vetran can tell you that the beef is in the features common with today's popular dynamic languages including automatic memory management, high level data structures and strong typing.
- Indeed. And the real meaning - namely, that Common Lisp had important language features and a large standard - is already mentioned in the lead section. The 'meaning'section is just an opinion without any reputable source.
- I will move it here: Lisp syntax is barely abstract; Lisp programs are constructed as trees of S-expressions, which are equivalent to the abstract syntax trees that compilers of other languages create internally. As a homoiconic language, Lisp also makes no distinction between code and data; Lisp programs are themselves just Lisp data structures. Lisp programs can thus generate additional Lisp programs themselves via macros. As a result, the programmer can construct complex domain specific languages with relative ease. Lisp advocates such as Paul Graham claim that this allows faster construction of more robust software compared to other languages.[1] Common Lisp, specifically, has a quite large standard library with a large number of functions with flexible interfaces, that capture many programming paradigms (like
remove,reduce,map, etc.). Greenspun's Rule expresses the opinion that these capabilities are necessary for any sufficiently complex software package, and so will be redesigned from scratch in an ad hoc manner in any large project, duplicating effort already exerted in Common Lisp. -- Zz (talk) 12:09, 9 September 2014 (UTC)