Lógica, computação e engenharia de software
Existe uma verdade básica sobre engenharia de software: não existe engenharia de software. Não no sentido das outras engenharias; o que se rotula de "engenharia de software" hoje em dia é parte gerência de projetos, parte coleção de métodos ad hoc para tentar assegurar que as coisas continuem nos trilhos. E os métodos frequentemente falham.
Por outro lado, vinda lá da década de 60, existe a idéia de escrever provas matemáticas de corretude de programas. O assunto foi exaustivamente pesquisado na época, mas logo se viu que o esforço necessário era muito alto para programas não-triviais. As demandas econômicas e a expectativa relativamente baixa dos clientes acabaram impulsionando a atividade de criação de software como um artesanato ao invés de engenharia. E esta é, mais ou menos alguns detalhes, a situação até hoje. Existe uma legião de "programadores" profissionais com formação deficiente, e mesmo muitas universidades que oferecem cursos de ciência da computação se contentam em dar um verniz teórico muito superficial, acompanhado por incontáveis horas de treinamento vocacional em Java ou qualquer que seja a linguagem da moda no momento.
O resultado é visível: bugs e falhas de segurança permanecem abundantes mesmo em software considerado de "alta qualidade". Os clientes se acostumaram a isso como se fosse a única forma, mas não precisa ser assim. O mesmo cliente que simplesmente balança a cabeça ao ver um bug do Word ou uma falha de segurança no seu Windows voltaria correndo para a concessionária devolver um carro que apresentasse o menor defeito. E software livre, sinceramente, não resolve este problema: eu uso Linux diariamente, em casa, mas o número de bugs e incompatibilidades nas aplicações é considerável, embora a base do sistema operacional seja sólida.
Baixas expectativas + altíssima demanda + profissionais incompetentes = software de má qualidade.
Mas as outras engenharias não nasceram da forma que são hoje; elas primeiro passaram por um período de ensino vocacional e técnico antes de chegarem ao estágio atual de assumir uma base científica. O cálculo, a análise matemática, se tornou a base das engenharias entre os séculos XIX e XX.
Pode-se ter esperança, então, que a engenharia de software siga o mesmo caminho. A lógica matemática se mostrou, nestas décadas de desenvolvimento da computação, ser uma base extremamente adequada para a atividade. Por que não dizer que a lógica está para a engenharia de software assim como a análise está para as outras ? Por que não basear a criação de software em uma fundação científica sólida ? Os problemas de gerenciamento de projetos vão continuar existindo, claro, como existem nas outras engenharias. Mas pelo menos quem precisa criar software que funcione terá um conjunto de métodos para garantir que as especificações são satisfeitas, assim como um engenheiro civil garante que uma ponte sustenta uma carga de até X toneladas, mais ou menos um porcentual de erro conhecido e controlado.
Ao ler este artigo de John Allen, eu tive vontade muitas vezes de simplesmente balançar a cabeça em concordância; os argumentos dele sintetizam muito do que eu já acreditava sobre o assunto. A teoria está se tornando cada vez mais relevante, embora a maioria dos praticantes ainda não se dê conta; por exemplo, a adição de genéricos em Java utiliza partes muito avançadas e recentes da teoria dos tipos (quantificação limitada de tipos polimórficos, alguém já ouviu falar?). Mesmo que o resultado não tenha sido excelente, a linguagem foi aumentada de forma significativa sem quebrar a compatibilidade. Esse tipo de cirurgia em linguagens já existentes há anos é quase impossível de ser feita sem deixar alguns efeitos colaterais. E quem fez isso ? Um grupo de teóricos conhecidos, entre eles o famoso Philip Wadler.
A Microsoft, por sua vez, emprega uma verdadeira legião de pesquisadores em linguagens de programação, alguns dos quais trabalharam e ainda trabalham em várias extensões para o CLR (o runtime da plataforma .NET) e para a linguagem C#. A extensão do CLR para usar genéricos, por exemplo. Mas existem várias outras coisas sendo feitas.
A questão é quando a teoria e o rigor vão atingir o Joe-Sixpack-Programmer, o programador comum que está "nas trincheiras". Isso eu não sei, mas desconfio que quem quiser trabalhar no ramo daqui a uns 20 anos deve se preparar para aprender uma boa quantidade de matemática, especialmente lógica...
Por outro lado, vinda lá da década de 60, existe a idéia de escrever provas matemáticas de corretude de programas. O assunto foi exaustivamente pesquisado na época, mas logo se viu que o esforço necessário era muito alto para programas não-triviais. As demandas econômicas e a expectativa relativamente baixa dos clientes acabaram impulsionando a atividade de criação de software como um artesanato ao invés de engenharia. E esta é, mais ou menos alguns detalhes, a situação até hoje. Existe uma legião de "programadores" profissionais com formação deficiente, e mesmo muitas universidades que oferecem cursos de ciência da computação se contentam em dar um verniz teórico muito superficial, acompanhado por incontáveis horas de treinamento vocacional em Java ou qualquer que seja a linguagem da moda no momento.
O resultado é visível: bugs e falhas de segurança permanecem abundantes mesmo em software considerado de "alta qualidade". Os clientes se acostumaram a isso como se fosse a única forma, mas não precisa ser assim. O mesmo cliente que simplesmente balança a cabeça ao ver um bug do Word ou uma falha de segurança no seu Windows voltaria correndo para a concessionária devolver um carro que apresentasse o menor defeito. E software livre, sinceramente, não resolve este problema: eu uso Linux diariamente, em casa, mas o número de bugs e incompatibilidades nas aplicações é considerável, embora a base do sistema operacional seja sólida.
Baixas expectativas + altíssima demanda + profissionais incompetentes = software de má qualidade.
Mas as outras engenharias não nasceram da forma que são hoje; elas primeiro passaram por um período de ensino vocacional e técnico antes de chegarem ao estágio atual de assumir uma base científica. O cálculo, a análise matemática, se tornou a base das engenharias entre os séculos XIX e XX.
Pode-se ter esperança, então, que a engenharia de software siga o mesmo caminho. A lógica matemática se mostrou, nestas décadas de desenvolvimento da computação, ser uma base extremamente adequada para a atividade. Por que não dizer que a lógica está para a engenharia de software assim como a análise está para as outras ? Por que não basear a criação de software em uma fundação científica sólida ? Os problemas de gerenciamento de projetos vão continuar existindo, claro, como existem nas outras engenharias. Mas pelo menos quem precisa criar software que funcione terá um conjunto de métodos para garantir que as especificações são satisfeitas, assim como um engenheiro civil garante que uma ponte sustenta uma carga de até X toneladas, mais ou menos um porcentual de erro conhecido e controlado.
Ao ler este artigo de John Allen, eu tive vontade muitas vezes de simplesmente balançar a cabeça em concordância; os argumentos dele sintetizam muito do que eu já acreditava sobre o assunto. A teoria está se tornando cada vez mais relevante, embora a maioria dos praticantes ainda não se dê conta; por exemplo, a adição de genéricos em Java utiliza partes muito avançadas e recentes da teoria dos tipos (quantificação limitada de tipos polimórficos, alguém já ouviu falar?). Mesmo que o resultado não tenha sido excelente, a linguagem foi aumentada de forma significativa sem quebrar a compatibilidade. Esse tipo de cirurgia em linguagens já existentes há anos é quase impossível de ser feita sem deixar alguns efeitos colaterais. E quem fez isso ? Um grupo de teóricos conhecidos, entre eles o famoso Philip Wadler.
A Microsoft, por sua vez, emprega uma verdadeira legião de pesquisadores em linguagens de programação, alguns dos quais trabalharam e ainda trabalham em várias extensões para o CLR (o runtime da plataforma .NET) e para a linguagem C#. A extensão do CLR para usar genéricos, por exemplo. Mas existem várias outras coisas sendo feitas.
A questão é quando a teoria e o rigor vão atingir o Joe-Sixpack-Programmer, o programador comum que está "nas trincheiras". Isso eu não sei, mas desconfio que quem quiser trabalhar no ramo daqui a uns 20 anos deve se preparar para aprender uma boa quantidade de matemática, especialmente lógica...
posted by tautologico at
3:41 PM
1 Comments:
Gostei do seu comentário sobre Scala. Um ponto positivo da linguagem é que ela diminui a "barrier to entry" para o contingente de programadores OO começar a adotar programação funcional. Acho que eu devo me incluir neste contingente, pois só conheço Scheme (superficialmente) e Scala - ainda não tive tempo de estudar Haskell nem ML.
Sobre este post específico, eu não acredito que técnicas de prova da correção formal de programas podem ajudar tanto assim. Um problema (bastante citado por aí) é que se a complexidade da prova for próxima da complexidade do algoritmo, o ganho na confiança da correção talvez não seja o suficiente para compensar o trabalho. Outro problema é que uma grande parte (talvez a maior) dos bugs estejam na formulação do problema (a infame "coleta de requerimentos") e não na implementação.
Isso não quer dizer que eu considere inútil o uso de provas no desenvolvimento de software. Conheço pouco sobre o assunto, mas tenho esperanças que liguagens com sistemas de tipos mais sofisticados ajudem bastante. E também espero que esse tipo de conhecimento se propague para mais programadores. Acho que o que eu quero dizer é que técnicas de prova são sem dúvida benéficas e quanto mais gente as conhecer melhor, mas mesmo se todo algoritmo escrito por aí for provado correto, ainda existirão muitos e muitos bugs advindos da mal formulação dos problemas.
By
Unknown, at 11:13 AM
Post a Comment
<< Home