> Cobol e .Net vão no mesmo barco, quase. Mas quanto ao requisito de > "obfuscação de código"? Isso ainda é muito forte? Lembro de um projeto que > foi feito em C++ pq ruby tinha o código "exposto", como se isso fosse > dificultar uma engenharia reversa naquele caso.
Um amigo meu que até acompanha a lista uma vez me disse: "Pra quem fala assembly não existe código fechado". []'s 2011/10/17 Tiago Peczenyj <[email protected]>: > > > 2011/10/17 Alexei Znamensky <[email protected]> >> >> >> 2011/10/17 Tiago Peczenyj <[email protected]> >>> >>> Claro Daniel, >>> Eu percebo que a pergunta sobre "esta pronto para usar em produção" tem 2 >>> vertentes (que eu inventei agora). Uma vertente é generalista, que uma dada >>> linguagem ou ferramenta tem que servir para muita coisa. Deve ser por isso q >>> muito projeto é feito em Java, por exemplo. A outra é especialista: nesse >>> meu problema em específico eu posso usar? >> >> Pacman, >> Eu acrescentaria uma outra perspectiva também à questão. A expressão >> "Pronto para Produção" pode variar bastante dependendo do contexto no qual >> está inserido. Por exemplo, aqui no âmbito da lista, o que eu vi gravitou >> (como sempre, e como esperado) em torno da robustez técnica da linguagem >> e/ou dos componentes do meio-ambiente que a cerca (grammar, rakudo, etc...). >> No entanto, levar um produto a produção, até onde eu enxergo, é uma decisão >> de negócio, não é uma decisão do time técnico de computação >> (desenvolvimento/suporte/whatever), e o papel deste último grupo é prover ao >> primeiro a maior quantidade possível de informações para que eles possam >> tomar essa decisão minimizando os riscos e/ou impactos para a empresa. > > Perfeito >> >> Isso dito, eu diria que "Pronto Para Produção" precisa de muito mais que a >> maturidade técnica do produto, precisa também, por exemplo, ter mecanismos >> de suporte bem definidos e ágeis. É preciso ter alguém, em algum lugar, >> comquem você possa abrir um chamado e essa entidade de suporte tenha a >> obrigação de atender tão rápido quanto possível. Tipo, chamar o Larry Wall >> no IRC???? Quanto tempo se gastaria para conseguir fazer o Larry Wall parar >> o que está fazendo e atender a VOCÊ? E se ele tiver outras prioridades, ou >> estiver dando uma palestra na Guiné Bissau, o que você faz? Pede para o >> cliente esperar com o site fora do ar "somente por alguns dias"? Fora o fato >> de que, você estaria pedindo a ele (ou a qualquer outra pessoa da >> comunidade) para resolver de graça um problema, para o qual você está >> recebendo. Quão justo é isso? > > É verdade. Utilizei o exemplo do Larry Wall mais como um exemplo extremo mas > não soou como tal. > >> >> Mais: se houver uma empresa que preste suporte para Perl, por exemplo. >> Imagine que o cliente tenha um problema gravíssimo no site, está fora do ar, >> aciona o suporte com a empresa, mas eles não conseguem atender a tempo dos >> seus SLAs combinados. O cliente processa. Se a empresa de suporte for muito >> pequena, o fim dessa história é a sua morte súbita: ela vai ter de pagar >> tanto dinheiro em multa(s) que vai falir em seguida. Não há empresas grandes >> atendendo Perl em escala e profundidade necessários para dar segurança legal >> (as in "the law", modafoca) e técnica aos clientes. > > Fico pensando em como isso afeta outras linguagens como Python, Ruby, etc. > Provavelmente ficam de fora desses nichos (acredito que o seu exemplo é de > prestação de serviços a TI corporativa, que além de recursos tecnicos ainda > faz uso de coisas como ITIL, etc). > >> >> Um dos motivos pelos quais muitos projetos são feitos em Java é porque tem >> muita gente estudando JAva, e tem muita empresa (e grandes) dando suporte a >> coisas feitas em Java. Isso não é necessariamente bom, mas atende à >> necessidade de segurança das pessoas que estão a comprar, seja essa >> necessidade fundamentada ou não. > > Cobol e .Net vão no mesmo barco, quase. Mas quanto ao requisito de > "obfuscação de código"? Isso ainda é muito forte? Lembro de um projeto que > foi feito em C++ pq ruby tinha o código "exposto", como se isso fosse > dificultar uma engenharia reversa naquele caso. > >> >> >>> >>> Eu não colocaria um software marcado como beta em produção, mas para >>> outras coisas temos formas de avaliar melhor. Por exemplo eu procuro >>> exemplos internos e indiretos para usar Perl no trabalho. Vou parsear log? >>> Vou usar Perl. Vou criar um deamon que lida com filesystem diretamente, vou >>> usar Perl. Isso cria uma bagagem para poder mostrar que tem X sistemas >>> rodando por Y meses sem incidentes e, então, posso considerar. Mas isto só >>> rola na vertente especialista. >> >> No frigir dos ovos, é uma decisão de negócio porque a única forma de >> conseguir decidir se usamos um software marcado como "beta" em produção ou >> não se resume a: quanto vamos ganhar/perder com isso, qual o risco de dar >> merda, e quanto custa se der merda? Se as respostas forem, respectivamente, >> uma alta e duas baixas, não há nenhum motivo pelo qual NÃO colocar em >> produção!!! Quem decide é a grana!! > > Claro. Mas se quem fez marcou como beta o fez com alguma razão. Fico com > medinho. :) > my $twocents; > []s > Russo > >> >> Eu não tinha pensando em usar Perl 6 ainda, nem para esse tipo de coisa. >> Seu post me dá até mais segurança para tentar :) >> >> 2011/10/17 Daniel Vinciguerra <[email protected]> >>> >>> Tiago, >>> Gostei muito do comentário e do seu ponto de vista e entendo >>> que perl6 tem todas as features de que vou precisar ou no mínimo >>> me atende de forma mais que satisfatória. >>> A linguagem é nova ainda e as vms que estão saindo (... começando >>> a engatinhar) estão ganhando cada vez mais poder (features, >>> performance, etc). >>> O fato é que, como responsável pelo projeto, que possivelmente virá >>> a ser um produto da empresa, devo tomar algumas decisões e cuidados >>> mínimos com este tipo de escolha, afinal de contas, tenho que usar a >>> melhor tecnologia para atender as expectativas/necessidades. >>> Me empolguei com o fato de poder usar perl6 para este projeto pois até >>> então só tinha brincado com as vms para conhecer a linguagem e como >>> o rumo das coisas é a evolução constante das vms que estão sendo >>> desenvolvidas não vejo problemas (...ao menos graves) em usar >>> perl6+rakudo >>> para encarar esta empreitada. :) >>> Obrigado a todos, e um forte braço! :) >>> Daniel Vinciguerra >>> Web Solutions Architect and Co-Owner at Bivee >>> http://github.com/dvinciguerra >>> >>> >>> 2011/10/17 Daniel de Oliveira Mantovani >>> <[email protected]> >>>> >>>> Você pode usar o perl -c foo.pl >>>> 2011/10/17 Daniel Vinciguerra <[email protected]> >>>>> >>>>> Bom dia senhores, >>>>> Iniciei um projeto a pouco e um dos requisitos é que eu deveria fazer >>>>> parse de de uma linguagem >>>>> de programação. A ideia é criar uma espécie de syntax validator... >>>>> Como não tenho experiencia com isso pensei em perguntar para ver >>>>> se alguém tem alguma dica >>>>> ou um módulo que eu pudesse usar. >>>>> >>>>> Forte abraço a todos, >>>>> >>>>> Daniel Vinciguerra >>>>> Web Solutions Architect and Co-Owner at Bivee >>>>> http://github.com/dvinciguerra >>>>> >>>>> =begin disclaimer >>>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>>> SaoPaulo-pm mailing list: [email protected] >>>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>>> =end disclaimer >>>>> >>>> >>>> >>>> >>>> -- >>>> "If you’ve never written anything thoughtful, then you’ve never had any >>>> difficult, important, or interesting thoughts. That’s the secret: people >>>> who >>>> don’t write, are people who don’t think." >>>> >>>> =begin disclaimer >>>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>>> SaoPaulo-pm mailing list: [email protected] >>>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>>> =end disclaimer >>>> >>> >>> >>> =begin disclaimer >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >>> SaoPaulo-pm mailing list: [email protected] >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >>> =end disclaimer >>> >> >> >> >> -- >> Tiago B. Peczenyj >> Linux User #405772 >> >> http://pacman.blog.br >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> >> =end disclaimer >> > > > > -- > Alexei "RUSSOZ" Znamensky | russoz EM gmail com | http://russoz.org > GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C > http://www.flickr.com/photos/alexeiz | http://github.com/russoz > "I don't know... fly casual!" -- Han Solo > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > > > > -- > Tiago B. Peczenyj > Linux User #405772 > > http://pacman.blog.br > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > =begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
