Re: [tlug] STM (was: Re: work times & accommodation @tokyo)

[Curt Sampson <cjs@example.com>]

On 2008-07-29 17:06 +0900 (Tue), Stephen J. Turnbull wrote:

> I don't think that's really a worthwhile distinction.  The blundering
> about that Curt and I have done regarding "are we talking about
> Starling or Google?" is essential...

Actually, I don't think it is. I now see that you appear to be arguing
about something completely different.

> In fact Curt and I seem to have come back to the "would agile
> programming really scale" thread; he claims that it (any of several
> "it"s ;-) would work if management would back it, and I want to know
> how to manage the scaling process.

Actually, I'm not claiming anything about agile, particularly not that
it would scale to very large teams or would be all that useful on
projects such as aircraft flight control systems.

Here is my basic argument.

    1. Some programming languages and tools are more powerful than
    others.

    2. Those who use these languages and tools, if smart enough to use
    the advanced features, will be more productive than they could
    possibly be in a language or with a tool without those features.

    3. Managers in large companies, and even small ones, often freeze
    the technology being used to less advanced forms, refusing to even
    explore the use of better technologies, and by doing this they are
    hurting their software development efforts in the long term.

My example: where are all the managers now who insisted that this
new-fangled Java stuff was entirely silly, COBOL had done just fine
for business applications for many years, and we don't need all this
object-oriented rubbish?

So, can really, really big companies change? Well, how many Java
programmers does IBM have, and how committed are they to Java?

So, does anybody care to claim that COBOL programers are, in general,
more productive than Java programmers, and moving from COBOL to Java was
all a huge mistake? Or would someone care to claim that Java in thirty
years will not be where COBOL was in the 90s, and that we've hit the
plateau of language development? Or that five years from now you can
start your company on its first steps in a new language or set of tools
and it will rapidly catch up with companies of similar size that have
had people experimenting with the language or set of tools for five
years?

Perhaps one area where this mistracked some people into thinking about
agile practices was when I mentioned that the groups doing deployments
seemed in part to blame for the blockage, with the excuse that they had
vast experience deploying Java apps (or whatever), but didn't have the
infrastucture for stuff developed in language/tool X. I merely pointed
out that they ought to be developing that, too. That's far from the
agile practice of having developers deploy their own stuff, and I wasn't
claiming that they should even start down that road.

> ...and note that Haskell and GHC have pretty tight processes a la
> Scheme SRFIs and Python PEPs: STM wouldn't be a part of Haskell if it
> hadn't proved itself as a best practice to some extent.

Well, do keep in mind as well that STM is just a library. There's
a lot of stuff in Haskell that looks special, the biggest example
being monads, but those have almost no special support in the language
itself (aside from a bit of fairly generic syntatic sugar in the "do"
statement), and are just libraries written in the langauge. This is not
at the level of Java's "synchronized" primitive, for example; it's more
like one of Java's collection libraries.

And again, I'd like to point out, underneath it all, where there
does need to be some special stuff (synchronization primitives),
it's not doing anything different from anybody else. STM's TVars,
the standard library's MVars, and the various blocking queues from
java.util.concurrent are all the same thing. STM has been implemented
before in other languages. The key difference with Haskell's STM is the
type checking, and that's something that the language itself offers.
Using the same kinds of tools and libraries as other languages use,
Haskell can let you do things that other languages won't.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com