8 ms·

C++ vs. Lisp

58 points by fogus 17y ago

dman 17y 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.
- tsally 17y 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.
  - dman 17y 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.
  - Xurinos 17y 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.
    - francoisdevlin 17y ago
      Insert Clojure rant here :)
- wendroid 17y 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
- Xurinos 17y 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?
  - dman 17y 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.
    - Xurinos 17y ago
      Since in C++ the + operator is actually a class method in C++, it sounds like all abstraction suffers the same potential problem of "no way for you to know by a casual read of the code". That is a good point on the macroexpand functions; I would hope that if syntactic abstraction was added to C++, there would be a similar way to view the resulting code (sounds like a great future gdb / MSVC debugger feature).
- silentbicycle 17y 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 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.)
  - dman 17y ago
    Thanks for pointing K out, hadnt seen it so far.
    - silentbicycle 17y ago
      There's a lot of stuff about it at http://nsl.com http://nsl.com, and you can get an evaluation version of Q (the newest K dialect) and associated documentation from http://www.kx.com http://www.kx.com.
  - tom_b 17y 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 . . .
    - silentbicycle 17y ago
- gruseom 17y 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.
  - deleted 17y ago
    [deleted]
  - dman 17y 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-abstraction 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.
    - JBiserkov 17y ago
      "Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." - Edsger Dijkstra, CACM, 15:10
- eru 17y 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.
- yummyfajitas 17y 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 17y 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.
    - yummyfajitas 17y ago
      ...such as syntactic shortcuts for complicated side effects. I can think of a couple of examples where I've done such things in lisp (mostly elisp, sometimes Clojure), but I don't see a good reason why I couldn't do them in Haskell. In fact, a function f: a -> M d (with M = IO, Writer or State if you want side effects) almost serves the same purpose: it turns a value into a set of actions to perform. I'm really curious, could you give an example of such a task/macro? (Note: I'm not trying to engage in a language war, I'm honestly curious. If I'm treating Haskell as Blub, I'd like to know about it.)
- MichaelSalib 17y 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.
  - nostrademons 17y 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.
    - MichaelSalib 17y ago
      Sure, you can totally do compile-time metaprogramming without language support, but the barrier to entry is much higher. That means that, at the margin, you're less likely to try it, especially for small projects. And most projects start small. I totally agree that good development shops do lots of compile-time metaprogramming. The issue is whether they do enough when dealing with problems (that start out as) too small to justify writing a full blown parser/compiler, and if they don't, how much of the shortage is attributable to a lack of language support in C++/Java.
Qz 17y ago
Why do people feel compelled to make websites with microscopic font sizes? edit: apparently it's a splog so that answers that.
- dman 17y ago
  Ctrl + is your friend. Also you can set minimum font size on most browsers.
  - klochner 17y 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?
  - Qz 17y ago
    I know how to fix it. I'm trying to understand why it happens in the first place.
    - psranga 17y ago
      http://www.456bereastreet.com/archive/200608/light_text_on_dark_background_vs_readability/ http://www.456bereastreet.com/archive/200608/light_text_on_d... This or another post proposed the hypothesis low-contrast, small text etc may look better during the design stage. Remember, the designer is probably working with dummy "lorem ipsum" text. Low contrast will highlight the designers contributions (color scheme, placement of info) and [save him/her the pain of reading the dummy text :)].
    - what 17y ago
      Designers don't have to use the site, so they probably just try and make it look pretty. But usability should trump aesthetics. If you're designing a blog, you should design it to be readable. That means a decent font size, no distracting graphics and definitely nothing that moves/blinks/flashes. (I'm biased, I've always preferred reading sites that are "plain." Just text and images only if they actually add value. Some color is ok too)
jacquesm 17y 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 17y 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.
- silentbicycle 17y 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 17y 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.
  - jacquesm 17y 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.
barrkel 17y ago
The problem statement link seem dead. I believe this is it: http://www.flownet.com/ron/papers/lisp-java/instructions.html 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-with-cpp-java-etc/C++-vs-Lisp.html http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-w... Is it a splog? The date on the antigreen.org version is August 2002.
- Daemmerung 17y 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 17y ago
Blogspam. Copy of circa 2002 article, mirrored at: http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-with-cpp-java-etc/C++-vs-Lisp.html http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-w... (via "Daemerrung" here: http://funcall.blogspot.com/2010/05/c-vs-lisp.html http://funcall.blogspot.com/2010/05/c-vs-lisp.html)
- jacquesm 17y ago
  Good catch!
- dasil003 17y ago
  Argh, that's insidious!!! Editors should change out the actual link... can they do that?
d0m 17y 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 17y 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 17y ago
In case you're curious about 'EasySTL' http://web.archive.org/web/20070515062100/http://userpages.umbc.edu/~bcorfm1/software.html http://web.archive.org/web/20070515062100/http://userpages.u...

58 points by fogus 17y ago

dman 17y 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.

tsally 17y 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.
- dman 17y 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.
- Xurinos 17y 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.
  - francoisdevlin 17y ago
    Insert Clojure rant here :)
wendroid 17y 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
Xurinos 17y 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?
- dman 17y 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.
  - Xurinos 17y ago
    Since in C++ the + operator is actually a class method in C++, it sounds like all abstraction suffers the same potential problem of "no way for you to know by a casual read of the code". That is a good point on the macroexpand functions; I would hope that if syntactic abstraction was added to C++, there would be a similar way to view the resulting code (sounds like a great future gdb / MSVC debugger feature).
silentbicycle 17y 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 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.)
- dman 17y ago
  Thanks for pointing K out, hadnt seen it so far.
  - silentbicycle 17y ago
    There's a lot of stuff about it at http://nsl.com http://nsl.com, and you can get an evaluation version of Q (the newest K dialect) and associated documentation from http://www.kx.com http://www.kx.com.
- tom_b 17y 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 . . .
  - silentbicycle 17y ago
gruseom 17y 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.
- deleted 17y ago
  [deleted]
- dman 17y 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-abstraction 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.
  - JBiserkov 17y ago
    "Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts." - Edsger Dijkstra, CACM, 15:10
eru 17y 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.
yummyfajitas 17y 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 17y 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.
  - yummyfajitas 17y ago
    ...such as syntactic shortcuts for complicated side effects. I can think of a couple of examples where I've done such things in lisp (mostly elisp, sometimes Clojure), but I don't see a good reason why I couldn't do them in Haskell. In fact, a function f: a -> M d (with M = IO, Writer or State if you want side effects) almost serves the same purpose: it turns a value into a set of actions to perform. I'm really curious, could you give an example of such a task/macro? (Note: I'm not trying to engage in a language war, I'm honestly curious. If I'm treating Haskell as Blub, I'd like to know about it.)
MichaelSalib 17y 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.
- nostrademons 17y 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.
  - MichaelSalib 17y ago
    Sure, you can totally do compile-time metaprogramming without language support, but the barrier to entry is much higher. That means that, at the margin, you're less likely to try it, especially for small projects. And most projects start small. I totally agree that good development shops do lots of compile-time metaprogramming. The issue is whether they do enough when dealing with problems (that start out as) too small to justify writing a full blown parser/compiler, and if they don't, how much of the shortage is attributable to a lack of language support in C++/Java.

Qz 17y ago

Why do people feel compelled to make websites with microscopic font sizes? edit: apparently it's a splog so that answers that.

dman 17y ago
Ctrl + is your friend. Also you can set minimum font size on most browsers.
- klochner 17y 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?
- Qz 17y ago
  I know how to fix it. I'm trying to understand why it happens in the first place.
  - psranga 17y ago
    http://www.456bereastreet.com/archive/200608/light_text_on_dark_background_vs_readability/ http://www.456bereastreet.com/archive/200608/light_text_on_d... This or another post proposed the hypothesis low-contrast, small text etc may look better during the design stage. Remember, the designer is probably working with dummy "lorem ipsum" text. Low contrast will highlight the designers contributions (color scheme, placement of info) and [save him/her the pain of reading the dummy text :)].
  - what 17y ago
    Designers don't have to use the site, so they probably just try and make it look pretty. But usability should trump aesthetics. If you're designing a blog, you should design it to be readable. That means a decent font size, no distracting graphics and definitely nothing that moves/blinks/flashes. (I'm biased, I've always preferred reading sites that are "plain." Just text and images only if they actually add value. Some color is ok too)

jacquesm 17y 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 17y 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.
silentbicycle 17y 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 17y 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.
- jacquesm 17y 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.

barrkel 17y ago

The problem statement link seem dead. I believe this is it: http://www.flownet.com/ron/papers/lisp-java/instructions.html 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-with-cpp-java-etc/C++-vs-Lisp.html http://antigreen.org/vadim/ProgLanguageComparison/lisp-cmp-w... Is it a splog? The date on the antigreen.org version is August 2002.

Daemmerung 17y 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 17y ago

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

jacquesm 17y ago
Good catch!
dasil003 17y ago
Argh, that's insidious!!! Editors should change out the actual link... can they do that?

d0m 17y 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 17y 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 17y ago

In case you're curious about 'EasySTL' http://web.archive.org/web/20070515062100/http://userpages.umbc.edu/~bcorfm1/software.html http://web.archive.org/web/20070515062100/http://userpages.u...