The elephant in the room is that Lisp's community makes it very hard to adopt Lisp for production. Scheme is not as affected, but in general you end up with several implementations, each doing now-common things like networking slightly differently, and each having a feature set that contains 90% of what you want. What's worse, if you get into non-trivial things it can be difficult to migrate from one lisp implementation to another when your priorities change and different features are required.
Compare this to most other languages–notable outliers like C/C++ excepted–have canonical implementations that world-wide communities can germinate from. This additional confusion at the outset of adoption has stopped more than one of my colleagues from learning Lisp.
There's also typically deployment issues. Because most lisp execution environments are so heavily tweaked out, a lot of times it's not clear how to deploy a piece of software. A great example of this was a web-app I received from a talented lisp consultant. His method for running the program? "Run SLIME in a Screen session and type the following commands." You can rightly argue that this was just one bad example, but I think everyone who's being honest has seen this kind of crap going on, and a clearer and more obvious way to deploy would do most lisps a lot of good.
And a fine argument that is. The need for hygenic macros is overstated.
What I don't see is why you can't provide both? It's not confusing to provide both, it's not difficult to provide both. There are that class of macros you write where variable capture is tedious to deal with manually, so why not save some code and make a correct implementation of hygenic macros just so that people who need them don't have to re-implement them?
I just counted up again and my code base shows 613 defmacro occurences and only 111 gensym occurences and I do not even use a with-gensyms macro, so I am not sold on the need. Then again, I do strive for the functional thang and try not even to use let. btw, I am not fastidious generally but (I guess cuz it is so easy) I never skip on a gensym -- I am definitely of the school that believes programming is hard enough as it is. :)
There are already two notable free interfaces for hosting public repos, repo.or.cz (which is acceptable but kinda slow), and github.com (which has a lot of neat new features involving project collaboration).
Although GitHub is really awesome, it's only free now because it's in beta... once they finish the site, it'll have a fee. On the other hand, they have talked about waiving that for open source stuff. Also, the beta is invite-only.
I was thinking of this while watching the video - when Linus talks about smartness is a good indicator of someone to pull from - that the minimum level of smartness to participate becomes being able to setup a public repo.
This is somewhat exclusionary but I'm sure there are worse litmus tests on who's code to trust.
I'm not sure what your professional experience making websites is, but mine has shown me time and time again that making good looking sites is an iterative process full of workarounds for real-world considerations.
The method you're suggesting would make it excruciating to converge on a good design with any real designer. Look at the markup any good looking and well-implemented web page (especially one with dynamic content), and you'll see a huge amount of extra tag work to accommodate the real world of cross-and-backwards-compatibility between browsers, CSS limitations, browser quirks, and other concerns that people making professional sites require.
If every one of these changes and workarounds required changes to the code, which would require my time instead of the designer's time?
The Rails way is just copying a method that nearly every web toolkit uses, and they use it for a reason. Arc's way may be cleaner, but without a templating language it will be at a disadvantage.
- If you get the layout, including both how it should look and how things should work, from an external source, or if there is substantial external input, use templates. It will save time and headache.
- If you are just about the only one responsible for the layout but support skins (for lack of a better word; the CSS part), use the HTML tag functions and macros embedded in Arc.
Since Arc is at this point targeted for exploratory programming, the former is an unlikely case.
What I would like to see, though, is a templating engine akin to HTML::Template [1] in Perl 5. It has the minimum of control structures and extra syntax on top of standard HTML, just enough to make it possible to use the template for dynamic content. All templating frameworks suffer from the same fault, though: they define a new but severely restricted embedded language that's mixed in an unpleasant way with the HTML source. The language embedded in Arc is a much cleaner way to do things.
Complex designed websites are pretty much impossible using Arc's current library. Well, unless you're a programmer/designer with a high pain threshold.
When Arc is no longer classified by whatever greek letter comes before alpha, it might be worth investing into a nice way to separate out some MVC/MTV/VH1/&c.
Continuations are more general than lightweight processes. They can also be used to implement exceptions, coroutines, and Ruby-style generators, and many other interesting control abstractions besides.
I'm just curious why we'd explicitly be re-implementing lwp over and over for each unique use rather than having a more formal implementation.
It's great that the arc application server does this for us, but maybe it could be part of the language? It certainly gives a lot of flexibility and it's a no brainer for making programs shorter, since any sort of server would be rewriting it (and probably with many uniquely wrong choices).
