[plt-scheme] Scheme contradictions

On Wed, 2006-05-03 at 00:35 -0700, mvanier wrote:
> All is not lost, though.  Ruby's pure-OO syntax is somewhat odder than python's 
> hybrid imperative/OO syntax, which may mean that people are starting to get to 
> the point where odd syntaxes don't totally terrify them.  Also, Ruby code blocks
> tend to get used in a fairly functional-programming-ish manner.  Finally, Ruby's 
> growth has largely been driven by its "killer app": Ruby on Rails.  Maybe we 
> need Scheme on Rails...

I'm not sure if I fully agree with this sentiment. Some syntax in Perl
is plenty weird looking and yet Perl is not an esoteric language. I do
think that the lack of a definitive implementation and a killer app in
Scheme have more to do with this. A lack of a standard and simple module
system hurts too -- Python and Java got this pretty right, it made the
easy things easy, as they should be.

On the other hand, I think that the relatively newly expanded PLT FFI
(in 300) is something that will do much to alleviate the situation of a
lack of "killer apps"; there's a lot of good stuff out there that can
now be more easily leveraged in PLT Scheme.

It would be nice if the opposite arrangement (eg, Python calling mzc
compiled native code) were just as easy. Right now it's a bit of a pain
out of the box to embed the interpreter with a program and provide
interfaces with simple, non-PLT specific data types involved. I am being
slightly selfish here; such a feature would be useful to me personally
to package the infrastructure around a numeric code so that other
numeric codes -- often written in C or FORTRAN -- could use them. There
is most certainly a world where it's just too much trouble to write
programs in anything but C, no matter how masochistic it is. 

This also means someone who just happens to prefer another language for
a given task would then be free to use my code via FFI.

In any case, Gambit-C has features to accomplish exactly this, but the
PLT package has impressed me the most with its commitment to polish*,
and I hope that will one day also have this functionality.

df

* Many polishing agents are abrasives, and this may explain why so many
projects don't get very much.