Sunday, August 05, 2007
Why Smalltalk will always be a second-class language...
Let's enumerate some reasons why Smalltalk will remain a second-class language:
- Microsoft didn't invent Smalltalk, IBM doesn't push it and Oracle doesn't support it and therefore Enterprise Architects can't incorporate it into their power vendor strategy
- Smalltalk is simply too hold. Enterprises sometimes choose the latest and greatest because it helps motivate their staff and not because it is the best tool for the given problem. This is why I believe Ruby on Rails will succeed.
- Smalltalk is slow compared to other first-class languages such as C++ and Java. Developer productivity is great in Smalltalk but developer productivity should always be a second-class concern over runtime performance
- Smalltalk is not open. Have you ever heard of any of the Cincom bloggers championing Smalltalk implementations should all be open source?
- Smalltalk is defective in that it only supports the Object-Oriented paradigm. Sometimes procedural, declarative, rules-driven and other approaches make better sense
- The vendors in the Smalltalk community are greedy and for the most part filled with employees that are idiots. Have you ever witnessed coopetition in the Smalltalk community amongst its major vendors to build marketshare? Maybe they could learn something from the Java community in this regard
- No convincing examples of enterprise applications. Pretty much ever person in the Java community is familiar with the J2EE Petstore. What is the equivalent in Smalltalk?
- No library support for modern security considerations such as supporting OpenID, CardSpace, XACML and so on
- No ability to write simple standalone applications. You can write a small application in C++ and/or Java, copy it onto a USB and give to someone else to run on their computer. You can't really do the same with Smalltalk
Links to this post: