Start FriedrichDominicus rants
Ok, you can get without my "valued" opinion. And do not feel attacked just because I disagree, but also let me held to my ideas.AFAIKT are a quite a few Lisp programmers in the due what you can to follow the actual trend. But I have also the impression that most Lispers have a dislike about XML. I'm in the same camp, XML is now part of the problem, we've to live with it.
My ucw Tutorial is about ucw usage. Now I'm just a user and not a developer so I have to decide whether I can live with decisions made from them or whether I can't.
I can and do have an opinion about a few parts. I'll try to get the code rendered, but as I learned it seems to mess up this cliki-engine quite bit.
Now let's see what the ucw developers have done
- the embraced the great new Web2.0 world (with inclusion of parenscript)
- the have not real favour of backward-compatability.
I'll add to this list over, time. Now what does this things mean to me as "user"
- I've to accept that the generated html does contain more than just a few
'traces' of JavaScript (if I don't to anything about it). You can see how they made use of this in there forms.lisp example. If you display it in an JavaScript enabled browser you'll see that during input the rendered fields change, e.g from red-bordered to non bordered.
That looks quite nice, but if you disable JavaScript as I do you still have to bear the costs of downloading more stuff then needed. If you are a bit interested in security you probably know why you do deactivate the code.
The whole Ajax stuff will generate zillions of new security problems. But hey it's shiny and looks "professional". So be it.
Now the other thing which happens. You have to accept more and more bloated web-pages, it will come the time where you won't get away with 10 MBIT bandwidth just to see a "hello World" web page.
The other point is that you ask for more trouble while having more sources. And by all means simplicity gets lost on the way also
- The backward-compatiblity is problematic. Base line is: If you are a ucw user you 'must' be prepared to change your code over and over again if you follow the development. And as I can tell it's quite a pace the ucw-developers run.
Undoubtedly ucw has improved over time. However it can drive you nuts how it behaves sometimes.
A story of confusion
Now here's a story I had with ucw not so far back in time. I had defined an application and I had defined an entry-point. I could check the server and did see the entry point, however if I tried to access this page I got an error like inexistent-entry-point signaled.Now that's stuff you do not dream of. I re-registered the entry point it showed up in the inspector, but no way accessing it.
Solution:
- Recompile the whole file
- create a new application
- re-register it
- add you entry point
Now you can tell it's just that I'm do dumb for it. May be, obviously UCW is not for average enabled programmers (what a challenge then ;-). But here's some food for though. Please check the outdated movie from UCW docs You see how Marco works, and guess what he did do a full-recompile even with small changes. Feel free to ask him why?
My point on it is that because it uses a really bunch for macros and a continuation approach (which just can be implemented in Common Lisp via Macros really), you do not know what parts have to be recompiled. So you recompile it all. This shows however another thing IMHO. It's not always wise to rely on all the features you get from Common Lisp all the time, it may be a wise decision to stay away from it, until you really have good reasons.
I'd argue a large parts on the difficulty to understand UCW comes from this Macro, Continuation, CLOS stuff. I hope I'll find to point out something I found much easier to understand.
However if you think you are really smart, try to get UCW, it's will be a challenge -- even for you. Maybe because I want to be smart also, I spend my time looking at UCW ....