> Therefore, simplifying GHC development likely wouldn't attract any larger user base for the language.
I can agree with that. What I meant was more that I see it as a sort of symptom of its complexity. A kind of complexity which causes problems elsewhere.
> Can you elaborate on this? Dynamically typed languages essentially have no type system (but yes even they do have types).
Of course they have a type system. You define types and the types of values determine what you can do with them. That is not different from static typing. It is just that the enforcement happens at runtime.
One example of complexity in static typing is what you get when you try to do any kind of meta programming such as templates or generics.
Perhaps the easiest way to illustrate the problem is to look at the terra language. http://terralang.org
In terra you see Lua serving the same job as the templating language in C++. Yet a typical templating language is very limiting compared to a full blown dynamic language.
With static typing you just very easily end up in a catch-22 situation: What are the types of the types of the types?
For instance in Julia I can write:
A = Int
B = Char
c = 10
bar(name::String) = println("Hello ", name)
foo(x::(c < 10 ? A : B)) = 2+x - 10
Which is kind of complete nonsense code, but it illustrates a few different things which I can trivially do in a dynamic language like Julia but which would be hard in a static language. Here I am storing types in the variables A and B. Then I define a function `foo` which has a specific implementation depending on the type of its single input argument `x`.
In `bar` I specify the type of `name` as String. However in `foo` the type of `x` is evaluated at runtime. When the function definition of `foo` get evaluated, only then do we decide what the type of `x` is.
Here an if statement is used to determine the type of `x`. However I have the availability of the full Julia language to make that decision. I can make multiple functions to do that.
Try something like that in a statically typed language and the type system will tie itself in knots. If you could even support this in a static language, the complexity of describing what I just did in a static language would make most software developers dizzy.
> That is not different from static typing. It is just that the enforcement happens at runtime.
Isn't the inherent problem with dynamically typed languages exactly that they do not enforce types at compile time nor runtime? Like you try to call a method of an object that does not exist, and it crashes the runtime.
Moreover, I'm not sure I get your example. Wouldn't that be just a matter of a union type + parametric pattern matching in a statically typed functional language? You would just get exhaustiveness checks and type safety on top of that for free.
I can agree with that. What I meant was more that I see it as a sort of symptom of its complexity. A kind of complexity which causes problems elsewhere.
> Can you elaborate on this? Dynamically typed languages essentially have no type system (but yes even they do have types).
Of course they have a type system. You define types and the types of values determine what you can do with them. That is not different from static typing. It is just that the enforcement happens at runtime.
One example of complexity in static typing is what you get when you try to do any kind of meta programming such as templates or generics.
Perhaps the easiest way to illustrate the problem is to look at the terra language. http://terralang.org
In terra you see Lua serving the same job as the templating language in C++. Yet a typical templating language is very limiting compared to a full blown dynamic language.
With static typing you just very easily end up in a catch-22 situation: What are the types of the types of the types?
For instance in Julia I can write:
Which is kind of complete nonsense code, but it illustrates a few different things which I can trivially do in a dynamic language like Julia but which would be hard in a static language. Here I am storing types in the variables A and B. Then I define a function `foo` which has a specific implementation depending on the type of its single input argument `x`.In `bar` I specify the type of `name` as String. However in `foo` the type of `x` is evaluated at runtime. When the function definition of `foo` get evaluated, only then do we decide what the type of `x` is.
Here an if statement is used to determine the type of `x`. However I have the availability of the full Julia language to make that decision. I can make multiple functions to do that.
Try something like that in a statically typed language and the type system will tie itself in knots. If you could even support this in a static language, the complexity of describing what I just did in a static language would make most software developers dizzy.