[Grok-dev] Re: What is Grok anyways... time for a name change? :)

[Sebastian Ware]

I'll try to answer all comments in a condensed manner.

DISCLAIMER: I don't want to hurt any cavemen's feelings, but it is  
highly competitive out there in the framework jungle... so you have  
to evolve your tools... ;)

I would like to se GROK as the tool of pioneers who know that the  
hack I write today might evolve into a mission critical, enterprise  
wide, application tomorrow, and I want to use the right framework up  
front.

The Zope being good/bad for Grok is an easy one. If a developer has  
bias against Zope, they obviously won't use Grok... but if the buzz  
gets hot on a this new framework Grok, which puts a great twist on  
the all new and improved Zope 3, then it will surely make (a  
professional) developer want to evaluate this option.

Regarding my list of names... why do people associate Java with a  
programming language... might it be because of SUNs marketing  
dollars? ;) I think so... and how about .NET... Remember, these days  
even management will have a say in the matter.

My point with the list was that there will always be short-lists when  
people evaluate stuff, and you want to be on that short-list, and you  
want to stand out.

    GROK|ZOPE3 -- an enterprise framework made easy

Grok, the caveman as a subculture. I am not convinced that he has  
(already) become a subculture. Grok the caveman is a metaphor, and he  
just gives me the wrong associations. Nonetheless, as an ironic comic  
strip bashing on the evils in software development, yeah I think it  
could become a really cool thing. As the poster boy of Grok... he  
might actually be a problem. :(

Grok currently communicates that it is aimed at developers who feel  
like cavemen. Only in my book, cavemen do stupid things and  
compensate with persistence. For me, PHP would be the tool of choice  
for a caveman.

I would like to se GROK as the tool of pioneers who know that the  
hack I write today might evolve into a mission critical, enterprise  
wide application tomorrow, and I want to use the right framework up  
front.

Mvh Sebastian
08-410 280 41
0707- 577 858

10 maj 2007 kl. 02.46 skrev Martin Aspeli:

> Martijn Faassen wrote:
>>> What is Grok?
>> "Grok is a web application framework for Python developers. It is  
>> aimed at both beginners and very experienced web developers. Grok  
>> has an emphasis on agile development. Grok is easy *and* powerful."
>
> FWIW, when I read this, I cringe a bit, thinking "yeah, right, of  
> course they'd say that". Rarely do you have your cake and eat it  
> too. It may be true in Grok's case (I like what I see), but this is  
> a bit like corporat emission statements:
>
>  "Our mission is to deliver superior shareholder value by  
> synergising our customer's needs with our unique research and  
> development, marketing and financing capabilities, in order to  
> provide the best possible solutions to our clients' complex  
> problems, whilst achieving a low total cost of ownership."
>
> (Can you tell I do this for a living?)
>
>> Perhaps we could elide this to this, though:
>> "Grok is a web application framework for Python developers."
>
> I like that better. I think Grok's selling points are:
>
> For Zope developers:
>
>  - It smoothens the learning curve and makes it easier to get up  
> and running quickly
>
> For Python developers:
>
>  - It is based on the experience of Zope 3
>  - It makes the full power of Zope 3 available (which means  
> scalability, security, patterns, lots of components already  
> available, etc)
>
> I also think it's important that Grok's proposition is still Zope- 
> like. You develop contentish things and use the ZODB and all that.  
> I really don't think Grok should try to auto-generate CRUD forms  
> with standard AJAXy widgets for RDBMS operations. Yes, it should  
> support RDBMS models, but it should still aspire to be Zopeish in  
> its approach to modeling solutions.
>
>> The rest of the about page already says stuff about power  
>> (experience web devs) and easy to use. What do people think? It  
>> doesn't hurt to introduce the topic in a few more words, I think.
>
> When I evaluate frameworks, I want to see:
>
>  - The main selling points (why is it worth my time)
>
>  - Some example code (I'm a developer after all), in no more than a  
> page (I'm a busy developer)
>
>  - Some balanced comparisons with the main competitors (I don't  
> have time learn ten frameworks and make up my own mind, nor do I  
> want a to see a one-sided comparison)
>
>  - Some examples of where it's been used successfully (I don't have  
> time/skills to fix bugs in the framework if it's all too immature)
>
> It's also important that page design is clean and not too  
> distracting, and that there are some links to the community.  
> Showing this mailing list, possibly with a link it shown in Nabble  
> so I can gauge activity without signing up to something (see http:// 
> plone.org/support) and some signs of life (news, blog posts...) are  
> important indicators.
>
>>> A tool for cavemen who want to use Zope 3? Doesn't sound very  
>>> comforting.
>> "Grok appeals to the caveman or woman in all of us. Cavemen, like  
>> us programmers, want powerful and flexible tools. Cavemen are  
>> great at tools after all; they invented the whole concept of them.  
>> But cavemen, and we, also want our tools to be simple and effective."
>> "Cavemen want tools like clubs: a club is powerful, flexible (you  
>> can bash in anything, mash potatoes too) and also simple and  
>> effective. Zope 3 is already powerful and flexible. Grok aims to  
>> make it simpler and more effective, for beginners and experienced  
>> developers alike. Grok: now even cavemen can use Zope 3."
>
> I like that. It's personable. It has a "voice". It tells a  
> compelling story. It's memorable. It's not marketing-y.
>
>
>> "Grok does away with ZCML. Instead it analyzes your Python code  
>> for the use of certain special base classes and directives, and  
>> then "groks" it. This grokking process results in the same  
>> configuration as it would have if you used the equivalent ZCML. We  
>> believe that having all configuration along with your Python code  
>> makes the code easier to follow and more fun to develop."
>
> I'm not sure about the context of this paragraph, though note that  
> this makes no sense unless you're already a Zope 3 developer, and  
> reads a bit like a slating of Zope 3.
>
>> What you're asking for is directions of the Grok project.  
>> Fundamental aims, and how they relate to Zope 3. The aim is to  
>> continue doing the following:
>> "During the development of Grok we have taken a careful look at  
>> common patterns in Zope 3 code and configuration. Grok aims to  
>> make these patterns more easy to use and succinct."
>
> Good.
>
>> We should write a bit of text with this information in it more  
>> directed towards people who are interested in the overall mission  
>> of Grok and its relationship to Zope 3.
>
> Yes, you/we should.
>
>>> Does stuff for Zope 3 work with Grok?
>> I thought I had written a bit of text about how grok is compatible  
>> with Zope 3 (we aim to be compatible both ways). Ah, it's in the  
>> tutorial:
>> "Grok is based on Zope 3 and is compatible with Zope 3, but you do  
>> not need to know Zope 3 (or Zope 2) at all to follow this  
>> tutorial. Grok builds on existing Zope 3 technology but exposes it  
>> in a different way to the developer. We believe Grok makes  
>> developing with Zope 3 technology easier and more fun for  
>> beginners and experienced developers alike."
>> We should make a statement about Zope 3 compatibility on the about  
>> page and I think on the homepage as well.
>
> Completely. It's the big selling point that sets it apart from a  
> "me-too" Python web framework. Grok and Zope 3 are integral and  
> symbiotic and kind of the same thing as far as a new developer is  
> concerned. Having to learn two names and two concepts and a  
> boundary sucks, but it's not really avoidable here for cultural and  
> practical reasons. So we need to teach, concisely, what is Zope 3  
> and what is Grok and how do they relate. A diagram may help here.  
> It could show that Zope 3 is "big and solid" and Grok is "light and  
> membrane-like".
>
>>>  From an identity point of view, the clear separation of the Grok  
>>> (name) from Zope 3 results in neither effort helping the other.
>>  > What would you rather evaluate:
>> [snip names]
>> You're talking about the name of the project. I presume you're not  
>> realistically expecting you can come into the project and get us  
>> all to change the name. I personally am -1 on a name change, as I  
>> think the current naming and identity strategy is working out fine.
>
> I completely agree, and turning around now would be damaging.
>
>> You discuss identity and then focus on just the name. Identity is  
>> far more than just the name. I think we should be talking about  
>> identity. Grok's identity is tied up to Zope's. We discuss our  
>> ties to Zope 3 very explicitly in our communications. On  
>> programming.reddit.com I saw it headlined like this:
>> "Grok: a new Python Web Framework, but on top of Zope!"
>> so we seem to have at least gotten the related identities across  
>> to *someone*.
>> If the *name* of software really matters much in people's  
>> evaluation choice, then why do you associate the name for coffee  
>> (or an Indonesian island) with vast enterprise software  
>> frameworks? What's up with those cups of coffee? That language is  
>> never going to make it in the big league!
>
> You underestimate Sun's marketing machine, but yeah, you're right.  
> Actually, "Java" works because it's easy to remember, distinctive  
> within its domain (i.e. it sounds totally different from C++, which  
> is arguably what it was competing against at the time), has an  
> obvious logo that's also memorable and so on.
>
>> Why the name of a gem for an object oriented programming language  
>> (playing off "perl", another one). A gem on rails? Don't know what  
>> that is, but it's going stick in my mind because it alliterates.
>
> Precisely the reason, yes. :)
>
>> A programming language named after Monty Python's flying circus?
>
> Actually, in the types of circles I work, Python is seen as a poor  
> cousin to Ruby, because people have heard of Rails (a lot, if you  
> read thins like InfoQ or TheServerSide, it's like the cool new  
> thing), and say "Python needs something like that". Hence the whole  
> Guido-chooses-a-framework thing (yay, that made a whooping great  
> amount of difference). Actually, Python is (from what I can tell) a  
> lot broader in scope and possibly more widely used than Ruby, it's  
> just that to most people (at last among certain groups) "Ruby" is a  
> shorthand for "Ruby-on-Rails" and Rails has had ridiculous hype.
>
> But I digress...
>
>> A web framework named after a guitar player?
>
> :p
>
>> "Tomcat"? What's a cat have to do with web servers? Or indian  
>> tribes? Or cherries?
>
> :p
>
>> Gears with turbo in them?
>
> But they're really fast!
>
>> These names only sound less bizarre because you're familiar with  
>> them.
>
> :)
>
>
>> I prefer "Zope Grok" to "Grok on Zope 3", as it's less of a  
>> mouthful and less similar to "Ruby on Rails".
>
> And sounds less awful.
>
>> TurboGears is an interesting case considering names and identity  
>> by the way, and it could be seen as a counter argument to your  
>> focusing on the name aspect. TurboGears explicitly markets itself  
>> as a "megaframework" of other frameworks, and speaks proudly about  
>> how it's building on CherryPy, Kid (becoming Genshi) and SQLObject  
>> (becoming SQLAlchemy). I think that marketing strategy worked  
>> quite well. Did you know that, for example? :)
>
> I keep forgetting...
>
>> Grok is a megaframework built on top of Zope 3 components. This  
>> makes for an integrated developer experience like Django but at  
>> the same time lets you benefit from a pool of evolving and  
>> swappable components like TurboGears. :)
>
> Again, Zope 3 is the selling point, imho.
>
>
>> Yes, good point. :) I think it it can serve as an introduction,  
>> because it's true and contrasts with Zope 3 for those who know  
>> about it. Luckily the text is aware of the YAPF nature of the  
>> first paragraph and we follow it up immediately with:
>> "You will likely have heard about many different web frameworks  
>> for Python as well as other languages. Why you should you consider  
>> Grok?"
>
> I think the I-know-Zope-3 audience is kind of secondary to the I- 
> want-to-build-a-webapp-and-I-know-Python audience, at least long  
> term. The Zope 3 people already know about Grok, and, frankly,  
> there aren't *that* many of them. Grok ought to be aiming to change  
> that. :)
>
> Martin
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev