| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | A IBM está no caminho do zen.... :)
Agora a sério, o problema é o chafurdanço de uma cambada de burocratas idiotas que andam de volta do J2EE, aquilo é um cancro que já devia ter sido erradicado há muito tempo.
É impressionante que, por exemplo, haja a necessidade de haver milhentas formas diferentes de obter a path actual dependendo do contexto em que estás.
JAVA sempre foi mau e todo o mundo java só tem vindo a piorar com o tempo.. "agora" lembraram-se de enfiar uma coisa parecida com templates.
Porque é que só ao fim de 500 anos é que se resolveram a seguir o conselho sábio do Bjarne Stroustrup que PREVIU a complexidade nas bibliotecas JAVA based por precisamente não permitirem a contextualização de genéricos??
A melhor coisa que poderia acontecer ao Mundo era que este movimento da IBM para o PHP fosse seguido por todos os outros, incluindo a SUN!
tag
|
| |
| |
| | Os templates, como estão no C++, quebram os interfaces binários.
Os templates, como estão no Java, não são mais que "syntatic sugar" para evitar upcasts explicitos. Mas são, de facto, bem vindos.
|
| |
| | Obviamente, "downcasts", não "upcasts".
|
| |
| | | Agora a sério, o problema é o chafurdanço de uma cambada de burocratas idiotas que andam de volta do J2EE, aquilo é um cancro que já devia ter sido erradicado há muito tempo. Explica la' se faz favor porque e' que e' um cancro ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Quem tira fotografias a livros sobre: Design Patterns and J2EE Patterns.
NÃO pode sequer começar a perceber porque é que J2EE é dos piores cancros que há por aí, logo a seguir ao .net
Há por aí muito boa gente que continua a ganhar a vida a fazer ASPs em visual basic e não quer outra coisa.. e a vida é mesmo assim... o que interessa é sobreviver num mundo imperfeito e se J2EE e "design patterns" te faz sentir bem... continua.
tag
|
| |
| | | Diz-me, ja' alguma vez fizeste alguma coisa em J2EE ? E ja' agora, qual foi o projecto mais complicado em que participaste ? E' que para websites da treta qualquer merda da' - nao e' preciso PHP.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Ainda não respondeste porque é que o J2EE (ou J2SE + WebServices) é um cancro. Dá exemplos concretos! O que queres dizer com o tirar fotografias a livros....
|
| |
| | | O que queres dizer com o tirar fotografias a livros.... Quer dizer isto :)
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Isso é o mesmo que dizer que o papel higiénico é um cancro porque muita gente limpa o cu com pedras e é muito feliz.
Não tens argumentos melhores? É que esse é um bocadinho triste...
|
| |
| | Eu não trabalho com Java, pelo que não posso falar por experiência própria.
Porém, pelo que tenho lido de queixas da própria comunidade de Java, é que implementar um projecto com J2EE é extremamente complicado e muitas vezes nem sequer é necessário para resolver o tipo de problema que se tem.
Por esse motivo a própria comunidade de Java tem fugido de soluções baseadas em J2EE e partido para coisas mais simples como Hibernate.
A verdade é que só em casos em que o volume de transações é muito elevado é que é mesmo necessário usar servidores de aplicações. Porém, interessa a certas empresas empurrar soluções baseadas em servidores de aplicações porque são produtos caros e a complicação para os pôr a funcionar requer consultadorias altamente qualificadas que são pagas a peso de ouro precisamente devido a essa complicação.
O perigo para os entusiastas do Java é que a Microsoft apresente alternativas descomplicadas que roubem mercado a todas estas empresas que vendem servidores de aplicações ou ganham fortunas a vender consultadoria cara.
Penso que por aí se entende o interesse da IBM em não depender de Java e recomendar PHP para projectos que não precisam de servidores de aplicações, uma vez que o interessa é não permitir que a Microsoft ganhe mercado com as suas alternativas.
A vantagem do PHP no caso é que como não requer tão elevados conhecimentos, isso permite contratar profissionais a preços mais acessíveis, o que torna os projectos mais viáveis em particular para pequenas e médias empresas.
|
| |
| | | Tens consciencia que o que acabas de dizer nao faz sentido nenhum... ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Eu tenho a perfeita certeza do que o que disse faz todo sentido. Talvez me tenha expressado de forma demasiado difícil para entenderes, mas essa possibilidade não parece te ter ocorrido.
|
| |
| | | Por esse motivo a própria comunidade de Java tem fugido de soluções baseadas em J2EE e partido para coisas mais simples como Hibernate. Achas ? E' que esta do Hibernate so' demonstra que nao fazes a minima do que falas... sabes o que e' o Hibernate ?
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Achas ? E' que esta do Hibernate so' demonstra que nao fazes a minima do que falas... sabes o que e' o Hibernate ?
Parece que continuas a ter dificuldade em entender o que expliquei, mas como tu não consegues ter uma discussão no Gildot sem tentar insultar a inteligência de quem achas que não concorda contigo, mesmo quando o problema está na tua dificuldade de compreensão, eu vou-te fazer um desenho.
Desde há anos que desenvolvo uma solução para aceder a objectos persistentes que é usada para os mesmos fins que o Hibernate apesar de usar uma abordagem diferente. Como podes ver sei muito bem o que o Hibernate.
Quem usa apenas Hibernate pode dispensar perfeitamente servidores de aplicações porque lida directamente com a base de dados. Logo não tem que lidar com a complexidade de por J2EE EJBs a funcionar. O servidor de base de dados acaba por cumprir a função do servidor de aplicações. Para quem não precisa de lidar com uma escala tão grande de transações e por isso não precisa lidar com transações distribuídas, Hibernate é quanto basta.
Sobre o que a comunidade Java tem a dizer sobre o assunto, pergunta ao Google sobre j2ee ejb versus hibernate para ficares a par.
|
| |
| | | Hamm?!? Mas nao percebes que o J2EE traz muito mais do que EJB's ? O Hibernate e' apenas uma forma de atingir persistencia de objectos -- mais nada!
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Claro, mas o que tu continuas a ter dificuldade de entender é que muitas pessoas não querem ter que lidar com a dificuldade de desenvolver projectos baseados em servidores de aplicação porque a especificação J2EE que usa EJBs adiciona um nível de complexidade brutal que muitas vezes não é necessário.
Por isso muitas pessoas preferem usar Hibernate que permite aceder aos objectos persistentes da suas aplicações sem ter que lidar com a parafernália dos servidores de aplicação.
Enquanto os fanáticos de Java não entenderem estes detalhes, sempre vai haver muito espaço para plataformas e linguagens como o PHP que facilitam a implementação de projectos usando muito menos tempo, consumindo muito menos recursos em produção e custando muito menos dinheiro. Penso que de certa forma era esta a mensagem da IBM para os burocratas que controlam as especifições da plataforma Java.
O resto das teorias da beleza das linguagens e das plataformas é conversa para académicos e engrupir os clientes desinformados que vão pagar uma bolada em mão de obra, senão em licenças de servidores de applicação.
|
| |
| | | E o que e' que isso tem a ver com a afirmacao inicial de que o J2EE e' um cancro ? O J2EE deve ser aplicado quando a complexidade do que se esta' a fazer o exige - mas nao tenhas a minima duvida que o PHP nao e' substituto. O resto das teorias da beleza das linguagens e das plataformas é conversa para académicos e engrupir os clientes desinformados que vão pagar uma bolada em mão de obra, senão em licenças de servidores de applicação. No comments.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | E o que e' que isso tem a ver com a afirmacao inicial de que o J2EE e' um cancro ?
Sobre o cancro, tens de perguntar a quem o mencionou inicialmente sobre o que pretendia dizer. Eu apenas dei a minha interpretação sobre a dor de cabeça de implementar objectos persistentes com J2EE EJBs para os quais a propria comunidade de Java tem achado melhores alternativas como o Hibernate.
O J2EE deve ser aplicado quando a complexidade do que se esta' a fazer o exige - mas nao tenhas a minima duvida que o PHP nao e' substituto.
Eu se fosse a ti não dava palpites desses porque podes ter mais tarde ou mais cedo engolir alguns sapos e trabalhar com PHP para não perderes contratos.
A própria Sun já acordou para essa eventualidade de ter de integrar PHP com Java, algo demonstrado na especificação JSR 223. Portanto, talvez não seja boa ideia ficares a cuspir num prato de onde possas vir a ter que comer no futuro. Seja como for isso é problema teu.
O resto das teorias da beleza das linguagens e das plataformas é conversa para académicos e engrupir os clientes desinformados que vão pagar uma bolada em mão de obra, senão em licenças de servidores de applicação.
No comments.
Serviu-te a carapuça! ;-)
|
| |
| | | Bom, tu tens um talento natural para desinformar. Ou entao nao compreendes os assuntos aqui discutidos e acabas por confundir coisas differentes... Eu apenas dei a minha interpretação sobre a dor de cabeça de implementar objectos persistentes com J2EE EJBs para os quais a propria comunidade de Java tem achado melhores alternativas como o Hibernate. Deixa ver se vais la' com um bonequinho -- o Hibernate e' apenas uma ponte entre objectos e modelos relacionais. Em muitos casos o Hibernate ate' e' usado dentro de servidores aplicacionais como o JBoss, WebSphere, etc. A própria Sun já acordou para essa eventualidade de ter de integrar PHP com Java, algo demonstrado na especificação JSR 223. Mais desinformacao -- o JSR223 e' apenas uma proposta de trazer um modelo de scripting para dentro do Java. Algo que ja' e' possivel 'a anos com coisas como o Jython ou o Groovy. O que e' que isso tem a ver com PHP ainda estou para perceber. Serviu-te a carapuça! ;-) Nao me serviu nada -- apenas acho piada ao pessoal que insiste em nao perceber que coisas como PHP, Perl e outras simplesmente nao servem assim que a complexidade aumenta.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Bom, tu tens um talento natural para desinformar. Ou entao nao compreendes os assuntos aqui discutidos e acabas por confundir coisas differentes...
Como demonstras abaixo, o único confuso com dificuldade em compreender o que te dizem aqui és tu.
Eu apenas dei a minha interpretação sobre a dor de cabeça de implementar objectos persistentes com J2EE EJBs para os quais a propria comunidade de Java tem achado melhores alternativas como o Hibernate. Deixa ver se vais la' com um bonequinho -- o Hibernate e' apenas uma ponte entre objectos e modelos relacionais. Em muitos casos o Hibernate ate' e' usado dentro de servidores aplicacionais como o JBoss, WebSphere, etc.
Estás a repetir o que eu disse acima, com uma grande diferença: o Hibernate pode ser e é usado para aceder a objectos persistentes sem recorrer a servidores de aplicações e por isso toda a complicação de usar J2EE EJBs é evitada dado que a base de dados é acedida directamente.
Eu nem sequer estou a dizer que usar servidores de aplicação não é boa ideia. O que estou a dizer é que usar servidores de aplicação para aceder a objectos persistentes usando J2EE EJBs é uma complicação brutal que muitas vezes não se consegue justificar nem tecnicamente nem financeiramente.
A própria Sun já acordou para essa eventualidade de ter de integrar PHP com Java, algo demonstrado na especificação JSR 223.
Mais desinformacao -- o JSR223 e' apenas uma proposta de trazer um modelo de scripting para dentro do Java. Algo que ja' e' possivel 'a anos com coisas como o Jython ou o Groovy. O que e' que isso tem a ver com PHP ainda estou para perceber.
Pior que ser ignorante, é ser ignorante e teimoso.
Para tua informação, JSR 223 é uma iniciativa da Zend Technologies, empresa que criou mecanismo de execução do PHP. Se tivesses ao menos lido o documento terias percebido que não tem nada a ver com essas tangas que inventaste agora.
De qualquer modo, não é tarde para te começares a informar sobre o assunto aqui, que suspeito que ainda podes vir a precisar.
Serviu-te a carapuça! ;-)
Nao me serviu nada -- apenas acho piada ao pessoal que insiste em nao perceber que coisas como PHP, Perl e outras simplesmente nao servem assim que a complexidade aumenta.
Como tens vindo a demonstrar, único que não percebe as coisas aqui és tu.
Problemas complexos requerem soluções adequadas e pessoas capazes para as implementar. Seria mais honesto da tua parte admitir que não tens capacidade para implementar soluções adequadas em PHP para resolver problemas complexos.
Porém, a tua personalidade impede-te de admitir humildemente quando não tens conhecimentos e capacidade técnica para resolver problemas com tecnologias que não conheces, como é o caso do PHP.
|
| |
| | | Estás a repetir o que eu disse acima, com uma grande diferença: o Hibernate pode ser e é usado para aceder a objectos persistentes sem recorrer a servidores de aplicações e por isso toda a complicação de usar J2EE EJBs é evitada dado que a base de dados é acedida directamente. Fonix, devo falar uma lingua diferente. O J2EE nao e' so' persistencia - e' muito mais do que isso. Vires mandar o argumento de que J2EE e' isto ou aquilo porque existe o Hibernate e' no minimo falacioso. O que estou a dizer é que usar servidores de aplicação para aceder a objectos persistentes usando J2EE EJBs é uma complicação brutal que muitas vezes não se consegue justificar nem tecnicamente nem financeiramente. Depende do que queres tirar do servidor de aplicacao - se apenas queres percistencia se calhar nao vale a pena. Se quiseres load-balancing/fault-tolerance entao ja' vale. Estas a reduzir o argumento a um sub-conjunto muito pequeno. Para tua informação, JSR 223 é uma iniciativa da Zend Technologies, empresa que criou mecanismo de execução do PHP. Se tivesses ao menos lido o documento terias percebido que não tem nada a ver com essas tangas que inventaste agora. My bad, pensava que te estavas a referir ao JSR-241 - mas "essas tangas" demonstram precisamente o quao flexivel o Java e J2EE sao. Problemas complexos requerem soluções adequadas e pessoas capazes para as implementar. Seria mais honesto da tua parte admitir que não tens capacidade para implementar soluções adequadas em PHP para resolver problemas complexos. Porém, a tua personalidade impede-te de admitir humildemente quando não tens conhecimentos e capacidade técnica para resolver problemas com tecnologias que não conheces, como é o caso do PHP. Caro, ao longo dos anos tive o desprazer de ter que manter e gerir software escrito em linguagens tipo PHP. Curiosamente em todos esses casos foi feita uma migracao para J2EE - por varias razoes que sao facilmente documentaveis. Vires comparar PHP a J2EE e' risivel ao ponto de se tornar ridiculo.
I can live with doubt and uncertainty and not knowing. I think it is much more interesting to live not knowing than to have answers that might be wrong.
|
| |
| | Estás a repetir o que eu disse acima, com uma grande diferença: o Hibernate pode ser e é usado para aceder a objectos persistentes sem recorrer a servidores de aplicações e por isso toda a complicação de usar J2EE EJBs é evitada dado que a base de dados é acedida directamente.
Fonix, devo falar uma lingua diferente. O J2EE nao e' so' persistencia - e' muito mais do que isso. Vires mandar o argumento de que J2EE e' isto ou aquilo porque existe o Hibernate e' no minimo falacioso.
Concerteza estás a fazer-te de desentendido só para não dares o braço a torcer.
Eu estou-te a dar um exemplo de complexidade muitas vezes desnecessária que corrobora o comentário da IBM que a Sun, a principal responsável pela especificação J2EE, falhou em tornar o Java em algo tão simples como o PHP.
Muitos membros da comunidade Java comprovam isso tendo descartado soluções baseadas em servidores de aplicações através de EJBs, em favor de soluções que usam o Hibernate para aceder a objectos persistentes comunicando directamente com as bases de dados, evitando assim a complexidade do uso de servidores de aplicação com J2EE EJBs.
Não é a utilidade da Java e todas as especificações da Sun que estão em questão, mas sim a facilidade de uso.
Onde está a falácia? Será a IBM também falaciosa quando afirma que a Sun falhou em tornar a linguagem Java simples? Serão falaciosos todos aqueles que usam Hibernate directamente para evitar a dor de parto que é desenvolver projectos com J2EE EJBs? (Isto são perguntas de retórica, não são para responderes).
Problemas complexos requerem soluções adequadas e pessoas capazes para as implementar. Seria mais honesto da tua parte admitir que não tens capacidade para implementar soluções adequadas em PHP para resolver problemas complexos. Porém, a tua personalidade impede-te de admitir humildemente quando não tens conhecimentos e capacidade técnica para resolver problemas com tecnologias que não conheces, como é o caso do PHP.
Caro, ao longo dos anos tive o desprazer de ter que manter e gerir software escrito em linguagens tipo PHP. Curiosamente em todos esses casos foi feita uma migracao para J2EE - por varias razoes que sao facilmente documentaveis.
Só comprovas o que eu disse: não tens conhecimentos de como resolver problemas complexos em "linguagens tipo PHP", que deduzo nem sequer sejam PHP, mas mesmo assim culpas a linguagem.
A página que citas corrobora esse facto porque, pelos vistos, quem escreveu aquele texto, também não tem bases de PHP para saber que as soluções que ele pensa que se usam no mundo do PHP são apenas as que ele conheceu.
Preferes migrar para Java porque realmente é o que tu sabes. Quando é o otário do cliente que paga, melhor ainda para ti porque o tempo e dinheiro gasto na migração não te sai do bolso. Esse é o perigo das consultadorias, não estão ali para encurtar o desenvolvimento, mas para sugar o dinheiro do cliente o máximo possível.
Não me admira que trabalhes para outros, porque se dependesses das tuas soluções esbanjadoras para sobreviver devias viver permanentemente na falência.
|
| |
| | Desculpa, eu com um container J2EE (app server) tenho automaticamente segurança (as in autenticação/autorização), transacções e clustering, sem mexer puto a não ser num ficheiro de configuração em XML. 0 programming sk1llz necessárias.
Para o meu site, é overkill, um CMS faz definitivamente o que eu quero e é um CMS qualquer, mas para um site e-commerce, por exemplo, relegar estas funcionalidades para segundo plano é dar um tiro no pé.
Mantendo uma utilização de stateless session beans a escalabilidade horizontal dispara para níveis bastante agradáveis. Mais uma vez, não é preciso alterar o codebase.
O J2EE, ao contrário do que muita gente diz, não é um canhão para matar formigas. Pegas num Jakarta e ao usar JSP's estás a usar J2EE numa vertente bastante simplista.
Ao fim e ao cabo, os requisitos (problemas) é que são, na maior parte das vezes, complicados - mais complicados do que parecem à 1a vista - não o J2EE.
---
Este espaço pode ser seu... |
| |
| | Para o meu site, é overkill, um CMS faz definitivamente o que eu quero e é um CMS qualquer Esta é a parte relevante de tudo que disseste. O que a esmagadora maioria das pessoas pretende é um CMS para sites de baixa audiência.
Usar servidores de aplicação para isso é ridículo e muitas vezes inviável financeiramente porque o orçamemento disponível é baixo e não dá para pagar mais do que um servidor partilhado com PHP em safe mode.
|
| |
| | Concordo na parte relevante, discordo bastante na parte da inviabilidade financeira até porque existem serviços de UMLinux bastante acessíveis que se especializam em J2EE (é preciso ter em mente que o Tomcat utiliza uma parte do J2EE!)
---
Este espaço pode ser seu... |
| |
| | É verdade que a oferta de servidores VPS evoluiu muito e isso reduziu os preços, mas onde eu queria chegar é que devido ao safe-mode do PHP é possível alojar centenas ou milhares de clientes com necessidades básicas no mesmo servidor (VPS ou realmente dedicado) e com isso oferecer alojamento a preços ridiculamente baixos.
Este facto não é de agora, já ocorre desde há muitos anos e tem viabilizado do negócio de muitos ISP, e também de revendedores e consultores que desenvolvem sites para clientes e mesmo depois de prontos ganham dinheiro de forma continua porque enquanto permanecerem no mesmo alojamento, ganham uma comissão praticamente sem fazer nada para além de cobrar os clientes para lhes manter os sites a funcionar.
De qualquer modo, voltando ao teu exemplo, os USD $20 que pagas ali por mês por uns míseros 96MB de RAM que mal dão para alguma coisa, dão para pagar 1 ano de alojamento de servidor virtual com PHP/MySQL em muitos lugares. Não é uma configuração muito poderosa, mas é o que basta para muitos sites que na verdade têem pouco tráfico.
|
| |
| | A RimuHosting só serviu de exemplo porque eles ajudam à configuração de appservers nos VPS' deles.
Não é por causa do JBoss nem do Tomcat que lá tenho conta :)
---
Este espaço pode ser seu... |
| |
| | Mais ainda, nós que pregamos constantemente o facto de que uma instalação de Linux tem de, e pode, crescer com a empresa, não devemos negligenciar o facto de o website também poder crescer ao menor custo possível.
---
Este espaço pode ser seu... |
| |
| | O Hibernate apenas e só faz Object-Relational Mapping.
E também deves saber que para implementares um projecto J2EE não precisas de usar EJBs? Ou seja podes ter o melhor do J2EE sem aquilo que é considerado mais complexo num projecto J2EE.
O exemplo do Hibernate não foi feliz.
Cumprimentos,
Pedro.
|
| |
| | caminho certo... muhahaha. quando o PHP for escalável e distribuído, fala com a gente.
eu gosto de PHP, mas compará-lo com J2EE é um bocado parvo. Java (a linguagem) tem alguns problemas, muitos resolvidos com a última versão, outros com um bom IDE (Eclipse).
agora, eu nem me lembro das bibliotecas de J2EE... lembro-me q a ideia dos Beans e os servlets eram um bocado mais fortes que o PHP... n deves ter muito a ideia de quanto backend corre em Java...
repito, gosto de PHP, junto a PEAR e um "templating engine" (tradução?) como o smarty, mas é um bocado diferente.
-----
Windows isn't done until Lotus won't run. |
| |
| | A afirmação mais idiota do mês...
Tu não fazes ideia de quão útil o J2EE é para resolver problemas de grande dimensão num mundo real.
Pelos vistos, os teus conhecimentos são de PHP onde o PHP é mais utilizado: nos websites, mas estás-te a esquecer que apenas uma pequeníssima parte de J2EE tem a ver com isso.
O PHP para mim ainda está abaixo do PERL porque não tem a beleza deste, nem chega aos calcanhares de outras linguagens mais sérias como o Python, Java, etc... hell, prefiro mil vezes trabalhar com shellscript a ter de lidar com as manhas e inconsistências do PHP.
Agora vem cá falar de cancros.
---
Este espaço pode ser seu... |
| |
| | Idiota??? nice! é sempre bom subir o nível!
Como tal, podem passar ao guiché seguinte, nada de novo por aqui :-)
tag
--
faz amigos com ubuntu
|
| |
| | Ainda não disseste porque é que o J2EE é um cancro.
|
| |
| | | IBM has made significant investments in Java software and will continue to invest in Java industry standards and its WebSphere-branded line of server software and tools... Parece que eles nao acham que o java seja assim tao mau.. :) E pelo que precebi, o artigo foca principalmente o beneficio que o PHP vai ter com a sua adopcao por parte da IBM, tal como o java teve..
|
| |
| | Bom, só criticas e nenhuma fundamentação. A IBM está a adicionar o PHP à lista de plataformas suportadas, e não a atacar o Java.
Porque é que só ao fim de 500 anos é que se resolveram a seguir o conselho sábio do Bjarne Stroustrup que PREVIU a complexidade nas bibliotecas JAVA based por precisamente não permitirem a contextualização de genéricos??
Podias voltar atrás e pensar no que disseste. O Java é infinitamente mais simples do que o C++. Se o Stroustrup conseguiu alguma coisa, foi dar inicio à linguagem mais complexa, pesada e feia de sempre.
Os templates (e a STL) em C++ é que são um cancro, capaz de transformar código limpo e legível numa salada medonha.
--
Carlos Rodrigues
|
| |
| | | Os templates (e a STL) em C++ é que são um cancro(...) Bom, só criticas e nenhuma fundamentação :-)
____________________
Pedro Santos :: psantos.net |
| |
| | Não preciso fundamentar para além do "transforma código limpo numa salada medonha", porque é óbvio para qualquer pessoa que olhe para código que use a STL e o compare, por exemplo, o seu equivalente usando a QPL.
--
Carlos Rodrigues
|
| |
| | Engraçado que tenho uma opinião diferente da tua. Eu gosto de templates e acho a STL muito elegante. São opiniões... e tu não devias dar as tuas opiniões pessoais como verdades supremas, porque não o são.
____________________
Pedro Santos :: psantos.net |
| |
|
| | Os templates (e a STL) em C++ é que são um cancro, capaz de transformar código limpo e legível numa salada medonha.
Epa, desculpa lá, mas a STL é das coisas mais elegantes de se usar... Já experimentaste sequer ou só viste isso algures?
|
| |
| | A IBM está no caminho do zen.... :)
Amiguinho! Tu sabes e eu sei que tu sabes (e tu sabes que eu sei que tu sabes) que PHP não é o caminho do Zen :)
Zen seria alguem abraçar o C++ e dar-lhe uma default library digna desse nome... Algo da dimensão do Java (sem os whatevers que referes que não posso comentar porque não conheço) mas na lingua dos deuses do limbo (C++).
Ao abraçarem o PHP apenas estarão a abrir a porta a mais um zilião de n00bs que vão trabalhar a metade do preço e nos vão tirar o emprego (pensando bem, qual emprego? eheheh).
A maior força do PHP é precisamente a sua maior fraqueza: qualquer merdas pode fazer uns sites da tanga. Claro que quem sabe faz melhor (mais escalável, fácil de manter, performante, seguro, etc), mas as empresas não tem essa percepção (leia-se interesse). Eles apenas vêem o "aspecto" da coisa e o custo.
Resumindo... Good news para os recém graduados e para os curiosos da informática, que vão ter menos barreiras para conseguir emprego (aprenda php em 24 horas), bad news para quem já deixou o acne.
|
| |
| | Por isso é que andam a revolucionar o Webspheare.
|
| |
| | A IBM está um bocado atrazada, o PHP teve algum avanço espectacular nos últimos dias ou sou eu que estou muito à frente?
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| |
| | Que sistema de fazer páginas web dinâmicas é que usas que é mais facil de usar que o php?
É que os mais faceis de usar que eu conheço já andam por aí há muito tempo (asp, php).
Parece-me que tudo o resto é mais dificil de começar a usar e tendo em conta que a IBM quer suportar o que é mais utilizado, acho que fez a escolha certa.
... Ou então não. |
| |
| | mod_python e mod_perl, só tens que saber apanhar variáveis do web-server e enviar dados e headers, tudo o resto é igual para quem já conhece a linguagem, o mesmo acontece com o PHP (especialmente depois do REGISTER_GLOBALS=OFF).
Numa situação destas dava a vantagem ao python por ser a linguagem mais fácil de aprender e de compreender o código já feito.
CGI-BIN, é mais lento do que usar o os mod's mas mesmo assim se usares linguagens mais rápidas do que o PHP (com são o perl e o python) a diferença de velocidade do CGI-BIN não será suficiente para que os scripts não fiquem mais rápidos nestas duas últimas linguagens. Quanto à dificuldade de usar estas linguagens para programação web, nada que uma semana (e já estou a dar 4 dias a mais) a fazer uma biblioteca de funções não resolva (e olha que no caso do python até já existem módulos builtin para isso, evitando assim a quem quiser construir a sua própria biblioteca de funções ou objectos para trabalhar em web).
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
|
| | O Spyce não conheço e o Zope, fora o tempo de aprendizagem e adaptação ao Application Server é python, logo é fácil.
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| | Não digo que não sejam boas opções... Mas mais facil que php ou asp para começar um projecto web não são certamente...os números falam por si.
Mesmo em termos de prendizagem acho que qualquer uma delas ganha ás alternativas de que falas. Pelo simples facto de que o php e identico ao C e ASP usa uma especia de Basic.
Tendo em conta que são duas linguagens muito utilizadas e das primeiras a ser ensinadas, fica muito facil para quem quer fazer um projecto web optar por estas duas opções.
Deve ser por isso que o php ganha aos pontos como linguagem escolhida para aplicações web.
... Ou então não. |
| |
| | | O PHP sofre do efeito bola de neve. A primeira coisa que as pessoas ouvem falar é PHP. Mesmo que procurem outras alternativas, o PHP+MySQL é de longe o que tem melhor oferta de serviços de hosting.
O facto de a sintaxe de PHP lembrar vagamente a de C tem pouco a ver com a popularidade do PHP, até porque muitas dos que programam em PHP não pescam nada de C (e vice-versa).
O PHP tornou-se popular porque oferecia pré-processamento de HTML quando as pessoas ainda andavam a fazer as suas webapps em C e Perl puro. Contudo, o PHP nunca se tornou popular fora das webapps. Eu não gosto mesmo de PHP, mas acho que isto é um bom testemunho às limitações do PHP.
Hoje em dia, tens plataformas que te oferecem a conveniência do pré-processamento de HTML com linguagens de uso mais geral: JSP/Java, Spyce/Python. PS: Se por acaso isto der a ideia de que eu percebo ou sequer quero perceber de webapps, desenganem-se. ;-)
|
| |
| | Penso que mod_python com templates PSP é tão (ou mais) simples e rápido como PHP/ASP uma vez que tem a vantagem de poderes desenvolver em python puro (simples e poderosa), podendo pré-compilar as páginas.
Para quem gosta de python penso que não existe nada melhor (nem Zope - muito lento, nem Spyces & Cheetah's - mais uma camada inútil).
Em relação aos numeros é como o MySQL toda a gente diz que é muito rápida e que é a mais utilizada mas e depois? não quer dizer que seja a melhor, apesar de ser a mais simplista.
|
| |
| | nem Spyces & Cheetah's - mais uma camada inútil). Isto não me parece fazer sentido. O PSP, Spyce e Cheetah parcem-me todos a mesma coisa: pré-processadores de HTML/XML baseados em Python.
|
| |
| | Tens razão. Peço desculpa, onde se lê "camada", leia-se "módulo(s)".
Ou seja, todos esses 'pré-processadores', na minha humilde opinião, não acrescentam nada de útil ao mod_python que já vem com baterias incluidas.
|
| |
| | Esses benchmarks são para rir!:
1- As querys não fazem qualquer sentido
2- Claramente as BDs (excepto o PostgresSQL) não foram "cuidadas"
É preciso lata (do autor do benchmark) para publicar uma coisa destas...
|
| |
| | | CGI-BIN, é mais lento do que usar o os mod's FastCGI
|
| |
| | | E quem é que suporta FASTCGI em Portugal (no alojamento, por exemplo). Já agora mod_python, spyce, etc? Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | Se calhar aí está um nicho de mercado que vale a pena investir, pelo menos se estiveres a insinuar que as pessoas não usam porque apesar de ser melhor e os utilizadores preferirem não há oferta (se não é isto que estás a afirmar, então não vejo a pertinência deste comentário).
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| | | Não estou a afirmar. Estou a peguntar porque tenho dois sites meus para ir para o ar, preferia fazê-los em python porque o resto das aplicações é também em python e não sei se o sapo.pt tem python instalado, quanto mais FCGI ou WCGI ou spyce. Qunaod controlava os servidores, era twisted + nevow. Agora que tenho de alojar páginas, sinceramente não sei o que escolher. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
| | Aparece pelo clustercube.com e a gente trata-te disso =) sorry a pub :P da-mos ao cliente o que ele necessita...
Characteristic of life style... |
| |
| | Não tens que pedir desculpa, pelo contrário, está a mostrar uma solução para o problema, o facto da empresa ser tua ou de trabalhares nela não invalida que estejas a apresentar uma solução para um problema que até agora ninguém aqui tinha tido resposta.
Eu também agradeço até porque também estou à procura de um local para alojar um site de uma pequena empresa que vai precisar de ter algumas coisas dinâmicas e estou a planear fazê-las em python, e sendo assim vou tomar em conta o link que deste ;).
Já agora só mais duas questões: Em que formato é que vocês suportam python? PSP, spyce, CGI-BIN, mod_python? Qual o webserver?
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| | "Já agora só mais duas questões:(...)"
Não me parece que o Gildot seja o local adequado para este tipo de questões.
Repara: eu podia indicar aqui o nome de pelo menos 5 empresas portuguesas que disponibilizam o que referes e não trabalho para nenhuma delas nem tenho qualquer interesse nelas. Opto por não o fazer por consideração pelos outros 'gildoteanos' que não utilizam (salvo raras excepções) este fórum para promover as suas empresas ou aquelas onde 'dão o litro'.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| |
| | Epá, como o meu interesse é saber quem é que fornece esse tipo de serviços, e estou num fórum sobre software livre, e todo o software que está em discussão é livre acho que essa discussão está a ser feita no sítio ideal, como a discussão é sobre linguagens de programação e a sua aplicação em WEB, acho que até a thread é a ideal visto estarmos a discutir o problema de não haver alojamentos para este tipo de linguagens (e que aparentemente há mas que ninguém fala porque tem medo de estar a fazer publicidade).
Desculpa mas não percebo qual a lógica de eu (ou qualquer outro interessado) ficar sem saber que existe alguém que presta um serviço com suporte para mod_python quando já me estava a preparar para fazer a coisa em CGI-BIN, que eu veja só traz vantagens para qualquer dos lados, e quantos mais alojamentos com carecteristicas semelhantes aparecerem melhor porque mais competição significa melhor serviço.
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| | "mas que ninguém fala porque tem medo de estar a fazer publicidade"
Medo? Não me fiz entender com certeza.
Eu disse que tinha _consideração_ pelos outros que aqui participam e não fazem, nem querem fazer, publicidade às empresas onde trabalham e/ou são sócios.
O facto de não saberes que empresas existem em Portugal que prestam os serviços que procuras é revelador de duas coisas:
1. As empresas que o fazem não promovem devidamente este tipo de serviços;
2. Não procuraste o suficiente.
Repara que eu respondi à tua pergunta ("Já agora só mais duas questões: Em que formato é que vocês suportam python? PSP, spyce, CGI-BIN, mod_python? Qual o webserver?") e não à mensagem que anunciava o serviço.
Esse tipo de questões deves, em minha opinião, colocar em privado - é para isso que servem os e-mails.
Já imaginaste o que seria do Gildot se viessemos para aqui 'postar' publicidade às 'tasquinhas' de cada um?
Não vir aqui fazer publicidade (explícita) também protege as empresas das más-línguas ou das línguas-afiadas que existem.
Imagina o sarilho que seria se eu agora bebesse mais uns copitos e viesse para aqui com rumores (fundados ou infundados) sobre a incompetência de uma empresa que explicitamente se auto-publicitou... Estava o caldo entornado.
~~~ O vinho é q'induca e o fado é q'instrói ~~~ |
| |
| | | Repara que eu respondi à tua pergunta ("Já agora só mais duas questões: Em que formato é que vocês suportam python? PSP, spyce, CGI-BIN, mod_python? Qual o webserver?") e não à mensagem que anunciava o serviço. Esse tipo de questões deves, em minha opinião, colocar em privado - é para isso que servem os e-mails.
Já imaginaste o que seria do Gildot se viessemos para aqui 'postar' publicidade às 'tasquinhas' de cada um? Não percebo esse espírito de bota abaixo, quando se tratam de empresas grandes não vejo isso acontecer, publicam-se aqui artigos (e na minha opinião muito bem) sobre as soluções ADSL deste e daquele, esclarecem-se dúvidas e etc. e ninguém se queixa.
Quanto à utilidade da pergunta ser feita em público, eu vejo por aqui pelo menos duas pessoas a quem ela possa interessar (como clientes).
"The greatest obstacle to discovery is not ignorance -- it is the illusion of knowledge."
Daniel J. Boorstin |
| |
| | Pedi desculpa, porque se calhar a empresa que fornece suporte ao gildot a eurotux.com pode não gostar muito, mas é como tudo.. a concorrência só faz bem e sabermos as alternativas em Portugal é bom.
Por acaso sou um dos sócios, mas não administro a máquina e tenho outro tipo de funções, mas por aquilo que falei com o admin suportamos apache + mod_python actualmente, eventualmente se houver necessidade poderemos instalar outro tipo de software se for rentável. Lembro-me que numa máquina antiga tinhamos tomcat (java), mas actualmente não porque não é rentável termos isso a correr.
Characteristic of life style... |
| |
| | da-mos??? De que língua é essa palavra?
|
| |
| | Nunca disse que era professor de português :-) mas na verdade é que não acerto muito bem com as palavras com "-" =)
Characteristic of life style... |
| |
| | Pois, mas "damos" não tem traço...
Não é preciso ser professor de português para falar e escrever bem a nossa língua, é uma obrigação básica de qualquer cidadão.
|
| |
| | Sim, mas e se este não nasceu em Portugal ? =) faço o melhor que posso.. :-) hehe
Quando escrevi, ainda pensei.. será com ou sem traço, mas parece que escolhi a má opção.
Characteristic of life style... |
| |
| | flash!
/me corre
-----
Windows isn't done until Lotus won't run. |
| |
| | O problema não são as páginas dinâmicas. Há uns tempos tive que adaptar um sistema feito por uns gringos que envolvia uma appliance que comunica com um application server alojado numa máquina qualquer.
O código do application server era 100% PHP. Tudo era feito em PHP! A aplicação web de consulta e configuração, a comunicação com a applicance (HTTP), o housekeeping, tudo em PHP!
Aquilo era um dos exemplos mais flagrantes do famoso "código esparguete" que alguma vez vi na minha vida. Estava tudo misturado e remisturado, a GUI, a comunicação com a applicance, acesso à base de dados, tudo no meio de uma salada indecifrável de código com páginas a fazer require de outras a fazer require de outras, etc.
Enfim, se eu pudesse, teria feito aquilo em Java, com uma separação muito clara entre as camadas, utilizando SOAP para comunicar com a appliance. Usaria os tais patterns tão difamados em alguns posts aqui, ou seja, faria uma verdadeira solução de engenharia, adequada à complexidade do problema, e não uma mistela à code monkey chico-esperto, meio atamancada como aquela que está lá, que é totalmente incompreensível a não ser para o louco que a fez, e é um verdadeiro pesadelo para gerir ou adaptar.
Nunca pensei que os gringos fossem tão amadores. Pensava que aquele tipo de merda fosse mais do género dos aprendizes de feiticeiros tugas.
|
| |
| | 3 words: job security!
E sim, não sou php zealot!
/me ducks
==
"Se vi mais longe foi porque comprei a porra duns binóculos." - Zé da Esquina |
| |
| | É incrivel pelo que começa por uma simples notícia se transforma numa grande discussão tipica do meu p... é maior que o teu.
Sou programador de PHP à 5 anos (trabalho apenas nisto, básicamente em LAMP), portanto acho que não sou suspeito.
Estou um bocado farto do PHP 4, talvez quando mudar para o PHP 5 a minha opinião mude com o novo object model. Mas falando do que conheço (PHP 4), estou farto porque:
- Simplesmente tem um pseudo object model que nem merece comentários. O resultado disto é que criar uma aplicação que se quer robusta e escalável é quase impossível porque os objectos simplesmente não possuem encapsulamento.
- O PHP 4 não possui métodos ou classes estáticas, um efeito directo é que por exemplo se eu usar apenas um objecto de ligação à base de dados e querer algo como o MVC tenho que andar a passar referências de objectos, dava jeito um getInstance(), não?
- As frameworks existentes são práticamente todas incrivelmente ridiculas, coisas como o Horde(em que o IMP foi desenvolvido) possuem um overhead incrivel para fazer o que faz. E sim já vi o seu código, nem merece comentários, nem sei como estes tipos dão conferências sobre isto.
O engraçado é que grande parte das frameworks que vi tentam simular coisas do java ou .Net, vi uma até que tinha a mesma estrutura de directórios idêntica (WEB-INF) e um web.xml para as configurações.
"O desenvolvimento em PHP é mais rápido":
Lógicamente que sim para pequenos/médios projectos, mas também perde em funcionalidades.
Utilizei apenas para fins académicos Java Servlets , JSP e Javabeans.
Não achei assim tão complicado o uso dos Javabeans.
O JSP 2.0 já tem as EL(Expression Language) em que básicamente já se tem um sistema de templates similar(melhor até) ao smarty, e é extremamente simples de se usar.
Isto tudo a somar à extensa API do Java (RMI, Corba, Java2D, etc.)...
[JOKE]
Talvez mude para as linguagens funcionais tal como o erlang:
factorial(0) -> 1;
factorial(X) when X > 0 -> X * factorial(X-1).
[/JOKE]
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| |
| |
| | É incrivel pelo que começa por uma simples notícia se transforma numa grande discussão tipica do meu p... é maior que o teu.
O meu --mesmo após 3 horas no congelador-- é maior que o teu a milhas!
Religion, the only confort left in a world splited by religion. (The Daily Show) |
| |
| | LOL
O meu é pequenino mas é trabalhador ;)
"You have to know, not fear, that someday you are going to die. Until you know that and embrace that, you are useless."
Tyler Durden |
| |
| | Trabalhar, não implica ter Qualidade no que se faz =)
Characteristic of life style... |
| |
