> I think this comes down to low ceremony vs high ceremony One of the most cited qualities of languages like Haskell are their "refactorability" - i.e. one can

> I think this comes down to low ceremony vs high ceremony One of the most cited qualities of languages like Haskell are their "refactorability" - i.e. one can routinely rip out the guts of a 100KLOC codebase and replace fundamental data structures and functionality in order to implement new features in a couple of hours, no problem whatsoever. In Rails, I'd do everything in my power to not touch any "important" code if I can get away with it, because no matter how good the test suite, it's still a test suite. It shows the existence of bugs, it doesn't prove their absence. Many people claim that's not a problem in practice, but I personally tend to avoid more fundamental code changes in dynamic codebases precisely because of that fact. To drive that point home, I'd trust a Haskell codebase without a test suite more than a Rails codebase with an average to good test suite. Also, it seems to me that "moving fast" is directly at odds with the topic at hand, upgrading Rails. If Rails allowed one to move fast, then surely upgrading Rails shouldn't take a year and a half, even in a big codebase? > Spec driven design seems to offer some of the benefits of static typing with the flexibility of dynamism. Definitely, though it's not a replacement for types. Also, the probably more important thing here is that Clojure is functional, making a whole class of bugs stemming from mutability and OOP impossible. If you're planning to go down the Clojure/spec route, you might want to check out Ghostwheel [0], a lightweight DSL which seems to be gaining a lot of traction lately. [0] https://github.com/gnl/ghostwheel https://github.com/gnl/ghostwheel