A former co-worker asked me over IM,
What advantage, other than being able to use it on a Linux box, does [Spyce] have over the ASP.NET Model? Because I can tell you, with Visual Studio, I feel pretty productive.
I answered,
The main one is a significantly shallower learning curve. Once you know how the ASP.NET event model and page lifecyle work, you are set -- but you remember how "easy" that was for [our] students. With Spyce there is only one rule: handlers run before the rest of the page, in the order they were added. That's it.
And, of course, Spyce runs Python. This is significant: Python is addictive; once you start writing code in it, it's painful to use less-expressive languages. This is something most people won't get until they try it, unless maybe they are old-school Lisp hackers.
Now, Spyce isn't quite to the point where it matches ASP.NET feature for feature. But it's close, and getting closer. I checked in an authentication Active Tag earlier today that will be in Spyce 2.1. After that, the only thing I miss from ASP.NET is the (form) validation controls. That will probably also be in 2.1, and then what is Spyce missing? ADO.NET? No, thanks; any feature that has entire books devoted to it has a very suspect cost:benefit ratio. I'd rather use an ORM tool like PyDO. Master pages from ASP.NET 2? Already done. Weird-ass bugs caused by IIS misconfiguration? I think we can leave those out.
Comments
You can do most things you'd use HttpHandler or Module for with a spyceModule. I blogged one example earlier: http://spyced.blogspot.com/2005/04/extending-spyce-with-spycemodule.html. As you'd expect, it's not 100% 1-to-1, but you'd use them for pretty much the same kinds of things.
IDEs have been the last excuse for many people to not use dynamic languages, and it's a very good excuse. But even without a top-notch Python IDE like Wing (wingware.com), I feel more productive in Python + Emacs than in C# + Visual Studio, or Java + Eclipse.
Caching to me falls into two categories: important, and unimportant. In the former category is caching data; all sites I have ever worked on have been database-bound, not python or tcl or C#-bound. In Spyce, this is the job of your data provider, e.g. PyDO or SQLObject.
In the latter category is stuff like "cache the output of this tag/control." In a very few situations this can be useful, and if someone wanted to step up and add this to Spyce I wouldn't object, but as I said above, 99% of sites have a data bottleneck, not a page-processing bottleneck.
Finally, the main purpose of ViewState in ASP.NET is to remember the "initial" state of your page so ASP can decide which handlers to fire on postback. Spyce deliberately chose not to go the event driven route, so it doesn't need that.
cache library. SkunkWeb has one built in,which is very convenient; you can cache data and output with fine control over cache duration. This is one thing I miss in many other frameworks, and it isn't particularly hard to do. (The skunk4 project, which is a deep dark secret, does factor the cache out from the framework as a whole).
no big deal but that [[]] tags look a bit scary and more messy than their ASP < percentage equivalent (blogger doesnt allow this stuff to be posted, sorry).
Could we override it? It should be a couple of chars change in your code isn't it?
IronPython 1.0, to the dismay of some hardcore MS haters, will be a inflextion point for three reasons:
1. It will not require the emacs/vim crew to use VS, and will allow the VS crew to use emacs/vim
2. It will have the standard (batties included) libraries to run most native CPython apps, so .NET developer can use the best of CPython
3. CPython developers can use the best of .NET
This day is coming... This is your future...
most people find that [[ ]] grows on them, though... it's significantly faster to type.
I don't see how they would get VS support in this late in the product cycle for 2.0, though. And 3.0 is a very long ways off.
Regarding the caching comment look what I've found:
pgpool is a connection server for PostgreSQL. pgpool runs between
PostgreSQL's clients(front ends) and servers(back ends). A
PostgreSQL client can connect to pgpool as if it were a standard
PostgreSQL server.
pgpool caches the connection to PostgreSQL server to reduce the
overhead to establish the connection to it.
Anybody using MySQL is just crazy! ;)
[[
to
< %
must be kidding . . . I mean, [[ is WAY quicker to type, I would rather have that any day.