3 ms·

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an u

Not a huge fan of ML for the Working Programmer, personally. I'd love to see (or one day write) the equivalent of Practical Common Lisp (which itself needs an update at this point) because MftWP is sooo dated. But I can see how it's a decent enough intro. Regarding your points: 1. Yeah editor support sucks. I normally edit in text mode with my own minimal keyword highlighting or ocaml-mode. 2. Poly/ML can definitely generate binaries! Most distros ship with `polyc` that will build the binary for you. But this is just a shell script around opening the REPL and calling some dump image function (like how you build a binary on SBCL). MLton and Poly/ML definitely allow you to build binaries. I don't know about SML/NJ. 3. For sure a pain. I use rlwrap [0] to work around this, which is ultimately simple enough! 4. Interesting! I personally find Haskell-style decorations so much more a pain since they're not inline. SML is very much like other major languages in the way it does inline types (TypeScript, Go, C#, etc.). [0] https://github.com/hanslub42/rlwrap https://github.com/hanslub42/rlwrap

yakubin 6y ago
2. Good to know. I needed to do a "sudo apt install libpolyml-dev", because otherwise it wouldn't link. 3. Thanks for the tip! That will save me a world of pain.
fbsvvc123 6y ago
Re (2): SML/NJ has a similar scheme to dump a heap image to get an executable.
cannam 6y ago
I absolutely love ML for the Working Programmer, but I think you have to see it as a philosophical text as much as a tutorial. To these points, I'd say 1. I find Emacs sml-mode is just about up to it. I do have complaints - I wish it would pull back the indentation more in lines that continue an expression, it doesn't handle multiple "where" clauses elegantly, it misaligns anonymous function alternatives - but every time I consider trying to fix them I decide they don't quite upset me enough. It's a slight pity though because I strongly believe a language should be auto-indentable (life's too short to indent code yourself), and SML is, just not quite with the existing mode. 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds - both producing executables. There are still problems on Windows, which doesn't have a properly native MLton port - the existing one uses MinGW which is ok-ish but not what I would prefer. (MLton has a code generator that produces C, so the limitation is that the runtime hasn't been ported rather than with the compiler itself.) 3. Agree, "rlwrap poly" 4. I like inline type decorations, but I also like to omit them most of the time. I think you do get some feel for when it's a good idea to add them, to clarify things for the call site or check your own intuition about the deduced types. Module boundaries (with signatures) also form a natural firebreak for out-of-control type errors.
- e12e 6y ago
  > 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds Do you have/use any dependencies? Like a http/2 (or tls capable) web server, a database client or a gui library? If you do, how does that work with two implementations - if not... What kind of programs do you write/problems are you solving?
dtornabene 6y ago
Just want to push back a bit and leave a dissenting view on ML for the Working Programmer. If one actually works their way through the text, by the end they will have written a basic interpreter for the lambda calculus, and a small tactics oriented theorem prover, either one of which is highly illuminating to someone who hasn't done this before. The text may not educate a reader on dependent type theory or similar developments but I'm struggling to understand how it is otherwise "dated". Other than that thank you for keeping SML in front of people, I for one appreciate it, its probably my favorite language these days
- eatonphil 6y ago
  I see your point. I guess it's just the title that has turned me off even after reading the book. It doesn't seem to send the right message these days if the idea is that working programmers are building lambda calculus interpreters or theorem provers? Even interpreting a lisp would seem more practical. I think Practical Common Lisp was more in the right track for content but today I'd focus more explicitly on language design or backend system design. Andrew Appel's book does already fill the language design slot though nicely.

yakubin 6y ago

2. Good to know. I needed to do a "sudo apt install libpolyml-dev", because otherwise it wouldn't link. 3. Thanks for the tip! That will save me a world of pain.

fbsvvc123 6y ago

Re (2): SML/NJ has a similar scheme to dump a heap image to get an executable.

cannam 6y ago

I absolutely love ML for the Working Programmer, but I think you have to see it as a philosophical text as much as a tutorial. To these points, I'd say 1. I find Emacs sml-mode is just about up to it. I do have complaints - I wish it would pull back the indentation more in lines that continue an expression, it doesn't handle multiple "where" clauses elegantly, it misaligns anonymous function alternatives - but every time I consider trying to fix them I decide they don't quite upset me enough. It's a slight pity though because I strongly believe a language should be auto-indentable (life's too short to indent code yourself), and SML is, just not quite with the existing mode. 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds - both producing executables. There are still problems on Windows, which doesn't have a properly native MLton port - the existing one uses MinGW which is ok-ish but not what I would prefer. (MLton has a code generator that produces C, so the limitation is that the runtime hasn't been ported rather than with the compiler itself.) 3. Agree, "rlwrap poly" 4. I like inline type decorations, but I also like to omit them most of the time. I think you do get some feel for when it's a good idea to add them, to clarify things for the call site or check your own intuition about the deduced types. Module boundaries (with signatures) also form a natural firebreak for out-of-control type errors.

e12e 6y ago
> 2. I like to use Poly/ML for automatic builds during development and MLton for "production" builds Do you have/use any dependencies? Like a http/2 (or tls capable) web server, a database client or a gui library? If you do, how does that work with two implementations - if not... What kind of programs do you write/problems are you solving?

dtornabene 6y ago

Just want to push back a bit and leave a dissenting view on ML for the Working Programmer. If one actually works their way through the text, by the end they will have written a basic interpreter for the lambda calculus, and a small tactics oriented theorem prover, either one of which is highly illuminating to someone who hasn't done this before. The text may not educate a reader on dependent type theory or similar developments but I'm struggling to understand how it is otherwise "dated". Other than that thank you for keeping SML in front of people, I for one appreciate it, its probably my favorite language these days

eatonphil 6y ago
I see your point. I guess it's just the title that has turned me off even after reading the book. It doesn't seem to send the right message these days if the idea is that working programmers are building lambda calculus interpreters or theorem provers? Even interpreting a lisp would seem more practical. I think Practical Common Lisp was more in the right track for content but today I'd focus more explicitly on language design or backend system design. Andrew Appel's book does already fill the language design slot though nicely.