Strong Types and Their Impact on Testing

First of all, from a type-theory point of view, both Email and WebForm have the same type. (same signature).

Also from a theoretical point of view, i think a type should not have an instance if its not valid and "EmailAddress" of value "aasda" should not exists. However it is allowed in his types.

Also, I don't see how defining lots of very specific types such as FromAddress and ToAddress are really making live easier.

Something like this does the job, and is typesafe (in golang):

  type EmailAddress string

  type Email struct {
    to EmailAddress
    from EmailAddress
    subject string
    body string
  }

  func sendEmail(webForm string) err = {
    email, err := validateEmailForm(form) # performs validation
    if err {
      return err
    }
    err := email_service.sendEmail(email)
    if err {
      return err
    }
  }

However, performing validation outside of the model makes it possible to create a model with invalid data. For example, calling val x = EmailAddress("@") would pass. Thus, a developer must remember to call the validation every time they create such a case class. In my experience, this wouldn't hold since developers are as lazy as the code allows them to be.

Instead, why not include requirements directly into a case class constructor. For example:

  case class EmailAddress(addr: String) {
    private val emailRegexp = ...
    require(emailRegex.findFirstIn(addr).isDefined, s"Email $addr not valid")
  }

The only downside is the conversion of these exceptions into Either, Scalaz Disjunctions or Scalaz Validation. Of course, it's not that pretty and idiomatic to convert try-catch blocks into Either. But IMHO, it's a small cost in exchange for the guarantee that if your model exists it must be valid.

I'm not sure how that's something that static typing provides, just seems like good functional programming/referential transparency.

I would just solve that with keyword arguments. Or, in Javascript, have the constructor take an object whose keys are fromAddress, toAddress, etc. (Pretty much the JS/ES5 version of keyword args.)

    validateFrom(form.from).toValidationNel |@| validateTo(form.to).toValidationNel |@| validateBody(form.body).toValidationNel |@| validateRecipient(form.recipient).toValidationNel)(Email.apply)

I'm sure this made perfect sense to someone at the time this decision was made, but naming things this way does absolutely nothing to help someone reading the code or using your library for the first time.

Can anyone explain the motivation for naming things in this way?

Python is strongly typed, although possibly not as much as we might hope. This fails:

    "cat" + 1

I agree with most of what's said in the OP. I just want to push back against the use of "strong" and "static" typing as if they were interchangeable. I'm in the same boat-- generally an advocate for compile-time static typing-- but to conflate static/dynamic with strong/weak is to misrepresent the issue, and unfair to the dynamically-typed languages. All of the modern dynlangs (e.g. Python, Ruby, Clojure) enforce type safety. They just do it at runtime, whereas Haskell, Scala and Ocaml do it at compile time.