Se você é um programador em linguagem de alto nível, que esta mais no ramo de aplicações comerciais ou utiliza algum tipo de ferramenta case, pra você, talvez isso não importe muito, afinal se a tela demorar 0.2s ou 1.2s, pro usuário não faz diferença, ele não vai notar, mesmo que demorasse 2s, ou até 3s, já que ele esta acostumado a esperar o Windows carregar, esperar a pagina carregar, esperar o programa iniciar, pra ele é normal esperar um pouquinho. E pra você que diferença faz, se pra abrir uma tela do seu programa, que emite a nota fiscal, o PC tiver que executar 100 mil instruções de máquina que não estão diretamente relacionadas ao que seu programa tem que fazer, por exemplo, coletor de lixo, checagem de pilha/heap e tantas outras coisas, afinal 100 mil instruções não significa nada em termos de tempo, já que as cpus modernas rodam a 3GHz ou mais, executar 100 mil instruções de máquina a mais, cada vez que abre a tela de notas fiscais não é nada, e também se cada registro da nota fiscal no banco de dados pudesse ocupar 10K no disco, na melhor das hipoteses, mas esta ocupando 20K, e dai, hoje temos discos da ordem de Terabytes, então isso talvez não faça muito sentido pra você. Já se você é daquele tipo de programador que já teve curiosidade de desassemblar uma função ou trecho de código que você fez pra ver no que se transformou o seu código e aquele if que você colocou na sua lógica, como é que fica em linguagem de máquina, e notou que quando se coloca inline na frente da função o compilador não gera as instruções necessárias para empilhar os parametros e nem a chamada da função, e que isso faz uma boa diferença, se a função for chamada inúmeras vezes, dentro de um loop por exemplo, então, você é do tipo de programador que vai entender do que eu to falando.
Me sinto como um mestre de obras (programador), em um canteiro de obras Chines, tendo a planta do prédio (problema a ser resolvido) só na minha mente, tendo que passar as instruções aos operários (core´s da cpu), sobre o que construir e o que cada um deve fazer (cada core da cpu), tendo que escrever em forma de verso e prosa (linguagem de programação), e traduzir isso pro mandarim usando google translator (compilador)(tradução ao pé da letra). Neste cenário, a única forma de saber se os operários entenderam o que deve ser feito é ver o resultado (testar/depurar o executavel), e claro, nada vai ser exatamente como o esperado a princípio, após sucessivas interações de comunicação com os operários, reescrevendo as instruções e revendo os resultados obtidos (testes/depuração/correções), é que vão surgindo o resultado desejado, mas quase sempre a um custo e prazo além do razoável.
Penso se há meios de melhorar essa comunicação, gostaria de sussurrar ao invés de ter que gritar do outro lado do quarteirão o que o computador tem que fazer. É como se eu estivesse em um prédio de 50 andares (software em camadas) tentando falar com um cara na calçada lá em baixo (cpu) !!!!
Recentemente li em um livro (Como quebrar códigos. Greg Hoglund/Gary McGraw) que a estimativa de bugs em um software fica entre 5 a 50 por 1000 linhas de código e que o Windows XP tem aprox. 40 milhões de linhas de código, logo, no melhor caso, estamos falando em estimados 200 mil bugs. Não tenho bases para comparar, mas se na construção de um software como o Windows XP, foi necessário, em termos de número de programadores, horas/homem e investimento, algo similar ao necessário para executar projetos de engenharia, como por exemplo, a construção das torres Petronas, na Malásia, ou a maior torre de TV do mundo, em Guanzhou, na China, seria como se logo após concluída, a estrutura apresentasse infiltração de água em dias de chuva, rachaduras em algumas paredes, a falta de algumas janelas e a presença de algumas portas onde não deveria existir, pra ser bem otimista. Isso me leva a questionar se as ferramentas e as metodologias que temos a disposição hoje, realmente ajudam a fazer softwares melhores e com poucos defeitos numa escala tão grande quando a demanda atual por software no mundo, e infelizmente, a resposta me parece ser NÃO.
Isso me leva a crer que a disciplina de desenvolvimento de software não evoluiu na mesma proporção que outras engenharias. Muitos classificam a atividade de programação como arte, algo abstrato e imprevisível. À mim, me parece mais estar ligada a área de exatas, em especial á area de engenharia, como a mecânica, a civil, a naval e a aeroespacial. Nestas temos softwares CAD (Desenho "Assistido por Computador") que permitem a visualização em 3D do produto/estrutura e nos permite simular e prever o seu comportamento antes mesmo da construção. Na programação não temos nada parecido com uma visualização 3D do programa que estamos construindo, muito menos um desenho assistido (CAD) que nos permita simular seu comportamento diante das forças a que será submetido (usuários, hackers, so, etc), na fase de projeto, antes de ser construído. Seguindo esta analogia o desenho de projeto de engenharia evoluiu da prancheta para o software CAD e as ferramentas e linguagens de programação, evoluiram em que direção ?
É obvio que as ferramentas e linguagens de programação evoluiram, desde os primórdios da programação em Assembler, mas me parece que não na mesma direção das engenharias e nem do hardware onde são executadas, me parece que evoluíram em direção ao ser humano, ao tentar humanizar a relação entre o programador e a máquina, ao criar linguagens cada vez mais próximas a linguagem natural do ser humano, cada vez mais abstratas. Isso a meu ver criou um abismo entre a forma como o programador vê o mundo e a solução do problema que deseja resolver (pensando em objetos, por exemplo) e as instruções computacionais necessária a solução desde problema da forma que a maquina entende. Para fazer a ponte existem os compiladores, que cada vez mais avançam para realizar a visão abstraída que o programador tem do mundo a sua volta e transformar essa visão em instruções de máquina realizáveis. Mas, perai, estamos escrevendo código para ser executado por outras pessoas ou executados por máquinas ?
Não quero dizer com isso que deveriamos voltar a quebrar pedra (programar em assembler), não seria produtivo, mas sim, que as ferramentas e as linguagens não evoluíram no mesmo sentido da evolução do hardware. Já se perguntou, por que o hardware é cada vez mais rápido e o Windows é cada vez mais lento !?!? será que é culpa exclusivamente dos programadores da Microsoft, ou o problema tem raizes mais profundas ? Será que parte do problema pode estar na qualidade do assembler que é gerado pelos compiladores, em seu esforço em vão de otimizar e tentar transformar em linguagem de máquina um código fonte cada vez mais abstrato ? Será que o problema pode estar na incompatibilidade dos paradigmas de programação que promovem a abstração da solução do problema, ao agrupar a informação em objetos, sem levar em conta o ambiente real e físico (tempo de acesso á memória, cache multinível, multicore, tempos de acesso a disco) onde isso vai realmente ser executado ?
Tenho a impressão que apesar da evolução das ferramentas e linguagens de alto nível, ainda estamos numa era pré revolução industrial. Vejo que o sofware ainda é feito de maneira artesanal, em grande parte, por indivíduos (programadores), ou pequenos grupos de artesãos (equipes de desenvolvimento), agrupados em aldeias (empresas). Quando vejo alguma empresa entitulada "fábrica de software" não consigo visualizar uma linha de produção como a que Henri Ford idealizou para a produção do Ford T, com analistas, arquitetos, designers, programadores, testadores, enfileirados em uma linha de produção contínua, parece mais uma grande aldeia, ou até uma cidade, de artesãos.
Como a "lei de Moore" de dobrar a capacidade a cada 18 meses, esta cada vez mais difícil de ser seguida pelos fabricantes de processadores, penso que em algum momento no futuro ira ficar cada vez mais evidente a necessidade de se repensar a forma como é feita o software, as metodologias e as ferramentas, pois atualmente, a direção atual da evolução das ferramentas e linguagens de programação nos leva cada vez mais a demandar por mais velocidade de processamento, para realizar as mesmas coisas.
Penso se não seria hora de voltar atrás, aos primórdios da computação e seguir uma linha evolutiva diferente da atual, na área de linguagens de programação e metodologias, que levaria mais em conta os avanços em hardware neste período e a interação humana da máquina com o programador num nível mais natural, baseado em tecnologias atuais, chega de escrever cartas para o computador (codigo fonte), para explicar o que queremos que ele faça, melhor seria mandar um desenho técnico, não acha. Penso em uma interação mais visual (gráfico), tátil (multitoque) ou quem sabe até vocal (comando de voz) do que textual, como por exemplo, ferramentas que nos forneçam um ambiente gráfico dos componentes computacionais (memoria, cache, cpu, armazenamento, interface do usuário) e nos permita interagir (programar) entre eles sem dispor de uma linguagem textual, mas mantendo a característica de baixo nível com alto nivel de produtividade e voltada para modelar a interação deste componentes físicos, orientado aos dados e não a objetos, ou seja, programar num nível mais realístico e físico em detrimento de abstrações e outras distrações. Tecnologia pra isso já existe, temos exemplos de multitoque e comando de voz no iPad/iPhone respectivamente, não se trata de utopia.
Alem disso penso nos benefícios que uma abordagem mais realista da programação de computadores, pode trazer no campo dos testes automatizados, da otimização do código, da melhoria da qualidade associada a um programa menor, que contenha somente as instruções de máquina necessárias à solução do problema. Qual seria o impacto no número de defeitos por 1000 linhas de código, díficil dizer, mas divagando um pouco, se 1000 linhas de código em linguagem de alto nível, teoricamente falando, representam talvez 4000 instruções de máquina, se com uma abordagem mais objetiva, consiga-se reduzir o número de instruções pela metade, estamos falando em uma redução de 50% nas expectativas de falhas e bugs, essa mesma linha de raciocínio aplicada em larga escala (40 milhões de linhas de código) a redução é significativa, sem falar em redução de tempo de processamento entre outras coisas.
Pergunta
alhm
Recentemente li 3 artigos fantásticos sobre o funcionamento do cache L1 e L2 (http://igoro.com/archive/gallery-of-processor-cache-effects/), sobre o impacto que o paradigma de orientação a objeto tem sobre os tempos de acesso á memória, a perda do cache e os impacto disso no programa como um todo (http://research.scee.net/files/presentatio...ing_GCAP_09.pdf) e sobre Programação Orientada a Dados (http://gamesfromwithin.com/data-oriented-design). E isso me fez refletir se estamos realmente usando as melhores práticas de programação ou se muito disso não passa de ilusão ou abstração da realidade.
Se você é um programador em linguagem de alto nível, que esta mais no ramo de aplicações comerciais ou utiliza algum tipo de ferramenta case, pra você, talvez isso não importe muito, afinal se a tela demorar 0.2s ou 1.2s, pro usuário não faz diferença, ele não vai notar, mesmo que demorasse 2s, ou até 3s, já que ele esta acostumado a esperar o Windows carregar, esperar a pagina carregar, esperar o programa iniciar, pra ele é normal esperar um pouquinho. E pra você que diferença faz, se pra abrir uma tela do seu programa, que emite a nota fiscal, o PC tiver que executar 100 mil instruções de máquina que não estão diretamente relacionadas ao que seu programa tem que fazer, por exemplo, coletor de lixo, checagem de pilha/heap e tantas outras coisas, afinal 100 mil instruções não significa nada em termos de tempo, já que as cpus modernas rodam a 3GHz ou mais, executar 100 mil instruções de máquina a mais, cada vez que abre a tela de notas fiscais não é nada, e também se cada registro da nota fiscal no banco de dados pudesse ocupar 10K no disco, na melhor das hipoteses, mas esta ocupando 20K, e dai, hoje temos discos da ordem de Terabytes, então isso talvez não faça muito sentido pra você. Já se você é daquele tipo de programador que já teve curiosidade de desassemblar uma função ou trecho de código que você fez pra ver no que se transformou o seu código e aquele if que você colocou na sua lógica, como é que fica em linguagem de máquina, e notou que quando se coloca inline na frente da função o compilador não gera as instruções necessárias para empilhar os parametros e nem a chamada da função, e que isso faz uma boa diferença, se a função for chamada inúmeras vezes, dentro de um loop por exemplo, então, você é do tipo de programador que vai entender do que eu to falando.
Me sinto como um mestre de obras (programador), em um canteiro de obras Chines, tendo a planta do prédio (problema a ser resolvido) só na minha mente, tendo que passar as instruções aos operários (core´s da cpu), sobre o que construir e o que cada um deve fazer (cada core da cpu), tendo que escrever em forma de verso e prosa (linguagem de programação), e traduzir isso pro mandarim usando google translator (compilador)(tradução ao pé da letra). Neste cenário, a única forma de saber se os operários entenderam o que deve ser feito é ver o resultado (testar/depurar o executavel), e claro, nada vai ser exatamente como o esperado a princípio, após sucessivas interações de comunicação com os operários, reescrevendo as instruções e revendo os resultados obtidos (testes/depuração/correções), é que vão surgindo o resultado desejado, mas quase sempre a um custo e prazo além do razoável.
Penso se há meios de melhorar essa comunicação, gostaria de sussurrar ao invés de ter que gritar do outro lado do quarteirão o que o computador tem que fazer. É como se eu estivesse em um prédio de 50 andares (software em camadas) tentando falar com um cara na calçada lá em baixo (cpu) !!!!
Recentemente li em um livro (Como quebrar códigos. Greg Hoglund/Gary McGraw) que a estimativa de bugs em um software fica entre 5 a 50 por 1000 linhas de código e que o Windows XP tem aprox. 40 milhões de linhas de código, logo, no melhor caso, estamos falando em estimados 200 mil bugs. Não tenho bases para comparar, mas se na construção de um software como o Windows XP, foi necessário, em termos de número de programadores, horas/homem e investimento, algo similar ao necessário para executar projetos de engenharia, como por exemplo, a construção das torres Petronas, na Malásia, ou a maior torre de TV do mundo, em Guanzhou, na China, seria como se logo após concluída, a estrutura apresentasse infiltração de água em dias de chuva, rachaduras em algumas paredes, a falta de algumas janelas e a presença de algumas portas onde não deveria existir, pra ser bem otimista. Isso me leva a questionar se as ferramentas e as metodologias que temos a disposição hoje, realmente ajudam a fazer softwares melhores e com poucos defeitos numa escala tão grande quando a demanda atual por software no mundo, e infelizmente, a resposta me parece ser NÃO.
Isso me leva a crer que a disciplina de desenvolvimento de software não evoluiu na mesma proporção que outras engenharias. Muitos classificam a atividade de programação como arte, algo abstrato e imprevisível. À mim, me parece mais estar ligada a área de exatas, em especial á area de engenharia, como a mecânica, a civil, a naval e a aeroespacial. Nestas temos softwares CAD (Desenho "Assistido por Computador") que permitem a visualização em 3D do produto/estrutura e nos permite simular e prever o seu comportamento antes mesmo da construção. Na programação não temos nada parecido com uma visualização 3D do programa que estamos construindo, muito menos um desenho assistido (CAD) que nos permita simular seu comportamento diante das forças a que será submetido (usuários, hackers, so, etc), na fase de projeto, antes de ser construído. Seguindo esta analogia o desenho de projeto de engenharia evoluiu da prancheta para o software CAD e as ferramentas e linguagens de programação, evoluiram em que direção ?
É obvio que as ferramentas e linguagens de programação evoluiram, desde os primórdios da programação em Assembler, mas me parece que não na mesma direção das engenharias e nem do hardware onde são executadas, me parece que evoluíram em direção ao ser humano, ao tentar humanizar a relação entre o programador e a máquina, ao criar linguagens cada vez mais próximas a linguagem natural do ser humano, cada vez mais abstratas. Isso a meu ver criou um abismo entre a forma como o programador vê o mundo e a solução do problema que deseja resolver (pensando em objetos, por exemplo) e as instruções computacionais necessária a solução desde problema da forma que a maquina entende. Para fazer a ponte existem os compiladores, que cada vez mais avançam para realizar a visão abstraída que o programador tem do mundo a sua volta e transformar essa visão em instruções de máquina realizáveis. Mas, perai, estamos escrevendo código para ser executado por outras pessoas ou executados por máquinas ?
Não quero dizer com isso que deveriamos voltar a quebrar pedra (programar em assembler), não seria produtivo, mas sim, que as ferramentas e as linguagens não evoluíram no mesmo sentido da evolução do hardware. Já se perguntou, por que o hardware é cada vez mais rápido e o Windows é cada vez mais lento !?!? será que é culpa exclusivamente dos programadores da Microsoft, ou o problema tem raizes mais profundas ? Será que parte do problema pode estar na qualidade do assembler que é gerado pelos compiladores, em seu esforço em vão de otimizar e tentar transformar em linguagem de máquina um código fonte cada vez mais abstrato ? Será que o problema pode estar na incompatibilidade dos paradigmas de programação que promovem a abstração da solução do problema, ao agrupar a informação em objetos, sem levar em conta o ambiente real e físico (tempo de acesso á memória, cache multinível, multicore, tempos de acesso a disco) onde isso vai realmente ser executado ?
Tenho a impressão que apesar da evolução das ferramentas e linguagens de alto nível, ainda estamos numa era pré revolução industrial. Vejo que o sofware ainda é feito de maneira artesanal, em grande parte, por indivíduos (programadores), ou pequenos grupos de artesãos (equipes de desenvolvimento), agrupados em aldeias (empresas). Quando vejo alguma empresa entitulada "fábrica de software" não consigo visualizar uma linha de produção como a que Henri Ford idealizou para a produção do Ford T, com analistas, arquitetos, designers, programadores, testadores, enfileirados em uma linha de produção contínua, parece mais uma grande aldeia, ou até uma cidade, de artesãos.
Como a "lei de Moore" de dobrar a capacidade a cada 18 meses, esta cada vez mais difícil de ser seguida pelos fabricantes de processadores, penso que em algum momento no futuro ira ficar cada vez mais evidente a necessidade de se repensar a forma como é feita o software, as metodologias e as ferramentas, pois atualmente, a direção atual da evolução das ferramentas e linguagens de programação nos leva cada vez mais a demandar por mais velocidade de processamento, para realizar as mesmas coisas.
Penso se não seria hora de voltar atrás, aos primórdios da computação e seguir uma linha evolutiva diferente da atual, na área de linguagens de programação e metodologias, que levaria mais em conta os avanços em hardware neste período e a interação humana da máquina com o programador num nível mais natural, baseado em tecnologias atuais, chega de escrever cartas para o computador (codigo fonte), para explicar o que queremos que ele faça, melhor seria mandar um desenho técnico, não acha. Penso em uma interação mais visual (gráfico), tátil (multitoque) ou quem sabe até vocal (comando de voz) do que textual, como por exemplo, ferramentas que nos forneçam um ambiente gráfico dos componentes computacionais (memoria, cache, cpu, armazenamento, interface do usuário) e nos permita interagir (programar) entre eles sem dispor de uma linguagem textual, mas mantendo a característica de baixo nível com alto nivel de produtividade e voltada para modelar a interação deste componentes físicos, orientado aos dados e não a objetos, ou seja, programar num nível mais realístico e físico em detrimento de abstrações e outras distrações. Tecnologia pra isso já existe, temos exemplos de multitoque e comando de voz no iPad/iPhone respectivamente, não se trata de utopia.
Alem disso penso nos benefícios que uma abordagem mais realista da programação de computadores, pode trazer no campo dos testes automatizados, da otimização do código, da melhoria da qualidade associada a um programa menor, que contenha somente as instruções de máquina necessárias à solução do problema. Qual seria o impacto no número de defeitos por 1000 linhas de código, díficil dizer, mas divagando um pouco, se 1000 linhas de código em linguagem de alto nível, teoricamente falando, representam talvez 4000 instruções de máquina, se com uma abordagem mais objetiva, consiga-se reduzir o número de instruções pela metade, estamos falando em uma redução de 50% nas expectativas de falhas e bugs, essa mesma linha de raciocínio aplicada em larga escala (40 milhões de linhas de código) a redução é significativa, sem falar em redução de tempo de processamento entre outras coisas.
Qual a sua opinião ?
Editado por alhmLink para o comentário
Compartilhar em outros sites
0 respostass a esta questão
Posts Recomendados
Participe da discussão
Você pode postar agora e se registrar depois. Se você já tem uma conta, acesse agora para postar com sua conta.