É bom viver sem saber como o programa que você criou funciona?

Quero dizer, existem bibliotecas realmente úteis que podem resolver problemas quando você está parado e não sabe como resolver isso ou aquilo com seu conhecimento da linguagem de programação que você usa ... Por exemplo, Boost for C ++ ou JQuery for JavaScript ou Spring for Java ... Eles resolvem problemas em segundos e você realmente não se importa com o que eles fizeram (apesar de serem escritos na mesma linguagem em que você está programando) ... Então, eu me pergunto se estou sozinho usando libs enquanto não estou sendo capaz de escrever soluções para meus problemas do zero ou é uma prática padrão?

Tudo bem não entender como resolver os problemas e usar as bibliotecas?

Em geral, não, não é.

Uma biblioteca pode poupar o trabalho (difícil!) De descobrir como resolver um problema, depurar a solução e mantê-la. Mas, se você for usá-lo, é melhor você entender como funciona - por que a solução realmente resolve o problema. Você não precisa saber como inventar carros, motores e robôs que constroem motores de carros, se estiver trabalhando como mecânico - mas entenderia melhor como as peças funcionam, o que todas elas fazem e como elas funcionam. se encaixam!

Essa é a razão pela qual você verá muitas pessoas se tornarem muito especializadas - muitas vezes aprendendo apenas a trabalhar com um único idioma, uma única plataforma, uma única estrutura e um conjunto de bibliotecas.

Dito isto, há muito que você terá tempo para aprender. Às vezes, você precisa usar atalhos - use-os, mas saiba que são atalhos. Talvez você só tenha lido o suficiente sobre uma biblioteca para saber que poderia descobrir, se tivesse tempo. Ou talvez você só descubra as duas funções que realmente precisa chamar e apenas o suficiente para fazer as chamadas corretamente. Esse é um atalho, que terá um preço - geralmente mais tarde, quando alguém (talvez um mais velho e mais experiente) precise corrigir o código.

Uma vez que computerworld.com.au perguntou a Bjarne Stroustrup "Você tem algum conselho para programadores em ascensão?"
E ele respondeu"Conheça os fundamentos da ciência da computação: algoritmos, arquiteturas de máquinas, estruturas de dados, etc. Não copie cegamente técnicas de aplicativo para aplicativo. Saiba o que você está fazendo, se funciona e por que funciona. Não pense que você saiba qual será a indústria daqui a cinco anos ou o que você fará então, então reúna um portfólio de habilidades gerais e úteis.Tente escrever um código melhor e com mais princípios. Trabalhe para tornar a "programação" mais uma atividade profissional e menos atividade de "hacking" de baixo nível (a programação também é um ofício, mas não apenas um ofício) Aprenda com os clássicos no campo e os melhores livros didáticos avançados; não fique satisfeito com o "como" facilmente digerido guias e documentação on-line - é superficial. "
Espero que esclareça suas dúvidas sobre o que é necessário para umVerdadeiro programador e o que é necessário para qualquer um ser um.

Sim - e todos fazemos isso!

Vamos pegar, por exemplo, um bug muito simples que eu estava corrigindo em algum código gráfico relacionado ao Mac. O código em torno do bug envolveu várias etapas:

1. Primeiro, um método Objective C aloca um buffer de pixel usando malloc () e o anexa ao seu objeto Objective C.
2. Mais tarde, algo acontece e uma rotina C envia uma mensagem ao objeto Objective C e recupera o buffer de pixel.
3. A rotina C compacta o conteúdo do buffer de pixel usando jpeglib e o envia por uma conexão TCP / IP.

Há muita coisa acontecendo lá! Aqui estão algumas coisas:

• Um alocador de memória dinâmico para implementar malloc (), que assume que a memória é fisicamente contígua e linearmente endereçável.
• O sistema de memória virtual do kernel Darwin subjacente para mapear a RAM física fragmentada e o espaço em disco (que é um dispositivo físico diferente da RAM), em algo que aparece no alocador de memória dinâmica como se fosse uma RAM fisicamente contígua e linearmente endereçável.
• Sistema de objetos do objetivo C
• O sistema de mensagens de tempo de execução do Mac OS e a maneira como ele interage com os objetos do Objective C
• A implementação da biblioteca jpeglib do padrão de compactação de imagem com varredura com perda JPEG, que usa um algoritmo discreto de transformação de cosseno
• A rotina de rede do espaço do usuário para o envio de dados, que são realizados através das várias implementações de protocolo TCP e IP, que, por sua vez, são chamadas no kernel do SO. Então, dependendo do que você ativou na sua rede, ele pode chamar um driver para a porta Ethernet, um chip wi-fi ou, mais incomumente, um driver USB ou Firewire.

Você entende todos os detalhes de como todas essas coisas são realmente implementadas? Eu com certeza não! Duvido que existam muitas pessoas no planeta que o façam - talvez até nenhuma. Então eu simplesmente não me preocupo com isso.

Mas é bom ser curioso e aprender pelo menos um pouco sobre as bibliotecas e ferramentas que você usa. Quando comecei a programar, sabia que compiladores e sistemas operacionais não podiam ser mágicos, mas eles certamente me pareciam assim. Ao satisfazer minha curiosidade por essas coisas, aprendi muito e tive uma ótima carreira até agora.

Acho que a principal razão pela qual usamos as bibliotecas é não "reinventar a roda" o tempo todo, abstraindo os problemas que eles pretendem resolver. Você pode tentar resolver os problemas sozinho, mas isso levaria mais tempo.

No entanto, sinto que também precisamos saber ou adivinhar como o problema é resolvido pela biblioteca. Isso geralmente está documentado na documentação do usuário da biblioteca e, com o software de código aberto, você sempre pode consultar o código.

Além disso, geralmente resolvemos problemas abstraindo as partes difíceis de qualquer maneira, por que não está tudo bem?

As bibliotecas estão lá para fornecer soluções para problemas comuns. Você precisa decidir se eles resolverão o problema específico que você está resolvendo. Eles não são um substituto para não saber como resolver um problema. Por exemplo, suponha que seu aplicativo exija uma tabela de hash, você deve ter conhecimento suficiente para entender qual o problema que uma tabela de hash está resolvendo. Você deve poder avaliar o desempenho da biblioteca que está usando para decidir se ela funcionará ou não no seu aplicativo. Acredito que usar uma biblioteca para cobrir conhecimento técnico inadequado não é o caso de uso correto. A decisão de usar uma biblioteca deve girar em torno de saber se o uso da biblioteca acelerará ou não o desenvolvimento e fornecerá uma solução testada e confiável. A decisão de usar uma biblioteca não deve girar em torno da incapacidade dos programadores de resolver um determinado problema.

Depende de você, sério .

Quanto melhor você entender as ferramentas com as quais está trabalhando, melhor poderá tirar proveito delas.

Por exemplo, raramente uso o jQuery, mas quando preciso sei o que tirar proveito dele e como posso coexistir com outras estruturas, como o Mootools.

Além disso, em breve vou me aventurar no gamedev com o UDK, e tenho certeza de que quanto mais eu entender sobre isso, mais poderei dobrá-lo com minha má vontade, mas também poderia seguir tutoriais fáceis de entender. Eu escolho o primeiro, apenas um pouco de tempo extra e ciclos cerebrais, e obterei resultados melhores e mais fáceis .

É importante conhecer seu domínio e sua parte do processo.

Por exemplo, digamos que você esteja usando uma biblioteca de processamento de imagens. Você realmente precisa saber tudo sobre borrões, transformações e espaços de cores gaussianos? Não. Mas você precisa saber por que está usando a biblioteca em primeiro lugar. Ou a função de classificação de uma estrutura. Você precisa conhecer o algoritmo de classificação real usado? Na maioria dos casos, não. Mas você precisa saber por que precisa dos dados classificados.

Por outro lado, se você estiver escrevendo um compilador, sabe muito bem como funciona um compilador, já que essa é sua parte no processo.

Certas estruturas, como o jQuery, abstraem bastante. Você precisa saber exatamente como eles estão funcionando? Não. Mas ter um entendimento forte e fundamental do que a biblioteca está fazendo será muito benéfico para você ao escrever o código, porque você entenderá melhor por que a estrutura é feita do jeito que é e poderá usá-la em todo o seu potencial. .

De acordo com minha experiência: como você não pode eliminar a dependência da biblioteca, você e sua equipe devem saber o suficiente para resolver o problema.

Como programadores, temos pouco tempo, então devemos escolher o que tem maior prioridade. O problema deve ser resolvido, o mais rápido e gentil possível. Somente esse motivo torna o "aprender tudo sobre as coisas" um tanto redundante.

O que eu quero adicionar aqui é "dependência". Como comunidade, todos somos dependentes dos outros. Nós apoiamos os Giants para construir nosso aplicativo: Java, .NET, API ... E confiamos nos Giants sobre seu trabalho; porque funciona para muitas pessoas. Se você tiver um problema sobre a estrutura ou API, há uma boa chance de que outras pessoas tenham enfrentado isso em algum lugar, e há uma solução / solução alternativa.

O único problema aqui: talvez, em algum lugar, em um critério restrito, os gigantes entrassem em colapso. Por exemplo, o flash não é suportado em alguns sistemas operacionais e há muitas coisas que não poderíamos fazer sem ele. Essa possibilidade é mais que zero, mas, neste caso, temos pequenas coisas que podemos fazer. Somente nesses casos, o conhecimento sobre "o que está por trás dos panos" se mostra útil, pois aponta onde o problema realmente está e pode criar uma grande solução alternativa; mas não sei se o tempo que investimos realmente vale a pena.

Para lidar com essa possibilidade, acho que há uma solução: porque a maioria dos programadores pode facilmente captar o "trabalho superficial" de uma biblioteca, e apenas às vezes precisamos de alguém que seja muito compreensivo: vamos dividir a equipe para fazer isso. Tentando fazer parte de uma equipe que cada um experimentou cerca de 1,2 bibliotecas / ferramentas úteis / "conjunto de habilidades" envolvidas : uma tem boa experiência com jQuery, outra especializada em banco de dados, ... Isso ajudará muito a minimizar riscos.

Outro ponto de vista é segurança. Quando você usa uma biblioteca da qual não conhece exatamente o funcionamento interno, faz suposições sobre o que está acontecendo exatamente. Cada suposição com falha pode abrir um vetor de ataque para um invasor mal-intencionado.

Ao chamar um Quicksort, você deve estar ciente do pior comportamento possível. Caso contrário, um invasor poderá injetar dados do pior caso e executar um DoS.

Ao chamar uma biblioteca de compactação, lembre-se de que quando alguns dados são compactados em menos bytes, deve haver dados que "compactam" em mais bytes que o original. Portanto, quando você supõe que o buffer de saída precisa apenas do tamanho dos dados de entrada porque compacta [para menos bytes], existe um estouro de buffer aguardando a ocorrência.

Você deve conhecer fundamentos suficientes sobre as coisas que fará, para poder provar suas suposições. Caso contrário, a biblioteca deve cuidar explicitamente disso, por exemplo, lançando uma exceção quando o buffer de saída fornecido não for grande o suficiente.

Não há problema em não entender tudo o que você usa, desde que tenha certeza de que funciona. Depois que você é mordido por um bug na lib, há tempo para ver como funciona, por que funciona e por que não funciona. Claro que você é sempre bem-vindo e incentivado a olhar por baixo do capô, mesmo que não precise.

Uma das coisas difíceis da programação é superar a tentação de resolver todos os problemas por si mesmo.

Está tudo bem, mas é perigoso. Como prática geral, deve-se saber trabalhar o que ele desenvolveu.

Meio ...

Tudo bem desde que você tenha uma idéia geral do que a biblioteca ou estrutura está tentando fazer. Quanto às partes internas e o que não é então, não. Adote a abordagem pragmática. Funciona, fez o que eu quero, tudo bem.

O ponto é não se surpreender com vários pequenos detalhes e apenas implementar sua maldita idéia.

Eu acho que o ponto é que você não vai saber tudo. Sério, você tem tão pouco tempo para investigar tudo, porque isso o distrairá do seu principal objetivo de criar essa sua idéia. Pouco a pouco, talvez, você possa reservar um tempo livre no fim de semana para ler um capítulo ou mais sobre o assunto.

Mas não tente descobrir tudo, a menos que você tenha muito tempo livre ... Olhe dessa maneira. A razão para as linguagens de programação é a proteção que impedimos de executar o código de montagem, a razão para o código de montagem é que protegemos de fazer 1 e 0. Eu não acho que você precise conhecer todos os detalhes do mecanismo por trás dele, mas apenas conhecer a essência geral dele. Como um coletor de lixo, eu sei que ele vai lidar com meus ponteiros / memória, não me importo com o algoritmo magicamente elegante que ele usa, apenas sei que funciona (para o que eu preciso) e que não faz mais nada. Talvez o engodo disso, mas eu. A menos que você esteja no campo em que precisa lidar com isso. Então você não faria essa pergunta de qualquer maneira, porque faz parte do seu trabalho haha.