[MLton] Multicore CPU's and MLton

[Ray Racine]

On Sun, 2005-07-03 at 14:44 -0400, Matthew Fluet wrote:
> 
> > Multi-core systems with lots of concurent threads seem to be the 
> > future.
> 
> I'll believe it when I see it.  

Try any number of websites.  This future is very much now.  For example,
in the Java/J2EE world I have a fleet of ex-VBers banging away on
servlets and JSP's.  Funny thing is they are so used to the basic
patterns and because of the very nature of the REST based web
(stateless) they (mostly) write concurrent code without knowing that
that is what they are doing.  Scary but all too true.

It is typical to have 100's of users submitting web requests with a 1-1
correspondence between thread <-> request (even this is changing) where
dozens of those threads are all zipping concurrently through the same
action handler.  I am sure multi-processor based development paradigm
would be a nightmare and a non-SMP aware system would suffer from the
additional kludges to achieve equivalent scalability.

The universe whirls in such an odd manner.  OO became the dominant life
form in the age of widget sets and fancy GUI libraries.  A truly elegant
well designed hierarchy of widgets, like the fundamental theorem of
calculus, brings tears to your eyes.  And just when they reached their
peak...

Along came the internet and user interfaces regressed to the stone age
of interaction via a peep hole otherwise known as a browser/html based
application.  OMG, what have we wrought.

The tragedy of it all is of course the whole web thing is REST based and
is therefore PERFECTLY aligned for functional languages.  I can't tell
you how many times I've thought, "if only we were doing this in a ML /
Haskell like language with a CML like model."  It's a bit sad to view
some poor ex-VBer writing Java or C# code and vainly seeking to tease
out an object hierarchy, just like those degenerate examples used in
their 21 day expert Java books, for a system which needs be purely
functional in nature.  Oh god the bugs, the bugs...

Open any class involved in handling a HTTP get/post and what you see are
classes whose instance variables are pure read-only configuration
parameters and the vast majority of methods are closed (all
variables/parameters are local).  The best design approach would be to
use classes as namespacing scoping / logical grouping structures (!!)
where everything as a static method e.g. write in a functional idiom in
an OO language.  But then its not OO!!! and they want to write OO so
desperately just like the books say.

The whole code base must perforce be stateless; tis the nature of the
web.  Unfortunately this is not what is taught of written in the all
those Java books.  Hence the multitudes of ex-VBers attempting to
extract an OO based system for a system which is purely functional by
its very nature.

The entire Sysiphusical (?) universe is full of doomed life forms
endlessly thrusting square OO pegs into round functional holes.

Honestly THE language of the multi-user Web should be functional in
nature just as old single user GUI widget event application was best
done in an OO language.  For what it matters I do feel that support for
native threads is key as well as asynchronous capabilities, compute
farms, mobile captured continuations, etc.... I see concurrency
ubiquitously in modern code. 

This should have been the age of ML + CML and not a the age of retro-
fitting an dead lock prone OO based language with a mutex/lock based
concurrency model rule the web.  Its such a head shaker to watch the
slow adoption of the the CML and asynchronous models ever so slowly
making their way into Java/C#.

In summary, context is everything I guess, everything I do is multiuser
thread centric and I see that getting to be much more prevalent.

I think the next big language will be more Scala like then not.  Most
likely an evolved Java where Scala like capabilities are slowly mixed in
over the years.

http://scala.epfl.ch/index.html


Ray