Re: Productivity and Perl

[educated_foo]

I read this article, and like anything written by any language's cheerleader, found it annoyingly unfair. Regarding two points that you summarize:

Most languages won't allow you to return a function. Further, if the language doesn't allow lexical scope, then a returning a function wouldn't do you any good.

This is completely unfair -- objects are ugly in Lisp, so you encapsulate your data with closures. Objects are easy in Java, so you bind data to functions with anonymous classes. Yes it's more verbose, but so's everything in Java. The point is that if you can't use closures, it's only going to frustrate you to insist on using them to solve all your problems.

I think the strong typing is mostly a red herring, too. Java's lack of generics (a la C++ templates) does pose a problem, but the static typing seems just fine. Either you want to add related things, in which case they should probably implement the same interface (e.g. "Accumulable"), or you're trying to add unrelated things, in which case you're doomed anyways.

Paul Graham points out that if another language requires 3 times as much code, coding a similar feature will take three times as long.

I wish I were smart enough for the rate of my coding to be limited only by how fast I could type, but sadly that doesn't seem to be the case. Code that is denser and more intricate just takes more time (per line, not per unit of functionality) to produce. Take these two examples:

(define (foo x)

  (call/cc (lambda (cc)

         (/ 7 (if (= x 0) (cc 'bad-value) x)))))

versus

int divideSevenBy(int x)

{

  if (x == 0) {

    throw new DivideByZerException("bad-value");

  }

  return 7 / x;

}

While the first is three lines and the second is six, if anything, the second took less time to write, not more. Having to type more characters does take more time, but even in this small example it's not the sole factor, and in a larger project, actual typing time is certainly the least of my worries (It can be easily dwarfed by "time spent figuring what went wrong in nested macro expansions.";)

Don't get me wrong -- the article has plenty of good things to say. But arguments like "my language is best because I can't make yours do things my language's way" deserve a quick trip to /dev/null.

/s