[HN Gopher] Comparing Objective Caml and Standard ML
___________________________________________________________________
Comparing Objective Caml and Standard ML
Author : weatherlight
Score : 67 points
Date : 2023-02-15 15:39 UTC (7 hours ago)
(HTM) web link (adam.chlipala.net)
(TXT) w3m dump (adam.chlipala.net)
| smlnj_help wrote:
| Perhaps the wrong place to ask, but, does anyone have a good
| reference on working with the NJ CM that is more tutorial than
| the linked manual? Was just getting started with the NJ compiler
| and was getting frustrated with the REPL. Will it still be as
| nice as he claims coming from more modern build systems?
| weatherlight wrote:
| I've been using SML with millet language server and VScode.
|
| you can highlight your code and run just the highlighted bits,
| in your REPL.
|
| https://github.com/azdavis/millet
| smlnj_help wrote:
| This looks great. Gonna try it later with the toml file and
| report back -- thanks!
| forgotpwd16 wrote:
| Interestingly in syntax OCaml is considered purer only once for
| its choice of not using overloaded operators.
| octachron wrote:
| In this comparison, "purer" more often than not means that the
| choice simplified the formalization of SML.
|
| And for the context, many people from the OCaml side considers
| that the SML formalization has been for a good part responsible
| for the freezing of SML since 1997.
| ggerules wrote:
| For those wanting more comparison examples between OCaml and SML,
| these additional web sites might be of interest.
|
| [1] needs updating with OCaml's newest features, but is still
| very good.
|
| [2] and [3] are useful to see more examples in those respective
| languages.
|
| [1] https://hyperpolyglot.org/ml
|
| [2] https://rosettacode.org/wiki/Category:OCaml
|
| [3] https://rosettacode.org/wiki/Category:Standard_ML
| eterps wrote:
| If you are looking for an ML dialect that has a more 'familiar'
| syntax, check out Rescript:
|
| https://rescript-lang.org/docs/manual/latest/overview
|
| Although personally I prefer the syntax of F# (but I don't like
| the .NET focus of it).
| giraffe_lady wrote:
| Rescript extremely underrated imo. For self-contained projects
| it's strictly superior to typescript: its type system is
| simultaneously easier to work with and more sound, with better
| type inference. The tooling isn't _better_ per se but it 's
| easier to use.
|
| If you have dependencies it depends. Writing bindings to all of
| them can take up a lot of time. Gentype from typescript types
| is often enough, but not always.
|
| Hope to see this one catch on a lot more. It's an incredible
| alternative to typescript.
| eterps wrote:
| > _For self-contained projects it 's strictly superior to
| typescript: its type system is simultaneously easier to work
| with and more sound, with better type inference._
|
| Exactly, typescript is a highly complex addition to a
| relatively messy language (JS).
|
| Rescript feels like what Typescript could have been, a
| cleanup of JS and a sound typesystem and excellent type
| inference. (however breaking compatibility as a consequence)
|
| IMO Rescript is easier to read than plain JS and still it's
| fully typed.
| hencq wrote:
| If you like F# but not .NET, Fable might also be worth a look:
| https://fable.io/
| [deleted]
| [deleted]
| sshine wrote:
| This is an oldie but a goodie.
|
| I remember reading this page making up my mind when choosing
| between the two.
|
| OCaml has, unlike Standard ML, grown quite a lot since this page
| was made.
|
| In particular, the section "Standard libraries", I'd recommend
| looking at:
|
| https://dev.realworldocaml.org/
|
| A couple of places where the comparison is outdated:
|
| - OCaml using Base [1] allows for result-type oriented
| programming
|
| - OCaml using Base uses less language magic and more module
| system
|
| While there was and is truth to the distinction that SML is for
| scientists and OCaml is for engineers, this dichotomy is getting
| dated: OCaml is under active development, which means that
| scientists who want better tooling will choose OCaml. For
| example, 1ML [2] by Andreas Rossberg was built in OCaml.
|
| [1]: https://opensource.janestreet.com/base/ [2]:
| https://github.com/rossberg/1ml
| cmrdporcupine wrote:
| I remember reading this many years ago. TBH I always felt SML was
| a nicer language, syntactically -- more readable (mainly because
| of the let..in..end scoping syntax) -- and I really liked its
| Basis library; something about the API choices there seemed to be
| one of the better collections libraries I've ever used. The
| "object" part of OCaml didn't feel necessary to me.
|
| But OCaml has had more momentum, and I don't know if anybody is
| even using SML anymore?
|
| Interesting to look back with a bit of history now, too. Choices
| like having objects/classes and exceptions (instead of result
| types) added into OCaml were probably seen as modernizing and
| adding in features that people expected; but now the pendulum
| seems to have swung against those features. OOP hype has passed
| -- e.g. Rust and Go don't have 'classes' with inheritance. And
| exceptions are also lacking in Rust etc, in favour of
| Option/Result type + pattern matching, so that control flow is
| more explicit and easier to reason about.
| weatherlight wrote:
| I'm learning SML for a college course right now. I'm pretty
| smittened, I gotta say. It seems strange to me, that it never
| took off.
| projektfu wrote:
| It's probably because I'm a chickenhead but I couldn't get
| the signatures/modules/functors thing working properly and
| found Haskell a wonderfully easy alternative.
| zarzavat wrote:
| If I've learned anything as a programmer, is that these things
| move in fashions. People will get sick of result types and
| exceptions will be hot again. OOP will be fashionable once
| again. The grass is always greener on the other side of the
| fence.
| cmrdporcupine wrote:
| This is quite possibly true, but I feel like exceptions are
| one of those things... people are just finally cluing into
| the fact that this is a non-local GOTO, and the consequences
| for reasoning about program flow can be terrifying, like
| Djikstra already told us.
|
| If exceptions have a "comeback" (they have not gone away in
| mainstream languages like Java, C#, Python etc.) I hope they
| come back in a way where they're bundled with static analysis
| features that help with the reasoning process.
|
| When I worked in Java, 10+ years ago, checked exceptions were
| considered an obnoxious "no-no", and bad style. Mostly
| because people just wrapped and rethrew them as runtime
| exceptions. But, like, runtime exceptions are awful, and
| almost every application I worked in had buckets of garbage
| in the logs which consisted of uncaught or "caught & logged"
| exceptions. Such exceptions are particularly troublesome in
| highly concurrent applications.
|
| Exceptions should be exceptional. I think Rust has made the
| right call here. Handle the error, or panic. Don't make it
| somebody else's problem.
| eschaton wrote:
| This is exactly the Cocoa exception model: Exceptions are
| treated as assertions, while errors represent things the
| program or user should be able to act on and recover from.
| Swift reifies this by not having exceptions at all, just
| fatal assertions like precondition() and fatalError(),
| while using try/throw/do/catch for propagation of errors
| (and making handling them non-optional).
| layer8 wrote:
| I view checked exceptions as syntactic sugar on what could
| be implemented as result types (as in "Either" result
| types) behind the scenes. It's not how they are implemented
| in Java, but potentially they could. When used in that
| fashion, they are certainly more ergonomic than explicit
| result types. Being (type-)checked is crucial for that, of
| course.
| cmrdporcupine wrote:
| Agreed, but back when I worked in Java and I tried to use
| checked exceptions in my code, team leads and fellow
| seniors always yelled at me.
|
| Still, the catch syntax was very verbose for handling
| common conditions. Exceptions were the wrong
| _syntactical_ tool for the job.
| xwolfi wrote:
| Hum, panic as in stop all work ?
|
| I like that in Java, units of work can continue after an
| unhandled exception because you know, sometimes, your
| software is used by many people in many input variants and
| say, if you re doing a trading backend, it's bad that you
| cant fill an order because of a silly parsing bug, but it d
| be way worse if you had to stop for the day until a dev
| wakes up and fix it.
|
| Log it, and while you fix it the thing still runs for 99%
| of inputs. Maybe that s what you call "handling" the error
| ? But it's cool to bubble up the exception because you can
| share the handler amongst all your downstreams: you may
| dislike having to do the same exact semi-complex log
| building everywhere and having it just capture exception at
| the top most unit of work dispatcher to catch if one threw
| something to then log and alert your support team in one
| place, might make sense.
|
| Ofc return types can do all that but you contaminate your
| whole program with handling for bugs you cant well predict
| the nature off... the only certain thing is that if your
| program is old and big enough, you'll screw up in
| innovative ways a general catch will allow to recover from,
| because you just dismiss the whole input and move to the
| next.
| cmrdporcupine wrote:
| Yes, panic, stop all work. If it's truly an exceptional
| circumstance, it's unlikely that anything further up can
| "fix it." Don't even try. Kill the process and restart.
| Or force the author to fix the bug.
|
| If it's an "expected" runtime condition that you can
| manage and recover from, then it's not "exceptional", is
| it? So don't use an exception. Pass the information to
| the caller that needs it, and adjust state accordingly.
|
| That's my take these days. I've seen too many systems
| degrade in cascading failures because of misguided
| attempts to "recover." Deadlocks, partial failures,
| explosions, etc. Real fun to diagnose.
| smasher164 wrote:
| Exceptions _will_ come back, but in the form of algebraic
| effects. All of the work that goes into error handling,
| asynchrony, mutable state, and IO will be generalized by
| effects.
| msla wrote:
| I think some things are fashions and some are lessons
| learned.
|
| For example, English-like syntax is out. Cobol has it because
| it was invented for its predecessor and Cobol's still around,
| SQL has it because its designers copied Cobol before we'd
| learned better, and that's it. We still use words in our
| syntax but explicit block structure with punctuation is now
| known to be easier to read.
|
| Speaking of block structure: Line numbers are gone.
| Unrestricted use of goto (as in, using goto to go from
| anywhere in the program to anywhere else in the program) is
| also gone. These things aren't fashion: We've learned better.
| We're more likely to invent a different kind of structure
| than to go back to that.
|
| Similarly, languages with absolutely no type system are also
| out: You can have the types on variables, like Haskell, or
| values, like Python, but choosing to have neither, like BLISS
| and BCPL, is no longer an option unless you're actually
| writing in assembly language.
|
| Other things, like column-oriented formatting, are gone
| because technology moved on. Even Cobol abandoned that one.
| agumonkey wrote:
| 90s OOP not much but I believe we ran the FP cycle and its
| ideas have been adopted as much as possible. I think there
| might be another more mathematical and practical (to cut the
| verbosity and improve reuse) revival of OO, context/aspect
| for some bit of meta maybe .. or contracts or
| multipledispatch.
| cmrdporcupine wrote:
| I'm holding out for the wave of logic / declarative /
| relational programming. That's my nerd preference.
| agumonkey wrote:
| I used to be a lisp head, sexps and paredit were so neat. Then
| I had a dan grossman sml mooc, it was the first time a language
| booted lisp outside my taste. Emacs sml/smie made indentation
| right. Very neat, I wish it could have a second coming.
| cmrdporcupine wrote:
| Does make me ponder how much work it would be to get a new
| SML runtime built up overtop of LLVM. Assuming someone hasn't
| done it already.
|
| Ah, yeah, it's been worked on before, just found a paper:
| https://people.cs.uchicago.edu/~jhr/papers/2020/ifl-smlnj-
| ll...
| smasher164 wrote:
| Remember that this is only comparing the languages. If you
| actually try to write code in Standard ML, you come to a rude
| awakening as to how poor the tooling is.
|
| Libraries are underdocumented and unavailable. The build system
| and package management is arcane. SML feels like a toy language
| compared to working in OCaml.
| weatherlight wrote:
| SML has the nicer syntax though, and the millet language server
| is really really nice.
| marktangotango wrote:
| PolyML has a lot more "stuff" build in like threads,
| multiprocess, and sockets. If I were to use SML in anger I'd
| use PolyML. Sadly I've never had the need.
|
| https://www.polyml.org/documentation/Reference/Basis.html
___________________________________________________________________
(page generated 2023-02-15 23:01 UTC)