9:15 - my talk is over, and Girorgio is up talking about promoting Smalltalk for shops that use 4GLs. So - we know what the advantages of Smalltalk are - how do we transmit those to new customers who think that curly braces are where it's at? We need to promote newer examples (BottomFeeder!) What about the "ordinary" requests: The standard DB oriented CRUD apps that people need "immediately". Here's Giorgio:

So you've sold these guys on the power of Smalltalk, but can you show them that the "simple" stuff is actually simple? Heh - it often seems that we (Smalltalkers) prefer to get complex requests so that we can show off our meta models, etc. When they see us defining classes in a browser, defining instance variables, defining setters/getters.... it starts looking complicated. Then we go into the GUI Builder - bearing mind that the 4GL shops are used to having things generated up from the DB schema (this may not be a good answer, but it sure looks good).

So, the standard IT shop can do the simple stuff gets done very quickly with these tools. That gets translated up for other things (and Smalltalk is hardly the only thing that runs into this). They probably got a Java demo, and thought that looked too hard too. The point is - if you can't do the really simple things quickly, then you don't even get to enter the race (these are places that are currently ruled by FoxPro, VB, et.al.). Yes, those "simple" apps get complex and the 4GLs fall down. It doesn't matter - they started there because they weren't convinced by what you showed them.

So - Giorgio has built a lot of tools (more involved versions of the slam demos I did when I was an SE) that allow you do the simple things quickly - simple data mappers that generate code and UI elements. What Giorgio is showing looks a lot like what I did back then, actually (mine were not much past demo-ware - Giorgio is using his stuff in real applications). He's got the goods - generate a form, have it handle the CRUD functions.

The good thing - underneath the generated forms and code are domain objects living on top of an object/db mapper. That means that a developer can take the results forward without being trapped in the "it's all GUI" problem. So it all goes like this:

1. create an application definition file called default.ini, which defines the mapping
2. Execute this: BasicApplicationSystem initializeSystem
3. Run the application like this: PhoneContactView new openMaster
4. Total time spent: 1 minute

That allows Smalltalk to enter the race against 4GLs, by making the simple stuff simple. We can then demonstrate where Smalltalk adds value that the 4GL can't - but we had to get to that point first. Giorgio's system also handles non-trivial examples that have more complex object/relational links. As well, you define your domain objects and generate a database schema from that.

He's made it all pluggable, allowing pre/post actions for objects on db actions (CRUD). All looks pretty good - it's a professional version of the hack work I did for demo purposes as an SE. The difference being (again) - that Giorgio's stuff is in actual production use and works there. Now there's a demo - it's pretty cool stuff - and the db mapping code works across VW, VA, VSE, and Dolphin. He's also got a C# version. He's interested in Pollock first, and possibly GLORP after that.