This post originated from an RSS feed registered with Agile Buzz
by James Robertson.
Original Post: Better, or Worse?
Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants
Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml
Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general.
I have much the same feeling. The one thing that I wish was different was performance. I know that Python is supposed to be for gluing C apps together, but I just did a little hacking on Kai Hendry's LuPy version of my Lucene plugin for pyblosxom, and it wasn't pretty. I wasn't sure that LuPy was reading the Lucene index files right, so I decided to reindex using a LuPy based indexer. Talk about slow.
I find this all kind of frustrating. I can say that I am vastly more productive in VisualWorks now than I was a few years ago - the tools are better, the language is better. Performance is much better - and you should see this talk at StS for info on how it's goiig to get better still. Smalltalk has evolved quite nicely, thank you very much - and I'm sure that the various Lisp tools have as well, although I have no real experience with them. There's actually fairly vigorous competition in the Smalltalk space, because we have multiple vendors - we get various takes on what works and what doesn't, instead of what Sun knows is best or what Microsoft knows is best. Why is Eclipse boring? Perhaps it's because - unlike Smalltalk and Lisp - it takes no advantage of being written in itself. You can't modify the environment, or even ask intelligent questions of it. Being able to do so is what leads to productive tools. Python doesn't quite get there, because - as a scripting language - people tend to use things like vi and emacs to develop. Productivity simply does not lie that way.
So what is this collective blind spot in the developer universe? Is it the siren song of Open Source and free tools? Are developers thinking that if its not free, they won't use it? That's part of it, I'm sure. And it's an interesting problem. certainly those same developers don't want to work for free - they want to be paid like everyone else. This leads to this theory: You should make money from consulting, not from the tools. To which I respond: Why?. You do realize that under that theory, small shops are pretty much locked right out? You need a certain scale in order to have a bunch of developers and a bunch of consultants. And before you say that the developers should be the consultants - not every developer is really suited to a customer facing position. Does the developer community really want to write off all the potential tool builders who are unwilling or unable to be consultants at the same time? Apparently so.
I think a lot of developers need to wake up and realize that "free" tools largely means bland, corporate tools - and bland, corporate languages. It takes a large outfit to be able to treat tools as loss leaders - leaving little room for small to mid-size outfits that might want to concentrate on different approaches. Even in curly brace land, all the interesting tools have been acquired (and then mostly disappeared). People seem to recognize that you get what you pay for - right up to the point where they select development tools. Then they expect a handout. If we stay on this path, we'll keep right on down the road described by Larry O'Brien.
Previous Topic
