Store is the boat anchor that will sink VisualWorks
Disclaimer: I don't have any detailed information about how Cincom works internally, or their customers. This post is purely based on observation, supposition and experience.
From what I can see from the outside, the single greatest impediment to the survival and growth of VisualWorks is the existing customer base. The requirement to maintain backward compatibility, or provide an automated migration path imposes an enormous engineering cost. Anything that can be done to avoid that problem, should be done, and IMHO should be Cincom's number one priority
From what I understand, forthcoming Cairo/Pango integration will not be done in a backwards-compatible manner i.e. a given window will be either a Cairo window or a legacy window. If so, this is a great idea because it means the implementation will be less work and require less compromise.
OTOH, I think the primary competitor to VisualWorks is Ruby, for the reasons given in my previous post. Obviously WebVelocity is a response to this, and while I would have done it slightly differently, I'm sure Michael and his team will deliver a great product. WebVelocity isn't bound by the legacy problem, and in fact Cincom is positioning it as being a separate product, that just happens to be written in VW. My issue is that I don't use Seaside, so WebVelocity does nothing for me, and furthermore, for all it's coolness, I don't think the future belongs to Seaside alone.
My primary Smalltalk development over the last 18 months has involved building a web application on a custom web framework that I derived from Seaside. The system has to be able to scale to a captive audience of millions of users, with session timeouts of at least 4 days. That's not exactly Seaside's target market, so I developed a damage based AJAX framework that doesn't use continuations, but does use block callbacks (much more efficiently than Seaside). IMO block callbacks are the killer Seaside feature, not continuations. I also have to deal with physically distributed server clustering with unreliable network connectivity that results in arbitrary cluster partitioning. It's just me, from design to deployment, so the project was totally dependent on VW delivery significant productivity gains over my initial Java version. So far, so good, although the VM does crash on a regular basis, with no useful debug info - but that's a separate issue.
So, as a competitor to Ruby you might think that the GUI doesn't matter, because Ruby has no real GIU. However the competition is TextMate + git/svn + bash + trac + github/sourceforge + Netbeans etc. It seems to me that the solution to this competitive problem is not to compete with those all those tools, but to embrace them. And that requires file based sources, integrated with the VW IDE. That's what I'm focussing on, and the primary obstacle is the way that Store dominates the IDE. I think trying to improve Store is a waste of time. The amount of effort required to bring store up to a reasonable level of functionality would be, IMO, better spent breaking the legacy problem and refactoring the way Store is integrated into VW so that alternative approaches to source control are possible i.e. making Store entirely optional. At this point, that's all I want in the next version of VW
File-based sources, using git or svn for version control, not only trivially solves the problem of binary resource support, it also massively improves the opportunities for collaborative development. I've written about those issues before so I won't repeat myself here.
Comments
Continuations
[Lukas Renggli] May 31, 2008 3:02:17.580
FYI: Seaside 2.8 doesn't use continuations either, unless you do #call:/#answer:.
Re: Continuations
[Antony Blakey] May 31, 2008 3:28:19.195
OK, but that would require me to avoid #call:/#answer:.
In any case, I use block callbacks extensively. I do that by recording the block's method, rather than the block itself. The block's method is effectively constant. I then encode the callback as a serialization of the closed-over values and the key for the recorded method, so I record very little data. I maintain a server side representation of every html page (and then allow 'damage' to that page to be automatically converted to AJAX JS responses that maintain the server/client equivalence), but both the page and the session data is serializable, primarily through the use of lifecycle notifications that can convert between passive and active representations, largely abstracted. Thus I can scale in a similar way that Gemstone allows Seaside to scale.
Re: The Return
[Antony Blakey] May 31, 2008 3:29:57.887
I understand your point, but without defining new syntax, I need to use either a block, or the somewhat non-standard brace. The problem with the brace is that there's no way to bring the method arguments into scope - blocks are the only scoping mechanism.
Of course I could define new syntax that defines a method object, but it would be purely for the sake of having a different visual representation. And I'd want that to be part of the core ST syntax keep the "it's just code" DSL-like nature of the format.
OTOH, I don't think the visual unification of those items will be that confusing, but I'll have to think about that some more.
[] May 31, 2008 3:53:42.319
I think you misunderstand what Cincom Smalltalk is about. Cincom Smalltalk is not about new customers. Cincom Smalltalk is about sucking money out of existing legacy customers that are locked in.
Re: Store is the boat anchor that will sink VisualWorks
[ James Robertson] May 31, 2008 11:37:24.451
Comment by James Robertson
Cincom Smalltalk is most assuredly not about "sucking money out of locked in customers". We may have some staff who think that way to be sure - and I'd ask you to contact me if you feel you've been mistreated.
Look at where we are headed - Seaside is open source, GLORP is open source. We are trying to sell our forward direction based on us having the best solution based on an open set of code.
[Antony Blakey] May 31, 2008 19:30:41.634
Every person at Cincom I have spoken to directly is eager to move the product forward and grow their market. While the existing customer base is an obvious asset, it is, as I've explained in this post, a significant liability.
And I think it's in the nature of the Smalltalk language for that to be the case, primarily because of lack of modularity.
You need look no further than WebVelocity and it's implementation/packaging strategy to see that Cincom are not only well aware of this fundamental structural issue in their business, but are trying to work through it. I think the tactic is absolutely right, but IMHO the strategy is wrong.