[algolicious]

I was interested in his response to the question, "What you dislike the most about Lisp?"

I must say that the lack of static typing really gets in the way on larger projects. Being able to confidently change datatypes and function signatures, knowing that the compiler will point out most inconsistencies that you introduce, is something that I've really come to appreciate after working with Rust and Haskell. Test coverage helps, of course, but I'm not a very diligent test writer, and tend to feel that type signatures are easier to maintain than an exhaustive test suite.

[cageface]

I've had the same experience. After working almost exclusively in dynamic languages for ten years I've been back to static typing in Scala, Java and C++ and in many ways its a welcome return. Dynamic languages are great for quickly hacking around small problems but I really appreciate the help of a good compiler and the kind of refactoring that modern IDEs can do in static languages.

[atdt]

Dart takes an interesting hybrid approach, making static typing optional but enforcing it rigidly wherever it is declared. (I'm not sure it originated with Dart, but that's where I encountered it.) This allows you to prototype things quickly without having to fuss about types. Later, when you're satisfied you've got the right idea, you go back and add static typing wherever having the guarantees that it provides would be useful.

I haven't had the chance to try this out yet. I'm sure some people like the fact that their programming language won't put up with fast-and-loose code -- you probably don't want your workout buddy to agree too eagerly to your suggestion that you skip the gym and grab a milkshake instead. But I think it might work for me. I'd be interested to hear about people's experiences, at any rate.

[hkolek]

The google closure compiler does this. You can optionally annotate your javascript functions with type information (JavaDoc style) and the compiler will enforce it. For example:

  /**
   * @param {Function} fn
   * @param {string|null|undefined} str
   */
  foo.bar = function(fn, str) {
      // do something
  }

It is pretty powerful, you can also do some generics-like stuff like "@param {Array.<string>}" to enforce an array with only strings as elements.

[cageface]

I like this idea in theory at least. I think Dylan worked this way too.

It's kind of shame Dylan died out. It seems like it was ahead of its time in many ways.

[BruceM]

Dylan does work in a similar way. One issue is that we don't go far enough yet, particularly with functions, so while you can specify a vector of integers, you can't (yet) specify a function that takes an integer parameter, just a function. We'd like to do something about that this year.

[beza1e1]

Recently, there is some activity to revive Dylan.

http://opendylan.org/

[BruceM]

In fact, we're working towards a new release in the coming month or so. :)

[blue1]

don't you get a similar benefit in common lisp by generously adding declarations? (esp. in sbcl with high levels of SAFETY)

[marijn]

As far as I know, no. You can get SBCL to point out some intra-function inconsistencies through declarations (or, in fact, often even without declarations), but I haven't found a way to make it warn when, outside of function X, I'm calling it with types different from the types associated with the arguments through declarations.

[blue1]

(declaim (safety 3) (ftype (function ({argument types}) {return types}) {function name}))

It checks both at compile time and at run time. I find it great for bug squashing. See http://www.sbcl.org/manual/index.html#Declarations-as-Assert...

[marijn]

That's neat. Thanks. Might be worthwhile for APIs.

[cageface]

I suppose you get at least some of the benefit. The other half of the advantage of a relatively simple statically typed language like Java is that IDEs can do really amazing structural transformations of your code. When I'm working in IntelliJ I'm constantly aggressively refactoring my code in ways I wouldn't dare in a language with less rigid syntax.