I recently introduced Pharo in a small-medium software company (parametrix.ch). They use it for Moose (moosetechnology.org) to analyze their systems written in various languages and to introduce an assessment approach in their day to day development process (humane-assessment.com). A number of them are now learning to program in Pharo and Moose.
Moose is a valuable platform exactly because it is built in Smalltalk. Developers understand the power of Smalltalk in the context of Moose quite quickly after they do a couple of tutorials. The result is that they end up wanting to learn Smalltalk.
In fact, I argued for quite a while that vendors should use Moose to promote Smalltalk. The cool thing about it is that it addresses directly programmers that develop in all sorts of languages (especially Java). This gives us a nice back door.
The Smalltalk success stories (at the enterprise level) come from solving problems that are very difficult to solve in the first place.
Looking at some of GemStone's customers there are two common characteristics:
- large complex problems
- problems whose domain is rapidly changing
The large problems have to be broken down into pieces that are small enough for a small team of people to attack effectively and the work of these small teams has to be integrated to address the larger problem.
This plays into the strength of Smalltalk in that Smalltalk code (and developers) can thrive in an environment where the code base is inconsistent/fluid ... For problems whose domain is rapidly changing it is a requirement that the _architecture_ of the system be able to migrate over time. As business rules change the architecture of the system has to evolve.
Again the requirement of having a malleable code base where functionality can migrate and the architecture can evolve play into the strengths of Smalltalk...
Smalltalk improves developer productivity ... pure and simple ... the reason that developing in Smalltalk is fun is that there is very little that gets in between the developer and the solution of a problem ... the debugger, inspector and all of the tools mean that a developer can focus on the problem at hand ... the dynamic nature of Smalltalk means that I can add instance variables and change interfaces without having to fight the compiler or the tools ... or lose track of what I am doing ....
With that said (here comes the rant:) ... the _enterprise_ is not necessarily interested in developer productivity...productive developers is way down the list for the enterprise ... just look at the waste (not just in software) in a typical corporation ... (end of rant) ...
Smaller companies (not at the enterprise level) _are_ interested in developer productivity, so that should be the sweet spot for Smalltalk and there is work to be done to make Smalltalk more attractive to those Smaller companies and it seems that Pharo is headed in the right direction to become more attractive ... Note that many development groups within the enterprise operate like smaller companies, it's just that a CTO of a Fortune 500 company isn't going to wholesale switch his company from using Java to using Smalltalk (at least not this year:)...
Oh and GemStone also has enterprise customers who don't necessarily advertise their Smalltalk success stories.
We must continue teaching in the universities..and why not.. The companies.. For free.... Only for introduce the technollogy in the market
We must support projects such Seaside, Reef, Glorp, SqueakDBX or Mars (and it's futures version for linux and windows). This cain of projects are the bridge from the mainstream world to smalltalk..
We must make deal's with the traditional software companies.. And don't be scare for sign a contract where the project have webservices and java, php or .net front-end. although the solution is not needed. (Obviously if you don't will be the architect :) )
We need make the peace with commercial people and the technology publications..
At last and over all, when any one from this group, have the chance, one chance, to have a CIO position, take it, and make the difference.
This one, please don't think as traditional CIO, think different.
I think an effective way to evangelize Pharo/Squeak/Smalltalk is to when anybody has the liberty to do so, use it in the small areas where the business has a need and no dependencies or any particular bureaucratic requirements.
Encourage coworkers to try it for personal projects, invite them to local user groups. Even if it is simply to explore something different and unknown. Find out some of their interests and where possible and reasonable demonstrate a Pharo solution for their interests.
I think the more people we can get to choose Pharo/Squeak/Smalltalk for personal interests, the more people will begin to use it for the jobs at work that they have the liberty to choose. Over time this could lead to understanding of the benefits that Pharo/Squeak/Smalltalk can bring to the enterprise environment or to the developers life in general. If they use it at home, they may also help to improve our enterprise story so that they can make a living using their tool of choice.