I really, really do get absolutely everything you are saying about text vs. graphical programming in terms of code manipulation productivity and religiosity of editors and all that. I get it, I’ve lived it. I used Emacs for 20 years(!) before switching to Eclipse (and now SBStudio as well) as the heart of my day-to-day development toolset.

And I still say: just try Event Flow for a while. Suspend some disbelief. Try not to make up your mind after just a couple days. It’ll pay off.

It’s not apples to apples in terms of overall productivity. It’s not always “how fast can I manipulate the commas for these 97 fields?” Some days it is, “I just shortened what would have been a 3 hour meeting to 5 minutes because I could point the Business Analyst at the Event Flow graph and it was just obvious.”

So it’s not really one or the other . . . it’s both. It’s why we have both. The tension between them is still playing out.

-Steve

The real problem I see with the graphical approach and programming in the large has to do with a complex project with multiple developers working out of version control. Since the XML files produced by the graphical approach encode metadata about the position of nodes and the like, it would make it cumbersome for multiple developers to work in the graphical environment. Consider the case where you create a graphical application and checking it in. I check it out and rearrange some of the icons to suit my tastes but make no other changes. Meanwhile you do the same. We will each have version control conflicts even though neither of us has made a change to the semantics of the app.

Even if you guys develop a way to separate the graphical aspects from the semantic aspects, the text approach will still be superior to a “real programmer”. Cut and paste, search and replace, regex matching, syntax highlighting, completion, and the like are all things developers master in their favorite editor. I type with just two fingers but code as fast as any developer because I have mastered my preferred editor. This is one reason why profession developers are so religious about there editor of choice.

Finally, there are some places where your present graphical environment is less helpful than it could be. I often find myself having to type in places that in theory the tool could offer a drop down of choices. I’m sure the graphical environment will improve as you guys mature the tool.

Your other points about modules and the like are good and they show that Streambase put a though into some important aspects of programming in the large.

Glad you enjoyed the class, and thanks for the write-up.

I work for StreamBase as a Services Consultant; I’ve been doing little else besides developing StreamBase applications, client, and plugins for the last 2.5 years. Yeah, yeah, I guess I’ve drunk the Kool-Aid, but on the other hand there aren’t many people in the world with more StreamBase application development experience than I have.

A few comments on your notes:

Yes, it’s true that the current StreamBase SBStudio IDE doesn’t have source control repository integration. But it does let you define a project whose local storage is external to the StreamBase Workspace. Which means you can use any external source control tool to manage SBStudio project files. On Windows, I personally find SBStudio and TortoiseSVN to be a nice combination. That’s not to say it won’t be a great day when SBStudio source control integration is released. But the lack of it shouldn’t give you much pause.

Second, I totally get what you’re saying about StreamSQL (the SQL-like text language) and Event Flow (the graphical language). Lots of people new to StreamBase think that they will like one or the other better. But I encourage you to give them both a chance. You may be surprised, and you may learn that “productivity” is a more nuanced concept than you now think . . . . Fortunately, with StreamBase you get to use either or both of the languages and you can use both in the same application if you want.

In terms of elevating productivity in Event Flow, check out the Save Schema and Schema Copy features of SBStudio. I tend to use the Saved Schemas View like a cut/paste clipboard for StreamBase Schema. These are often the unsung heroes of my development day.

In terms of encouraging “development in the large” in Event Flow, think on these 3 features: Modules, Module Reference Input Schema Overrides, and implicit-mode Operators. These things together make it possible to design segmentable applications that are resilient to schema evolutions, not to mention module reuse between projects. These features have analogues in StreamSQL, as well.

Have fun!

-Steve