Michael C. Libby wrote:
> On Fri, Jan 14, 2005 at 08:49:54PM +0900, PA wrote:
> 
>>On Jan 14, 2005, at 12:42, Michael Neumann wrote:
>>
>>
>>>Often it's easier to write a new application from scratch then 
>>>understand an existing one. By writing Wee from scratch, I learned 
>>>*why* Avi (who wrote both IOWA and Seaside/Borges) did the things in 
>>>this way. I used Avi's ideas and implemented them in Ruby how I'd 
>>>implement them.
>>
>>Beside "writing your own" as a learning experience, another thing not 
>>to underestimate is the ludic aspect of all this. A lot of open source 
>>project are simply for fun, not for profit nor "efficiency".

Yes, exactly. It is fun, and you can learn a lot of things in doing so. 
I personally want to understand the underlying libraries before I like 
to use them. So this is what I did with Wee ;-)

>>Sometime, even though there already exists uncountable "solutions" out 
>>there, I just feel like writing my own as a hobbyist. Just because I 
>>can :o)
> 
> 
> Seems to me that web sites are often highly customized animals, as well.

But they can IMHO be grouped into two categories:

   * web *applications*
   * web "sites"

Web applications are much more like GUI application are, just that the 
browser
is the GUI, whereas web-sites are more like traditional sites, with some 
dynamic stuff in them. From my point of view, web applications need 
registration and are build with a limited number of users in mind (you 
develop these kind of applications for a compary for example). This is 
my definition of "application" vs. "site", it may be wrong for someone 
else than me ;-)

Wee is very well suited for applications, whereas Rails and Nitro are 
better suited for dynamic sites (with many users, but not so much 
interaction and UI-state).

> Might make less sense trying to fit the design into an existing framework
> than it does to just build something that does exactly what is needed for
> the case at hand.
> 
> Part of the problem we have with Ruby is that writing new code that is 
> fairly powerful is very, very easy. This is a good problem to have. :)
>
> Of course, this also means that it might be easier to simply code from
> scratch than figure out how to extend existing complex code. With Ruby
> this is less of a problem than some languages, but big projects are 
> still big projects... and that can be intimidating (at least to me).

Hm, I don't think it's easy to develop Nitro or Rails from scratch. And 
they are good for most purposes, so unless you want to take a different 
approach, you would not want to write them from scratch.
> 
> I also want to suggest that the names chosen for most of these projects
> aren't particularly helpful, nor are the descriptions. This means that 
> people like me, who tend to get glazed eyes fast when anything that 
> looks even remotely buzzword compliant or marketing-flashy comes along,
> may miss a perfectly useful package simply because it has a "wierd" name
> or the description is too vague. I'm sure this is just prejudice on
> my part, but I tend to avoid stuff that comes across like an ad in 
> Dr. Dobbs for the latest Java gizmo or the newest .NET snake oil.

Which name(s) do you have in mind? ;-)

That's why I like to see examples in their description. The best 
description for me is an example. You can quickly see it's beauty and 
simplicity from an example.

> Is it possible the names make people think of a package as someone's pet
> project rather than a community resource to be hacked and extended?

Wee is for sure a pet-project, at least it started as one. But IMO, it 
has potential for very dynamic applications. And if you take a look at 
the sources (the core), you'll see that it's pretty well documented and 
easy to understand.

Regards,

   Michael