| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | programador + visual basic :-D mais vale perder(ganhar?) algum tempo a aprender python/C/C++ e usar a QT, wxwindows, gtk, etc...
|
| | | | | | Ou .NET/C#/Mono.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | nesse caso é mais perder tempo hehe. esqueci-me de mencionar o java
|
| | | | | Olha que já tive menos certezas do o mono ser perder tempo. Lá pelo facto de vir da MS o C# não quer dizer que seja bom ou mau. O Miguel de Icaza tem razão numa coisa: se a Microsoft resolver puxar patentes, tem o Java como prior art na maior parte das coisas. E temos um bom ambiente de programação, livre e aberto, se não tentarmos seguir a MS. É claro que gostaria de ter uma terceira solução, totalmente livre. O OGG/VORBIS é uma prova que uma solução livre se pode ir impondo no mercado. Prova: vejam em que formato estão os ficheiros de som e de vídeo na maioria dos jogos novos. Talvez parrot, talvez outra. No entanto, estamos circunscritos a .NET/mono ou Java. É esta a escolha no momento. Preferiria de algum modo Java, mas o controlo da Sun e a inexistência de uma verdadeira solução livre (gcj, kaffe e sablevm são irrelevantes) mostram que talvez a solução mono tenha virtudes endógenas e escondidas. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | Aí é que te enganas e parece que não estás atento.
o grupo apache está a realizar uma implementação totalmente open source do JDk
http://incubator.apache.org/harmony/
Está mais atento ;)
para além disso a SUN criou uma comunidade de individuos para contribuirem para o JDk da propria SUN
|
| | | | | Conheço o projecto, mas não me doa a cabeça até ele estar próximo do da Sun. O mono tem uma porrada de anos, e nasceu pouco depois da MS e não está nem próximo do .NET nem em desempenho nem em número de classes. Devia dizer que o harmony (que incidentalmente já tinha sido o nome de uma realização livre e entretanto falhada do QT) também é por enquanto irrelevante. Até porque Java em si é irrelevante (no que concerne à linguagem) para este assunto, pois falamos mormente de ambientes de execução. Lixe-se a linguagem, o que interessa é o runtime. Por outro lado quanto se aposta aqui que os próximos processadores terão suporte para instruções CLI e não JAVA? Não desprezeis o poder da Micosofre, muito embora menos de 15% do VISTA seja escrito em managed code. O maior problema do Java foi ligar à VM uma linguagem: sei bem que não tem de ser assim, infelizmente foi o que a Sun fez, e o resultado está à vista. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | harmony (que incidentalmente já tinha sido o nome de uma realização livre e entretanto falhada do QT)
Descontinuada é diferente de falhada. O projecto Harmony apenas tinha pouca razão de ser depois do Qt ter sido libertado sob GPL, e a fundação KDE Free Qt criada. Nos três meses do projecto, atingiram as 25.000 linhas, sendo previsto que pudesse substituir o Qt num ano.
Libertem a Fátima Felgueiras! |
| | | | Por outro lado quanto se aposta aqui que os próximos processadores terão suporte para instruções CLI e não JAVA? Não desprezeis o poder da Micosofre, muito embora menos de 15% do VISTA seja escrito em managed code. Algo como o Jazelle dos ARM? Não é provável. Este tipo de extensões só costumam valer a pena em processadores embebidos, de baixa performance. E o .NET está fora desse espaço. Nem a SUN tem extensões para JAVA nos UltraSPARC. O maior problema do Java foi ligar à VM uma linguagem: sei bem que não tem de ser assim, infelizmente foi o que a Sun fez, e o resultado está à vista. É relativo. O CLI não é o santo graal da ligação entre linguagens. Define uma infraestrutura para linguagens imperativas, orientadas a objectos e com garbage collecting e as linguagens têm que se adaptar a ela. Por exemplo, multiple inheritance do C++ (não é que vá sentir a sua falta) foi à vida no managed C++. E IIRC, não é possivel escrever uma class .NET em IronPython que possa ser utilizada nas outras linguagens.
O C# é a realização máxima dessa infraestrutura e não é muito diferente do Java. O VB.NET e o managed C++ apenas capitalizam na familiaridade que as pessoas já possam ter com VB e C++.
|
| | | | | Não me entendam mal. O que quero dizer não é que o CLI é a descoberta da fusaão fria nas TI. De maneira nenhuma. Como disse antes, até preferia que tivesse sido a VM java a ganhar a corrida. No entanto, o controlo excessivo da Sun sobre a VM (por um lado) e a ligação da VM (por marqueteiros, e não por necessidade) a uma linguagem fez o que fez. Consideremos a promessa do Java (disclaimer: fiz o primeiro projecto de Java com mais de 5000 linhas de código em 95-96, fora JDK, no tempo em que Java só era usado para applets, e que tinha de dar o feedback para os engenheiros da Sun da performance do compilador). A promessa do Java sempre foi o Desktop. Ora, a ligação com a Microsoft relegou-a ao obscurantismo do data-center, onde irá lenta mas progressivamente ser substituída pelo .NET (a facada da MS na Sun) e pelo LAMP. Queiramos ou não, a VM Java só tem duas soluções: ou se abre, tipo OpenOffice, ou será como o Manuel Monteiro: irrelevante. A comunidade Open Source tem três hipóteses: ou se rende à Sun Microsystems, que nunca normalizou o JAVA, ou se rende a uma VM (VM, não linguagem) da ECMA --- CLI ---, ou cria outra. Na minha opinião, consideraria estas hióteses da última para a primeira. Seria Parrot uma solução? Não sei. Não conheço suficientemente o Parrot para o dizer. Continuo no entanto a dizer isto: o OGG/VORBIS é para mim a prova viva de que um padrão livre pode ser adoptado pela indústria, com benefícios para todos. Se houver uma VM rápida o suficiente para correr jogos e aplicações, e agnóstica no que tende a linguagens, acredito que a indústria se converteria a ela. Há uma vantagem no Java e na sua VM: O código da SUSI ainda corre sem recompilação. O problema para mim, portanto, não reside na linguagem, que é substituível, mas na VM, que deveria ser o núcleo das nossas preocupações. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | | IMHO, acho que sobrevalorizas o valor da VM no .NET No Java tens uma linguagem sã e portável e um conjunto de bibliotecas mais ou menos sãs mas igualmente portáveis, através de arquitecturas e sistemas operativos. Isto permite efectivamente escrever código uma vez e correr numa grande diversidade de plataformas. O facto de ser baseado em VM é a cereja no topo do bolo. Write once, compile once, _distribute once_, run everywhere. No .NET, o CLI e o C# são standards da ECMA, mas as bibliotecas não são. Tens as .NET para Windows, as do projecto Mono para Unix.
Write once.. run in Windows. No fundo, é apenas mais uma iteração das ferramentas de desenvolvimento da MS. O facto de ser baseado em VM é útil, mas não faz muita diferença. Quanto à normalização do Java, também é relativo. A SUN não é uma organização independente como a ECMA ou o ISO, mas a especificação do Java está disponivel e a SUN tem feito um bom trabalho a não lixar ninguém. O Postscript também não é de nenhuma organização independente (é da Adobe) e ninguém se queixa de ser um elemento fulcral na impressão em Unix.
O problema da comunidade Open Source e especificação do Java é que a SUN impõe algumas cláusulas sobre a distribuição de implementações que não cumpram as especificações que chocam com o modelo de desenvolvimento Open Source. O lado positivo deste controlo todo é que tem permitido à SUN evitar o "embrace, extend and exempt" que arruinou tantas outras tentativas de criar plataformas portáveis. Ou já nos esquecemos das ideias da MS para o Java há uns anos? Acho que o que vai acontecer é rigorosamente nada. Em geral, quem desenvolvia para Windows vai continuar a desenvolver para Windows, quem desenvolvia para Unix vai continuar a desenvolver para Unix e quem desenvolvia para Java vai continuar a desenvolver para Java.
|
| | | | | Mais uma vez, falo da máquina e não das bibliotecas. Até estou a usar a stack do mono e GTK# na minha experiência. Só isso, 'System.Console', 'System.Collections' e mais nada. E estou impressionado, mesmo sabendo que o Mono tem muito para andar em termos de desempenho e de bibliotecas. Estou-me a borrifar neste momento para as bibliotecas. Quero uma VM rápida, segura e que possa inspeccionar e modificar se necessário. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | Mas ... para que te serve a VM?
|
| | | | | A VM é o início. As bibliotecas vêm a seguir. Se o Parrot for bom para correr perl, python, java ou mesmo C, as bibliotecas estão lá todas. O ideal seria uma VM tal que pudesse compilar para ela a partir do gcc (C, C++, Java)... e com python realizado lá. O CLI já é um início. Na verdade, nem de linguagens falo, pois uso C (não C++) e python com muito gosto. Mas gostaria de mudar para python + C + linguagem compilada de mais alto nível para os meus próximos projectos de interfaces no PC dos meus sistemas embutidos. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | | Se há sitio onde a Sun falhou no Java foi na optimização do desempenho do Runtime Enviroment (ou VM se preferirem). O Java conquistou a fama de ser lento, pois se não a tivesse não haveria hoje lugar para o .NET ou o AJAX (verdade seja dita, o que se faz com o JS em AJAX está para além das vocações e intenções desta linguagem). O .NET se tem espaço para progredir é porque o Java ainda tem muitas falhas, limitações e coisas irritantes. No fundo, o .NET é uma crítica ao Java, e em certos pontos é uma crítica muito legítima.
O AJAX é um bicho que anda a fazer coisas que muitas delas são mais simples de implementar em JAVA, e o JS e o Java são praticamente tão ubiquos um como o outro (ao contrário do .NET). Qual é a vantagem do JS então? A rapidez, e a facilidade para o utilizador, it just works.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | O mercado do OGG/Vorbis são os jogos ? Xeeeeeee patrom ! Eu a julgar que era um formato para replace o MP3 ! Nem sempre o que é tecnicamente melhor é aquilo que se impoe :) O MP3 está ai para dar e durar. Quem se importa com mais ou menos bitrate, mais ou menos tamanho, quando a capacidade de armazenamento está a aumentar a cada dia que passa ? A malta quer é ouvir música, com mais ou menos qualidade.
"The fanatical element among our customer base hasn't done us any favors." |
| | | | | Não disse que eram os o mercado (seja o que isso for) do OGG/VORBIS eram os jogos. Lá estás tu a provar um ponto através de colocar palavras que não disse. Disse que os novos jogos tinhas os ficheiros em OGG, o que não é exclusivo de outras aplicações. O Ogg é para mim a prova de que padrões livres se irão adoptar solidamente. A bagagem que já existe em MP3 será decerto predominante nos próximos anos. Ninguém disse o contrário. No entanto, as firmas que não queiram royalties ao Fraunhoffer Institute terão que desenvolver o seu próprio formato ou adoptar um. O OGG/VORBIS está no topo da lista de formatos livres adoptáveis. Já é suportado pela maioria das aplicações de leitura de media. É pervasivo já hoje em diversos sites. Nestas coisas, a adopção vem de cima para baixo. Se os que desenvolvem o adoptarem, a «malta» irá adoptá-lo mais cedo ou mais tarde. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| | | | | Mas acho que o link no artigo devia apontar para a página do RealBasic, e não para um artigo escrito pelo poster, isto assim dá a sensação que o dito está mais interessado é em fazer publicidade ao seu site, não que isso seja mau em si, mas nesse caso eu acho que devia indicar no artigo que o link é para outro artigo do mesmo autor, qualquer coisa do género: "Se você quiser ficar sabendo mais pormenor disso aí, continue lendo o artigo em meu sitio". Ainda porcima no artigo a que o artigo remete para, o único link existente é para a página de downloads do Realbasic De qualquer forma, quem quiser aceder ao site do RealBasic carregue aqui.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | | Depois de me dar ao trabalho de explorar o site do RealBasic chego à conclusão que existe uma versão paga e outra que é de graça mas é crippleware da versão paga. O que significa entre muita coisa, que a 'esperança' do "(CABELO)" de abrirem o código é vã, a não ser que e uma Novell ou Red Hat os comprasse. Por outras palavras, esqueçam, aqui não a nada para ver, circulem.
'In the future, the oppression will come in increasingly subtle forms'. |
| | | | | | | Procurem gambas nos pacotes das vossas distribuições de Linux. Ouvi falar muito bem disso. Francisco Colaço
Quem não faz, ensina; quem não faz nem ensina, faz metodologia. Quem não faz nem ensina nem faz metodologia, faz futurologia. |
| |
|
