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

[Eden Cardim]

>>>>> "Alceu" == Alceu R de Freitas <glasswalk3r em yahoo.com.br> writes:

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

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

Toda linguagem de programação é necessariamente compilada.
    
    Alceu> Eu concordo com você, mas uma coisa é a teoria, outra é a
    Alceu> prática.

A literatura que eu sugeri são relatos de projetos reais que coincidiram
bastante com a minha própria experiência em desenvolvimento e gestão de
projetos de software.

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

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

Não, não está porque ele desqualificou a linguagem de forma geral. Se
ele dissesse "Perl é difícil de vender pro mercado nacional", invés
disso, ele pegou a visão estreita que ele tem sobre o assunto e
extrapolou pruma área onde ele não tem autoridade.
    
    Alceu> Vou citar um exemplo: se eu checar para meu chefe aqui e
    Alceu> dizer que agora sou mestre em inteligência artificial, ele
    Alceu> vai cagar e andar. Se disser, no entanto, que agora tenho MBA
    Alceu> de Harvard, ele vai colocar uma foto minha na mesa dele.

    Alceu> Por que isso?

Porque você provavelmente está trabalhando no lugar errado, vendendo o
produto errado pra pessoa errada. É igual tentar vender espelho pro
Stevie Wonder.
    
    Alceu> Empresas querem saber de resultados. Se Perl pode ajudar a
    Alceu> empresa a ser eficiente e ganhar dinheiro, é isso que vai
    Alceu> interessar meu chefe.

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

    Alceu> É uma visão curta, ridícula... mas é o que temos por aqui.

É uma visão que requer habilidade pessoal e tempo pra mudar, alguns
sentam pra fazer, outros ficam reclamando e disseminando fatos
imprecisos.

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

Porque em geral os profissionais de TI não tem a formação necessária
para se compreender as virtudes e fraquezas das ferramentas num contexto
mais amplo. Os que tem formação suficiente estão ocupados trabalhando e
perdem pouco tempo com esse tipo de discussão (eu deveria seguir o
exemplo, mas não consigo ainda, tenho muita coisa ainda por aprender).
    
    Alceu> Acho que são estas perguntas que temos que nos
    Alceu> fazer. Lembram-se da história do VHS e Betamax?

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

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

Não é bem assim, o iphone é uma prova disso, tem várias falhas técnicas
e mesmo assim as pessoas fazem fila para comprar. O mercado de um
produto é uma combinação de vários fatores e "não existe bala de
prata".
    
    Alceu> Um exemplo: minha área usuária me mostrou um banco de dados
    Alceu> SQL Server feito à partir de um monte de planilhas Excel com
    Alceu> dados, pois estava sendo um tormento atualizá-las
    Alceu> manualmente.  Eu sugeri usar Access para ter acesso aos dados
    Alceu> rapidamente. Eles não quiseram, queriam um "sistema web"
    Alceu> porque era mais moderno.  Bem, eu comecei fazer algo com
    Alceu> CGI::Application e quando fui olhar o modelo
    Alceu> relacional... era a coisa mais escabrosa que eu vi. Disse ao
    Alceu> usuário que teria que arrumar aquilo primeiro, ou não teria
    Alceu> como garantir integridade dos dados. Ele achou ruim, porque
    Alceu> ia demorar mais.

Em primeiro lugar, "integridade dos dados" faz parte da lista de
requisitos desse projeto? Em qual prioridade? Se você não souber a
resposta pra essas duas perguntas, sinto lhe informar, mas o erro foi
seu.
    
    Alceu> Eu fiz um monte de horas extras para entregar o sistema
    Alceu> funcional... e o sistema foi reprovado porque era feio. Eles
    Alceu> queriam uma interface bonita, eu avisei que não era designer
    Alceu> (fiz um HTML pé de boi mesmo com HTML::Template) e eles não
    Alceu> quiseram arrumar um por causa de custos. Enfim, nem sei o que
    Alceu> eles usaram depois.
    Alceu> A conclusão que tirei disto foi: 1 - Para o usuário, tanto
    Alceu> faz se o modelo de dados precisa ser arrumado ou não; 2 -
    Alceu> Para o usuário, tanto faz se o backend é eficiente e bem
    Alceu> desenhado;

Na verdade, a conclusão é que antes de começar o trabalho, você precisa
sentar e coletar os requisitos do sistema, e depois você começa a tirar
conclusões e tomar decisões a respeito de qual ferramenta você vai
utilizar. Se for uma tarefa impossível, você vai precisar falar "não dá
pra fazer".

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

E porque "não estar no core do Perl" é um problema? O artigo começa
falando "Perl is shell on steroids.", quando um artigo começa com uma
colocação completamente equivocada como essa, eu nem leio o resto.
    
    Alceu> De novo, você sabe, eu sei disso. Mas muito programadores
    Alceu> experientes por aí não sabem.

Ah, então o problema está nos programadores, não na linguagem, correto?
    
    Alceu> Se pensarmos em como a linguagem auxilia o programador a não
    Alceu> escrever código ruim, temos o Perl::Critic. Mas eu, por
    Alceu> exemplo, não comprei ainda o Perl Best Practices que o
    Alceu> pessoal tanto cita. Então fiquei meio sem "ajuda" da
    Alceu> linguagem.
    
    Alceu> Daí a necessidade de divulgação e pesquisas. Eu estou vendo
    Alceu> um progresso nessa área, mas ainda falta bastante.

Cara, isso depende muito do perfil de quem está usando a linguagem,
geralmente as pessoas mais instruídas preferem ferramentas menos
intrusivas e mais flexíveis. Por isso que a maioria de nós usamos unix
ou derivados invés de windows, não é mesmo?
    
    >> Deve ser desse tipo de análise que saem os orçamentos de software
    >> superfaturados típicos do Brasil.

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

Deixa pra contar quando estivermos no boteco, é mais divertido.
     
    >> 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.

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

Cara, WYSIWYG, apesar de útil para escrever protótipos, não funciona
muito bem com GUIs, porque a área útil da aplicação é desconhecida e de
tamanho variável e o "layout" e a quantidade de elementos gráficos
precisa mudar programaticamente para se adequar. Então, a não ser que
não exista o requisito de "ser utilizável em qualquer resolução ou
tamanho de janela", a existência de uma ferramenta WYSIWYG pode vir a
ser pouco relevante para projetos envolvendo GUIs. De novo, os
requisitos vão determinar qual ferramenta é mais adequada.
    
    Alceu> Se não me engano, temos o Padre (que ainda não chegou lá) e o
    Alceu> Glade (mas só gera XML, não código Perl).

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

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

Quer dizer que se usa a mesma biblioteca que pode-se usar com perl, mas
com bindings para PHP? Continuo sem enxergar a vantagem ou desvantagem
entre as duas abordagens.