[Cascavel-pm] Res: Res: off topic DotNet

Alceu R. de Freitas Jr. glasswalk3r em yahoo.com.br
Segunda Junho 28 09:32:29 PDT 2010



----- Mensagem original ----
> De: Eden Cardim <edencardim em gmail.com>
> Enviadas: Segunda-feira, 28 de Junho de 2010 10:24:19

    João> 2 
> critérios básicos - quantidade de sistemas desenvolvidos na
    
> João> plataforma e disponibilidade mão de obra.

> Esses dois critérios são contra-argumentados na literatura de engenharia
> de software que eu indiquei num email anterior.

Eden, e o que eu faço com meu gerente que não leu e nem está interessado em ler tal literatura?

Digo isso porque atualmente eu não consigo "vender" o uso interno de Perl aqui. Não temos NENHUMA linguagem de programação fracamente tipada e sem compilação (vulgarmente chamada de script) para podermos produzir código rápido e funcional. E olha que meus usuários acham que a área de TI deve funcionar como pastelaria.

Eu concordo com você, mas uma coisa é a teoria, outra é a prática.
    
João> Em 
> ambas, PHP e Java batem Perl muito facilmente. Pelo menos
> João> no Brasil (acho que você não mora aqui).

> Ciência não tem 
> nacionalidade, o fato de uma ou outra linguagem ser mais
> ou menos popular no 
> Brasil não fazem dela a melhor ou pior linguagem.

Acho que aí entra a questão de contexto.

No contexto científico, você está correto.No conceito mercadológico, o João está correto.

Vou citar um exemplo: se eu checar para meu chefe aqui e dizer que agora sou mestre em inteligência artificial, ele vai cagar e andar. Se disser, no entanto, que agora tenho MBA de Harvard, ele vai colocar uma foto minha na mesa dele.

Por que isso?

Empresas querem saber de resultados. Se Perl pode ajudar a empresa a ser eficiente e ganhar dinheiro, é isso que vai interessar meu chefe.

O problema é vender essa idéia para quem não tem conhecimento técnico. O Brasil não valoriza profissional especialista, basta verificar como cientistas e pesquisadores competentes decidem ir embora do país.

É uma visão curta, ridícula... mas é o que temos por aqui.
  
>   João> Em termos de fazer o que tem que ser feito, todas elas fazem 
> o
    João> que tem que ser feito.

> fazem o que tem que 
> ser feito" é o argumento mais vago que eu já li na
> vida.

Outro exemplo que me faz concordar com o João. Eu não acho que ele esteja denegrindo nossa linguagem favorita, mas colocando seu ponto de vista.
Se tecnicamente é tão bom quanto ou melhor que outras linguagens, por que não é utilizado em escala maior?

Acho que são estas perguntas que temos que nos fazer. Lembram-se da história do VHS e Betamax?

Voltando a questão do "fazer o que tem que ser feito", para os usuários tanto faz se o programa é bem estruturado ou não. Para eles o importante é que o programa:
1 - Funcione
2 - Rode num tempo aceitável
3 - Não fique dando problemas

Todo o caminho que deve ser percorrido para chegar nisto é de interesse da área técnica, não usuária.

Um exemplo: minha área usuária me mostrou um banco de dados SQL Server feito à partir de um monte de planilhas Excel com dados, pois estava sendo um tormento atualizá-las manualmente.
Eu sugeri usar Access para ter acesso aos dados rapidamente. Eles não quiseram, queriam um "sistema web" porque era mais moderno.
Bem, eu comecei  fazer algo com CGI::Application e quando fui olhar o modelo relacional... era a coisa mais escabrosa que eu vi. Disse ao usuário que teria que arrumar aquilo primeiro, ou não teria como garantir integridade dos dados. Ele achou ruim, porque ia demorar mais.

Eu fiz um monte de horas extras para entregar o sistema funcional... e o sistema foi reprovado porque era feio. Eles queriam uma interface bonita, eu avisei que não era designer (fiz um HTML pé de boi mesmo com HTML::Template) e eles não quiseram arrumar um por causa de custos. Enfim, nem sei o que eles usaram depois.

A conclusão que tirei disto foi:
1 - Para o usuário, tanto faz se o modelo de dados precisa ser arrumado ou não;
2 - Para o usuário, tanto faz se o backend é eficiente e bem desenhado;

    João> Segundo minha opinião: - Sistemas complexos são 
> aqueles que
    João> envolvem:
    João> * Uma 
> interface administrativa (GUI)
    João> * Uma interface de 
> usuário (GUI)
    João> * Um core com N funções

Segundo o 
> teu critério, o northwind (o banco de dados do ms access) é
mais complexo do 
> que o fritz (a engine de xadrez que empatou 4 vezes com
o Garry Kasparov e 
> derrotou outros grandmasters como Vladimir
Kramnik). De novo, a literatura 
> introdutória de engenharia de software é
categórica nesse assunto.

Esse foi um exemplo bem ruim mesmo. Mas aqui vai um bom (ponto de vista): http://www.faqs.org/docs/artu/ch14s04.html#perl. É claro que já está desatualizado, existem recursos no Perl para contornar ou resolver os pontos negativos apresentados, mas essas coisas ainda não estão no core do Perl (Moose é um excelente exemplo). 

De novo, você sabe, eu sei disso. Mas muito programadores experientes por aí não sabem.

Se pensarmos em como a linguagem auxilia o programador a não escrever 
código ruim, temos o Perl::Critic. Mas eu, por exemplo, não comprei 
ainda o Perl Best Practices que o pessoal tanto cita. Então fiquei meio 
sem "ajuda" da linguagem.

Daí a necessidade de divulgação e pesquisas. Eu estou vendo um progresso nessa área, mas ainda falta bastante.

> Deve 
> ser desse tipo de análise que saem os orçamentos de software
> superfaturados 
> típicos do Brasil.

É bem por aí. Ou pior ainda Eden. Eu tenho uma porção de histórias de consultorias "especialistas" que fariam seu cabelos ficarem de pé e depois caírem.

 João> * wxWidgets ainda não 
> tem versão 1.0 e vários itens
    João> disponíveis em outros 
> APIs (incluindo Flex) ainda não estão
    João> 
> disponíveis.
    
> Ok, enumera os itens disponíveis no flex que 
> não estão disponíveis no
> wxWidgets. Por sinal, wxWidgets é uma biblioteca C, 
> perl só fornece bindings.

Eu acho que API está OK. Somos bons nisso.
Mas não temos ferramentas para auxiliar a criar interfaces gráficas.
C# e Java contam com ferramentas gráficas bem competentes para fazer esse tipo de coisa.

Se não me engano, temos o Padre (que ainda não chegou lá) e o Glade (mas só gera XML, não código Perl).

A propósito, como é mesmo o procedimento 
> para se desenvolver GUIs em
PHP? Falta ainda o benchmark indicando que PHP é 
> mais rápido que 
> perl.

Tem o PHP-GTK, mas não tenho idéia se é bom ou ruim. Mas se eu fosse um programador novo que quisesse criar interfaces gráficas com uma linguagem script, esse seria um bom ponto para começar: ao menos existe publicação em português sobre o assunto (http://www.novateceditora.com.br/livros/phpgtk/).

[]'s
Alceu



      


Mais detalhes sobre a lista de discussão Cascavel-pm