Por que o mundo .Net parece adotar cordas mágicas em vez de alternativas de tipo estático?

Então, eu trabalho no .Net. Eu faço projetos de código aberto em .Net. Um dos meus maiores problemas não é necessariamente o .Net, mas a comunidade e as estruturas em torno dele. Parece que em todos os lugares que esquemas e seqüências de nomes mágicos são tratados como a melhor maneira de fazer tudo. Declaração em negrito, mas veja:

MVC do ASP.Net:

Olá rota mundial:

        routes.MapRoute(
            "Default",                                              // Route name
            "{controller}/{action}/{id}",                           // URL with parameters
            new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
        );

O que isso significa é que o ASP.Net MVC irá, de alguma forma, procurar HomeControllerno seu código. De alguma forma, crie uma nova instância e, em seguida, chame a função Index aparentemente com um idparâmetro de algum tipo. E depois há outras coisas como:

RenderView("Categories", categories);
...or..
ViewData["Foobar"]="meh";

E também existem coisas semelhantes com o XAML. DataContexté tratado como um objeto e você tem que esperar e orar para que ele resolva o tipo que você deseja. As DependencyProperties devem usar seqüências de caracteres mágicas e convenções de nomenclatura mágica. E coisas assim:

  MyData myDataObject = new MyData(DateTime.Now);      
  Binding myBinding = new Binding("MyDataProperty");
  myBinding.Source = myDataObject;

Embora confie mais no elenco e em vários suportes mágicos de tempo de execução.

Enfim, digo tudo isso para terminar aqui: por que isso é tão bem tolerado no mundo .Net? Não estamos usando linguagens de tipo estaticamente para quase sempre saber qual é o tipo de coisa? Por que a reflexão e o tipo / método / propriedade / quaisquer nomes (como seqüências de caracteres) preferem tanto em comparação a genéricos e delegados ou até mesmo a geração de código?

Há motivos de herança que estou faltando, por que a sintaxe de roteamento do ASP.Net depende quase exclusivamente da reflexão para realmente resolver como lidar com uma rota? Eu odeio quando mudo o nome de um método ou propriedade e de repente as coisas quebram, mas não parece haver nenhuma referência a esse método ou propriedade e, é claro, não há erros de compilação. Por que a aparente conveniência das cordas mágicas foi considerada "vale a pena"?

Eu sei que também existem alternativas tipicamente tipadas para algumas coisas, mas elas geralmente ficam no banco de trás e parecem nunca estar em tutoriais ou outro material para iniciantes.

Na verdade, há um empurrão no mundo .NET contra essas mesmas coisas que você mencionou. No primeiro exemplo que você deu, no entanto, o mecanismo de roteamento recebe uma convenção para mapear a rota padrão. O fato de as rotas serem dinâmicas torna quase impossível o uso de uma configuração estática.

Você também mencionou o XAML / WPF, ambos em desenvolvimento bem antes da introdução dos genéricos no .NET e voltar ao suporte aos genéricos atrasaria ainda mais um produto já muito tardio (Longhorn / Vista).

Existem exemplos na estrutura do ASP.NET MVC de usar expressões lambda no lugar de seqüências de caracteres mágicas e o Entity Framework / LINQ leva ainda mais longe onde a linguagem e a estrutura fornecem suporte nativo para compor consultas SQL em um gráfico de objeto estático (em vez de construir seqüências mágicas de SQL, você obtém a validação em tempo de compilação de suas consultas).

Para outros exemplos de configuração estática, consulte o mapa de estrutura e outros contêineres modernos de injeção de dependência e outras estruturas que precisam inspecionar o gráfico de objetos em tempo de execução, mas permitem que o desenvolvedor forneça sugestões estaticamente usando expressões lambda.

Portanto, a resposta curta é que, historicamente, o .NET não suportava a travessia estática de um gráfico de objetos até a versão 3.5. Agora que o temos, muitos desenvolvedores preferem isso a seqüências de caracteres mágicas e muitos têm buscado um suporte ainda mais profundo, como um operador symbolOf que funciona de maneira semelhante ao operador typeOf.