Almost like objects
Over on the Jaybaz weblog we find out why you want real objects instead of what C# (and Java) offer:
Every so often, I see a C# user say they'd like to add a method to an enum. Maybe it's Flags and they want to verify that the combination of flags is legal according to their business rules. Or maybe they're in the process of moving to something more OO, involving inheritance instead of constants.
Maybe if they had started with objects, they wouldn't have that problem. Then again, they might pull in fewer consulting dollars that way....
Comments
Re. Almost like objects
[Steve Wart] May 28, 2004 11:08:18.211
What's wrong with consultants being motivated by how much money they are going to make? If you can't provide financial incentive to get people to use Smalltalk, what else is there?
Elegance in software development is fundamentally related to the economics of the industry. The fact that tools are actually getting less productive as technology advances is more a sign of perverse economic incentives than it is the fault of developers or consultants. Give us a break.
The question is, why are productivity metrics in IT so distorted? If you are a vendor offering a tool with economic benefits over the likes of Java and C#, the world should be beating a path to your door.
In marketing, the answer is the same as it has always been. Figure out what your customers want, and sell it to them. Don't blame them if they use the competitor's offerings instead.
Most developers are in the business of serving their customers, and most customers don't care about the technology we use. The user experience Smalltalk offers to developers is hands-down the best I've ever had. But what matters to me is the user experience of *my* customers, and unfortunately, none of them want to program. Not even in Smalltalk.
Dilbertonians
[Hmmm...] May 28, 2004 12:56:23.035
Who makes the decision to go with the complicated stuff is also who benefits from the decision. If as a corporate manager you can get a lot of money going through your department, power to you. Certainly the other managers are more likely to fail with less resources. And what if you fail? Well in that case let's disguise CRUD 101 into Rocket Science 798. Hence if you fail, if you waste tons of money on something overcomplicated, at least you can blame the allegedly inherent complexities of your project. Consultants are a manager's way to buy ass armor. It so happens that the real task in most cases is simple to begin with. Especially after you spend real gray matter time on it.
Smalltalk is difficult to sell in this scenario. Because, just as for us developers it shows how little we understand something until we're done implementing it, it will smear the manager's own ignorance and lack of understanding in his face. No manager wants that when the goal is his american dream. Therefore, as a manager you have to choose something complicated, something that will make engineers will cheer when the record they just saved comes back from the database. Disguise it as a challenge, do a presentation to them using a solved example from the web to show them how simple it is. Then throw the gauntlet. Engineers will thrive under this challenging environment as long as you don't push too hard. Happy engineers don't complain to their boss about stupid assignments. And if everything goes to hell, the developers are to blame: obviously they have been all excited about small accomplishments all this time!
As long as we're stuck in this rat race, as long as we can't see that eternal exponential growth can't happen, and as long as we are unable to shake ourselves off consumism, we're doomed. In Monopoly there's only one winner. We don't even see what happens to the losers. And when there's only one left standing? After the victory lap ends, what? Apres moi le deluge.