| awk pior em legibilidade? what the fuck? o awk é perfeitamente legivel: é semelhante ao C em syntax e nao tem ponteiros. quase que podia ser java :) De facto, o awk em si, nao tende a produzir expressoes complexas (mas podem-se arranjar)! O formato de um script em awk é "condicao accao". Accao é um bloco com statements-- esta é a parte parecida com C. A condicao, é constituida normalmente por expressoes regulares, mas pode ser outra expressao que avalie num valor falso (0) ou verdadeiro. Por exemplo, a minha linha de awk favorita, é a seguinte, que elimina linhas duplicadas, mesmo que nao estejam ordenadas: awk '!a[$0]++' files... Normalmente vêem-se coisas do estilo: awk '/pattern/{print substr($0, 4,5)}' files mas o que vem atras do bloco na verdade, pode ser qualquer coisa que se enfie num if.
Como as expressoes regulares vêm nativas no awk, tem-se tendencia a usa-las (tal como no perl) e isso torna muitos dos scripts dificeis de ler (a parte das REs, pelo menos). Quanto ao perl, é muito generalista, muito porque tem sido hackado ao longo dos anos, a comportar uma quantidade incrivel de paradigmas e/ou funcionalidades. Muitas delas ficaram esquisitas... mas funcionam, enfim. Neste momento, pode-se fazer e programar em perl, quase como se quiser. Existem varias formas de condicionalismos (if (cond) {}, expr if cond; cond and expr ... ), varias formas de produzir ciclos, existem tres tipos de goto's (os "normais", a-la fortran, e funcionais, que entretanto acho qeu foram deprecated). Com o "use" ou "no" podem-se ter varios comportamento run-time. Por exemplo, o "use strict" (mais concretamente, o "use strict 'vars'") obriga a que as variaveis sejam pre-declaradas, como na maior parte das linguagens nao-scripting (C,pascal,java), com "no strict" ja existe auto-definicao por referenciacao (como em awk, tcl). O Python tem um metodo ligeiramente diferente (as variaveis sao auto-definidas *apenas* em statements de iniciacao), e nao me admirava se qualquer dia, ja houvesse um "use" para esse modo. Dos varios paradigmas mencionados em cima, pelo menos "objectos" e "eventos" sao suportados por perl. Objectos builtin, e eventos por um modulo (nao me lembro do nome, mas deve fazer match de /event/i concerteza :)). Na verdade, a unica coisa que nao deve ser possivel fazer em perl, é fugir aquela syntax, para quem nao gosta. Quanto aos usos, basta encontrar "o binario de perl mais proximo de si", e tem-se uma forma de resolver quase todos (para nao dizer mesmo todos) os tipos de problemas, ou desenhar quase todos (para nao... bla bla...) os tipos de solucoes. Contudo, admito que em grandes projectos (ou coisas que envolvam mais que um ou dois ficheiros de um modo geral), talvez perl nao seja a melhor solucao. O mecanismo de classes e/ou modulos é parecido com o de python (foi baseado no deste), mas é mais dificil de realizar (em consequencia, nao existem muito programadores medianos a escrever modulos (.pm) em perl) e está menos integrado na linguagem. O operador bless é tudo menos blessed, e nao se percebe a logica de como se chega aos dados criados por este (nas instancias) e aos metodos e as variaveis globais do modulo...
|
