Thank you for making this reduced graph. I'm all for visualization, but the full call graph seemed to show nothing except how useless a full call graph is.
Good point. "Around" is a concept used a lot in aspect-oriented programming. But I suspect that even fewer people are familiar with AOP or "around" than with macros or resource management.
andreyf, I completely agree with you. How people write code in a language is -- from a user experience perspective -- part of the language in a very real sense. I've written about this before. http://plpatterns.com/post/37655849/1-2-n
Using symbols like ¬ and λ is a start. Paredit is even better. But I think programmers are stuck in the mindset that source code has to come from an ASCII text file. If you truly get the idea that code is just data, there's no reason why your "IDE" shouldn't be integrated with the language and provide a higher-level representation of the data you're editing. Also, depending on the task, you may want to view different aspects of your code. You can think of your source as the model in an MVC where multiple views and editing styles for the same data-structure are possible.
Once you view your code simply as data, all sorts of possibilities open up. The so-called Source Code In Database site has tons of examples of these features. http://mindprod.com/project/scid.html
No, I think what people are getting at is... why does program source have to be represented by only ASCII text? After all, if code is data, an IDE is just a data editor, where that data happens to be code.
I think it has been shown many times throughout history that notation matters. In fact, the entire concept of Arc is based on this principle. Otherwise, Common Lisp would be suitable.
Why does it have to be ASCII? No reason, The simplest answer may just be that the language writer feels that adding UTF-8, or UTF-16, support would be a waste of their time, or is below them. As for programming IN the language, it becomes a matter of what is easy for the programmer to type. In a way, this whole thing is a matter of deciding what is the lowest common denominator that one wants to support.
Sure, Qi was implemented in CL, but that doesn't mean Lisp isn't blub compared to Qi. Think Greenspun's Tenth Rule, but instead of C and Lisp, Lisp and Qi respectively.
(Too bad I'm posting 11 days late... I would have liked to have heard a rebuttal.)
It doesn't look to me like it's obviously shorter.
I haven't tried counting nodes in both either, but in nonwhitespace chars, which should be a reasonable approximation of nodes in two languages so similar, the Arc version is slightly shorter: 755 chars vs 774.
