| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | Mono (Pontos:4, Interessante) |
| | | Olá. Já houve uma thread sobre o Mono em que se falou mais ou menos dessas coisas: Why Mono?. Foi mais uma thread de Java vs .NET. Para quem não sabe, houve um seminário da Novell em que se falou do Mono, se queres ter uma ideia podes ver a apresentação on-line. Vê este post do meu blog para saberes como ver o filme, nomeadamente a parte do Mono. Também tens vários ppt's de apresentação, que são mais virados para a comunidade Linux. Para instalar, podes ver um artigo que eu escrevi sobre instalar o Mono: Mono no Linux. Duvido muito que a Microsoft vá patrocionar o Mono... sigo de perto o projecto e nunca vi nada do género. Seja como for o Mono é uma excelente plataforma, como poderás ver na apresentação! Aconselho a toda a gente. E o Mono não é dependento do Gnome, contudo as aplicações gráficas são, pois usam o GTK#. As aplicações gráficas têm sempre de ser dependentes de alguma coisa nativa! ;-) Isto se quiserem ser rápidas. O Java também é outra boa opção, se não tás por dentro nem do Java, nem do Mono, vai ser complicado escolheres. Seja como for, podes usar o MonoDevelop para projectos Java, aliás, podes mesmo correr Java no Mono. Falando das outras opções, o .GNU, quando o experimentei, não estava tão avançado como o Mono. Eles já tinham as System.Windows.Forms a funcionar (relativamente bem), mas de resto não tinham muito implementado, especialmente no que toca a XML. Já o experimentei no ano passado, não sei como está agora, mas também no site é raro ver notícias. Eu do python sei pouco, sei que já há compiladores de python para .NET e que aparentemente é mais rápido usar o python no Mono devido ao JIT, AOT, etc. Mais sobre isso aqui: IronPython: A fast Python implementation for .NET and Mono. Do python em si, tenho lido que é uma linguagem muito estrurada, muito boa (com uma sintaxe peculiar para quem está habituado a C++/Java/C#), mas que não é muito adequado para projectos grandes. Tal vez para o .NET/Java seja, não sei, é melhor leres a opinião de alguém por dentro do assunto. Já agora, também existe o Jython, que é o python para o Java. :-) Resumindo, eu voto no Mono, mas é a minha opinião pessoal, e vai haver várias pessoas com bons argumentos para usares outra plataforma. Acho que o melhor é mesmo experimentares, fazes umas coisas pequenas em cada lado e vês do que gostas mais. E vê a apresentação do Mono(começa por volta do minuto 58)! ;-)
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | Java + Eclipse.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | | | Eu experimentei o Java com SWT e estou deveras impressionado com a facilidade e o desempenho da biblioteca gráfica. Estou com o mesmo dilema que o Autor, só gostaria de ter uma interface fácil às bibliotecas que já desenvolvi em C (não C++). De qualquer modo, o python é excelente. Agora, alguém me pode dizer duas coisas: 1) o jface alguma vez irá ser destacado do eclipse?, e 2) o draw2d (do GEF) é concorrente directo ao Java2D? Francisco Colaço
|
| | | | | Estou com o mesmo dilema que o Autor, só gostaria de ter uma interface fácil às bibliotecas que já desenvolvi em C (não C++). Porque nao JNI ?
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | Acho que o JNI, que já usei, ainda é um pouco difícil de manter. Compara-o com o ctypes do python e verás de antemão a diferença. Em disclaimer: o P/Invoke também me parece demasiado confuso (no sentido de manutenção face à evolução das interfaces de uma biblioteca, o que, sendo raro, naturalmente não deixará de acontecer). Francisco Colaço
|
| | | | Em termos de facilitar a manutenção do código e simplificar a geração automática dos bindings,
isto pareceu-me interessante...
|
| | | | | Usei já disso, e gostei. Uso-o mais com python, perl e tcl. Francisco Colaço
|
| | | | Sem dúvidas. Eu ainda acrescentaria isto que estou a usar para desenhar GUI's (SWT no meu caso, mas também faz Swing).
É excelente, e ao contrário das opções semelhantes para Swing (JBuilder, NetBeans) parece-me gerar código muito mais limpinho.
|
| | | | | Já experimentaste ? Se sim, qual a tua impressão ?
|
| | | | Das opções que apresentaste eu aconselho-te a esquecer as variantes de .NET. Qualquer argumento de compatibilidade com o .NET da Microsoft é pura ilusão. O .NET é a grande aposta da Microsoft para aumentar a penetração do Windows no mercado dos servidores e os clones nunca conseguirão atingir a compatibilidade, é como tentar apanhar a própria sombra. No entanto se quiseres usar o Mono (por exemplo) como o "Mono" e não como um compatível-.NET já não tenho grandes objecções (para além de se estar a aumentar o mindshare da plataforma .NET...).
Portanto resta o Java e o Python. A escolha entre estes dois depende do que queres fazer. Se o projecto é grande então é melhor o Java. Se o projecto é relativamente pequeno ou queres fazer uns protótipos então aconselho Python. Ambas as linguagens permitem chegar directamente ao SO com métodos nativos caso não haja outra hipótese.
-- Carlos Rodrigues
|
| | | | | | | Qualquer argumento de compatibilidade com o .NET da Microsoft é pura ilusão. Porquê? Eu até agora tenho tudo compatível. O meu projecto final usa muita coisa da plataforma .NET e eu trabalho em Linux/Mono e o meu colega com o .NET da Microsoft. O Mono é 100% compatível com o .NET 1.1 (último lançado pela Microsoft), excepto em pontos que ainda não têm implementação no Mono. É objectivo deles ter compatibilidade para trazer os recursos de windows para Linux. Por isso gostava de saber porque falas em ilusão.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | O Mono é 100% compatível com o .NET 1.1 (último lançado pela Microsoft), excepto em pontos que ainda não têm implementação no Mono.
Boa... o Mono é compatível em tudo excepto o que não é...
-- Carlos Rodrigues
|
| | | | | Não te faças de desentendido. Se eles por exemplo ainda não têm as System.Windows.Forms a funcionar porque ainda não tão implementadas então é natural que essa parte não seja compatível. Seja como for, não me respondeste.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Não me estou a fazer de desentendido. O .NET é o .NET, se o Mono não implementa algo tão fundamental como as Windows.Forms então não é compatível com o .NET, ponto final. Chamem-lhe outra coisa que não .NET, caso contrário estão a alimentar a ilusão de um .NET multiplataforma e a atirar programadores iludidos para o mundo do .NET da MS.
Não vou voltar a entrar no debate sobre o .NET mas vou dizer isto: se o Mono não é compatível com o .NET então simplesmente não é uma escolha com pés e cabeça actualmente, pois existem outras soluções melhores (e igualmente não .NET). E digo mais, quem se puser a implementar coisas em .NET a pensar que depois as vai por a correr em Mono (ou o contrário) vai apanhar uma grande desilusão pois este nunca vai ser um clone do .NET da Microsoft. Podem escrever aquilo que eu digo, daqui a uns tempos cá estarei para ser corrigido se estiver errado.
PS: não adianta recorreres à tua experiência académica, no mundo real as aplicações têm GUIs e recorrem a outras funcionalidades também disponíveis apenas na implementação da MS.
-- Carlos Rodrigues
|
| | | | Acho que a tua falta de argumentos neste assunto te tá a confundir, já te andas a contradizer: No entanto se quiseres usar o Mono (por exemplo) como o "Mono" e não como um compatível-.NET já não tenho grandes objecções e vou dizer isto: se o Mono não é compatível com o .NET então simplesmente não é uma escolha com pés e cabeça As SWF ainda não tarem prontas não quer dizer nada, as coisas não se fazem de um dia para o outro. A minha experiência académica é com aplicações Web, e não tenho problemas nenhuns. Tu és teimoso e tens tanto ódio a coisas que não conheces que até mete impressão. Mas eu aceito as tuas opiniões, se bem que desta vez estão mal fundamentadas. Se não gostas de .NET, não uses, mas estar a falar mal sem saber... ;-) Principalmente quando já foi feito tanto trabalho, e quando são pessoas como o Miguel de Icaza que estão por detrás disto, pessoas muito mais experientes do que tu, ou eu, no mundo do Linux. Vê o meu blog, há lá o ppt de uma apresentação onde eles falam o porquê de trazerem o .NET para outras plataformas.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | Tu é que estás a tentar encontrar contradições onde elas não existem e ódios onde eles não existem. Usar o Mono como Mono é assumir que ele irá ser para sempre uma plataforma por si só (e que neste momento ainda nem sequer está madura o suficiente) não é pegar nele como um .NET.
Essa teoria de que o Mono vai um dia ser um .NET é como esperar pela chegada do D. Sebastião. O Mono irá ser sempre tão compatível como o Wine (e já muita gente conhece a minha opinião acerca do Wine...). Eu até te dizia para ficares com as tuas ilusões, se não fosse o caso das tuas ilusões só contribuirem para que a Microsoft ganhe outro monopólio...
Já agora, vocês tiram muitas ilações acerca dos meus ódios mas eu vou chocar-vos dizendo que eu até seria capaz de aceitar trabalhar com .NET (da mesma forma que trabalho com Windows). Só não esperem que se for eu o decisor alguma vez escolha .NET, nem que eu deixe de fazer a minha "advocacy".
-- Carlos Rodrigues
|
| | | | | | - Mono - Outro clone open source no .NET e pelo que ouvi falar ia passar a ser patrocinado pela propria Microsoft para tentar dar alguma notariedade à sua plataforma... Mas que disparate! Ao que sei existe uma boa relação entre a equipa do mono e a equipa de .net da m$, mas não passa daí, não há qualquer apoio da m$ ao projecto.
Cuidado com as palavras que usam!!
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | | | Porque é que deram "despropositado" ao post acima ? Está 100% correcto... Se houve alterações, indiquem, pf... é mais útil que moderar negativamente um comentário correcto... :-)
|
| | | | | ... talvez fizesse sentido optares pelo Python, uma vez que parece que os programadores desta linguagem são, estranhamente, dos mais bem pagos. Agora resta saber, como refere o Olifante no seu blog, se o facto de os programadores de python serem mais bem pagos se deve à linguagem em si ou ao facto de os melhores programadores a preferirem entre outras... Cumps.
"mudem de rumo, já lá vem outro carreiro" |
| | | | | | Fico contente por saber ambas as coisas que dizes!
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Então o que sugeres é que o homem escolha python para que o projecto lhe saia mais caro?!
Não percebi essa.
Além de que, programadores de COBOL tambem eram pagos a peso de ouro, assim como os de assembly...
Não prova nada.
|
| | | | O projecto não sai mais caro porque o tempo de desenvolvimento é mínimo comparado com as outras linguagens referidas.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | O projecto não sai mais caro porque o tempo de desenvolvimento é mínimo comparado com as outras linguagens referidas.
queres corroborar essa afirmação com dados factuais?
links, please.
|
| | | | Apenas um, descoberto agora mesmo (google, claro):
http://econweb.tamu.edu/turocy/python.htm
"mudem de rumo, já lá vem outro carreiro" |
| | | | Aqui segue a minha opinião, tendo em conta o que sei do projecto que é, com efeito, muito pouco...
Antes de mais, tens de ver até que ponto dois parâmetros, dependência e interoperabilidade contam para ti e para o teu projecto. Dependência, porque ao usares .NET estás dependente da vontade súbita de uma empresa que, ao mudar algumas especificações no .NET framework que agora irá lançar, vai quebrar certamente muitas compatibilidades com o Mono, até que estas sejam reestabelecidas. A minha opinião é que eu *não* confiaria.
O outro problema é a interoperabilidade que pode derivar, ou não, da primeira. O Mono e o .NET ainda não são 100% compatíveis e, como tal, o trabalho que possas fazer numa plataforma poderá não ser realmente compatível com a outra, para além de que, nunca será compatível com as outras plataformas que não suportadas ou pelo framework da Microsoft ou pelo Mono.
Acho Python uma linguagem muito engraçada, mas não sei até que ponto a usaria para programar um projecto de grande complexidade. Atenção ao psyco que é um inline code optimizer que melhora muito as prestações do Python, mas mais detalhes com o mlopes ;-)
No caso do Java tens de ter em atenção alguns aspectos:
- A package Swing não é livre, como tal, há uma licença que deverás seguir para que a possas usar. Desconheço os contornos exactos desta licença, mas ainda é de relevo. Podes usar, neste caso, a package SWT que acompanha o Eclipse e é, sem dúvida, uma grande concorrente!
- Os IDE developers para mim existem três: JBuilder, SUN ONE e Eclipse. Os dois primeiros são os únicos que permitem desenhar GUIs com Swing, no entanto, são proprietários e bem caros. O Eclipse é *EXCELENTE* e permite-te desenhar os GUIs, não nativamente, mas recorrendo a alguns plugins que muita gente já referíu por aí. Pena todos estes guis precisarem de 4 ou 5 monitores de 20" para uma pessoa não se perder no meio de tantas toolbars :-(
Dominus vobiscum |
| | | | | | | Olá. Os argumentos contra o Mono que vejo mais são aqueles que disseste. Por isso queria ver se tornava mais receptivo. :-) o CLI (runtime) e o C#, tal como vários assemblies do .NET (equivalente aos packages) são um standard da ECMA. A Microsoft não pode mudar as coisas asism sem mais nem menos, por serem um standard. Pelo menos implementações que cumpram o standard não têm problemas. É claro que pode haver sempre partes proprietárias, mas isso pode haver em qualquer lado. Falando de compatibilidade, o Mono é 100% compatível com o .NET 1.1 (último lançado pela Microsoft). E já tem várias freatures da próxima versão prontas. Por outro lado, pode ser sempre um risco a Microsoft virar-se contra o Mono. Mas se o fizesse, porque não o faria contra o WINE? E em último, porque não têm as mesmas desconfianças sobre o Java? Ler este texto da autoria do Miguel de Icaza - Project Manager do Mono: The fear that people have on Mono's legal issues apply equally as well to everything else. Let me explain. Sun owns various patents on Java, and they might just feel at some point threatened enough to use them as a weapon against open source. In the same way people feel that Microsoft might pull that trigger. Just to put things into a different perspective: Sun has litigated over Java in the past (against Microsoft) over a contractual dispute and has done threatening legal moves against JBoss at some point (which I do not claim to understand) over bits of J2EE. If Java on Linux became a threat to Sun, would they use their patents? I do not know, and I hope not. Am only illustrating the point, just like other people have vehemently illustrated the Microsoft patent risk before. There is nothing in Java that makes it any safer than Mono at this point. We do not have any guarantees, any written statements, any guarantees that Java on Linux will not be sued under certain conditions. Microsoft has granted RAND+Royalty Free licenses to any patents they might own that are required to implement the ECMA 334/335 standards. So at least our core VM, classes and compilers are safe from any litigation from *Microsoft*. Now, pay attention to the above, because it is important. The fact that Microsoft has given access to any patents they might hold on .NET does not mean that a third party that has a patent that is required to implement ECMA (or Java) will grant that license. Why does this matter? Because we just do not know if someone has a patent on pieces that Java and .NET implement. There might very well be one that we are not aware of. The patent might remain sleeping for a few years before someone decides to profit from it. And the above is important. It is important because even with a fully re-engineered virtual machine, runtime system and the rest, we do not know if you will not be infringing on a Sun, Microsoft or third party patent. With the current patent situation, it is probably impossible to ask small startups or individual developers to do a patent review before they make decisions on how to implement their software, only very large companies might afford it, and believe me, even with vast resources, you might be taken to court by an unknown (Eolas patent for example) or by a law firm who focuses on purchasing dormant patents and litigate them. Nat used to say "If you write a thousand lines of code, you are violating someone's patent today". The picture is not pretty for anyone in the software industry. But this is similar to what happens to biology students: on their first four semesters as they learn about all the dangers, infections, vectors for infections and bacteria, they stop eating everything, they start washing their hands with special products, they double clean their utensils, they wash their fruits ten times a day. Two years later they are eating food with their bare hands again.
_____________________
Pedro Santos :: psantos.net :: blog |
| | | | | o CLI (runtime) e o C#, tal como vários assemblies do .NET (equivalente aos packages) são um standard da ECMA. A Microsoft não pode mudar as coisas asism sem mais nem menos, por serem um standard. A m$ pode não poder mudar o standard sem mais nem menos, mas pode não cumprir o standard e implementar as coisas de uma forma diferente de forma a criar incompatibilidades e dado o historial da m$, isso é bem provavél.
A m$ simplesmente não é de confiança Pelo menos implementações que cumpram o standard não têm problemas. As que cumprirem o standard são compativeis com o standard, o que não é inerentemente a mesma coisa que ser compativél com a implementação da m$. É claro que pode haver sempre partes proprietárias, mas isso pode haver em qualquer lado. Não pode em todo se a implementação for Software Livre com copyleft, não pode. Pode no entanto neste caso, o que significa que dizes adeus à compatibilidade.
Já agora não te esqueças das patentes que a m$ anda a registar, que te podem impedir de implementares o standard. Não percebo a razão de tanta fé na bondade da m$, quando ela so deu razões para não acredirtarmos nela. Francamente! Vocês nunca aprendem!
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | A package Swing não é livre
Não compreendo. Fazendo parte integrante do j2se, tem um licenciamento especial ?
Nunca tive conhecimento de qq regime de excepção para o Swing, desde que ai foi incluido.
Podes fundamentar ?
|
| | | | | mais detalhes com o mlopes ;-) Porquê????
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Esqueleto, (1) Que tipo de projeto você está pretendendo desenvolver? Biblioteca? Aplicação? Em que área? Aplicação vertical? (2) Tem que ter interface Web? Porque? (3) Tem que ter interface Gráfica? Que ambiente? (4) Tem que ser multiplataforma? Cobrindo quais plataformas? (5) Tem que ter alguma interface remota (Web Service, CORBA, ou semelhante)? Porque? (6) Vai fazer acesso a RDBMS? quais? porque esses? Respondendo a essas perguntas, dá pra decidir entre as alternativas que você indicou, ou mesmo algumas outras (Perl, Ruby, C++/KDE/Qt, wxWidgets em C++,Python,Perl), mas sem essas informações, fica muito difícil.
|
| | | | | | Desenvolvimento de aplicações, por exemplo, de gestão para comercializar. Imagina as aplicações da TI ou Etica-Data ou qualquer outra SoftwareHouse.
Deveria ter a possibilidade de poder ter Interface Web (não prioritário) e Interface Gráfica (Prioritário).
Em relação à multiplataforma, é uma realidade que não deve ser colocada de lado, se for possivel, tanto melhor.
|
| | | | Com Python, você vai ter uma gama muito grande de IDEs (KDevelop, wxGlade, entre outros) para desenvolver e uma gama maior ainda de toolkits (TK*, QT*, KDE, GTK*?, wx* -- os marcados com * são multiplataforma, entre outros); boa conectividade com banco de dados e, mais tarde, você pode integrar seus objetos no ZOPE e ter uma interface web bem-feita. acho que é a linguagem/ambiente onde o tipo de aplicativo que você quer desenvolver sairá mais depressa. A propósito, dê uma olhada no GNUe (GNU Enterprise); tem um monte de módulos que já estão prontos para usar; e é em Python.
|
| | | | mas esqueci de dizer: em Python, você vai ter a vantagem que, uma vez determinados "gargalos" em seu sistema, você pode otimizá-los, além de re-escrevendo em C/C++, com as ótimas ferramentas psyco (eu uso muito, e é excelente) e pyrex (nunca usei, mas parece muito interessante, é uma mistura de C e Python)
|
| | | | Obrigado ....
devo dizer que esta é a unica resposta com sumo realm que posso usar.
Muito obrigado, entendeste o objectivo do exercício.
Vou olhar para o Python com muita aternção.
Não me respondeste ás formas de Deplyment tenho com o Python.
(())
Esqueleto
|
| | | | | Uma IDE muito interessante é o Boa Constructor. É uma IDE competente, e se vc não precisar de widgets extremamente ricos (como o QT), o Wx (que é adotado pela IDE) resolve o problema. Destaque para o editor visual de janelas, bem como para o help integrado (facilmente expansível). Não é a panacéia para todos os males, contudo. Como a ferramenta ainda está em Alpha, é um pouco complicado recomendá-la para uso em ambiente de produção sem alguma cautela. No meu, até agora, não tenho do que reclamar, pelo contrário. Mas também não dependo únicamente dela... Se vc for trabalhar na plataforma Win32 (e portabilidade não for algo essencial), usar objetos COM com o PythonWin32 é muito, mas muito simples. Quanto ao deployment, a geração de pacotes não é das mais simples, mas não chega a ser complicada. Vc pode simplesmente enviar o código pré-compilado, ou o fonte. A compilação é em tempo real, e totalmente transparente. É interessante lembrar que, como Java, Python é usa bytecodes interpretados, logo a máquina alvo precisa ter o Python instalado - o que pode ser uma preocupação à mais se levarmos em conta que as versões mais recentes de Python adicionam features (e alguns bugs) às antigas.
[]s,
Pink@Manaus.Amazon.Brazil.America.Earth.SolarSystem.OrionArm.MilkyWay.Universe |
| | | | | Usem pyrex, é excelente. Complementado com ctypes (que usei uma vez para em duas horas fazer uma interface perfeitamente manutível a uma biblioteca CAN), nem pensaria duas vezes em recomendá-lo. Francisco Colaço
|
| | | | As minhas escolhas dependem das necessidades. Aqui está a conclusão do que vi até agora entre trabalho meu e de amigos meus (do melhor para pior):
Desempenho actual: Java, Mono, Python
Desempenho potencial: Mono, Java, Python
Velocidade de desenvolvimento: Python, Mono, Java
Bibliotecas disponíveis: Java, Python, Mono
Plataformas: Python, Java, Mono (sim, estou a ignorar J2ME - ainda tenho alguma dificuldade em chamar java àquilo - o python ganha ao java, ou pelo menos empata graças ao Jython).
Robustez: Python, Java, Mono
Traduzindo, escolhe a tua. A velocidade de desenvolvimento é a mais importante para mim, portanto prefiro o python. Mas a minha caixa de ferramentas inclui algumas coisas muito estranhas...
|
| | | | | | | Nao percebo genuinamente como e' que o Python suporta mais plataformas que o Java. Tambem nao percebo de que forma e' que em robustez o Python e' melhor que Java... Nao percebo muito de Python, mas acho isso incrivel considerando o tamanho e "backing" por traz do J2EE.
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | Nao percebo genuinamente como e' que o Python suporta mais plataformas que o Java.
bem, eu tenho um linux sparc e um linux mips e em ambos nao tenho java, mas tenho em ambos python...
o problema e' que a sun nao faz a JRE para todos sistemas e conbinacoes de hardware e nao sendo software livre ou sequer open-source, nao se pode recompilar para esses sistemas
a robustes provavelmente vai no mesmo caminho, no python podes corrigir bugs no intrepretador por ser livre, no java tens de reportar o bug e esperar que seja corrigido
Higuita |
| | | | A robustez advem principalmente, na minha opinião, do desenvolvimento ponderado, estruturado e organizado que são filosofia do Guido VanRossum.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Embirram logo na parte que expliquei...
Python ganha ao java ou, pelo menos, empata, porque um dos dois principais interpretadores de python é o jython que corre em qualquer implementação de J2SE.
Quanto a robustez, o que tenho observado tem a ver com a quantidade de condições de erros que não tens de lidar como programador, como overflows de inteiros.
|
| | | | | Concordo quanto ao Python ser uma boa escolha. Na verdade, eu suspeito que para a vasta maioria das aplicações, a velocidade e facilidade de desenvolvimento é muito mais importante que a velocidade de execução. E com o Parrot, em breve o Python terá mais uma VM, desta vez Open Source. Eu não considero o Java como um advanço muito importante em relação ao C/C++ em termos de facilidade de desenvolvimento como linguagem em si, com a excepção das bibliotecas standard. Mas a verdade é que também existem bibliotecas em C para tudo, é preciso é normalmente deixar a portabilidade do código fonte para trás, o que é algo irritante. A portabilidade de binários é outra coisa. Essa é mais importante para software proprietário que Open Source. O GCC é a nossa VM estática de C/C++. :-) Na minha opinião, o ideal seria ter uma linguagem de mais alto nível, sem tipos, estilo Python. Na qual pudesses embeber código numa linguagem de mais baixo nível, com tipos. Esta linguagem teria uma performance mais elevada e seria usada para segmentos de código críticos e fazer as bibliotecas base de sistema. i.e. substituir o C. Possivelmente até seria possível usar o C para esse efeito, com extensões.
|
| | | | Dois pontos:
- Discordo quanto ao facto do Java não ser um avanço importante em relação ao C++. Comparado com Python, Java é horrível, mas só o facto de não teres de fazer a gestão da memória é um avanço significativo.
- O que é que é "uma linguagem sem tipos"? Python foi desenhado para ser facilmente extendido em C. Os tipos nativos (lists, dicts, etc.) são todos em C. E com Pyrex é *ainda mais fácil* extender Python com tipos em C. O que descreves parece ser a situação actual do Python...
|
| | | | Creio que ele quer dizer "weak typed" em oposição a "strong typed". Penso que uma das grandes vantagens do python relativamente ao java é mesmo o weaked typing do python.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Hmm... Mais uma guerra de terminologia... Python é "strongly, dynamically typed".
- Python é "strongly typed" porque o interpretador se recuza a aplicar incorrectamente operações aos tipos. Por exemplo:
1 + "1"
gera um erro (mas é código válido em Perl). É necessário dizer no entanto, que há várias gradações, porque
1 + 0.1
é válido em Python (o interpretador converte 1 em float automaticamente) mas já é inválido em Haskell por exemplo -- pelo que se pode dizer que Haskell é mais "strongly typed" que Python.
- Python é "dynamically typed" porque os tipos só são verificados em "run time". Uma variável (em Python é mais correcto dizer "name binding" ou coisa parecida) pode referenciar diferentes tipos durante o seu tempo de vida. Por exemplo:
var = 1
var = ""
É perfeitamente válido. Ao contrário, C++ é "statically typed" porque o tipo de uma variável é declarado no código e é verificado quando este é compilado.
Dito isto, deixem-me acrescentar que os sistemas de tipos em C/C++ são uma farsa porque há maneiras de contorná-los (macros em C, casts em C++, etc...). Para sistemas de tipos feitos como "deve ser" ver linguagens funcionais como Haskell.
Em relação a Java, também concordo que o sistema de tipos de Python é muito superior. As razões ficam para outra altura...
|
| | | | Por acaso já uma vez tinha lido algo do género daquilo que explicas aqui e concordo. Relativamente ao facto de poderes atribuir valores de diferentes tipos durante o tempo de vida de uma variável, é giro ver o que se pode fazer por exemplo se atribuitres um valor a __builtins__:
__builtins__ = ""
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Isso já acontece muito com o python, normalmente as cenas de nível mais baixo que precisem de velocidade são feitas em C ou C++. O swig (nuca usei mas já utilizei coisas feitas com o swig) também me parece uma ferramenta excelente para criar módulos utilizaveis em python feitos em C sem ter que aprender toda a api que torna possível criar módulos em C.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Quanto ao desempenho: fizestes provas com o Psyco e/ou o Pyrex?
|
| | | | faltou referir que, em termos de velocidade de execução, o Python é muito mais lento do que Java.
Java actualmente é muito, muito rápido. e quem achar esta afirmação estranha é porque tem andado a dormir nos últimos dois anos.
|
| | | | | Olá. Nas máquinas de hoje, para as aplicações de normais de desktop, a velocidade de execução de um programa é irrelevante: a maior parte do tempo a aplicação está à espera do utilizador. Para além disso, temos que as interfaces gráficas (qt, gtk+, wxwindows) são totalmente em C/C++, assim como algumas das bibliotecas onde a velocidade é importante, pelo que uma aplicação real não deverá ser muito penalizada pela lentidão do interpretador. Somando a estes factores temos, para mim, o mais importante: o meu tempo é muito mais precioso do que o do computador. Logo, se demora menos tempo a desenvolver em python do que em java, será essa a linguagem que escolherei, se só estiver em causa esse factor. Cumps.
"mudem de rumo, já lá vem outro carreiro" |
| | | | Pela tua lógica só o pessoal que desenvolve o Java é que esteve acordado! Não te esqueças que durante esse tempo tanto o python como o mono também se desenvolveram.
Posso-te inclusivé dizer que há uns tempos fiz um teste de velocidade em manipulação de listas/arrays e de strings e em ambos os casos, o python que à uns anos era considerado mais lento que o perl foi cerca de 3x mais rápido. Se usasse o psyco então um teste que me demorava 0.9xxxx segundos em perl e 0.3xxxx segundos em python passava para os 0.0xxxx segundos em python (claro que isto não é linear nem acontece sempre que se usa o psyco, mas já descrevi acima o tipo de teste feito).
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Se a escolha é entre Java e Python, IMHO Python.
Rapidamente, alguns pontos:
1. Em termos de expressividade, Python deixa Java no tapete - o que, convenhamos, também não é muito difícil. O que é fácil, é fácil, o que é difícil é mais fácil. Por exemplo, em Python tudo é um objecto - funções, classes, etc. são objectos. Pelo que podem ser passados como argumentos a funções, podem ser inspeccionados, instanciados, etc. Em Java tudo isto é, ou impossível, ou muito difícil (e muitas destas coisas *são mesmo úteis*).
2. Existe um compilador de Python para a JVM, Jython, pelo que podes ter o melhor (?) dos dois mundos.
3. Existem libraries para (quase) tudo em Python. O problema é que não existe stanmdardização. POr exemplo, existem vários web frameworks - Zope, twisted, etc.
4. Em termos de performance, em geral Java é melhor, mas a situação não é clara. A VM do Python é muito melhor em termos de memória por exemplo. IO é em geral melhor em Python (porque recorre a C), etc.
5. Diria que fazer o "deployment" de uma aplicação em Java será mais fácil, porque já existe standardização. Em Python as coisas não serão tão simples. Várias opções existem, a melhor será distutils.
6. Unit testing sempre!
|
| | | | | | É sempre triste responder a nós mesmos, mas aqui vão mais três pontos importantes:
- IDE's: a situação em Java é bem melhor, o Eclipse é muito bom. Em Python, Boa constructor promete mais ainda está "muito verde".
- GUI's: wxPython. Nunca programei GUI's em Java, mas não me admirava nada se o wxPython (um porte do wxWindows para Python que corre em Linux, Windows e Mac OS X) fosse bem superior ao swing, awt, ou lá que raio é que se usa em Java :-)
- A comunidade Python é das mais amigáveis e prestativas. Quer a tutor mailing list quer comp.lang.python são óptimos forums com pessoas do mais competente que há.
|
| | | | E se queres só fazer um GUI para Linux, tens o python-gtk que é muito porreiro. A RedHat usa-o imenso, para os programas de instalação e de configuração.
|
| | | Python (Pontos:2, Informativo) |
| | | Bem, agora já tenho mais comparsas a recomendar o Python :-) Lê isto (pdf). IDEs: bons mas comerciais tens o BlackAdder e o Komodo. Free, provavelmente o WingIDE ou o Boa Constructor. Em relacao a instalacoes/instaladores não há mta coisa para Linux, nem nada comum 'as varias distribuicoes. Em relacao ao Windows podes estar interessado em dar uma olhada ao Py2EXE e ao Inno Setup Cumprimentos Mario Valente Cumprimentos Mario Valente
|
| | | | | | Mário, porque não à um instalador gráfico ??? algo que defina um script de instalação, procure dependências, as instale, que coloca icons no Desktop, na QuickBar e um no menu Start (como se chama ni KDE e GNOME????)
Para windows temos diversas ferramentes como o Wise, Install Shield e outros, mas, para linux, ou compilamos tudo ou não.
Sei que ainda à o RPM, mas, os programadores que os desenvolvem nem sempre os terminam .. nem os fazem da melhor forma. Uma vez instalei um soft que no final nem sabia qual o binário para executar... estas práticas não deveriam ser consideradas má programação ???? Ou será que o Deployment não é considerado programação ?????
Se pensarmos que a maioria das vezes (muitos %) para compilar uma source basta fazer "./configure && make && make install", (como root), porque é que este processo não está mais optimizado num só????
Estou claro a pensar na info-excluida que tenho em casa que pode até encontrar algo na NET que gostaria de colocar no linux, e ela para instalar tem sempre que efecturar diversas operações.
Será pedir demais uma certa automatização destes processos ??????
(())
Esqueleto
|
| | | | Tomei a liberdade de responder pelo Mário.
porque não à um instalador gráfico ???
Para quê? Também preferes livros com quadradinhos?
...algo que defina um script de instalação, procure dependências, as instale
Em debian isso chama-se apt-get, no gentoo é o emerge, para redhat sei que tambem há um
EM WINDOWS ISSO NÃO EXISTE. Quando muito podes meter as dependencias no pacote (como acontece com o directX nos jogos, ou com o Java runtime em muitas aplicações).
...que coloca icons no Desktop, na QuickBar e um no menu Start (como se chama ni KDE e GNOME????)
Meu amigo, em unix existe uma coisa que se chama liberdade de escolha. Podes ter o window manager que te apetecer, seja ele compativel com a norma ou não. Por isso não há uma maneira standard de fazer isso.
Mas sim, normalmente os RPM's e os DEB's e afins adicionam o dito programa num ficheiro de menu que é utilizado por vários desktop managers (semi)compatíveis com a norma (Gnome, KDE).
Para windows temos diversas ferramentes como o Wise, Install Shield e outros, mas, para linux, ou compilamos tudo ou não.
uh?! E eu que pensava que os RPM's normalmente vinham em binário. Quem é este gajo?
Em windows NÃO TENS maneira standard de instalar o software. Como disseste, tens várias ferramentas, podes até criar o teu próprio installer em visual basic se te apetecer, e quem instalar que se foda.
Dou-te só o exemplo de algumas aplicações que depois de instaladas, não as consegues remover porque o uninstaller dá erro. Isso é no mínimo ridículo.
Em unix, as coisas vão para o sitio onde tem de ir. E não há cá installers manhosos feitos por não sei quem, a meter ficheiros onde não devem.
Sei que ainda à o RPM, mas, os programadores que os desenvolvem nem sempre os terminam .. nem os fazem da melhor forma.
E no windows fazem sempre bem? Isso é uma piada right?
Uma vez instalei um soft que no final nem sabia qual o binário para executar...
Isso porque não leste o manual :)
As aplicações não tem de consistir apenas num unico binário. Muitas vezes tens grupos de binários pequenos. Querias o quê? um iconzinho para cada um é?
Larga os livros aos quadradinhos pá. Isto é informática.
estas práticas não deveriam ser consideradas má programação ???? Ou será que o Deployment não é considerado programação ?????
Não. É um paradigma diferente daquele a que o tio patinhas te habituou.
Eu estou habituado a pilotar carros de formula 1 nos jogos de computador, mas não os consigo pilotar na vida real. Será que deveria ser considerada má mecânica? Ou piloto maçarico?
Se pensarmos que a maioria das vezes (muitos %) para compilar uma source basta fazer "./configure && make && make install", (como root), porque é que este processo não está mais optimizado num só????
Se pensarmos que a maioria das vezes usas as letras "n", "ã" e "o" para escrever "não", porque não as abolimos e criamos uma tecla "não"?
Estou claro a pensar na info-excluida que tenho em casa que pode até encontrar algo na NET que gostaria de colocar no linux, e ela para instalar tem sempre que efecturar diversas operações.
Simples, instala-lhe um sistema operativo para info-excluidos. Sugiro o Windows da Microsoft, és capaz de conhecer.
Será pedir demais uma certa automatização destes processos ??????
Depende, tás a pedir a quem?
Lembra-te que normalmente em linux as aplicações nascem duma comichão que alguém sentiu vontade de coçar. Se ninguem se deu ao trabalho de fazer isso é porque provavelmente não fez comichão a ninguem (ou porque não faz sentido)
|
| | | | As vezes me pergunto se realmente alguém entende o que estou a dizer.
Quando dou o exemplo da info-excluida que tenho em casa, tento saber como seria se eu chega-se a um conjunto de empresas como por exemplo os Agentes de Viagens e lhes propose-se Linux em vez de Windows e uma aplicação de gestão da agência.
Com a utilização do computador eles haveriam de querer melhorar o desktop, colocar as coisas como gostam, e para isso poderiam querer instalar aplicativos.
Pessoas que olham para os computadores como uma ferramenta de trabalho e não como uma forma de vida, como muitos de nós fazemos, tem que poder ter mecanismos que lhes permita resolver a maioria dos seus problemas de uma forma simples e muitas vezes sem recorrer a grandes conhecimentos de informática.
Estou a pensar criar uma empresa que vai desenvolver aplicativos de gestão para a plataforma Linux ou ainda que desenvolva aplicativos Cross-Platform, e uma das minhas principais preocupações é como é que faço o deployment das minhas aplicações (e dos patches) para pessoas que pouco percebem de computadores e de informática.
Se eu estivesse a desenvolver para pessoas, como os demais neste forum, que se interessam pela informática e pelos sistemas operativos e pela forma como trabalham, eu não teria qualquer problema em não pensar no deployment.
Não quero, nem pretendo fazer em linux o mesmo que existe em Window$, mas, pretendo saber quais as minha opcções para minorar todos os problemas que me refiro.
Respondendo directamente aos problemas que colocas:
porque não à um instalador gráfico ???
Para quê? Também preferes livros com quadradinhos?
Penso que estas a ser demasido leviano no que diz respeito a esta questão pelas razões que incialmente apontei.
Sem uma forma final refinada de deployment as aplicações linux estarão condenadas a ser usadas somente por que realmente anseia pelo conhecimento e pela forma que o SO funciona, e não o vulgar utilizador.
Mas estas no teu direito de não gostar de "livros com quadradinhos" da mesma forma que eu tenho direito em ler esse livros.
Meu amigo, em unix existe uma coisa que se chama liberdade de escolha. Podes ter o window manager que te apetecer, seja ele compativel com a norma ou não. Por isso não há uma maneira standard de fazer isso.
Claro que não vou discutir isso contigo, estou perfeitamente de acordo com essa liberdade, apesar de achar que podiamos fazer um pouco mais por essa dita liberdade que parece ser somente para uns, os que realmente gostam de computadores, pois, os outros ficam presos na resolução das dependências.
Dou-te só o exemplo de algumas aplicações que depois de instaladas, não as consegues remover porque o uninstaller dá erro. Isso é no mínimo ridículo.
hummmmm
Realmente isto é um problema que acontece com frequência, mas, não quer dizer que não tentemos melhorar o processo, e que mesmo que a Desistalação de um software dê erro, deverá ser possivel continuar e até mesmo remover o software do sistema.
Isso habitualmente acontecia do windows devido ao mais que famoso REGISTY que felizmente não temos no Linux. Quando havia algo no registry que não correspondia à realidade (algo já tinha apagado manualmente) o sistema não era inteligente o suficiente de continuar com a remoção, dando erro e passando a ser impossivel remover tal aplicativo.
Estou de acordo, está mal feito, é má programação como tanta coisa que também vejo noutros sistemas.
E no windows fazem sempre bem? Isso é uma piada right?
Ao ler a tua resposta uma pergunta surge sempre nos meus olhos: "Porque ele fala sempre no Window$??? Será que gosta assim tanto dele??"
Programar sob a plataforma Window$, Linux, Mac ou Unix é programar, e não e um menor programador que usa Visual Basic ou C++, são ambos programadores.
Tanto à má programação em Windows como Linux, se não nunca haveria correcções de correcções???
Mas não é sobre os erros e qual a melhor programação, o que quiz referir aqui é que à RPM que colocam ICONs no Menu, que colocam Icon no Desktop que apresentam uma lista dos pacotes em falta e consequente URL para fazer download, sei lá... uma infinidade de coisas. O que me pergunto é o porque de todos os RPM não serem assim?? Porque é os programadores não se dão ao trabalho de se preocupar o Deployment tanto como deram ao desenvolverem a aplicação????
Essa resposta foi respondida noutro POST de uma forma simples. Quem elabora esses pacotes não é o programador, mas, a distribuição.
Neste ponto uma pergunta se impõe: E a minha aplicação de gestão? Devei deixar na forma de Source-Code? Deverei criar um RPM ??? Deverei usar outro qualquer mecanismo? Deverei esperar que seja oficialmente aceite pela Distribuição ke habitualmente uso?
Tantas perguntas ... sim ... e cada vez que me respondem, outras surgem.
Não. É um paradigma diferente daquele a que o tio patinhas te habituou.
Eu estou habituado a pilotar carros de formula 1 nos jogos de computador, mas não os consigo pilotar na vida real. Será que deveria ser considerada má mecânica? Ou piloto maçarico?
Realmente, penso que não percebeste a questão de fundo e continuas a pensar que estou aqui a brincar aos programadores .... aceito a tua visão, mas, desde já te garanto que é errada.
Eu não estou habituado a nada.. estou simplesmente a tentar saber quais as opcções que tenho e infelizmente não me ajudaste em nada a não ser destruir. Essa não pode ser a atitude (minha opinião).
A tua analogia não podia ser mais errada, pois, a realidade que colocas é bem diferente do jogo.
Não falamos de paradigas, mas, sim de soluções reais.
Se pensarmos que a maioria das vezes usas as letras "n", "ã" e "o" para escrever "não", porque não as abolimos e criamos uma tecla "não"?
Apesar de não estar de acordo contigo, estou de acordo que não devemos criar a tecla "não". Simplesmente me parece que este processo podia ser bem mais optimizado com o objectivo de deplyment e mais nada, para que um qualquer info-excluido recebe um novo pacote e com o rato directamente do email que recebeu faça duplo-clique e instale a aplicação.
Simples, instala-lhe um sistema operativo para info-excluidos. Sugiro o Windows da Microsoft, és capaz de conhecer
É info-excluida mas não é burra. Pode ter as suas dificuldades em usar o Linux, mas, conhece as suas vantagens e o vai usando.
Eu lhe vou preparando as coisas de forma que com clicks do rato ela faça o que pretende, mas, o trabalho de preparação é meu, quando acho que podia ser dos programadores que desenvolvem as aplicações.
Lembra-te que normalmente em linux as aplicações nascem duma comichão que alguém sentiu vontade de coçar. Se ninguem se deu ao trabalho de fazer isso é porque provavelmente não fez comichão a ninguem (ou porque não faz sentido)
Tantas coisas que não fazem sentido e existem. Se calhar ninguém teve a coragem de combater esse cepticismo que mostras porque sabe que são batalhas perdidas até poder ganhar uma... umazinha .
Tentar aparecer com algo novo, ou fazer perguntas que fazem sentido (nem que seja para mim) faz com que todos batam no ceguinho mesmo sem pensar.
Em relação à tua 1º frase
Tomei a liberdade de responder pelo Mário.
Não sabia que eras um paladino que escreves e respondes pelos demais.... eheheheheh
|
| | | | Quando dou o exemplo da info-excluida que tenho em casa, tento saber como seria se eu chega-se a um conjunto de empresas como por exemplo os Agentes de Viagens e lhes propose-se Linux em vez de Windows e uma aplicação de gestão da agência.
Com a utilização do computador eles haveriam de querer melhorar o desktop, colocar as coisas como gostam, e para isso poderiam querer instalar aplicativos.
Quando dás o exemplo dos info-excluídos esqueces-te de que os sistemas operativos NÃO SÃO feitos para serem operados por essas personagens. Daí o conceito de utilizador root (que supostamente será alguém que tem mais do que 2 dias de experiencia e saiba instalar software) e os restantes utilizadores. No windows, TAMBÉM tens o "Administrator", mas infelizmente, por default todos os utilizadores são administradores.
Pessoas que olham para os computadores como uma ferramenta de trabalho e não como uma forma de vida, como muitos de nós fazemos, tem que poder ter mecanismos que lhes permita resolver a maioria dos seus problemas de uma forma simples e muitas vezes sem recorrer a grandes conhecimentos de informática.
Claro, claro. Esses mecanismos chamam-se administradores de sistemas.
Infelizmente (ou será felizmente?) os computadores não são tão fáceis de operar como as televisões. Numa televisão nunca podes estragar o aparelho utilizando o telecomando.
Estou a pensar criar uma empresa que vai desenvolver aplicativos de gestão para a plataforma Linux ou ainda que desenvolva aplicativos Cross-Platform, e uma das minhas principais preocupações é como é que faço o deployment das minhas aplicações (e dos patches) para pessoas que pouco percebem de computadores e de informática.
Neste caso menciono-te novamente o mundo windows. Normalmente, os escritóriozinhos de esquina que compram uma aplicação de gestão qualquer, precisam que o técnico vá lá instalar a dita cuja. Não vejo porque tem de ser diferente no Linux. Lembra-te que não estás a desenvolver televisões.
Se eu estivesse a desenvolver para pessoas, como os demais neste forum, que se interessam pela informática e pelos sistemas operativos e pela forma como trabalham, eu não teria qualquer problema em não pensar no deployment.
Deployment é a buzzword da semana?
[...] estou perfeitamente de acordo com essa liberdade, apesar de achar que podiamos fazer um pouco mais por essa dita liberdade que parece ser somente para uns, os que realmente gostam de computadores, pois, os outros ficam presos na resolução das dependências.
Epa, a liberdade de conduzir automóveis tambem parece ser somente para uns, os que realmente tiraram a carta de condução.
Acho que podiamos fazer mais um pouco por essa dita liberdade. Vamos fazer automóveis que se guiam sozinhos.
Ao ler a tua resposta uma pergunta surge sempre nos meus olhos: "Porque ele fala sempre no Window$??? Será que gosta assim tanto dele??"
A pergunta surge nos teus olhos? tens de tratar disso.
E não, não gosto nada de windows. Tu é que insistes que temos de transformar o linux numa coisa parecida com o windows.
o que quiz referir aqui é que à RPM que colocam ICONs no Menu, que colocam Icon no Desktop que apresentam uma lista dos pacotes em falta e consequente URL para fazer download, sei lá... uma infinidade de coisas
Vou voltar a repetir. Não há métodos standard para gerir icons no desktop, icon no menu, etc.
Cada window manager é como é. Não existe um standard. Eu uso um window manager sem icons, há quem use icons, há quem use desktops tridimensionais, há quem nem sequer tenha menus, ou quem não use desktop de todo. Queres prever todos os casos possíveis?
Quando muito podes meter "redhat com desktop gnome" nos requerimentos do software. Não eras o primeiro.
Essa resposta foi respondida noutro POST de uma forma simples. Quem elabora esses pacotes não é o programador, mas, a distribuição.
Claro. E ainda bem que é assim (apesar de não ser a norma). Senão era como no windows: cada aplicação instalava os DLL's onde queria e cada programador inventava um novo instalador manhoso.
Neste ponto uma pergunta se impõe: E a minha aplicação de gestão? Devei deixar na forma de Source-Code? Deverei criar um RPM ??? Deverei usar outro qualquer mecanismo? Deverei esperar que seja oficialmente aceite pela Distribuição ke habitualmente uso?
A melhor maneira é entrares pelo mundo do autoconf e automake. Odeio ambos, mas são a "norma em vigor". Depois é facil criares pacotes para qualquer distribuição.
Não inventes instaladores gráficos, porque nenhum administrador de sistemas que se preze vai permitir que se instale isso.
Não falamos de paradigas, mas, sim de soluções reais.
Ora aí está uma frase feita. Típico da malta "enterprise".
Tinhas futuro como CEO.
Simplesmente me parece que este processo podia ser bem mais optimizado com o objectivo de deplyment e mais nada, para que um qualquer info-excluido recebe um novo pacote e com o rato directamente do email que recebeu faça duplo-clique e instale a aplicação.
Parabéns, acabaste de inventar os virus informáticos.
>Simples, instala-lhe um sistema operativo para info-excluidos.
>Sugiro o Windows da Microsoft, és capaz de conhecer
...É info-excluida mas não é burra.
Nem eu disse isso. Se leres bem, eu disse "sistema operativo para info-excluidos" e não para burros. Ela pode até ser muito inteligente. Pode ser excelente médica, advogada ou whatever, mas não é administradora de sistemas.
Eu lhe vou preparando as coisas de forma que com clicks do rato ela faça o que pretende, mas, o trabalho de preparação é meu
Certo, chama-se a isso um administrador de sistemas.
...quando acho que podia ser dos programadores que desenvolvem as aplicações.
Errado.
Se calhar ninguém teve a coragem de combater esse cepticismo que mostras porque sabe que são batalhas perdidas até poder ganhar uma...
Não. Lembra-te que estás a falar de software livre. Se queres fazer um sistema que funcione como queres, tás à vontade, ninguem te impede.
Claro que se funciona de maneiras que vão potenciar o desastre, ninguém mais o vai utilizar. Pensa nisso.
>Tomei a liberdade de responder pelo Mário.
Não sabia que eras um paladino que escreves e respondes pelos demais.... eheheheheh
Paladino do Mário Valente? nahhh.
Normalmente nem costumo estar de acordo com as opiniões dele.
Só que o teu post estava mesmo a pedi-las. Não resisti.
|
| | | | Mais uma vez obrigado por voltares à discussão, mas, à alguns pontos que desejo refutar na tua retórica:
1º Não pretendo mudar o Linux para ser um Windows.
Pretendo somente perguntar aos presentes até que ponto acham que podem ter uma sistema mais destinado a info-excluidos, pessoas que pouco percebem de computadores. Pela tua resposta, se é info-excluido, só tem uma hipotese.... WINDOW$.
Bem, como podes ver estou em completo desacordo contigo. Penso que enquando essa atitude prevalecer o Linux nunca vai deixar de ser um SO para estar numa sala fechada a fornecer alguns serviços a um conjunto de pessoas que nem ousam chegar perto para não estragar com a sua estupidez.
Penso que o Linux (e suas distribuições) quer e deseja avançar para soluções mais "finas" ou "User Friendly" e encontra muitos entraves a essa evolução.
Quando falas da empresazinha da esquina, lembro que essas pessoas podem querer instalar a nova versão do Open Office, ou uma qualquer aplicação de Comunicações (aMSN, GAIM ou qualquer outro), e neste momento quem o queira fazer no Linux vai andar as aranhas.
2º Sim Deployment é a buzzword da semana ... so mês e se calhar mesmo do ano.
Não é tido em conta por quem programa ou por que elabora esses pacotes.
Quando falo nos Icons no menu, falo simplesmente de entradas no menu, não é necessário e obrigatorio que haja um icon.
Em WindowManager como o FluxBox, aparece o nome da aplicação, e é simplesmente isso que gostaria que o Instalador fizesse.
3º Função do Administrador de sistemas.
Bem, como o nome diz, ele é administrador do sistema e não necessáriamente a pessoa responsável por instalar ou não aplicativos de costumização nas máquinas.
Eu já trabalhei numa empresa que tinhamos a nosso cargo a rede de mais de 30 Agentes de Viagens, e a instalação de aplicativos era da nossa responsabilidade. Usavamos o PCAnyWhere para entrar nas redes dos clientes e configurar e instalar e manter os aplicativos instalados.
Enquanto eram poucos clientes, estas tarefa (administrador de sistema) era simples de implementar, mas, com dezenas de clientes, com os seus problemas mais incriveis, esta era uma tarefa para um verdadeiro "Golias".
Se ainda colocarmos no âmbito do administrador de sistemas a incumbência de tratar dos aplicativos de costumização do ambiente de trabalho.... bem ... acho que não faz sentido.
Se calhar na cabeça de alguma mente retorcida faça sentido, não na minha.
4º Penso que definitivamente temos que desmistificar a ideia que o Linux é para administradores de sistemas como dizes
Nem eu disse isso. Se leres bem, eu disse "sistema operativo para info-excluidos" e não para burros. Ela pode até ser muito inteligente. Pode ser excelente médica, advogada ou whatever, mas não é administradora de sistemas.
E como até pode ser inteligente, mas, como não administradora de sistemas não pode usar linux????
Acabem com essa ideia, e vamos avançar para um Linux em ambiente Desktop quer seja realmente simples de usar.
(())
Esqueleto
|
| | | | Pela tua resposta, se é info-excluido, só tem uma hipotese.... WINDOW$.
Não só. Tambem pode usar MacOS que é bastante user-friendly. Se calhar há mais, mas linux (ou unix) não faz parte da lista.
Penso que enquando essa atitude prevalecer o Linux nunca vai deixar de ser um SO para estar numa sala fechada a fornecer alguns serviços a um conjunto de pessoas que nem ousam chegar perto para não estragar com a sua estupidez.
Acabaste de descrever o paraíso.
Unix não foi pensado para ser simples. É um sistema operativo para técnicos.
MacOS e Windows já tem o publico target que referes.
NOTA: antes que alguém me apredeje, MacOS funciona bem com gente burra, mas também é muito mais do que um sistema operativo bonitinho :)
Em WindowManager como o FluxBox, aparece o nome da aplicação, e é simplesmente isso que gostaria que o Instalador fizesse.
Eu uso debian, e normalmente as aplicações de desktop adicionam uma entrada ao ficheiro de menus (que é partilhado por quase todos os window managers). Claro que ninguem te impede de criar um package que não o faça. Se quiseres podemos juntar uns quantos manos e batemos em todos os gajos que não o fizerem.
Bem, como o nome diz, ele é administrador do sistema e não necessáriamente a pessoa responsável por instalar ou não aplicativos de costumização nas máquinas.
Não só mas também.
Enquanto eram poucos clientes, estas tarefa (administrador de sistema) era simples de implementar, mas, com dezenas de clientes, com os seus problemas mais incriveis, esta era uma tarefa para um verdadeiro "Golias".
Sim, o windows tem a fama de ser impossivel de administrar. Mas isso é um problema do Windows e não da natureza do trabalho do administrador de sistemas. Há software aos pontapés para gerir clusters.
Os utilizadores NUNCA podem ter o poder de instalar. Senão vais ter o dobro do trabalho quando eles foderem o sistema operativo com a ultima versão do bonzy buddy, kazaa, porn dialers e tudo o que é spyware, malware, adware e virus.
Deves saber isso melhor do que eu.
E como até pode ser inteligente, mas, como não administradora de sistemas não pode usar linux????
Pode. Contigo no cargo de administrador de sistema.
Se lhe deres poder de root vais perder todas as vantagens que ganhaste ao fugir do windows. Ela VAI partir muita coisa, e nisso eu aposto o que tu quiseres.
Repito: unix não foi feito a pensar nos não-informáticos.
Para terminar:
Há os gnome's, kde's e afins que servem o propósito que referes. Há inclusivé interfaces gráficos para instalar/gerir RPM's, tudo a pensar nos não-técnicos. Se ainda não estão no ponto que queres, sugiro que te juntes às equipes de desenvolvimento dos mesmos em vez de andares para aqui a pregar que devemos transformar isto numa coisa simples para "quem não vive disto".
|
| | | | | Quando falas da empresazinha da esquina, lembro que essas pessoas podem querer instalar a nova versão do Open Office, ou uma qualquer aplicação de Comunicações (aMSN, GAIM ou qualquer outro), e neste momento quem o queira fazer no Linux vai andar as aranhas. Isso não é verdade!
Com a minha distribuição gasto poucos segundos nas operações que o sistema necessita para instalar software, depois disso o gestor de pacotes faz o download e instala o software escolhido. 2º Sim Deployment é a buzzword da semana ... so mês e se calhar mesmo do ano. Não é tido em conta por quem programa ou por que elabora esses pacotes. Mais uma vês isso não é verdade. O deployment das aplicações na minha distribuição é excelente, não tenho qualquer problema, existe de facto uma preocupação enorme com o deployment na minha distribuição.
As ferramentas que permitem um rapido e facil deployment existem, existem standards defenidos para facilitar o deployment, mas não podes obrigar ninguém a utiliza-las. Quando falo nos Icons no menu, falo simplesmente de entradas no menu, não é necessário e obrigatorio que haja um icon. Em WindowManager como o FluxBox, aparece o nome da aplicação, e é simplesmente isso que gostaria que o Instalador fizesse. Sempre que instalo um pacote de um software da minha distribuição susceptivel de ficar no menu, ele de facto fica lá. Bem, como o nome diz, ele é administrador do sistema e não necessáriamente a pessoa responsável por instalar ou não aplicativos de costumização nas máquinas. Qualquer administrador de sistemas que se preze limita ao máximo que os utilizadores possam instalar software e/ou o ambiente em que os utilizadores podem instalar software ou fazer qualquer outra alteração. Os utilizadores não são de confiança. Se ainda colocarmos no âmbito do administrador de sistemas a incumbência de tratar dos aplicativos de costumização do ambiente de trabalho.... bem ... acho que não faz sentido.
Se calhar na cabeça de alguma mente retorcida faça sentido, não na minha. Há situações (na minha opinião a maioria) em que a falta de conhecimentos do utilizador, pode levar a que essas tarefas tenham de ser pelo menos parcialmente executadas e limitas pelo administrador.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Eu estou habituado a pilotar carros de formula 1 nos jogos de computador,
longe vão os tempos em que saiam bons simuladores de F1 para PC :(
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | Mário, porque não à um instalador gráfico ??? Há, vide post meu abaixo sobre o Loki Installer. Cumprimentos Mario Valente
|
| | | | Sim .. vi ... vou olhar para ele com atenção.
Obrigado
|
| | | | Vamos lá colocar um caso:
Ora tens a tua aplicação de gestão de gambozinos e vais instala-la num linux qualquer.
Como a aplicação é muita gira, utiliza o loki installer e não uma porcaria dum gestor de pacotes para CLI.
A aplicação tem algumas dependencias. Digamos que usa 3 ou 4 libs. Como resolves isso?
Compilas estaticamente? Incluis as dependencias no pacote e caso já estejam no sistema operativo ficam duplicadas?
Tudo boas soluções, né?
Mas que se f*da, pelo menos tens um installer gráfico que te faz lembrar do Sistema Operativo Que Usavas Antes (tm) aka Microsoft.
É mais giro.
|
| | | | | Como a aplicação é muita gira, utiliza o loki installer e não uma porcaria dum gestor de pacotes para CLI. A aplicação tem algumas dependencias. Digamos que usa 3 ou 4 libs. Como resolves isso? Da mm maneira q o gestor de pacotes para CLI... Compilas estaticamente? Incluis as dependencias no pacote e caso já estejam no sistema operativo ficam duplicadas? O pacote pode incluir as dependencias e apenas as instalar caso seja necessario, nao criando duplicados. Cumprimentos Mario Valente
|
| | | | Como a aplicação é muita gira, utiliza o loki installer e não uma porcaria dum gestor de pacotes para CLI.
A aplicação tem algumas dependencias. Digamos que usa 3 ou 4 libs. Como resolves isso? Da mm maneira q o gestor de pacotes para CLI... Compilas estaticamente? Incluis as dependencias no pacote e caso já estejam no sistema operativo ficam duplicadas? O pacote pode incluir as dependencias e apenas as instalar caso seja necessario, nao criando duplicados. Cumprimentos Mario Valente
|
| | | | O pacote pode incluir as dependencias e apenas as instalar caso seja necessario, nao criando duplicados.
No caso dos gestores de pacotes de CLI, a unica maneira de poderes gerir eficazmente os pacotes instalados, é ter uma db com a lista de tudo o que está instalado e as dependencias, e não instalar nada por "outros métodos".
Se instalas uma lib compilando a source da mesma, o gestor de pacotes não faz a minima ideia de que ela está instalada (nem da versão).
Ora, partindo do principio que Loki não tenha interfaces para o dpkg, rpm, yast, portage e todos os outros gestores de pacotes do planeta, não terá maneira de saber o que está instalado.
Como resolves isso?
Como fazes se precisares de uma lib que por sua vez precisa de uma data de upgrades a outras libs que estão instaladas? Não é um caso raro.
Duplicas tudo num local separado para não quebrar nada? Sobrepões as que estão instaladas arriscando quebrar tudo (inclusivé a db do gestor de pacotes)?
Se tiveres uma aplicação que use libs bleeding edge, vais precisar de carregar todas as dependencias atrás, desde o libc às libs do gtk/qt (e respectivas milhares de dependências).
Não sei porquê, mas não me parece muito boa ideia.
É um preço muito alto a pagar em troca de um installer bonitinho.
|
| | | | | Devo dizer desde já q isto não é area de minha "especialidade" e interesse... No entanto... Nunca achei mto inteligente a gestao de pacotes por via de "db com lista de tudo o q está instalado e as dependencias e nao instalar nada por outros metodos". Claro q essa metodologia inviabiliza qq instalador standard; assim como inviabiliza o uso de pacotes de "origens" diversas; ou a instalacao à unha. Nao sei o que o Loki installer faz. Mas, respondendo directamente à tua questao "como resolves" parece-me q seria obvio q um instalador conhecesse a API de 2 ou 3 gestores de pacotes (os mais importantes, q representassem 80% das instalacoes) e checkasse a existencia das libs por via dessa API. No entanto, IMHO parece-me q o que faria mais sentido era um instalador pura e simplesmente testar, à lá ".\configure"/autoconf, a existencia de versoes de libs e funções especificas através de chamadas directas à função, instalando a lib caso fosse necessário. Algo tipo ldcheck mas sem sugerir, q fosse automatico... My 2 cents.... Cumprimentos Mario Valente
|
| | | | Claro q essa metodologia inviabiliza qq instalador standard; assim como inviabiliza o uso de pacotes de "origens" diversas; ou a instalacao à unha.
No caso da instalação à unha, podes sempre gerar tu mesmo um pacote a partir da source (desde que venha no formato autoconf/automake) com 2 ou 3 comandinhos.
É muito simples e é muito boa prática, porque assim tens sempre noção do que tens instalado e as respectivas versões (sem teres de guardar a source algures).
No entanto, IMHO parece-me q o que faria mais sentido era um instalador pura e simplesmente testar, à lá ".\configure"/autoconf, a existencia de versoes de libs e funções especificas através de chamadas directas à função, instalando a lib caso fosse necessário. Algo tipo ldcheck mas sem sugerir, q fosse automatico...
Sim, essa já me parece uma melhor sugestão, mas que infelizmente não funciona porque os gestores de pacotes não checkam as dependencias através do ldcheck.
Se instalares uma lib à unha e depois tentares instalar um pacote que dependa dessa lib, ele vai dar-te um erro de dependências, porque está a checkar pelo pacote da lib, e não a lib em si. O que até faz todo o sentido. Não só de libs são feitos os pacotes.
|
| | | | Desculpa, mas, gostaria de entender qual o teu problema em tentar encontrar uma solução.
Se tens algum problema com a utilização de um processo de instalação Visual, já te disse que estas no teu direito, mas, fazer disso um "pé de vento" porque alguém acha que isso é importante, por favor... Onde está a liberdade que tanto apregoas????
Eu não pretendo que em Linux tenha que haver impertrivelmente um Instalador visual para linux, se calhar posso resolver o problema com o RPM, mas, apresenta-me soluções para o meu problema.
Esta tua atitude de achares que como ninguém ecetou tal projecto, achares que não é necessário não me resolve o problema.
Em relação ao problema propriamente dito, se eu te soubesse resolver o problema que colocas se calhar fazia eu um Installer para linux que detectasse se as libs estão instaladas e instalasse se não existisse ou usava a instalada.
Mais uma vez vens tu falar em Windows.... eu nunca falei em windows.. só perguntei que "Fazedores" de pacotes à para linux... à algum que se possa utilizar no X ou são todos utilizador na Prompt ????
A pergunta é simples .. e a resposta ainda é mais, e a conversa acaba aqui.
E seu eu quizesse colocar nos pacotes de distribuição todas as dependncias ??? qual é o prob ?? É uma decisão minha e não tua.
(())
Esqueleto
|
| | | | Desculpa, mas, gostaria de entender qual o teu problema em tentar encontrar uma solução.
Uma solução para o quê exactamente? Não teres um instalador bonito?
Eu não pretendo que em Linux tenha que haver impertrivelmente um Instalador visual para linux, se calhar posso resolver o problema com o RPM, mas, apresenta-me soluções para o meu problema.
A solução para o teu problema é utilizares primeiro o RPM para poderes chegar à conclusão de que não precisas de bonecos, nem de reinventar a roda.
Esta tua atitude de achares que como ninguém ecetou tal projecto, achares que não é necessário não me resolve o problema.
Novamente, qual é o teu problema? Queres um instalador gráfico porque é bonito?
Em relação ao problema propriamente dito, se eu te soubesse resolver o problema que colocas se calhar fazia eu um Installer para linux que detectasse se as libs estão instaladas e instalasse se não existisse ou usava a instalada.
Se tu soubesses resolver o problema que coloquei eras Deus. Quanto ao resto da frase, sugiro que leias a resposta que dei ao mvalente neste mesmo thread.
Mais uma vez vens tu falar em Windows.... eu nunca falei em windows.. só perguntei que "Fazedores" de pacotes à para linux... à algum que se possa utilizar no X ou são todos utilizador na Prompt ????
E onde foi que viste um instalador visual como o que queres? uh? Se calhar foi no Windows não? No mesmo windows onde aprendeste o termo "prompt".
Tu mesmo falaste em Wise e Install Shield (que por acaso até são soluções comerciais, sugiro-te outros: InnoSetup e NSIS). A menos que os ditos cujos tenham sido portados para outras plataformas, da ultima vez que vi funcionavam em Windows.
Sugestão: RTFM primeiro, e depois coloca as duvidas existenciais que restarem.
Se tanto insistes em ter "ferramentas visuais" sugiro que as procures no google.
Para o teu "problema" específico, sugiro-te isto.
A pergunta é simples .. e a resposta ainda é mais, e a conversa acaba aqui.
Sim, acho que já respondi o suficiente.
E seu eu quizesse colocar nos pacotes de distribuição todas as dependncias ??? qual é o prob ?? É uma decisão minha e não tua.
Claro. Nesse caso sempre podes fazer um instalador com 700Mb. Levas a distribuição inteira atrás. É uma excelente solução. Not.
|
| | | | | «Mário, porque não à um instalador gráfico ???» Pá tu tens uma pancada por instaladores. Já no pt.comp.so.linux estás sempre a falar disso. « algo que defina um script de instalação, procure dependências, as instale, que coloca icons no Desktop, na QuickBar e um no menu Start (como se chama ni KDE e GNOME????)» Cada distribuição de GNU/Linux funciona de maneira ligeiramente diferente e cada ambiente de desktop também funciona de maneira diferente, isto agrava-se quando as distribuições não cumprem standards como o Linux Standard Base.
É praticamente impossível fazer isso que tu dizes, por isso é que as varias distribuições têm os seus próprios repositórios de software. «Para windows temos diversas ferramentes como o Wise, Install Shield e outros, mas, para linux, ou compilamos tudo ou não.» Para window$ cada software se instala de uma maneira diferente, o que é uma chatice para os utilizadores, por não haver um procedimento padronizado. Em GNU/Linux a melhor forma de instalar software para quem não tem muitos conhecimentos e não quer ter trabalho é utilizar o gestor de pacotes da sua distribuição, que frequentemente têm front-ends gráficos muito mais simples de utilizar do que os instaladores para window$. Alias muitos destes front-ends fazem o download e a instalação do software (incluindo resolução de dependências), poupando-te o trabalho de teres de fazer o download do software e a resolução de dependências. «Sei que ainda à o RPM» E não só o RPM como uma quantidade de gestores de pacotes superiores ao RPM. «, mas, os programadores que os desenvolvem nem sempre os terminam .. nem os fazem da melhor forma. Uma vez instalei um soft que no final nem sabia qual o binário para executar... estas práticas não deveriam ser consideradas má programação ???? Ou será que o Deployment não é considerado programação ?????» No mundo do Software Livre, principalmente no mundo *nix o deployment, nem sempre é uma tarefa do developer, alias quase nunca é. É uma tarefa que normalmente cabe a que distribui software (por exemplo as distribuições de GNU/Linux). «Se pensarmos que a maioria das vezes (muitos %) para compilar uma source basta fazer "./configure && make && make install", (como root), porque é que este processo não está mais optimizado num só????» Não nem sempre basta isso, por vezes tens outras coisas para fazer como resolver dependências. Mas para quê andar a compilar quando tens pacotes binários? «Estou claro a pensar na info-excluida que tenho em casa que pode até encontrar algo na NET que gostaria de colocar no linux, e ela para instalar tem sempre que efecturar diversas operações.
Será pedir demais uma certa automatização destes processos ??????» Esse processos e outros já estão automatizados de forma melhor do quem em window$.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Para window$ cada software se instala de uma maneira diferente, o que é uma chatice para os utilizadores, por não haver um procedimento padronizado
Mais padrão que... Next, Next, Next, Finish (e a mensagem do costume: Reboot the computer now?), Yes.
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | Bem, agora já tenho mais comparsas a recomendar o Python :-) E a tendência será para aumentar.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | .. sou suspeito.
Mas continuo a afirmar que o python è excelente. Ainda não me deixou mal onde precisei, excelente em quase tudo (excepto velocidade onde perde para o C/C++, mas visto que estas não constam da lista..) e com a vantagem de ser um projecto d S.L. estavel e (vá là atirem pedras se poderem) "production ready".
Ao contrario do que muitos pensam, a variedade (leia-se "falta de standardização" em resposta a posts anteriores) não è uma falha, mas sim uma vantagem. Existem varios bindings para varias livrarias (bibliotecas, se preferirem màs traduções) gráficas (GTK+, QT, wxWindows, FLTK, XUL, etc..), bases de dados (RDBMS, ODBC e se quiserem incluir nesta categoria xml) entre outras funções, que se não chegarem podem sempre ser extendidas ou criadas quer com python quer em C.
Mais não digo pois existe excelente documentação por ai na net.
Já agora, de realçar è também a curva de aprendisagem, que comparada com qualquer outra linguagem que eu conheça, inclusivé BASIC, è mínima.
Cumprimentos a todos.
|
| | | | | | | excepto velocidade onde perde para o C/C++ e perde para o Java. Java deixa o Python a comer pó. esta é a realidade.
|
| | | | E já agora tens algum benchmark que demonstre isso e que não seja feito pela SUN ou a mando da mesma?
É que apesar do que se diz, ainda hoje as aplicações em Java demoram a arrancar, comem montes de memória continuam a ser gráficamente lentas (tipo mudanças de menus, etc...) e tendem a ser gráficamente desagradaveis (em termos de aspecto).
Digo isto baseado em ver aplicações Java a correr em Linux...
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | | Java deixa o Python a comer pó. esta é a realidade. Não é. Cumprimentos Mario Valente
|
| | | | Achei isto interessante:
python 0.04 1.84 3.67 5.47 7.31
java 0.55 27.97 56.88 84.32 114.72
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | usando uma expressão que será conhecida do leitão "fuckin' hell"! Não arranjas uns testes mais recentes?
Comparação da treta por comparação da treta, toma lá esta: http://osnews.com/story.php?news_id =5602&page=3
Isto leva-nos a pensar o quê? Que benchmarks é como um par de tomates, qualquer c*r*lho tem um!
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | este benchmark mostra a supremacia arrasadora do Java sobre Python em termos de desempenho. quanto ao aspecto dos interfaces gráficos, isso não tem que ser assim. por exemplo, o novo applet de entrega do IRS está com um interface muito fixe.
|
| | | | | este benchmark Tu tens un benchmark; eu tenho outro. Portanto já se colocam algumas duvidas se a realidade É que o Java deixa o Python a comer pó :-)... Reformulacao da tua anterior informacao absolutista: em *algumas* coisas o Java deixa o Python a comer pó; noutras o Python deixa o Java a comer pó; o que só vem confirmar que é como o Linux vs Windows: não há nenhuma ferramenta perfeita para tudo e devemos adequar a sua escolha ao problema. Cumprimentos Mario Valente
|
| | | | Boas.
"Reformulacao da tua anterior informacao absolutista: em *algumas* coisas o Java deixa o Python a comer pó; noutras o Python deixa o Java a comer pó;"
Nem de propósito, o Guido numa das últimas palestras que deu salientou o facto de que as próximas versões de python teriam que ser mais performantes:
http://www.xml.com/pub/a/2004/03/31/pycon.html
(excelente artigo)
@261, Nbk
|
| | | | E o que te leva a concluir dai que o java é mais rápido?
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Respondendo às tuas ultimas perguntas:
Para crear icons nos menus basta seguir os standards do freedesktop.org (e também não doi ver o que diz o LSB sobre isto..).
Para executar rotinas post/pre-install também podes usar um script python quase como um './configure' (desculpem a analogia foleira).
Para fazeres algo tipo um instalador .exe em linux tens o exemplo dos ficheiros .run da nvidia (source sob GPL ;) e o antigo update-tool da loki que ainda anda prai, ou podes criar tu mesmo algo do genero (que è facilmente duplicavel em python).
Axo que desta vez è tudo. Abraços!
|
| | | | | | | Talvez alguns de vós achem interessante os uma conversa (num forum publico) recente entre individualidades do mundo java, python e outros..
http://www.gia.ist.utl.pt/~aml/promoting-lisp.html
|
| | | | Python para o business logic e object pascal/delphi para construção de user interfaces, interacção com o sistema operativo, etc. Conectas object pascal com python através do Python for Delphi.
Dado que tens o core da aplicação em python é facil dares-lhe o uso que queiras. O object pascal é apenas uma das escolhas para acederes às tuas classes python. Tens java, c++, php, etc... Portanto não estas limitado em termos de ambientes onde a tua plataforma poderá correr. Pode ser web, desktop, etc.
Depois tens sempre Lisp...
|
| | | | No post não dizes nada acerca do projecto em causa. Já li um comentário teu em que referes que um exemplo do que queres é uma aplicação de gestão comercial com interface gráfico e potencialmente com interface web, também.
De qualquer modo, com base no tipo de perguntas que colocas penso que:
- Não conheces nenhum dos ambientes que falas, e;
- es muito novo e/ou;
- não és programador e/ou;
- és um gestor interessado em tecnologia.
(Não estou a falar mal de ti! Mas, lendo as tuas perguntas e os teus objectivos, só posso depreender que tens experiência técnica zero nestes tópicos e em linux)
Por isso vou responder baseado no "ouvinte" e não baseado no teu projecto. Três hipoteses:
1) Se és tu que vais desenvolver usa o python com os bindings QT. Em termos de opensource não deves encontrar nada mais simples. Se te deres mal tenta o kylix ou o VB...
2) Se tens alguém que vai desenvolver isso (ou vais contratar), usa o ambiente a que esse(s) programador está habituado. Não é boa ideia perder tempo com as ferramentas quando podes estar a trabalhar...
3) Pede vários orçamentos detalhados do projecto e depois vê o que cada empresa propõe tanto para a "versão 1" como para a manutenção ou custo/hora. Analisa as propostas e decide por uma empresa (e não pelas ferramentas).
---
Em relação aos "instaladores para linux" e porque é que "o meu icon não aparece na desktop" isso é assunto digno de outra thread :>
paz,
ratao |
| | | | | | | Se te deres mal tenta o kylix ou o VB... he he, estás a ser mauzinho... usa o ambiente a que esse(s) programador está habituado. Não é boa ideia perder tempo com as ferramentas quando podes estar a trabalhar
Isso não é bem verdade , a escolha da linguagem é muito importante, para um programador entrar na rotina de uma nova linguagem pode durar uma ou duas semanas (ou um ou dois dias no caso do python ;)) e esse tempo num projecto de médio/longo prazo não é importante relativamente às consequências que podem advir da escolha de uma linguagem inapropriada. Por exemplo se o programador estiver habituado a PHP e começar a fazer o projecto em PHP, podes ter a certeza que quando o projecto começar a crescer vai perder muito mais do que o tempo que levaria a adaptar-se a uma nova linguagem só para conseguir manter o projecto consistente e a funcionar (dou o PHP como exemplo mas há linguagens piores).
Como conclusão eu aconselharia para o estilo de projecto descrito a não usar outra coisa que não fosse Python ou Java, a minha opinião pessoal é, como já se deve ter tornado evidente o Python, mas Java apesar de na minha opinião ser inferior é a outra alternativa.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Digo sim à tua primeira hipotese:
Não conheces nenhum dos ambientes que falas
Apesar de já algum tempo usar linux como desktop e nenhum dos computadores em casa terem Windows, pouco tenho feito em termos de desenvolvimento.
Sou programador de VB e agora de VB .NET desde à 8 anos e desta plataforma estou farto. Já fiz aplicativos que fazem de tudo nesta linguagem e ela não me traz nada de novo.
Desde à 2 anos que tenho o Linux como servidor de rede em casa, e desde Junho do ano passado como Desktop.
Tenho a certeza que a utilização destas novas tecnologias no mundo empresarial traz as suas vantagens, mas, o sistema ainda não esta desenvolvido o suficiente para ser considerado acabado em diversos pontos e 1 deles é precisamente o Deployment.
Claro que posso estar enganado e o RPM fazer muito mais do que penso, ou ainda não ser uma ideia generalizada de desenvolver algo que ajude a minorizar o processe de Package e Deployment de uma aplicação.
Vejo que o que falta essencialmente na comunidade Open Source é massa crítica que tenha um pensamento forma sobre estas questões e ainda um conjuntos de aplicativos que sejam compativeis com as diversas plataformas.
Infelizmente não sou assim tão pensador quanto isso, e escro ainda pior, mas, sou critico. Critico o que acho que está mal, mesmo que isso não seja o acordo do resto da manada que continua a avançar impiedosamente contra a Ravina.
Não pretendo desenvolver um virus (claro) que seja executado a partir de 1 email... claro que não, foi simplesmente um exemplo do que gostaria que acontecesse.
Em relação à linguagem de programação, penso que o Python é o concesso geral seguido do Java e um ou outro elemento referiram o Mono em respostas envoltas em polémica. Polémica que não entendo, pois, como amantes do mundo do Software livre não deveriam estar a propor JAVA que é propriedade de uma empresa, mas, pelo que li só querem software livre ou Software pago que não seja Micro$oft.
Não vou contratar ninguém, o que fizer faço eu mesmo e a minha equipa e gostaria de usar sempre ferramentas OpenSource tanto como compilador como IDE de desenvolvimento, por isso, Kylix e VB estão completamente fora de questão.
Queria para finalizar fazer reafirmar a tua frase
só posso depreender que tens experiência técnica zero nestes tópicos e em linux
Sim nos apectos que pergunto, a minha experiência é ZERO.
Tirando PHP nunca desenvolvi para linux e quero fazer. Não sabia como começar, mas, agora tenho vários pontos de partida importantes, especialmente da linguagem e algumas livrarias que devo usar.
Em relação ao Installer... praticamente nada.
Lembro aos presentes que quando instalamos um Oracle ou o Zend Studio temos um installer que nos faz esse trabalho.
Esse installer foi desenvolvido de propósito para instalar essas aplicações. Penso que podia haver um standard para instalações de uma forma gráfica e não entendo porque à tanta relutância neste ponto.... mas vou saber .... não irei parar enquando não souber.
(())
Esqueleto
|
| | | | Polémica que não entendo, pois, como amantes do mundo do Software livre não deveriam estar a propor JAVA que é propriedade de uma empresa
O Java não é software livre mas é software aberto que corre em diversas plataformas de diversas empresas, desde o Symbian aos Solaris, passado pelo Linux nas mais diversas arquitecturas. O .NET corre em telemóveis e x86 mas apenas em Windows, além de que é uma ferramenta de lock-in mais do que qualquer outra coisa (não esquecer que a Microsoft só seguiu para o .NET quando a Sun os processou por estarem a aplicar o "embrace, extend, extinguish" ao Java).
Se em vez da Sun o Java fosse da Microsoft (nos mesmos termos em que existe actualmente) eu recomendá-lo-ia na mesma.
-- Carlos Rodrigues
|
| | | | Obrigado pelo esclarecimento, mas, não creio que seja a ideia generalizada.
(())
Esqueleto
|
| | | | Ouve, o que tu queres é mesmo Java+SWT... Irão dizer que o SWT é mau porque não chega a todas as plataformas mas... o SWT chega ao Windows ao Linux e ao Mac OS X. Conheces mais alguma plataforma desktop com saída?
Em Windows tem o L&F de uma aplicação Windows, em Linux o L&F de um GTK ou o Swing (não sei se depois isto permite usar qualquer L&F do Swing como o Motif ou o Metal) e em MacOS X o Carbon.
Se me perguntas, é razão mais que suficiente para apostar neste caminho!
O Eclipse é mais que bom e a versão 3.0 será ainda melhor por isso mantem-te atento.
Ainda sobre o SWT talvez ainda este ano - wishfull thinking - venha cá para fora o binding para QT. Mas não tens de te preocupar com isso porque não é necessário alterar o código.
Com o Java, ainda te permite um monte de coisas no(s) servidor(es) - umas mais potentes, outras menos - como por exemplo transacções, beans, RMI, enfim, N funcionalidades que se decidires usar estão ali, à mão de semear. E tudo isso tem qualidade mais que comprovada.
Em python será assim?
---
Conformity is the jailer of freedom and the enemy of growth.
--John F. Kennedy |
| | | | | Sou programador de VB e agora de VB .NET desde à 8 anos Nesse caso tb deves levar em conta o Visual Python Cumprimentos Mario Valente
|
| | | | | especialmente da linguagem e algumas livrarias que devo usar Sugiro que para a parte gráfica se usares python, experimentes o Tkinter, não é o meu toolkit preferido mas é o que vem com a distribuição base do python, tornando assim mais fácil a instalação, se isso não for um ponto importante então aconselho o pygtk.
"Absence is to love what wind is to fire. It extinguishes the small, it enkindles the great." |
| | | | Este é actualmente um dos pontos fracos do Python (a sua importância depende dos gostos), a escolha a nível de GUIs pode ser resumida a:
- pygtk - funciona muito bem em unix; funciona bem em Windows mas com as limitações em termos de integração visual com o resto do sistema ("culpa" do GTK);
- PyQT - funciona muito bem em unix; suponho que funciona muito bem em Windows (nunca experimentei) mas o QT em Windows paga-se, e bem;
- wxPython - pelo que ouvi funciona bem em unix e Windows; fácil de instalar no Windows mas com algumas dependências em unix (wxPython -> wxGTK) que podem tornar a sua instalação chata (as dependências são um bocado grandes -- isso tem sido uma razão para eu não experimentar algumas aplicações Python que o usam; o meu interesse nelas não era suficiente para encher a minha instalação com aquela tralha toda);
- Tkinter - funciona bem onde o Python existe; Aceitável em Windows mas feio o suficiente para rachar pedra em unix... (o Tk sempre foi feio).
Eu diria então que o Tkinter é bom para prototipagem pois é standard e as aplicações resultantes não vão durar muito tempo anyway. Serve para experiências.
Dos restantes eu escolheria o pygtk (ou o PyQt, mas este parece-me ser menos usado) se a aplicação é para correr em unix e há poucas hipóteses de ser usada em Windows (se for necessário pode correr na mesma) ou então wxPython se é importante que corra bem em ambas as plataformas.
-- Carlos Rodrigues
|
| | | | | Relativamente a este assunto, Eric Raymond fez um post em Outubro de 2000 advogando o abandono do Tkinter como toolkit distribuído com o Python, sugerindo o wxPython. Cumps.
"mudem de rumo, já lá vem outro carreiro" |
| | | | usa o python com os bindings QT. Em termos de opensource não deves encontrar nada mais simples.
Encontra, Python com os bindings de GTK2 (pygtk).
-- Carlos Rodrigues
|
| | | | | Neste momento no que diz respeito ao desenvolvimento de software a plataforma começa a ter mais importância do que a linguagem. A linguagem pode ser boa mas cada vez torna-se mais necessário suporte para áreas como: componentes, persistência, suporte para transacções, suporte para a web, WebServices,etc A escolha da plataforma/linguagem depende muito do que se quer: se é uma programa de 20 linhas, uma aplicação para a loja da esquina ou um sistema de informação. O que pode ir desde de pegar no VisualBasic até utilizar um servidor aplicacional. No que diz respeito ao J2EE o modelo é bom, o .NET tem uma boa implementação (em algumas áreas, pelo menos) e o Phyton apesar de implementar: coisas como componentes e persistência (eu n conheco o Phyton muito bem) não sei se estará neste campeonato, pelos menos por agora. Flame me :))
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | Na minha opinião é Java com o IDE Netbeans. acredita! eu não percebo nada de programação, mas com o Netbeans programar(java) nunca foi tão informativo, facil e facil de aprender. Viva o Netbeans !!
|
| | | | Ontem lembrei-me de experimentar o python. Fiz um hello-world e depois compilei-o para bytecode, funcionou muito bem.
Depois fiz outro hello-world, desta vez com wxPython. Compilei tambem para bytecode e funcionou igualmente bem.
Pequeno pormenor: para que este segundo exemplo corra noutra máquina, preciso de ter os bindings wxPython no destino.
A questão é: não há maneira de compilar estáticamente? Ou alguma maneira de eu saber quais as dependencias (e sub-dependencias) que tenho de meter no "pacote" para poder distribuir?
|
| |
|
