C++ vs. Lisp

Good catch!

Argh, that's insidious!!! Editors should change out the actual link... can they do that?

Ctrl + is your friend. Also you can set minimum font size on most browsers.

Readability bookmarklet might help http://lab.arc90.com/experiments/readability/

Interestingly, the font size isn't microscopic on Firefox 3.6.3 in Windows, on a small screen (17") at 1280x1024. I wonder what's different?

A lot of web-safe fonts get sloppy when large. Smaller fonts, at least in theory, look better at the cost of lower readability.

That's what I've been told, anyhow.

Most of the articles of any size on that site have been cut-and-pasted from elsewhere. Maybe it's a splog-in-training.

Would the minimal # of lines of readable code be a useful metric? It's not an easy to evaluate one as you have to actually read the program, but a smaller program should be more understandable than a larger one if they both have approximately the same information density.

Lines of code and readability are both surrogate measurements for codebase complexity. People focus on lines of code both because it's easy to measure and because readability doesn't go down linearly as codebases increases - there are discontinuity spikes.

Once it grows past a certain size, you need the right kind of IDE, etc. to cope with the conceptual sprawl. People start duplicating functionality because they aren't aware things already exist, minor details that handle historically recurring bugs get overlooked in the noise, it takes much longer for new people to understand the codebase, etc. A 100k codebase is not just ten times harder to maintain than a 10k codebase.

Why do Gzipped source size is better? I mean, if with the same number of LOC, Gzipped size is different, that means one program is more repetitive than the other, right? I suppose experiments were done to show that Gzipped size was "better" in some sense?

I don't think you can objectively measure readability. It is tightly coupled with concrete syntax, which is highly subjective.

Hold on there. Gzipped source is a terrible metric. It would undercount duplicate code, the worst kind of program bloat.

Not that I'm defending LOC. If one has to count something, counting tokens seems less susceptible to noise.

OBLIG

"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

- Philip Greenspun

"Including Common Lisp."

- Robert Morris

"We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

- Guy Steele, Java spec co-author

Well reasoned for the most part, but Lisp has occupied the high ground for development tools for a long time (REPL, SLIME, trace/untrace, step, describe/inspect, room, macroexpand). Other languages have been playing catch up in this regard as well. Whether Lisp still occupies the high ground today is unclear, but it is erroneous to say that Lisp programmers envy the development tools of other languages.

I have been trying to understand the problem with syntactic abstraction in other languages -- or creating your own languages to fit the problem. Is it a real issue? or is the problem with it just same problem people have with any unfamiliar codebase where the developers made unclear or poor abstractions?

To clarify what I mean, I have presented lisp ideas to fellow coworkers and met with resistance along two lines:

(1) They want to understand what is really going on, and the abstraction can obscure that. This sounds to me like a general abstraction problem more than an issue with syntactic abstraction... and really, it seems like a problem with understanding how someone chose to abstract things. They want to look underneath the hood for answers.

(2) They suggest that new developers will have a hard time understanding and adding to the system. But new developers for any project have to learn the local language anyway. It may look like C++, python, or whatever, but it the framework other developers developed always has its own learning curve.

Surely syntactic abstraction is just another abstraction tool that can be used to help make those frameworks easier to dive into. There is always poor code and poor documentation; this is not an excuse not to declare functions or other pretty approaches. Why is it any scarier to use this tool than to use someone's library?

Prolog also has syntactic abstractions, though it doesn't have a culture that uses them to the same extent because (overgeneralizing a bit) every expression is quoted by default, and it also has extremely powerful pattern-matching. That (or good support for lazy evaluation, in other languages) covers many of the same use cases as Lisp-style macros.

Also, K has a "whizbang sleek look" that makes Lisp look ridiculously verbose. (http://www.nsl.com/papers/kisntlisp.htm) Ditto J and APL, though K seems to take it furthest. Part of their density comes from being based on ideograms, not lexical tokens; the density is like comparing Chinese to English.

Unfortunately, K is closed source and limited to 32-bit platforms for non-commercial evaluation. It's also quite expensive, since its primary product is a mind-bogglingly fast database designed for real-time stock data analysis. I'm been fascinated with K for a while, though, albeit mostly at a distance. (J's evaluation isn't limited to noncommercial use, though.)

I'm really tired of hearing this:

syntactic abstractions dont scale up with the number of programmers

... as an objection to Lisp macros. It has become the invariable staple of these discussions and is accepted (by the people who accept it) without any question. Yet is there any evidence for it? I don't think I've ever even seen any evidence alleged for it.

The fact is, to justify this statement requires more than proving it's true. You'd have to prove that this failure of syntactic abstraction to "scale up with the number of programmers" is worse than the failure of abstraction in general to do so. Indeed, in my experience, it's programming that fails to scale up with the number of programmers.

Ocaml also allows syntactic abstractions nowadays. Of course it's more complicated to use than in Lisp, because the syntax of Ocaml is more complicated in the first place.

To some degree, I feel that syntactic abstraction is a premature optimization. Many (most?) benefits of macros can be replaced by a combination of lazy evaluation and functional programming. Most of the performance benefits can be obtained by a sufficiently smart compiler which does partial evaluation. I use macros in lisp a lot, and I often wish I had them in Python/Java/C++.

In Haskell, I can only think of one very narrow use for them which has never actually come up for me in practical use (automatically generating instances for combined monads).

Out of curiosity, can anyone provide a more common use of macros which can't easily be done in Haskell with HOF/Lazy evaluation?

I think there's one other important lisp feature that hasn't been widely adopted: compile-time metaprogramming. A lot of lisp macro use boils down "allow developer to generate lots of new code based on tiny fragments of code he writes." The Python community has adopted this to good effect, but the Java/C++ community really hasn't. The funny thing is, the need for good code generation doesn't go away simply because the language provides no facilities for it. That's why C++'s broken template system is so often abused to provide compile-time metaprogramming. And that's why Java added annotation factory support. The preferred use for annotation factories is to register a factory class that the compiler will call when compiling code that uses your annotation. Your factory can then access a special compile time API that allows it to create new Java source files based on the AST that the compiler feeds it. More sketchily, your factory can modify the AST in place. This is an insanely baroque way of getting compile time metaprogramming but it solves a real problem.

Actually his example can be written quite succinctly (but in general case closures would be much more expressive):

copy(words.rbegin(), words.rend(), ostream_iterator<string>(cout));