[Haskell-cafe] Re: How does one get off haskell?

[braver]

On Jun 18, 10:37 am, Ivan Lazar Miljenovic <ivan.miljeno... at gmail.com>
wrote:
> "C. McCann" <c... at uptoisomorphism.net> writes:
> I've seen a lot of people claim that there are cases where it's
> easier/better to use dynamic typing than even Haskell-style static
> typing, but have never been given an example or reason why.  Care to
> actually provide one?

Since this is heading for yet another static vs. dynamic typing and
the universe kind of threads, I'd add some dynamic spice.  In the last
two years I've explored, and learned, the following languages for
large-scale data mining: OCaml => Scala => Clojure => Haskell now =>
back to OCaml tomorrow with my graph for now :).  I was seriously
impressed with Clojure for data mining as its dynamism allows to
easily handle any shape of data.  When you slice and dice a huge data
frame (in R parlance), your subsets are vectors or maps of varying
types and lengths; you can also get nulls.   Clojure is made for
this.  Its vectors and maps are first-class citizens, so my graph data
looks like:

{:mandy {1 {:alice 1 :bob 2} 2 {:john 1 :alice 3} ... :bob {...}}

So when your problem is open-ended and the shape of data is in flux, a
dynamic language is faster to prototype.  If, on the other hand,
you're at PHB's whim and some specs and types are handed around, then
static approach is natural from the beginning.  The NPEs are still
very annoying, but it all kind of works in the end.  The choices are
often dictated by external library availability, accepted usage, etc.
I can see Haskell an excellent replacement for a majority of Python/
Ruby/Java/C# situations if you have the manpower, including the
bosses'; Scala or Clojure when on JVM, F# when on .NET.  In fact
mixing Clojure and Scala projects allows a good dynamic vs static
balance in a similar functional style, with some excessive OO in Scala
for those who miss it.

-- Alexy