The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Software development selections

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Software development selections Posted: Feb 27, 2004 10:29 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Software development selections
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.
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Advertisement

I've been thinking about this post by Joel Spolsky again - I posted on it last night before I went to bed, but I didn't really go into the topic that deeply. Joel asserted that developers have tried Lisp (the same argument extends to Smalltalk) and rejected it in favor of things like VB, C , C#, and Java. This is an argument I've heard many, many times. The problem is, it's completely bogus. First off, most developers haven't actually tried (insert niche system here). One of a small number objections come up, either from developers or from management:

  • We won't be able to find any (blah) programmers!
  • That technology is very old (never mind that the libraries are up to date)
  • I would rather work in (insert mainstream language here), so that I can stay marketable

Notice how none of these are actual technical arguments. The first two would be reasonable management issues if they had validity, but they don't. First off, go find a developer. Ask them how many software development languages they know, and then ask how hard they find learning a new one. Heck, if newness alone was a barrier, then neither Java or C# ever would have taken off.

The objection is often this: "If we build a Smalltalk application, and our developers leave, what then?" Well heck, what if you build a Java application, and your developers leave? Sure, there are more people who know Java - but that's not the hard part. How many developers are you going to find who know and understand your business domain? If you had a choice between hiring:

  • Someone who knows your problem domain, but doesn't know the implementation language
  • Someone who knows the implementation language, but doesn't know the problem domain

Which one would you hire? The better answer would be the first person - learning the new language will take a lot less effort than learning the problem domain. Many IT managers don't actually believe that, even if they say it - that's clear from the way they hire and the way they decide on implementations and rewrites. It's equally clear that business staff (implicitly) think differently - the knowledge staff that handles business issues is typically not full of candidates for outsourcing.

Let's go back to the other part of Joel's assertion - that "millions" of developers have tried (Lisp, Smalltalk) and rejected them. That's just silly. Sun claims that there are 3 million Java developers. Most people think that VB has wider penetration, and I'd guess that C is on the order of Java. Then there are niche languages like Smalltalk and Lisp - millions of developers have tried them and rejected them? I don't know about IBM's VAST numbers, but I know that we get an average of 1000 or so people downloading VW and OST Non-Commercial per month. Even if every one of those people actually took a serious look at the products, that's in the low tens of thousands per year (and some of these are repeats - people picking up newer revs). Back in its heyday (pre-Digitalk merger), ParcPlace was a $40 million dollar firm, and I recall that we had estimates of actual end developers in the low tens of thousands. Digitalk was something like a $10 million dollar outfit, but likely had at least as many (possibly more) actual users. VAST was bigger, but not significantly so. Those numbers went down in the late nineties, and have now started to go back up again. Does that qualify as "millions" of people having tried Smalltalk and rejected it?

Like many other things, software development is a popularity contest. There is perceived safety in numbers, and the C language family has become that "safe" haven. This has nothing to do with quality or productivity - it has to do with the fact that C was a good choice for development early on (given the state of the art in processors, disk and memory) - and that advantage built up higher through inertia and the creation of a large "installed base" of people who knew the language. C , Java, and C# benefit from this familiarity, and VB benefits from the widespread early deployment of Basic on PCs and University systems.

That's not a rejection of Smalltalk or Lisp, at least not in the way Joel implied. It shows that the early "winners" in the language derby gained a large advantage in terms of mainstream adoption. It says nothing about how hard it would be to use a niche language, even though many people (especially IT project managers) read it that way. As I said above, training a new developer in Smalltalk is a whole lot easier than training them in your problem domain. Having developers learn Smalltalk is not a hard thing - just ask them. Bottom line - if you make the statement "Yes, Smalltalk is more productive, but..." - just eliminate the latter half of the statement.

Read: Software development selections

Topic: Jon Udell misses on formats Previous Topic   Next Topic Topic: Conspiracy, or something simpler?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use