1. 4
  1.  

  2. 3

    I know this is sort of comment upsets people, but if you need maintainability that badly, why not use a nice typed language? The app talks about demonstrating best practices - wouldn’t it be nice if you could codify best practices in the form of types and let people pour their code into that, providing underlying infrastructure in a different module as needed?

    Much of my problems maintaining Python and Ruby applications, particularly web applications, was because I didn’t have types. This becomes an insidious problem above and beyond immediate checking at any given moment - it forces more tests that I have to maintain (overhead) and discourages me from refactoring.

    I did Python, Ruby, and Clojure for years, I don’t think it’s worth it anymore to use an untyped language.

    It’s a super silly and tiny example but I wrote a URL shortener in Haskell using Scotty. I also did a literate write-up here.

    I think Yesod has made it clear (at least to me, even though I don’t agree with all of Yesod’s design) that scaling up types to capture intent in web applications is practical and useful today. Even the friggin' routes are type-safe. Dead link -> broken build! That’s fantastic IMO :)

    I use types so I can think less because it lets me offload active work and “memory” to the computer - same reason I write tests. They’re also handy for clearly communicating intent.

    1. 1

      if you need maintainability that badly, why not use a nice typed language?

      Some possibilities:

      1. None of the developers are familiar with a language that is both typed and “nice.”
      2. A lot of work has already gone into the application before they realize that they need those guarantees.
      3. Management isn’t willing to invest in “obscure” languages, for fear that they won’t be able to find enough (inexpensive) developers.
      1. 1

        Advertising a Haskell gig is a good way to get solicitations from a fair number of talented developers. :)

    2. 2

      Before everyone chimes in with “This could be way simpler by….”, I probably agree with you in most cases. In the case where we used this strategy, however, simpler solutions just didn’t give us the flexibility we needed.