[patrec]

Let's take your static printf as a concrete example. Here's what a not so great error message looks like (ocaml's built in Printf):

  utop # Printf.sprintf "Some int: %d another int: %d" 1 "2";;
  Error: This expression has type string but an expression was expected of type int

Here's what a good error message looks like:

  clang -Wall printf.c
  printf.c:6:52: warning: format specifies type 'int' but the argument has type 'char *' [-Wformat]
     printf ("Some int: %d some other int: %d\n", 1, "2");
                                           ~~        ^~~
                                           %s

Notice how it also highlights the mismatched part in the string-based DSL.

[otini]

The second message is arguably clearer, but I don't think anyone would be really hindered by the first one, especially given that, unlike in C, application of printf have an explicit type:

    # Printf.sprintf "some int: %d another int: %d";;
    - : int -> int -> string = <fun>

I think a general tendency in statically typed languages is that we like to write stuff using only the type system, rather than adding code to the compiler. Same for macros: we will rather have them proved correct by the typechecker than make them raise errors (also it is possible, through exceptions).

But maybe this is detrimental to clarity of errors in some cases. I'd be interested to see how Racket handles errors.

[patrec]

Is it really arguable? I'd be surprised if anyone took longer to fix a bad format string based on clang's output than on ocaml's.

Printf is a trivial example – good output is mostly useful because of ubiquity and C's unsafety.

I believe what sets racket apart is mostly their mix of tech and culture:

- their macro system, whilst being extremely flexible, preserves enough source location information that you can give good error messages

- due to their pedagogic background they care about good error messages took effort to tool for them (e.g. syntax-parse: http://www.ccs.neu.edu/racket/pubs/icfp10-cf.pdf)

By contrast, common lisp and to a lesser extend clojure are also flexible but produce pretty bad error messages (and both have a culture that strongly de-prioritises approachability). This comes at a real productivity cost that doesn't disappear completely even with experience.

In lisp you can write a nice SQL like language or a math DSL without resorting to string parsing. In ocaml you kinda can't because the base syntax isn't that flexible. So I'd expect the problem to be worse and I don't think types are a magic fix. The worst and most voluble compiler error output known to man must be C++ template metaprograming errors.