1. I deliberately used only features all web app libs would already have.
2. My hypothesis is that shorter (in the codetree sense) programs are easier for the author to read, and in exploratory programming the author is the most important audience.
Regarding number two, after I started using syntax coloring editors for my Common Lisp I noticed that the blue stuff (the language keywords) was surprisingly scant. ie, Most of the text consisted of my own variables and operator names. This (I guess) is especially true of functional languages and maybe also because I never miss achance to hide boilerplate with macros. So in conclusion my fellow Archers, I think real world code you write will be as long as you want it to be. No one forces you to pick short names or use the chaining:thing.
I know very few web frameworks which have Arc's style of implementing user actions, and for good reasons: either you've got a huge memory leak, or links have an expiry date. (I got a deadlink-error while clicking on reply...)
I have a hypothesis about bloating memory: it will stop mattering soon. Solid-state non-volatile storage at RAM speeds on a fast bus will allow for terabytes of memory -- and increase with the unimpeded Moore's Law of storage. I know of at least one company, FusionIO, offering this as a product already.
If you can store all but the largest databases in memory, why not use a web framework that doesn't bother with a "real" DB like MySQL? But clearly, I'm talking about memory hungry systems generally, and not memory leaks.
You can set an explicit expiration or have the links gced fifo. I used the latter in the example (and the reply form), but for something more critical (like YC funding applications) I'd add an explicit expiration. It's only one more token.
1. It's a toy problem, I get it. But how much information is conveyed?
I suppose you could call any library from any language with enough leg work, but it is easier and shorter in the same language. Python talks to C very easily, and there is an IMMENSE number of C libraries. OpenCV is an excellent, open-source computer vision toolkit that already have python bindings. My point is that the programmers using a language will benefit greatly from a community of people building tools that can easily be used in that language.
2. At times, making things explicit is easier to read. After I finish my current project, I'll learn Arc and see. It's just really nice sometimes to say
Even since this started to work, I still prefer some_dict.has_key("username") because then if an ordinary string accidently found its way into some_dict I'd get a runtime error instead of a silent logic bug.
is somehow difficult to read? (arguable, this is an arctable and not a dictionary which is closer to an associated-list. If it were an associated-list you'd be able to do it as either:
(if (assoc "username" arc-alist) ... )
or
(if (alref arc-alist "username") ... )
I'd hardly call any of these difficult to understand; though perhaps assoc would make more sense if the list were the first parameter and the key the second like the alref works. i.e.
(assoc list key)
rather than:
(assoc key list)
Because at the minute alref and assoc are not conforming to the same standards, which make them rather awkward to use.
True, but the returns are more useful (assuming has_key returns T if it has the key. I am unfamiliar with python I'm afraid).
If the current syntax is difficult to memorize, you could always write a simple function which abstracts it away into something you're more familiar with:
