Nos últimos quatro anos, basicamente desisti da ideia de que o .NET é um runtime de várias linguagens.
- A chamada escolha entre as duas linguagens mais populares, C# e VB.NET, é não é mais significativa do que a escolha entre Coca-Cola e Pepsi. Sim, IronPython e IronRuby são linguagens dinâmicas significativamente diferentes, mas estão em algum lugar no horizonte e longe de serem cidadãos de primeira classe do IDE.
- Há simplesmente o muito atrito cognitivo ao traduzir para frente e para trás entre esses dois idiomas muito, muito semelhantes. Ponto e vírgula ou sublinhado? Sensibilidade ou insensibilidade a maiúsculas e minúsculas? Parênteses ou colchetes? Matrizes que começam em um ou matrizes que começam em zero? To-may-to ou to-mah-to? Simplesmente não vale a pena o esforço mental que custa acompanhar todas essas pequenas diferenças que podem prejudicá-lo tão facilmente.
- Misturar o código-fonte em diferentes idiomas é, na melhor das hipóteses, incômodo. O senhor precisa separar cada idioma em seu próprio projeto compilável. Separados, mas iguais. Mais ou menos isso. Bem, na maioria das vezes.
- A maior parte da comunidade adotou o C# como o padrão de fato, portanto, o senhor terá que enfrentar um árduo trabalho de tradução de código se quiser ficar com o VB e integrar de forma limpa as bibliotecas de código-fonte comumente disponíveis em sua base de código. E se o senhor quiser entender o código que o senhor está absorvendo em seu aplicativo (observação: isso não é realmente opcional em minha experiência), é melhor aprender a lê-lo sem um monte de ginástica de tradução mental. E quando tiver aprendido a ler e escrever a linguagem bem o suficiente para integrá-la, o círculo estará completo. Assim como eu, o senhor ficará se perguntando por que não cortou totalmente a pena de tradução e ficou com um único idioma.
Isso não quer dizer que o senhor não possa desenvolver várias linguagens no .NET. Mas, na maioria das vezes, não vale a pena o incômodo. É menos doloroso acompanhar o rebanho e escolher o C# como todo mundo faz. Em sua maior parte, Aprendi a aceitar e fingir que o C# é a única linguagem .NET. Admito até com relutância que terminar explicitamente as linhas com ponto-e-vírgula é muito melhor do que a mistura de retornos de carro e sublinhados que temos no VB.NET. Mas ainda há duas coisas que me deixam louco no C#.
O primeiro é o mal da sensibilidade a maiúsculas e minúsculas. Como defensor das pessoas em detrimento das máquinas, tenho que deixar registrado que a diferenciação de maiúsculas e minúsculas em uma linguagem de programação está errada e será sempre estar errado. Sei que a decisão está gravada em pedra neste momento e que nunca vai mudar, então vou deixar isso para lá. É a uma questão religiosae nós, desenvolvedores de software, somos nada mais do que religiosos. Vamos em frente.
A segunda é o imposto de compilação do C#. Quando trabalho em C#, estou constantemente compilando a solução para garantir que não quebrei nada. É um imposto de produtividade ridículo em um loop infinito: Escrever um código. Compilar. Escrever um pouco mais de código. Compilar. Alterar uma função. Compilar. Renomear uma variável. Compilar. Refatorar alguns métodos. Compile. Em seguida, compilar novamente, só para ter certeza. Espere um segundo… já compilei isso? Compile!
O senhor percebe um padrão aqui? Vou desgastar prematuramente minhas teclas CTRL, SHIFT e B. Ao programar em C#, sinto-me como um macaco em uma gaiola que distribui ração quando pressiono CTRL+SHIFT+B. É uma completa perda de tempo, mas o senhor é obrigado a fazer isso por meio de incentivos perversos no IDE.
O que é particularmente triste nisso é que, na minha experiência, a maioria dos desenvolvedores de C# acha que a compilação manual o tempo todo é um estado natural das coisas. Bem, não é. No VB.NET, temos o seguinte tecnologia inteligente chamamos compilação de histórico. A compilação em segundo plano poupa o esforço de toda essa compilação manual sem sentido, repetitiva e entorpecente. É muito simples: enquanto digita, imagine todo esse processo de CTRL+SHIFT+B acontecendo automaticamente em segundo plano para o senhor.
Com compilação de antecedentes, Sei imediatamente quando cometi um erro. Não preciso esperar até a próxima vez em que chamarei o compilador manualmente. Digamos que eu digitasse o seguinte código C#:
string s; s = 1;
Bem, esse código parece bom no editor. Até que eu compile. Compare isso com o equivalente em VB.NET:
Dim s As String s = 1
No momento em que eu terminar de digitar a atribuição (por exemplo, mover o cursor para fora da segunda linha), a instrução será sinalizada como uma atribuição inválida. Não é necessário fazer compilação; ela aparece automaticamente como um sublinhado ondulado no plano de fundo.
Esse é um exemplo reconhecidamente trivial, mas a compilação em segundo plano facilita muito minha vida no VB.NET. Ela reduz o tempo de resposta entre o erro e a correção a praticamente nada. E o senhor pode fazer outras coisas inteligentes com ela, como renomear rapidamente uma função ou variável para ter uma ideia de onde ela está sendo referenciada por meio da pilha de erros do compilador que aparece. Se não fosse isso, seria uma coisa a menos que eu teria de lembrar de fazer: ah, sim, o IDE do C# me mostra problemas básicos de sintaxe, mas tenho de compilar meu C# para ver o que está acontecendo. realmente quebrado. Isso não parece que o trabalho desnecessário para o senhor? Para mim, com certeza é.
A compilação em segundo plano é algo que, diferentemente da sensibilidade a maiúsculas e minúsculas, é não é escrito em pedra, e possivelmente poderia ser corrigido. Trata-se de um recurso do IDE, não da linguagem. Esperamos que a equipe do C# acabe por corrigi-lo. reconheça a enorme perda de produtividade da taxa de compilação do C# para o desenvolvedor médio. Se alguns desenvolvedores são masoquistas que odeiam a produtividade, então torne a compilação em segundo plano uma opção configurável que eles possam desativar. Eles podem marchar em passos largos, de volta à sua roda de dor interminável de CTRL+SHIFT+B. Mais poder para eles.
Pessoalmente, prefiro deixar o computador fazer o trabalho pesado de compilação em segundo plano. Livre da onerosa taxa de compilação, não mais invocando compulsivamente o compilador a cada poucos minutos, posso passar mais tempo me concentrando em meu código.
Talvez eu tenha aceitado a penitência do C#, mas gostaria que os santos da Microsoft concedessem esse pequeno desejo a um pecador convertido do VB.NET.