<story><title>Lisp is Too Powerful</title><url>https://c2.com/cgi/wiki?LispIsTooPowerful</url><text></text></story><parent_chain></parent_chain><comment><author>raganwald</author><text>The notion of programming languages being “too powerful” rests on fallacious assumptions.&lt;p&gt;The faulty reasoning is this: If Hacker Hortense does something with powerful language L that Newbie Nathan finds confusing, we assume that language J won’t permit Hortense to do that, and therefore if we standardize on language J, fewer bad things will happen.&lt;p&gt;This reasoning is faulty. First off, if Hortense and Nathan don’t see eye to eye on how to write programs, no language will solve the problem, because you have a disparity of experience and/or education. If what you want is code Nathan will like, and you don’t want to raise Nathan to Hortense’s level, you have to drag Hortense down to Nathan’s level with coding standards. And you could have done that in Language L just as easily as J. If you ban L, what will you do when Hortense implements Parser Combinators and Monads in J?&lt;p&gt;The first flaw is the assumption that language &lt;i&gt;features&lt;/i&gt; introduce complexity, when in reality it isn’t the features, it’s the &lt;i&gt;solution to the problem&lt;/i&gt; that confuses.&lt;p&gt;This indirectly leads into the second fault with the reasoning. There is a hidden assumption that Hortense is going to write so much code, and there will be so many “problems” Nathan will have with his code, and every problem we eliminate is one fewer problem in the result. This is not how software works.&lt;p&gt;Let’s say Hortense writes some code in L, and Nathan complains that there are seventeen things he doesn’t understand. Ten of them rely on features of L, seven are independent of the language. If we tell Hortense to rewrite things in J, we cannot assume that the result will have seven things Nathan doesn’t understand. It might have even more as Hortsense works around J’s deficiencies.&lt;p&gt;For a demonstration of this, look at any modern Java Dependency Injection Framework. These complex and opaque software machines are made up of of XML, interfaces, and classes. They exist in no little part because Java lacks the reflection and meta-programming of languages like Lisp or even Ruby. Are these thing simple by virtue of being written in Java instead of Lisp?&lt;p&gt;Imagine for a moment that DI frameworks don’t exist, and that Hortense had built something in Lisp with macros for dependency injection. Nathan is nonplussed, so Hortense rewrites it in Java and rolls her own DI infrastructure. Will the result really have fewer things that Nathan doesn’t understand? Or will it be even more inscrutable thanks to the accidental complexity of working around Java&apos;s limits??&lt;p&gt;The “problem” is not that some languages are too powerful, it is that people imagine that teams of programmers can work together on complex problems without communicating, and some people assume that when there is a disparity of experience of knowledge, that people can work together without educating or learning from each other.</text></comment>
<story><title>Lisp is Too Powerful</title><url>https://c2.com/cgi/wiki?LispIsTooPowerful</url><text></text></story><parent_chain></parent_chain><comment><author>spacemanaki</author><text>There&apos;s some definite trolling down at the bottom half of that page: &quot;Huh? I&apos;ve seen no objective evidence that BrainFsck is more challenging for business applications and systems software programming than is Lisp. I invite you to provide clear evidence that it is more challenging.&quot;&lt;p&gt;Leaving that aside though, other people smarter and more experienced with Lisp than I have suggested that this &quot;problem&quot; is not unique to Lisp, and may not be a much of a real problem. I really think it&apos;s just a question of having good documentation and sensible style which explains what you need to know to use the magic even if it doesn&apos;t explain what&apos;s underneath. It&apos;s true that a lot of &quot;lone hackers&quot; aren&apos;t going to be writing good (or any!) documentation, but that&apos;s not a Lisp problem.&lt;p&gt;Ruby&apos;s metamagic is a common example. I already know Ruby and recently I&apos;ve been learning Rails. I know there&apos;s a lot of magic going on behind the scenes, and occasionally I&apos;ll read some example or something and know that underneath there&apos;s magic that I do not entirely understand. I can continue studying the framework as a user and probably even get away using it for a while without completely understanding the magic underneath. I doubt that every person who has used Rails commercially completely understood every part of the framework that they use, since that would be a huge drag on their ability to ship their thing.&lt;p&gt;Another interesting example: This past week I talked to someone at a nearly pure Scala company and he described this DSL that they wrote (or just use? I can&apos;t remember) to interface with SQL databases. It exploited the fact that infix operators are really just methods and that you can define implicit conversions on existing library types that allow you to sort of extend them (I don&apos;t actually know Scala, so this may be slightly off base). The snippet of code he showed me, while it looked like Scala, would be turned into an SQL clause. Programmers who use this don&apos;t necessarily need to understand all of the gritty details so much as they need to understand what the designer intends and understand the semantics of SQL and of the DSL.&lt;p&gt;In Common Lisp, &quot;lambda&quot; is a macro. I don&apos;t really know how it works, but I know that it expands into lower level code defining a function and a closure. It&apos;s the same way with standard macros (in some Lisps) like let, letrec, cond, if, and, or etc... Most Lisp programmers who are not experts can use them understanding that they are macros but maybe not knowing their complete implementation because they are very well defined (and because they are pretty simple).&lt;p&gt;More complicated macros like &quot;with-open-file&quot; can be used by programmers who probably have some idea of how the macro works, but not a complete understanding. As long as your own macros and Lispy magic are documented sufficiently and designed sensibly programmers should be able to use code in your &quot;world&quot; without understanding it completely. At least to start.&lt;p&gt;N.B. I haven&apos;t used Lisp in a commercial setting, so it&apos;s entirely possible all this is bunk and I&apos;m just being naive. Wouldn&apos;t be the first time.&lt;p&gt;&lt;i&gt;edit&lt;/i&gt; Upon re-reading this monster comment I realize it might come across that I&apos;m advocating some kind of &quot;cargo cult&quot; or copy-and-paste style of ignorant programming. I&apos;m really not. My point is that while understanding your tools is important, so is knowing when you don&apos;t need to peel back the curtain and instead need to address the problem at hand.</text></comment>