Four Lectures on Standard ML (1989) [pdf] | Hacker News Reader

Four Lectures on Standard ML (1989) [pdf]

cs.tufts.edu

113 pointsswatson74144 comments

I did Advent of Code in SML a couple years ago. It was an interesting experience. I don't think I've ever previously experienced such a vast disconnect between the quality of the core language, and the lack of functionality in the standard library.

I think that it could have easily been my favorite dialect of ML if its standard library hadn't been so anemic even by 1990s standards. As it is, though, my AoC solutions tended to take a large effort, not because the problems were difficult to solve in the language, but because I ended up having to build up so many of my own algorithms and data structures. Fortunately, doing that in in SML is a genuine joy. But it still, sadly, renders the language irrelevant for just about any practical purpose nowadays.

Is that the case, even with the 'BASIS' library?

Yes. The Basis library does not live up to today's standards. Which is of course no surprise, given that it hasn't changed since the 90s.

While it is true that things don't move fast, there have been proposals to it which have seen some adoption (thinking MONO_BUFFER was implemented by smlnj has compat in mlton). And I recall a proposal from polyml subsequently was implemented in smlnj. I don't know if there actually is a process in place to actually decide to accept proposals into the basis.

One of the things I like about the basis library is it's principled stance that if it doesn't require compiler support, host operating system support, is more efficiently implementable by the compiler than would be with an external library, or has clear proven utility it belongs in a separate library. This barrier for inclusion is to me at least undoubtedly good.

Personally I would split things apart further (kicking host OS support to a separate library from the basis, as I am inclined towards non-posix hosts where most of the API requiring host support isn't implementable). And kicking out any optional types/modules to separate libraries (where said library is then optional).

So while it is about as minimal a standard library as exists, (for my purposes at least) it sometimes feels like it contains too much. Given there is no language level support for things like conditional compilation of anything optional within the basis. These tend to be my gripes with the basis... not "it needs more things".

Agreed.

Though, also, maybe don't go too far with kicking things out into individual separate libraries. Last year I did AoC in Scheme, and there the annoyance was figuring out exactly which of the approximately nine kajillion SRFI packages I needed to import to get different bits of functionality. A smaller number of more tightly integrated libraries that are allowed to evolve over time would have been more pragmatic.

Yeah, excessive modularity can be just as bad as any monolith. I'd tend towards sticking to a few libraries with well defined boundaries like target OS, or perhaps one for native cpu architecture word sizes and the like. But that still leaves some optional oddities like IntInf without an obvious destination.

I had the exact same experience - I did some of AoC in SML, fell in love with the core language, and even hacked on a toy SML compiler (didn't get too far).

It really is a wonderful language held back by a lack of good tooling and ecosystem, and well, users.

SML/NJ has a standard library [0] beyond Basis with a lot of useful functionality, e.g. sets, queues, hash maps, red-black trees, sorting functions, regex.

[0] https://www.smlnj.org/doc/smlnj-lib

This website looks hilariously mangled on mobile. Which at first I kind of expected, until it said at the bottom it was updated in 2022.

> This website looks hilariously mangled on mobile.

Not much better on the browser though they seemed to have cleaned it up a bit since my last visit. Many years ago when I visited the website to download smlnj for class, I had to double and triple check the url and google/bing/etc the website to make sure it was not a spam site because of how barebones and amateurish the site looked.

> Which at first I kind of expected, until it said at the bottom it was updated in 2022.

I think the last update year is actually 2020. 2022 is the release year of the latest SMLNJ version. I think they could have layed it out better but smlnj is mostly for academic use so I'll let it slide.

What's its advantage over others?

i concur with this assessment. I did the wonderful course, "Programming Languages, Part A" by The University of Washington. Part "A" of the course teaches Functional Programming and uses Standard ML as a vehicle to teach it's semantics.

I completely fell in love with the language, but I concur that the tooling is almost non-existent and the error messages that bubble up, leaves much to be desired.

i took that course. it was a whole lot of fun. i still have yet to take parts B and C.

I made a language server for SML with a focus on attempting to provide good error messages: https://azdavis.net/posts/millet/

it's wonderful and thank you :)

SML pops up now and again on HN, which is always nice to see. I wrote a language server for SML in an attempt to improve the tooling situation around the language: https://azdavis.net/posts/millet/

The main motivator for why I did this is because we use SML as a teaching language at my university and students always seem to struggle with the error messages and tooling from the compiler.

It's so refreshing when the ML acronym is used for its original meaning rather than for the AI hype.

milliliter?

With a capital-M ML would be megaliter, not milliliter. Milliliter would be mL (or ml).

I wish more programmers would take an intense course on functional programming.

I learnt so much in my OCaml classes and really enjoyed programming with it.

Why use OCaml when we have F#?

It doesn't matter which functional language you use, any will do its educational purpose.

But as for other languages, there is pros and cons for each of them. I never tried F#, only Haskell and OCaml.

Sure. I'm just curious what do people who are into functional programming actually think. I've taken a look at F# and other MLs and F# seemed the best althoigh not this simply - another ML (I can't easily recall which one) had some interesting features F# lacked. So I hunt for curious thoughts people may have on this when they MLs are discussed. I personally have little interest in academic computer science but do have strong interest in using cool programming languages to write concise reliable code. Functional languages really shine at saving a solo developer's time as most of the bugs are caught during compile time, verbosity generally is lower and readability generally is higher.

Its owner doesn't really know where to drive it to.

However in general, any would do.

Do you mean the F# Software Foundation consisting of 1831 members?

I mean Microsoft.

Quite curious what those 1831 members would do, if Microsoft decides to play a VB6/VB.NET (both now in maintenance) on F#.

Does Microsoft care about F# at all? Wasn't it a short-lived experiment of the 2000th creative era which just happened to attract enough persistent community interest to avoid being archived?

It cares enough to ship it on VS, and still pay salaries that keep it going.

I expect it to fade into oblivion the day Microsoft decides to drop it.

Those foundation members will hardly keep it relevant, once it becomes yet another third party language on .NET ecosystem.

Perhaps they want to have access to some features that ocaml has that F# does not. Like:

* gadts

* first class anonymous modules

* functors (module level functors)

* polymorphic variants

* row polymorphism

* effect handlers

Although, I must confess, I haven't exactly kept up to speed on F# development. Perhaps F# has added some of these features recently?

Sincere thanks! This is exactly what I meant to ask!

I haven't used F# in a couple years now, but the longtime position of the maintainers has been that F# will not and should not adopt many features along those lines because they interact poorly with the .NET type system.

It's not a perfect comparison, but, having spent some time dealing with all the unusual and surprising ways that some Scala language features interact with Java's type system, I tend to agree with the F# community on that point.

Why won't OCaml steal F# features then?

I think the first questions to ask would be, which ones would it steal and why?

As others have hinted at, F# and OCaml are really not interchangeable languages. They handle lots of things in very, very different ways. Even the difference in runtime makes a big difference. You could very similarly have asked, "Why use Objective-C when we have Java?"

I would rather ask why use Java (for reasons other than the large legacy code base and the job market) when we have Scala (which doesn't even force you to program functionally and can be used as "a better Java" if you want, it can be used to write really weird code but doesn't have to).

Having spent some time using both in a professional context, I would actually choose Java over Scala. And I say that as someone who cut their teeth on functional programming and still tends to prefer it over OOP.

The problem with Scala is that good, maintainable code is defined more by how many language features you have the discipline to avoid using than it is by how many you do. And that makes it more difficult to keep a large Scala codebase maintainable on a team with varying levels of experience. Freely mixing ad-hoc and subtype polymorphism (that is, type classes and subclasses), for example, is a very short, very slippery slope to a situation where the best way to figure out how the code works is to already know how the code works.

Scala, The Walmart of language paradigms.

I never could wrap my head around the context variables or whatever they were called, where the language would pick a random variable from your local environment and pass that as an argument to the function call.

Well, those two are comparable. Java is based on Objective-C (it's ObjC without the C… or the Smalltalk… which is why there's not much left.)

And the App Store still runs on a Java port of WebObjects to this day.

Relying on Microsoft’s .NET is not what a lot of us would want to do, especially when it comes to libre software.

To me .Net seems the most powerful thing to make a relatively esoteric language practically useful in the real life. Compiling to .Net gives a really solid ground for free. Compiling to JavaScript is a great option but the JavaScript landscape seems way less stable and this way harder to support.

But you have to rely on Mono or .NET Core for Linux which isn’t something many want to put on their servers or desktops.

Is there any legitimate reason to avoid having it?

Can you suggest some course(s) and/or language(s)?

Reply on news.ycombinator.com