| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | | Para começar, quero dizer que o Mono ainda não corre a 100% em todas essas plataformas que indicaste, sendo que o Linux deve ser a mais suportada e com menos problemas. E por outro lado a Novel (que está por detrás do Mono), escolheu como IDE de trabalho o Eclipse e não o MonoDevelop. Como disseste, o Eclipse já leva outro andamento nas pernas. Por outro lado, ninguém do Mono anda a falar do "build once, run everywhere"... Eu pessoalmente acho que isso é muito complicado de se ter. Quanto ao tema: "O que é melhor para fazer o quê?", acho que isso depende de muitos factores. Tu vens de um passado Java, é natural que prefiras o SWT+Java. Outras pessoas preferem GTK+Python, outras linguagens nativas... acho que, no fundo, mais importante que "Qual a melhor para desenvolvimento" é "Qual aquela em que eu estou mais à vontade para desenvolver". Eu não vou dizer que a X é melhor que a Y, depende tudo da equipa de desenvolvimento e de muitos factores. Uma coisa que me fez confusão há algum tempo, foi na empresa onde eu trabalho, os chefes terem contratado uma equipa de outra empresa. Esta equipa trabalhava em Java, são uns prós em Java e têm muita experiência em Java. Contudo, a empresa tem parceria com a MS, e fica bem é ter produtos em .NET. Ou seja, toda a equipa vai trabalhar em .NET. Isto é só um exemplo em como a escolha da tecnologia sem ter em conta o factor humano pode ser um erro crasso. Do Java para o .NET, não é um salto, nem pouco mais ou menos. Digo isto porque um dos meus colegas também veio do Java... Não tamos aqui a falar da linguagem, mas da arquitectura da plataforma. Passar do Java para o .NET é ter de aprender toda uma plataforma nova. Sob o meu ponto de vista, a empresa está a desperdiçar uma equipa que iria render muito mais trabalhando em Java. Mas se eles fossem para Python, era a mesma coisa... Isto tudo para dizer que estas guerras de A versus C já cansam... Java ou .NET ou Python, no fundo são todas boas, e cada um tem é de usar aquela que gosta mais.
____________________
Pedro Santos :: psantos.net |
| | | | | | <chiunf><chiunf> Não sentes o cheiro a hype? Pois eu sinto e foi só por isso que enviei o artigo. Já tivemos esta discussão uma vez e o ponto de vista é comum: tudo depende da experiência. Só que há já algum tempo que se fala do Mono this and Mono that. Ah, e na discussão do mono há sempre alguém a bater no ceguinho (Java) porque é demasiado complicado e blá blá blá. E as aplicações SWING são lentas e blá blá blá.
Hey, alguém se preocupa em ver se existe algum outro toolkit? O artigo é explicitamente sobre Mono+GTK# e Java+SWT, não é Java vs Mono Reloaded. É sobre aplicações gráficas.
Fala-se bastante deste assunto neste momento, porque básicamente desenvolver aplicações em C/C++ pode ser terrívelmente moroso e não compensar, daí olha-se para qualquer coisa que seja RAD.
Quem olha para o que tem sido dito sobre o Mono fica naquela: "ah pois é, esta coisa do Mono+GTK#/Gnome# é que é excelente para fazer aplicações" mas parece que se esquecem de que há algo muito melhor que isso só que é para Java e é o SWT.
E passar do Java para o C# *foi* um pulo, talvez o IDE tenha ajudado bastante à festa, mas foi um pulo.
---
Este espaço pode ser seu! |
| | | | Do Java para o .NET, não é um salto, nem pouco mais ou menos.
Não concordo. Saltar do Java para Python, C++, .NET (C#) não é nada difícil. Digo isto porque não me foi complicado saltar do C++ para Java, nem do Java para Python. Todas estas linguagens têm fortes semelhanças e quem tenha conhecimentos de base como deve ser (i.e. não seja apenas um curioso ou um paraquedista) não terá dificuldade em adaptar-se. Normalmente uma semana ou menos é suficiente.
Vou arriscar aqui e dizer que estás a confundir tarefas com a plataforma/linguagem. É claro que não é assim tão fácil saltar de um Java onde se faziam umas coisas gráficas para um .NET onde se vai fazer webservices (por exemplo). Mas o grau de dificuldade é equivalente a saltar para os webservices mesmo na plataforma Java, porque a dificuldade está na tarefa e não na plataforma.
-- Carlos Rodrigues
|
| | | | | Lol, se tu concordasses com o que eu digo, aí é que eu me admirava! ;-) Naturalmente eu falava de Java e .NET e não Linguagem Java e C#. O meu colega que já tem muitos anos disto, que fazia páginas em Java, agora está a fazer páginas em ASP .NET. Ele programar, programa bem. Mas sabe toda a estrutura das páginas? Como são processadas? Os eventos? Como os controlos interagem com as páginas? Onde pode ir buscar informações sobre o pedido, etc, etc, etc. Isto não se aprende numa semana. Eu duvido muito que, com uma semana a dar uma vista de olhos ao Python, conseguisse fazer uma aplicação a sério e tirar todo o partido da linguagem/plataforma.
____________________
Pedro Santos :: psantos.net |
| | | | Lol, se tu concordasses com o que eu digo, aí é que eu me admirava! ;-)
Não ando aqui para fazer posts "me too" a dar palmadinhas nas costas do pessoal. Se concordasse não respondia (o que acontece muitas vezes, FYI).
Mas sabe toda a estrutura das páginas? Como são processadas? Os eventos? Como os controlos interagem com as páginas? Onde pode ir buscar informações sobre o pedido, etc, etc, etc. Isto não se aprende numa semana. Eu duvido muito que, com uma semana a dar uma vista de olhos ao Python, conseguisse fazer uma aplicação a sério e tirar todo o partido da linguagem/plataforma.
Ó tu de pouca fé! É claro que numa semana não se aprende tudo o que há a aprender, mas aprende-se o suficiente para fazer o trabalho como deve ser. As plataformas nunca são assim tão diferentes, sejam quais forem as que escolheres para comparar (excepto Java/Prolog ou C/LISP, como é óbvio). A documentação existe para alguma coisa, e é para ser consultada. Saber fazer uso correcto dela também é algo que não está ao alcance dos curiosos, mas está perfeitamente ao alcance de um estudante universitário como tu, que é suposto conhecer suficientemente bem os conceitos por trás destas plataformas para não se deixar intimidar.
Só quando se mergulha de cabeça é que se descobre que afinal a transição nem é nada complicada. O factor psicológico do desconhecido é que provoca essa sensação de que vai ser complicado. Mas também acho que não estás suficientemente à vontade com Java (da mesma forma que eu não estou com .NET) e daí a tua desconfiança. Se um dia tiveres que saltar para um projecto a sério em Jave vai ver que te habituas rapidamente (e se for em Python será a mesma coisa).
-- Carlos Rodrigues
|
| | | | SWT já é nativo de Java? eu tentei .. mas n tenho tempo para estar a desenhar SWT à la pata, glade is so more easy and quick! subscrevo tudo o q o pre disse, e acho q foste bastante precipitado nas tuas "declarações", tendo em conta que a equipa do Mono não utilizou expressões que tu indicaste como sendo deles ou de outros ligados directamente ao mono. Não esqueçamos uma coisa meu amigo ... Mono é uma implementação livre do .NET, n serve so para aplicações stand-alone!! aliás, é mt mais virado para outros lados .. como os webservices, por exemplo.
After all, we're all alike! |
| | | | | | o eclipse tem plugins para desenhar GUIs com SWING OU SWT, existindo um Livre da IBM (AUML, ou assim uma coisa).
-----
Quem quiser ajudar à conversão a Slackware e FreeBSD, que esteja à vontade. |
| | | | | Por tudo isto, não percebo porque é que ninguém se parece interessar no SWT para criar aplicações com GUI, rápidamente e que sejam cross-platform. é simples perceber porquê, não funciona bem :) quando tentei usar o SWT, no Windows havia para lá umas coisas que funcionavam, no GTK começava a estoirar com uns erros de GTK e com o Motif haviam para lá umas coisas que não mostravam bem.. por outros palavras, problemas diferentes em plataformas diferentes... não estou para arriscar isso, prefiro o SWING
|
| | | | | | hmmm pois eu não tive problemas nenhuns :\ Aliás, o maior e melhor exemplo é o Eclipse itself.
---
Este espaço pode ser seu! |
| | | | Este hype em redor do Mono já cansa. De um lado estão os tipos que gostam de afirmar que vai permitir interoperabilidade com o .NET da Microsoft, o que é bullshit pura, só se em Windows se escusarem a usar funcionalidade que só a Microsoft disponibiliza, o que não vai acontecer (o P/Invoke é demasiado atraente e as Windows.Forms não são nem nunca vão ser suportadas de forma satisfatória pelo Mono -- o WINE não é uma solução satisfatória).
De outro estão os tipos que querem promover o Mono como a plataforma por excelência em Linux. Ora eu sou tão a favor dos RADs como qualquer outro, mas não aceito a sua utilização generalizada. Não me apetece transformar o meu Athlon 2400 no meu antigo P3 450. Além do mais esta ideia de usar RADs para aplicações desktop provoca-me calafrios.
Para mim um RAD é para fazer aplicações simples rapidamente, e aí eu prefiro o Python. Para aplicações duradouras (browsers, editores de imagem, etc. e tal) o C/C++ ainda não tem rival, pois oferece performance e o tempo extra que se perde (que pode ser amortizado com ferramentas tipo Qt Designer) acaba por compensar no final.
Mas entrando no tópico do artigo, não me agrada a ideia de fazer aplicações em Mono/GTK#, acho que era preferível que as distribuições passassem de uma vez por todas a trazer o gtkmm para os críticos do C se calarem e poderem finalmente fazer coisas em GTK/C++ sabendo que podem correr em todo o lado. Além do mais é mais uma plataforma para somar às que já existem e que servem os mesmos propósitos (como o Python ou mesmo Java, que toda a gente tem instalado por causa do plugin). Por outro lado também não é multiplataforma, o GTK ainda não corre decentemente em Windows, não é suportado no .NET da Microsoft (AFAIK).
Quanto ao Java/SWT, o panorama não melhora no que respeita à performance mas melhora em relação à portabilidade. O JRE está disponível numa série de plataformas e é verdadeiramente write-once/run-anywhere (por mais que os seus detractores o neguem). Mas mesmo assim não estou bem convicto das vantagens do SWT. É mais rápido mas menos portável, e ser implementado sobre toolkits diferentes em plataformas diferentes torna-o manhoso para quem quer ter uma interface consistente em todas as plataformas. Deste ponto de vista prefiro o Swing (puro, e não aquela treta sobre GTK que funciona mal como o caraças). Acredito que o Java/SWT tenha o seu lugar (o Eclipse em Swing era capaz de ser muito lento), tal como o terá o Mono/GTK#, mas até hoje, de todos os projectos que já me passaram pela cabeça, ainda não me ocorreu nenhum em que o modelo SWT/GTK# me agradasse. Ou se é totalmente multiplataforma e se usa Java com Swing ou se é nativo e se usa Qt/GTK (Qt também é nativo em Windows, portanto...). Para ficar sem ser carne nem peixe prefiro o Python.
-- Carlos Rodrigues
|
| | | | | | | Nota, que as SWF já não vão usar o Wine, pelo menos totalmente. JRE está disponível numa série de plataformas e é verdadeiramente write-once/run-anywhere (por mais que os seus detractores o neguem). Mentira! Desde quando é que uma plataforma/linguagem por si só faz com que os programas corram em todo o lado? Se os programadores não tiverem consciência de certos pormenores, nunca uma aplicação Java vai correr em todo o lado. Para aplicações maiorzitas, as coisas não são assim tão lineares. Eu da primeira vez que instalei o Linux, foi logo por a correr um trabalho que fiz em Java, e aquilo deu excepções por todos os lados. Até em código da plataforma! Eu chamava um FileDialog ou lá como se chamava, e carregasse onde carregasse levava com uma excepção.
____________________
Pedro Santos :: psantos.net |
| | | | Se deu caca é porque estavas a fazer qualquer coisa mal... ou então o resto do mundo tem muita sorte...
---
Este espaço pode ser seu! |
| | | | | Naturalmente que a culpa é minha, não quis implicar o contrário. Mas nota o facto de ter desenvolvido a aplicação sempre no Windows, nunca ter experimentado no Linux, e da primeira vez, naturalmente, que dá bronca. Ou seja, não é compilar uma vez e já está, é ir compilando aqui e acolá e fazendo os ajustes. Tal como eu tou a fazer no meu trabalho final. Penso que devemos ter gasto à vontade 20% do tempo de desenvolvimento com pormenores multiplataforma. Nota que a aplicação funcionava lindamente em Windows...
____________________
Pedro Santos :: psantos.net |
| | | | Repito a ideia inicial: estás a fazer qualquer coisa muito mal...
---
Este espaço pode ser seu! |
| | | | | Então estás a dizer-me que eras capaz de fazer um projecto enorme... por exemplo de 3 anos, sempre a desenvolver no Windows, com muito IO, muitas coisas, e ao fim de 3 anos ias correr isso no Linux, no Solaris, etc, e dava *exactamente* igual e sem problemas? Por experiência própria: duvido. Imagina que nesse projecto de 3 anos tinhas um programador, que usava sempre '\' nos path's. Não ia funcionar! Este deve ser o pormenor anti-multiplataforma mais directo. Como este, há outros mais subtis.
____________________
Pedro Santos :: psantos.net |
| | | | Epá, até eu que não corro nada em Windows uso o os.path (eu desenvolvo principalmente em python) para me garantir que esse tipo de erros não ocorre, que programador razoável é que faz um projecto que sabe ser multiplataforma e não se preocupa com este tipo de coisas?
Para além deste erro básico, práticamente só em system calls (algo que tento sempre evitar fazer não só por arruinar as possibilidades de a aplicação ser multiplataforma como pelo facto de começar um novo processo, que é pesado) é que se pôe este problema, mas isso é (quase) sempre evitável.
Se precisas de importar módulos exclusivos de um sistema, então é porque estás a fazer uma aplicação especifica para uma plataforma o que automáticamente anula a necessidade de preocupação com este tipo de coisa.
"Para mim a tecnologia é como as tangerinas, na medida em que não consigo fazer uma analogia decente sobre nenhuma das duas neste momento" Scott Adams |
| | | | Era um exemplo simples, para mostrar que não é assim tão linear. Mas ok, se vocês juram a pés juntos que não há problemas relacionados com multiplataforma em Java, eu não me vou pronunciar, porque não programo em Java há muito tempo. Mas apostava que 3 anos a desenvolver só numa plataforma... levava-se para outra e ia dar problemas. Eu não falo de algoritmos e código, falo da interacção com o sistema operativo, que há sempre, nem que seja só por ficheiros, paths, dirs, etc. Mas hey, não digo mais nada. Já cá não está quem falou. :-)
____________________
Pedro Santos :: psantos.net |
| | | | Como eu te disse noutro lado, mostra-me código Java que não funcione em todas as plataformas e que, obviamente, não seja in-your-face específico de um sistema. Se quiseres manda-me por mail, sem me mostrares um exemplo concreto eu não vou contrariar aquilo que até aqui tem sido a minha experiência.
-- Carlos Rodrigues
|
| | | | hmmm aconselho-te urgentemente a dar uma vista de olhos no System.getProperties.
---
Este espaço pode ser seu! |
| | | | Eu já fiz montes de coisas em Java e tudo corria sem qualquer sobressalto em Linux e Windows. E isto sem andar a pensar em pormenores. É claro que há forma de quebrar a portabilidade, mas é complicado. Quanto ao teu programa, só vendo... (se me quiseres enviar o código está à vontade).
-- Carlos Rodrigues
|
| | | | a questão não é se é possível fazer, a questão é que dá muito trabalho e não é tão linear e básico como a SUN fez crer. Aliás, pelo que leio, "compile once run anywhere" é um mito, por muito que se tente. não não tenho provas, é o que leio.
-----
Quem quiser ajudar à conversão a Slackware e FreeBSD, que esteja à vontade. |
| | | | Eu discordo. Até hoje não tive problemas em correr todas as coisas que fiz em Java, tanto em Linux como em Windows. E também não tenho tido problemas com aplicações de terceiros. Só há problemas com aplicações Java que foram pensadas para a VM da Microsoft (relacionadas com a API?).
Quanto ao compile-once/run-anywhere, o compilador é o mesmo em todas as plataformas (obviamente com algumas diferenças lá por dentro, mas gera o mesmo código) portanto não estou a ver o problema.
-- Carlos Rodrigues
|
| | | | a minha rotina diária no trabalho: desenvolver em windows+websphere+whatever!!.. (pls, não me atirem pedras, não tenho escolha!), testar, e transferir os .class para um AS400 perdido algures no edifício para testes de pré-produção... é certo que são essencialmente serviços e afins, sem componentes visuais.. mas para o que eu faço, é linear!
Plexar. |
| | | | hmmm espera que estás a fazer confusão com uma pequena coisa: o interface do SWT mantêm-se através dos vários toolkits. A diferença é que usando o toolkit GTK tens o L&F Gtk, usando o QT tens o L&F de um QT, etc. A coisa funciona +/- como um Skin, não é necessário alterar uma linha de código.
Com o Mono, a conversa já não é bem esta.
---
Este espaço pode ser seu! |
| | | | Não estou a fazer confusão. O que eu disse, por outras palavras, é que com Swing sabes que em qualquer plataforma a tua aplicação vai ter o mesmo aspecto, exactamente o mesmo aspecto. Mesmo a nova skin "Ocean" para o Swing mantém todos os widgets com propriedades idênticas às do clássico "Metal". Isto é muito importante quando se está a desenvolver uma aplicação que poderá correr em plataformas não testadas. O Swing com GTK é um bom contra exemplo, as coisas ficam diferentes e muitas vezes um interface bom fica completamente desfigurado.
-- Carlos Rodrigues
|
| | | | ah ok... então de facto o SWT não é para ti :) O SWT tem a vantagem de fazer com que uma aplicação que a correr no Gnome com o binding do GTK se pareça com qualquer outra aplicação GTK ao invés de um alien que ali foi parar.
---
Este espaço pode ser seu! |
| | | | Não estou a dizer que renegue o SWT, mas é algo que tenha muita vontade de usar. Mas no entanto uso frequentemente o Azureus que é SWT e acho que faz (o SWT) um bom trabalho de integração com o ambiente (ao contrário do que acontece com o Swing/GTK).
-- Carlos Rodrigues
|
| | | | "interoperabilidade com o .NET da Microsoft, o que é bullshit pura, só se em Windows se escusarem a usar funcionalidade que só a Microsoft disponibiliza, o que não vai acontecer"
e quem quer usar o Windows.Form? Pelo que leio, aquilo é o pior toolkit alguma vez inventado em termos de arquitectura...
A ideia do Mono é expandir a plataforma, não é andar a seguir a MS.
"Não me apetece transformar o meu Athlon 2400 no meu antigo P3 450. "
Para quem programa tanto em Java, escusavas de dizer disparates destes. Linguages interpretadas não precisam de ser lentas, desde que tenham um JIT que consiga optimizar coisas que um compilador não optimize. Tem é que gravar a classe optimizada para disco... (digo eu, alguém sabe se alguém faz isto?)
"Para mim um RAD é para fazer aplicações simples rapidamente, e aí eu prefiro o Python."
Cada um tem direito às suas preferências... tens consciência que a imagem também vale muito?
"Para aplicações duradouras (browsers, editores de imagem, etc. e tal) o C/C++ ainda não tem rival, pois oferece performance e o tempo extra que se perde (que pode ser amortizado com ferramentas tipo Qt Designer) acaba por compensar no final."
Para aplicações de desktop, queres tu dizer. É que há muita empresa que tem grande parte dos sistemas a correr JAVA, não me parece que não os consideram duradouros.
Perder tempo a desenvolver em c, com uma complexidade muito maior quando temos processadores a 3GHZ é muitas vezes um autêntico desperdicio de recursos. Além de que é necessário saber muitos mais truques e coisas a evitar em linguagens de baixo nível (IMO).
Quanto às vantagens de Mono... bem, é livre. Pode ter as vantagens que quiseres, desde que desenvolvas ou pagues para desenvolver... não é isso que dizemos tão bem do software livre?
Simplesmente acho que estás a dizer que não queres porque já tens algo que funciona para ti, e não queres reiventar a roda. Ora, não te esqueças que alguém se lembrou de inventar pneus... ou seja, é sempre possível melhorar, e olha que os problemas de Java não são muito levezinhos...
-----
Quem quiser ajudar à conversão a Slackware e FreeBSD, que esteja à vontade. |
| | | | e quem quer usar o Windows.Form? Pelo que leio, aquilo é o pior toolkit alguma vez inventado em termos de arquitectura...
Já alguma vez programaste com Win32? Se sim pergunta-te como é que aquilo conseguiu sobreviver até hoje. Nem sempre é uma questão do que é melhor, o Windows.Forms é o standard no .NET da Microsoft e é isso que vai vingar, goste-se ou não.
Quanto ao expandir a plataforma, neste ponto eu concordo, e apoiaria, mas apenas se abandonassem todo e qualquer esforço para seguir a implementação da Microsoft (fora as característcas do C# e o que está definido no standard ECMA). O esforço de implementar coisas como as Windows.Forms só mostram que na realidade eles também não acreditam muito nisso e estão, em parte, numa de seguidismo. Mesmo que não fosse, é esta a ideia que a esmagadora maioria da pessoas tem, que o Mono quer expandir mas tentar seguir o MS.NET ao mesmo tempo, e é por isso que é tão pernicioso. Porque a Microsoft vai sempre fazer um melhor trabalho de expansão da plataforma (afinal é deles e partiram com vantagem) e o Mono vai andar sempre atrás deles.
Para quem programa tanto em Java, escusavas de dizer disparates destes. Linguages interpretadas não precisam de ser lentas, desde que tenham um JIT que consiga optimizar coisas que um compilador não optimize. Tem é que gravar a classe optimizada para disco... (digo eu, alguém sabe se alguém faz isto?)
A interpretação de bytecodes impõe sempre uma penalização, mesmo com JIT. Só em aplicações que se mantêm em execução durante longos períodos de tempo é que a análise run-time do programa pode amortizar essa penalização (e em alguns casos até superar programas nativos). Isto não acontece no caso das aplicações desktop, que normalmente têm ciclos de execução curtos.
Mas não digo que o Java (ou o .NET) seja inadequado ou genericamente lento para aplicações desktop, o que acontece é que é necessário pesar as razões porque se quer fazer em Java ou .NET e não entrar numa de que os CPUs actuais são poderosos e os ciclos são para desperdiçar. O overhead de uma ou outra aplicação aguenta-se bem se houver razões para isso, mas multiplica isso por um valor maior e começas a ver que afinal os ciclos de CPU ainda são preciosos.
Quanto a gravar a classe optimizada. Bem, por um lado isso derrota todo o propósito dos bytecodes, mas por outro pode ser útil se se usar caching. O gcj compila para código nativo mas até agora não se observam grandes vantagens nisso (em aplicações desktop é capaz de ter) e o .NET da Microsoft também faz uma espécie de caching. Verdade seja dita que aqui o .NET tem vantagem pois os bytecodes estão mais próximos do código original, facilitando optimizações estáticas que beneficiam no desktop. Por outro lado o Java é mais baixo-nível, o que se não facilita a optimização dinâmica (que beneficia aplicações com longos ciclos de execução), pelo menos não a penaliza e não complica a VM.
Cada um tem direito às suas preferências... tens consciência que a imagem também vale muito?
Não percebi essa da imagem. É por o Python não ter peso na indústria?
Para aplicações de desktop, queres tu dizer. É que há muita empresa que tem grande parte dos sistemas a correr JAVA, não me parece que não os consideram duradouros.
Quando falei em duradouros falava em aplicações que vão sofrer uma evolução gradual ao logo do tempo e cujas tarefas não são leves computacionalmente. No que dizes em relação às empresas, é verdade e já falei sobre isso acima.
Mas atenção, é preciso saber diferenciar as aplicações desktop daquelas aplicações business que vão correr praticamente sozinhas nas máquinas. Uma aplicação dessas em Python em principio poderia roer até ao último ciclo de CPU se isso facilitar o tempo de desenvolvimento, mas isto porque não irá penalizar o restante uso da máquina.
Perder tempo a desenvolver em c, com uma complexidade muito maior quando temos processadores a 3GHZ é muitas vezes um autêntico desperdicio de recursos. Além de que é necessário saber muitos mais truques e coisas a evitar em linguagens de baixo nível (IMO).
Em muitas aplicações a complexidade não é assim tão "maior". E tudo depende do tipo de aplicação, como já disse. Se estás a fazer um editor de imagem, a complexidade é semelhante quer faças em Java ou C++, porque é o problema que é complicado e não a programação. Mas chateia esta onda de querer deitar RAD em cima de tudo o que mexe.
Quanto aos 3GHz, isso é algo que me irrita sobejamente. Nem toda a gente tem máquinas topo de gama nem os ciclos de um CPU são para ser comidos por uma única aplicação. Achas que o pessoal anda aí a optimizar subsistemas VM e a fazer malabarismos para aumentar a performance das máquinas por serem masoquistas? Deitar ciclos fora sem razões para isso é ser completamente alheio à noção de que um computador não é normalmente usado para apenas uma tarefa e á noção de que os tempos de resposta são extremamente importantes para a "felicidade" dos utilizadores.
Quanto às vantagens de Mono... bem, é livre. Pode ter as vantagens que quiseres, desde que desenvolvas ou pagues para desenvolver... não é isso que dizemos tão bem do software livre?
Ser livre ou não é irrelevante quando até agora só tem servido para dar credibilidade aos instrumentos de lock-in de certas empresas, sem com isso trazer benefícios reais, apenas muito hype e promessas que não acredito que sejam cumpridas.
-- Carlos Rodrigues
|
| | | | sim, não vais ler isto... *shrug*...
o Windows.Forms tem q ser implementado para ser fácil fazer a conversão de .NET para Mono... não tem q ser perfeita, e por isso é q vao usar o Wine, é para o desenrascanço... aí eles concordam ctg :)
Eu tb n estava a falar de compilar a classe, mas sim as optimizações feitas, ou o tal caching que afirmas que há em .NET. Parece-me o ideal.
Porquê usar Java/.NET/Mono? Porque perder anos a desenvolver aplicações já não é muito viável...
>>Cada um tem direito às suas preferências... tens consciência que a imagem também vale muito?
>Não percebi essa da imagem. É por o Python não ter peso na indústria?
Claro que é. Adoro o q vi de python, mas sem apoio "pesado", não vai deixar de ser um nicho. ou isso ou ganha alguns programadores a Perl ;)
De facto em Python é fácil usar extensões em C por motivos de velocidade. Java nem por isso, e .NET talvez melhor q java ?
Pah, gosto de RAD :P à medida que os computadores se tornam uma comodidade, o mais importante é as coisas aparecem rápido e para o fim que é proposto. IMHO... agora, eu não considero a complexidade igual, em Java/Python/C#... podes organizar as coisas em objectos limpinhos, encapsulados, e apanhar qualquer erro com um try/catch, sem repetir sempre as mesmas linhas de código.
Anyway, IMO tem muito para dar dependendo de como aproveitam... a ver
-----
Quem quiser ajudar à conversão a Slackware e FreeBSD, que esteja à vontade. |
| | | | (...) em que toda a gente fala do Mono como se se tratasse da melhor solução para construir aplicações cross-platform.
Penso que esta afirmação não é de perto nem de longe a mais feliz do teu artigo.
O Mono não pretende ser nem a pior nem a melhor solução para construir aplicações Cross-Platform, mas sim, mais uma solução com as suas vantagens e desvantagens.
O Mono surge num momento de guerra entre a o que é proprietário e o que não é proprietário que é claramente encabeçada pela Micro$oft contra o movimento de Software Livre.
Mesmo com esta guerra, penso que a Micro$oft não anda a fazer nada sem pensar duas vezes e sem tirar alguma proveito disso.
Esta polémica toda á volta do software livre copiar o que é proprietário, juntamente com o acontecimentos mais recentes levam a pensar que isto tudo está a ser uma conspiração à escala mundial (eehhehe estou a ser dramático nas palavras claro), pois, se n
ao vejamos:
- A Micro$oft muda de uma forma categórica a estratégia de plataforma de desenvolvimento para uma onde o C é mais predominante.
- Nos exemplos da MSDN a sequência de código é normalmente C#, VB e C++ onde antigamente era somente VBasic.
- À linguagem C foi dada as possibilidade de gestão de interfaces que no VBasic foi um sucesso.
- Incentivo da M$ a foruns sobre C#
- Associação à SCO para criar falsas acusações na comunidade OpenSource sobre roubo de código.
- Libertação de código do Window$ na Internet que pode influenciar programadores que desenvolvem Software Livre para poder processar mais tarde.
- Algum incentivo para que o C# seja realmente uma liguagem Cross-Platform com evolução (que o Java não foi durante muito tempo). Algumas apresentações da M$ referem Mono e usam Mono.
Com a contatações destes factos todos (muitos deles puras hipoteses) podemos concluir que a M$ pode estar a tentar usar o C# para convencer os utilizadores Linux que esta é a melhor plataforma de desenvolvimento, pois, é estável (quanto baste), tem uma vasta equipa de desenvolvimento que a evolui, porque é livre e porque é cross-plaform, destornando assim o JAVA que tantas dores de cabeça deu à M$ com processos.
Estará a M$ a tentar fazer à SUN o mesmo que fez a outras empresas como a Netscape, que é aniquilando nos seus proprios territorios mais com mais recursos tanto financeiros como humanos ?!?!?
Apesar de estar com este discurso todo, sou neste momento um adepto do .NET e ando a programar em Mono no Linux .. mas ... num dá que pensar esta situação toda ?!?!?
esquisito ... muito esquisito a ordem dos acontecimentos ....
(())
Esqueleto
------------------------------ Visit me in: http://www.tusofona.com/esqueleto |
| | | | | | Estará a M$ a tentar fazer à SUN o mesmo que fez a outras empresas como a Netscape... Só agora é que reparaste? Onde é tens andado nestes últimos 8 anos?
|
| | | | duuuhhhhhhhhh
------------------------------ Visit me in: http://www.tusofona.com/esqueleto |
| |
|
