| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | por Anonimo Cobarde em 19-07-01 10:59 GMT (#1)
|
| O phython é uma linguagem de scripting, o Java é uma linguagem ponto.
|
| | | | | | | E a diferença de etiquetas quer dizer que em Python não é fácil nem conveniente nem apropriado escrever que tipos de programas (supostamente fácil, convenientemente e apropriadamente escritos em Java)? Isto excluindo uma questão de performance que seria resolvida em C ou eventualmente C++... O Python não é apenas apropriado para scripts de poucas linhas escritos à pressa para desenrascar e que nunca mais se lêem... Aliás, umas das virtudes da linguagem é a forma como consegue ser "escalável" desde os problemas mais simples (que se consegue resolver de forma simples e sem o overhead associado a outras ferramentas) até aos problemas mais complexos, incluindo a integração com componentes noutras linguagens.
|
| | | | O que disseste e tao absurdo...
Normalmente refere-se a scripts quando se fala de pequenos programas quick and dirty feitos em alguma linguagem de programacao interpretada.
Tanto o Java como o Python sao linguagens de programacao orientadas/baseadas em objectos. Qual a melhor? Sinceramente nao sei, acho que a programacao por objectos e mais uma questao de filosofia de programacao do que outra coisa qualquer. Claro que teriam de surgir algumas linguagens que facilitassem a utilizacao pratica desta filosofia de programacao.
Agora este argumento e provavelmente o mais ridiculo de todos os apresentados nesta thread.
Quanto a indentacao, e relativamente facil mudar a indentacao de codigo de formas automaticas, por isso nao serve sequer de argumento. O facto de te forcar a uma indentacao tem a "vantagem" de que vais ler codigo todo com o mesmo estilo de indentacao.
Quanto a rapidez, qualquer linguagem "objectual" perde em eficiencia de desempenho, e depois, o java pq corre num bytecode, o python pq e interpretado, perdem por nao serem aplicacoes nativas. Qual a pior forma? Bem... o perl e interpretado e e fenomenalmente rapido... mas creio que se alguem quer mesmo rapidez absoluta e ao maximo no desempenho da aplicacao, certamente nao vai escolher nenhuma destas tres (excepto se envolve manuseio abusibvo de expressoes regulares, caso em que o perl vai bater a rodos). Para alem disso, a brutalidade que os cpus de hoje em dia sao, permite que precisemos mais de nos preocupar com a utilidade e rapidez de desenvolvimento. Claro que quando se for a escalabilidade, depois vem-se com tretas do genero de uma maquina precisar de nao sei quantos gigas de memoria pq a aplicacao que faz uma coisa simples e feita em java...
Contudo, termino por dizer que prefiro um bom programador em perl do que um mau programador em java, e VICE VERSA. Mas melhor que isso, prefiro um gajo que nao me venha dizer que a tecnologia XPTO e a solucao para todos os males.
Hugs, Cyke
|
| | | | Acho que uma das diferenças e pegando no que disseste do bytecode sim e nao qul o pior do java é que no java uma das causas que leva a este a eas aplicaçoes feitas no mesmo serem mais ou menos rápido se deve a qualidade do vm em que este corre dependendo deste esssencialmente o seu desenpenho. Quanto ao python não faço a minima ideia porque nunca mexi nisso.
|
| | | | O Python não tem uma plataforma de base para desenvolvimento de aplicações empresariais n-tier como tem o java (J2EE). Tanto quanto sei tem o zope que é parecido ao tomcat (jsp's) ou seja um servidor de páginas dinâmicas como o PHP, ASP's, etc...
Ora no que toca a aplicações empresariais isso não chega. É necessário separar o modelo de negócio das fontes de dados e das interfaces (que podem nem ser web) e integrar aplicações novas com sistemas legados.
Actualmente existem 2 grandes concorrentes neste mercado: a Microsoft e a Sun. No primeiro caso encontras a nova treta .NET, DCOM+ e C#. Isto não queremos! Depois tens a plataforma da Sun derivada da tecnologia Corba e com montes de produtos (Jboss, BEA Weblogic, etc...).
A questão de base é que uma linguagem de programação, não é, por si só, uma plataforma de desenvolvimento. É, no entanto, um componente essencial dessa plataforma.
Tó-Zé 'Senador' |
| | | | | | | O que é que as "plataformas de desenvolvimento" multi-nível multi-buzzword acrescentam? Não estou familiarizado com elas (o acima é mesmo uma pergunta, não ironia), mas fico com a impressão de que inserem no processo uma quantidade brutal de problemas de interdependência, de dependências em relação às empresas que as fornecem, e em geral toneladas de complexidade supérflua nos "montes de produtos" (até porque quando entramos na esfera puramente comercial "closed source", a essência do jogo é estar permanentemente a mudar o cenário para vender, vender, vender). O Zope, bem aplicado, fomenta algo diferente do que (diz-se) PHP e JSP fomentam, pelo menos se mal usados (mistura confusa do tal "modelo de negócio", fontes de dados e interfaces); não se trata apenas de servir "páginas dinâmicas" (o lado das páginas tentando o mais possível restringir-se à função de "templating") mas "objectos", objectos que podem perfeitamente falar com outros objectos construindo-se a estrutura que for mais conveniente. Quem não consegue gostar do Zope pode tentar, por exemplo, o Webware. O Python sempre me pareceu uma excelente "gluing language", com a qualidade rara de ser simpática para usar desde as aplicações mais triviais (facilitando a aprendizagem até como primeira linguagem) até grandes projectos. Mas outros com boa experiência da complexidade de grandes projectos poderão explicá-lo melhor do que eu. Já agora, a propósito de "aplicações n-tier", o que acham do artigo "Scalability, Three-Tiered Architectures, and Application Servers"?
|
| | | | Não se trata de uma questão de buzzwords. São coisas tão diferentes quanto é a diferença duma aplicação monolítica para um sistema cliente-servidor.
A arquitectura de um SI está intimamente ligada com a arquitectura organizacional da empresa. Melhor dizendo, deveria estar.
Isto não quer dizer que o Python seja uma má linguagem para certas aplicações. É uma excelente linguagem. Mas são necessárias mais coisas para mapear uma arquitectura organizacional e os processos de negócio (sim, isto é Economia!) numa aplicação coerente. Para isso temos plataformas que acrescentam uma base de, entre outras coisas, escalabilidade, redundância, abstracção, segurança e integração.
Tó-Zé 'Senador' |
| | | | E em que é que a linguagem Java favorece o não monolitismo por comparação com Python?
|
| | | | | No www.python.org estão disponíveis comparações de Python com outras linguagens, incluindo Java. Para além das qualidades intrínsecas da linguagem, achei e acho apelativo o facto de ser software livre, menos sujeito aos caprichos puramente comerciais que poderiam afectar a linguagem se fosse fortemente controlada por uma empresa ou um pequeno número delas, incluindo alterações bruscas no apoio à linguagem, mudanças de características por razões "políticas" de marketing (incluindo featuritis ), e incerteza sobre limitações futuras à liberdade de uso...
|
| | | | | É mais rápido programar em python e cometem-se menos erros. Se tivermos em conta que um programador, por mais barato que seja, custa no mínimo 4.000$00/hora (incluindo software, hardware, impostos, segurança social, material de escritório, etc). Isso quer dizer que cada erro pode custar, rapidamente, mais de uma centena de contos (quem já programou um sistema médio conhece a sensação de passar uma semana à procura de um bug que até era simples, quando descoberta a sua causa). O Java foi feito nestes pressupostos. A principal razão para a existência de um garbage collector era que a grande maioria dos bugs eram de gestão de memória. Programar em python é mais rápido, mais simples e o código é mais legível, o que facilita a detecção de problemas. Por isso defendo que é melhor o Java. Claro que não vamos confundir a linguagem com a plataforma, essa é outra guerra.
|
| | | | | | | O Java foi feito nestes pressupostos. A principal razão para a existência de um garbage collector era que a grande maioria dos bugs eram de gestão de memória. O "garbage collector" e' muito mais que isso -- e' algo que gere racionalmente a "heap" de um processo. Estas a reduzir as coisas sem saberes do que estas a falar. É mais rápido programar em python e cometem-se menos erros. Humm... em que baseias uma afirmacao tao generalizada -- nesse caso programar em VB e' ainda mais rapido, e isso nao quer dizer que seja uma linguagem "melhor". Programar em python é mais rápido, mais simples e o código é mais legível, o que facilita a detecção de problemas. Por isso defendo que é melhor o Java. Claro que não vamos confundir a linguagem com a plataforma, essa é outra guerra. Humm -- por muito que goste de Python, nao estou a ver como e' que uma linguagem que baseia a definicao de blocos com indentacao e' mais legivel. Tambem nao estou a ver como e' que isto permite detectar melhor problemas -- para mim os problemas sao resolvidos com um bom design e planificacao *antes* de escrever seja o que for. (...) em python é mais rápido, mais simples e o código é mais legível, o que facilita a detecção de problemas. Por isso defendo que é melhor o Java. (...) Fugiu-te a boca para a verdade... Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias
|
| | | | | O "garbage collector" e' muito mais que isso -- e' algo que gere racionalmente a Estas a reduzir as coisas sem saberes do que estas a falar. "heap" de um processo. Não estou a reduzir, estou a afirmar que a maior vantagem de um garbage collector é, efectivamente, gestão automática de memória. Se é mais racional ou não, deixo isso para os especialistas de gestão de memória. em que baseias uma afirmacao tao generalizada -- nesse caso programar em VB e' ainda mais rapido, e isso nao quer dizer que seja uma linguagem "melhor". Experiência pessoal e de outros. O VB tem uma grande desvantagem em relação a outras linguagens (sim, porque aquilo deixou de ser BASIC há muito tempo): a sua legibilidade. Não sei se alguma vez tiveste de fazer debugging de uma aplicação VB, mas não o desejo ao meu pior inimigo. (...)Tambem nao estou a ver como e' que isto permite detectar melhor problemas -- para mim os problemas sao resolvidos com um bom design e planificacao *antes* de escrever seja o que for. Os maiores custos de software hoje em dia são de manutenção. Neste caso já não há design e planificação que te safem (a não ser algumas técnicas de refactoring, embora ainda não tenha encontrado nada de especialmente útil). Nestes casos quando faço um sistema que usa outros programas ou quando corrijo erros no sistema de alguém não me posso dar ao luxo de assumir que foi tudo bem pensado à partida. Nestas situações, em que refazer do zero não é uma opção, a legibilidade do código é importante, e, se conheces python, sabes que só o dispensar das chavetas e a simplicidade da sintaxe permite-te ter mais código útil no ecrã e escrever código mais compacto sem reduzir a legibilidade. Estas características são critícas quando tens de compreender o que faz o código (indispensável em processos de refactoring. Fugiu-te a boca para a verdade... Se toda a gente fosse perfeita não era preciso ter código legível, pois não ?
|
| | | | | >O "garbage collector" e' muito mais que isso -- e' algo que gere racionalmente a "heap" de um processo. Estas a reduzir as coisas sem saberes do que estas a falar Exerces um esforço consciente para ser rude?.. Ou isso á tão natural que nem notas?
Seja como for o autor do comentário parece saber do que está a falar, o "garbage collector" serve essencialmente para libertar endereços de memória que já não estão a ser referenciados, se isto é uma redução, é das mais elucidatórias que tenho visto. >Humm... em que baseias uma afirmacao tao generalizada -- nesse caso programar em VB e' ainda mais rapido, e isso nao quer dizer que seja uma linguagem "melhor". Talvez o autor do comentário baseia essa afirmação na sua experiência pessoal com a linguagem, experiência que, a julgar pelos relatos de pessoas que usam as duas linguagens, é partilhada por outros. Mas tens razão isto é a opinião do autor, não um facto cientifico. Humm -- por muito que goste de Python, nao estou a ver como e' que uma linguagem que baseia a definicao de blocos com indentacao e' mais legivel. Não estás a ver?! Como disse o Yoda : "That is why you fail." > (...)Tambem nao estou a ver como e' que isto permite detectar melhor problemas (...) Conclusão natural da premissa anterior > (...) para mim os problemas sao resolvidos com um bom design e planificacao *antes* de escrever seja o que for. Falando da minha experiência pessoal nem sempre tenho o luxo de estar envolvido na fase de análise e especificações de um projecto, muitas vezes só sou chamado depois do "crash & burn". Assumir que as coisas foram bem pensadas "*antes* de escrever seja o que for" é o erro de palmatória #1. E como deitar o que está feito fora e começar de novo não é uma opção, tenho que chafurdar em código alheio. Nessas alturas acho que dar um beijo na mão do Guido van Rossum e chamar-lhe Padrinho por ter criado uma linguagem compacta e que quase se lê como se fosse uma linguagem natural é um acto de reverência adequado. >>(...) em python é mais rápido, mais simples e o código é mais legível, o que facilita a detecção de problemas. Por isso defendo que é melhor o Java. (...)
>Fugiu-te a boca para a verdade... Errare humanum est
luis
|
| | | | | Exerces um esforço consciente para ser rude?.. Ou isso á tão natural que nem notas? Desculpa la' -- o que o jneves disse sobre "garbage colectors" e' uma reducao simplistica sobre as coisas, que no contexto usado nao poe o Java em muito boa luz. Se queres ter uma discussao tecnica, deves estar preparado a ouvir umas bocas quando dizes asneiradas -- eu espero a mesma coisa. Não estás a ver?! Como disse o Yoda : "That is why you fail." De cada vez que nao tens conhecimentos suficientes para justificar algo usas um quote do StarWars ? Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias |
| | | | | >(...)deves estar preparado a ouvir umas bocas quando dizes asneiradas -- eu espero a mesma coisa(...) Totalmente de acordo. Pena é que as tuas "bocas" se resumam a comentários depreciativos acerca da conhecimentos técnicos de pessoas que muito provavelmente não conheces. De cada vez que nao tens conhecimentos suficientes para justificar algo usas um quote do StarWars ? Q.E.D.
Penso que num forúm que se quer de saudável troca de ideias comentários do tipo : ".. não sabes do que estás a falar..." e " ...vai ler um livro antes de abrires a boca..." são contra-producentes. Criam nos intervenientes posturas defensivas. Se alguém comete uma "gafe" deve ser corrigido, mas de maneira construtiva. Somos todos humanos, todos erramos, e o gildot apesar nos esconder atrás dos nossos monitores é uma praça pública, nenhum de nós gosta de ser chamado de nabo em praça pública. Eu também cometi o mesmo erro que tu. A quote do Star Wars foi despropositada, por isso peço desculpa. Penso que o jmce respondeu às tuas dúvidas ("nao estou a ver como e' que uma linguagem que baseia a definicao de blocos com indentacao e' mais legivel. Tambem nao estou a ver como e' que isto permite detectar melhor problemas"). luis
|
| | | | | Totalmente de acordo. Pena é que as tuas "bocas" se resumam a comentários depreciativos acerca da conhecimentos técnicos de pessoas que muito provavelmente não conheces. Desculpa novamente -- em que e' que o meu comentario for depreciativo ? Chamei nabo a alguem ? Simplesmente comentei que o que o jneves disse era uma simplificacao extrema, e que da forma como ele o disse estava a retratar uma linguagem (Java) como uma porcaria qualquer e que o Python e' que e' bom.
Da minha parte, um argumento reducionista mereceu uma resposta reducionista.
Q.E.D. Ainda estou 'a espera da tua justificacao tecnica. Penso que num forúm que se quer de saudável troca de ideias comentários do tipo : ".. não sabes do que estás a falar..." e " ...vai ler um livro antes de abrires a boca..." são contra-producentes. Criam nos intervenientes posturas defensivas. Se alguém comete uma "gafe" deve ser corrigido, mas de maneira construtiva. Concordo plenamente -- mas nao estou a ver porque e' que se alguem afirma que outro tipo nao parece perceber muito de um assunto (o que a mim me parece ser o caso) isto e' destrutivo. Numa comunidade como esta que abraca o movimento open-source a discussao livre entre peers deve ser respeitada, e criticas, mesmo quando "destrutivas", se teem bons argumentos tecnicos por tras devem ser respeitadas -- no entanto concordo contigo que nos devemos respeitar uns aos outros -- mas como nao insultei a inteligencia de ninguem (pelo contrario, muitas vezes ha' uns "espertos" que parecem jogar as coisas a seu favor no Gildot) nao vejo porque e' que tenha sido destrutivo. Regards,
-- "Why waste negative entropy on comments, when you could use the same entropy to create bugs instead?" -- Steve Elias |
| | | | Já vi realmente que faz parte da tua natureza e não ponho em causa o teu conhecimento técnico mas concordo plenamente com o outro user penso que seja o (Luis) porque por vezes es um bocado impulsivo embora não é crime nenhum o ser o que não é certo e que mesmo apos um esclarecimento por parete do "jmce" continues a bater na mesma tecla será por seres teimoso ? Ou pior que isso ?
A vida é para ser vivida com mais calma é acho que foi isso que transpareceu da opniºão do luis que no fundo era uma reflezão das atitudes que ele tb tem, só tinhas que fazer o mesmo refletir um pouco.
|
| | | | Totalmente de acordo! (é redundante mas não ha mas nada nesse comentário que hakja para acrescentar o que senão a minha expressão de concordância com este user.)
|
| | | | | A legibilidade não ajuda a re-leitura do código e a pesquisa de problemas, para um mesmo nível de organização com que se trabalhe? Legibilidade e indentação? Menos elementos, dos que não auxiliam imediatamente a "ler", no texto do código, logo código mais expurgado de elementos menos importantes do ponto de vista da percepção humana: numa linguagem que baseia a definição de blocos em outros elementos de sintaxe, a indentação continua a ser uma ajuda fundamental para ao ler percebermos rapidamente o aninhamento de blocos... como já notou qualquer pessoa depois de aninhar incorrectamente blocos (chaveta a mais ou a menos em C, por exemplo) apesar de a indentação sugerir que tudo estaria bem. Mas claro que nem todos funcionam da mesma maneira, e a legibilidade de uma sintaxe pode não ser a mesma para todos. Nenhuma linguagem evita a necessidade de um bom design, mas isso não quer dizer que o trabalho custe o mesmo com todas as linguagens (e dependendo também do domínio: é possível programar o cálculo das fases da Lua em TeX, mas há ferramentas mais simpáticas quando se passa do processamento de texto ao cálculo das fases da Lua). Não pensando agora no facto de se estar a trabalhar a um nível mais alto do que, por exemplo, em C (o que evita tratar de muitos pormenores, mas não tenho experiência de Java para fazer a comparação com esta), há várias características da linguagem que contribuem para essa sensação (que é bastante comum) de mais facilidade de trabalho sobre Python. Parte virá talvez de ser uma linguagem muito compacta... é fácil manter "na cabeça" o conjunto da linguagem sem ter de rever frequentemente uma enorme quantidade de variações e efeitos subtis associados a diferentes construções. Fica-se com a sensação de uma linguagem muito bem planeada e consistente. Por comparação o Perl traz nele muitas camadas de história, tanto de interfaces anteriores ao Perl (variadas ferramentas de Unix) como da evolução do próprio Perl; para algumas pessoas essa combinação é simpática e a filosofia geral da linguagem resulta bem, para outras frustrante pela "visibilidade" que a linguagem assume por comparação com o problema que se procura resolver com ela. O que fui sentindo sobre o Python, e o que tenho ouvido outros contar sobre como foram ganhando gosto pela linguagem, parecem coincidir em muito com um relato do Eric Raymond.
|
| | | | Bom era mesmo de um comentário desses que precisava estou precisamente agora neste dilema java ou python eis a questão :)
Estive todo empenhado a olhar para o java mas como sou decendente da forja de programadores que usam IDE para fazer qualquer coisa fui directamente para o java pelos argumentos apresentados pela sun e pelo editor que embora não sejo o melhor que por ai ha mas ao menos é qualquer coisa nem cheguei a olhar para o resto agora com essa discursão por aqui vou acabar por ver melhor o python e não na diagonal.
Obrigado a todos por porem isso em praça :)
|
| | |
|
