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

[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?
> 
> These names only sound less bizarre because you're familiar with them.
> 
>> When in fact Grok and Zope 3 are based on the same mature code base and 
>> could be evaluated as two development styles -- whatever suits your 
>> shop. And the connection could be reflected right in the name such as 
>> "Grok-on-Zope3". Now THAT would make it a lot less like Yet Another 
>> Python Framework... and a lot more like... hmmm... intereseting... 
>> what's the twist?
> 
> I prefer "Zope Grok" to "Grok on Zope 3", as it's less of a mouthful and 
> less similar to "Ruby on Rails".
> 
> 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? :)
> 
> 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. :)
> 
>> Rounding off with a small Yet Another Python Framework warning...
>> "YAPF is a web application framework for Python developers. It is aimed 
>> at both beginners and very experienced web developers. YAPF has an 
>> emphasis on agile development. YAPF is easy and powerful."
>>
>> ...only the original swaps GROK for YAPF... ;)
> 
> 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?"
> 
> Regards,
> 
> Martijn