Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- prog:qual-ambiente-escolher [2023/01/18 21:41] – [Aprender a programar é um projeto por si só] remoção de redundância hrcerq
+++ prog:qual-ambiente-escolher [2024/12/28 00:22] (atual) – [Qual ambiente de programação escolher?] legibilidade hrcerq
@@ Linha 1: / Linha 1: @@
 ====== Qual ambiente de programação escolher? ======
-Por vezes no canal //#mundo-libre// do [[howto:comandosirc-unreal#conectar_em_um_servidor|Servidor IRC do Slackjeff]] se iniciou a discussão sobre qual ou quais linguagens e ambientes de desenvolvimento de software seriam mais interessantes para aprender. Muitas pessoas chegam ao canal com uma sede de conhecimento (que particularmente considero louvável), mas sem uma clareza de qual conhecimento priorizar. Evidentemente, não há uma resposta pronta para esta questão. Uma linguagem adequada para uma situação pode não ser boa para outra, assim como diferentes implementações de uma mesma linguagem poderão ser voltadas para usos diferentes. Facilmente você se perderá nas escolhas, se pensar que há uma única solução universal para todos os problemas.
+Por vezes no canal //#mundo-libre// do [[howto:comandosirc-unreal#conectar_em_um_servidor|Slackjeff IRC]] se iniciou a discussão sobre qual ou quais linguagens e ambientes de desenvolvimento de software seriam mais interessantes para aprender. Muitas pessoas chegam ao canal com uma sede de conhecimento (que particularmente considero louvável), mas sem uma clareza de qual conhecimento priorizar.
+Evidentemente, não há uma resposta pronta para esta questão. Uma linguagem adequada para uma situação pode não ser boa para outra, assim como diferentes implementações de uma mesma linguagem poderão ser voltadas para usos diferentes. Facilmente você se perderá nas escolhas, se pensar que há uma única solução universal para todos os problemas.
 Porém desconfio de que no fundo não é uma resposta pronta que você busca, mas sim algumas dicas sobre como pode chegar a essa resposta por conta própria. Este artigo é uma tentativa (espero que bem sucedida) de guiar o leitor a não apenas uma, mas a várias decisões satisfatórias, cada qual para as situações e desafios que se apresentarem. Para isto, vamos discutir alguns princípios básicos.
@@ Linha 19: / Linha 21: @@
 ===== Como dialogar com as máquinas =====
-Muito bem, agora você abriu a sua mente para todas as possibilidades de aprendizado, e decidiu tomar uma decisão não contaminada por discursos simplistas, que não lhe convem. Isso é um grande passo, mas ainda assim, essas possibilidades são muitas. Como resolver isto? Para começar, precisamos eliminar uma outra confusão, que diz respeito a linguagens e implementações. Talvez você já tenha se deparado com os termos “linguagem compilada” e “linguagem interpretada”. Tratam-se de termos não muito corretos pois uma linguagem de programação, antes de mais nada, é apenas uma linguagem e isso tem pouca relação com o modo como ela será traduzida para linguagem de máquina, ou seja, instruções em forma de dígitos binários (bits), que controlarão o dispositivo utilizado.
+Muito bem, agora você abriu a sua mente para todas as possibilidades de aprendizado, e decidiu tomar uma decisão não contaminada por discursos simplistas, que não lhe convém. Isso é um grande passo, mas ainda assim, essas possibilidades são muitas. Como resolver isto? Para começar, precisamos eliminar uma outra confusão, que diz respeito a linguagens e implementações. Talvez você já tenha se deparado com os termos “linguagem compilada” e “linguagem interpretada”. Tratam-se de termos não muito corretos pois uma linguagem de programação, antes de mais nada, é apenas uma linguagem e isso tem pouca relação com o modo como ela será traduzida para linguagem de máquina, ou seja, instruções em forma de dígitos binários (bits), que controlarão o dispositivo utilizado.
 Essa estratégia de tradução pode variar significativamente para uma mesma linguagem, de modo que ela pode ser interpretada ou compilada, a depender da implementação utilizada. Evidentemente, algumas linguagens são pensadas especificamente para uma estratégia, não sendo muito adequadas para outras. Seja como for, linguagens tem uma relação mais forte com a arquitetura lógica dos programas, ou seja, **como interpretar e conectar ideias**. Implementações, por outro lado, tem relação mais forte com a arquitetura física, ou seja, **como traduzir essas ideias para bits**, que por sua vez terão uma representação física, como impulsos elétricos ou ondas eletromagnéticas, por exemplo (varia conforme o meio de transmissão e armazenamento desses bits).
@@ Linha 25: / Linha 27: @@
 Então vamos detalhar um pouco mais o que as implementações fazem. No processo conhecido como compilação (que a rigor ainda pode ser subdividido em algumas tarefas), o código-fonte é convertido para bits em sua integralidade, previamente à execução do programa. No processo de interpretação, por outro lado, os comandos do programa são traduzidos dinamicamente, isto é, enquanto o programa está em execução. A interpretação tende a ser mais lenta, e a depender do tipo de tarefa a ser executada, essa diferença de desempenho pode ser imperceptível ou absolutamente inviabilizadora. Ainda uma terceira estratégia relativamente comum é chamada de compilação em tempo de execução (compilação JIT, na singla em inglês, Just In Time), na qual partes do programa são compiladas enquanto ele executa, aproveitando algumas estatísticas coletadas durante a execução.
-Tipicamente, linguagens de mais baixo nível (isto é, que proveem menos camadas de abstração entre a linguagem de programação e instruções binárias) são usadas em implementações que recorrem à compilação, porém não há uma regra explícita sobre isso. Além disso, pode ocorrer de algumas linguagens possuirem apenas uma implementação e algumas implementações contemplarem apenas uma linguagem, mas não se deixe enganar por casos assim, pois é muito comum (talvez até mais comum) que haja relações múltiplas entre linguagens e implementações, muitas vezes envolvendo estratégias diferentes para cada combinação.
+Tipicamente, linguagens de mais baixo nível (isto é, que proveem menos camadas de abstração entre a linguagem de programação e instruções binárias) são usadas em implementações que recorrem à compilação, porém não há uma regra explícita sobre isso. Outro fato que merece destaque é o de que é muito comum que uma linguagem possua várias implementações diferentes, cada qual com um objetivo em particular. Isto pode ocorrer, por exemplo, quando uma implementação compila o código, enquanto outra interpreta, e assim essas implementações seriam úteis em situações diferentes.
 Escolher uma linguagem e uma implementação **depende muito do que você planeja fazer**, em primeiro lugar. Então, primeiro de tudo, você precisa compreender quais são as premissas e restrições em jogo, envolvendo requisitos de desempenho, segurança, manutenibilidade, compatibilidade, portabilidade, interoperabilidade e usabilidade. Saber tudo isso quando você tem um projeto bem definido pela frente já é uma tarefa complexa por si só, que dirá quando você não possui nenhum projeto no radar e apenas quer aprender a programar. Isto nos leva ao próximo tópico.
@@ Linha 67: / Linha 69: @@
 Essas perguntas não são difíceis de responder com uma breve pesquisa, e são altamente reveladoras. Compreender o contexto em que uma linguagem e suas implementações surgem ajuda a compreender em que cenários ela tende a ser mais eficaz. Ao longo do tempo essas linguagens vão evoluindo e podem ser adaptadas para novos cenários. **Compreender as características** de uma linguagem e de suas implementações que a fazem ideal para um contexto ajudará a entender se serão adequadas também para o seu contexto em particular.
-Essas características dirão muito sobre os tipos de aplicações que se pretende construir. Existem diferentes arquétipos que você pode considerar para o seu programa, e a linguagem escolhida pode se encaixar melhor ou pior nesse arquétipo. O livro Structure and Interpretation of Computer Programs (vide referências) possui em seu preâmbulo uma interessante alegoria sobre programas que são construídos como pirâmides e programas que são construídos como organismos vivos.
+Essas características dirão muito sobre os tipos de aplicações que se pretende construir. Existem diferentes arquétipos que você pode considerar para o seu programa, e a linguagem escolhida pode se encaixar melhor ou pior nesse arquétipo. O livro //Structure and Interpretation of Computer Programs// (vide referências) possui em seu preâmbulo uma interessante alegoria sobre programas que são construídos como pirâmides e programas que são construídos como organismos vivos.
 Pirâmides são gigantescas estruturas, formadas por blocos pesados e muito difíceis de mover (pra não dizer impossíveis). Ao longo do tempo elas vão sofrendo mudanças, mas essas mudanças são pequenas e graduais, e leva muito tempo para que uma pirâmide mude significativamente o seu aspecto. É uma estrutura criada para durar. Organismos, por outro lado, sofrem diversas mutações ao longo da vida. Eles vão se adaptando conforme o meio onde vivem e assim garantem sua sobrevivência, ou perecem, quando não são capazes de fazê-lo. Perceba o caráter antagônico dos dois arquétipos aqui expostos: no primeiro a grande virtude é a **rigidez**, no segundo é a **flexibilidade**.