Hacker News new | ask | show | jobs
by nabla9 4533 days ago
Why not both?

ghc compiler in Haskell has -fdefer-type-errors flag. SBCL Common Lisp implementation has option to turn type warnings into errors. Extending -fdefer-type-errors function and creating better type checker for dynamic languages could achieve best of both worlds.
2 comments
ufo 4533 days ago
The actual reason for why not both is that its actually very hard to do and is still kind of an open problem. Some things are easy to do statically but hard to check dynamically (for example, parametric polymorphism or type-based overloading and name resolution) and some things are easy to check dynamically but hard to specify using static types (for example, array bounds checking).
link
nabla9 4533 days ago
You can do those things that are easy to do statically at development/testing time and those thing that are easy to do dynamically in runtime.

Some things like overloading based on return values don't work dynamically, but you could either choose to not have them or resolve them in development time. I would like to see languages where dynamic vs. static is continuum and programmers can determine how much they need want case by case basis.

link
ufo 4533 days ago
> You can do those things that are easy to do statically at development/testing time and those thing that are easy to do dynamically in runtime.

But then you lose the ability to freely mix and match the static and dynamic code. For example, if you want to write a dynamic implementation for some parametrically polymorphic code there must be a way to check at runtime that the dynamic implementation is respecting the type that you assigned to it (there are ways to do that but they are all very tricky).

The list of tricky things also grows very quickly once you put some though into it. You mentioned return type polymorphism but there are also many other things that are hard to check dynamically (record field names) and lots of things that dynamic codes likes to do (like mutability and subtyping) that force extra complexity into the static type system or that can be used to subvert the static types if you are not careful.

link
coolsunglasses 4533 days ago
>(for example, array bounds checking)

It's relatively easy to do this statically compared to bringing the benefits of Haskell to a unityped language. We just don't program in languages designed around dependent types typically.

Dependent types aren't hard.

Agda, Idris, Coq for any who are curious as to what that looks like.

Total functional programming is cool ^_^

link
ufo 4533 days ago
You are right. The biggest problem I was trying to point out is that you need to make your static type system much more complex in order to be able to even state some things that are easy to check dynamically. Also, dependent types on their own dont solve the problem of interfacing with dynamic code.
link
emiljbs 4533 days ago
I agree. Good dynamic languages (Common Lisp, Smalltalk, Factor) has a lot going for them but static typing is also really nice. A mix between the two (preferably something that starts out as a dynamic lang and slowly moves towards being static) would be great (Common Lisp kinda does this with optional static typing).
link
aidenn0 4533 days ago
CL's type system has a few warts to really do static typing well.

For a language that truly hass optional static types see Shen[1]

[1] http://shenlanguage.org/

link