Dont Brag Beyond Your Science

I am getting a little tired of people claiming that language X or paradigm Y is so damned great. Not just "good", but "great". If you can produce reasonably objective, external evidence that something is better, such as less code or fixing OnceAndOnlyOnce, then you have room to brag and evangelize. But, that bragging right is only as powerful as the evidence you offer. If something can be shown a few percent better, then you are allowed to brag a little bit, but not a lot.

If it helps you "think better", but you cannot describe in detail how it helps you think better, then shut up. That is not good enough because your thoughts cannot be analyzed by any objective means (except perhaps some kind of productivity metric). I know this bothers some, but internal evidence only frustrates because it cannot be dissected by geeks, and geeks go crazy when you don't let them dissect things that you keep selling.

Here are some guidelines for such evidence:

• People can study it without having to pay a fee or buy a book.

• Fellow proponents of your pet technology must also agree (50% or more) that the evidence you present is good. This is to reduce "shotgun" attempts. You first have to pass by peers of your pet technology before releasing it to skeptics and agnostics. If it cannot pass by believers, then in all probability it stinks.

The reverse is also true: Don't bash something with a heavy hand unless you can clearly show why it stinks.

I am getting a little tired of people saying they are getting a little tired of people claiming that language X or paradigm Y is so damned great.

[And I'm getting tired of:

• People asking for scientific support for one side of a debate without offering it for their own side. When scientific evidence is lacking (largely true for debates about the effects of technologies and languages on programmer productivity), subjective evaluations are all that are available. Deal with it, or move on. Note that popularity statistics are not scientific evidence.
• If evidence is lacking, then respect each other's choice without telling them they are going to paradigm or language hell for not using your exalted pet technology.
• Lazy but argumentative people who argue vociferously against a technology or language without understanding it. The cases are numerous where study material is available for free, but the debater doesn't use them.]
• Are "lazy but argumentive" people more noisy than haughty zealots? If X is so great, then it should have objective evidence behind it. It has to improve SOMETHING measurable if it is truly a leap ahead of the pack.

---

Let's review past advances that most agree are superior:

• Assembler replaced by 3rd-Generation languages
  • Less code
  • More machine independence

• Blocks (mostly) replacing Goto's
  • More consistency between developers and shops
  • Indentation offers visual cues that Goto's didn't.
  • (Note: I have never interviewed a Goto fan, so I cannot accurately represent their viewpoint)

The benefits of most alleged advances since these have been far more difficult to describe. Proponents seem at loss of words. It seems we reached a point in history where science cannot work or something. Very odd. They may say things such as "better abstraction", but that is impossible to objectively measure beyond less code and OnceAndOnlyOnce. (MeasuringAbstraction).

Please, there have been many many more advances since then that anyone even slightly educated agrees upon. HigherOrderFunctions, LexicalScope, Closures, Continuations, AnonymousFunctions?, MultiMethods, Classes, Functions, Procedures, Modules, Namespaces, etc. If you think everything since structured programming (it's not called blocks) has no clear cut advantages nor wide acceptance, you need to study more, program more, and quit expecting others to try and prove things to you. The answers are there, easily found, easily understood with only simple reading, if you're looking for it, but no one's going to force it down your throat for you.

Most of those offer incrmental improvements, not revolutionary improvements.

Exactly the words of a Blub programmer, you are caught in the BlubParadox, unfortunately, there is no escape.

Plus, there are different ways to approach the same thing. By the way, In don't include "functions" as something new. Even many assembly languages have subroutine-oriented commands. Plus, some of those offer objective evidence in the form of less code. For example, suppose we get information from an external system which provides a "function code". We want to execute some code based on this function code. If we don't have dynamic function abilities, then we probably have to do an if/elseif or case statement:

  select on function_code
  case "foo": foo(x)
  case "bar": bar(x)
  case "grog": grog(x)
  .....
  end select

If we can execute a function based on the name of the operation (run-time function determination), we don't need a case statement. Thus, we have objectively less code. I can show somebody the code and say "see see see!". (They could counter that the need for such is not common enough to abandon compile-time checking, but at least we are comparing code instead of vague innuendos.)

As far as "not fully understanding what is being criticized", one does not have to know how a car engine works to see who wins a race, or know how rockets work to determine which one flies higher or more accurately.

[Flawed analogies, overly simplifying. What's the analog, in programming activities, to "winning the race"? "Flying higher or more accurately?" Productivity? Hard to measure, and hasn't been. Quality? Same deal. If you're criteria is popularity of a technology, you're not measuring something that's directly indicative of technical fitness.]

[In fact, if you look at specific technologies or solutions within engine or rocket design, you'll no doubt find a lot of debate and opinion. Because of the nature of these pursuits, I'd think it's easier to do specific, controlled tests, and there's more money available to do it, to help sort out the debates and opinions. But choosing among programming languages seems more analogous to choosing between methods of designing engines than what to incorporate into the design, and I'll bet those choices are just as unclear in mechanical engineering as they are in software development.]

But they are fighting over a few percentage points of difference, not revolutionary differences. Nobody in the field claims they can make a rocket go 100 times further on the same amount of fuel. Sure, there is the nuclear option, but it carries a big risk to earthlings. It could be built on the moon instead of Earth to reduce risk, but at a big cost. These tradeoffs are known and accepted. The fights over the significance of these known tradeoffs are not that large. They are what I call "incremental fights".

[Again, you're focusing on the wrong analogy. If you want programs to run as fast as possible, Lisp might not be your best choice. (Although it's not bad in that area, either.) Coding is like detailed design work; you do it once, manufacture the program once (by compiling it and trivially copying the results over and over), and then users run the program over and over again. Launching a rocket is like launching a program. Generating all the detailed mechanical drawings and process descriptions that feed into the manufacturing process is akin to coding. Debating the merits of programming languages and other programming technology is like choosing among CAD programs, catologing methods for drawings, tools to assist in calculating dimensions and shapes. Efficent use of the designer's time is only one criterion; ease of performing engineering changes is also important, and the ability to easily find, read, and understand the drawings, and being able to verify assemblies with simulations is a plus. This analogy still breaks down in some places, but it's much closer. (A big difference is the fact that "manufacturing" is cheap to the point almost of not existing in most software development.)

[I'm not sure why you think that Lisp advocates are fighting a "big fight" rather than an "incremental" one. I've never seen anyone claim that you could write a program a hundred times (or even ten times) faster in Lisp than in C. You might be lamenting a behavior that doesn't exist. But a lot of people say that they've found the writing and modification of programs to be more convenient, more pleasant, and perhaps a bit faster in Lisp than in many other languages. Since Lisp isn't as widely used as C++ or Java, you'll find that a lot of these people, despite their personal preferences, have had to do a lot of coding non-Lisp languages, because there aren't that many Lisp programming jobs to go around. So they have actual hands-on experience with multiple languages. Contrarily, most of the naysayers seem to have minimal Lisp programming experience. These impressions come from following comp.lang.lisp for a couple of years, and from debates here on C2. I find this to be pretty interesting, don't you?]

[Lisp comes up often on wiki because CommonLisp is a rich language with features that are directly relevant to many of the technical topics that come up here. Few other languages cover this much territory, all in one package. As more people become familiar with it, it's not surprising that it gets mentioned with disproportionate frequency.]

---

Re: "Contrarily, most of the naysayers seem to have minimal Lisp programming experience..... I find this to be pretty interesting, don't you?"

A classic "chicken-or-egg" issue. Those who don't find it as wonderful are probably less likely to pursue it.

[Bad analogy. You need an egg to get a chicken, and a chicken to get an egg. If someone cares to, they can find out more about a programming language by investing the time. In other words, it's a matter of choice, not impossibility. We already have the chicken; but she hasn't invested the time necessary to lay an egg. So she doesn't have much credibility when lecturing other chickens on the merits or faults of egg-laying. ]

[Those who do find it wonderful frequently have extensive experience in Java or C++ (owing to the necessity of, y'know, earning a living) and yet still prefer Lisp. The typical pattern is Lisp-lovers who know a lot about Lisp and Java/C++, and Lisp-haters who know a lot about Java/C++ only. Given a choice between someone who knows a lot about both options, and someone who knows a lot about one, who are you more likely to believe?]

Using that logic, most fan-backed languages will always score "better". Only the most popular languages will have people forced to use them for long periods of time even if they are not a favorite choice of a given person. I find your metric silly. By the way, I don't think highly of C++ or Java either.

• [That was a completely nonsensical rejoinder. First there was no "metric" suggested -- merely a criteria for judging the credibility of people who offer opinions on Lisp vs. more popular languages. What does this have to do with fandom? It addresses breadth of experience. Second, the assertion had little to do with language popularity -- the point was that many Lisp advocates have extensive experience with multiple languages, and the comparative numerical unpopularity of Lisp is just a possible reason for this. We could as well have been talking about Oz vs. Haskell -- would you give the opinions of someone who programmed only in Oz more weight than those of a person who had programmed quite a bit in both languages? Note that these are not strong arguments for a language, but strong arguments would require objective research, which is lacking. Where objective data is lacking, one sometimes has to settle for an argument via appeal to authority -- in this case, authority via hands-on experience.]

• It's popularity has to do with the fact that it is one of the better languages, and perhaps even the best. However, It is not that much better than it's competitors. I am claiming that it's value is overstated, not that it is not valuable.

• [I think I see. You mean "popular" as in "Lisp's advocates really talki it up a lot", not as in "there are lots of people that like Lisp"? (That's the only way I can make sense of introducing "popularity" into the argument here, anyway.) So you're dismissing the strength of their convictions. But the paragraph you were replying to made an argument for granting more weight to some people who express a favorable opinion of Lisp because of their broader experience, and you haven't addressed the logic of that argument at all.]

• Your suggestion that the favorability of Lisp is directly proportional to the total number of languages and experience is tough to verify. You are asking us to accept anecdotal evidence to verify anecdotal evidence.

• [I didn't say that Lisp's favorability was proportional to anything, although your conclusion is essentially correct. I'm saying that the credibility of people expressing opinions can be judged by their experience. That's a step removed from saying anything concretely about the language. And they're reporting their own experiences, so who knows if they're telling the truth? They might be aliens participating on Usenet via a 9600 baud connection from Alpha Centauri.]

• [The value of Lisp may in fact be overstated by some people. But how can you know one way or the other without learning about it yourself? The objective scientific research hasn't been done to prove anything about programming language quality for most interesting definitions of "quality". If you have specific questions about Lisp, lots of people will be able and willing to provide answers, but nobody can give you an objective "proof" for their opinions.]

(This also works against Lisp when compared to HaskellLanguage/ObjectiveCaml programmers. Many Lisp-lovers - notably PaulGraham - lack experience in Haskell/Ocaml and tend to dismiss it as "academic", while many Haskell weenies also have extensive experience with Scheme and other Lisp dialects. This leads me to believe that Lisp is Blub to Haskell (BlubParadox)). -- JonathanTang]

• Careful about gaining any "truths" about lisp from watching the non-factual opinions of vocal lispers. Really; in any well-functioning society, four people will have five divergent opinions. The advantage of a MultiParadigmProgrammingLanguage is that someone like PaulGraham can diss OOP, while other lispers totally love it. I like to think Lisp encourages interesting dissent. Here a lisper writes a LispMachine VM in OCaml: http://groups.yahoo.com/group/lispmachines/message/93
  • Many Lisp-Lovers have no extensive knowledge of OcamlLanguage/HaskellLanguage. Right. And many actually HAVE extensive knowledge about Ocaml/Haskell. Both is true. For example Yale Haskell was written in CommonLisp. Or see the many years of the conference Lisp and FunctionalProgramming, where both camps came together. For the Haskell/Ocaml-people you cite, I often think that they just know some (or more) SchemeLanugage? - which I would hardly see as 'extensive Lisp knowledge'. Plus I have the feeling that writing actual applications is a bit more popular on the Lisp side. ;-)

[Hmm. Found this interesting thread where Graham's comments get discussed by Lispers: <http://lambda-the-ultimate.org/node/view/186> The conversation wanders off into the pros and cons of Haskell.]