[plt-scheme] Look at it differently: Why PLT?

There is a lot of discussion going on here about how many PLT users wish it
would conform more closely to R6RS. As someone working in two arenas where
standards are especially important (healthcare and government), I can't help
but be sympathetic. Indeed, I'd like to be able to use PLT Scheme for
production work, and not conforming with existing standards is a major
impediment there.

That being said, everyone on this list is using, or at least interested in
using, PLT Scheme. Why? I suspect everyone will have their own answers, but
here are some of mine:

1. I like the DrScheme development enivornment. Though I could certainly use
command line tools, I find it easier to use an integrated environment.
There's nothing wrong with that. I don't know a Java developer in this
office that Doesn't use Eclipse (I used to use NetBeans, but have since
switched to Eclipse). Okay, to be fair Java has idiosynrasies making it even
more awkward not to use an IDE, but the point remains.

2. PLT Scheme provides many (unfortunately, not all) of the capabilities I'm
most interested in. Support for both web applications and low level socket
programming is a must. I frequently make use of patterns and pattern
matching (perhaps making my programming style a bit more ML or Haskell-like
than Scheme-like?) Though I haven't really made extensive use of it yet, the
unit system seems to provide a very powerful mechanism for abstraction, and
is something that I believe to be crucial for large scale applications. The
contract system is a big one. I recently received my copy of the OOPSLA 2008
procedings in the mail, and there is a paper (Dino Distefano, "jStar:
Towards Practical Verification for Java") that demonstrates how a research
prototype (jStar) is able to handle (albit awkwardly in some ways) four
common design patterns in Java. I didn't pick it up with Scheme in mind, but
I couldn't help but think about how much simpler, more elegant, and powerful
contracts in PLT Scheme are. Two additional areas with rich support are XML
and GUI development (including graphics). For me, these are both close to
being a must.

4. PLT Scheme is vital. I've argued in other forums that when a language or
framework is no longer being actively developed (and no, I don't mean just
maintenance), it is already on the road to obsolescence. There is a tension
here between the desire for standardization and stability on the one hand,
and innovation and intellectual vigor on the other. But insisting too
quickly on standardization can easily lead to a kind of "analysis
paralysis".

5. PLT Scheme is portable. It supports Windows, OS X (Macintosh), and Linux
equally, and code developed on one platform is generally portable to the
others. Time and again, we run into situations where a tool is only
available on one platform or,  even if it is available on multiple
platforms, one or more of them is a "second class citizen". Either the
newest versions of the product will not be available, or technical support
will be much more limited, or both. I really appreciate the fact that this
isn't the case with PLT Scheme.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20081119/da87b55a/attachment.html>