 |
gildot |
 |
| |
| | O futuro do software e do programador | | |  | Contribuído por scorpio em 05-11-03 15:21
do departamento bola de cristal | |  | |  | | |  ^magico^ escreve "No IBM developerWorks foi publicado o artigo Secure programmer: Validating input onde são referidas várias técnicas que devem ser implementadas pelos programadores quando existe a necessidade de obter introdução de dados por parte dos utilizadores. Deste artigo gostaria de realçar, it won't prevent all attacks, but it does make a program much more resistant, que vem de encontro ao que numa discussão recente eu tive a oportunidade de referir. O artigo não é muito extenso nem muito "aprofundado" no sentido que se limita a fazer uma introdução às validações básicas que cada programador deveria saber e principalmente realizar." | | | | | | " Em seguimento um outro artigo publicado na Technology Review discute a possibilidade de todos nós podermos ser programadores. Derivado ao facto do software ser tão complexo, a solução apresentada é a de criar ferramentas de desenvolvimento simples (como o Excel e o Word) para que os utilizadores possam criar os seus programas, baseando-se apenas em processos, e para os quais as ferramentas se limitam a gerar código. A minha visão é diferente como já tive a oportunidade de expressar (ps: dava jeito ter uma pesquisa que me desse todos os comnetários que eu fiz no Gildot), no entanto o que é que vocês acham? Será que a solução para o estado actual do software é criar ferramentas mais inteligentes para gerar o código, ou será deixar a evolução encarregar-se de limpar todos os pseudo-programadores que por aí andam? Ou por fim, vamos continuar com software com problemas de segurança, dificeis de usar, caros, obsoletos (apesar de muitos usarem buzzwords da tecnologia mais recente)? Será que, como é referido no artigo -- The kind of software Simonyi envisions will not only relieve tomorrow's programmers from the need to behave like machines; it will also enable experts in a given field: insurance, accounting, health care to make their own changes to their software, easily and without the constant aid of a programmer -- nós os actuais programadores seremos dispensáveis num futuro próximo?" < Microsoft oferece $250.000 na captura de hackers | Linux chegou aos telemóveis. > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | e q e q programa o gerador? e os módulos do gerador? ummm
|
| | | Godel (Pontos:5, Informativo) |
| | Este senhor escreveu um Teorema famoso que coloca alguns limites sérios à implementação de geradores de código.
Muito resumidamente, do pouco que sei sobre isto:
1. O teorema é genérico sobre proposições, não interessa aqui para o caso.
2. O efeito prático é ser impossível fazer um algoritmo que pegue noutro algoritmo numa linguagem do tipo imperativo (IMP) e determine, em tempo finito, se qualquer ciclo termina.
3. O facto disso ser impossível traz bastantes problemas: é impossível validar a correcção de um programa gerado face ao seu problema inicial.
Não sou matemático mas, tanto quanto sei, esta questão coloca alguns obstáculos à criação de geradores de código eficientes. Se alguém aqui me pudesse esclarecer porquê agradecia :)
Tó-Zé 'Senador' |
| | | | | | Vou tentar explicar sem entrar em grandes detalhes matematicos e sem dar cursos de IA à pressao. :)
Penso que é do senso comum que nao ha algoritmo para produzir codigo (source code, codigo maquina, etc), para resolver determinado problema.
Entao, é necessario ir criando a arvore do programa (qualquer programa pode ser representado pela sua abstract syntax tree - AST). Esta arvore tem de ser criada por 'tentativa e erro' (tecnicas para isto incluem os algoritmos tipicos de procura em grafos, algoritmos geneticos, tecnicas de colmeia - formigas -, e recentemente meta-procuras - Optimal ordered problem solver). Depois de criar uma possivel AST, esta tem de ser testada para ver se faz o pretendido. É aqui que "entra" o teorema do Gödel. Não ha forma de "olhar" para a linguagem e dizer "isto corre bem"/"isto pára", etc (só em linguagens limitadas e de pouca utilidade pratica). A unica forma de testar o programa, é corre-lo (pode-se usar uma "maquina virtual" que pare o programa depois de X tempo, por exemplo).
Como sao gerados milhares e milhares de programas ate que se chegue a algum que faça alguma coisa de util, é natural que este processo nao seja muito eficiente (é um problema NP-completo).
No entanto, têm-se feito alguns progressos (programas de poucas dezenas de linhas). Tenho muitas duvidas que o problema "gerar um programa dado um problema" seja resolvido nas proximas duas dezenas de anos, MAS, actualmente ja existem algumas tecnicas uteis e giras. Por exemplo, programas que "pegam" em duas funcoes parecidas e geram uma 3ª funcao que "generaliza" as duas primeiras (refactorização).
Espero que tenha sido claro e tirado a tua duvida.
|
| | | | É isso mesmo: +1 esclarecedor :)
A questão está mesmo na condição de paragem para os ciclos com um "if" lá dentro. Claro que qualquer linguagem interessante tem ciclos desses e sem ciclos desses não teríamos a expressividade sequer do ASSEMBLY (que permite ciclos ainda mais complicados), e por conseguinte, de qualquer sistema de símbolos sob o qual assenta a informática moderna.
A propósito deste assunto conta-se uma história muito engraçada de uma empresa americana muito grande com uma sigla de 3 letras (para não dizer qual) que decidiu investir nesta área nos anos 70. Gastou vários milhões de dólares num programa de I&D XPTO para validar outros programas. A parte engraçada é que o teorema da incompletude do senhor Godel que provava que tal era impossível foi escrito nos anos 30 :)
Tó-Zé 'Senador' |
| | | | Sem dúvida que a validação é algo importante, mas não é tudo. A trivialidade, essa sim, é algo realmente importante numa aplicação projectada com a segurança em mente.
Actualmente muitas das falhas que vemos já não podem ser consideradas falhas de validação mas mais falhas lógicas. E estas falhas lógicas devem-se bastante à falta de projecção da estrutura do software, à falta da separação abstracta daquilo que é complexo em níveis mais triviais e fáceis de assimilar, à inexperiencia dos programadores, à preguiça/negligência e à falta de consistência do código.
Foi para tornar certas tarefas mais triviais que o homem criou as ferramentas de trabalho (e entre elas os computadores). Por vezes o próprio programador esquece-se disso mesmo e resolve (por preguiça talvez) "fazer tudo à mão". O programador, mais do que qualquer outra pessoa de qualquer outra área, tem a possibilidade de criar as suas próprias ferramentas (procedimentos) com um interface (API) consistente que melhor se adapte ao seu estilo com objectivos triviais e muito específicos que podem mais tarde ser utilizados noutros procedimentos com uma scope mais abrangente, geral e abstracta para construir algo sólido dividindo desta forma a complexidade em várias camadas que fazem com que tarefas que antes pareciam complexas agora pareçam triviais.
Cada um tem um limite de abstracção que consegue suportar e cada um deve reconhecer qual o seu limite e dividir o nível de abstracção do seu código tendo isso em conta ou dificilmente conseguirá algo seguro.
Quando um problema parece algo complexo é porque não estamos a dividir o abstracto em camadas de trivialização suficientes. Devemos portanto tentar separar o problema geral em problemas mais pequenos mas mais específicos, tentar então resolver um a um os problemas específicos e então resolver o geral com todas as ferramentas que criámos para resolver os específicos.
Esta é a minha ideia da programação segura, e quem já teve oportunidade de me pedir conselhos sobre implementações ou de olhar para implementações minhas de certo que reconhece aqui a minha forma de ver a segurança.
Não creio que algum dia os programadores sejam substituídos, isso é utópico e inaplicável. Prova disso é que mesmo com tanta linguagem de alto nível se continue a dar tanta importancia a linguagens de baixo. O problema é que quanto maior é a abstracção de uma ferramenta mais difícil se torna usá-la porque deixa de ser fácil controlar directamente a maquina, e uma maquina é inútil se ninguem tiver controlo directo sobre ela. Basta ver que o Windows por muito user-friendly que seja e por mais que a Microsoft invente nunca será tão dinâmico como um Unix* (especialmente um Open Source) nas mãos de alguem com orientação técnica.
"Success reflects luck, not skill!"
-- flock of Balticor |
| | | | | | eh, isso é análise/programação 101 :)
----------
-1: Redundante! |
| | | | | A forma como os problemas de programação são resolvidos pela maior parte dos programadores radica na realidade de sermos humanos: muitas vezes com erros, muitas vezes não de forma óptima, muitas vezes introduzindo problemas de segurança nos sistemas. Ainda assim, e apesar de tudo, o espaço que existe para que o rasgo e visão de um ser humano produza um pedaço de código brilhante, ou uma interface excepcional, é o que me faz continuar a ser orgulhosamente um programador.
No code = No errors
|
| |
|
