[Grok-dev] Choice quotes

[Martin Aspeli]

Hi guys,

Below are some of my favourite tidbits from our recent discussion.

Martin

"""
Unsophisticated developers will look for Ease of use. They will also
look for power, but may not be able to understand power. They will also
look for scalability, but may not be able to evaluate what is scalable
and what is not. They look for reusable components they can simply use
to have great effect.

Sophisticated developers will look for the things unsophisticated
developers look for, but are able to evaluate it better. In addition
they look more for flexibility and evolvability of existing code over
time. They also look for reusability of code that's already there
(powerful components), as well as the ability to create reusable code
themselves.

Community and fun is appreciated by everybody, but more by a developer
with a social, open source mind set.

...

I don't consider Zope technologies to be competing with Grok, as the
synergy effects are much bigger than the competitive effects. A win for
Grok is a win for Zope and vice versa.

"""
     - Martijn Fassen

"""
To attract developers, the key benefit of Grok/Zope 3 is the fact it
is a 100% object-oriented solution. No "impedance mismatch" to deal
with.

I have a theory that Ruby is attracting more Java gurus than Python
because Ruby is perceived as "more object-oriented" than Python. I
know it's BS, but the perception is there.

Now, Grok leverages a robust stack that is completely object-oriented,
 >from the views all the way down to ACID object storage, and with
aspect-orientation to boot. Now that is something any Ruby guru would
wish they had.
"""

     - Luciano Ramalho

"""
 > > 4 What are the benefits of choosing Grok (over "competing" frameworks)?

Flexibility, and evolvability. These are very strong points. If you
write code using the component architecture, it tends to stay more
flexible later on. An existing application can have its behavior
modified without modifying the application's code (a lot). The component
architecture also offers a general way to make your own applications and
frameworks pluggable.

The already discussed two-edged sword of the ZODB. Really simple object
persistence is really great to have. I think Grok, by using the ZODB,
can be fundamentally simpler than any framework which uses a relational
object mapping.

I've been looking at the internals of Django a tiny bit and I see much
metaclass code that scares me. I grokkers are much simpler to ensure
component registration - your objects are far less magic. Systems like
Django (or for instance, widgets in the ToscaWidget framework) use quite
a bit of automation that looks somewhat scary to me. Normally this kind
of abstraction makes you productive, but when it does, you're scratching
your head.

That I think Zope 3 and Grok are less magic is probably partially due to
perspective - I'm used to our way of doing things. That said, I do think
Zope 3's explicitness and clearcut component and configuration systems
help in reducing magic.

 > > 6 If someone explained Grok in an article or review in a single
 > > paragraph, what would we want it to say?

Uh, I will need to examine the about grok page again.  :)

 > > 7 If I described a "beginner" Grok newbie, what features in Grok would
 > > interest him the most?

Ease of use while knowing there's great power available. Easy form
generation. Transparent persistence.

 > > 8 If I described an "advanced" Grok newbie, what features in Grok would
 > > interest him the most?

Flexibility and evolvability over time. Community's understanding that
things should be easy to get into *and* cleanly built *and* powerful.
Grok has the benefit that we have a central architecture in place
(component architecture and grokker infrastructure) that helps with
constructing such code.

 > > 9a Is there a silver bullet? (Something that if one gets it, just puts
 > > Grok in a class of itself with regards to competitors)

There is no silver bullet.  :)  Key benefit?

Grok should be just as easy as the competitors, but offer more reusable
components and more flexibility, allowing you to construct great
software now that will age well.
"""
     - Martijn Fassen

"""
 > > I like the idea of an "opinionated" framework, though I think Rails
 > > maybe stole that one.  ;-)

Right. The Rails people have rather hyped the stuffing out of that, and
now at least DHH is getting some backlash against his opinionatedness.

Luckily in the Python world we've had a design principle for many years
that fits quite nicely here:

"There should be one-- and preferably only one --obvious way to do it."

Let's use this one instead of the word "opinionated".
"""
     - Martijn Fassen

"""
 > > 4 What are the benefits of choosing Grok (over "competing" frameworks)?

* Model inheritance: The ZODB provides a very natural, very simple way
of storing your data. It also makes it *much* easier to use advanced
data modeling techniques such as model inheritance.

* Security: grok.require and grok.define_permission is already well
ahead of many other frameworks.

* Maintainability and Code Reuse: Components, Interfaces and Adapters

* Architecture: It doesn't force your application into a MVC-like
system. Grok has an MVC-like system, but it's not bending over itself to
force everything into just those three categories of components.

  * Grokking: By introspecting the code, Grok lets you put different
components within a single file. Sometimes you have a single model with
just two views. I really like having just one file for this rather than
dancing around between a model file and two view files.

  * Python Web Framework Synergy: All web frameworks provide an opinion
on how applications should be developed. Sometimes your application is
very similar to the type of application that the original authors of the
framework were trying to create, and you are a happy developer. Other
times your application ends up becoming quite a different creature and
you find yourself "fighting the framework" . For me, there are certain
web sites/apps where Grok is an obvious choice, other times I find that
using Plone is the obvious choice, and sometimes the app sits somewhere
in the middle and either framework could provide a good solution. While
Plone and Grok are two quite different creatures, since they are both
 >from the world of Python and Zope, it is relatively easy to "choose the
right tool for the job". It's also easy, and getting easier, to find
good functionality in the other Python web frameworks and apply that
code to your own Python web project.

 > >
 > > 5 What might be considered drawbacks with Grok compared to "competing"
frameworks?

* Relational databases, relational databases and relational databases.
There are so much data already out there in relational databases, and
many existing systems where you just want to provide a view or window
into just a subset of that database.

   In addition, while relational databases lock you into a more rigid way
of thinking about your data, the constraints imposed by them open up
other ways of working with data. Rails has script/generate for creating
new CRUD boilerplate, and Django has the lovely Django Admin interface.
Neither of these could port cleanly to a ZODB-based system without
forcing the ZODB to act more like a relational database.

* Grokking: By introspecting the code, grok lets you put different
components within a single file. This means there is less convention
'baked in' to the framework, and you sometimes have to think, "Where
should I put this component" - this is more of a hurdle when you are
just learning Grok. To the brand new Rails developer, looking at some
folders called Model, View and Controller, running script/generate, and
then starting to edit the generated boilerplate provides a very strong
message of positive reinforcement, as you feel like you are using Rails
in "The Right Way".

...

 > > a Is there a silver bullet? (Something that if one gets it, just puts
Grok in a class of itself with regards to competitors)

The Zope Component architecture. Grok provides a very strong story for
code reuse and maintainability. So often I see/hear the debate of Strong
Typing versus Dynamic Typing - Java proponents who find Python and Ruby
messy because you need to peek into the implementation to deduce the
intent of some code. Python and Ruby advocates who are horrified by the
reams of code generated by Java and it's IDEs. zope.interface addresses
many of the concerns of a typical Java developer, namely, "How do I use
this object, what does it's methods expect, what do they return and what
attributes does it have? Be specific.", while still staying within the
wonderful realm of the best dynamically typed language out there.

 > > 9b Is the silver bullet easy to explain?

No. And trying to explain interfaces and adapters to a web dev newbie
just makes them feel like the silver bullet is pointed at them  :(
"""
     - Kevin Teague