[Zope3-Users] What is the status on Zope4?
Andreas Jung
lists at zopyx.com
Sat Sep 6 20:27:49 CEST 2014
This nonsense needs some remarks....
2014-09-06 18:02 GMT+02:00 Christopher Lozinski <lozinski at freerecruiting.com
>:
>
> On 9/6/14, 5:00 PM, Andreas Jung wrote:
> > Better look into Pyramid
>
> I did look at pyramid. Multiple times. My highest respects to Chrism.
>
> So why am I using Grok instead of Pyramid?
>
> Pyramid has a bit of an idenity issue.
It has? Never heard of that...this is _your_ own opinion.
> Is it for relational databases,
> or the Zope Object Database? Is it for Traversal or for URL dispatch?
> Then there are three different ways of configuring it. And multiple
> different templating systems.
>
Pyramid gives me as a programmer the freedom to choose the database, the
routing mechanism and the template language that
I need and that I want for my projects. It does not tell me to: you have to
use this and this...this is _freedom_ and not an identity issue.
>
> If you are a consultant, than pyramid is just the thing. Whatever the
> customer wants, he gets. You want fry's with that. Great. You got it.
>
Stupid remark. Either you are a programmer or you are not.
>
> Grok is for the purist. ZODB is expected, although one can call a
> relational database. Grokers are how it is configured although ZCML can
> be used. Page Templates are used for templating, although other options
> are possible. Traversal is your only option, although it can be
> replaced. Indeed I just replaced grokcore.traverser. I have a clear
> mental model of Grok.
>
Constraints are perhaps a good thing if you are a programmer with a very
limited horizon
or if you need holding-hands with having only only possible option for
doing database, routing and templating.
> A uniform mental model has a number of advantages. First it leads to
> simpler code,
Bullshit - where is a Pyramid application more complex than a related Grok
application?
>
> And eventually there wil be performance benefits. Like the risc chips,
> or the optimizations on the Objective-C dispatcher, a simpler model can
> be more effectively optimized.
>
Nobody cares about such micro-optimization aspects.
>
> Another Pyramid issue is that all these options lead to code
> complexity.
Once again: bullshit! Complex application code remains complex independent
of the web framework. Provide some evidence for your claim.
> I was just reading a posting on that this morning.
>
Means you are repeating phrases without citing the source and likely
without having real world experience with small and large Pyramid projects?!
> Worse yet that code has been optimized making it even harder to understand.
>
So much bullshit, FUD in one sentence....provide evidence please.
Pyramid is usually every easy to understand when it comes to the Pyramid and
webframework related aspects. Bad application code can be written with
Pyramid
and Grok.
>
> On the issue of optimizing for humans vs Computers. Pyramid code has
> been highly optimized. For computers that is, not for people.
What a stupid blathering.......explain your nonsense and provide evidence.
This whole article read as you if you were on drugs while writing these
lines.
> Optimizing code for computer performance makes it pessimal for human
> understandability. Not that grok is brilliant on this point either, but
> i could easily imagine Grok going on the Paleolithic diet, and becoming
> a very small understandable code base, with modules that could be easily
> swapped in by those who want to optimize for performance rather than for
> people.
>
>
-aj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/zope3-users/attachments/20140906/6baf1a6b/attachment-0001.html>
More information about the Zope3-users
mailing list