On Fri, 24 Aug 2012, Michael Moeller wrote:
Although 'features' are in vogue, SML is well advised to resist. Of
course it's nice Poly/ML connects to the net, for example. On the other
hand I won't like to see it choked by tons of libraries turning a small
nice language into a bloated software monster which can do everything.
It surely is a matter of taste what's worth to be kept in a new library
and what's up to the programmer. Keeping things clean and simple never
did any harm. Think twice before proposing a new feature an experienced
programmer is able to develop by himself easily.
I also subscribe to this.
Incidently, I've worked a lot both on Isabelle/ML (based on Poly/ML) and
Isabelle/Scala (based on the great thing by Odersky on the JVM) in the
past few years.
Even though Scala is suffiently flexible to imitate SML programming style
(and a bit more), the two worlds are somehow complementary: ML the
super-clean high-performance symbolic computation engine, Scala the huge
monster with the industrial-strength JVM stuff in the background.
When I need some socket programming, I do it in a few lines of Scala.
When I need sophisticated symbolic manipulations I do it in ML. (Sometimes
there is a conceptual overlap, and I get the wrong side in the first go,
but it is then reasonably easy to port to the other side.)
So instead of trying to connect to Poly/ML via the C interface, I better
use Scala/JVM stuff over an explicit protocol.
What is also interesting to see is how the latest improvements of the
Poly/ML runtime system (parallel GC, heap management with online sharing
of immutable data) compares to what Oracle tries to achieve with the JVM.
Here a very sophisticated runtime system provided single-handedly by David
Matthews, there a multi-billion dollar company with thousands of
developers. Let's see what Oracle does next to catch up ... :-)
Makarius
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml