How NOT to market your favorite programming language

My dislike of Java is probably at least as strong as that of Obie Fernandez, but his blog post attacking Java is simply not an acceptable way to debate the matter. [I was alerted to this post by Blaine Buxton].

The author is also flat out wrong on a few major points, most notably the importance of good dev tools. I've found that the better the programmer, the more good tools help: They amplify whatever you've got to give. And I'd take a great programmer using Java over a poor one using any other language. The "dirty little secret" of IT is that quality of personnel matters far more than tools.

---

• Chronos blog home page
• Chronos Date/Time Library web site

How to market a dynamic programming language

The Ruby on Rails community has provided us with a canonical "how to" for marketing a dynamic programming language: Ruby on Rails vs Java.

Where's the Smalltalk version?

---

• Chronos blog home page
• Chronos Date/Time Library web site

Smalltalk Considered Unfriendly

Eric Dobbs' blog post (Playing Nice - what Perl's got that LISP and Smalltalk lack) hits the nail on the head: Smalltalk and LISP have not been as successful as Perl because LISP and Smalltalk want to be independent universes, hermetically sealed off from the rest of the world:

There's always been only one Perl; differing versions, sure, but you have never had to spend any time choosing whose Perl interpreter to use. More importantly, Perl began with the assumption that it would not be the only tool in your toolbox: it set out from the beginning to play well with others. By contrast, there have always been many flavors of LISP and Smalltalk any of which have tried to be pretty much everything you ever need.

Painting in broad strokes, David says Smalltalk's weakness is "at the boundaries:" when you want to try to do some typical unix system maintenance, or interfacing with underlying C libraries, or something similar. As long as you're staying within the Smalltalk environment, it completely rocks. But it's definitely painful if you try to reach outside. And it's especially painful if you want your code to work with different Smalltalks. What Perl got right was making it completely painless to integrate with its environment.

In some sense LISP wants to be on a LISP Machine and Smalltalk wants to be in its virtual machine, whereas Perl wants to go out and play with the other kids. The former languages are introverted and Perl is extroverted.

But, as Eric points out, that raises the question: "Why is Java more successful than LISP and Smalltalk?" After all, Java also wants to do everything itself, in its own idiosyncratic way, instead of relying on the host platform.

My answer: Java has not been as successful as it could have been, had it not been so fixated on always defining its own, separate culture (e.g, libraries, protocols, architectures, standards, etc.) And Java has peaked. It is losing ground against its competition, not continuing to advance. It owes its initial success to several unique factors, none of which are anywhere near as important as they were ten years ago: a) C++, b) the internet revolution, and c) the backing of Sun Microsystems, Inc. Java is now a legacy programming language, and its future will unfold in accord with that status.

Note that the languages that are beginning to overtake Java don't suffer from Java's antisocial attitude: Perl, Ruby, Python and C#. Yes, C#. Sun's strategy with Java was "same language, same architecture, same libraries--on all platforms." Microsoft's strategy with C# (and the CLR) is "any language, same architecture, same libraries, at least on Windows, and we're OK with others duplicating the CLR (and .Net) on other operating systems."

But I would also note that the the CLR, although it is better than the JVM at support for multiple langauges, is nevertheless not as friendly as it should be to deeply dynamic programming languages. That's one reason that the CLR-based languages aren't quite as "hot" as Ruby, Perl and Python.

Society is based on the theory that cooperation and collaboration are superior to conflict and confrontation. Peace is better than war. Friends are better than enemies. But Smalltalk and LISP have been trying to succeed as anti-social hermits, alone on their respective mountaintops (or up and away in their lonely balloons.) In the long term, I don't think that approach is likely to succeed. Smalltalk and LISP need to learn how to "play nice."

And there are two sides to "playing nice":

1. Being willing and able to request services from your neighbors
2. Being willing and able to answer requests for services from your neighbors

In other words, interoperability is reciprocal. You have to be able to play the role of a "broker," someone who "makes a market" in some set of services or commodities. That means you have to be equally willing to buy (make requests) or sell (respond to requests.)

From the point of view of the outside world, to the extent that Smalltalk and LISP provide any interoperability at all, it's almost all one sided: Smalltalk and LISP may deign to request something, but they don't offer any services in return. Unless and until that changes, I don't foresee either Smalltalk or LISP making much forward progress in the marketplace.

Of course, it's not that simple. There are really strong and compelling technical reasons why Smalltalk and LISP don't offer services that are easily consumable by foreigners. And there are also strong and compelling cultural reasons why Smalltalk and LISP prefer to build their own services and tools, instead of using the "community standard" services. The future of the two languages will depend on whether Smalltalkers and LISPers see these facts as reasons to do nothing, or as challenges to be overcome.

[Post Script:

I don't whether this is a direct response to my post, but Cincom (the folks behind VisualWorks) are making significant improvements to the ability of VisualWorks Smalltalk to "play nice" with other languages—as described in a blog post by James Robertson, the VisualWorks product manager: Better FFI all the way around]

---

• Chronos blog home page
• Chronos Date/Time Library web site

Comparative Examples: Chronos/Smalltalk vs. Ruby

The documentation of the Ruby "Date.rb" module contains some example code for the usage of Ruby's Date and DateTime classes.

The Ruby examples, and the Chronos code to do the same things, are presented below:

Print out the date of every Sunday between two dates:

Ruby:

    def print_sundays(d1, d2)
        d1 +=1 while (d1.wday != 0)
        d1.step(d2, 7) do |date| // It's not clear whether this means [d1, d2] or [d1, d2) 
            puts "#{Date::MONTHNAMES[date.mon]} #{date.day}"
        end
    end

    print_sundays(Date::civil(2003, 4, 8), Date::civil(2003, 5, 23))

Chronos/Smalltalk:

DateAndTimeUtility class>>printSundaysFrom: startDate through: endDate
 "Left-closed, right-closed interval: [startDate, endDate]"
 | nextSunday |
 nextSunday := startDate nextDayOfWeek: Sunday.
 nextSunday 
       through: endDate 
       every: 1 
       weeksDo: [:eachSunday | 
                Transcript 
                   cr; 
                   show: eachSunday localePrintString]
############

DateAndTimeUtility 
 printSundaysFrom: (YearMonthDay year: 2003 month: April day: 8)
 through: (YearMonthDay year: 2003 month: May day: 23)

Note that instead of "startDate nextDayOfWeek: Sunday" one could also do exactly what the Ruby code does: "[date dayOfWeek = Sunday] whileFalse: [date := date tomorrow]."

The Chronos/Smalltalk output:

 April 13, 2003
 April 20, 2003
 April 27, 2003
 May 4, 2003
 May 11, 2003
 May 18, 2003

Calculate how many seconds to go till midnight on New Year’s Day:

Ruby:

    def secs_to_new_year(now = DateTime::now())
        new_year = DateTime.new(now.year + 1, 1, 1)
        dif = new_year - now
        hours, mins, secs, ignore_fractions = Date::day_fraction_to_time(dif)
        return hours * 60 * 60 + mins * 60 + secs
    end

    puts secs_to_new_year()

Chronos/Smalltalk:

| now |
now := DateAndTime now.
now secondsUntil: 
    (now 
        subtractingYears: 0 
        months: 0 
        days: now daysSinceStartOfYear - now daysInYear
        seconds: now secondsSinceStartOfDay 
        nanoseconds: now nanosecondsSinceSecond).

It should be noted that, once Chronos implements leap seconds, the Chronos code will correctly answer the number of UTC seconds--including any leap seconds. The Ruby example wouldn't, even if Date.rb ever implements leap second support. If we didn't care about leap seconds, we could instead use the following Chronos code:

| now |
now := DateAndTime now.
(Duration 
    days: now daysInYear - now daysSinceStartOfYear
    hours: 0
    minutes: 0
    seconds: now fractionalSecondsSinceStartOfDay negated) asSeconds

And there are yet other ways to do this in Chronos. A few examples:

• In one line of code:

  
  | now | (now := DateAndTime now) nextYear atFirstDayOfYear atStartOfDay secondsSince: now



• Efficient, with logic that's easy to follow:

  
  | now |
  now := DateAndTime now.
  (YearMonthDay year: now year + 1  day: 1) secondsSince: now

I should also point out that the Ruby code in the example above (as well as the last Chronos variation) would be subject to a possible bug, in the following situation: a) the current time is in the year before the year 1, and b) the calendar system in use forbids the year zero. But that's not a situation most of you would ever have to worry about. I, on the other hand, do have to worry about such issues when writing the logic internal to Chronos, since Chronos deals with multiple calendars--and new calendrical systems can easily be defined and added.

Ever want to design and implement your own Calendar?

---

• Chronos blog home page
• Chronos Date/Time Library web site

Finding the Signal-to-Noise Ratio in the Never-Ending Language Debate

Exceprt from a blog entry by Reg Braithwaite:

Speaking of Rails, I'm going to conclude with my take on one reason why Rails is taking off and Seaside is not. Rails allows programmers to express the idioms they already know (relational databases, web-backed MVC, stateless event handling plus a global session store) in fewer bits.

Seaside provides a whole new idiom, continuations, that IMO is more powerful. I think you end up with an even higher signal-to-noise ratio with a Seaside app than with a Rails app. Why? Because continuations afford you a much higher degree of controller reuse.

Now, here's the catch: if you try to imagine your current application running on both Rails and on Seaside, you probably won't see much difference between the two (although they'll both be an order of magnitude better than ASP.NET). They will look the same because you designed your application with idioms that both Rails and Seaside support.

To get a big win, you'd have to rethink your application's flow and logic. You'd have to "think in Seaside." And you're not going to do that. So you pick Rails, like so many others have picked it, because it looks just like your ASP app, only all the noise has gone away. It's all signal, baby.

Now, do you see the thing here? Ruby has been around for a while, but nobody switched. Why? Because they couldn't see how its new idioms would help them. Every time a programmer considered switching from Blub to Ruby, she was presented with all these new idioms, like dynamic types. None of this meant anything to her, because they didn't appear to make the idioms she already knew more compact. No win.

But now she looks and she sees her existing web idioms, and she sees them expressed with way fewer bits, and she is suddenly prepared to learn this Ruby thing if it will let her say:



class Language < ActiveRecord::Base

has_and_belongs_to_many :idioms

end

My take: Eventually, the world realized and accepted the fact that Arabic number notation provided a compelling advantage over the use of Roman Numerals (ever try to do long division using Roman Numerals?) But the acceptance/adoption process took decades--or even centuries.

To paraphrase Lord Keynes: "The herd can remain irrational far longer than you can remain solvent."

Ruby On Rails is a "killer app." I'm thinking it's time to learn Ruby. I also think that vendors/purveyors of Smalltalk systems should provide Ruby compilers that generate code that runs on Smalltalk VMs.

I also wonder whether anyone would be interested in porting Chronos to Ruby. Hmmm....

---

• Chronos blog home page
• Chronos Date/Time Library web site