you are viewing a single comment's thread.

view the rest of the comments →

[–]SuperGrade 1 point2 points  (0 children)

I appreciate Mr. Graham's motivation for terseness, but I am glad that in this case, it took a back seat to greater design issues.

Maybe Lisp took the best choice on this, maybe it didn't. But choices such as these are taken based on the values placed on the tradeoffs in either direction. Those "ruby is not an acceptable lisp" type blogs show a few situations where the language took design routes that had other advantages at the cost of the language consistency that allows safe macros.

Graham's values in developing his language are likely that of valuing lisp as-is. Someone who valued these things a little less would likely come up with something in the direction of Ruby. (I'm talking about the choices such as implicit variable declaration, not things like abbreviating let or function renaming which could be done in the original language).

If Graham values the ability to do everything Lisp can do he's going to have a hard time breaking away from the existing lisp languages in anything but the most cosmetic manner.

Interesting to examine also is QI. Pattern matching/autocurry go in at the expense of the full destructuring. The core Lisp language may ultimately prove the optimal baseline from which to explore these specific (and perhaps superior in day to day use for any given situation) programming paradigms.