OK, the caste system comment was a little over the top. ;-)
"""You can try claiming that this audience doesn't actually want ease-of-use, nor convenience. They want the full power, just better documented. I'm not buying, it though. I think this audience will swap freedom for simplicity, 8 days a week and twice on Sunday."""
I know people want convenience. I bank on this in consulting: hiring someone is the ultimate convenience.
I typically get hired by people who have already tried to do something (with varying degrees of success) using many of the Zope-related tools you mention. They hire me, because, to one degree or another, they understand that to do what it is they actually want to do, they need to try a different tact. Usually it's because what they came up with is either too slow or too complicated to maintain or both, usually with the willing help of the tools they chose. They are *not happy* to find out the tools they chose aren't really fit for purpose.
Believe it or not, I'd rather that these customers *didn't need to hire me*, and had started on the right tact in the first place.
Any website that is less than 100% cacheable whose frequently-accessed pages take longer than 300ms to render *cannot not work under significant load in production* without constant babysitting which, over time, costs more than a rewrite. This is why I suggest most "alternate environments" or "domain specific languages" are at least partly evil. If they aren't crafted very carefully to allow scaling, you basically have to throw all your code out and start all over again once you figure out that it can't possibly work under "real" load. SQL is a notable exception because its domain is so focused and its optimization patterns so mature. Maybe something so general can be conceived for content management; if so, I haven't seen anything like it yet.
To the extent that there's a middle ground to this tension, I'm all for seeing a solution. But it can't lead them down the garden path like TTW programming did; it needs to be able to scale. It also IMO *cannot be part of the core framework*. It needs to be an add-on, or a process. Any general purpose application server framework needs to stay very small to avoid suffering the same fate as Zope 2.
At the end of the day, people want to use an *application*. I'm all for seeing applications built on top of Zope that help people do things. I just don't want to see them turn into deep-seated framework; I particularly don't want to see them turn into framework to in order to "sell" Zope, because I just don't feel like it's ethical or smart in the long run to repeat the folly of the TTW environment "domain specific environment" in the context of a general purpose application server. IOW, I'd rather separate the marketing of content management applications from the technology that supports content management (an applicaation server).
"""You can try claiming that this audience doesn't actually want ease-of-use, nor convenience. They want the full power, just better documented. I'm not buying, it though. I think this audience will swap freedom for simplicity, 8 days a week and twice on Sunday."""
I know people want convenience. I bank on this in consulting: hiring someone is the ultimate convenience.
I typically get hired by people who have already tried to do something (with varying degrees of success) using many of the Zope-related tools you mention. They hire me, because, to one degree or another, they understand that to do what it is they actually want to do, they need to try a different tact. Usually it's because what they came up with is either too slow or too complicated to maintain or both, usually with the willing help of the tools they chose. They are *not happy* to find out the tools they chose aren't really fit for purpose.
Believe it or not, I'd rather that these customers *didn't need to hire me*, and had started on the right tact in the first place.
Any website that is less than 100% cacheable whose frequently-accessed pages take longer than 300ms to render *cannot not work under significant load in production* without constant babysitting which, over time, costs more than a rewrite. This is why I suggest most "alternate environments" or "domain specific languages" are at least partly evil. If they aren't crafted very carefully to allow scaling, you basically have to throw all your code out and start all over again once you figure out that it can't possibly work under "real" load. SQL is a notable exception because its domain is so focused and its optimization patterns so mature. Maybe something so general can be conceived for content management; if so, I haven't seen anything like it yet.
To the extent that there's a middle ground to this tension, I'm all for seeing a solution. But it can't lead them down the garden path like TTW programming did; it needs to be able to scale. It also IMO *cannot be part of the core framework*. It needs to be an add-on, or a process. Any general purpose application server framework needs to stay very small to avoid suffering the same fate as Zope 2.
At the end of the day, people want to use an *application*. I'm all for seeing applications built on top of Zope that help people do things. I just don't want to see them turn into deep-seated framework; I particularly don't want to see them turn into framework to in order to "sell" Zope, because I just don't feel like it's ethical or smart in the long run to repeat the folly of the TTW environment "domain specific environment" in the context of a general purpose application server. IOW, I'd rather separate the marketing of content management applications from the technology that supports content management (an applicaation server).