[Grok-dev] Re: on the name "Grok"

Brandon Craig Rhodes brandon at rhodesmill.org
Mon Apr 28 12:14:20 EDT 2008


Martijn Faassen wrote:

>> Since Lennart and Godefroid had such success with Grok in Zope 2,
>> and naming issues came up once again, I thought I'd sketch my idea
>> on a policy for the name 'Grok', and the package name 'grok'.

And Philipp von Weitershausen <philipp at weitershausen.de> replied:

> -1

Okay, Philipp actually said a bit more than that, but I think the
above-quoted line pretty much sums up his position. :-)

Observe that "Grok" means two different things, because the people who
named it were clever, and, as is typical for a software project
created by smart people, they were deliberately deploying a double
entendre.

  1. To "grok" something, from Heinlein, means to look at it and to
     deeply understand it; thus, it means to use Python introspection
     to look across a bunch of classes and perform Zope registration
     on them without requiring the user to type bad, horrible ZCML.
     Packages that support "grokking" typically provide new base
     classes for you to inherit from, and they auto-configure any
     sub-classes of these that you create.

  2. "Grok" is a friendly cave man whose web framework, "Grok", is
     really mostly stuff that other people wrote: lots and lots of
     Zope 3, *plus* some logic that will "grok" the classes you write
     that inherit from the caveman's Site, View, et cetera, *plus*
     whatever bits of glue we keep adding to make forms, viewlets, and
     other things more pleasant to use than they are in normal Zope 3.
     Plus we auto-associate templates.

When Martijn proposes an "import grokcore.component as grok", and
touts the name "five.grok", and other people talk about "plone.grok",
they are all using Meaning #1 of the name "Grok".  So whenever they
see a library that performs auto-configuration based on Pythonic
introspection, using "martian" technology and magic Python in-line
declarations at the top of a class, they name that class "grok".

Philipp is offended by this because, for him, the name Grok should be
limited to Meaning #2: it should only apply to the particular web
framekwork, that is actually mostly the Zope 3 web framework but with
convenience and sanity added.

In other words, Martijn sounds like he wants to use "grok" as a verb.

Philipp wants to keep "Grok" as a noun.

Martijn sees that we can now auto-detect and auto-register "Five"
components, and he knows that this is best called "grokking" them, so
he thinks that "five.grok" sounds like a fine description of that
action.  But Philipp objects because "Grok" is a cave man, not the
name of a general technique, and no matter how convenient Django might
become if it adopted the Zope component framework and used
martian-powered auto-configuration, it would still not be Grok, nor
would it run Grok web sites or understand Grok code.

To differentiate the noun from the verb, I am tempted to suggest that
Martijn and his friends start using some cognate of the verb; would
"five.grokker" or "five.grokkable" or "five.grokked" or something work
just as well?

Only as a joke, I'll note that we could have used "grok" for the verb
and "Grok", with a captial letter, for the cave man's web framework.
So "import five.grok as grok" would only give you the verb, whereas
"import Grok" would give you the noun. :-)

Anyway, I need to think more about this.  But the two meanings of
"grok" are starting to separate out, just like Zope-the-web-framework
and Zope-the-bare-component-framework are starting to need different
names to distinguish them.

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Grok-dev mailing list