Codificadores gerenciados x codificadores nativos

Sou codificador e tenho experiência com código nativo e gerenciado. Comecei com Pascal e C, depois mudei para C ++ e, eventualmente, para C #.

Durante o último ano, estive codificando quase exclusivamente em C # e perdi muito do que costumava acontecer naturalmente quando eu era um codificador C ++.

Algumas semanas atrás, quando me sentei para escrever algum código C ++ nativo, me peguei remexendo quando lentamente me familiarizei com as complexidades, peculiaridades e idiossincrasias de tudo isso. Estou quase com vergonha de dizer que tinha esquecido completamente que passar uma matriz alocada dinamicamente para uma função sem também passar seu tamanho significaria que a função de recebimento não teria como saber quanto tempo a matriz é.

Existem inúmeros artigos e documentos que comparam e contrastam código gerenciado versus código não gerenciado. Todos sabemos que o código nativo, se bem otimizado, pode executar significativamente mais rápido e mais leve que o código gerenciado. Por outro lado, o código gerenciado possui coletores de lixo e otimização específica da CPU e do SO em tempo de execução, o que pode dar ao código nativo uma execução pelo seu dinheiro.

Puramente do ponto de vista técnico, não há um vencedor claro.

Não há dúvida de que o código gerenciado é de ordem de magnitude mais simples de codificar e entender. Veja a diferença no número de linhas necessárias para construir uma GUI simples no Win32 C ++ vs C #.

Nos meus dias de codificação nativa, escrevia principalmente simulações matemáticas que rodavam em supercomputadores. Eles tinham CLIs feias e eram principalmente focados em algoritmos. Atualmente, escrevo em C # e produzo belos aplicativos GUI, mas ficaria perdido se eu precisasse criar um calibre semelhante em um idioma nativo. Mesmo com uma estrutura como QT, ainda levaria o dobro do tempo para produzir algo em C ++ / QT do que em C #.

Sempre que vejo alguém que escreveu um aplicativo GUI completo e em grande escala em C / C ++, não posso deixar de sentir uma sensação de reverência e uma pitada de ciúmes.

Estou curioso para saber como outros codificadores experientes veem idiomas gerenciados e não gerenciados. Você vê o código gerenciado como amador ? Você vê codificadores nativos como mais hardcore ?

Atualmente, meu trabalho diário é em C ++, mas já programei em várias línguas o suficiente para que eu quase não perceba mais a diferença. Aqui estão minhas observações:

• Muitas das alegadas ineficiências com outros idiomas são frequentemente reimplementadas pelos programadores de C ++ como práticas recomendadas. Adicionamos verificações nulas suficientes, verificação de limites de matriz, verificação de tipo, validação de entrada etc. para negar em grande parte qualquer vantagem de velocidade de execução obtida pelo idioma que não faz essas coisas automaticamente, pelo menos para códigos que não exigem muito processamento de dados.
• Esse clichê extra se torna um hábito arraigado depois de um tempo, para que realmente não pareça um trabalho extra e se destaca como um dedão dolorido quando está faltando.
• Quando programa em uma linguagem "gerenciada", ainda penso na alocação de memória, para garantir que não crie um vazamento de memória. Talvez eu não esteja explicitando delete, mas ainda estou ciente do ponto em que o coletor de lixo considera elegível para exclusão. Eu tive mais dificuldade em resolver problemas de pouca memória começando em Java do que em C ++, provavelmente porque em C ++ eles são muito mais difíceis de ignorar por muito tempo.
• O mesmo vale para a digitação dinâmica. Ainda tenho que acompanhar se um parâmetro de função é uma matriz, um int ou uma string. De fato, requer mais esforço mental, porque o tipo não está claramente listado ali para mim.
• O estilo C ++ moderno é muito diferente da era anterior ao C #. Em vez de mudar a linguagem, as pessoas "descobriram" como usar os recursos C ++ existentes de maneiras exclusivas para evitar grande parte do gerenciamento de memória servil do passado. Padrões de design que liberam memória automaticamente são muito comuns agora.
• Até onde eu sei, mesmo que seja possível criar aplicativos GUI apenas escrevendo código, designers gráficos como QT designer são o método amplamente preferido, com código usado principalmente apenas para manipuladores de eventos ou personalização de tempo de execução.
• Os idiomas que você não usa extensivamente há algum tempo sempre parecem um pouco desajeitados, mesmo que você se lembre da sintaxe. Se eu não escrevo python há um ano, há muitas idiossincrasias que esqueci, e parece mais estranho que o C ++ por um tempo, mesmo que objetivamente a maioria das pessoas considere o python a linguagem "mais fácil".

Com a combinação de todos esses fatores, meu modelo mental permanece bastante consistente entre quando eu programa em C ++ e outras linguagens, e as diferenças parecem principalmente meramente sintáticas. É verdade que muito disso é resultado de treinamento, hábito, padrões de codificação e padrões de design modernos, em vez de recursos intrínsecos à própria linguagem C ++, mas a comparação ainda permanece.

Acho que o que estou tentando dizer é que, na minha experiência, o treinamento do programador faz muito mais diferença do que o idioma que ele está usando.

Você vê o código gerenciado como amador? Você vê codificadores nativos como mais hardcore?

Não.

Eu vejo as diferenças entre um engenheiro e um programador. O engenheiro hardcore sempre escolhe a pilha de idiomas / tecnologia apropriada para realizar o trabalho no menor tempo possível, com um padrão de tempo de execução aceitável.

Com a potência do processador atualmente, a frequência de realmente precisar obter o máximo possível de uma máquina usando idiomas nativos de nível inferior está ficando cada vez menor. Geralmente, não há realmente um caso comercial para isso. A produtividade sempre supera a diferença de alguns milissegundos no tempo de execução.

Infelizmente, a Microsoft nos levou a confundir o "Código gerenciado" com as bibliotecas de classe C # / .net.

Há duas coisas separadas e quase não relacionadas em jogo aqui.

1. Bibliotecas .Net legais.

2. Código gerenciado.

O C # oferece um pacote organizado, com suporte e fácil de usar por um preço.

O C ++ possui inúmeras bibliotecas legais que fazem quase tudo o que o .Net faz. Em vez de culpar o código "C ++ nativo" por ter mais "complexidades, peculiaridades e idiossincrasias" do que o código C # / .net, você pode procurar por melhores bibliotecas C ++.

Bibliotecas melhores também permitem que você escreva um bom código C ++.

Sempre que vejo alguém que escreveu um aplicativo GUI completo e em grande escala em C / C ++, não posso deixar de sentir uma sensação de reverência e uma pitada de ciúmes

Política ruim. Em vez disso, você deve descobrir quais bibliotecas de definições de classe elas usaram. Você também pode usar essas bibliotecas.

É tudo sobre as ferramentas. Sem ferramentas, somos apenas animais de calça.

"C ++ nativo" não significa que você deve jogar fora todas as suas ferramentas. Isso significa que você precisa encontrar boas ferramentas. A Microsoft não está mais ajudando você, então você precisa gastar tempo encontrando a combinação certa de ferramentas.

A questão aqui não é sobre programação hardcore ou algo assim, é sobre controle. O fato é que o C # oferece produtividade a um custo de controle. Se você estiver escrevendo um programa que precisa de uma grande quantidade de controle (essa memória está desalocada exatamente agora), não terá outra opção a não ser usar C ++. Se você precisar fazer isso rapidamente, pode ser necessário usar o C #. O problema é que as bibliotecas de suporte para C # são muito melhores e mais recentes que as fornecidas para C ++. Por exemplo, o MFC é muito, muito antigo e suas práticas são conhecidas por serem terríveis; ele foi escrito muito antes da padronização. Se a Microsoft se esforçar para fornecer novas bibliotecas C ++, por exemplo, confira o novo PPL no Visual Studio 2010 e, estranhamente, essa tarefa se torna fácil no C ++. E acho que eles estão migrando dessa maneira,

Por outro lado, o código gerenciado possui coletores de lixo e otimização específica da CPU e do SO em tempo de execução, o que pode dar ao código nativo uma execução por seu dinheiro.

Já ouvi muitos defensores da linguagem gerenciada dizerem isso, mas na verdade nunca vi isso verdade. O fato é que as novas instruções de CPU disponíveis em CPUs mais novas simplesmente não oferecem muita vantagem, a menos que você esteja praticando matemática muito pesada; nesse caso, você não pode se dar ao luxo de precisar compilar ou interpretar em execução -time e você pode usar o compilador C ++ da Intel para usar o mais recente e o melhor no SSE de qualquer maneira. O escopo das otimizações do compilador do C ++ é enorme comparado ao que o JIT pode fazer, porque o JIT precisa ser executado em uma fração do tempo enquanto o programa está sendo executado, enquanto os compiladores do C ++ são bastante lendários por levar o tempo necessário para compilar.

A coleta de lixo não é um tipo de coisa mágica ou algo parecido - é uma escolha de algoritmo. É apropriado para todas as situações? Nem por um momento, observe a confusão IDisposable em C # e como o Java nem se deu ao trabalho de tentar resolver esse problema, enquanto os destruidores do C ++ fecharão seus arquivos e liberarão sua memória e seus soquetes etc. O GC é ótimo para alguns programas. , e não para alguns outros.

Na minha opinião, o C / C ++ nativo, comparado ao C #, parece um assembler para o próprio C / C ++. Outra camada complexa de abstração (não totalmente verdadeira, mas digamos assim) como sempre, oferece um desenvolvimento mais fácil, mas com certa redução de velocidade e uso excessivo de memória. Então, a meu ver, é apenas dividido em categorias diferentes, criando assim novos subtipos de programadores.

Btw por seu nível de abstração C # é incrivelmente rápido, a Microsoft fez um excelente trabalho.

Existem programadores amadores, não idiomas amadores. Idiomas que eles têm todos (bem, a maioria deles pelo menos) seus propósitos.

Atualmente, estou trabalhando em um mecanismo de cálculo de seguro usado para testar o sistema de produção. O sistema de produção foi fabricado em C, nosso mecanismo é feito em Java e, desde há mais tempo, superamos o mecanismo C, sendo ao mesmo tempo muito mais produtivo. Não porque o Java em si seja mais rápido que o C, é rápido o suficiente e nossos algoritmos são melhores, nós os implementamos mais facilmente, poderíamos testar mais rapidamente e melhor e refatorar nosso código.

Também escrevi código de teste para comparar os resultados do cálculo com o conteúdo do banco de dados de produção: não em C, não em Java, mas em Ruby. Novamente, é rápido o suficiente e precisa de muito menos código, por isso é mais fácil de implementar, mais fácil de testar e mais fácil de expandir.

E não me sinto amador, não importa qual idioma eu use, me sinto assim apenas se eu fizer um bug estúpido que não deveria ter acontecido.

No ano passado, a empresa em que trabalho trabalhava na engenharia reversa de um código CRC de comunicações por força bruta (finalmente conseguimos). 3 Cada desenvolvedor tinha sua própria versão, Borland C, C # .Net 2008, VB6. O VB6 era obviamente lento, o Borland C foi rápido, mas o C # .net o açoitou 12 vezes a velocidade. Não era o que esperávamos.

Depende de uma mistura de coisas, mas basicamente, tudo o mais é igual, sim, o código nativo é mais "hardcore" do que o código gerenciado.

Acho que isso geralmente é uma coisa ruim para um aplicativo comercial normal, porque significa que o desenvolvedor médio deve colocar mais energia mental nos aspectos não comerciais do código.

Meu programa é o que poderia ser melhor descrito como C ++ como Java. Minha opinião é que você pode obter a mesma programação de baixo nível em Java, mas é muito mais difícil que a programação de baixo nível em C ++. No entanto, você geralmente precisa dessa programação de baixo nível em uma pequena fração do seu código e, onde não é necessário, uma linguagem gerenciada é mais produtiva.

Os desenvolvedores nativos geralmente obtêm a reputação de serem mais hardcore, porque se sentem mais hardcore e agem dessa maneira. Os desenvolvedores nativos são treinados em um sistema que não tolera erros, porque inevitavelmente levam a falhas graves ou vazamentos ilimitados de memória. Em particular, o .NET permite hacks preguiçosos, como colocar try / catch em torno de tudo, evitando que o desenvolvedor pense que eles precisam entender o problema principal (" às vezes, apenas lança InvalidOperationException. Não sei explicar, vamos pegar tudo. Isso código é crítico! "). Isso não é totalmente preto e branco, mas minhas observações cresceram no mundo não gerenciado e agora trabalham em código gerenciado em período integral.

Além disso, os desenvolvedores gerenciados também tendem a ter acesso a BCLs muito mais limpos e organizados. Isso geralmente os incentiva a explorar o que realmente acontece debaixo das cobertas. É verdade que o mesmo pode ser dito para, digamos, STL ou Boost, mas a biblioteca de classes .NET geralmente é boa o suficiente para nos tornar intelectualmente preguiçosos às vezes.

Dito isto, escrever um programa gerenciado bom e entregável exige muito trabalho. Isso significa fazer perfis de memória e CPU, testes de unidade e análise de código de maneiras semelhantes às que os desenvolvedores não gerenciados fazem. Desenvolvedores não gerenciados tendem a entender isso, e desenvolvedores gerenciados tendem a incluir mais daqueles que não o fazem.

Novamente, não preto e branco. Existem muitos desenvolvedores não gerenciados intelectualmente preguiçosos e desenvolvedores gerenciados hardcore. Nem por definição é mais elite que o outro.

Você vê o código gerenciado como amador? Você vê codificadores nativos como mais hardcore?

Há uma lacuna entre os dois países, e não consigo entender o porquê: os sistemas gerenciados estão escritos em algum lugar no código nativo (como final, tudo é executado "em assembly"). O que eu quero ver (ainda na minha vida) é um sistema de construção de aplicativos, no qual toda a subtarefa do aplicativo será escrita no tipo de idioma correto.

O código nativo ficou mais fácil desde que o Go foi lançado. Acho mais fácil ler e escrever do que Java e C #. Embora a programação da GUI com o Go, a partir de agora, não seja muito agradável (dei uma olhada rápida nas opções).
Tente não julgá-lo por sua falta de comunidade grande e variedade de bibliotecas em comparação com o C # (por exemplo), porque ainda é considerado novo.