gildot

Topo
Sobre
FAQ
Tópicos
Autores
Preferências
Artigos
Sondagens
Propor artigo


8/3
gildicas
9/30
jobs
10/9
perguntas
10/25
press

 
RealBasic 2005: Um Visual Basic multi-plataforma!
Contribuído por scorpio em 20-03-06 22:31
do departamento development
News Alessandro de Oliveira Faria (CABELO) escreve "O RealBasic é uma interface RAD que permite obter produtividade e portabilidade do código entre plataformas GNU/Linux, Mac OS X e Windows 98, NT, ME, 2000 e XP. O único ponto franco deste pacote é não possuir o código aberto. Mas quem sabe a Realsoft não resolve abrir o código fonte do RealBasic para ter um futuro promissor. Na minha opinião, o RealBasic não deixa de ser uma alternativa na plataforma GNU/Linux para os programadores da linguagem Visual Basic. página "

Megamail regressa | Encontro Nacional da Sociedade Portuguesa de Matemática  >

 

gildot Login
Login:

Password:

Referências
  • Linux
  • Alessandro de Oliveira Faria (CABELO)
  • página
  • Mais acerca News
  • Também por scorpio
  • Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário.
    oximoro (Pontos:2)
    por slug em 21-03-06 1:25 GMT (#1)
    (Utilizador Info) http://aeminium.org/slug/
    programador + visual basic :-D

    mais vale perder(ganhar?) algum tempo a aprender python/C/C++ e usar a QT, wxwindows, gtk, etc...

    Re:oximoro (Pontos:2)
    por Specimen em 21-03-06 2:34 GMT (#4)
    (Utilizador Info)
    Ou .NET/C#/Mono.

    'In the future, the oppression will come in increasingly subtle forms'.

    Re:oximoro (Pontos:2)
    por slug em 21-03-06 3:08 GMT (#5)
    (Utilizador Info) http://aeminium.org/slug/
    nesse caso é mais perder tempo hehe. esqueci-me de mencionar o java
    Re:oximoro (Pontos:2)
    por fhc em 21-03-06 10:34 GMT (#6)
    (Utilizador Info)

    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.

    Re:oximoro (Pontos:1)
    por jac em 21-03-06 11:20 GMT (#8)
    (Utilizador Info)
    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
    Re:oximoro (Pontos:2)
    por fhc em 21-03-06 17:28 GMT (#9)
    (Utilizador Info)

    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.

    Re:oximoro (Pontos:2)
    por blacksheep em 21-03-06 19:19 GMT (#10)
    (Utilizador Info) http://rpmcruz.planetaclix.pt/
    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!
    Re:oximoro (Pontos:2)
    por raxx7 em 21-03-06 23:34 GMT (#12)
    (Utilizador Info)
    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++.


    Re:oximoro (Pontos:2)
    por fhc em 22-03-06 10:27 GMT (#13)
    (Utilizador Info)

    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.

    Re:oximoro (Pontos:2)
    por raxx7 em 22-03-06 20:11 GMT (#15)
    (Utilizador Info)

    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.


    Re:oximoro (Pontos:2)
    por fhc em 28-03-06 13:02 GMT (#16)
    (Utilizador Info)

    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.

    Re:oximoro (Pontos:2)
    por raxx7 em 28-03-06 21:51 GMT (#17)
    (Utilizador Info)
    Mas ... para que te serve a VM?

    Re:oximoro (Pontos:2)
    por fhc em 30-03-06 9:20 GMT (#19)
    (Utilizador Info)

    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.

    Re:oximoro (Pontos:2)
    por Specimen em 29-03-06 18:22 GMT (#18)
    (Utilizador Info)

    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'.

    Re:oximoro (Pontos:0)
    por tonidosimpostos em 21-03-06 22:09 GMT (#11)
    (Utilizador Info)
    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."
    Re:oximoro (Pontos:2)
    por fhc em 22-03-06 10:46 GMT (#14)
    (Utilizador Info)

    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.

    Eu não queria ser chato... (Pontos:2)
    por Specimen em 21-03-06 1:57 GMT (#2)
    (Utilizador Info)

    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'.

    Ugh... (Pontos:2)
    por Specimen em 21-03-06 2:09 GMT (#3)
    (Utilizador Info)

    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'.

    Re:Ugh... (Pontos:2)
    por fhc em 21-03-06 10:36 GMT (#7)
    (Utilizador Info)

    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.

     

     

    [ Topo | FAQ | Editores | Contacto ]