Re: scsh in PLT Scheme?

["Brent A. Fulgham" <bfulgham@debian.org>]

On Sun, Mar 31, 2002 at 09:04:24AM -0800, Alex Peake wrote:
> You raise a perspective which is interesting. Suppose I move to the world of
> POSIX:
> 

Alex, as others have pointed out, POSIX is not really the same thing as
.NET or even Java.  It's a standard set of operating system services,
such as ways to access files, open sockets, send datagrams, etc.  There
is nothing special about the Windows API (which I work with every day)
that would prevent it from implementing a POSIX interface (such as
Cygwin or other tools already do.)  There are some differences (e.g.,
POSIX's 'fork' versus Windows 'ProcessCreate' that might be harder to
bridge, but others are virtually identical aside from naming.

> * How would I then deal with connecting to RDBMSs? Currently I use
> (Microsoft) ADO (COM) to connect with MS SQL Server. I am assuming that the
> best I could do is some low level connection to Oracle, or perhaps DB2?
> 

ODBC would be one option.  Another would be to create a Scheme
'standard' similar to Perl's DBI, or Java's JDBC that would make our
software platform-agnostic.

> * How would I integrate with Message Queueing? Currently I use COM and MSMQ
> 

This one is harder.  I know IBM's MQSeries can interoperate with MSMQ
(though I'm not sure of any Scheme support).  I've never given this one
much thought.  We did some initial benchmarking with with MSMQ on our
financial system and eventually dropped it due to various performance
bottlenecks.  This is possibly due to our architecture, but ever since
then I've basically ignored this technology.

> * What would I do for a User Interface? Currently I use (in addition to Web
> Browsers to which the answer is easy) Visual Basic forms with lots of OCX
> (COM) user interface widgets (smart grids with built in drop downs,
> toolbars, calendars, ...).
> 

POSIX really says nothing here.  Under PLT we obviously have the MrEd
toolkits, though not much in the way of a GUI-builder.  But to be
honest, Alex, I have found GUI-builders to be more trouble than they are
worth.  You may have seen the same thing I have -- GUI builders allow
people to quickly throw together applications, but the design is very
muddled.  In review of code I constantly find display widgets with
business logic deeply ingrained, components with deep cross-dependencies
that prevent any kind of meaningful code modifications without
rebuilding the entire world, etc.

Although, I do admit that it's nice to have access to useful tools like
TrueGrid, etc.  However I have spent months dealing with "DLL Hell"
caused by various third-party widgets being upgraded by other software
on my clients' machines causing our software to break, etc.

> * What would I do to program in the Web Server environment? Currently I use
> Active Server Pages. I assume it means using PLT Web Server, or else Apache
> and CGI or mod-xxx?
>

Again, ASP does not share any ground with POSIX.  We are (IMHO
unfortunately) using ASP for a lot of our new products.  I say
'unfortunate' because we are too tightly bound to IIS-specific
functionality.  I would much prefer a system that could work on iPlanet,
Apache, and IIS.  Portability yields better design and better financial
position (due to the ability to change suppliers as needed.)  Apache
provides an ASP module, so you can continue working as you are used to,
though not in Visual Basic.  If you use JavaScript, Perl, Python, Common
Lisp, or even GUILE you can do ASP on Apache in those languages.

> * What would I use for email? Currently I use a COM object.
> 

Do you mean to interoperate with Exchange to allow "Mail To" support or
something?  If so, I can't really answer this.  Microsoft does not
publish specifications for interop with Exchange, so it's not really an
option.

On the other hand, if you just want your application to be able to send
e-mail, it's no trouble to send e-mail from Scheme (or even any
standard UNIX program) using any of a number of standard SMTP libraries
or utilities.

> * What would I use for XSLT? (XML seems well covered in Scheme!). Currently
> I use MS XML COM.
> 

There are at least three top-quality Java implementations.  Plus one
Perl implementation, two C++ versions that compile on AIX, Linux,
Solaris, etc...

> * Would Scheme integrate with all of this in a consistent way (as COM does
> now and soon .NET will)?
> 

Currently POSIX doesn't specify these interconnections.  However, there
is nothing preventing you from using true standards such as SMTP, POP3,
XML-RPC, SOAP, etc., to do much of this.

> Where I am coming from, is that I have been on an almost two year intensive
> research following the trail of "there has to be a better way". (I develop
> large business applications - Web Commerce, Warehousing and Order
> Processing, ... I am driven to delivering good business solutions cost
> effectively.)

Then the various web-services definitions seem to be the best bet (at
least in theory).  You know the latest acronyms "WSDL", UDDI, blah blah
blah.

[ ... snip ... ]

> My conclusion? There (unfortunately) is no good solution. There are a number
> of adequate compromises. Functional languages seem to offer most from a
> language perspective, and amongst those I prefer Scheme (hence my use of PLT
> in my work). I also believe, and have practiced extensively, in generative
> programming (most of my Scheme work is here).
> 

I have been on a similar search, Alex, and also have no good answers.  From what I can see, the best choice right now is Java.  My company elected to go with C#/.NET.  I disagree with this choice, because:

1.  Lack of knowledgable development resources.
2.  Lack of historical background and industry 'best practices.'
3.  The (debatable) improvement over Java and the JVM is not large
enough to be worth the risk of retooling everything around this new
technology (at least yet).
4.  Vendor lock-in to a single supplier.

Another large reason I objected strongly to this is my exerience dealing
with Microsoft over the years.  Although we are supposedly part of one
of their vendor partnership situations (in which we get access to
various technology, top-level customer support, etc.) we still have had
far too many problems with interoperation and third-party conflicts.

Over the years we have followed Microsoft from one technology to
another: Early 1990's (Windows 3.1 and VB 3.0, 16-bit C++, VBX's and custom controls), late 1990's (Windows 95, VB 6.0, 32-bit C++, OCX, COM objects, ActiveX, SQL Server), early 2000's (C#.NET, etc., etc.)

Over this time I have found that while it's easy to work with these
technologies in the beginning, they quickly fall apart as you enter the
heavy maintenance and support stage of a product life-cycle.  Since
that's something like 75% of the development effort of a product, it's a
huge resource drain when you spend days and weeks tracking down DLL
conflicts, or try to explain to a client that installing Quicken on
their desktop machine will cause their financial services platform to
randomly crash under heavy use.

The systems we have running on the back-end (AIX, Linux, etc.) have not
shared these problems.  To be honest, we keep far more draconion control
on these boxes, but I do know that upgrades and new software installs
have been far less problematic.

So, this is already too long and off-topic and I'll stop.  But please
don't assume that .NET is Brook's magic bullet.  As he would tell you
himself, there is no such thing.  And our best bet for safety, security,
and expandibility is following standard protocols and avoiding
single-vendor controlled technologies.

(And now I'll descend from my soap box).

-Brent