C++ vs. Lisp

http://www.ebhakt.info/blog/?p=2291

by fogus • 16 years ago

58 66 16 years ago

dman7• 16 years ago

Interesting article. Over time most of lisps features (generic functions, garbage collection) have been ported over to other languages save two - syntactic abstraction and metaobject protocols. On syntactic abstraction there seems to be genuine difference in opinion between lisp (scheme) and other languages. Lisp is on the side of allowing programmers to invent their own syntactic abstractions hence making their programs shorter and at times more understandable. Other languages have largely been unwilling to make that leap of faith because syntactic abstractions dont scale up with the number of programmers. They also make it harder to reason about the correctness of programs and make tools like profilers, debuggers, code steppers. So this continues to remain a genuine point of difference which means the lisp programs will continue to have the whizbang sleek look which other languages will find hard to emulate. On the other hands lisp programmers will continue to look in envy at the development tools of other "less featureful" languages.

wendroid• 16 years ago

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

tsally• 16 years ago

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.

dman7• 16 years ago

Good point about slime (its my development environment of choice). Lisp tools are built for dynamic development from the ground up, so on that aspect they are very good. However finding a lisp source stepper that works has been an exercise in frustration for me. The best one ive found so far has been the PLT scheme stepper that mostly works.

Xurinos3• 16 years ago

With regard to development tools, maybe he was referring to libraries and community support.

Perl, a slow language criticized for its syntax and bearing the stigma of being a mere scripting language, is often lauded as having huge community support and tons of helpful (even if often crappy) libraries via CPAN. C++ has similar support (no CPAN that I am aware of, but I have always quickly found solutions and libraries with the search engine).

Granted, CL can connect via U/CFFI to any external library, but it is harder to find the wrappers for CL than C/C++ header files.

Xurinos3• 16 years ago

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?

dman7• 16 years ago

There is a small difference - syntax affects the read time comprehensibility of code in ways other abstractions dont. For eg in C++ an overridden "+" operator could be doing anything in the background and there would be no way for you to know by a casual read of the code. Lisp has macroexpand-l for this, but one needs to be dilligent enough to use it on new pieces of code.

silentbicycle5• 16 years ago

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.)

dman7• 16 years ago

Thanks for pointing K out, hadnt seen it so far.

tom_b• 16 years ago

K, J, Lisp, Prolog . . . I'm beginning to be worried about my own fascination with uncommon languages.

Is there a support group available? If the three books you read when the kids are asleep are The Reasoned Schemer, The Art of Prolog, and On Lisp, are you now officially beyond help on the language geek scale? I used to be a somewhat productive programmer. These days I think more about making sure I've picked the right language for the problem . . .

gruseom6• 16 years ago

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.

dman7• 16 years ago

I dont know what you count as evidence but here are two eminent authorities speaking about related topics - Turing award winner Barbara Liskov - http://www.infoq.com/presentations/liskov-power-of-abstracti... (Syntactic abstraction related talk starts at minute 17).

Heres what Dijkstra has to say about something that is tangentially related (he is talking about the importance of read time comprehensibility of code). "My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible." This is from the influential GOTO considered harmful paper.

MichaelSalib4• 16 years ago

Let's assume for a moment that the critique is correct: macros don't scale. OK. The C++ templating system can be used to accomplish many of the same things as a good macro system (see http://matt.might.net/articles/lambda-style-anonymous-functi... for one example). Does the C++ templating system "scale"?

Or, to put it another way: lots of C++ shops ban the use of advanced templating metaprogramming. Has C++ suffered egregiously as a result?

eru2• 16 years ago

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.

yummyfajitas2• 16 years ago

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?

lukev• 16 years ago

The only things I can think of are things that wouldn't enter the head of a Haskell programmer to begin with, such as syntactic shortcuts for complicated side effects.

So you're right, lazy evaluation can do just about anything in a purely functional environment. But now count the number of programming languages that provide a purely functional environment...

The rest of us need macros.

MichaelSalib4• 16 years ago

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.

nostrademons2• 16 years ago

I dunno what life inside other big companies is like, but Google uses compile-time metaprogramming all the time. There're tons (perhaps too many) "little languages" used inside Google. Some have even been open-sourced, eg. protobufs, google-ctemplates, Closure Compiler. And if their open-source output is any guide, FaceBook uses tons of little languages as well.

It's just that they're done the UNIX way, with a small miniature compiler or XML substrate, instead of the Lisp way, where you write everything in S-exprs. This tends to make the little languages easier to grok for users but harder to implement, which tends to be a good tradeoff, as there will be far more users than implementers of a programming language.

Qz4• 16 years ago

Why do people feel compelled to make websites with microscopic font sizes?

edit: apparently it's a splog so that answers that.

dman7• 16 years ago

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

klochner• 16 years ago

I often find fonts a little too light as well (this post included).

Anyone have a better/quicker method than firebug for darkening fonts?

Qz4• 16 years ago

I know how to fix it. I'm trying to understand why it happens in the first place.

d0mine• 16 years ago

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

alain94040• 16 years ago

Added to http://mylanguageisbetterthanyours.com/mylanguage/why-Haskel...

Qz4• 16 years ago

I have it and use it, I just don't understand why people choose those tiny fonts to begin with.

randallsquared• 16 years ago

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?

Qz4• 16 years ago

I'm on 3.6.3, windows, 22", 1680x1050. I have to ctrl+ three times to make it readable.

i80and• 16 years ago

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.

jacquesm6• 16 years ago

Why the extreme focus on lines of code?

That's not the best metric to begin with (I used to think so too, but someone here pointed out that gzipped source is already much better), and besides that, there are other ways of looking at it besides 'size', such as readability.

SapphireSun• 16 years ago

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.

silentbicycle5• 16 years ago

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.

loup-vaillant• 16 years ago

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.

jacquesm6• 16 years ago

Because gzip (or any other text compression protocol) tends to reduce the size of the file without reducing the information content. So for instance, if you used longer variable names but the same overall structure or if you split single lines up in to multiple lines (or vv) the gzipped bytecounts would be relatively close in spite of huge differences in source size.

gruseom6• 16 years ago

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.

jacquesm6• 16 years ago

That's the whole point. Even if you program in a 'sloppy' way the gzip algorithm will see that and reduce accordingly so you are comparing the languages, not the programmers stylistic elements.

Besides, the article talks about implementing the same algorithm twice in different languages, if you went about that in a completely different way then that would of course be problematic. But when comparing the expressiveness between two languages you'd assume the same major structures would be present.

barrkel• 16 years ago

The problem statement link seem dead. I believe this is it:

http://www.flownet.com/ron/papers/lisp-java/instructions.htm...

Also, the article seems to be a duplicate of this one:

http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-w...

Is it a splog? The date on the antigreen.org version is August 2002.

Daemmerung• 16 years ago

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

zachbeane• 16 years ago

Blogspam. Copy of circa 2002 article, mirrored at: http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-w... (via "Daemerrung" here: http://funcall.blogspot.com/2010/05/c-vs-lisp.html)

jacquesm6• 16 years ago

Good catch!

dasil003• 16 years ago

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

d0m• 16 years ago

I have to agree that even thought STL is extremely powerful, it makes program extremely verbose.

But, in my opinion, the real reason C++ code seems so verbose is because of the lack of closures. In C++, when you need one, you have 2 choices: either manually coding everything that would be in the closure or create a totally new function.

In fact, in the new c++2k10, it could be interesting to have a STL-like but with closures instead.. so one can do: some_sequence.sort_by(_1 > _2);

or: foreach(sequence, cout << _1 << endl); that's, again in my opinion, way better than: for (int i = 0; i < sequence.size(); i++) { cout << sequence[i] << endl; } and again still better than: for (list<int>::size_type i = 0; i < sequence.size(); i++) { etc..}

wuch• 16 years ago

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));

tmsh• 16 years ago

In case you're curious about 'EasySTL'

http://web.archive.org/web/20070515062100/http://userpages.u...

C++ vs. Lisp

Related Stories