3 ms·
> It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this
by dserban 12y ago
> It is easy to cover the spectrum with these and I don't see where Haskell would be a better fit. maybe somebody could shed some light on the strengths of this ecosystem.
One of Haskell's unique selling points is the fantastic ease with which you can build software that is correct-by-construction and concise at the same time.
For someone I'm mentoring, I recently came up with two examples of this [1][2].
I don't have time ATM to explain all the details (maybe someone else does), but based on them I intend to write in the near future a blog post titled "Using the expressive power of Haskell's type system to build software that is correct-by-construction". I'll submit the link to HN when that happens.
It will be part 3 of this[3] ongoing series.
[1] https://gist.github.com/dserban/11176875 https://gist.github.com/dserban/11176875
[2] https://gist.github.com/dserban/11139419 https://gist.github.com/dserban/11139419
[3] http://techblog.rosedu.org/haskell-part2.html http://techblog.rosedu.org/haskell-part2.html
- BasDirks 12y agoThis is not idiomatic code. Briefly: data Inches = MkInches Double deriving (Eq,Show) There is newtype for this. (MkInches u) \+/ (MkInches v) = MkInches ( u + v ) First two pairs of parens are redundant. from_inches_to_cm vin = MkCm (vin_as_pure_double * 2.54) where (MkInches vin_as_pure_double) = vin Surely you want: inchToCm (MkInches x) = MkCm (x * 2.54) In Haskell we use camelCase. Besides these fairly trivial mistakes there are simply better approaches for dealing with units.