Jean-Marc Orliaguet is rewriting CPSSkins again, this time in Java, as Nuxeo is switching their CPS platform from Python and Zope to the Java language . The reasons for this switch are detailed in the FAQ. I'm not going to debate them here. Jean-Marc, part of the community around Nuxeo making the switch, now posted some interesting criticisms of Zope and the Zope community. I am compelled to give a response from the perspective from the Zope community. If it's all a bit long and ranty, please forgive me. I'm going to quote Jean-Marc copiously here. Let's start: "You probably read the news the other day. There have been very few reactions so far apart from Phillip reporting the news and Paul making an allusion to it." Jean-Marc, the news means Nuxeo's exiting our Zope community. I sincerely regret Nuxeo's leaving, as they contributed a lot. It's a major loss and we're mourning it. We're a diverse lot, so we don't have a single reaction. Possibly many of us feel that too much reaction would result in an argument about how wrong the other side is, as we're not joining you in the switch to Java for our own Zope-based platforms, and you're not going to be convinced to switch back either. So, there's not all that much to say overall, except to wish you luck. I'm sure Jean-Marc's motivations in posting the criticisms are a genuine attempt to help us improve our Zope community. Thank you, Jean-Marc, that's valuable. I do however admit frankly that I'm a bit bothered by some of Jean-Marc's implications. I realize that it makes sense psychologically to defend the choice you've made, much like it makes sense for me to defend Zope and Python in the face of criticism. Overall I think my answers give me the impression that Zope 3 isn't doing so badly, even from a Java perspective. :) He starts by saying: "For Zope, what can be learned from the Java technologies?" and then lists some points. I'll repeat his points and give a response for each. IDEs can indeed be very helpful. It's a general issue with Python that IDEs are not as powerful and well-developed as those in the Java world. Tools can compensate for the deficiencies in a language, and languages can compensate for the deficiencies of tools. For a lot more about this, there is an insightful article about the psychology behind all this. I'm a "language maven" myself, but I recognize that other people are "tool mavens". More power to them, but I'm doing fine myself, thank you. Again as a language maven, I don't think we as the Zope community should make an IDE a priority, as we only have so many resources to go with. Since this is an open source community anyone can step up and try to implement one, though. Jean-Marc says: "The bottom-line is that there is only one chance for a developer to get the API right, because other developers expect it to be stable and easy to extend." I can't get an API right the first time unless I have a lot of experience with the problem at hand, meaning having gotten the API wrong already a number of times. That appears to be true at first sight for Jean-Marc too; I'm sure it's easier to get the API right for CPSSkins the third time around. Stable APIs are, of course, important. That's one reason why in the Zope community we've adopted explicit interface descriptions heavily, and test everything to heck just so we know we're not accidentally breaking something. Concerning getting things right the first time in the Java community: the Java community understands refactoring well though. The IDEs have built-in support. Jean-Marc: "And no, the deprecation feature is not a tool available to developers for doing cosmetic refactoring or for renaming packages." This point is not backed up by argumentation. I'm a big believer in iterative development as I know I'm not smart enough to get things right the first time. Instead of living with a mistake forever, I think it's often more effective to correct the mistake when possible, instead of living with it forever. Instead of just breaking people's code when we change things, we make the commitment to support the old code for a significant period while issuing deprecation warnings. It's somewhat ironic that Jean-Marc's point is stated in the context of the Nuxeo switch away from Python to Java - I imagine that will break a few APIs in CPS here and there as people move over to the new platform... Of course, Nuxeo uses the same reason I did just now: it's better to change from Python to Java now by API breakage than it is living with it forever. Yes, following established specifications is often a good idea, so I (as a member of the Zope community) have often argued it's useful to follow specifications. In fact, I wrote a whole article about how to evaluate them. Note that not all specifications are equally valuable. Sometimes they're inappropriate for the job. Sometimes they're too heavy and more light-weight processes are in order. "Lots of packages are being added in the Zope3 repository without proper reviewing, implying: "we find this useful, hence someone else may find it useful too". This is relatively harmless for utility packages that have a limited scope, but for framework foundation modules this is a problem." Jean-Marc, you're implying we're adding new framework foundation modules to Zope 3 without proper reviewing. I don't think that's happening. We've added non-framework packages to the Zope 3 software repository. That doesn't mean they're core and that doesn't mean you have to use them. Before I start using a piece of open source software I evaluate how mature it is, whether it has developers backing it up, and so on. This is a fact of life in the open source community (or for any software developer, really). If I were just focused on standards I might use PyXML, as it supports DOM. I then realize PyXML is not very actively developed anymore, and that it tends to suck to work with the DOM API in Python, so I might switch to lxml or Amara. We've had extensive discussions in the Zope 3 community on how to formalize the process of component maturation and mark packages as more or less stable and more or less supported more explicitly, and we'll continue taking steps in that direction. It's important to realize that people learn, though. Software components that are perfectly good at some stage may still be replaced by better ones later. This process of evolution is healthy. "But having 3 or 4 different specifications of a same basic feature because they were hurried in simply means a lack of concertation." Sure. Are you implying we're hurrying in features a lot? Are you implying we regularly have 3 or 4 different specifications of same basic features in Zope 3? Are you implying that such a thing never happens with Java software? Concerning package naming convention, I don't think we're doing too badly. Zope uses namespace packages extensively. "Otherwise as a developer I may well start using a zope.abc package to learn 3 months later that the package was just the result of an experiment, and that it will be replaced by a "better" implementation." I'm missing something here. Are you implying we just dump everything into the 'zope' namespace package? We clearly do not. Zope Corporation uses 'zc' for its package namespace. I've been using 'hurry'. We also got 'lovely' for Lovely Systems packages, and 'z3c' for packages managed by the communit, and so on. 'zope' is used for core packages, though admittedly we do have some non-Zope core packages sitting around - a situation we want to resolve. I'm not saying our situation is perfect, but I think we struck the balance between too cumbersome and too lightweight pretty well overall. "There are no such things as adapters, factories, utilities, events in the Java language, these are just design patterns." The implication here is that these things are all available in the Python language, but I think Jean-Marc here is comparing the Java language with the Zope 3 component architecture here. Perhaps it would've made more sense to compare Zope 3's component architecture with some component model in Java, such as J2EE or whatnot. Perhaps that makes no sense - I don't know much about J2EE. Indeed: "In other words, in some cases using the Adapter pattern may be a good idea while in other cases, it may be a bad idea. One cannot know the solution until the problem to be solved has been described." Indeed, sometimes the adapter pattern is not a good idea, and sometimes it is. You seem to be implying that we think it's always a good idea and that we think we can know the solution to a problem before it is has been described. Sometimes it's nice to have a registry of adapters so you can find the right one automatically. The latter is what Zope's component architecture offers and it makes it more easy to devise APIs with plugin points. "My impression is that the 4 basic patterns promoted in the zope3 architecture as the "new religion" are predefined solutions to problems that are yet to be identified." Let me hereby correct your impression, as it doesn't appear to be correct. Zope 3's component architecture provides useful facilities for looking up adapters and utilities, yes. It's not a religion and I personally encourage everybody to write plain Python where possible. We've also been doing this Zope thing for some years and indeed have identified several problems in architecture we keep running into and that we'd like to have some assistance with. Hence the component architecture. "Conclusion: the Component Architecture is not a universal solution for particular problems." You seem to be implying we think it is. No, it's a bit more subtle than that, just like Design Patterns. It's interesting to contrast, by the way, how first you recommend specifications as a way to get APIs right the first time around, and now you argue against solving solving problems that are yet to be identified. Jean-Marc argues that hooking up small dedicated components is overhead. He then says that small dedicated components are the wrong appproach. I agree that hooking up small dedicated components is overhead, and reducing this overhead is something that I'm personally interested in tackling (sprint in about 3 weeks coming up). I disagree that this means small components are the wrong approach. I do agree that it is useful for us to study plugin-architectures in other systems. I'll note that Java-based frameworks are not generally well known for having low developer overhead for hooking things up. One of the reasons of the success of Ruby on Rails is that it is a reaction to the overhead of getting things set up in Java. This therefore appears to be a criticism we possibly share with the Java world, not necessarily something to learn from the Java world. "Conclusion: the Component Architecture does not replace high-level API design" You seem to be implying that someone thinks it does. We don't. We think that it helps in API design, as it gives you tools enabling you to write pluggable APIs, such as interface-based lookup of adapters and utilities. The title of this point is rather odd. ZCML is of course valid XML. If you run it through an XML parser and you get an error, then that's a bug, please report it to us. Anyway, the general point is that we should reduce the amount of XML for component configuration. I agree with this point. I'll note again that Java-based frameworks are not generally well known for having low developer overhead for hooking things up. That doesn't make this criticism less valid, though. Jean-Marc knows a lot more about this than I do, and I'm sure there are useful things to learn from various Java-based frameworks here. Thanks for the pointers! "What is "pythonic" what is not? but who cares basically as long as you have a good API and a great framework? Really, it is better to spend energy on more important things." You seem to be implying we spend a lot of time arguing about some mystical quantity called Pythonic, being on some "trip" so to speak, but you know that's not what we do most of the time. Besides, for a system to be Pythonic means that system has a good API, following the conventions of the Python language and community. Here is what I had to say about this, when I stopped for a change and did discuss it. "The balkanization of the Python community is a real issue I think." Indeed. As you might know I've been arguing for the Zope community to engage positively other areas of the Python community (and beyond) for a long time. So, good criticism, and one we've been aware of for a while. Zope 3 is in part one reaction to the criticism from the Python community on Zope 2, for instance - we've been developing that since 2001. I believe there's strength in our diversity, but I also believe there's a lot to benefit from working together. Recent developments help ease the sharing of components between communities through the egg distribution mechanism, so I'm very hopeful we're on the right track. But this is perhaps not so good a criticism in the context of learning from Java. From a distance I have the feeling that the Java community hasn't entirely solved the issue of balkanization just yet either. There appear to be multiple competing web frameworks for instance, Eclipse and NetBeans for IDEs, multiple UI toolkits, and so on. I'm going to quote this section entirely, as this one really upset me on a personal level: "Self-criticism is about being able to see what others did and admit when it is the case that they did some things better; especially taking a look at JEE, JBoss, Eclipse, or Ruby-On-Rails, Turbogears, Django, etc. JBoss Seam for instance was created as a Java response to the Ruby-on-Rails' success. What has the Zope Community's response been to RoR? Maybe it is time for constructive self-criticism?" Come on, Jean-Marc. You imply here, no, outright say, that we do not engage in constructive self-criticism, while nothing could be further from the truth. I, along with many others in the Zope community, fully admit other communities have done things better than Zope, including the Java community, and I personally have been working on these issues where I can. While I dislike what you've been saying by implication so far, at least most of them are points that can be honestly debated, but this one I think is just completely unfair. Constructive self-criticism is taking place continuously in the Zope community. I know, as I've been engaged in it for a long time now, as you should well know. You also mischaracterize our position concerning a web site. I do believe we need a better web site for Zope and better marketing towards developers in general. I think that's one lesson we can learn from Ruby on Rails and friends. Do you disagree? You imply we believe that's the only thing other platforms have going for it. I feel offended by the implication that you think we do, and that we're so blind we don't even look. We do. Jean-Marc, you appear to be saying a lot by implication. It's not my preferred style of criticism.
![[Comments]](/blog-content//themes/Default/comments.png "24 comments")
(24) Sun Sep 24 2006 16:54 Jean-Marc's implications:
The Importance of the IDE
The Importance of stable APIs
The importance of standards
The Design Patterns
The Component Architecture
ZCML is not XML
The Presentation Layer
The "pythonic" trip
Balkanization
Self-criticism
- Comments:
Posted by Jean-Marc at Sun Sep 24 2006 18:18
Martijn, thank you for responding to my post.First of all, to clear things up, I am not leaving the python/zope community. The difference is that I know have the possibility to take a wider perspective and as I result be more self-critical and share the criticism with others.To be honest with you, the points that I am listing are mistakes that I personally made:- focussing too much on the language and not enough on the IDE, on the fact that not everything has to be solved through the language.- not spending enough time on the specification and too much time on implementation.- not paying enough attention to standards, and by standards I hope that you understand that I do not mean HTTP, XML, WebDAV, or FTP, but oSGI, JSR-170, XForms, JSR-168 etc, the industry standards. - feeling obliged to "leverage the Component Architecture"- putting too much configuration and "meta-programming" code into ZCML, instead of simply using another format for configuration (json, XForms, XSD, CSV, text file ...) based on pragmatic needs.- the presentation layer would deserve a book in itself, unfortunately not many zope3 programmers seem to understand that UI programming really is the tough part. But real programmers don't do HTML, do they?- the remark on "pythonic" came to my mind since I could not find any equivalent term in Java (in the sense that code is getting judged according to criteria that no one really can define). There seems to be less concern about these details in Java.But after reading your post, I would not say that you fully disagree with anything that I wrote.So again, my point is: take a real look at what other communities do, take what is good and ignore the rest.
Posted by Martin Aspeli at Sun Sep 24 2006 18:57
Very well put, Martijn :)You didn't address the issue of UI design. I've been using JSF and Facelets (JSF + JSP is just silly) for another project recently, and mostly come away disappointed. The basic idea is that you write beans (simple Java classes) that you register under some name in an XML file. Then you refer to them like:This will then pull the value from myBean.getMyProperty(). Beans are bound in session, request or application scope, and spring into existence when referenced. As such, they're not much different from registering view classes in Z3 and acquiring them via context/@@foo.The problem is that JSF is schitzofrenic about whether it's really about building some component tree that represnets UI state at a very abstract level (i.e. you could theoretically render it to non-HTML representations), or whether it's just about plugging things into HTML with pretty syntax.Writing a new JSF component is also quite difficult (or rather, there are many things you have to do) and we still are writing HTML to an output stream in Java code to render anything. Facelets makes it barable, and also adds metal-style "reverse" macro includes (fill-slot), and stops the interesting situation where JSF components inside JSP constructs (like loops) were not evaluated at the same time (so your loop isn't repeating what you think it's repeating).Also, the HTML that JSF spits out is atrocious. Everything is done with inline JavaScript, and forms don't always behave the way you think, often because some internal component tree state is cached. It's very hard to debug what's going on because the output HTML is so far away from what you actually wrote, and a lot of the binding of form state to actual variables happens behind the scenes. For example, I've been grappling with bugs that mean that when one part of my form fails to convert (e.g. to an int on the backing bean) the entire form is submitted without error but does not set any values on the backing bean at all. Some of that is just implementation weakness (and some of it in MyFaces), but it's very hard to follow what's going on sometimes.I actually think that the Z3 version of a view is very attractive, easy to understand, easy to debug and powerful. There is still too much ZCML magic going on in the browser:page/browser:view directives, but they don't really affect you in the same way. Also, viewlets are extremely powerful and useful constructs that are analoged in the Java world mainly by JSR168 portlets - but these need a portlet container (as in, a big portal server like WebSphere Portal Server), and really are not meant (as far as I can understand) as fundamental building blocks for bespoke UI composition.My personal opinion on Java is that it is exceedingly good at some things and very appropriate for certain type of systems. Those tend to be more in the back-end and middle-ware, though. For building web applications and HTML-based front-ends the language and the frameworks makes your life too difficult and makes development too slow.
Posted by Jean-Marc at Sun Sep 24 2006 19:29
Martin, take a *real* look at Seam, it solves the issues that you mention.http://www.jboss.com/products/seamhttp://docs.jboss.com/seam/1.0.0.GA/reference/en/html/tutorial.htmlYour argumentation is similar to someone's judging Zope only on the basis of DTML.Seam competes with ruby-on-rails in terms of simplicity and transparency. Doing AJAX with Seam couldn't be simpler.Nothing in the world of Zope2/Zope3 can compete so far. Until you guys begin to realize that frameworks are judged on the basis of how easy it is to create a UI and to integrate with existing information systems (SQL-based, LDAP, ...) there isn't a chance that zope will be in the race. The times have changed.http://www.eweek.com/article2/0,1895,1861003,00.asphttp://squizlog.keithpitty.org/archives/000457.html...
Posted by Martin Aspeli at Sun Sep 24 2006 19:45
I haven't had a chance to look at Seam yet. I had to do some real work before evaluating it and Spring and WebWork 2 and Sitemesh and ... My capacity for absorbing new frameworks is somewhat exhausted for this project. :-(I will, though, for the next project - thanks for the pointer. I hadn't even heard about it until now, which may have something to do with the fact that it seems to have been released after we had settled on a platform.Btw, DTML is analogous to JSP, and comparatively obsolete. JSF is what the Java world have been touting lately, largely in response to the way ASP.NET made web-development more like traditional RAD GUI development.But this comment is both iflamatory and incorrect in its implications:"Until you guys begin to realize that frameworks are judged on the basis of how easy it is to create a UI and to integrate with existing information systems (SQL-based, LDAP, ...) there isn't a chance that zope will be in the race. The times have changed."Indeed.
Posted by Martijn Faassen at Sun Sep 24 2006 20:24
Jean-Marc, I disagree with you on much of what you seem to be *implying*. I therefore disagree with you saying I'm agreeing with you. :)Secondly, if some of these points are mistakes you personally made, then don't call them mistakes of the Zope community. Anyway, concerning standards: "oSGI, JSR-170, XForms, JSR-168 etc, the industry standards"Two of those standards are JSRs. I just looked up oSGI, and that's Java-specific as well. That's called "stacking the deck" in a debate.Concerning paying attention: even though it's a Java-based standard, I've personally advocated looking at JSR-170 to the Zope community, and I think Florent Guillaume at Nuxeo actually might've heard about it from me personally. I am not sure yet about the value of JSR-170 - it promises interoperability between CMSes but it seems to be rather low-level. Does it actually accomplish more than an absolute minimum? It may be too early to judge whether it's a successful standard in the Java world.I think XForms is a standard to watch. Java is ahead in implementation compared to the Python community here. That's one benefit of using Java - more standards support. Java is quite a bit ahead there, and so is C# probably, but I consider Python to be a good runner-up in standards support as programming languages go.Concerning easy hookup of views and the like: this is an area we need to improve in Zope 3. I will take a look at Seam, apparently currently the way to do it in Java. I do find it ironic you say in the Java world they specify and therefore get it right the first time, and then when people complain about whatever's specified you say there is a new way that's much better. This implies to me that the "API of the week" phenomenon is something not only constrained to the Python world. :)
Posted by Jean-Marc at Sun Sep 24 2006 20:31
Actually I have looked at the JSF API (the equivalent of ZPT roughly) and the Facelets API (the equivalent the ZPT macros roughly). The difference is the ZPT implementation is so linear and so un-API-wise that there isn't a chance that it can be extended or anything can be plugged into without doing low-level changes in the code.Considering performance I have experienced 400 to 600 request / second on the rendering of JSF / facelets pages, when ZPT lies at 40 req/s in the best circumstances. That's something I don't really get, actually this has nothing to do with python or java, this has to do with how the request / response lifecycle is implemented and has been optimized.Facelets actually cache the result of page composition which ZPT doesn't do. Without the caching, the performance of facelets drops down to 40 req / s.My intuition is that the ZPT implementation ought to be rewritten with a real API to make it possible to cache page fragments.Best
/JMPosted by Jean-Marc at Sun Sep 24 2006 20:48
Martijn, I am not "implying" anything, so whatever you think I am implying, I am not necessarily implying. All I can discuss is what I actually wrote, not what you think "I am implying".I also know that you are acting in your roll of python/zope technology advocate, which is understandable so I understand your reaction.My mistake was to not look at other technologies sooner with a neutral eye, which is what the 10 points I listed are about really. I admit it.However I am sure that everyone in the Zope community has already downloaded and assessed the quality of Ruby-on-Rails, Turbogears, Django, JavaEE, and concluded that zope was best in every aspect... So it could be that I am the only one who did the mistake ;-)
Posted by Martin Aspeli at Sun Sep 24 2006 20:51
Jean-Marc,That's simply incorrect. ZPTs can be extended by providing new expression types. For an example, look at zope.contentprovider. This is done by writing a particular named adapter, and is very simple. The ZPT engine has a real API, defined by real interfaces.As for caching, if you're going to cache, you may do so in middle-ware or outside the implementation. We get very good performance with e.g. CacheFu and Squid. Of course, some automatic mid-level cache right after ZPT composition may be interesting to look at.
Posted by Steve at Sun Sep 24 2006 21:18
I'm curious why a multi-language platform wasn't the solution. Why not Zope (or at least Python) on the server side, and Java on the client side? With XML-RPC or something in between?I'm just learning Python right now, coming from the Java server-side world, and there's a lot of JBoss kool-aid to be had. It's very curious for all the Java press I see about moving to Ruby/Python, while Nuxeo is going Python->Java.Steve,
server-side Java guyPosted by Jean-Marc at Sun Sep 24 2006 21:18
Martin,Registrering new tales provider expressions is not really what I meant.you should have seen Julien and Fred Drake last year at Zope Corp with who tried for almost a week to modify Zope Page Templates to make it support XML vs HTML mode cleanly, before giving up after a few days :-)Only two or three persons in the world probably know how to modify the ZPT code.Ask Tres' opinion about the ZPT API.But it could be that we're off-topicRegards
/JMPosted by whit at Sun Sep 24 2006 22:19
Last time I checked, no one asks for an exit-interview in open source. jmo, go paint the bikeshed somewhere else.-w
Posted by Chris McDonough at Sun Sep 24 2006 22:20
Is it possible that one important reason for Nuxeo's switch goes along the lines of "we want to be able to outsource software development to many inexpensive Java people"? That would be a valid reason to switch, but it doesn't have much to do with technology.
Posted by Andreas Reuleaux at Sun Sep 24 2006 23:02
By the way: there is an eclipse plugin for Python: pydev,
http://pydev.sourceforge.net/
Also one can use a shell with autocompletion: pycrust & pyshell (now part of wxpython, http://www.wxpython.org)Posted by inexpensive non-java developer at Sun Sep 24 2006 23:12
Chris, you're probably more close to the truth than most of this "Java is great, how come didn't I see this earlier?" BS. Sorry for the pathetic rant, but some things never cease to amaze me.
Posted by Dario Lopez-Kästen at Mon Sep 25 2006 01:52
oh, come on. I need to react at some of this; instead of looking into what actual content and possible value Jean-Marc's remarks may have (something which only Martijn and Martin seem to be doing), there is mocking and ridicule. Like Jean-Marc pointed out it's not about leaving the Python/Zope world and it is not about "Java is great, how come didn't I see this earlier?" BS" as "inexpensive non-java developer" puts it nicely - all that has happened so far is that a new opportunity has emerged, an opportunity that may or may not solve some of the issues that we have, i.e. interfacing to existing systems and frameworks with out having to write huge amounts of glue code. For some organizations the problem of how to become a "good player" in the world of existing applications is tough problem to solve - especially if you use a different technology.The IDE point IS a big issue. I have been using Eclipse and PyDev for more than a year now, after trying boa, SPE and others. As a matter of fact, it was PyDev that led me to try Eclipse - together with the other editors that eclipse had available (ie. html, css, etc). I have never looked back - and I am not even using the PyDev Extensions, which from what I hear are really good commercial additions.What saddens me the most is that Zope is still a great platform. When I chose Zope over other systems 6-7 years ago there was no competition. Today, it is still true, to a large extent. But the competition is catching up and being self-sufficient and self-content, ignoring and failing to evolute the advances others have made will not lead to advancement. Why is looking at the advances done by successful others and learning from them such a bad thing? It is not about the language, it is about the patterns, the methodology. I am convinced that the competition has learned a lot from Zope - both in the python world and in the java world. So let's do the same.
Posted by Tres Seaver at Mon Sep 25 2006 05:06
Jean-Marc wrote: > Only two or three persons in the world probably know how to modify the ZPT code. > Ask Tres' opinion about the ZPT API.Actually, I think the *language* design, at the API level, is fine: what chaps me is the *implementation* as a byte-code interpreter using tons of Python primitives as optimizations. That implemenation is the current limiting factor for optimizing ZPT, because it is impossible to
replace pieces of the applicatoin with parts rewritten
using knowledge gleaned in the five years since it was
implemented: there *is* no API governing the interactions
of the various bits of the engine (the internals).Ironically, if we'd had the component architecture when we first implemented ZPT, we wouldn't have this problem, as the interactions between the pieces would have been specified using interfaces, which would then make the individual parts of the engine replaceable.Martijn, thanks for a response which said much of what I wanted to write.Posted by Martijn Faassen at Mon Sep 25 2006 10:42
Jean-Marc, I realize you may not think you're implying anything, but from the perspective of this reader, you are. :)
Posted by Benji York at Mon Sep 25 2006 14:27
Martijn, he is either implying much or saying little. I haven't decided which.
Posted by paddy3118 at Wed Sep 27 2006 04:42
Jean-Marc can be seen as giving an "exit inteview". They are only a waste of time when nothing is said, or what is said is not considered. (Note: consideration of points raised can include their later rejection as well as their acceptance).
What is difficult, but is neccessary, is to ignore any personal slights (imagined or real), during analysis.Hey, nothings perfect. And my idea of perfection is better than yours :-)- Paddy.Posted by Martijn Faassen at Wed Sep 27 2006 11:29
Paddy, good point. At first I interpreted this as a comparison of Zope + Python with Java + various things, as this is how it was announced. I tried to read his comparison as best I could, making explicit any implications I read into it by asking whether he meant to imply them. I have received a blanket statement that he didn't intend to make any implications, which means right now I'm at a loss on how to interpret what he said. Without implications, he's not saying much about API design in Zope 3.The best way to figure out what was meant is of course to listen to what Jean-Marc has to say himself. He reported in a comment tha these points described mistakes that Jean-Marc himself considered to have made. For instance, the point we need to take home here most in my opinion is that we need to make clear to people that we do not believe the component architecture is where API design ends, but is only a system that can be helpful when expressing certain pluggability concerns in an API. We do want to communicate things we do not intend to.We also need to take away the impression that we break APIs in Zope 3. That's not true and there seems to be a lot of fear and uncertaintly about this. The point of self-criticism to be careful when changing APIs, and to communicate these changes extremely well, had already been made in previous discussions.In a more recent blog entry it seems to be Jean-Marc main point of the original article was to induce self-criticism in the Zope community, something he perceived a lack of. I disagree strongly that we lack such self-criticism. This was the point that bothered me on a personal level.Unfortunately, Jean-Marc's article made it hard to have a self-critical debate, as by the nature of his article he seemed to place himself outside our community. Self-criticism has to come from within. The natural reaction here was to respond as if it were external criticism.Again perhaps the main point to take home is one of communication. I certainly believe we have plenty self-criticism taking place within the Zope community. What I believe we need to do more is to record the results: "we were doing this, but we thought it wasn't ideal, so now we're going to do this". This is also helpful for other reasons - a record reduces the risk we make a good decision but then forget about it again.
Posted by sathya at Mon Oct 02 2006 02:37
Hiring Zope developers is a challenge. However hurdles are everywhere. Switching to Java does not make them go away. There is another famous example of a CMS switching to Java (Vignette) to be more market friendly. I dont think it increased their chance of success from what I know.
When you pick Zope as a technology you have to learn how to live with market forces.
If you have lots of money to throw at marketing and sales in addition to product development
you have a good chance at success regardless of Java or Zope/Python
technical innuendo should not be a reason to switch as the Zope community has enough strength to compete with any technology out there.Posted by Jean-Marc at Tue Oct 03 2006 16:38
to conclude, the "What Zope can learn from Ruby on Rails" article (http://faassen.n--tree.net/blog/view/weblog/2005/04/06/0)seems to have been more successful than the "What Zope can learn from Java" article.Posted by Martijn Faassen at Tue Oct 03 2006 18:14
I'm not sure what you mean with that, Jean-Marc; how does one compare success? How does one define success?I know I'm still working on trying to get a better face of Zope to the world (better developer marketing), and am also starting work to simplify the Zope 3 experience itself for beginners and experienced developers alike.
Posted by anonymous Plone user at Sun Nov 12 2006 00:33
From my brief interaction with JMO he is an arrogant ass**** and the Zope community should be glad to see the back of him.
