Biggest feature of this release seems to be 64bit multicore programming.
My experience with this release so far:
- installation on ubuntu 16.04 worked
- it was very easy to create a statically linked executable and run it on my server
- excellent foreign function interface
- separate compilation mechanism
- multicore support
- record polymorphism
For me it is just great to see how SML# matures as a platform.
The computer gaming market doesn't function like most other markets; the idea of considering that monthly income as recurring indefinitely is rather odd.
Of course, You are absolutely right. The author said he had no idea how to value his work and I was thinking... Hmm, he might try to use financial math formulas such as the NPV as help. If the game makes $9000 profit per year at a discount rate of 3% you could value it:
$8738 ... (makes profit for N years, where N = 1)
$17221 ... (makes profit for N years, where N = 2)
$25458 ... (makes profit for N years, where N = 3)
$41217 ... (makes profit for N years, where N = 5)
$76772 ... (makes profit for N years, where N = 10)
$133897 ... (makes profit for N years, where N = 20)
$284390 ... (makes profit for N years, where N = 100)
And no software is able to make profit for 100 years.
(disclaimer: my calculation might of course be wrong, I didn't put much thinking into it)
Nope, my post was just meant as some random fact. You can easily put a price on an infinite stream of constant payments.
I don't believe the project is able to generate an infinite stream of 750$ payments. But if it could, that would be roughly it's value.
By the way, for an investor it does not matter how much effort (1 year, 5 years, 100 years) the author did put into the project. For the present value of the project only matters what monthly payements there will be. If someone can forecast these payments, he can also put a price tag on the project.
So it might also be, that there is no more interest in the game in one or two months ... then it would be roughly worth 0$ to 750$ (even if it took much effort to implement it).
Huh? You are questioning the commenter's sincerity just based on how often they want to post a comment on HN.
Witch-hunting does not really make HN a better place.
Although SML is such a beautiful and pragmatic language and has many Compilers and Runtimes, I am not aware of any real world projects with impact other than the well-known SML compilers (Mlton, SMLNJ, MosML, Poly ... to only name a few).
Usage of SML results in very short, readable and efficient programs, so I wonder why there is only so little industry adoption.
Most of the people who would be using SML are using Haskell, hence why Robert Harper is so bitter, constantly writing blog posts about how much "Haskell sucks", and how "unsafe" it is.
I'm not sure it is right to speak of "most people". Many people use OCaml these days. For instance, I have the impression that in work on program verification and static analysis OCaml is more popular than Haskell. Coq is written in OCaml, for example. The Haskell community much more vocal though.
Harper has strong opinions, but he has a few points. Haskell may be great, but one should be aware that it is not an improvement on SML in each and every respect. For example, SML has a much better module system than Haskell.
Perhaps OCaml gets a lot of use in that community because a lot of that community is French -- that was my experience, anyway. And a lot of the folks in that community don't seem as vocal (to this side of computing) only because they are using different channels and complaining about different stuff!
It was actually surprising (and somewhat annoying) that Twelf is written in SML.
adaption of ML style languages suffers from the unfamiliar syntax, the pretty steep learning curve for those trained in imperative dialects at 'java-school'.
at least when it comes to syntax mythryl might someday provide an option. its basically SML/NJ with a c-like syntax and multithreading support. still very much in development but looks promising: mythryl.org
that said Haskell certainly seems to be the winner of the current functional language trend.
I don't think people really care about syntax that much. OCaml, F#, Haskell all have similar looking syntax, Scalla has a particularly ugly one (maybe if it wasn't supposed to be C/Java-like it wouldn't have ended like this).
...the only times I heard people bitching about syntax to the point of staying away from a language for it was either about Lisps ("undistinquishable paren soup") or about Python's significant indentation and lack of multiline lambada. MLs have a pretty familiar math-like syntax and apart from some operators seems "normal looking" even for Java and C programmers.
SML# is one of the lesser known SML implementations, although it's a quite good one. The only thing that I found impractical,... you can only link 32bit libs, which is very odd on todays 64bit Systems.
Nevertheless, the thing I like most at SML# is the excellent FFI. You can just pass SML-records or SML-functions to C. SML# is very powerful if you code your applications in SML and C.
The recently released ocaml-ctypes <https://github.com/ocamllabs/ocaml-ctypes > library by Jeremy Yallop does something similar. It uses GADTs to represent the C type system in OCaml's type system with as-you-would-expect OCaml signatures. For example, you can pass an OCaml comparator to a C sort function that takes a function pointer and it works.
It's not quite as smooth, as far as I know, but it will soon include C header consumption and C stub generation to both improve binding accuracy/safety and remove dynamic paths for performance.
Biggest feature of this release seems to be 64bit multicore programming.
My experience with this release so far:
- installation on ubuntu 16.04 worked - it was very easy to create a statically linked executable and run it on my server - excellent foreign function interface - separate compilation mechanism - multicore support - record polymorphism
For me it is just great to see how SML# matures as a platform.