Implying that advocating ease-of-use and convenience is advocating a caste system has a certain, err, chilling effect on the conversation. [wink]
If you look at tools like ArchGenXML, CPSSKins, and other work done separately by Rob Miller and Nuxeo on making AT/CPSSchema types TTW, you'll notice something crazy. People are attracted to these things.
It's like CLIs vs. GUIs in Linux. There's a class of people that think we are actively harming people by giving them a GUI. That what people really need is the "freedom" of a CLI and the full power it gives. After all, Emacs runs in terminal mode, and that's all that people need, right? [wink]
ArchGenXML, though incomplete in delivering its potential for convenience, is still a slam-dunk for this audience. It is so attractive, some people are willing to install a pig-slow Java app and confront UML. Imagine the task of developing the content schema in a drawing tool vs. throwing a Zope 3 component architecture book at them, and you're unlikely to get a response of: "I yearn for freedom, gimme the book".
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 certainly don't buy the half-pregnant thing. I think Archetypes has shown that a subset of functionality, exhibited in a well-bounded, well-scoped way, is attractive to a group of people that just want to get a certain job done without drinking the whole kool-aid. So yes, I think there is very much a group of "scripter" that less interested in the whole enchilada.
I agree that it's still questionable whether doing something for this audience makes sense, or whether the cure is worse than the disease. However, if we don't even agree on the demand, it's a moot point.
I realize that this debate mimics other age-old debates. I'm sure when SQL arrived, people said that it was too confining and that you should just learn a language like cobol. And then, when QBE arrived, people said you should just suck it up and learn SQL. Heaven knows what they said when Access arrived. [wink]
As a note, nearly all of what I'm talking about is specific to the content management market. I'm not implying that generic web applications can be done in a non-component-programmer way. I'm intrigued by Martijn's followup which discusses domain-specific languages.
can't complain...
Posted bychrismat
2005-12-21 01:17 AM
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).
If you look at tools like ArchGenXML, CPSSKins, and other work done separately by Rob Miller and Nuxeo on making AT/CPSSchema types TTW, you'll notice something crazy. People are attracted to these things.
It's like CLIs vs. GUIs in Linux. There's a class of people that think we are actively harming people by giving them a GUI. That what people really need is the "freedom" of a CLI and the full power it gives. After all, Emacs runs in terminal mode, and that's all that people need, right? [wink]
ArchGenXML, though incomplete in delivering its potential for convenience, is still a slam-dunk for this audience. It is so attractive, some people are willing to install a pig-slow Java app and confront UML. Imagine the task of developing the content schema in a drawing tool vs. throwing a Zope 3 component architecture book at them, and you're unlikely to get a response of: "I yearn for freedom, gimme the book".
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 certainly don't buy the half-pregnant thing. I think Archetypes has shown that a subset of functionality, exhibited in a well-bounded, well-scoped way, is attractive to a group of people that just want to get a certain job done without drinking the whole kool-aid. So yes, I think there is very much a group of "scripter" that less interested in the whole enchilada.
I agree that it's still questionable whether doing something for this audience makes sense, or whether the cure is worse than the disease. However, if we don't even agree on the demand, it's a moot point.
I realize that this debate mimics other age-old debates. I'm sure when SQL arrived, people said that it was too confining and that you should just learn a language like cobol. And then, when QBE arrived, people said you should just suck it up and learn SQL. Heaven knows what they said when Access arrived. [wink]
As a note, nearly all of what I'm talking about is specific to the content management market. I'm not implying that generic web applications can be done in a non-component-programmer way. I'm intrigued by Martijn's followup which discusses domain-specific languages.
"""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).