Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standard ML in 2020

notes.eatonphil.com

Post reply on HN
Print view View original

91–100 of 125 posts

Re: Standard ML in 2020

#91

Post by _hzrk »

fouric wrote: post #88
hajile wrote: post #22

StandardML really hits a nice sweet spot in language design. The syntax is super-easy to learn (The BNF for the whole fits in a mere 2 pages[0]), but contains a lot of features in that small package. Rather than tacking on functional features (eg, Java with lambdas), these features have been carefully considered and streamlined and include bits like proper tail calls and currying. You get nice bits like actually soun…

Why should I use SML over Rust or Lisp? Rust's performance is almost certainly much better, with a larger library ecosystem. (Common) Lisp has macros, which allow me to implement pattern-matching; an even simpler BNF (as short as one line, depending on how you define it); dynamic typing, which makes generics unnecessary, and for all the hate that it receives is regularly deployed to production systems on large scales…

SML over lisp:

* Doesn't have macros, which in my 16 years of experience is a plus, macros pollute, should at most be an implementation detail

* Has types

* Doesn't have parantheses and the annoying prefix notation

* Your knowledge of SML can be translated easily to OCaml, Java, Scala, which are more or less part of the same family

SML over Rust:

* I don't have to reason about lifetimes, I'm not in a constrained environment

* TCO (tail call optimization)

* At its core, Rust is still an imperative language, it was influenced by ML but not that much as many believe

SML over Scala:

* It doesn't suffer of Haskellism and Extreme Bipolarity (oop/fp) and gets the job done.

Re: Standard ML in 2020

#92

Post by eatonphil »

Munksgaard wrote: post #77
brmgb wrote: post #43

Earlier quoted context omitted.

SML is standardized which is useful if you want to build an implementation for academic purpose. I don't think anyone seriously uses it outside academia however.

I have worked professionally with Standard ML for a few years, but my friends and I used to joke that I was probably the only professional Standard ML developer in existence.

What did you build? The only real use cases I've heard of were in language prototypes or proof assistants (i.e. HOL, Isabelle).

Re: Standard ML in 2020

#93

Post by eatonphil »

Munksgaard wrote: post #74
eatonphil wrote: post #11

Earlier quoted context omitted.

None of them have invested very much in tooling as far as I know. There are some small sml-modes for emacs or plugins for vim but they only do basic syntax highlighting. One of the biggest missing things for SML tooling is parsers for SML written in SML. They tend to be written in the implementation language and not exposed as a library. So you don't see SML formatters or documentation generators so much. There have…

MLKit is a (quite performant) SML implementation written in Standard ML, including the parser.

Actually now that I look, the one formatting tool I saw come out this year is based on a parser that apparently SML/NJ exposes.

https://github.com/ProjectSavanna/autoformat/blob/master/run...

Re: Standard ML in 2020

#94

Post by smabie »

hajile wrote: post #41
zepto wrote: post #31

Earlier quoted context omitted.

I was under the impression that ocaml’s optimization was pretty good. Granted multicore is not here yet.

Ocaml's optimization is very good, but not perfect. For example, if you need 32-bit integers instead of 31-bit integers, your performance is going to tank due to boxing. MLton is a whole program optimizer (rather than function at a time like Ocaml) and wrings out a ton of performance though compile times are quite a bit longer.

I believe flambda is whole program, could be wrong tho

Re: Standard ML in 2020

#95

Post by hajile »

fouric wrote: post #88
hajile wrote: post #22

StandardML really hits a nice sweet spot in language design. The syntax is super-easy to learn (The BNF for the whole fits in a mere 2 pages[0]), but contains a lot of features in that small package. Rather than tacking on functional features (eg, Java with lambdas), these features have been carefully considered and streamlined and include bits like proper tail calls and currying. You get nice bits like actually soun…

Why should I use SML over Rust or Lisp? Rust's performance is almost certainly much better, with a larger library ecosystem. (Common) Lisp has macros, which allow me to implement pattern-matching; an even simpler BNF (as short as one line, depending on how you define it); dynamic typing, which makes generics unnecessary, and for all the hate that it receives is regularly deployed to production systems on large scales…

Those are both great languages.

Rust is very much a ml variant. It's all the things you claim and probably more. It's also at least an order of magnitude more complex. If you know rust, you'll probably find SML super easy to learn and refreshingly easy to code.

People gravitating toward SML likely want a few things: easy to learn, simple infix syntax with functional support, compile time type static type checks, multithreaded, very fast without a drastic recode.

Common lisp libraries are better, but not drastically so (well, I've never had 5 grand to throw at lisp works, so I can't comment there). CL is more complex to learn (must people can probably learn the entire SML language in the time it takes to master the loop macro). Macros are powerful, but mean that even if you can find a lisp dev, it'll take a long time for them to learn your custom variant of the language.

CL offers unofficial threading, but last I checked it was much harder than the SML solutions. CL is pretty fast out of the box, but if you ever need peak performance, the code changes a lot and can become very finicky (though CL makes seamlessly hiding those bits easier than most languages). Even at it's most optimized, I don't know that it can match milton in performance or memory usage.

Dynamic vs static typing is a battle that's all but over. When you have devs coming and going on a team, type make transitions easier. Loads of dynamic languages have started adding them and even CL sort of does.

CL has loads of interesting features from well known ones like macros/reader macros or metaobject protocol to less known ones like optional dynamic scoping.

I'm just saying why I enjoy SML (not trying to argue that it's the end all, be all of programming). There are other great languages too. Do what you love.

Re: Standard ML in 2020

#97

Post by stutonk »

chriswarbo wrote: post #81
stutonk wrote: post #34

Earlier quoted context omitted.

The profusion of Category-theoric abstractions and some of the more recent purely functional norms in Haskell are like the PhD-level version of `AbstractVisitorContextFactoryBuilder` which, aside from all the unnecessary cognitive load, lead to enormous dependency graphs of the npm variety. Personally, I wonder if uniqueness types in languages like the sadly forgotten Clean (a close relative of Haskell) would have be…

I find there are two main problems with monads in Haskell: - Monad is just an interface (with nice do-notation, to be sure), but it's elevated to an almost mythic status. This (a) causes Monad to be used in places which would be better without (e.g. we could be more generic, like using Applicative; or more concrete by sticking to IO or Maybe, etc.) and (b) puts off new comers to the language, thinking they need to le…

Well said. This is exactly my gripe with Haskell monads. There are too many places where the hierarchy isn't uniform and there are a bunch of special monads like IO and List. It leads to the same ambiguous "is a" problem of complicated OO hierarchies and is one of the reasons they don't compose well.

The ironic thing is that these algabraic effect systems have a feel/control flow pattern that's quite similar to exception handling from the OO languages or interrupt handlers in low-level code.

It's much easier to just say "this piece of code is impure, it may do X, Y, and Z and if so then ..." than to try and shove everything ad-hoc into the abstract math tree. But then you lose the purity of your language and it's really awkward in a language whose primary concern is purity. That may be a reason why algebraic effects seem a bit more natural in OCaml.

Re: Standard ML in 2020

#98

Post by stutonk »

nine_k wrote: post #58
stutonk wrote: post #34

Earlier quoted context omitted.

The profusion of Category-theoric abstractions and some of the more recent purely functional norms in Haskell are like the PhD-level version of `AbstractVisitorContextFactoryBuilder` which, aside from all the unnecessary cognitive load, lead to enormous dependency graphs of the npm variety. Personally, I wonder if uniqueness types in languages like the sadly forgotten Clean (a close relative of Haskell) would have be…

I don't think there's a way to not use monads, because a ton of everyday things just work in a monadic way, things like lists, or statement sequences in presence of exceptions. I think it's wiser to admit and use these properties instead of ignoring them. Ignoring maths that underlie computation when writing software is like ignoring math that underlies mechanics when building houses: for some time you can get by, bu…

The problem isn't with the mathematical concept of monads, it's that Monad is a typeclass in a hierarchy along with other totally abstract category theoric classes introduced at different stages and people use them with varying levels of knowledge and ignorance so things are placed arbitrarily and there are a bunch of ambiguities. Just look at this [0] mess. Is that really what we want?

[0] https://wiki.haskell.org/wikiupload/d/df/Typeclassopedia-dia...

Re: Standard ML in 2020

#99

Post by hajile »

smabie wrote: post #94
hajile wrote: post #41

Earlier quoted context omitted.

Ocaml's optimization is very good, but not perfect. For example, if you need 32-bit integers instead of 31-bit integers, your performance is going to tank due to boxing. MLton is a whole program optimizer (rather than function at a time like Ocaml) and wrings out a ton of performance though compile times are quite a bit longer.

I believe flambda is whole program, could be wrong tho

https://www.cs.cornell.edu/courses/cs3110/2017fa/htmlman/fla...

As of 3 years ago it wasn't, but maybe that has changed.

Whole program compilation isn't without its downsides though. It seems pretty common to develop in SML/nj because of fast compiling then doing final performance profiling and deploying with mlton (having a standard helps). Function at a time is also more amenable to caching and reusing part of the previous compile.

Re: Standard ML in 2020

#100

Post by chriswarbo »

EE84M3i wrote: post #67
elihu wrote: post #55

Earlier quoted context omitted.

> Are you familiar with unsafe IO? > It's used pervasively in low-level code because the idealism of monads just doesn't cut it. In my opinion, this proves that the pragmatism of side effects is a necessary evil for actually getting things done in a performant way. It seems like you aren't very familiar with the ways Haskell programmers deal with side effects and mutation. UnsafePerformIo is sometimes needed, and the…

Wait, I thought that lazy io (e.g. getting a lazy string back from "reading" a file, which triggers subsequent reads when you access it) was widely considered bad and a mistake.

Lazy IO is really useful for commands which stream data over stdio, e.g. this is a really useful template, where 'go' is a pure function for producing a stdout string from a stdin string:

    {-# LANGUAGE OverloadedStrings #-}
    import qualified Data.ByteString.Lazy.Char8 as BS

    main = BS.interact go

    go :: BS.ByteString -> BS.ByteString
    go input = -- Generate output here
If you don't mind Haskell's default String implementation, then it's just:

    main = interact go

    go :: String -> String
    go input = -- Generate output here
Post reply on HN