| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Nesta história da importância do Mono, mantenho a minha posição de há 15 dias. O Mono é uma boa ideia ser for encarado como uma nova plataforma, mas é uma má ideia se for encarado como uma plataforma compatível com o .NET pois nunca o será. O .NET é a última estratégia de lock-in da Microsoft (e até hoje a mais perigosa) e eles não vão deixar que exista uma implementação compatível noutros SOs que não o Windows.
Eu acho incrível como o Java demorou anos a impôr-se e agora toda a gente salte cegamente para a carruagem do .NET só porque é da Microsoft. O espírito de manada é realmente uma coisa curiosa...
-- Carlos Rodrigues
|
| | | | | | [2] Sim, o Java já faz isso, mas a maior parte dos programas em Java com UI gráfica são lentos.
Este é, sem dúvida nenhuma, o mito número 1 do Java.
-- Carlos Rodrigues
|
| | | | | Pois, isso era o que eu dizia. Mas ainda está para vir um programa com interface gráfica em Java que não seja lento. Os últimos casos que experimentei foram o ArgoUML e o dMSN, cada um pior que o outro. Em termos não UI, realmente o Java está cada vez mais rápido, tenho lido sobre isso. Mas no que toca a SWING e AWT... acho que não podes defender tão radicalmente o Java. E com isto nem digo que a culpa seja do Java. Eu já li um livro sobre optimizações em Java, que relatava técnicas sobre obter melhor performance em aplicações gŕaficas com Java, e realmente há imensos pormenores que passam ao lado de um programador normal (pelo menos a mim passavam). São estas coisas que eu digo que falta na documentação do Java. Eu quando digo que a documentação é má, não é por ter uma descrição de todos os métodos (que tem), é porque se queremos ir mais abaixo, se queremos as coisas mais ao pormenor, não as temos.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Pois, isso era o que eu dizia. Mas ainda está para vir um programa com interface gráfica em Java que não seja lento. Os últimos casos que experimentei foram o ArgoUML e o dMSN, cada um pior que o outro. Em termos não UI, realmente o Java está cada vez mais rápido, tenho lido sobre isso. Mas no que toca a SWING e AWT... acho que não podes defender tão radicalmente o Java.
Nos últimos tempos o Java tem dado enormes saltos em termos de performance, mas é verdade que o Swing não é particularmente rápido. Mas não te esqueças que o Swing é completamente portável, e como tal não usa widgets nativos e outras técnicas para obter mais performance. Para mim isto é uma vantagem e não uma desvantagem. Quem quer UIs rápidos em Java pode muito bem usar o SWT (o Eclipse usa SWT e não é nada lento em termos de UI) sacrificando o Write Once Run Anywhere.
Em .NET não tens um equivalente ao Swing, tens um equivalente ao SWT, e como esta é a única forma de fazer UIs suportada pela Microsoft, o Mono ou é 100% compatível ou é irrelevante, e isto não é uma tarefa fácil, a Microsoft certificou-se disto.
-- Carlos Rodrigues
|
| | | | Mas não te esqueças que o Swing é completamente portável, e como tal não usa widgets nativos e outras técnicas para obter mais performance.
Não conheço java, mas o que dizes não faz muito sentido.
Se cada sistema operativo precisa de uma VM, porque não se optimiza a interface gráfica para utilizar a aceleração?
O código seria portável na mesma...
|
| | | | O Swing usa aceleração, a aceleração que a API de linhas e pontos do Win32 ou X11 proporciona. Mais do que isso tornar-se-ia dificílimo de manter em mais do que 2 ou 3 plataformas pois cada toolkit tem as suas particularidades. Um bom exemplo disto é o look GTK+ do Swing. Aquilo usa o GTK+ mas em muitas áreas (tipo a semântica de desenho dos widgets no pai) as diferenças são inconciliáveis. É por isso que o look GTK+ não é o default em Linux, tem imensos bugs, alguns deles nada triviais de resolver sem mexer nos conceitos do próprio Swing.
-- Carlos Rodrigues
|
| | | | Ah, mais um detalhe. O Swing é escrito em Java, não é nativo, isto para assegurar a portabilidade para todo o lado com o mínimo esforço e o mínimo de problemas de compatibilidade. Como eu disse, quem quer velocidade usa o SWT, que não está presente em todas as plataformas onde existe Java.
-- Carlos Rodrigues
|
| | | | Mas ainda está para vir um programa com interface gráfica em Java que não seja lento. Descarrega este ficheiro de 2 KB e carrega-o com o teu Java Webstart. Em Linux basta executar: javaws alienflux-full.jnlp Depois de o experimentares não voltarás a dizer que um GUI em Java é lento...
|
| | | | | Aprovado. Ninguém rejeita o Mono por ser da Microsoft, mas por desconfiança quanto às intenções da Microsoft, o que são duas coisas completamente diferentes. Francisco Colaço
|
| | | | Concordo plenamente contigo, eu tenho as mesmas desconfianças.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | | Já não olhava para o dotgnu à bastante tempo e pelo que vi agora, parece que apesár de estár um pouco incipiente é promissor: já tem um compilador de C# (embora o trabalho ainda não esteja completo), mas como está a ser escrito em C e não em C# como o do mono, é compriensivél que demore mais tempo (para além de este projecto ter muito menos apoios), algo que achei interessante é o compilado de C# do dotgnu poder compilar codigo para correr uma JVM (isto também ainda não está completo). Ao contrário do projecto mono as window$ forms parecem ser uma prioridade, e ao que parece já há trabalho nessa àrea. Também algo que é novidade para mim é que o dotgnu vai utilizar algumas das bibliotecas de nivél mais alto do mono, e ambos os projecto têm está a aproveitar o trabalho um do outro e parece que assim iram continuar.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | | Carreguei no botão errado. Continuando... Na FAQ, também se lê que existe uma desconfiança em relação à m$, mas que no entanto a comunidade não tem de utilizar esta tecnologia com os mesmo propósitos que a m$ usa, uma das ideias é permitir à comunidade fazer coisas completamente diferentes com esta tecnologia do que a m$ faz ou indica que se deva fazer. De qualquer das formas continuo a achar que o .net é uma armadilha da m$.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Viva pessoal...
Eu sempre olhei par ao .NET com muita desconfiança, como se fosse totalmente copiado da plataforma JAVA, mas, isso não é totalmente verdade.
Depois de ter começado a fazer coisas e a ver o que a plataforma .NET pode fazer e a facilidade que tem em possuir na mesma solução diversas linguagens e uma total integração das diversas linguagens da mesma plataforma.
Muitos de vós iram achar que somente se integra com linguagens M$ ... e é verdade... e ai está se calhar o poruqê de tanto sucesso das linguagens de programação M$.
Em relação ao .NET, não creio que seja uma copia do JAVA, claro que é uma utilização dos mesmo conceitos, mas, se alguém relalmente teve tempo para olhar com atenção, nada tem haver da forma como o JAVA aborda as mesmas questões.
Não critequemos somente por criticar, e porque é bom criticar as as coisas que a M$ faz, mas, critiquemos quando a M$ faz realmente as coisas mal feitas.
Perfiro o Linux e a programação em Linux à preocupações com a segurança que a M$ só tem agora.
Penso que o projecto MONO tem pernas para andar, nem que seja para dar uma "xapada de luva branca" à Sun por não ter evoluido ao seu JAVA como a M$ tem feito com as suas plataformas.
Se houvesse alguma linguagem que fosse de tão fácil desenolvimento como o .NET para linux, haveria muito mais desenvolvimento para a plataforma.
(())
Esqueleto
|
| | | | | | Se houvesse alguma linguagem que fosse de tão fácil desenolvimento como o .NET para linux, haveria muito mais desenvolvimento para a plataforma.
Bullshit! Todo o desenvolvimento que agora se anda a fazer em .NET não é justificado com uma suposta facilidade ou suposta integração de linguagens ou qualquer outra suposta vantagem que o .NET tem em relação ao Java. A razão é simples, o VB 6 acabou e quem nele desenvolvia está agora a migrar para VB.NET e noutros casos é uma simples questão de seguir o caminho das buzzwords. Na realidade o .NET não tráz nada que o Java não pudesse já fazer (e o Java é hoje muito mais maduro, completo e portável).
Se houvesse alguma linguagem que fosse de tão fácil desenolvimento como o .NET para linux, haveria muito mais desenvolvimento para a plataforma.
Tretas. O Delphi era considerado de fácil desenvolvimento, a Borland lançou o Kylix que prometia trazer essa facilidade ao Linux e foi um enorme flop. A fácilidade só é justificada em business apps e nessa área quem toma as decisões são tipos que não sabem que existe mundo para além da Microsoft.
PS: eu gostava ainda de ouvir argumentos a favor do .NET que não revelassem uma completa ignorância do que o java fornece e não soassem a marketroid talk saída de uma conferência publicitária da Microsoft...
-- Carlos Rodrigues
|
| | | | | PS: eu gostava ainda de ouvir argumentos a favor do .NET que não revelassem uma completa ignorância do que o java fornece e não soassem a marketroid talk saída de uma conferência publicitária da Microsoft... Se leres bem com atenção o que escreves, dá para reparar que ninguém te vai tirar essa mania da cabeça... So why waste words ?
Mister ToniDosImpostos
"O software é como as mulheres, se não sabes, não MEXAS !"
(c) ME, 2004! |
| | | | | Enquanto te mantiveres nesse mesmo nível, eu continuo a ficar feliz :)
Mister ToniDosImpostos
"O software é como as mulheres, se não sabes, não MEXAS !"
(c) ME, 2004! |
| | | | Tens toda a razão quando dizes:
Na realidade o .NET não tráz nada que o Java não pudesse já fazer (e o Java é hoje muito mais maduro, completo e portável).
Mas temos que ter em conta que a Sun não faz evoluções ao java à algum tempo.
É lento a arrancar, dificil de desenvolver e com o IDE simplesmente intragavel.
nessa área quem toma as decisões são tipos que não sabem que existe mundo para além da Microsoft
Neste ponto até tens alguma razão, mas, com a publicidade que o Linux tem tido ultimamente, temos visto muitos destes tipos que tomam decisão e olhar por cima da cerca à espera de ver uma proposta clara de outros SO, que ainda não é possível devido à grande complexidade de desenvolvimento e ao muito tempo ainda usado para o mesmo em aplicações LINUX.
No Linux ainda à tudo para fazer. Não queiramos que mais ou menos 10 anos num regime aberto, onde as evoluções era à medida que alguém tinha tempo para as fazer, com 20 anos de desenvolvimento exaustivo por equipas vastas e bem pagas para o efeito.
Por esta razão a M$ em termos de desktop ainda é superior ao LINUX .... somente pelo tempo que tem... mas ... o LINUX está no bom caminho, só lhe falta uma boa ferramenta de desenvolvimento.
(())
Esqueleto
|
| | | | | Mas temos que ter em conta que a Sun não faz evoluções ao java à algum tempo. Dá uma vista de olhos pelo J2SDK 1.5 Beta 1 e depois talvez mudes de ideas... É lento a arrancar, dificil de desenvolver e com o IDE simplesmente intragavel. Eu uso o Eclipse para desenvolver em Java e não concordo com nenhuma dessas afirmações. Quando se fala em Java não se pode incluir o IDE (que suponho que seja o NetBeans) como parte dele. Sinceramente às vezes fico com a impressão que quem diz mal do Java é porque nunca o explorou recentemente...
|
| | | | Muito interessante o link para o SDK 1.5
Ao que parece o Java está a tentar recuperar terreno em duas frentes; na primeira, recuperar os próprios erros do passado, Generic Containers (Duh!) e Enums (Eureka!), ou seja estão decididos finalmente a copiar o que há de melhor no C++ e chegar à conclusão de que Strong Type Checking é algo de bom. Na segunda frente de recuperação, incluir inovações inpiradas pela vaga C#, o incluir de Metadata directamente no código soa suspeitamente aos Properties do .Net
Outros melhoramentos na linguagem como o 'for' para iteradores é algo de positivo, mas agora aquela de voltar aos variable arguments e pasme-se printf like system.out é de rir e dá a ideia de que apesar da evolução os velhos do restelo ainda imperam dentro da Sun.
IMHO, a especificação C# é melhor que a do Java e foi inspirada nesta e na de C++, mas é preciso não esquecer que o Java é livre e independente da plataforma... enfim, apesar de tudo o que interessa saber é que "They Are Sucking Less"... :-)
|
| | | | | Java é livre?
Nem pensár, Java no maximo é independente de plataforma. Porque o Java é proprietário.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Com as recentes notícias há a esperança disso mudar. Alguém sabe se houve mais desenvolvimentos no caso?
|
| | | | Sinceramente às vezes fico com a impressão que quem diz mal do Java é porque nunca o explorou recentemente...
Tenho que dar a mão à palmatória e dar razão à tua afirmação.
Especialmente com aparecimento da IBM no panorama, o JAVA e até mesmo o Linux tem tido um grande avança em muitas frentes.
Ao IDE que tanto "bato" nos meus posts é o que podemos fazer download no site da Sun, e se esse não é o oficial o que é????
Espero que estejamos todos de acordo que é um interface dificil de trabalhar que afasta qualquer alma de desenvolver com ele.
Vou fazer download do Eclipse e olhar para ele com olhos de ver. Se as coisas são como tenho aqui lido, fico realmente muito contente e com esperaça para o futuro do próprio JAVA, que até ontem via escuro e sem luz ao fundo do tunel.
Gostaria no entanto que pudessem olhar para o .NET com olhos de ver e não somente com olhos de criticar tudo. Está uma excelente plataforma de desenvolvimento, simples, madura e com diversas ferramentas de apoio ao programador.
A FrameWork .NET é excelente, e com praticamente tudo o que necessitamos.
Aliado a isto temos um excelente IDE que nos facilita o trabalho com diversos mecanismos de apoio ao desenvolvimento, como o já famoso Auto-Completentiom e gestão de comentários e consequente emissão de documentação.
Uma das razão porque não enverdei pelo java, foi precisamente pela sua complexidade no desenvolvimento e utilização do IDE.
(())
Esqueleto
|
| | | | | Ao IDE que tanto "bato" nos meus posts é o que podemos fazer download no site da Sun, e se esse não é o oficial o que é???? Não consigo perceber a defenição de IDE oficial. É um grande absurdo qualificar uma linguagem com base nos IDE's que tem disponiveis. Uma linguagem é uma linguagem os IDE's são os IDE's. Não é preciso um IDE para programar.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | alias: o contrário de oficial é clandestino, por isso não faz muito sentido!
João Jerónimo Jabber: j_j_b_o@jabber.org ICQ: 312332573 |
| | | | | Temos de distinguir duas coisas no .NET: - .NET Framework que é um conjunto de ferramentas, bibliotecas, etc, que pode ser adquirido gratuitamente
- Visual Studio .NET que é o IDE oficial da Microsoft e que se paga ;-)
Em Java temos o J2SDK (nas suas variantes SE, EE e ME) e existem vários IDEs (destaco estes três que foram os únicos que já usei): Com tudo isto quero realçar que devem ser feitas duas comparações, uma entre o .NET e o Java e outra entre o Visual Studio .NET e os vários IDEs para Java.
|
| | | | Gostaria no entanto que pudessem olhar para o .NET com olhos de ver e não somente com olhos de criticar tudo.
nós olhamos, vemos algo do qual não pudemos sair, não tem garantias, não tem o nível de desenvolvimento que a alternativa.
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | Mas temos que ter em conta que a Sun não faz evoluções ao java à algum tempo.
Não faz? As APIs disponíveis para Java estão em constante evolução. Agora se te estás a referir à linguagem, realmente estabilizou nos últimos anos, mas isto é uma Good Thing(tm). O Java 1.5 (que tráz algumas coisas novas) pode marcar um marco terrível, uma mudança de um Java simples para um C++ alike que é exactamente o contrário dos princípios subjacentes ao seu desenvolvimento.
Neste ponto até tens alguma razão, mas, com a publicidade que o Linux tem tido ultimamente, temos visto muitos destes tipos que tomam decisão e olhar por cima da cerca à espera de ver uma proposta clara de outros SO, que ainda não é possível devido à grande complexidade de desenvolvimento e ao muito tempo ainda usado para o mesmo em aplicações LINUX.
Aplicações em C/C++ são igualmente complexas de desenvolver em Windows ou em Linux. Quem diz o contrário é porque nunca programou a sério em Linux e não conhece o sistema, sofrendo assim do natural síndrome da coisa desconhecida.
O .NET não veio revolucionar a facilidade de desenvolvimento em Windows, pois já antes existia o Delphi (Kylix em Linux), o VB e o Java e isso nunca alterou o panorama de que a esmagadora maioria das aplicações para Windows são desenvolvidas em C++.
É lento a arrancar,
Um mito puro e simples. Tens usado Java ultimamente?
dificil de desenvolver
Simplesmente não consigo compreender esta afirmação...
e com o IDE simplesmente intragavel.
Quando falas de IDE estás a baralhar as coisas. Não existe um IDE oficial para Java, e se te estás a referir ao Netbeans (como já é dito noutro post) então é melhor começares a analisar os Eclipse ou outras alternativas, pois o Netbeans não e lento e pesadão por ser feito em Java, é lento e pesadão porque carrega tudo quanto é módulos logo ao arranque...
-- Carlos Rodrigues
|
| | | | | Não é que me sinta fascinado pelo java ou mesmo plo .net (por tecnologias proprietárias), mas dizer que uma linguagem é boa ou má, por haver um IDE que eventualmente não presta, é uma barbaridade do tamanho das Torres Petrona. Quanto a ser facil ou rapido desenvolver em GNU/Linux depende das ferramentas e tencologias e metodos que utilizas.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Boa, retorqui duas vezes o mesmo excerto... deve ser do avançado da hora... (mas faz sentido na mesma).
Penso que o projecto MONO tem pernas para andar, nem que seja para dar uma "xapada de luva branca" à Sun por não ter evoluido ao seu JAVA como a M$ tem feito com as suas plataformas.
O Java é uma linguagem madura e não estou a ver que evolução tamanha a Microsoft fez e que a Sun não fez e devesse ter feito...
Isto faz-me lembrar um comentário do slashdot:
Too much syntactic sugar causes cancer of the semicolon.
-- Carlos Rodrigues
|
| | | | Isto faz-me lembrar um comentário do slashdot:
Too much syntactic sugar causes cancer of the semicolon. Lol, esse comentário está engraçado. Mas depende muito as sensibilidade de cada um o que é o syntatic sugar, e o problema é se essa sintaxe é de facto útil ou não. Podes dar um exemplo?
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Posso dar vários exemplos, alguns de Java e outros não, em que considero o açúcar sintáctico útil ou não:
- Os templates (ou genérics): não considero isto particularmente útil em Java, pois a mim não me incomoda fazer casts quando retiro objectos dos containers. Por outro lado a possibilidade de ter um container com vários tipos de objectos é útil (bem sei que isto se mantém mas passamos a ter duas formas de fazer o mesmo).
- Autoboxing: isto tem alguma utilidade mas tráz para o Java ambiguidades, e uma poluição da noção de tipos primitivos e objectos.
- Operator-overloading: uma funcionalidade originada no inferno que devia ser erradicada da face do planeta e os seus promotores executados de forma muito dolorosa. Espero que ninguém tenha a triste ideia de acrescentar isto ao Java, pois só serve para confundir quem leva com o frete de manter o código ("hmmm, a + b, o que é isto soma ou um operador qualquer?). Eu gosto de código claro, mesmo que se tenha de gastar mais uns caracteres.
- Tratamento de XML embebido na linguagem: uma coisa completamente estúpida de se incluir numa linguagem de uso geral, quase tão estúpida quanto o SQL Embedded.
PS: bem, na realidade eu vejo um único caso onde o operator-overloading é útil, em pacotes de cálculo onde seja necessário fazer operações aritméticas complexas com tipos numéricos não primitivos (e, verdade seja dita, isto não é vulgar o suficiente para justificar ser incluído numa linguagem genérica -- as linguagens de domínio restrito têm alguma razão de ser sabem?)
-- Carlos Rodrigues
|
| | | | Dá para perceber que não deves ser grande fã de C++ :)
|
| | | | Por acaso bem pelo contrário. A maneira como eu encaro o C++ é bipolar. Por um lado acho o C++ a maior aberração na história das linguagens de programação (bem, também temos o PL/1...) e que demonstra bem os perigos do design por comité. Foram cedendo e adicionando tudo o que cada programador mais o seu cão conseguiam imaginar e achar remotamente útil. No final conseguiram uma linguagem monstra, cheia de ambiguidades e impossível de dominar totalmente por um ser humano.
Por outro lado acho o C++ uma excelente linguagem se escolhermos um subset dela para utilizar, resistindo à tentação do operator-overloading e uso de templates o mais possível. No fundo, usando aquele subset do C++ que se transformou no Java :).
O principal problema do C++ é que cada um usa o seu próprio subset e no final podemos acabar com uma salsada de diferentes dialectos difícil de manter, se não tivermos cuidado.
-- Carlos Rodrigues
|
| | | | Os templates servem para restringir, em compile time, o tipo de dados, não é só verificação em runtime. grande, mas grande diferença :)
autoboxing... concordaria contigo, mas pelo que sei houve muita gente a querer, por alguma razão há de ser. é que dá trabalho...
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | Bem ... não vejo porque dizes que o JAVA é uma linguagem madura ...pq está à muito tempo no mercado ???? Porque tem tido avanços claros no seu desenvolvimento???
Infelizmente o JAVA parou no tempo... a Sun o fez parar.
Em relação ao ao que a M$ fez para que o .NET fosse (para mim) melhor que o JAVA foi :
- Melhorou claramente o IDE de desenolvimento, pois, no JAVA é simplesmente intragavel.
- Criou uma Framework (até aqui o JAVA tem) onde podes desenvolver em diversas linguagens (VB .NET, C#, J# e C++)
- No desenvolvimento WEB é uma separação entre o que é Interface e o que é funcionalidade (não vi ainda em nenhuma ferramenta de desenvolvimento, logo, considero uma evolução)
- Uma limpeza de desenolvimento e linguagens simples.
Se não achas que isto são vantagens, tenho pena, mas tens direito à tua indignação e opinião... ela é tua.
(())
Esqueleto
|
| | | | | Não me queria tornar num paladino do Java... se o faço é pelos anos de favores que a linguagem já me proporcionou. Sinto-me com o dever de defender-lhe a honra.. :p Melhorou claramente o IDE de desenolvimento, pois, no JAVA é simplesmente intragavel. Mas é claro que é intragavel: O Java é uma linguagem, não é um IDE. Quando se comparam linguagens de programação pela qualidade gráfica que nos oferecem, na verdade, está-se a fazer uma grande confusão: alhos com bugalhos. O único critério de sweetness que se pode associar a uma linguagem depreende-se exclusivamente pela syntaxe que nos é oferecida. Ora, a maior flexibilidade que nos é dada pelo .NET tem como despesa uma maior complexidade, ambiguidade e redundancia na syntaxe. Para o programador isto não é problema. Na verdade é o IDE que torna o .NET viável. Para pessoas como eu que ainda gostam de fazer os projectos para a Univ com o uso exclusivo de um editor de texto vulgar e as ferramentas disponibilizadas pela linha de comandos: compilador, cvs, ant, etc, tornam-se evidentes todos os factores que tornam linguagem X melhor que linguagem Y. - Criou uma Framework (até aqui o JAVA tem) onde podes desenvolver em diversas linguagens (VB .NET, C#, J# e C++) Apenas util para o mouse engineer que quererá portar a sua APP do VS6.0 para a plataforma mais recente. Sinceramente parece-me uma grande redundancia, afinal de contas o que se faz com com J# tambem se faz com C# e eventualmente com VB Por outro lado se o programador tiver a necessidade de integrar ASP na solução terá que aprender mais uma linguagem diferente, e aí por adiante Com a combinação de Java+Servlets+JSP+JDBC consegues combinar na mesma linguagem, as funcionalidade oferecidas pelo .NET, mas com menos redundancia. - No desenvolvimento WEB é uma separação entre o que é Interface e o que é funcionalidade (não vi ainda em nenhuma ferramenta de desenvolvimento, logo, considero uma evolução) Não viste porque não procuraste. Considera isto: MVC (Model View Controler) O modelo é a Base de Dados, tem todo o teu negócio. Depois tens várias vistas: um JSP para os teus clientes e uma APP em Java Swing para um responsavel pela manutenção do sistema, por ultimo cada destas vistas tem associada um "controlador", que é responsavel pela actualização de dados na BD entre outras coisas. Por outras palavras, tens a separação entre a Interface e a funcionalidade. Aquilo que querias oferecer, como uma grande inovação na engenharia de software à Microsoft é já bem antigo e remonta, possivelmente, nas primeiras implementações (na teoria já deve vir de muito antes), ao Java. - Uma limpeza de desenolvimento e linguagens simples. Bem.. acho que aqui já estamos conversados
Is this desire? |
| | | | Sinceramente parece-me uma grande redundancia, afinal de contas o que se faz com com J# tambem se faz com C# e eventualmente com VB
Mas é que se consegue uma coisa. Consegue-se ter um projecto supostamente uniforme onde são usadas várias linguagens pela simples razão que um programador gosta mais de uma e outro gosta mais de outra (sim, porque elas são todas a mesma coisa exceptuando a sintaxe), o que dificulta a sua manutenção.
Por outras palavras, tens a separação entre a Interface e a funcionalidade. Aquilo que querias oferecer, como uma grande inovação na engenharia de software à Microsoft é já bem antigo e remonta, possivelmente, nas primeiras implementações (na teoria já deve vir de muito antes), ao Java.
Sim, o modelo MVC originou no Smalltalk, que precede o Java por qualquer coisa como uma década.
-- Carlos Rodrigues
|
| | | | Sim .. com toda a razão o IDE é diferente da liguagem e nunca foi isso que eu quiz dizer. O que quiz dizer foi que a facilidade de utilização do IDE faz com que o .NET seja uma linguagem viável.
Para pessoas como eu que ainda gostam de fazer os projectos para a Univ com o uso exclusivo de um editor de texto vulgar e as ferramentas disponibilizadas pela linha de comandos: compilador, cvs, ant, etc, tornam-se evidentes todos os factores que tornam linguagem X melhor que linguagem Y.
Sim, cada um escolhe como quer programar, e no .NET também temos a possibilidade de desenvolver com um qualquer editor de texto e depois compilar o programa à mão, mas, não tiras partido de todas as funcionalidades que o IDE te propociona, mas, isso é uma decisão tua.
Agora convenhamos que partindo de uma boa linguagem com um bom IDE temos um conjunto ideial de programação.
Com a combinação de Java+Servlets+JSP+JDBC consegues combinar na mesma linguagem, as funcionalidade oferecidas pelo .NET, mas com menos redundancia.
Que menos redundância falas aqui ???
MVC (Model View Controler)
Realmente se isso existe porque é que não está visivel ???
Não tenho muita experiência em programação em JAVA, mas, o pouco que tentei fazer tive muitas dificuldades em começar a desenvolver devido à complexidade do IDE.
Não me venham com essa conversa que o IDE != da linguagem, pois eu sei isso muito bem, mas, se ele for de simples utilização, leva a que os programadores se embrenhem mais e mais na linguagem e com mais facilidade.
Com isto não estou a dizer que o JAVA não é BOM, longe disso, mas, o facto de não ter havido evoluções claras no sentido de melhorar a vida dos programadores, tornar os programas mais fáceis de desenvolver (melhorar o IDE), melhorar alguns processos (como os locks) e melhorar a velocidade de carregamento dos programs desenvolvidos em JAVA, se calhar o JAVA seria um excelente concorrente para o .NET.
Infelizmente o JAVA está parado, o seu desenvolvimento tem sido inexistente, e com isso outras linguagens avançam usam o que o JAVA tem de bom e melhoram.
(())
Esqueleto
|
| | | | | «...faz com que o .NET seja uma linguagem viável.» .net não é uma linguagem. «...Não tenho muita experiência em programação em JAVA, mas, o pouco que tentei fazer tive muitas dificuldades em começar a desenvolver devido à complexidade do IDE. Então não usasses o IDE, ou procurasses outro IDE que achasses melhor, o que não deve faltar por aí são IDE's. Não me venham com essa conversa que o IDE != da linguagem, pois eu sei isso muito bem, mas, se ele for de simples utilização, leva a que os programadores se embrenhem mais e mais na linguagem e com mais facilidade. Isso talvês aconteça com alguns (provavelmente muitos), mas não com todos.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | MVC (Model View Controler) Realmente se isso existe porque é que não está visivel ??? Claro que está visivel, é apenas mais um padrão de desenho que podes usar, qualquer bom programador usa padrões de desenho sem ter que estar a depender do IDE para esse efeito Infelizmente o JAVA está parado, o seu desenvolvimento tem sido inexistente, e com isso outras linguagens avançam usam o que o JAVA tem de bom e melhoram. Isto só demonstra o teu desconhecimento e falta de informação sobre a linguagem. Procura aí em baixo na tree, creio que o PRE diz alguma coisa sobre o que vai sair já na versão 1.5
Is this desire? |
| | | | Não tenho muita experiência em programação em JAVA, mas, o pouco que tentei fazer tive muitas dificuldades em começar a desenvolver devido à complexidade do IDE.
Não me venham com essa conversa que o IDE != da linguagem, pois eu sei isso muito bem, mas, se ele for de simples utilização, leva a que os programadores se embrenhem mais e mais na linguagem e com mais facilidade.
Mas que insistência... O Java não tem um IDE oficial, logo quando criticas o IDE, criticas apenas isso, o IDE. Se não gostas daquele que usaste simplesmente ias à procura de outro... Isto é uma mentalidade típica do mundo Microsoft, onde, por exemplo, o Visual Studio é considerado o IDE oficial, mesmo havendo uma data deles, alguns superiores em diversos aspectos.
E depois também não compreendo esta dependência que certas pessoas têm do IDE. Eu, pelo menos, detesto ter um IDE a fazer-me a papinha toda e a armar-se em mais esperto que eu.
-- Carlos Rodrigues
|
| | | | MVC (Model View Controler) Realmente se isso existe porque é que não está visivel ??? Está, pois: "Design Patterns", de Eric Gamma, Richard helm, Ralph Johnson e John Vlissides, Addison-Wesley, 1995; ISBN: 0-201-63361-2 Só que é um conceito e, como tal, independente da linguagem de programação. Aliás, creio que aparece pela primeira vez associado ao Smalltalk, sendo igualmente aplicado (com bastante frequência) em C++ e Java.
|
| | | | O MVC não é um dos padrões explicados no "Design Patterns", apesar de ser mencionado várias vezes. Eu sei do que digo porque esse livro é uma das minha referências.
|
| | | | | Melhorou claramente o IDE de desenolvimento, pois, no JAVA é simplesmente intragavel. Linguagem de programação != IDE.
Uma linguagem de programação pode ter vários IDE's e nenhum deles é a linguagem ou faz parte da linguagem, logo não se pode utilizar a qualidade de um IDE para qualificar uma linguagem. Também podes utilizar diversas linguagens de programação para Java, um bom exemplo é o Jython.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | | «Perfiro o Linux e a programação em Linux à preocupações com a segurança que a M$ só tem agora. Não me digas que também acreditas no Pai Natal e no Coelhinho da Pascoa.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | A verdade é que à medida que fui aprendendo tive de me render.
Esta é a verdadeira influência do ensino superior. E é esta a razão porque a Microsoft paga viagens a Seattle a alguns professores. Começa-se a leccionar novidades nas cadeiras sem que essas novidades tenham tido tempo para amadurecer e ao mesmo tempo relegam-se para segundo plano tecnologias com provas dadas, de preferência dando a ideia que as novidades são o futuro e a melhor coisa desde o pão às fatias e as tecnologias com provas dadas são obsoletas e cheias de defeitos. Depois os alunos rendem-se, elogiando as novidades apenas pelo que deram numa cadeira e pelo que ouviram numa palestra de um senhor bem falante da Microsoft (tentando disfarçar o facto de na realidade não saberem bem o que as tecnologias com provas dadas conseguem fazer). No final das contas o pior é ainda acreditarem no Pai Natal e em supostas promessas de portabilidade que nunca irão acontecer, e esquecerem-se que mesmo ao lado essas promessas já foram cumpridas nas tecnologias com provas dadas...
Isto tudo faz lembrar os velhinhos todos a votarem no Paulinho das feiras que lhes prometia aumentar as reformas e ajudar a lavoura... e já sabemos onde isso vai parar...
-- Carlos Rodrigues
|
| | | | | | Não sei porque és tão radical. E sobretudo como consegues ser tão crítico relativamente a pessoas que têm outras opiniões que não a tua. Já deste o .NET a fundo? Se calhar quando deres também vais gostar! ;-) Não sei porquê, sinto que és daquelas pessoas do contra. Antes de aprenderes Java, dizias mal dele? Não sei porquê tenho esse pressentimento. Eu dei Java a fundo, eu dei .NET a fundo! Porque não aceitas a minha opinião, mesmo não concordando com ela? Eu aceito a tua, e compreendo-te perfeitamente. Como disse, eu já fui super contra o .NET.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Já foste contra o .NET sem conheçer as suas potencialidades?
Então com é que tens a lata de vir criticar a atitude das pessoas que são contra?
Eu gosto de desenvolver em python + pyGTK + pyGame + pyOpenGl + zope + <todos os outros modulos disponiveis que andam por aí> mas não sou contra nenhuma plataforma ou linguagem que não conheça.
Nem ando a divulgar que python é mil vezes melhor que .NET :)
Se o .NET (MONO) é bom os programadores vão acabar por o descobrir e utilizar. Eu, pela pouca experiencia que tive, não gosto .NET .
... Ou então não. |
| | | | Humz... palavras sábias, belo comentário. Dou-te toda a razão. :-)
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Não sei porque és tão radical. E sobretudo como consegues ser tão crítico relativamente a pessoas que têm outras opiniões que não a tua.
Não sou radical, defendo as minhas posições. E sou crítico pois (acho) que possuo uma coisa muito importante chamada "espírito crítico". Não gosto de emprenhar pelos ouvidos.
Já deste o .NET a fundo? Se calhar quando deres também vais gostar!
Nunca dei .NET a fundo, da mesma forma que nunca dei Java a fundo. A maioria das coisas que sei, e o Java cai neste saco, aprendi por minha vontade. E era exactamente isto que eu queria que ficasse bem claro. Um curso superior não serve para ensinar a última moda, serve para dar as bases e guiar a auto-aprendizagem do aluno, pois é isto que vai ter de fazer no mundo "real".
Eu já tive cadeiras em que certos aspectos do Java faziam parte da matéria, tal como noutras também se incluía o .NET.
Mas o mais importante é isto, o Java é portável e o .NET não. As referências ao Mono são irrelevantes pois nunca será uma alternativa ao .NET tal como o Kaffe, o GCJ, o Java da IBM ou outros nunca o foram...
-- Carlos Rodrigues
|
| | | | Ups, carreguei no submit depressa de mais...
Porque não aceitas a minha opinião, mesmo não concordando com ela? Eu aceito a tua, e compreendo-te perfeitamente.
Aceitar a opinião? Eu nunca aceito as opiniões dos outros a não ser que esses outros me convençam (é o tal espírito crítico de que eu falava) e acredita que consigo ser convencido. Sim, eu já disse mal do Java, e do Mozilla, e do GNOME e agora defendo-os -- mas nunca critiquei o Java pela portabilidade, mind you -- pois o que eu neles criticava foi corrigido (Java: lentidão, Mozilla: lentidão e bugs, GNOME: falta de integração).
-- Carlos Rodrigues
|
| | | | Nunca dei .NET a fundo, da mesma forma que nunca dei Java a fundo.
Bem nos estava a parecer que essa era a razão de tanta conversa e tão pouco insight. :-)
Ainda tens a lata de vir falar do suposto FUD universitário e afim. Começa a aprender sobre o que falas a sério antes de falares sobre o que não sabes que só fazes um favor ao mundo.
Há muita gente que gosta de .net e não quer saber do que tu queres saber por uma razão principal: São coisas que só são importantes para um fanático dogmático como tu. O mundo empresarial não quer saber de coisas serem mais ou menos portáveis se eles nunca vão querer portá-las, etc. Se eles podem correr coisas antigas sem trabalho, ainda melhor!
O mais engraçado é que a maior parte destas pessoas tem empresas e gere empresas. Ou seja, não anda a brincar aos javas e .nets antes de tomar decisões como tu fazes antes de andar a falar como se fosses um expert. Se o java fosse tão bom, era usado por questões de produtividade, o resto é conversa...
http://www.absolutbsd.org/ |
| | | | Não conheço nem java nem .net (e não pretendo vir a conhecer tão cedo) por isso nesta conversa sou imparcial, mas o fato dele nunca ter "dado" determinada matéria na universidade não quer dizer que não a conhece... digo eu
O rapaz tinha acabado de falar em ser auto-didacta...
Organizem-se pá :)
|
| | | | Não conheço nem java nem .net (e não pretendo vir a conhecer tão cedo) por isso nesta conversa sou imparcial, mas o fato dele nunca ter "dado" determinada matéria na universidade não quer dizer que não a conhece... digo eu
Não me parece que isso estivesse em discussão. Ele é que tem medo dos papões dos professores da universidade que só dão .net....
Achar que as pessoas lá por não darem java nas faculdades (o que por acaso até dão) e só darem .net é a causa do .net ser bem sucedido é passar um atestado de estupidez a todos os portugueses.
http://www.absolutbsd.org/ |
| | | | Bem nos estava a parecer que essa era a razão de tanta conversa e tão pouco insight. :-)
Meu amigo, já passaste por um curso de Engenharia Informática a sério? Se sim e não te deste conta que o objectivo é dar as bases, preparar a mente para aprender sozinha, guiar, então sugiro-te que voltes para lá e aprendas mais alguma coisa. Dar a moda do dia (seja Java, .NET ou o que for) a fundo como se fosse o Santo Graal só ajuda a formar pessoas que depois não se irão conseguir libertar da sua formação base e evoluir.
Ora dá uma volta pelas universidades, mais particularmente pelos cursos de Engenharia e depois diz-me se aqueles que parecem dominar a matéria das cadeiras são os que sabem mais... Eu respondo-te já, não são, são aqueles que demonstram curiosidade e capacidade de aprender por si e alargar os horizontes. E não, não estou aqui a vangloriar-me, estou a dizer que conheço pessoas de ambos os grupos.
O mundo empresarial não quer saber de coisas serem mais ou menos portáveis se eles nunca vão querer portá-las, etc. Se eles podem correr coisas antigas sem trabalho, ainda melhor!
É isto que diferencia um mouse-engineer e um curioso de um Engenheiro (não no canudo mas nas atitude). Um mouse-engineer atira umas coisas para cima das outras e fica contente quando funciona (por exemplo, aquelas aplicações de vómito em VB), um Engenheiro tenta resolver os problemas usando aquilo que sabe, manténdo a prespectiva económica e equilibrando-a com boas soluções técnicas, tanto para hoje como para o futuro, não esquecendo nunca o espírito crítico sobre tudo aquilo que faz, caso contrário são meros operários.
-- Carlos Rodrigues
|
| | | | [bocas de primária irrelevantes...]Dar a moda do dia (seja Java, .NET ou o que for) a fundo como se fosse o Santo Graal só ajuda a formar pessoas que depois não se irão conseguir libertar da sua formação base e evoluir.
Então o que é que devem dar? Devem dar teoria e só teoria? Dão java, c++, .net ou o que for preciso para demonstrar paradigmas de programação, etc. Ou queres que só dêem a teoria? Ao menos dá-se algo e as pessoas ficam a saber de algo a sério para não andarem a opinar sobre o que não sabem. A teoria é bonita mas quando é preciso fazer é preciso "aprender" a prática.
O que é que eu disse tem a ver com o facto de as pessoas depois nao conseguirem mudar do que aprenderam inicialmente? Alguém estava a discutir isso? Santa paciencia... se as pessoas não mudam porque não têm capacidade, a faculdade não tem culpa que elas sejam limitadas. Há pessoas que nunca querem mudar e ninguém tem culpa disso a não ser elas mesmo. Não respondes alhos com bugalhos, mas eu compreendo que isso te dê jeito...
Ora dá uma volta pelas universidades, mais particularmente pelos cursos de Engenharia e depois diz-me se aqueles que parecem dominar a matéria das cadeiras são os que sabem mais... Eu respondo-te já, não são, são aqueles que demonstram curiosidade e capacidade de aprender por si e alargar os horizontes. E não, não estou aqui a vangloriar-me, estou a dizer que conheço pessoas de ambos os grupos.
Se tivesses alguma memória em relação ao que já tenho dito, saberias que eu não acho que as pessoas com melhor score académico são as q sabem mais ou que se safam melhor depois da faculdade. O que não faltam é estudos a esse respeito...
Depois, o que que isso tem a ver com o facto de tu estares a opinar sobre tecnologias e não saberes coisas delas a fundo?
Aos mouse engineers nem te respondo pois de fundamentalistas que nunca fazem nada está o mundo cheio... Lá porque no teu mundo pequenino e limitado achas que um bom profissional não pode usar coisas que tu aches mal, é um problema teu.
Um engenheiro faz o que é preciso para resolver um problema em determinado tempo em face dos recursos disponíveis (e ao que sabe é claro). Esta é a definição mais corrente e não a tua visão romanceada de que tem todo o tempo do mundo para usar o mais correcto e andar a pensar de como será daqui a 10 anos, etc... Se for possível, ainda bem, se não for, tem que se fazer da melhor forma possível.
Relativamente aos operários, os operários japoneses são todos licenciados, e quase todos em engenharia. É apenas mais uma achega à tua visão classicista do mundo elitista que preconizas para os engenheiros...
http://www.absolutbsd.org/ |
| | | | lol.
sim, um engenheiro tem de ter vista curta e planear só para o próximo ano, porque a gente sabe que coisas como o y2k e programas em ada e cobol não existem. sinceramente, deixa de tentar ler as coisas segundo aquilo que queres ler e lê a opinião dos outros com espirito crítico.
O que está em questão não são apenas os méritos técnicos de uma ou outra solução, tens que incluir a dependebilidade de ambas, porra.
quanto a saber das tecnologias a fundo, é um disparate pegado. só sabe a fundo quem é obrigado a trabalhar com elas todos os dias durante meses para projectos reais. tudo o resto é ilusão.
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | quanto a saber das tecnologias a fundo, é um disparate pegado. só sabe a fundo quem é obrigado a trabalhar com elas todos os dias durante meses para projectos reais. tudo o resto é ilusão.
Tens que avançar para um grande projecto e tens que decidir entre .net e java. Tens duas hipóteses:
1) Falar com alguém que foi "obrigado a trabalhar com elas todos os dias durante meses para projectos reais"
2) Falar com uma pessoa que sabe apenas a teoria e apenas o que tem lido sobre cada linguagem
A escolha não é difícil. Já agora, o que são projectos irreais? :-)
http://www.absolutbsd.org/ |
| | | | epah, "falar"? vais contar os teus planos aos amigos ou pagar a uma empresa de consultadoria? é que a consultadoria é cara, e sempre tendenciosa.
projectos reais, epah, são coisas com dimensão e que não podem sofrer deslizes, mesmo. não são o caso de casos de faculdade ou fazer o sitezinho da PME normal... e isto deixa com que não haja possibilidade de explorar completamente as soluções em duas plataformas desta dimensão. IMHO, claro...
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | | «...Se o java fosse tão bom, era usado por questões de produtividade, o resto é conversa...» Isso é treta, as razões de sucesso de uma tecnologia nem sempre são a sua qualide e Historia está cheia de provas disso.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Isso é treta, as razões de sucesso de uma tecnologia nem sempre são a sua qualide e Historia está cheia de provas disso.
É verdade. Como se sabe é preciso mais e só a Sun é que ainda não percebeu. Isso é que é triste ao final destes anos todos... mas terão o destino que merecem :-)
http://www.absolutbsd.org/ |
| | | | > Se o java fosse tão bom, era usado por questões de produtividade, o resto é conversa...
Heheheheh. Tá boa esta.
humm ... será que não era uma piada ?
|
| | | | Se o java fosse tão bom, era usado por questões de produtividade, o resto é conversa...
Qual é o teu "insight" impresarial para tirares tão flagrante conclusão (que pelo o que percebi, o Java não é bom nem produtivo para empresas)?
Plexar. |
| | | | Se o java fosse tão bom, era usado por questões de produtividade, o resto é conversa... É exactamente o que me fez tomar a decisão de passar a trabalhar em Java: a produtividade!!! Devo esclarecer que a alternativa então colocada (estamos a falar de 2000), para produzir uma aplicação de gestão, era o C (ou C++). Depois de avaliar o tempo de desenvolvimento, cheguei à conclusão que a mesma aplicação demoraria 3 (três) vezes mais tempo se feita em C/C++ (e só para uma plataforma) do que se fosse realizada em Java (para n plataformas). Posso acrescentar (agora, passados 3 anos) que tenho a certeza de ter tomado a decisão correcta. Quanto ao ser lento, foi uma coisa que me preocupou na altura... Felizmente, aí estava enganado, pois o Java, hoje em dia, é quase tão rápido como as linguagens não interpretadas. Só falta mesmo a Sun modificar a licença para passar a poder ser considerado software livre (e as coisas até parece estarem bem encaminhadas). De qualquer maneira a Sun inspira-me muito menos desconfiança que a MS (basta comparar o histórico de ambas as empresas). Também achei, na altura (e mantenho), que produzir um ERP a pensar em corrê-lo num único S.O. (qualquer um) seria suícida para uma pequena empresa. Quanto aos IDE's, nada vos impede de usarem o 'vi' (ou o 'emacs') para produzir o código, e o Ant para o compilar ;-). São ambos bem mais leves que o Netbeans, ou o Eclipse, ou wahtever... No entanto o 'code completion' e 'sintax highlightning' também contribuem decisivamente para o aumento de produtividade (pelo menos em aplicações com centenas de classes e centenas de milhar de linhas de código.
|
| | | | Repara, eu não sou anti-Java, tanto que o uso. E muito menos penso que não é largamente usado (leia-se, rentável) a nível mundial... basta pegar nas job offers e ver o que se pede que as pessoas saibam. O que acho lamentável é as pessoas serem anti .net só por ter origem (mais ou menos original não está em discussão) na m$ quando é a melhor alternativa para muita gente.
http://www.absolutbsd.org/ |
| | | | O que acho lamentável é as pessoas serem anti .net só por ter origem (...) na m$ quando é a melhor alternativa para muita gente. Se achas que é a melhor alternativa, continua a usá-lo, mas não digas que não foste avisado ;-)
|
| | | | a ms não é a melhor alternativa para ninguém... enfim, opinião e isso tudo, mas é meter-se num barco que daqui a 5, ou mesmo 1 ano, não sabes se pode estar afundado.
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | | O problema é que o .net é uma armadilha em que muita gente de boas intenções está a cair. Não se esqueçam da Historia caso contrário estam destinados a repeti-la e com a m$ já se repetiu muitas vezes.
Não que o Java em quanto tecnologia proprietária não tenha também os seus problemas...
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | isto talvez seja uma perda de tempo mas...
"why mono?"... e pk não "why not mono?"
|
| | | | | Bem, acho que vou tentar expor algumas das coisas que me fazem preferir o .NET. Espero que respostas a este post não sejam flames, e que sejam bem fundamentadas, como eu vou tentar fazer! :-) 1. Checked Exceptions
As checked exceptions são aquelas excepções que somos obrigados a apanhar, e elas não existem no C#. Porquê? Problemática de versões e manuntenção do código. Neste artigo do designer principal do C#, ele explica a fundo o porquê do C# não ter checked exceptions. Lendo com atenção só lhe podemos dar razão. O Bruce Eckel com o seu artigo Does Java need Checked Exceptions?, também dá a sua opinião sobre este tema. Contudo, embora estes dois artigos possam convencer muita gente, nas respostas ao artigo do Bruce Eckel logo vemos outros excelentes exemplos em como as checked exceptions são claramente necessárias em ambientes com vários programadores. Eu acho que as checked exceptions são necessárias, mas acho que o modelo do Java não é o melhor, pois conduz à má programação. Quem nunca engoliu uma excepção só porque não dava jeito apanhá-la? Mais sobre isto Ask a Language Designer: Why doesn't C# have exception specifications? 2. Delegates vs Pattern Observer no Java
Os delegates são simplesmente pointers para métodos. Quando dei Java, eu achei brilhante o modelo de tratamento de eventos. Cria-se uma classe anónima, adiciona-se ao evento e puff, já está. Com o tempo, realmente comecei a ficar farto de ter no construtor tanto código devido a tratamento de eventos. Ainda para mais temos de tar a criar interfaces e/ou classes(Adaptadores...) para os nossos eventos, uma interface por evento? Agrupamos todos os eventos na mesma? E depois temos de tar com os adaptadores? Acho que é um pouco de mais do que é preciso. O problema é que a classe cliente tem de conhecer o evento, tem de implementar a interface (Inner classes ajudam). Em C# basta registar um delegate(pointer) para um método... mais nada. Além disso os delegates são criados em compile time, se forem relativos a um método virtual, apontam logo para o método específico, por isso esse nível de indirecção vem de graça. E para iterar sobre eles não é preciso os casts normais que é preciso para os eventos no Java. Por isso os delegates são mais eficientes, até podem ser mais eficientes do que chamar um método virtual. 3. Virtual e Override
Em Java todos os métodos são virtuais. Será que sendo tudo virtual, os programadores de Java se lembram que os métodos virtuais são mais caros, e marcam como final aqueles que não precisam de ser virtuais? Não... É raro ver isso, e mesmo que os haja, tem de partir do programador, não é algo explícito na linguagem. Por isso em C# todos os métodos por defeito são não virtuais. Se queremos polimorfismo então declaramos explicitamente. Este problema do plimorfismo por defeito em Java ainda traz mais problemas quando se trata de versões, como este exemplo pode clarificar e bem. 4. Genéricos em C# e em Java
Um dos problemas, quer do Java, quer do .NET, é o boxing e unboxing. Boxing é um termo que vi pela primeira vez no .NET que se refere à passagem de um tipo valor para um tipo referência, por exemplo em Java não podemos ter tipos valores nos contentores como o ArrayList, temos de criar um Integer (tipo referência), para alojar o tipo valor(int). O unboxing é a operação inversa. De facto o .NET faz isto automaticamente por nós, visto que em .NET podemos nós fazer os tipos valor que quisermos (em certas ocasiões são muito eficientes). Esta introdução foi mais porque, tanto em JAva, como em .NET, os genéricos dão mais jeito é para tipos valor, é onde se consegue melhor optimização. Em .NET, os genéricos são resolvidos em Runtime, se o JIT vê uma classe template, instancia um tipo correspondente. Ou seja podemos ter um ArrayList, e temos a certeza de que não há boxes e que defacto temos um contentor de ints, ponto. Os genéricos em .NET vão aparecer na próxima versão, e acho que vão trazer um autêntico boost de performance à paltaforma. Isto porque há Hashtables e coisas do género que precisam mesmo de tipos valor, e que perdem muito em eficiência por haver o boxing. Bem, em .NET, os genéricos até são bacanos. E em Java? Em Java os genéricos infelizmente serão só syntax sugar. O que temos com ArrayList a;é só a facilidade sintática de trabalhar com inteiros. Se iterarmos pela lista, podemos fazer int x = a.get(0); temos um inteiro, mas o problema é que lá por baixo há todos os casts necessários, há todo o processo de boxing/unboxing necessários... O problema é que eles quiserem acrescentar genéricos sem alterar a VM, e assim há limitações visíveis. Podem ver uma comparação mais exaustiva sobre os genéricos em C#, Java e até C++ aqui. 5. foreach, propriedades, atributos e XML
Digam o que quiserem, o foreach é algo excelente. Aumenta a produtividade e bem, só não vê isso que nunca usou o foreach -- pelo que ouvi dizer o foreach vai ser implementado no Java. As propriedades são outra coisa muito boa. Eu estava muito habituado aos get's do Java, e custou-me a entrar neste conceito de propriedades, mas agora acho-as muito necessárias, tanto a nível de uso, como a nível de gestão das nossas classes. E por último os atributos: os atributos permitem-nos expandir a metadata das nossas classes/métods/whatever, permitindo-nos fazer tudo o que quisermos. Um bom exemplo é o XmlSerializer do .NET, basta ter uma classe, dizer que ela é serializável (com o atributos Serializable), e passá-la ao XmlSerializer e puff: fez-se a serialização - nada a ver com o processo de serialização do Java. Isto é só um exemplo do uso de atributos. E digo: nem se compara o tratamento de XML em .NET com o de Java, eu tive de fazer uns quantos leitores de XML com o SAX e pah... simplesmente não tem comparação. 6. Invocação Nativa
Quem usou o JNI sabe o pesadelo que aquilo é. Nem se compara com a facilidade de interoperabilidade do .NET com DLLs e até com COM. Supostamente o Java não precisaria de JNI, que põe em causa a portabilidade do código. Mesmo assim às vezes é necessário por motivos de performance, ou outros. 7. Assembly
Aqui é mais o assembly vs package. Acho que ter uma unidade mínima de armazenamento de código é bom, e está muito melhor conseguido em .NET com os assemblies e com os módulos. Sem bem que isto seja relativo, e aqui não tenho muitos argumentos, além de dizer que é o que eu prefiro. Em Java, andar com os .class, ou até com os .jar atrás chatiava-me. Prefiro tudo organizado em Assemblies, que posso muito simplesmente incluir noutros projectos. 8. Múltiplas Linguagens
Podemos ter um Assemlby com módulos em várias linguagens. De notar a facilidade te ter por exemplo, o módulo de UI em C#, e ter um módulo lógico em Haskell.NET ou Sheme.NET, e ter ainda outro módulo em Managed C++ em que interagimos com o Sistema operativo muito melhor. E isto tudo é compilado para IL (os byte codes do .NET) e fica tudo num assembly pronto a usar, sem termos ideia de como foi implementado. -- E pronto, não me lembro de mais nada por agora. :-) Está aqui um artigo com 10 razões para usar o C#, tem algumas coisas que eu disse, mas tem outras também, com exemplos e tudo.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | | Bem...sem querer criticar os teus argumentos que foram bem fundamentados e concordo contigo que são coisas úteis. Mas... as pessoas continuam a confundir plataforma .NET com o C#.
O C# é uma óptima linguagem, eu programo em Java à anos, gosto do Java, mas considero que o C# é uma linguagem mais "evoluída" que o java ( mas, nem tudo no C# é bom ). O java dormiu no ponto e há que mudar isso.
Mas o importante da questão, o .NET não é o C#, o .NET é uma plataforma que permite correr IL que pode ser criado em C#, ou VB.NET, ou outra ( já agora quero ver quantas linguagens .Net vão vingar ). Enquanto confudirem .NET com C# vai haver estas discussões que não levam a lado nenhum.
O .NET neste momento tem falhas muito graves, vou só destacar 2 que considero importantes de serem resolvidas:
* Não é multiplataforma e provavelmente nunca será porque a M$ é uma empresa egoísta e isso a médio e longo prazo será mau para o .NET.
* Tem graves problemas de perfomance, principalmente na ocupação de largura de banda. A mesma aplicação feita em J2EE e em .NET. A .NET ( se for usado as facilidades do ASP.NET ) irá ocupar mais largura de banda devido aos excessivos pedidos ao servidor e à info extra que passa ( numa Intranet com redes a 100Mb não é grave, mas numa Extranet é muito crítico ).
Vou dar exemplos reais, de aplicações reais e não programitas de universidade.
A empresa onde trabalho possui equipas especializadas em Java e .Net, ambas são necessárias para a empresa.
Neste momento as aplicações em plataformas com Java aguentam grandes sistemas, com milhares de utilizadores sem criar problemas.
As aplicações em .NET, quebram muito e tornam-se muito pesadas e digo-te que ainda são sistemas bem menores que os feitos em Java.
Pá....podes argumentar que as equipas .Net não percebem nada do que estão a fazer, pode até ser. Mas as mesmas tiveram vários cursos de formação, e alguns deles ( os mais importantes) da M$; as equipas de java por seu lado tem apenas a formação Universitária.
E caso o .NET vingue mesmo, a net será como os computadores actuais, são cada vez mais rápidos, com mais memória mas nunca são suficientes para correr sistemas M$, isso é um facto.
|
| | | | | Sim, tens razão, quase tudo do que disse é relativamente ao .NET em geral, e ao C# em particular. No .NET as linguagens são apenas sabores e há poucas diferenças sem ser a sintaxe. Quanto ao teu exemplo, eu não tenho experiência nesse campo, e nunca iria duvidar ou por em causa. Afinal de contas o Java anda por cá há muito mais tempo, e eu nunca disse para deitar fora o Java. Aliás, acho que cada tecnologia tem o seu lugar. O meu ponto de vista foi com base na minha experiência, é natural que não tenha sensibilidade para comparar o .NET e o Java em todos os campos. Seja como for, obrigado pelo exemplo, e pela resposta esclarecedora. :-)
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | A .NET ( se for usado as facilidades do ASP.NET ) irá ocupar mais largura de banda devido aos excessivos pedidos ao servidor e à info extra que passa ( numa Intranet com redes a 100Mb não é grave, mas numa Extranet é muito crítico ).
O número de pedidos é controlado pelo programador, sendo ele que decide como quer que os pedidos sejam feitos (geek work: postback). Relativamente à informação extra (a famosa viewstate) é uma coisa que realmente é muito útil, e se por um lado não tendo cuidado ela pode crescer exponencialmente, com o minimo de inteligência é fácil controlar o seu tamanho no estritamente essencial e funcional.
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | Neste momento as aplicações em plataformas com Java aguentam grandes sistemas, com milhares de utilizadores sem criar problemas.
muahahahahahahhaha... milhares de utilizadores... MUAHAHAHHAHHAHAHA!
ai que não posso... AHAHAHAHHA!
leste isso onde? :)
|
| | | | Bem...se não sabes, tudo o que for acima de 1000 é milhares. E diz-me quantos utilizadores pensas que tem as Intranets de grandes empresas ? Os sistemas homebanking quantos utilizadores pensas que tem ? Hoje em dia quem não acede à sua conta bancária via internet ? E quantos clientes terá uma instituição bancária ?
Depois...um sistema pode ter milhares de utilizadores mas não significa que milhares deles acedem simultaneamente. Nunca quis dizer isso, mas um sistema com milhares de utilizadores tem picos de carga e são nesses picos que se avaliam os grandes sistemas.
Depois eu não li...eu vejo diariamente.
Mas qual a tua dúvida ? Qual o teu problema ?
|
| | | | | Bem, tinha lido algures que não se pretendia uma .NET/C# vs qq coisa, mas já que se abre o jogo, aproveito para esclarecer alguns pontos. checked/unchecked exceptions: em java **existem** unchecked exceptions-- aquelas que derivam da RuntimeException. Por outro lados os Error tb não são checked. Simplesmente a prática em java é usar checked exceptions, mas se quiseres o modelo de ter excepções opcionais, go ahead, make your day. delegates: delegates (a.k.a as method pointers) e outras coisas (enum, gotos, lista de parâmetros) foram algumas das coisas que a MS introduziu para não fazer um sistema exactamente igual a java. A SUN resistiu à maior parte (cedeu em algumas) das features que se consideravam quebrar a "pureza" quer da linguagem que do conceito OO, como estes que mencionei... agora com a entrada do .net/c#, o sun resolveu repensar esta estratégia e adicionou uma série deles. method pointers poderá ser uma adição do j2se 1.6... já agora na tua descrição penso que querias dizer "se forem relativos a um método NÃO virtual" virtual e override: aqui java ganha. Em java o modelo é simples e deixa o trabalho para o compilador/JIT. A VM sabe quando chegou ao método final a executar, quando isso pode ser determinado, e fixa esse método. Por isso usar "final" nem sequer é recomendado para métodos. Já fiz testes de performance com duas classes iguais, so que numa os métodos estavam marcados com final e na outra não, e a performance foi a mesma. generics e box/unbox: para já estás a falar de vaporware, dado que .NET NÃO SUPORTA genéricos "as we speak". Java (1.5, que já anda aí) suporta. E tb suporta box/unbox que .net já suportava. No caso de box/unbox trata-se de syntax sugar puro, em ambos os casos. No caso de generics, de facto em java são syntax sugar. Não sei como serão em .net, mas ponho desde já sérias reservas que funcionem ao estilo dos templates C++, o que obrigava a ter várias versões de código executável para as mesmas fontes. O problema disto numa linguagem OO é que quebra os contratos. Estas optimizações devem ser todas feitas ao nível do compilador/JIT. Esse é tb um dos erros em haver "struct"s no .NET -- se uma classe é ou não struct-like devia ser feito pelo compilador. Já agora, em java actualmetne NÃO é feita essa optimização, mas desconfio que vá acontecer em 1.6, tendo em conta as modificações feitas na gestão de memória da actual 1.5. foreach/propriedades/xml: foreach já existe em 1.5. Tanto foreach como propriedades são syntax sugar puro. O tratamento de XML em j2se1.5 melhorou com suporte xml no jdbc. De qq mdo o que havia já era parcilamente equivalmente ao que se usa em .net, acontece que a maior parte das pessoas usava SAX, em vez de dom + queries xpath, prática esta que é comummente verificada em .net o JNI não é muito agradável, mas não é nenhum pesadelo. Já fiz algumas coisas em jni e não me parece nada do outro mundo. Escrever código nativo e usá-lo em .net nunca fiz, portanto não sei comparar, mas posso-te dizer que uma InputStream nativa tem cerca de 200 linhas de código em C, quase "limpas" de interface java. assemblies: nada a dizer aqui. Sao essencialmente equivalentes, embora o modelo de java seja mais natural: classes - arquivam-se em jar -- podes ter outras coisas lá com metadados. Simples e extensivel como se tem visto até à data. Mais: com esta técnica, agora com o j2se1.5 os jars ainda são mais comprimidos. Em .NET vai ser complicado ter .dlls comprimidos, a não ser que cada uma tenho código embebedido para para o deflate (!). múltiplates linguagens: idem para java. O que está presente nas classes bytecode, portanto qq coisa que gere bytecode serve.
|
| | | | | checked/unchecked exceptions: em java **existem** unchecked exceptions-- aquelas que derivam da RuntimeException. Por outro lados os Error tb não são checked. Simplesmente a prática em java é usar checked exceptions, mas se quiseres o modelo de ter excepções opcionais, go ahead, make your day. Eu disse que não existiam? Lê melhor o que eu disse. Eu disse que em Java existem, e em C# não. delegates: delegates (a.k.a as method pointers) e outras coisas (enum, gotos, lista de parâmetros) foram algumas das coisas que a MS introduziu para não fazer um sistema exactamente igual a java. Concordaria contigo a 100%, não fosse o facto das coisas introduzidas serem uma mais valia. :-) generics e box/unbox: para já estás a falar de vaporware, dado que .NET NÃO SUPORTA genéricos "as we speak". Java (1.5, que já anda aí) suporta. Pois não. Vai suportar na próxima versão, lá para o fim do ano. Mas vê bem a idade do Java e a idade do .NET, e a implementação de genéricos em cada uma das tecnologias... Não sei como serão em .net, mas ponho desde já sérias reservas que funcionem ao estilo dos templates C++, o que obrigava a ter várias versões de código executável para as mesmas fontes. Por favor, lê atentamente o que eu disse. Eu expliquei como vão ser os genéricos no .NET e passei um link. Esse é tb um dos erros em haver "struct"s no .NET -- se uma classe é ou não struct-like devia ser feito pelo compilador. Uma struct em C# não tem nada a ver com uma classe. Uma struct é um tipo valor, uma classe é um tipo referência. Como é que o compilador poderia saber qual deles usar? oreach/propriedades/xml: foreach já existe em 1.5. Tanto foreach como propriedades são syntax sugar puro. Pois são! Mas se aumentam a produtividade são bemv vindas. :-) múltiplates linguagens: idem para java. O que está presente nas classes bytecode, portanto qq coisa que gere bytecode serve. Sim tens razão, mas acho que esse mecanismo está melhor no .NET. -- Obrigado pela resposta, mesmo achando que não leste com atenção tudo o que disse, conseguiste mostrar-me algumas coisas que desconhecia -- sendo a mais importante a questão do final em Java.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Eu disse que não existiam? Lê melhor o que eu disse. Eu disse que em Java existem, e em C# não. Deve-te ter escapado alguma coisa algures. Disseste que em C# as excepções são unchecked e em java checked. Mas não é assim: em java existem CHECKED e UNCHECKED exceptions. Existem ambas as duas, como dizia o outro. Uma struct em C# não tem nada a ver com uma classe. Parece que ainda tens que aprender um pouco melhor C# -- na prática uma struct é exactamente a mesma merda que uma classe, mas com uma diferença: as classes são alocadas na memória (heap) e as struct no stack. Tão simples quanto isto. Porque é que as structs têm que ser boxed ou passadas por valor? Porque caso contrário, se fosse passada a ref para um método, este podia guardar essa ref num atributo, retornar, a função original retornar tb e zás, stack violation quando se acedesse ao atributo. O que é o compilador pode fazer aqui? A partir da vida que um objecto pode ter, decidir se pode estar no stack (struct) ou tem que estar em mem (classe). Como calculas, esta tarefa é extremamente complexa. Em C#/.net a solução foi deixá-la para o programador. Em java ainda não foi resolvida, fica tudo em mem. A automatização deste trabalho provocará uma grande melhoria de performance e dimuição drástica de uso de memória.
|
| | | | | Eu sei que em Java há ambas, eu não disse que não havia. Só falei na problemática das checkes exceptions. Eu sei muito bem as diferenças entre uma struct e uma classe. Bem, então tu dizes que um tipo valor é exactamente igual a um tipo referência? Não estás a ver a grande diferença de um tipo alojado no heap (mais rápido, sem tabela de métodos virtuais, sem o GC ao barulho), com um tipo referência que tem tudo isso e mais alguma coisa? As structs existem para criarmos os nossos tipos valores, porque podem ser de um grande boost de performance se bem utilizados, devido às suas diferenças. Contudo, há alturas em que precisamos de ver um tipo valor como um objecto, e por essa razão é necessário o boxing.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Quando falas no foreach, estás-te a referir ao foreach do XML ou mesmo á programação em si (C# ou VB.Net), eu utilizo o .Net para uma cadeira na Universidade e só posso concordar contigo o for each foi muito bem pensado, facilita em muito o desenvolvimento.
------------------------------------------------------------
Todas as coisas mudam, e nós mudamos com elas. |
| | | | Era ao foreach do C#. :-)
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Ui, um pop-quiz! :D 1. Nunca engulo a exception, é mais profissional fazer algo semelhante a: (bear with me please)
void myJavaMethod(int aX) throws BMFException
{
try
{
//blablabla que faz o throw de um BMFException
}
finally
{
//código de limpeza aqui
}
}
Como podes verificar, não precisas de fazer o catch para nada ;)
2. De facto gosto bastante dos (void*) wopps Delegates :) Ponto para o .Net
3. Mais uma vez, o final está lá bem presente e é usado criteriosamente :) Caso não saibas, o final não serve apenas para virtuals: muito melhor que isso tudo, serve para disponibilizar métodos in-place. Se não sabes do que falo, go check your C tutorial ;)
4. Honestamente, aqui entre nós dois que ninguém nos ouve, boxing/unboxing é daquelas coisas que não aquecem nem arrefecem. Vais criar um ArrayList para int's? Que tal um simples e velho int[]?
5. foreach em java:
for(Iterator it=arrayList.Iterator();it.hasNext();)
//do your thing
Só não faz é o cast "automágicamente", mas que se lixe... a gente (as in royal we) gosta de ter algum controlo sobre aquilo que os outros metem num ArrayList e queremos mandar cá para fora um ClassCastException quando alguém faz caca
As propriedades são definitivamente bastante úteis em .Net, principalmente pela clareza de código que permitem ter, ao invés de andar a criar uma carrada de get's e apenas alguns set's.
Apesar de concordar também com os atributos, deixa-me só clarificar que existem duas maneiras automatizadas de fazer parsing de XML, ou usas o DOM ou usas o SAX... Não há DOM, SAX e MS-Way. Fazer parsing de XML em Java usando o DOM ou o SAX não é diferente de fazer parse de XML em .Net em DOM ou SAX.
Sobre a serialização em Java, depende do que queres fazer... se é para usar em RMI, nem tens de te preocupar com isso (IIRC), mas RMI é apenas para Java. Mas ainda assim, concordo que a MS-Way-of-doing-things é um bocado mais avançada.
6. Apesar de concordar com algumas coisas que dizes, esta não vai ser uma delas... JNI ou o .Net DllImport é indiferente, dão o mesmo trabalho a fazer à unha e à partida tens de ter consciência que aquilo não vai funcionar em qualquer outra plataforma. Agora, que o VS.Net facilita a vida, há disso não tenhas dúvidas... desde que sejam coisas simples :) Tive um colega meu aqui há uns anos - quando o .Net foi c*gado cá para fora - que andou a marrar com a importação de uma Collection de VB. Executava o método da DLL COM que devolvia uma Collection mas não fazia mais nada com aquilo. Não sei se entretanto as coisas mudaram mas...
7. Qual é a diferença mesmo?! 8. hmmmm apesar de também gostar da ideia da mistela (desculpa, mas é isso que gosto de lhe chamar :)), não acho isso muito vantajoso num projecto interno... Já viste se o gajo de C++ se vai embora? Lá tens de perder uma ou duas semanas a aprender C++ para poder fazer a manutenção do código dele.
Mas aí a culpa nem é do homem, é de quem deixou o uso da linguagem ao critério do programador.
Por outro lado, se uma empresa tem um gajo que só sabe C++ e mai'nada, pode reaproveitá-lo para projectos em .Net e metê-lo numa equipa de VB-zealots.
Já ando de olho no mono há mais de um ano e estou mortinho para que a versão estável venha cá para fora mas também te digo, ficar-me pelo .Net e ignorar o Java é um erro de carreira... mark my words.
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | serve para disponibilizar métodos in-place.
s/in-place/inline <duh>
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | Olá, antes de mais obrigado pelo post que achei muito interessante. :-) Sobre o catch: por acaso é um bom método, nem o conhecia. Mas isso põe a tua classe à prova de bala, mas não implica que o utilizador ingula a excepção. Não concordas que isso é má programação? Talvez não seja muito relevante em projectos pequenos, mas... 3. Mais uma vez, o final está lá bem presente e é usado criteriosamente :) Caso não saibas, o final não serve apenas para virtuals: muito melhor que isso tudo, serve para disponibilizar métodos inline. Se não sabes do que falo, go check your C tutorial ;) Por acaso desconhecia completamente. Fui induzido em erro por um artigo que li. Mas por acaso faz mesmo todo o sentido. Contudo, não sei se neste ponto ganha ao .NET, ou fica em pé de igualdade. Acho que ganha porque delega para a VM a escolha dos métodos virtuais, mas isso tem problemas de versões, como tava no exemplo que dei. 4. Honestamente, aqui entre nós dois que ninguém nos ouve, boxing/unboxing é daquelas coisas que não aquecem nem arrefecem. Vais criar um ArrayList para int's? Que tal um simples e velho int[]? Não, nunca tive necessidade disso. Mas já tive necessidade de usar inteirnos em TreeMaps, e Hashtables... Só não faz é o cast "automágicamente", mas que se lixe... a gente (as in royal we) gosta de ter algum controlo sobre aquilo que os outros metem num ArrayList e queremos mandar cá para fora um ClassCastException quando alguém faz caca Mas o foreach lança excepção caso não consiga realizar o cast. Esta parte é mais uma questão de gosto, eu prefiro fazer um foreach( XmlNode node in parent.ChildNodes ) e ter o node do seu tipo, em vez de tar com cast's a toda a hora, ou tar a criar uma referência do tipo que quero logo asseguir ao for (tal como o foreach faz). Apesar de concordar também com os atributos, deixa-me só clarificar que existem duas maneiras automatizadas de fazer parsing de XML, ou usas o DOM ou usas o SAX... Não há DOM, SAX e MS-Way. Fazer parsing de XML em Java usando o DOM ou o SAX não é diferente de fazer parse de XML em .Net em DOM ou SAX. Mea culpa então. Eu conheço as diferenças, simplesmente tinha ideia que a parte DOM não estava implementada em Java (se estava, porque me fizeram usar o SAX? yuck). Erro meu. 6. Apesar de concordar com algumas coisas que dizes, esta não vai ser uma delas... JNI ou o .Net DllImport é indiferente, dão o mesmo trabalho a fazer à unha e à partida tens de ter consciência que aquilo não vai funcionar em qualquer outra plataforma O mesmo trabalho? No JNI tens de andar com aquela C API (na minha opinião), no .NET tens só de adicionar um atributo a dizer a lib onde ele vai buscar a função. Não sei o contexto do problema do teu colega, mas eu nunca tive problemas nenhuns a chamar COM, DLL's normais, etc. Quanto à portabilidade, também depende como usas. O Pessoal do Mono tem umas directrizes que, se cumpridas, e caso a lib exista em todo o lado, permitem uma "suposta" portabilidade. 8. hmmmm apesar de também gostar da ideia da mistela (desculpa, mas é isso que gosto de lhe chamar :)), não acho isso muito vantajoso num projecto interno... Já viste se o gajo de C++ se vai embora? Lá tens de perder uma ou duas semanas a aprender C++ para poder fazer a manutenção do código dele. Mas isso já são problemas de gestão. O .NET não diz que tens de usar várias linguagens, apenas permite que o faças. Cabe a cada um, no seu belo entender, usar esse mecanismo. Já ando de olho no mono há mais de um ano e estou mortinho para que a versão estável venha cá para fora mas também te digo, ficar-me pelo .Net e ignorar o Java é um erro de carreira... mark my words. Concordo contigo. Ainda bem que esta discussão não descarrilou e deu para aprender mais umas coisas em ambos os campos. :-) Eu nunca disse adeus ao Java, mas acho que só lucramos com duas tecnologias concorrentes.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Hello :) Mais achas para a fogueira:
Sobre o catch: por acaso é um bom método, nem o conhecia. Mas isso põe a tua classe à prova de bala, mas não implica que o utilizador ingula a excepção. Não concordas que isso é má programação? Talvez não seja muito relevante em projectos pequenos, mas...
Se o utilizador da minha classe engole a exception ou não, é um problema que já não é meu. Não acho que seja má programação, bem pelo contrário! Se não queres/tens de tratar uma Exception, executa o teu clean-up no finally e chuta a dita para cima.
Acho que ganha porque delega para a VM a escolha dos métodos virtuais, mas isso tem problemas de versões, como tava no exemplo que dei.
Uma classe final ou método final, não pode ser reescrito (overwrite) por uma subclasse, como tal não apresenta qualquer problema de versões. Final é final :)
Não, nunca tive necessidade disso. Mas já tive necessidade de usar inteirnos em TreeMaps, e Hashtables... Usar inteiros como chaves de TreeMaps ou Hashtables? Bom, se não estou em erro, um TreeMap ou uma HashTable cria a árvore com base no resultado da função hashCode() de um objecto (existem pela net fora algumas rotinas que ajudam a melhorar a performance da coisa quando usas classes tuas que só derivam da classe Object).
O box/unbox automático só simplifica na clareza do código, mas isso pode induzir algumas pessoas em erro quando essas ficam sem conhecer as razões das coisas e no fim o resultado não é o esperado.
Sobre o resto estamos mais ou menos de acordo :)
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | Se o utilizador da minha classe engole a exception ou não, é um problema que já não é meu. Não acho que seja má programação, bem pelo contrário! Se não queres/tens de tratar uma Exception, executa o teu clean-up no finally e chuta a dita para cima.
Pek Pek. E unta-te. ;)
|
| | | | > Por isso em C# todos os métodos por defeito são não virtuais.
Por defeito da especificação ou da implementação ? Como ainda não analisei nenhuma não sei qual é a mais defeituosa.
|
| | | | | bons pontos e boas respostas... não é normal... :)
não me parece que seja por aí que alguém vá escolher uma plataforma ou outra, sinceramente.
quanto a várias linguagens... usar .NET e não usar C# é um desperdício de tempo. IMHO.
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | 8. Múltiplas Linguagens
Podemos ter um Assemlby com módulos em várias linguagens. De notar a facilidade te ter por exemplo, o módulo de UI em C#, e ter um módulo lógico em Haskell.NET ou Sheme.NET, e ter ainda outro módulo em Managed C++ em que interagimos com o Sistema operativo muito melhor. E isto tudo é compilado para IL (os byte codes do .NET) e fica tudo num assembly pronto a usar, sem termos ideia de como foi implementado. Isto é muito bonito na teoria mas na prática tem-se verificado que as implementações de outras linguagens na plataforma .NET é incompleta ou implica alterações nas próprias linguagens. Como exemplo fica aqui uma report da ActiveState sobre a implementação do Python.NET e uma thread recente do Slashdot com alguns comentários interessantes.
|
| | | | | Olá. Não tenho a experiência nem os conhecimentos que tu e a grande maioria daqueles que te responderam têm, pelo que o que vou dizer será de certeza mal fundamentado e provavelmente totalmente ao lado do tema. No entanto, aqui vai -- se estiver muito mal moderem o post para baixo até desaparecer. Existem outras linguagens/plataformas de desenvolvimento verdadeiramente portáveis, que normalmente ficam esquecidas nas discussões .NET vs Java. Por exemplo, Python junto com Qt ou wxWindows (só para dizer dois) possibilita que uma aplicação escrita nesta linguagem corra em vários SO's. Não seria melhor pegar nestas plataformas e tentar desenvolvê-las em vez de tentar fazer uma coisa totalmente de novo e ainda por cima dependente de uma plataforma proprietária que não se sabe como evoluirá? Cumps.
"mudem de rumo, já lá vem outro carreiro" |
| | | | | | O problema desses ambientes é não conseguirem competir com o Java ou .NET no segmento "enterprise". Mas, por outro lado eu sou tentado a dizer que prefiro fazer prototipagem em Python do que em Java.
Se, tal como eu afirmo, o futuro do Mono não é ser um .NET mas sim uma nova plataforma, então a questão levantada acima pelo MeeTra torna-se ainda mais premente.
-- Carlos Rodrigues
|
| | | | | O problema desses ambientes é não conseguirem competir com o Java ou .NET no segmento "enterprise". Já agora porque achas isso? Marketing? Ou razões tecnicas? Se forem razões tecnicas quais são elas (diz só as mais importantes)? Essas razões tecnicas não são resoluveis (nem que num futuro a medio prazo)?
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Colocar uma plataforma nesse segmento exige um esforço tremendo (tanto técnico como de marketing, pois não basta dar para fazer, é preciso que os decisores o saibam e não olhem com desconfiança). O Python (por exemplo) simplesmente ainda não está lá (mas não vejo nenhuma razão técnica para que não possa estar daqui a uns anos se houver interesse nisso). O que eu quis dizer é que essas plataformas não têm a abrangência do Java ou do .NET, o que não quer dizer que não tenham as suas áreas de aplicação.
Estou a ser intencionalmente vago pois não há uma definição clara do que é o segmento "enterprise". Se considerarmos que o Python é perfeitamente usável na área onde o VB era tradicionalmente usado, então também podemos considerar que já está preparado para parte desse segmento. Mas se considerarmos as áreas onde opera o J2EE (Servlets, EJBs) então temos de admitir que ainda há muito a fazer.
-- Carlos Rodrigues
|
| | | | Concordo com você. Temos muitas ferramentas no Linux hoje que, se ainda não atingiram uma maturidade ou nível de funcionalidade exigidas para certas coisas que o .NET pode fazer, elas podem chegar lá com uma qualidade infinitamente superior a qualquer coisa vinda do Bill.
O engraçado é que algumas pessoas argumentam que o .NET resolve vários tipos de problemas que só são problemas se enquadrados na filosofia do .NET, sem o .NET os problemas ou não existiriam ou seriam contornados de outra maneira!
Concordo que alguns padrões podem ser bem proveitosos, mas não é nada que nos faça correr desvairados para o lado da Microsoft. ;-)
É como primeiro fazer a propaganda do tipo do problema e depois aparecer com a solução milagrosa ....
Usuário GNU/Linux 224050 |
| | | | Já que se fala em Python será interessante ver daqui a uns tempos se o Parrot é bem aceite pela comunidade e se consegue competir com o Java e o .NET.
|
| | | | yep, só no outro dia é que vi isso... muito interessante :D
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | | Vou, em parte, repetir um post que fiz há umas semanas sobre o mesmo assunto. Porei em causa o .NET, não do ponto de vista tecnológico, mas do ponto de vista da interoperabilidade. Tal como afirma o CrLf, o .NET é, e tenderá a ser cada vez mais, uma forma de "lock-in" ao Windows. É óbvio. Para termos alguma esperança que programas desenvolvidos em .NET corram sem problemas em Mono é necessário que não façam uso de chamadas P/Invoke ou de qualquer coisa do namespace Microsoft.* ou dependam da existência do Registry do Windows. Por outras palavras, a interoperabilidade entre .NET e Mono tenderá a ser uma lotaria do género daquela que já há alguns anos utilizadores de Linux jogam quando querem correr um programa Windows em Wine: alguns programas funcionam, outros funcionam parcialmente, outros nem sequer arrancam. Só aqueles programas que tiverem sido concebidos com a interoperabilidade com o Mono em mente é que poderão correr sem problemas. O Mono é um projecto tecnologicamente interessante e, se bem que não seja necessariamente mau para o Linux que ele exista, há que ter a consciência clara que o Mono ainda não constitui (e dificilmente constituirá) uma opção séria para desenvolvimento de aplicações de ambito enterprise. Não se está a ver projectos de grande envergadura e que envolvam grandes investimentos confiarem no Mono para correr aplicações desenvolvidas em .NET. Neste campo, o Java continuará a merecer mais confiança, e não é difícil entender porquê: o código das JVM da Sun ou da IBM está na base das implementações disponíveis para vários sistemas operativos. O programador Java, ao desenvolver aplicações num determinado sistema operativo, tem uma razoável grau de confiança que as suas aplicações serão portáveis. Tem uma razoável confiança que as classes de terceiros das quais fizer uso comportar-se-ão como esperado quando o seu programa for executado num outro sistema operativo. Pelo menos, a Sun, a IBM e outros fabricantes de JVMs empenham-se para que tal aconteça. Porém, com .NET não há quaisquer garantias. A Microsoft apenas disponibiliza esta plataforma de desenvolvimento para Windows e, como empresa, apenas se responsabiliza pelo seu bom funcionamento em Windows. A responsabilidade pelo bom funcionamento das plataformas compatíveis com .NET (dais quais o Mono é um exemplo) é dos terceiros que as desenvolvem. É, pois, uma pura utopia pensar num futuro de aplicações portáveis feitas em .NET. E aqui é que reside o carácter mais pernicioso do Mono: este projecto descansa as consciências de alguns que actualmente desenvolvem em .NET fazendo-os embarcar na ilusão que estão a desenvolver aplicações portáveis. Com o esperado aumento da taxa de penetração do Linux nos servidores e nos desktops, a interoperabilidade terá que assumir uma importância fulcral. E o .NET -- ou pior ainda, o que os mouse-engineers farão com o .NET --, só pode motivar desconfiança.
|
| | | | | | | Esses artigos assumem que seria bom para a Microsoft ter um .NET portável, mas não é. E porquê? Porque em toda a Microsoft as duas únicas divisões que dão lucros são a divisão que produz o Microsoft Office e a divisão que produz o Windows. Tudo o resto são manobras (muitas vezes dispendiosas) de manter o domínio sobre estas duas áreas. É uma espécie de comunidade de abelhas em que muitas dão a vida para que algumas continuem a manter o enxame poderoso.
-- Carlos Rodrigues
|
| | | | Podes mostrar-nos números para justificar essa afirmação? É que não vejo muito bem como é que alguns dos produtos da MS encaixam nessa teoria (ex. MSSQL).
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | na Visão desta semana vem um artigo (sobre Linux) onde aparece um gráfico que mostra qual a percentagem que cada produto tem nas receitas da MS. o Windows e o MS Office dominam esmagadoramente. o .NET, ao trancar ainda mais os fabricantes de software ao Windows, vai assegurar que o Windows continue a ser muito vendido (a nível desktop, mas também de servidor) e, consequentemente, que o MS Office continue a ser popular (porque se o Linux for mais adoptado, o OpenOffice/StarOffice passa também a ser mais popular no Windows).
|
| | | | Correcto. Mas o que o CrLf disse é que são os únicos produtos que dão _lucro_ à MS. Isto é, tudo o resto que a MS faz dá _prejuízo_ e apenas existe para suportar o mercado do MS Windows e MS Office.
Isso é uma tática comum e acredito piamente que a MS o faça relativamente a alguns produtos. Mas há outros que não consigo encaixar nessa tática. Daí questionar a afirmação dele.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | Ao que sei são as unicas que ainda cresceram (apesár de o crescimento ter diminuido), no ultimo ano, não me lembro se as outras deram prejuizo. Li isto em várias noticias em vário sites, como já foi à muito tempo ja não sei quais.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | A minha afirmação era para ser interpretada com uma pitada de sal. É muito provável que hajam mais áreas dentro da Microsoft a dar lucro, mas esse lucro é irrisório quando comparado com o lucro do Office e do Windows. Não posso afirmar com certeza mas penso que o MSSQL é uma dessas áreas que não dão lucro. Repara, a Microsoft investe brutalmente nessas outras áreas para que sirvam como alavanca do Windows, o que faz com que os ganhos que delas obtém dificilmente conseguem cobrir os custos. Tudo isto é compensado pelas obscenas margens que obtém com o Office e o Windows, pelo que a Microsoft continua a ser uma empresa muito lucrativa.
Este artigo do Cringely é bastante ilustrativo desta prática.
-- Carlos Rodrigues
|
| | | | | Concordo. Só achei a questão do "únicos" um tanto exagerada. A respeito do artigo, parei de ler quando sugeriu que a MS gostaria de substituir os CPUs x86 fornecidos pela Intel/AMD/Transmeta/VIA/Cyrix por CPUs "IL" fornecidos pela IBM e que emulassem x86. Next conspiracy theory please..
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | na Visão desta semana vem um artigo (sobre Linux) onde aparece um gráfico que mostra qual a percentagem que cada produto tem nas receitas da MS. o Windows e o MS Office dominam esmagadoramente.
Ya, o mesmo artigo onde dizem que o RMS é o criador do Linux... pffff aquilo olha para o GNU/Linux como se fosse uma empresa - ah, da qual o Linus aparentemente é o CEO :)
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | Pensava que quem dizia GNU/Linux também achava que o RMS tinha sido o seu criador...
-- Carlos Rodrigues
|
| | | | pensas mal, no meu caso é do hábito de escrever Debian GNU/Linux :)
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | Concordo completamente contigo. Só queria a tua opinião sobre uma coisa, e se a Microsoft tiver intenções de alargar os seus horizontes/mercado a outros sistemas operativos? Eu, tal como toda a gente, sou muito desconfiado em relação ao .NET e à Microsoft. O que é que eles querem? Porque é que têm o Rotor a correr em plataformas não Windows como o FreeBSD e o Mac? Será que eles querem que o pessoal se habitue ao .NET, e depois de modo que puxar comunidades de outras plataformas para o Windows? O C# e o CLI são ECMA Standards... será que a Microsof quer um Mono que faça tudo bem dentro dos standards, e depois se os clientes quiserem mais terão de usar bibliotecas só Microsoft?
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | A estratégia da m$ deve passar por aumentar as opções ao mesmo tempo que combate furiosamente para manter as suas plataformas como dominantes.
Quem acredita que o .net é um esforço para que se possa obter independencia em relação ao OS está na minha opnião muito iludido, já na independencia em relação ao hardware é diferente, é obvio que a m$ quer que o .net se torne dominante neste aspecto. O rotor (implementação de .net sob a shared source), é uma obvia tentativa de matar o Java. À m$ não lhe chega que o .net tenha sucesso, tem de dominar absolutamente, tem de ser um monopolio, ou seja, tem que matar a unica ameaça, o Java. É esse o padrão de actuação da m$, ao longo do tempo e assim penso que vai continuar. O C# e o CLI são standards proprietários, ou seja, totalmente controlados do ponto de vista de propriedade pela m$, apenas são publicados pelo ECMA, nada te garante que futuras versões sejam standards.
Tal como o rotor estes standards fazem parte da tentativa para fazer-nos crer que desta vês vai ser diferente. Tal como qualquer outra implementação que não a da m$ o mono será tão compativél quanto for conveniente à m$ e pelo tempo que for conveniente à m$. Resumindo o rotor e os standards são uma cortina de fumo. A m$ está a utilizar tecnicas de estratégia facilmente reconhecidas por qualquer um que conheça minimamente a m$ e que tenha lido a Arte da Guerra de Sun Tzu.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Novell, contamos contigo :)
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | Olha, eu publiquei um artigo com alguns comentários sobre o Mono onde recebi muitas críticas mas muitos elogios também, e depois disso sou reconhecido como um "demonizador" do Mono e do Icaza, então não vou os méritos da coisa em questão aqui, mas vou resumir minha opinião:
Eu não confio em mais NADA que possa vir do lado da Microsoft (vi tudo que aconteceu praticamente nos últimos 15 anos vindo do lado deles), acho que o pessoal do Mono tinha que ser menos que supostamente "ingênuos" sobre isso e acho que todos devemos abrir os olhos com as patentes que a Microsoft tem sobre o .NET, por que hoje em dia os argumentos técnicos deles estão se esvaindo (todo mundo está finalmente vendo a falta de qualidade pungente dos produtos) e eles vão começar a jogar sujo para arrumar mais dinheiro e poder. Vide a cobrança do FAT (em relação à patentes-coitadas das camêras digitais!) e as atitudes da SCO (que agora não é nem de longe uma companhia de software, e sim de advogados).
Abraços!
Usuário GNU/Linux 224050 |
| | | | | | há que ter consciência que as patentes de software só existem na américa...
e mesmo assim, parece que também estão fartos de atribuir erroneamente patentes (vi na scientific american que pretendiam um modelo menos litigioso, etc).
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | O Mono é uma implementação da especificação C#/.NET da Microsoft que está no processo de se tornar um standard ECMA. A Ximian está a participar neste processo.
Quando o processo terminar vai existir uma implementação Microsoft de acordo com a especificação publicada e uma implementação Ximian que vai estar tanto de acordo com a especificação como eles conseguirem. Depois disso, a Microsoft vai provavelmente começar a "expandir" a plataforma e da mesma maneira que as especificações W3 são totalmente estranhas ao bando de azeiteiros que andam praí a fazer "webdesign" as especificações da plataforma .NET vão ser estranhas aos escribas de VB.
Os planos da Ximian não são muito diferentes mas os resultados são. A Ximian pretende tornar o Gtk# o toolkit de referência do .NET. Quando a MS avançar com as suas extensões proprietárias a Ximian pretende ter as suas próprias extensões abertas para competir. A escolha não vai ser entre o sistema Windows e o sistema Linux mas sim entre "apenas o Windows" e "Tudo" dado que o Mono funciona em Linux, Windows, Unix(Solaris e ?) e potencialmente OSX. Se conseguir estar ao nivel do .NET em termos de documentação e IDEs até pode ser que ganhem.
Em resumo, a Ximian quer vencer a Microsoft no seu próprio jogo. Se conseguir daqui a 5 anos a Novell vai estar de novo em todos os desktops empresariais. A vida é complicada.
|
| | | | | | Só para complementar, uma pergunta que se faz muito ao pessoal do Mono é: "E se a Microsoft decidir boicotar o Mono?", ao que o Miguel de Icaza responde: "Nesse caso teriamos nós um ambiente de desenvolvimento multi-plataforma, mesmo não sendo o 'mesmo' do o da Microsoft, teria na mesma o seu valor".
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Eu nunca gostei do Java. Porquê? Primeiro, porque mistura duas coisas: O runtime, e a linguagem, num só. Eu considero isso um erro colossal. A principal razão de sucesso do C não foi tanto a performance em si, como o simples facto de quase qualquer linguagem de programação poder interagir com as bibliotecas C. Sim jovens, é necessário que existam várias linguagens de programação, pela mesma razão que usamos ferramentas de vários tipos. Quando quero aparafusar qq coisa, uso uma chave de fendas, não um martelo. Um martelo pode ser porreiro para muitas coisas, mas não é uma ferramenta universal. Tal coisa não existe. Nem mesmo um canivete suíço dá para tudo hein! O segundo erro do Java foi a Sun decidir controlar a plataforma com punho de ferro, não permitindo que esta evoluísse para nichos de mercado. Nenhuma plataforma pode esperar resolver todos os problemas por si só. Também não gosto do .NET. Porquê? Porque a Microsoft tem patentes sobre esta treta toda, patentes que eles não irão disponibilizar livremente. O C, por exemplo, também não tem esses problemas. Para além disso, qual é a garantia que eu tenho que eles não vão fazer os truques do costume e fechar a plataforma? Eu não uso o Java precisamente por causa destas razões e também não vou usar o .NET.
|
| |
|
