- Different World Image-based development is strange to most developers. Also, Smalltalk forces developers to drop all of their pre-existing tools to play in this magical world. It's a lot to give up.
- Different Syntax Smalltalk's syntax baffles a lot of developers because it's so different from anything else. Most of what they have seen has been Algol-based. But, I've never seen a developer not understand it within a few minutes, but it is a hurdle for folks. This hurdle will always be there. Changing the syntax would make Smalltalk not Smalltalk.
- Unwillingness to compromise Smalltalk is powerful and the integrated tools is what makes it powerful. But, a little compromise to help developers dip their toes would help. At least allow to have some sort of training wheels before they jump in all the way. We need to allow them to test the waters.
But, the new obstacles along with the old ones are:
- We no longer have the largest library It's incredible the amount of open source libraries that Java and Ruby has. It's especially true for Java. It's enormous. Anything I want and it's been done. From database mapping to GUI to XML to you name it, it's just a source forge click away.
- Dated All dialects besides Dolphin look dated. There's no pizazz and simple things like consistent key bindings are not there. It's all a matter of polish and it shouldn't matter, but it does to a lot of developers. Sad but true. Looks matter.
- Tutorials There has been movement in this area recently in both Squeak and Visual Works. It's great and we need more.
- Marketing All of the Smalltalk web sites look old. Some graphic designers would go a long way. Ruby on Rails got to the top of the heap and exposed Ruby because of great marketing. I was programming in Ruby before Rails and it had none of the benefits of Smalltalk. We have a strong community, but marketing wins. Java kicked our butts once and at the time, we had the best libraries, environment, and everything. Marketing is king.
Now, that being said, I think a better looking Squeak, VisualWorks, and VisualAge is a must. I think they should all look at Dolphin. Dolphin is everything a modern Smalltalk should be. It's gorgeous. The key bindings are consistent, tools are easy to understand, and it's a pleasure to work with. They are also constantly adding new tools to help productivity (IdeaSpace) as well. In fact, I usually show developers Dolphin first to get them interested.
I think a good looking GUI is the first step. But, I also think making it easy for developers to use Smalltalk as a scripting language is a must too. We need to allow for developers to ease into image-based development by using their own tools. Yes, they will be less productive, but consider it to be an olive branch somewhat.
If we are to get more developers interested, we must come a little to them. I tried writing a scripting like environment for Squeak to make it easier for developers outside of Smalltalk to code in a more scripting style. And I keep playing with syntax to keep the simplicity, but also things to developers from the outside more comfortable.
And last but not least and this is a deal breaker: libraries. Seaside is a huge advantage, but we need more libraries that not only do cool things, but practical things as well. We have a lot of growth needed in this area.
The Ruby community has done a great job at showing off what you can do with pure objects and closures. Now, let's make it easy for them to see why an image and integrated tools make your live easier! We need to get off our island and start mingling with everyone. I created the Omaha Dynamic Language User's Group in the hopes to show developers what makes Smalltalk great(along with other dynamic languages as well like Lisp).
Posts
1 comment:
I've started doing some development in Dolphin Smalltalk, and I've really enjoyed your blog. I think your comments about what is needed to market Smalltalk are very accurate, though they do slightly shame me. I usually program in Cocoa on the Mac, and my reason for using Dolphin is that it is fairly close to that experience. I would not be even trying it without Ted Bracht's Dolphin Companion book. I really do need more tutorials, especially on middle-level stuff. I'm just nowhere near the kind of programmer you are. For example, I first came across your blog looking for ways to do "Undo". You suggest looking at the Command class. It will probably take me about three days to work it all out, I'm that slow. I got so depressed about the whole thing, I'm ashamed to say I started looking at the prices on RealBasic, Delphi -- then I looked at the code itself: I just couldn't use that.
So I guess you could say my taste is better than my brains, and Dolphin is something of a struggle for me. I think about half the struggle, though, is actually learning how to learn. I learned both Python and Ruby quite quickly, because it was obvious how to learn them. I've accepted the idea of looking at the code in the image for clues, but I still struggle with how to do that. A tutorial on that, like a "deconstruction" of a learning process you have gone through would be a great help.
Thanks for the blog. It's amazing to me still how captivating the world of objects can be.
Post a Comment