But now I know _where_ to ask ....

More generally, I would like folks' opinion as to whether or not
learning SML is a waste of time - in this day and age. So far, I'm
finding SML simple and intuitive to learn. Maybe I should look at the
process as merely a stepping-stone towards a similar but newer
language??

I'm not a professional programmer, but simply an avid amateur/
hobbyist. I enjoy doing website "backends", for which I've used Perl,
PHP, Tcl and newLISP.

I suppose that I'm still on a quest for _my_ "holy grail" of
programming languages. :)

There are practical issues though: there are very few libraries available.  I know of no modern usable GUI library, for example.  (On that note, I am hoping to release bindings for GTK+ soon.)  Availability of libraries may well determine whether SML is suitable for your purposes.

As for the language, there are many ways it could be improved/extended, from little fixes to new fancy ideas (many of which are noted at http://www.successor-ml.org/), but these have little bearing on getting useful stuff done.  In my opinion, the most pressing issue today is the lack of language-level support for Unicode, and for this alone, SML is in dire need of a revision.

SMLserver
http://www.smlserver.org/

ML server pages
http://ellemose.dina.kvl.dk/~sestoft/msp/index.msp
(didn't appear to be working properly when I tried - server issue?)

and once you've properly mastered SML and want more from the type system...

Ur/Web
http://www.impredicative.com/ur/

Newer languages similar to ML (such as O'Caml, Scala and F#) nearly all
have the disadvantage of being "infected" by object-oriented
programming, partly because of running on JVM or .NET, where there is a
need to support libraries designed for Java or C#.  Haskell is less
similar to SML than, say, Scala or F#, but it has (so far) avoided this
infection -- though the word "class" is used, it means something
different than in Java or C#.  But Haskell is also a much more complex
language than SML.

It would be really nice to have a new language similar to SML that
solves some of the issues with libraries, Unicode, multi-threading and a
few other things -- but without going overboard in complexity.  It would
not be that difficult to design and implement such a language, but it is
a lot of work to make extensive libraries -- which is why many recent
attempts use existing object-oriented libraries instead of making new
libraries.

As for whether it is worth to learn SML: Definitely.  Even if you won't
use it for serious projects, having learnt it makes you a better
programmer in other languages.

some notes:
1) in IT there is no "age" or "time". technology or fits requrements or
not, thats it. "Old" language still can be "perfect fit" for task.
Sure "New" languages emerges everyday... and dies everyday))
Their developers make this "feature monsters" just because they can.
not because that languages was needed.

2) about requirements. languages divides on two big categories.

first category  is research, prototyping languages. yes, those scripting,
agile, dynamic, with "modern" powerful features etc. those "for dummyes".
this languages praises fast generation of "seemingly working" prototype
for sell.

second category is industrial languages. industrial means "for ingeners"
here. such langs emphasizes quality, control, proving solution
correctness, maintenance, contracts.
they do not try get "first shot", they try do right shot. and one more if
needed. and again. such languages do not like hard to control
superfeatures. they like simplicity and use modular "divide et conquer"
tactic for program manageability. SML is such language. maybe
Ada is. or modula-2. it's easy to determine - such languages have
separate interface and implementation part of modules. have good,
isolating modularity. not OOP dependence madness, not namespaces.

so. not "cool features" is good. manageability and guaranteed safe use of
primitives combinations is good. and this is hard to do in language with
cool features, just because it combinations is hard to predict.

"newer" not necessary better. because nobody really tries do better.

see - SML have 5-7 living implementations. still living. good?
look at existentialtypes.wordpress.com

http://learnyouahaskell.com is probably the most popular Haskell
beginners' guide these days, and the Freenode #haskell IRC channel is
very helpful.

@phil.c
Thanks for the IRC channel heads-up, and the web-related links!

I'm currently test-driving SML with 3 different compilers. I like this one:

http://www.ps.uni-saarland.de/alice/

@Torben

I have an aversion to OOP - but I don't mind Wirth's approach to it in Oberon2 etc.

Mythryl http://mythryl.org/ might just be the answer when it becomes a little more fleshed out.

@Natarov

I know!! The perfect hammer may not exist, or the perfect fly-rod, but I have one of each that _I_ think are. :) Programming languages are tools - after all, each suited for a particular task (maybe). I guess maybe I should say that I'm still searching for "native tongue" - my "default" programming language. SML (Alice flavor) might just be the one.

I've fooled around with the MUMPS language. I like it, but getting it to happen on my machines has been a chore. It is _still_ widely used in Healthcare and financial institutions - after all these years.

I'll be test-driving OCAML as well.

@Paul

I tried Haskell using the link you provided, some 3 yrs ago. I found it a bit too complicated - then! And the Freenode channel may come in handy.

LOL ... but everybody's "suck" criteria are _so_ different. I just assume that they all are good and have some value, until I test-drive them. :)

seriously, it's developers just leave it and make other job now.
at google, if i correctly remember...
and... alice is definetely not so "complete, mature and stable".
i was try to build and try it some, on different bsd/linuxes.
it is continues to be interesting research testbed and it feels.
more or less worked only core part, with minimum features and
on stability-liking linuxes. like debian or slackware.

i hears it used in practice somewhere... but
alice definetely needs updating to modern realities and closing bugs.

The compilers/interpreters each have their own pros and cons.  There is no one answer - it depends on your particular circumstances.

MLton typically produces the fastest code (by some margin) but has no interactive session: it produces stand-alone executables.  It typically takes the longest to compile (by some margin) due to optimization, so this may not be most suitable during development if e.g. you are frequently recompiling programs whose running time is low.  If you need an interactive session, then I would suggest looking at Poly/ML or SML/NJ.  For large-scale industrial applications, we found that Poly/ML scales up much better - it was a lot faster and has an x86_64 version.  If you're learning SML, that probably isn't a big deal and it may well be that the wide range of tools/utilities provided by SML/NJ would be more useful.

My suggestion would be to look at MLton, Poly/ML and SML/NJ.  That's just practical advice based on my own experience, not a balanced view considering all available implementations.

[snip]

...oh-o, seems i know many... seven!... implementations, beside alice...
looks like with ML you definetely NOT vendor-locked, like with gnat or
evergrow ghc! he-he...

0) so, alice... it's bytecoded implementation and purposely will be such
(for code migration). as such it somewhere slow (but has jit) and more or less
portable. as i remember, have some problems with oses which "not linux" (like xBSD).
base sml language in it is greatly extended with parallel and distributed features,
with constraint programming, etc. which is not so well-founded and narrow as in
smlsharp case. general and powerful, of course. but you not always need power,
sometimes predictability and reliability is preferred... having solution you
deny other solutions... and as sayed, standards (Standard ML 97) is good.
...i hear alice developer now spend all time making v8 javascript at google,
and javascript is bad language...

1) smlnj. the so named "standard implementation of ML". i use it some, it's average.
oriented to dynamic, explorating, interactive use. memory images can be stored to
file and runned on other computer with same runtime version (or can be packed
with runtime forming independent, somewhere big, executable),
but smlnj is not for binaries. it's big, elaborated, interactive environment.
memory consumption is moderate. generates native code in-memory (MLRISC backend)
and so has slower compiling time than mosml, has somewhere bigger memory
consumption also, but faster run times (on par with mlkit).

2) mlton. optimizing compiler. i say it "optimising whole picture, not small peepholes",
optimising-at-large. it do less optimisations-in-small than gcc, i think, but apply
optimisations-in-big more thoroughly (some peepholes rests unoptimized, sse not used
etc). supports parallelism (threads), as is polyml, but in somewhere different way.
resulting binaries is self-contained and relatively small (what not used is not included).
one BIG problem with it - it's a real memory and processor hog, and always will be.
it can easy eat gigabytes because of "whole-programness" and multiple passes
of optimisation transformations in memory. and because of that it sometimes can't
be used on old desktops or netbooks. i recommend you setup zswap in your linux for
this beast. peoples recommends use mlton for compiling release binaries only.
some game developers or crossdevelopers use it as wunderwaffe.
there is one possible trap in "use for final release only".
"whole-program"-ness somewhere changes semantic for some SML constructs
(like scope for definitions). this can be good (you get efficient functors for free!)
or bad. it depends... be warned.

3) polyml. compact interactive system. two files, easily distributed with application.
has parallelism. i think internally looks like smlnj (generate native code in-memory),
but smaller and simpler. moderate sequential performance, but people say it has
good parallel scalability. main application - polyml powers isabelle theorem prover.
i do not know if polyml GC is parallelized now (that somewhere limited speedup
on 4-6 in applications other than symbolic computations with small shared state),
but it is actively supported.

4) mlkit. simple native batch compiler (MLRISC-based codegenerator, as smlnj).
optimisator in this compiler is simple and gives moderate quality.
not so good in optimisation as mlton, but more predictable. has small runtime.
really great things in this compiler is:
  region-based memory allocation (compiler optimise some work for gc,
make it possible to program realtime systems) and
  separate module compilation (really good thing for incremental big project development).
try to use it together with mlton.
it's bad, bad that this compiler somewhere forgetted and leaved in shadows!

5) moscow ml. bytecode interpreter on old caml (wich was before ocaml) runtime.
fast compiles, slow runtimes (no jit). compact. have separate module compilation.
as i hear, have some problems with float numbers. some admins use it as scripting
language and for small web interfaces. in the past some use it for theorem provers.
small memory consumption is main goodie of this implementation.

6) hamlet. interpreter of full ml written in ml. useful in teaching and
experimenting with language, can be in one big sml file.
slow, of course. compile it with mlton.

7) smlsharp. interesting ml native-code x86 compiler. roots of project grows from
mlkit as i think (it not related with dotNet and c-sharp). so characteristics is also like
of mlkit. have good c interoperability. somewhere polished in fresh, release version.
hey, developers say it has parallelized gc now.
has ml language extended with some enterprise-y constructions like records and
such. and this extensions try to be formally verified and theoretically founded
(meanwhile, i personally do not like oop and inheritance, but managers like).
developed by japan government-founded project, they tries to get language for
usual commercial development, specially targeted at low maintenance costs
(like Ada was). i ask developers if it will have jvm codegen in future (for more
"enterpriseness"). they reply - "maybe". interesting project, i will look at it future...