Name: Anonymous 2014-06-18 22:32
I originally read this book in the hope that I would 'get' Lisp. Having tried it a few times in the past, I failed to see what was special about it. Indeed, it struck me as an awkward language with a terrible syntax. But maybe I needed a paradigm shift to really think in Lisp. This book did not provide that shift.
I didn't finish this book, and I may leave it unrated once I figure out how to clear ratings since I'm not sure I can fairly evaluate it. Frankly, I may be this book's anti-audience, and Mr. Hoyte may be my nemesis :). For instance...
I think Lisp is outdated. Yes, it was great in its day. Yes, it was better than many later languages. And yes, it contributed to many languages and showed how a simple language based on a small set of powerful concepts can outdo significantly more complex languages. But time has moved on. Better languages are available and there's no way around it, Lisp's syntax stinks. Indeed, many of Lisp's supporters seem to be unaware of (or intentionally ignore) language developments over the last decades. Hoyte does the same when he compares Lisp to C. C is outdated and stunk even when it was first released. One would have to try to make a worse language. Why not perform a detailed analysis of Lisp versus a more recent language?
I think macros are to be used sparingly -- if at all. Hoyte is a big fan of macros, but never makes a good case for them. His unit conversion example uses macros to avoid quoting the symbol. This is unconvincing for two reasons. The first is that the symbol would have been unnecessary with a different functional or object composition, and indeed would have resulted in more readable code. The second is that using macros just to avoid symbol quoting is no reason to use something as dangerous as a macro. Indeed, Hoyte even points out the risk in the double evaluation of a squaring macro, but then he goes on to resolve it with more complications rather than abandoning macros entirely.
I think Lisp is best used in a functional style. In this way, many of Lisp's more awkward features (like the set and loop forms) are avoided. This of course requires a tail recursive version of Lisp (like Scheme). Hoyte stresses that Lisp is not functional, which while true, ends up enforcing a programming style in which Lisp is even less suited.
I think Lisp is much inferior to many of the more recent languages like Haskell. For instance, Haskell outdoes Lisps Let-Over-Lambda style by giving it for free to the user (and with more flexibility) thanks to currying. Haskell outdoes Lisp in list processing by offering list comprehensions and pattern matching. In addition, Haskell's type safety is a good thing. Yet Hoyte thinks that Haskell is a language that one learns on the road to Lisp! He also doesn't like Haskell's type safety. Indeed, this seems to be a philosophical issue among us, as Hoyte has good things to say about Perl, a language which I think is only good for small, niche, throwaway projects. His love of Forth also stresses this difference, although in all fairness I think Forth is compelling because it at least offers the paradigm shift of point-free programming; but even then it has been superseded by better point-free languages like Factor.
In short, Hoyte is a Lisp fan with a classic 'hacker' mindset; he enjoys programming close to the metal and does not like language restrictions getting in his way. I think Lisp is outdated and believe strong language controls are important to control human fallibility. Many of my objections to this book are due to the differences in philosophy and therefore I wonder if it is fair that I rate this book.
I didn't finish this book, and I may leave it unrated once I figure out how to clear ratings since I'm not sure I can fairly evaluate it. Frankly, I may be this book's anti-audience, and Mr. Hoyte may be my nemesis :). For instance...
I think Lisp is outdated. Yes, it was great in its day. Yes, it was better than many later languages. And yes, it contributed to many languages and showed how a simple language based on a small set of powerful concepts can outdo significantly more complex languages. But time has moved on. Better languages are available and there's no way around it, Lisp's syntax stinks. Indeed, many of Lisp's supporters seem to be unaware of (or intentionally ignore) language developments over the last decades. Hoyte does the same when he compares Lisp to C. C is outdated and stunk even when it was first released. One would have to try to make a worse language. Why not perform a detailed analysis of Lisp versus a more recent language?
I think macros are to be used sparingly -- if at all. Hoyte is a big fan of macros, but never makes a good case for them. His unit conversion example uses macros to avoid quoting the symbol. This is unconvincing for two reasons. The first is that the symbol would have been unnecessary with a different functional or object composition, and indeed would have resulted in more readable code. The second is that using macros just to avoid symbol quoting is no reason to use something as dangerous as a macro. Indeed, Hoyte even points out the risk in the double evaluation of a squaring macro, but then he goes on to resolve it with more complications rather than abandoning macros entirely.
I think Lisp is best used in a functional style. In this way, many of Lisp's more awkward features (like the set and loop forms) are avoided. This of course requires a tail recursive version of Lisp (like Scheme). Hoyte stresses that Lisp is not functional, which while true, ends up enforcing a programming style in which Lisp is even less suited.
I think Lisp is much inferior to many of the more recent languages like Haskell. For instance, Haskell outdoes Lisps Let-Over-Lambda style by giving it for free to the user (and with more flexibility) thanks to currying. Haskell outdoes Lisp in list processing by offering list comprehensions and pattern matching. In addition, Haskell's type safety is a good thing. Yet Hoyte thinks that Haskell is a language that one learns on the road to Lisp! He also doesn't like Haskell's type safety. Indeed, this seems to be a philosophical issue among us, as Hoyte has good things to say about Perl, a language which I think is only good for small, niche, throwaway projects. His love of Forth also stresses this difference, although in all fairness I think Forth is compelling because it at least offers the paradigm shift of point-free programming; but even then it has been superseded by better point-free languages like Factor.
In short, Hoyte is a Lisp fan with a classic 'hacker' mindset; he enjoys programming close to the metal and does not like language restrictions getting in his way. I think Lisp is outdated and believe strong language controls are important to control human fallibility. Many of my objections to this book are due to the differences in philosophy and therefore I wonder if it is fair that I rate this book.