Lisp is not the same paradigm: it's imperative and eager where Haskell is lazy and pure functional.
The languages support different means of abstraction. e.g., Lisp has macros, Haskell has all that type inference enables. I can't honestly say that being able to (effectively) use the return type of a function as a parameter to that function is better than being able to invoke macros with the same syntax as a function call --- but it suits me better.
True, Haskell isn't a lisp clone. But it is functional nevertheless. More 'purely' functional too.
So why do people, who have ignored functional programming in lisp for all these years suddenly taken to lisp?
Is they Hype-field around Haskell really that strong?
Static type systems are evolving rapidly and becoming so powerful they are close to merging with algebraic specifications (e.g. OBJ, CASL). They will (soon) have type/proof systems that will become the foundation for all future engineering of large reliable systems. Why would you make an application author write unit tests on the outside of a weak language, when you can verify from inside of a strong one ? Why would you even wrap a weak language with an incomplete informal poorly specified unit test generator, when you can verify it rigorously inside the type system of strong language ?
Along with convergence of languages and tools, there is also a recognition that isolation of side effects and composition of operations are the fundamental mechanisms for building large software systems from reusable components, and Category Theory is the formalism for describing composition. For example, in the Haskell community there is an ongoing exploration of the compositional properties of isolation primitives like Monads, Arrows, Applicative Functors and Comonads (yeah, Category Theory terminology is a barrier to progress). Haskell is not the final language, but it is the medium in which the correct path is being discovered. I would also say the move from Java to Scala is also a step in the right direction of more powerful type systems and a (more) functional approach.
On the Lisp side, there has always been a cacophony of variations, and people might have had high hopes for Arc, but the future is Clojure.
Interesting that the two most innovative recent languages, Scala and Clojure, have been built on the JVM.
6 comments
[ 2.7 ms ] story [ 13.2 ms ] threadThe languages support different means of abstraction. e.g., Lisp has macros, Haskell has all that type inference enables. I can't honestly say that being able to (effectively) use the return type of a function as a parameter to that function is better than being able to invoke macros with the same syntax as a function call --- but it suits me better.
Readability counts!
Along with convergence of languages and tools, there is also a recognition that isolation of side effects and composition of operations are the fundamental mechanisms for building large software systems from reusable components, and Category Theory is the formalism for describing composition. For example, in the Haskell community there is an ongoing exploration of the compositional properties of isolation primitives like Monads, Arrows, Applicative Functors and Comonads (yeah, Category Theory terminology is a barrier to progress). Haskell is not the final language, but it is the medium in which the correct path is being discovered. I would also say the move from Java to Scala is also a step in the right direction of more powerful type systems and a (more) functional approach.
On the Lisp side, there has always been a cacophony of variations, and people might have had high hopes for Arc, but the future is Clojure.
Interesting that the two most innovative recent languages, Scala and Clojure, have been built on the JVM.