Isn't this problematic? Lispers fling around lots of superlatives, as if their favorite language will never be dethroned from its position atop the language kingdom. And they always felt justified about this.
Shouldn't we confront them about this?
I do think there's a science of programming languages which can inform us how to best design the tools we use. Isn't it just possible that these Hindley-Milner languages are the next step in the progression that LISP started?
Look at the transition from Newtonian to Einsteinian mechanics. They were both great at the time of release, but one is clearly a step forward. The former is usually embeddable within the latter, but edge cases in the former don't quite work the same in the latter. And some cases in the former are just downright illegal in the latter. And unfortunately, the latter is a lot more complex for the power users. But, the latter is more expressive, teaches us more about the world... and enables completely new possibilities like nuclear fusion/fission.
This is like the difference between dynamic and static typing. Dynamic typing is certainly embeddable within Haskell. Just define a data type Dyn which is the sum of types Int, String, Float, [Dyn], and Dyn -> Dyn. You will see how much LISP is possible without much added syntactic cruft. But Haskell users don't need and want to operate in this way, because they can leverage the benefits of static typing.
Remember, these things don't come from whims of clever people or corporations. LISP and Haskell both come from research of very fundamental ideas. his is much more like real science than social science. And we should keep our eyes open to the future of this field, instead of proclaiming that we're finally done with our "100 year language".
There isn't some unified continuum of power in languages, though. There are some problems for which a H-M-ish type system is a tremendous advantage, and there are others for which it gets in the way. Same with lazy evaluation - it can make a problem much simpler or much harder to reason about. Sometimes using a language built from the ground up to support distributed and concurrent programming (e.g. Erlang), unification and backtracking (Prolog), or constraint programming is the right tool for the job. Sometimes being able to work close to the Unix kernel or run on an embedded system without an OS is more important.
Languages are a means to an end -- they help manage complexity while solving a problem. There's value in being able to extend a language's semantics to support a superset of several major language families, but unless handled very carefully, it can turn the host language into a sprawling mess in the process.
That's why we need a language with a scalable type system that supports both static and dynamic typing. (Actually VB had that years ago with Variant data types, but the rest of the type system was horrible.)
I suspect it might be fruitful to do static analysis for constraints, with type identity as just one attribute. While inferring that X is an int is useful, inferring that it's an int which is always positive and less than 256 would allow a lot of other optimizations. Even if an inference engine can't completely prove something is always a (string * int list) pair, it would still be useful to know that it's (string * (either int or double) list), and the list cannot be empty. Etc. Type declarations or inference are a bit all-or-nothing, and I think being able to read through the properties that the compiler could infer (or at least confirm) would help find bugs, suggest optimizations, etc.
If I ever get past the first dozen projects on my list, I'd like to write a compiler for a dialect of Prolog designed with constraint analysis in mind. (I also need to read more about what's already been tried, first - this is just me being curious about how far constraint analysis could go and wondering out loud.) It would be tricky, but more feasible with Prolog-like semantics than in, say, C.
Isn't it just possible that these Hindley-Milner languages are the next step in the progression that LISP started?
It's possible they've discovered interesting ideas, but they're not on the line of development Lisp started. They grow more out of the Algol tradition.
I don't think anyone has ever proclaimed "we're finally done with our 100 year language." That would be extremely unlikely. The question is more which present languages are on the path to it.
Dynamic typing is certainly embeddable within Haskell. Just define a data type Dyn which is the sum of types Int, String, Float, [Dyn], and Dyn -> Dyn. You will see how much LISP is possible without much added syntactic cruft. But Haskell users don't need and want to operate in this way, because they can leverage the benefits of static typing.
An enumerated type (as you describe) is very simple to implement, but true dynamic typing is a bit more complicated, and there's some constructs from dynamically-typed languages which can't be expressed within the bounds of Haskell's type system.
The Data.Dynamic[1] module is a pretty good implementation of dynamic typing in Haskell, but it's still a bit awkward to use compared to a language which supports dynamic typing natively (eg Python).
Well, I'm arguing from the Bob Harper standpoint that untyped lambda calculus is simply a mode of use of typed lambda calculus. That is, untyped lambda calculus is typed lambda calculus with exactly one type.
Now, neither LISP nor Haskell are just lambda calculus... but I look at Haskell as a bigger language that subsumes most of LISP.
Lazy evaluation. Template Haskell. Quasiquotations (EDSLs). The GHC API. (Liskell.)
I believe between them anything Lisp macros can do they can do, though it may not be so easy. (Strangely, we seem to have little need of them, but I will leave it to the reader as to whether this is a Blub situation or regular Haskell is just that good.)
My theory, as someone admittedly inexpert in both Lisp and Haskell but having used both on occasion, is that both are so ridiculously powerful in different ways compared to "normal" languages that very few people ever even reach the point of being comfortable Blub programmers in either, never mind hitting the wall and wondering "what's next?" [0]
Really, how many programmers are out there who simultaneously 1) spend enough time with either language to master it 2) are smart enough to not only realize the language is limiting them, but to invent a new language to surpass those limits 3) aren't heavily tied to their current language 4) have enough spare time to bootstrap a new language with all the associated scaffolding (libraries, &c.) needed for anyone to want to try it?
[0] Feel free to substitute Scheme, an ML dialect, or other related languages into that sentence.
For something going beyond (but including) Haskell, see Curry [1]. Curry marries functional and logic programming, and compiles down to Haskell in recent versions.
But that's a tradeoff you make. If you have anything more than the most rudimentary of basic syntax, macros become hard. Whereas most of the things that Haskell brings to the table can be incorporated into any other functional language.
Comments
Isn't this problematic? Lispers fling around lots of superlatives, as if their favorite language will never be dethroned from its position atop the language kingdom. And they always felt justified about this.
Shouldn't we confront them about this?
I do think there's a science of programming languages which can inform us how to best design the tools we use. Isn't it just possible that these Hindley-Milner languages are the next step in the progression that LISP started?
Look at the transition from Newtonian to Einsteinian mechanics. They were both great at the time of release, but one is clearly a step forward. The former is usually embeddable within the latter, but edge cases in the former don't quite work the same in the latter. And some cases in the former are just downright illegal in the latter. And unfortunately, the latter is a lot more complex for the power users. But, the latter is more expressive, teaches us more about the world... and enables completely new possibilities like nuclear fusion/fission.
This is like the difference between dynamic and static typing. Dynamic typing is certainly embeddable within Haskell. Just define a data type Dyn which is the sum of types Int, String, Float, [Dyn], and Dyn -> Dyn. You will see how much LISP is possible without much added syntactic cruft. But Haskell users don't need and want to operate in this way, because they can leverage the benefits of static typing.
Remember, these things don't come from whims of clever people or corporations. LISP and Haskell both come from research of very fundamental ideas. his is much more like real science than social science. And we should keep our eyes open to the future of this field, instead of proclaiming that we're finally done with our "100 year language".
There isn't some unified continuum of power in languages, though. There are some problems for which a H-M-ish type system is a tremendous advantage, and there are others for which it gets in the way. Same with lazy evaluation - it can make a problem much simpler or much harder to reason about. Sometimes using a language built from the ground up to support distributed and concurrent programming (e.g. Erlang), unification and backtracking (Prolog), or constraint programming is the right tool for the job. Sometimes being able to work close to the Unix kernel or run on an embedded system without an OS is more important.
Languages are a means to an end -- they help manage complexity while solving a problem. There's value in being able to extend a language's semantics to support a superset of several major language families, but unless handled very carefully, it can turn the host language into a sprawling mess in the process.
That's why we need a language with a scalable type system that supports both static and dynamic typing. (Actually VB had that years ago with Variant data types, but the rest of the type system was horrible.)
I suspect it might be fruitful to do static analysis for constraints, with type identity as just one attribute. While inferring that X is an int is useful, inferring that it's an int which is always positive and less than 256 would allow a lot of other optimizations. Even if an inference engine can't completely prove something is always a (string * int list) pair, it would still be useful to know that it's (string * (either int or double) list), and the list cannot be empty. Etc. Type declarations or inference are a bit all-or-nothing, and I think being able to read through the properties that the compiler could infer (or at least confirm) would help find bugs, suggest optimizations, etc.
If I ever get past the first dozen projects on my list, I'd like to write a compiler for a dialect of Prolog designed with constraint analysis in mind. (I also need to read more about what's already been tried, first - this is just me being curious about how far constraint analysis could go and wondering out loud.) It would be tricky, but more feasible with Prolog-like semantics than in, say, C.
Isn't it just possible that these Hindley-Milner languages are the next step in the progression that LISP started?
It's possible they've discovered interesting ideas, but they're not on the line of development Lisp started. They grow more out of the Algol tradition.
I don't think anyone has ever proclaimed "we're finally done with our 100 year language." That would be extremely unlikely. The question is more which present languages are on the path to it.
The Data.Dynamic[1] module is a pretty good implementation of dynamic typing in Haskell, but it's still a bit awkward to use compared to a language which supports dynamic typing natively (eg Python).
[1] http://www.haskell.org/ghc/docs/latest/html/libraries/base-4...
> Isn't it just possible that these Hindley-Milner languages are the next step in the progression that LISP started?
Why do these preclude lisp? It seems to me you're drawing a false dichotomy.
Well, I'm arguing from the Bob Harper standpoint that untyped lambda calculus is simply a mode of use of typed lambda calculus. That is, untyped lambda calculus is typed lambda calculus with exactly one type.
Now, neither LISP nor Haskell are just lambda calculus... but I look at Haskell as a bigger language that subsumes most of LISP.
But, Haskell has no answer to LISP macros.
> But, Haskell has no answer to LISP macros.
Lazy evaluation. Template Haskell. Quasiquotations (EDSLs). The GHC API. (Liskell.)
I believe between them anything Lisp macros can do they can do, though it may not be so easy. (Strangely, we seem to have little need of them, but I will leave it to the reader as to whether this is a Blub situation or regular Haskell is just that good.)
My theory, as someone admittedly inexpert in both Lisp and Haskell but having used both on occasion, is that both are so ridiculously powerful in different ways compared to "normal" languages that very few people ever even reach the point of being comfortable Blub programmers in either, never mind hitting the wall and wondering "what's next?" [0]
Really, how many programmers are out there who simultaneously 1) spend enough time with either language to master it 2) are smart enough to not only realize the language is limiting them, but to invent a new language to surpass those limits 3) aren't heavily tied to their current language 4) have enough spare time to bootstrap a new language with all the associated scaffolding (libraries, &c.) needed for anyone to want to try it?
[0] Feel free to substitute Scheme, an ML dialect, or other related languages into that sentence.
For something going beyond (but including) Haskell, see Curry [1]. Curry marries functional and logic programming, and compiles down to Haskell in recent versions.
[1] http://en.wikipedia.org/wiki/Curry_(programming_language)
The "may not be so easy" part is the trick.
But that's a tradeoff you make. If you have anything more than the most rudimentary of basic syntax, macros become hard. Whereas most of the things that Haskell brings to the table can be incorporated into any other functional language.