[BlueBream] BlueBream TTW

Sat Feb 25 18:31:47 UTC 2012

Let me explain the real role of "schema + formlib + ZODB-based programming"
from my point of view.

Most of the code in the world - is about nothing.

It consists of if-else ladders in 50-90% of the code, and these conditions
check some bullshit. And these bullshit-checks are really grow in your code
while you are maintaining your project. Why? Because in our computations,
in our interactions with real world, in our interactions with databases we
are not dealing with result, but we are dealing with *possible result.*

And "patterns" is not helping here absolutely. And "component architecture"
is not helping here absolutely, too. And objects-oriented programming is
not helping here absolutely. (But look at functional programming,
applicative style - the answers are there, may be).

Zope3 was a good attempt to solve this problem. And actually, it did. And
it did this by triangle "schemas + formlib + ZODB-based progamming". Remove
any corner of this triangle - and you will fall off, and you will start to
build infinite number of ordinal bullshit-checks.

So Zope3 reached that point with a cost restrictions, and the most
important restriction is ZODB. Its advantages are its restrictions,
actually. You data is bounded to your code, and there aren't ways to bypass
this.

Any other attempts to reach this are leading you into monads (and in
finish, math theory of categories). Good language for them is Haskell (or
Scala if you are good feeling yourself in Java-world). Learn them. Then
look monads in python code.

I mentioned that Zope3 reached this point and solved these problems. In a
sense, he is ahead of its time. But I see many Zope3 code of newbies and I
see the same bullshit-checks. The problem is not that they are newbies in
Zope3. The problem that they are newbies in programming. *And problem that
they spit out the question "How to program better"*, and they do not going
to be good programmers never. They are spawning entropy all the time by
their work.

BTW. BlueBream project now is in software errosion, I think.

On 3 February 2012 21:22, Christopher Lozinski <lozinski at freerecruiting.com>
wrote:
>
> Okay, I am starting my third attempt at getting BlueBream to do my
> bidding.  I am trying to build a Zope 2 TTW-like development environment
> on top of BlueBream.
>
> How did I get here?  Let me take it from the top.  I like the
> dynamically bound languages Objective-C, Smalltalk and Python.  Static
> binding in C++ makes no sense to me.   While Objective-C was quite dead
> for a while, the iPhone has made it popular, and of course Python is
> doing great.  Next we need a database, relational databases are such a
> pain particularly for storing trees.  There are a number of closed
> source commercial object-oriented databases with interesting features,
> but in the python world, ZODB seems to be the open source market
> leader.  Nothing much in the Objective-C world.   So ZODB brings me to
> Zope.  Of course Zope 2 had its problems.  The ZCA Zope Component
> Architecture is so much smarter.  Which brings me to BlueBream.
>
> But this mailing list appears dead.  The website download page has the
> most recent version as released a year ago, enough to scare even the
> most hard-core BlueBream supporter away.   When I posted a tentative
> email, I was discouraged, go use Pyramid they kindly suggested.
>
> So I took a much closer look at Pyramid.   That community seems to have
> grown so much in the last year.  But I just do not like the stripped
> down computational model it presents.   The whole BlueBream Schemas make
> so much more sense to me.  The more work the framework does, the less
> work I have to do.  Or the faster I can do it.  And I have lots of work
> I want to get done quickly.
>
> But I learned a very important lesson from the Pyramid guys.
>
>
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/designdefense.html
>
> They hid the ZCA from the end users.  Sure software geeks love the ZCA,
> but it is really too complex for the average user.  That is the piece I
> was missing.  Pyramid wisely hides it.  If we do a TTW development
> environment, then lots of stuff needs to be hidden.  A simpler
> computational model is needed.  Just instantiating objects onto a tree
> is quite simple.  Furthermore the ZMI registration feature needs to be
> hidden.   Just automatically register all views in the global register.
> And do not think of having adaptors registered, we want a simple
> computational model for the newbies.   No adaptors! No ZCA!  That comes
> later.  Sure all of that stuff needs to be there under the hood, but
> hide it from the TTW interface.  KISS!
>
> So what do we use as the foundation to build this?  Well there are three
> TTW interfaces. I have looked at them all.  ZMI, ice.control, and ZAM.
> ZMI is so ugly.  And it gets so much bad press.  And the registration
> part used to  confuse me.  Ice control has this lovely TTW python
> interpreter.  And ZAM.demo, which two of us now report does not install
> correctly, looks great.  It is extensible, if you can figure out the code.
>
> But I am back at using the ZMI.  It actually does what I want.  Add a
> dtml method and view it, no problem!  I believe if I just get the
> folders that use acquisition, and figure out how to use the PAU for
> authentication I should be good to go.  I will also need python, TTW.
> Just straight python, not restricted python.   Why even bother with
> restricted python, no one but me should have permissions to edit the
> python code.
>
> I can just feel some of my readers cringing as I write this.  I held off
> writing this for a while, I have no desire for the bad vibes.  In fact
> they kept pushing me away from this approach.  But I now better
> understand why this email generates negativity.
>
> There are really two different computational models.  One is the classic
> python file system based developer model.  You are actually editing text
> files and using the Zope Component Architecture.  The other is the TTW
> Zope 2 approach.   It has its strengths.  Each has their use cases.  But
> if you are locked into one world view, the natural thing is to reject
> the other point of view.   Really no point in getting into arguments
> with people who see the world differently.  So rather than discouraging
> this point of view, please let us allow each other to take different
> approaches.
>
> And yes, if you do want to get into a serious discussion about this
> stuff, I would be open to it.   In general I would love to talk with
> anyone who understands these issues.
>
> I am never quite sure what I am going to do next.  Plans always change,
> but here is my general idea. Rather than working in the abstract, I have
> an application I am building TTW, starting with the ZMI.
> Strategically, what I want to do is use the Zope Schemas to define my
> classes, and then implement the methods TTW.  I just need a class that
> first looks up the methods in a TTW folder. You can see the code for how
> to do this in ZClasses.   Later I can move the whole Schema definition
> thing into a TTW model.
>
> Why am I writing this?  Mostly to connect with other people who see
> things the same way.  Partially because it helps me clear up my
> thinking.   Partially because it generates useful information from the
> readers.   At the very least, I will breathe some life into the
> BlueBream mailing list.
>
> And compliments and thanks to all the people who wrote Zope 2,
> BlueBream,  the BlueBream website, documentation and the excellent page
> on defense of Pyramid Architecture.  Lots of great engineering has been
> done here.  Now we just need to simplify it for newbies.
>
>
> --
> Regards
> Christopher Lozinski
>
> Check out my iPhone apps TextFaster and EmailFaster
> http://textfaster.com
>
> Expect a paradigm shift.
> http://MyHDL.org
>
> _______________________________________________
> bluebream mailing list
> bluebream at zope.org
> https://mail.zope.org/mailman/listinfo/bluebream

--
Ilshad Khabibullin
+7 981 688 26 35
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zope.org/pipermail/bluebream/attachments/20120225/92f621b4/attachment.html>