Re: Multimedia in DrScheme

[Paul Fernhout <pdfernhout@kurtz-fernhout.com>]

John Clonts wrote:
> 
> Paul Fernhout wrote:
> >
> [snip graphics pointers]
> >
> > It's a shame to see so much duplicate work required to maintain various
> > platforms in various projects -- all essentially similar effort
> > requiring substantial time by good people. Also the effort by all of us
> > to learn all these open source platforms (Squeak, DrScheme, GForth, what
> > have you) just to have a choice oof languages. I downloaded the DrScheme
> > source (6 Hours CVS!) and it's basically a forked version of wxWindows
> > from several years ago -- and so a maintenance requirement -- although
> > I'll given Matt and others here lots of credit for keeping it stable and
> > useful on the major platforms, and they do show a strong commitment to
> > supporting it. However, it's opaqueness (being compiled) means one has
> > to rely heavily on the HelpDesk for getting API information. I think the
> > HelpDesk in DrScheme if fabulous -- Squeak could benefit from something
> > like it.
> >
> > I would love to see an open source Scheme, Smalltalk, Pascal, Forth,
> > etc. all using a common core, with native FFI interface functions,
> > native code generation as desired, and also good emulated widget set for
> > a simple common core API. Multimedia functions should be near identical
> > from any language you choose to use on this platform. Hope we get there
> 
> Hey, you mean like Common Language Runtime , ".net" :)

Shriram pointed out the same thing privately.

Yes what Microsoft proposes sounds like a good idea -- for someone else
to do in an open source way.

The problem I have with a Microsoft Common Language runtime is:
1) it does not exist in a final form yet
2) even if it did, I expect it to be proprietary at the implementation
level (likely producing another Java situation where people reimplement
it with different code on different platforms, leading to a host of
compatability issues).

Obviously if Microsoft releases the source under say the SD-revised
license and it is well written, I would jump on it. I think that
extremely unlikely as it might undermine their Windows monopoly by
making it easier for Linux and the Mac to have equivalent software by
making cross-platform development easier.

But yes, to an extent C# for example is supposed to provide a portable
assembler (like the earlier C-- effort). How portable the APIs in .NET
will be is another question. Given Microsoft's past history, I don't
expect .NET to turn out to be something really open or really
cross-platform (except perhaps long enough to damage Sun/Java?).  On the
other hand, Microsoft is making a commitment to XML, and that surprised
me (since it in theory it might erode the Microsoft Office monopoly or
contribute to other cross-platform activity).

Personally, I'd like a language API to give me a standard FFI interface,
including a way to generate machine code and call it, (and for
convenience, an optional platform independent way to blit bits on the
screen, get user input, and do reliable networking -- and maybe a plugin
interface). All the rest can be added -- for example, sound as FFI. And
give me exception handling and modularity in the language, and again,
everything else can be added. (Stretching things a bit of course...
Obviously just to start, APIs for memory allocation and knowing what OS
you are on would all be probably needed as basic common cross-platform
APIs.)
 
Linus Torvalds got it right when he said get the interface right and the
implementation can always be improved -- but that interface is
practically set in stone because of all the callers. Perhaps we need
better interface layers to build our open source languages on?
(Something above an OS but below a typical stand-alone language).

Of course, the language standards that evolve on top of that better base
are things one would hope would become stable (like Scheme became a
stable standard -- although I think still suffering in the areas of
exception handling and modularity as a standard).

To bring this back around to DrScheme before getting too Off-Topic, the
issue is being able to leverage off of work by other open source
developers. For example, Squeak developers are doing lots of work to get
sockets to work across all platforms -- yet witness the recent issue
with DrScheme sockets under Linux. And obviously Perl, Python, and TCl
programmers all are writing socket code for numerous platforms. If all
that effort could be pooled, what wonders we might see. Think on the
story of the "Tower of Babel" where people were made to speak different
languages so the tower could never touch the heavens. I'm not suggesting
everyone program in Scheme -- just that to the extent possible, open
languages could share many facilities -- especially ones related to
cross platform bitmaps, sound, networking, file access, FFI, plugin
architecture, native widgets, installation, documentation viewers, maybe
some memory management, OS interface calls for processes, and so forth.
Note this is also different from saying everyone should just use Linux.
Obviously there may be some performance issues if one has to add another
layer isolating language and runtime libraries, and various language 
implementations have their own expectations about threading, garbage
collection, memory allocation, and so forth.

Actually, in choosing wxWindows I think the DrScheme team made an
excellent choice of what is/was available. wxWindows is one of the best
cross-platform libraries going. And there are interfaces to it from
other things -- like Python. There are only two issues: 
1) customization of an earlier version produced a fork that requires
work to maintain [and if I look at this from the point of a commercial
developer I might need to maintain it myself if I use it in a
project and the core DrScheme team moves onto other stuff in years to
come]
2) that the lower level needs to be supported in C and not something
elegant like Scheme.

I wonder what wxWindows would look like if it had been designed to serve
as a "Common Language Runtime" for Scheme, Python, etc. instead of a
windowing library orginally for C/C++.  SDL (Simple DirectMedia Layer)
is a similar effort, and bindings exist for several languages (not yet
Scheme that I saw):
  http://www.devolution.com/~slouken/projects/SDL/
If one was going to add multimedia (and emulated widgets) to MzScheme
and not use wxWindows as MrEd does, SDL would be an interesting choice.

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com