Ser ou não ser?
[quote=MaikoID]Não considero linguagem de programação, linguagem presa a uma única plataforma, isso pra mim é um bash orientado a objetos nem de longe é uma linguagem de programação.
A linguagem que mais tem mercado é C/C++ e que tem mais crescido para dispositivos embarcados é C/C++ ou estou errado? Dizer que as duas mais disputadas linguagens no mercado é Java e .Net é no mínimo tosco…
Abraço.[/quote]
Pensando assim você vai longe… :?
[quote]…
Em java simplesmente não ha necessidade de instanceOf T e t.newInstance() porque em java generics é um tipo de assinatura forte e não um mecanismo de template como na familia C. Independentemente disso, não ha aplicação que seja impedida por essa diferença. O mesmo com a sobrecarga. Que uso vc fez disso que não , não podendo fazer em java o impediria de usar java ?[/quote]
Vou resumir isso em vantagens que o c# pode ter em relação ao java.
*Sobrecarga de Operadores- Flexibilidade. Se eu não me engano, aqui no guj tem um tópico sobre isso.
ex:
http://www.arnaut.eti.br/op/CPPAI06.htm
*Ponteiros - Opção de se usar ou não coletor de lixo, em partes de código. Isso me dá performance para operações com imagens digitais. Se fizer um benchmark com BufferdImage, e um Bitmap do winforms, usando unsafe, vai ver que a diferença de velocidade de processamento é grande.
Memory leaks em java são tão comuns como em c ou outra linguagem. A diferença é que as ferramentas para lidar com isso são muito fortes em java.
Ex: VisualVM, Profiler;
*Structs e tipos unsigned- Não preciso usar nenhuma api para implementar um protocolo de comunicação. Novamente ganho performance.
*Tipos unsigned: Tipos unsigned são subtipos dos tipos primitivos. Em java, o char pode ser unsigned, mas o integer não, nem o long, nem nenhum. Posso utilizar o intervalo de um inteiro negativo, adicionando-o ao positivo e aumentando a sua capacidade, com a palavra chave unsigned.
*Multimedia, Hardware - Directx e Opengl são recursos ligados diretamente ao hardware. Java 3d é somente um mapeamento sobre direct3d ou opengl, e você pode escolher qual usar. Esse mapeamento é somente um jni.
Agora, cada trabalho pede um tipo de funcionalidade. Citei essas, porque (no meu caso) uso constantemente.
[quote=Roberto Porto]
Pensando assim você vai longe… :?[/quote]
Porque uai? Linguagem de programação obrigatoriamente tem de ser independente do SO, pessoal acostumado com venda casada não costuma pensar muito em portabilidade e livre direito de escolha…
Bash = C# = Funciona só numa plataforma.
Como OO é um conceito, acredito que ambas “linguagens” são equivalentes em bash é possíve implementar o conceito de OO com alto grau de dificuldade adminito, rsrs.
Sobre a descrição tosca que segue no tópico: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Czão rules, C# tem 0,5% a mais de uso que Python, então nem me venha falar sobre as “Linaguagens mais usadas no mercado” que não passa de besteira e das brabas…
[quote=MaikoID][quote=Roberto Porto]
Pensando assim você vai longe… :?[/quote]
Porque uai? Linguagem de programação obrigatoriamente tem de ser independente do SO, pessoal acostumado com venda casada não costuma pensar muito em portabilidade e livre direito de escolha…
Bash = C# = Funciona só numa plataforma.
Como OO é um conceito, acredito que ambas “linguagens” são equivalentes em bash é possíve implementar o conceito de OO com alto grau de dificuldade adminito, rsrs.
Sobre a descrição tosca que segue no tópico: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
Czão rules, C# tem 0,5% a mais de uso que Python, então nem me venha falar sobre as “Linaguagens mais usadas no mercado” que não passa de besteira e das brabas…
[/quote]
Oo - C# roda em várias plataformas, inclusive ipods, nintendos wii, powerpcs, arms.
Não entendi o bash…
Só complementando…o mono tem um compilador nativo, de c#, para todas essas plataformas.
Olha só. Na época do VB6 e Delphi, todo mundo dizia que Delphi era melhor. Conhecendo o VB6 acredito que era mesmo, mas não foi suficiente para fazer ele dominar o mercado. Na época do ASP (sem o .) o PHP já vinha fazendo sucesso. Hoje vemos especificações java que são ignoradas pelo mercado, e ferramentas que vão até contra as ideias das especificações, serem usadas em massa. Estou usando NetBeans em um projeto pessoal. Até o momento senti falta de pouca coisa comparando com o Eclipse. Algumas até achei melhor, mas o Eclipse domina o mercado com folga, aliás li que existe uma IDE melhor que o Eclipse, mas é paga. Mas quase não é usada quando comparada as anteriores.
Trabalhei em um banco grande com java para web e o sistema sofria constantes ataques da equipe interna do banco para transforma-lo em ASP(sem o .). Durantes anos o java resistiu por ter créditos quanto a segurança, e como o Banco todo era Microsoft, eu ficava até abismado com a resistência, que convenhamos, era merecida. Quando saio .Net o java não resistiu e o sistema foi todo convertido. A empresa que eu trabalhava foi toda convertida também, quando chegou a minha vez de me converter eu sai. Na maioria das vezes não importa muito a linguagem a ser usada. A decisão é estrategicamente voltada para o negócio da empresa como um todo. E negócio envolve parcerias. Alguém já trabalhou com BPM aqui? Se usar o Aqualogic, vai automaticamente usar o WebLogic. E se usa WebLogic e quer usar BPM, não vão deixar vc enfiar um JBoss para rodar junto. Vai rodar no WebLogic e vai ter que ser Aqualogic porque ambos são da BEA. E por ai vai. O que realmente torna o .Net atrativo é a gama de parceiros e clientes que a Microsoft tem. Existem muitos projetos interessantes em .Net do ponto de vista de negócio e as vezes para java o projeto é um porre mesmo usando pattern e tecnologia de ponta, por causa do parceiro. Para mim não é Java x .Net, é Microsoft x o Resto. E me desculpe quem se ofender, eu não visto camisa de empresa nenhuma mas é assim que vejo o mercado. A Microsoft, seja la o que ela fizer, se for pelo menos útil, vai ser bastante usado, mas dificilmente vai ter a mesma qualidade dos concorrentes.
E quem disser que é mais produtivo usar JTable do Swing ao invés do DataGrid do VB6 ta de brincadeira. Só o fato e ter que implementar o DataModel já acaba com essa afirmação. Mas concordo que VB6 é um lixo e a Microsoft não matou ele a toa. O Swing é considerado uma obra de arte OO por muita gente, mas é devido sua abstração, ou seja, muita coisa tem que ser implementada. E DLL, OCX e .JAR acabaram virando tudo a mesma coisa. No caso do VB se vc instalar ele inteiro na maquina do cliente :shock: e depois remover ele, os erros de ocx simplesmente desaparecem. No JBoss ainda não consegui fazer isso. :mrgreen: hehehe e nem tentei. Mas mesmo assim ainda prefiro o java, pela sua transparência, portabilidade e padronização, isso o .Net não tem.
[quote=juliocbq]
Oo - C# roda em várias plataformas, inclusive ipods, nintendos wii, powerpcs, arms.
Não entendi o bash…
Só complementando…o mono tem um compilador nativo, de c#, para todas essas plataformas.[/quote]
Só roda em Windows-like não é?
Sim existe o mono que é cross plataform, mas até hoje não vi uma aplicação desenvolvida nele (com certeza deve existir) e seu “framework” praticamente é reescrito a cada versão, se isso for cross-plataform eu desacarto, obrigado.
Porém o Mono tem que amadurecer muito para posibilitar o desenvolvimento de aplicações de forma decente, por que do jeito que está só serve mesmo para fazer o Hello World.
[quote=MaikoID][quote=juliocbq]
Oo - C# roda em várias plataformas, inclusive ipods, nintendos wii, powerpcs, arms.
Não entendi o bash…
Só complementando…o mono tem um compilador nativo, de c#, para todas essas plataformas.[/quote]
Só roda em Windows-like não é?
Sim existe o mono que é cross plataform, mas até hoje não vi uma aplicação desenvolvida nele (com certeza deve existir) e seu “framework” praticamente é reescrito a cada versão, se isso for cross-plataform eu desacarto, obrigado.[/quote]
Dá uma olhada nisso. É usada para desenvolver filmes em holywood, e jogos para a maioria dos consoles, como o n wii e e ps3. Desenvolvida com mono.
Ao meu entender, o único problema é sobre manter a compatibilidade com winforms. Mas por mim, usaria somente o gtk mesmo, que é muito estável.
Olha esse hello word.
[quote=marcosalex]Pra quem acredita que uma vantagem do .NET é ser um padrão ECMA:
http://mono-nono.com/bbpress/topic/detailed-count-of-net-35-covered-by-ecma-335
É a mesma coisa do OOXML com o ISO: nem o Office 2007 segue o padrão que eles remeteram pro órgão.[/quote]
marcos, ECMA é a linguagem c#. Ela não tem nada haver com dotnet.
Se a jvm suportasse c#, eu passaria a usá-la, ao invés do dotnet.
A MS não repeita nem o padrão ISO, para c++. Mas não preciso dela pra codificar em c#.
[quote=juliocbq]marcos, ECMA é a linguagem c#. Ela não tem nada haver com dotnet.
Se a jvm suportasse c#, eu passaria a usá-la, ao invés do dotnet.[/quote]
Olha, confesso que ficaria tentado também. Só sinto falta realmente da implementação de interfaces anônimas privadas inline. Dá para contornar com os delegates anônimos, mas não é tão poderoso, já que cada delegate representa uma única função.
[quote=marcosalex]Não precisa pra codificar em C#, mas então não pode alegar que a especificação da linguagem está coberta pelo padrão, que é o que a MS e os defensores do C# e .NET alegam.
Nem 20% dele é compatível com a especificação “oficial” do ECMA. Ou seja, fail![/quote]
Nesse caso, é bom não chamar o Java de ISO também.
Afinal, a API do Java não é ISO…
[quote=marcosalex][quote=juliocbq]
marcos, ECMA é a linguagem c#. Ela não tem nada haver com dotnet.
Se a jvm suportasse c#, eu passaria a usá-la, ao invés do dotnet.
A MS não repeita nem o padrão ISO, para c++. Mas não preciso dela pra codificar em c#.[/quote]
Não precisa pra codificar em C#, mas então não pode alegar que a especificação da linguagem está coberta pelo padrão, que é o que a MS e os defensores do C# e .NET alegam.
Nem 20% dele é compatível com a especificação “oficial” do ECMA. Ou seja, fail![/quote]
O mono cobre a especificação em 100%. Se a microsoft não padroniza ISO nem ECMA é opção e problema dela. Não me afeta em nada se eu tenho poder de escolha.
Eu poderia muito bem desenvolver uma jvm e não seguir o padrão. É tudo uma questão de opção.
Discordo, em Java não existe essa possibilidade, mas a necessidade existe sim. Tanto que uma abordagem comum é contornar isso com reflection.
[/quote]
Mostre exemplos. Da minha experiencia quando um programador quer fazer isso é porque a sua modelagem é falha.
repare no método
[code]public T newInstance(){
}[/code]
Mesmo que não houvesse erasure não é possivel saber quem é T porque se trata de um método puramente co-variante.
Para este método ter acesso a algum T real o T precisa ser definido na classe
Agora sim, porque em algum lugar terei que escrever
Se vc fizer isto, vc terá acesso a X via reflection dentro de newIntance.
não ha necessidade de t.newinstance()
instanceofT é absurdo porque se T é genérico vc não deveria estar tentando saber que tipo ele é.
não. O ponto não é esse. O ponto é que na prática , mesmo sem essa feature maluca, não ha limitação.
Sim. generics servem apenas para assinar fortemente. Só.
Se não ha limitações impostas pela diferença de implementação, este ponto não é portanto relevante à discussão.
Isso é um missconception comum. char , embora o nome, é um numero. O que acontece é que existem os literais de char que o java mapeia pela tabela UTF-16. São os literais, não o tipo, que representam caracteres. vc pode escrever char c = 3 sem problemas
e pode fazer operações ariméticas sem problemas (bom, como os mesmo problemas que com os outros tipos numericos diferentes de int)
char pode representar o que vc quiser. Acontece apenas que o java lhe dá essa canja de poder usar para representar caracteres (em um certo encoding). Mas isso não é de longe nem de perto limitativo.
Se deveria haver um classe, então escreva-a. Essa coisa de esperar que a plataforma lhe dê tudo não é razão.
Se deveria haver um tipo diferente, já argumentei.
aliás java explicitamente não tem unsigned por causa do critério de segurança (pela mesma razão que não tem ponteiros e destrutores e outras coisas assim… afinal java não é da familia C)
Já. Em JME para manipular imagens gif e tiff.
Eu fiz um stream especial que tratava os bytes. Não tive problemas.
Eu acho esse tipo de adaptador normal. Se houve unsigned seria muito mais complexo. Java é OO , ter
um vasto leque de tipos primitivos não é o objetivo.
E como já concluimos, isso não impede nada. Portanto, tb não é razão para preferir uma plataforma à outra.
[quote]
Mas se fosse impossível ter acesso a esses recursos , coisas como o JMonkey seriam impossíveis. O ponto é que a plataforma Java sim pode ter acessos nativos do nivel que vc quiser não impossibilitando nenhum projeto ou obrigando a escolher outra plataforma.
as diferenças sintáticas e semânticas das linguagens são detalhes , firulas. O que interessa para um arquiteto é a capacidade de responder às qualidades esperadas. E isso é a plataforma como um todo que oferece. Indo, até, além das fronteiras dos SDKs …
[quote=ViniGodoy][quote=juliocbq]marcos, ECMA é a linguagem c#. Ela não tem nada haver com dotnet.
Se a jvm suportasse c#, eu passaria a usá-la, ao invés do dotnet.[/quote]
Olha, confesso que ficaria tentado também. Só sinto falta realmente da implementação de interfaces anônimas privadas inline. Dá para contornar com os delegates anônimos, mas não é tão poderoso, já que cada delegate representa uma única função.[/quote]
Só pelo fato de poder usar sobrecarga de operadores. Criar uma classe representasse uma matriz, e simplesmente:
[code]byte byte[3][3] = {1,1,1,1,1,1,1,1,1};
Matrix a = new Matrix(bytes);
Matrix b = new Matrix(bytes);
Matrix c = a + b;[/code]
Imagina isso, extendendo uma classe para se trabalhar com imagens digitais, ou mesmo protocolos.
socket("192.168.1.2:80");
socket << byte;
Realmente só faltava estar na jvm.
[quote=marcosalex][quote=juliocbq][quote=marcosalex]
Não precisa pra codificar em C#, mas então não pode alegar que a especificação da linguagem está coberta pelo padrão, que é o que a MS e os defensores do C# e .NET alegam.
Nem 20% dele é compatível com a especificação “oficial” do ECMA. Ou seja, fail![/quote]
O mono cobre a especificação em 100%. Se a microsoft não padroniza ISO nem ECMA é opção e problema dela. Não me afeta em nada se eu tenho poder de escolha.
Eu poderia muito bem desenvolver uma jvm e não seguir o padrão. É tudo uma questão de opção.[/quote]
É óbvio. Não estou dizendo que você é obrigado ou que deveria seguir ou que o melhor é seguir.
Só estou dizendo que se você NÃO segue, jamais diga que segue ou que a sua vantagem é seguir o padrão porque você está mentindo. [/quote]
Mas o mono segue, então porque eu estaria mentindo?
[quote=marcosalex][quote=juliocbq][quote=marcosalex]
É óbvio. Não estou dizendo que você é obrigado ou que deveria seguir ou que o melhor é seguir.
Só estou dizendo que se você NÃO segue, jamais diga que segue ou que a sua vantagem é seguir o padrão porque você está mentindo. [/quote]
Mas o mono segue, então porque eu estaria mentindo?[/quote]
Quem mente é a MS.
Mas o tópico é sobre Java e .NET, não sobre Java x Mono. Uma vez que o Mono está sempre correndo atrás do .NET e até hoje não cobriu nem a versão 2.0 por completo, embora tenha algo da 3.0 e da 3.5.
Mas mesmo assim tenho minhas dúvidas sobre se ele cobre 100% do ECMA.[/quote]
Sim o tópico é sobre .net. Mas o que eu quero dizer é a respeito da linguagem c# que não tem nada haver com isso.
E o objetivo do mono não é cobrir o winforms em 100% porque ele é patente da MS. O Objetivo é um framework para gtk#.
Agora que a linguagem c# é muito boa, isso é mesmo, sem sombra de dúvidas.
Não é absurdo, porque T representa um tipo. Nesse caso, deveria ser possível testa-lo. Type erasure vem com limitações e nega-las é agir com ignorância.
Não poder testa-lo é só uma dessas limitações. Da mesma forma, construir um T não é absurdo porque T pode ser construído.
Ainda não há solução para se construir T, ou se testar se um determinado objeto é do tipo de T, sem apelar para a reflection. E reflexão, apesar de remover a limitação, costuma a ser insegura e só verificada em runtime.
Você também não pode testar se uma lista é instanceof List ou instanceof List. Afinal, para o Java, ambas as listas representam exatamente o mesmo tipo. Você não pode testar dentro de seu código que tipo tem T.
Todas são limitações. São limitações terríveis? Não. Mas podem te incomodar, dependendo do que você esteja fazendo.
Não concordo que seja irrelevante. Não está sendo comparado somente o que as linguagens são capazes, mas como. Se for comparar só o que podem fazer, então, assembly será tão bom quanto Java.
[quote]Isso é um missconception comum. char , embora o nome, é um numero. O que acontece é que existem os literais de char que o java mapeia pela tabela UTF-16. São os literais, não o tipo, que representam caracteres. vc pode escrever char c = 3 sem problemas
e pode fazer operações ariméticas sem problemas (bom, como os mesmo problemas que com os outros tipos numericos diferentes de int)
char pode representar o que vc quiser. Acontece apenas que o java lhe dá essa canja de poder usar para representar caracteres (em um certo encoding). Mas isso não é de longe nem de perto limitativo.
[/quote]
Imprima um char. O que aparece? Um número? Por que o Java faz a conversão implícita?
O tipo char representa um caracter, codificado na forma de um número. Ele pode ser convertido para uma representação numérica, mas ele não é um número. A definição de char, dada pela sun, é:
Trata-lo como um número é só uma forma de simplificar diversas operações, mas é, na prática, uma violação do conceito do tipo char em si. É lidar com a sua forma bruta, o que não deveria ser feito. É como tratar o String como um array de números, ou dizer que o um int é formado por 4 bytes de -127 até 128. Tudo isso é verdade, mas não é o que o tipo foi criado para representar.
Ele foi criado para tratar caracteres. A “canja” que o Java dá é justamente ao contrário: permitir que ele seja tratado como um número.
[quote]Se deveria haver um classe, então escreva-a. Essa coisa de esperar que a plataforma lhe dê tudo não é razão.
Se deveria haver um tipo diferente, já argumentei. [/quote]
É razão sim, já que estamos comparando duas plataformas. Por mim, isso é um recurso muito básico, e qualquer API de classes que se propusesse estar na “borda” entre duas aplicações deveria tratar esse detalhe. Eu já escrevi essa classe, como provavelmente milhares de programadores que já precisaram fazer isso, em operações de I/O por aí.
Aliás, isso já foi solicitado para a Sun também.
C# suporta o tipo unsigned, e não tem esses problemas. O Java não trata o tipo primitivo unsigned long e, se você precisar dele, terá que recorrer a operações matemáticas lentas, na classe BigInteger. Específico? Talvez, mas uma limitação do mesmo jeito.
Finalmente, é fácil usar o argumento de “implemente você”. Nesse caso, eu deveria dizer que o LINQ não pode ser levado em conta, pq poderia ser implementado em Java? Acho que não… é um recurso importante, que está na API padrão da plataforma .net.
Usando o argumento de “implemente você”, você simplesmente abre mão de comparar as APIs padrão, já que, por definição, tudo o que está lá poderia ser implementado na linguagem.
Desculpa para boi dormir. Tipos com sinal não são inseguros. Se quer segurança, você teria que ter formas de definir ranges de maneira geral.
Esses recursos são implementados através de C, não de Java. Fora que é um processo lento, difícil e extremamente sujeito a erros. Um driver JNI se torna uma implementação complexa e insegura.
Em C#, o código fica limpo, elegante e facilmente integrado. O que acaba gerando um número de bindings maior e menos sujeito a erros. Não se pode negar que é uma vantagem sobre o Java. Isso é, se você não considerar que o programador é idiota, e que só pq esse recurso é mais fácil por lá, eles vão sair usando a torto e a direta. Aliás, o recurso é fácil, mas continua não sendo trivial, e na prática, não está sendo usado indiscriminadamente pela comunidade C#.
Nem sempre, muitas diferenças sintáticas podem evitar erros, ou tornar o código consideravelmente mais legível. Admito que elas podem ser evitadas, mas uma linguagem poderia só ter o comando “while” por exemplo, e não ter for nem for each. Mas não se pode negar que ficou mais fácil e agradável programar em Java depois do for…each e, de quebra, essa instrução evitou alguns erros comuns.
Não é absurdo, porque T representa um tipo. Nesse caso, deveria ser possível testa-lo. Type erasure vem com limitações e nega-las é agir com ignorância.
Não poder testa-lo é só uma dessas limitações. Da mesma forma, construir um T não é absurdo porque T pode ser construído.
[/quote]
Na prática esses recursos que vc identifica não impedem a criação de aplicações de um certo tipo.
O seu argumento virou então que em .NET , com C# (atenção ao detalhe de comparar as linguagens, porque em VB não ha signed byte… e o argumento ao contrário)… algumas aplicações podem ser feitas mais depressa.
Que tipo de aplicações são essas que podem ser desenvolvidas mais depressa ?
Até agora duas areas : perto do hardware e protocolos , e windows forms
Ok. Java realmente não é para hardware e protocolos - embora como vimos não é impossivel - já que uma coisa que pode fazer com .NET é DLL - que é algo mais de intra - e forms são para todos os OS por default o que significa que certas regras tem que ser seguidas.
Otimo. Vc faz esse tipo de coisa muito rapidamente (segundo vc mais depressa e com menos problemas que se fosse em java). Ok.
Agora vc quer utilizar essa vantagem para competir com o cara que, como eu, usaria java, mesmo sendo mais “lento”.
Vc vende o seu sistema para empresas que usam a plataforma windows. E eu vendo para quem usa a plataforma windows e as outras.
Vc acha que é o trade-off de velocidade/facilidade por portabilidade compensa ?
Ok, cada caso é um caso, mas a menos que haja exemplos concretos de estudos que foram feitos para uma aplicação X e se provou que .NET teria maior ROI a longo prazo é difícil entender como Y porcento do mercado é maior que Y+Z do mercado.
Os meus pontos, que ainda não refutaram são:
- detalhes da linguagem são detalhes. Não impedem nada ou tornam nada mais possível que antes. No máximo dão velocidade (RAD) mas não são impedimentos.
- a velocidade obtida por esses meios não compensa a longo prazo, pelo que, mesmo sendo mais RAD não é automáticamente uma boa escolha devido ao OS lock-in já que uma aplicação java nunca ficará obsuleta. Nunca terá que ser re-escrita quando a versão mudar. E isso, mesmo considerando apenas o windows (.NET vs java no windows apenas) ainda é uma vantagem estrondosa que mata qualquer uma vantagem de velocidade.
Ok, agora, se vc faz software de vida curta, sim. Ai vale a pena usar o .NET. Aplicações que são escritas para durar um ano ou dois.
Mas, na boa, fazer aplicações assim é se aproveitar dos clientes. Pois uma das qualidades dos sistemas é a longividade. se tem data para morrer, de que serviu o investimento ? O ROI para a empresa que faz o software é alto e o cliente que se f…
Não é um tipo de politica profissional que eu entendo nem pratico e tlv por isso não use o .NET… eu entendo que mercadologicamente falando existam pessoas usando dessa forma, não os censuro, mas não me venham dizer que .NET é melhor que Java. Ele é para um nicho. java é para qualquer coisa.
dito assim parece meu megalomano, mas o problema não é do java, e sim do uso do java (e até do .NET, ruby, etc) que é a falta de investimento em Plataformas de Aplicação (que o java não é)
Se vc tem uma plataforma de aplicação para o seu ramo de negocios vc consegue ser um Time to market mais pequeno ainda que fazendo drag-and-drop.