
On Jun 18, 10:37 am, Ivan Lazar Miljenovic
"C. McCann"
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