| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Se calhar aconselhava-te a ter mais cuidado com outras ferramentas do que com a linguagem propriamente dita. Por exemplo, a escolha do GUI builder e da base de dados podem ser mais importantes do que a linguagem porque nesse tipo de aplicações perde-se mais tempo a desenhar a interface com o utilizador e a manipular dados do que a desenvolver algoritmos, etc.
|
| | | | | | Concordo plenamente, estes são realmente os dois pontos mais importantes a ter em conta quando se desenvolve uma aplicação deste tipo.
As minhas escolhas foram:
- Base de Dados - PostgreSQL - free as in speech and beer e com features só disponiveis em alternativas comerciais que custam muitos ¤¤¤¤, saliento o facto de ser uma ORDBMS, extremamente útil neste tipo de aplicações.
- GUI Builder/Toolkit - wxWindows - also free as in beer and speech, multiplataforma, completo, API bem estruturada e relativamente bem documentada, native look and feel, disponível em varias linguagens (C++, Python, BASIC, LUA, JavaScript, etc). Como GUI Builder uso o DialogBlocks do Julian Smart, apesar de ser comercial vale certamente o preço simbólico de 50¤
Este projecto merece muito mais crédito do que aquele que lhe é habitualmente atribuido.
|
| | | | Peço imensa desculpa pela ignorância, mas agora aproveito para perguntar:
Porque é que se diz "free as in speech and beer"? (livre como o diálogo e como a cerveja)
A intenção é rimar (free, beer) ou o significado é outro?
Obrigado e mais uma vez desculpem a 'lamice'...
---
tyFUZZ |
| | | | Não se diz "free as in speech and beer" mas sim "free as in speech not as in beer".
E isto significa "livre como o discurso e não grátis como a cerveja", usa-se para distinguir que o software livre (free) não é necessáriamente grátis (free).
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| | | | O que não invalida que aquilo que eu disse está correcto, tanto o wxWindows como o PostgreSQL são free as in speech (software livre) e são grátis (as in beer).
|
| | | | eheh... obrigado a todos pela resposta! Posso dizer que fiquei elucidado!
Mas já agora, só uma achazinha: desde quando é que a cerveja é grátis?!?
---
tyFUZZ |
| | | | segundo dizem os entendidos, free pode ter varios significados
|
| | | | | Acho que interpretaram mal o que ele queria dizer:
Ele queria dizer 'free as in speech', porque é Software Livre, e 'free beer' porque vai ser grátis, isto é, sem custo monetário.
Dominus vobiscum |
| | | | Exacto:
``Free software'' is a matter of liberty, not price. To understand the concept, you should think of ``free'' as in ``free speech,'' not as in ``free beer.''
---
tyFUZZ |
| | | | Mas essa tua primeira escolha talvez seja um erro não?
Isto é, ao criar um software dessa dimensão deverá ser cross-compatible com as mais variadas db's, não vá o cliente XPTO ter uma base de dados ranhosa que usa meticulosamente para guardar as suas informações e não está disposto a dispender mais cobres.
Parabéns pelo projecto, espero que tudo corra bem e possam lucrar com ele :-)
Dominus vobiscum |
| | | | Mas essa tua primeira escolha talvez seja um erro não?
Quanto a mim é uma escolha do mal menor, ou optava por tornar a aplicação compatível com varios SGBDS tendo de limitar o meu SQL aquilo que todos os engines suportam ou escolhia unicamente um que suportasse todas as funcionalidades que eu preciso e pretendo utilizar.
Para mim o mal menor é a segunda opção, existe sempre a possibilidade de portares os dados do cliente para o novo SGBD, facilita-te a implementação do projecto e podes utilizar aquelas features do SQL que nem todos os engines suportam e que te tornam a vida mais fácil.
Acredita que sei do que falo, depois de quase 3 anos a desenvolver software de gestão com DB's em Access davas os olhos da cara para poder utilizar um engine com suporte de SQL mais completo.
Devo também acrescentar que esta minha escolha foi também influenciada pelo facto de o projecto ser para mim apenas um passatempo onde aplico e testo novos conceitos e ideias que me vão aparecendo, com fins mais didaticos que comerciais, não deixando no entanto de assumir proporções sérias.
Parabéns pelo projecto, espero que tudo corra bem e possam lucrar com ele :-)
Obrigado pela força, servirá quanto mais não seja para por em pratica algumas ideias minhas, quanto a poder lucar com ele, como já disse, por enquanto não é esse o objectivo mas... é sempre bem vindo :)
|
| | | | Acho que te esqueceste de referir uma coisa: a linguagem com que a equipa de programação de sente mais à vontade.
Na minha opinião, qualquer linguagem imperativa ou orientada aos objectos serve, é sé escolher a água em que os programadores gostam mais de nadar!
-=[ Rui Lameiro ]=- |
| | | | Eu uso C++ e desenvolvo com o Qt Designer.
Plenamente satisfeito.
Fazer uma aplicação de gestão é mais dificil do que parece :)
Gestão de Compras/Stock/ é o que me dá mais dores de cabeça
Se alguém tiver dúvidas será um prazer ajudar.
|
| | | | | | Não esquecer uma coisa importante neste caso: o QT requer uma licença para uso comercial e usar o QT Free durante o desenvolvimento, pagando a licença na altura do lançamento da aplicação, não serve. Como se pode ver o licenciamento do QT ainda tem issues (por outro lado é uma excelente plataforma).
Q: Can we use the Free Edition while developing our non-free application and then purchase commercial licenses when we start to sell it?
A: No. The Free Edition license applies to the development phase - anything developed without Professional or Enterprise Edition licenses must be released as free/open source software.
-- Carlos Rodrigues
|
| | | | Por outro lado, se se pretender desenvolver código de gestão comercial mas sob GPL (com distribuição do código fonte da aplicação, portanto) podes usar QT (apesar do RMS não gostar muito da ideia).
Não há razão para não considerar esta alternativa, quando se diz que se pretende criar uma aplicação de gestão comercial para Linux... Claro que ir pela via GPL implica ainda a possibilidade de utilizar outro código GPL que já esteja desenvolvido para fazer a mesma coisa noutras aplicações.
Cumps, JB |
| | | | A licença é um bocado obscura nesse ponto. Mas se esse "COMERCIAL" significar que o produto vai ser comercial, é um bom investimento pagar a licença. A vantagem de o mesmo código poder ser compilado nas plataformas mais conhecidas parece-me grande. Assim o cliente pode compar a versão Linux, Mac ou Win32.
Nem será preciso discutir a qualidade da documentação do Qt e o produto é muito bom para base de dados.
|
| | | | | A GPL permite-te utilizar o software seja para que fim for.
A questão do licensiamento das QT, não é a respeito de utilizações comerciais, mas sim a utilização das QT com software proprietário.
«They that give up liberty to obtain a little temporary safety, deserve neither liberty nor safety» Benjamim Franklin (1706-1790) |
| | | | Não esquecer uma coisa importante neste caso: o QT requer uma licença para uso comercial e usar o QT Free durante o desenvolvimento, pagando a licença na altura do lançamento da aplicação, não serve. Como se pode ver o licenciamento do QT ainda tem issues (por outro lado é uma excelente plataforma). A TrollTech aproveita-se da confusão entre Comercial e Proprietário intencionalmente, para obter proveito extra.
Desde que a aplicação seja publicada sob a licença GNU GPL pode perfeitamente ser vendida e comercializada com a QT livre (aparentemente para GNU/Linux e poucos mais sistemas livres, mas os outros também não interessam ;)).
|
| | | | Desta vez foi mesmo uma questão de trocar "comercial" por "proprietário". :)
-- Carlos Rodrigues
|
| | | | kerem almoços grátis, não?
a licença não é assim tão cara...
---
Que Bush vos abençoe. |
| | | | É cara se começares a desenvolver o programa ainda sem saber se este vai ser GPL ou proprietário. Nestes casos tens de pagar a licença "just in case". É claro que é isto mesmo que a Trolltech quer quando não permite iniciar o desenvolvimento de programas proprietários com o QT Free Edition, os projectos que falham e os indecisos também são obrigados a pagar (se se quiserem manter legais, claro).
-- Carlos Rodrigues
|
| | | | Boas.
"É necessário ter em linha de conta:
1. Tempo de desenvovimento
2. Manutenção"
Se fossem só esses dois pontos a ter em conta, eu aconselharia python, pois é bastante fácil de manter (o código é extremamente legível, mesmo o mais complicado), e o tempo de desenvolvimento é bem curto.
Um dos problemas é a quase inexistência de bons IDE's para desenvolver interfaces gráficas ( vulgo GUI's ). Nada que não se combata com um par de olhos, uma mão cheio de neurónios e duas máos, claro.
@138, Nbk
|
| | | | | | funny, agora é que li este post e reparo que podia ter poupado umas palavras :-)
quanto a GUI toolkits para python, o Tkinter deixa um pouco a desejar para a integração com o GTK não é de toda má (ver www.PyGTK.org)
Hybriz, the god's dog
|
| | | | >É necessário ter em linha de conta:
>1. Tempo de desenvovimento
>2. Manutenção
se é só para ter em conta estes dois aspectos, aconselho vivamente Python com um toolkit qualquer para o GUI (PyGTK ñ é mau).
Python é bastante facil e a latência entre ideia teorica e ideia implementada é diminuta.
Sendo a linguagem simples e flexivel que é, a nivel de manutenção torna-se bastante agradavel.
Hybriz, the god's dog
|
| | | | | | | Ao invés de Tk (que é feito) e GTK (que dizem correr em windows, mas não sei se adopta o aspecto nativo), experimenta o wxWindows... Eu concordo na utilização de python. Para construir GUIs, é do melhor, pois o impacto de velocidade é mínimo, [quase] imperceptível ao utilizador. Nota: a vantagem de wxWindows, é ser Cross-Platform. wxPython
|
| | | | | Olá. Outra vantagem de utilizar wxWindows parece ser ter um IDE pronto a usar: Boa-constructor.
"mudem de rumo, já lá vem outro carreiro" |
| | | | o wxWindows é tao cross-plataform como o Tkinter :-) de qualquer modo, apenas vejo vantagens em usar wxWindows por causa do IDE.
Hybriz, the god's dog
|
| | | | > que dizem correr em windows, mas não sei se adopta o aspecto nativo
http://gtk-wimp.sourceforge.net/
|
| | | | O wxWindows/GTK já usa o GTK 2, ou ainda usa o GTK 1.2?
Cumps.
|
| | | | Dá para escolher na compilaçao, embora o suporte de GTK2 ainda nao seja considerado absolutamente estável.
|
| | | | Embora isso seja verdade utilizo o wxGTK CVS compilado com o gtk2 sem problemas de maior, apenas alguns GTK-warnings na consola de vez em quando, o que até mesmo algumas aplicações GTK2-only produzem.
|
| | | | Python é bastante fácil em termos de aprendizagem, o desenvolvimento é rápido, parece que a linguagem não se pôe no caminho do programador (como acontece frequentemente em outras linguagens).
Tem um sistema de módulos que facilita a organização necessária a um projecto médio/grande. As classes em Python também ajudam não só na organização mas na própria flexibilidade da linguagem, já que quase tudo são objectos (damn statments) e o python é weak typed, o que significa que podes passar objectos de qualquer tipo para dentro de métodos ou funções e deixar a função decidir o que faz consoante aquilo que descobrir sobre o objecto passado (como acontece frequentemente com uma coisa chamada "file like objects" que básicamente são objectos que possuem métodos read e write compativeis com os dos ficheiros e podem ser usados em funções que lêem e escrevem ficheiros em vez dos próprios ficheiros).
O python é a linguagem com melhor "introspeção" que conheço, podes saber em run time imensos detalhes sobre os objectos que estão a ser usados; por exemplo experimenta na linha de comandos do python criar uma string:
>>>a = "sou uma string"
e depois fazer um dir a essa string:
>>>dir(a)
ou ainda
>>>dir("sou uma string")
O "dir" devolve-te uma lista (noutras linguagens conhecidas como array) de métodos e propriedades do objecto, existe muito mais para além disto, e isto é só um exemplo que se calhar nem é muito relevante para o que aqui se fala.
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| | | | Linguagem:
Pascal:trata-se de criar uma aplicação de gestão comercial, por isso o Pascal chega e sobra :-P
Nos sabores Kylix/Delphi ou free pascal/Lazarus.
Base de Dados:
Firebird claro, tem store procedures, trigger, generatores, muita documentação e apoio em PT, uma maravilha (e é mais facil de instalar do que outras BD mais mediaticas).
Outros nomeados:
Gambas (BASIC), o muito interessante Glade, o espetacular Anjuta+Glade, o Kdevelop (é potente mas complicado), e claro todas as outras sugestões apresentadas nos posts anteriores.
|
| | | | Quem eh macho programa em brainfuck e nao reclama. http://www.muppetlabs.com/~breadbox/bf/
|
| | | | | | és macho? tao faz funçoes de I/O em bf e posta.
PS: intercall ou malbouge parte brainfsck :)=
Hybriz, the g0d's dog.
|
| | | | Eu? Sou o maior bicha e programo em VB :PPPP
|
| | | | Qual a vossa opinião sobre a linguagem de programação mais indicada para desenvolver uma aplicação de GESTÃO COMERCIAL para Linux.
Para responder a esta questão é necessário antes demais salientar que a escolha depende sobretudo da ocasião e da situação do que propriamente da ferramenta.
Um software de gestão tem caracteristicas muito particulares (e peculiares) para os seus utilizadores, e cada utilizador tem as suas ambiguidades, não sendo fácil agradar a gregos e a troianos, esta situação implica logo que o software deve ter uma base de configuração bastante flexivel (tecnicamente: ecras com configurações imensas).
Por outro lado, não deve ter milhares de opções porque os utilizadores aborrecem-se com botoes e mais botoes, menus e mais menus (tecnicamente: ecras limpos, apenas com o essencial, abusando dos menus de contexto para operações superfulas e com a opção de atalhos configuráveis para essas operações "mais" escondidas).
De um modo geral, o que interessa numa aplicação de gestão são três aspectos:
* calculos exactos e integridade dos dados - vocês não imaginam quantas vezes já eu vi aplicações a efectuarem calculos errados. Mas mais grave que os calculos errados são os calculos incoerentes mediante a "janela" onde se está o que leva o utilizador a desconfiar e que tecnicamente é completamente descabido.
É importante usar um método de "business objects" onde ficam concentradas todas as operações de calculo e obtenção de valores, permitindo assim reutilizar estes "business objects" em diversas janelas bem como em aplicações completamente diferentes.
* performance - não há nada mais chato do que estar à espera que um documento seja calculado e guardado no sistema. Quer dizer, posso acrescentar que existe uma coisa mais chata que é não poder trabalhar concorrencialmente na base de dados pq o sistema não suporta ou porque estou com "lock" até o meu colega do lado acabar o que está a fazer.
Significa isto que é muito importante que os procedimentos de calculo sejam elaborados de modo a serem rápidos e eficazes.
No entanto o ponto fundamental (que melhor se nota) na performance de uma aplicação são a obtenção de relatórios. Neste aspecto deve-se usufruir sobretudo do poder do servidor de base de dados (usando e abusando de SQL).
Pessoalmente tenho por norma, para cada análise criar uma unica stored procedure para obter os dados dessa análise (ficando o calculo contido num sitio, e ainda obrigando à optimização do SQL).
Pessoalmente uso algumas regras na obtenção de valores para as análise, entre as quais destaco: a este nível é altamente improvável o uso de cursors, e mesmo quando é necessário fazer calculos em vários passos dentro do procedimento, facilmente se abusa de sub-queries, tabelas temporárias, indices bem definidos e alguns truques de calculo usando CASE's e IF's; uma outra regra é evitar criar tabelas pré-calculadas, visto que retiram a dinamicidade das análises, e se queremos tabelas pré-calculadas para análises mais complexas nada melhor do que criar uma base de dados OLAP para o efeito em vez de usar a OLTP; relativamente ao ao tempo de execução, uma análise não deve demorar 3 horas (como eu já vi), mas sim andar no tempo abaixo dos 30 segundos.
* interfaces de utilizador apelativos - finalmente vem aquilo que chama mais a atenção ao utilizador que são os ecrâs de trabalho. Estes sem duvida alguma devem ser simples, intuitivos e apelativos; convém salientar que ser apelativo não significa que deve ter bonecada e corezinhas (até porque isso distrai o utilizador do seu trabalho) mas sim devem possuir um aspecto formal com os controlos bem posicionados.
Assim, sabemos agora que é necessário escolher uma ferramenta de desenvolvimento que facilite a construção dos interfaces e que a linguagem por detrás ajude a controlar esses interfaces.
Posso dizer que (para Windows) uma combinação excelente para o desenvolvimento de uma aplicação de gestão comercial é o Delphi (para interfaces) e o tal SQL (para usar e abusar no servidor). Como nota, esta aplicação de gestão com cerca de 200 ecrâs, 120k loc Delphi, 250 tabelas, 900 stored procedures, 80k loc SQL demorou 2 anos a ser concluida por uma equipa de 2 pessoas.
No entanto é preciso evoluir e avançar, e visto já ter entrado num novo patamar, foram escolhidas outras ferramentas.
Este patamar implica a construção de uma base que sirva de apoio à aplicação de gestão (desktop) e a versão da mesma na intranet (mais orientada para análises). Assim optou-se por utilizar .NET Framework (linguagem C# se bem que mais uma vez refiro que acho a linguagem pouco relevante) para o desenvolvimento de ambas.
Respondendo directamente à questão colocada, sem duvida alguma que eu optaria por desenvolver usando o mono numa combinação GTK# e C#. Até porque facilmente se percebe que o que já estou a desenvolver se encaixa neste novo paradigma.
Finalmente e relativamente à base de dados, não há muito a dizer. É à escolha do freguês se bem que pessoalmente estaria indeciso entre Firebird e PostgreSQL. Actualmente uso SQL Server, o que não é um problema, desde que se use apenas SQL ANSI o que (infelizmente) não foi o caso.
Cumprimentos,
Fernando Silva
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | | | Presumo que a aplicação em questão seja de alto nível e grande performance, gostaria era que (acrescentado ao teu bom texto) idicasses as razões para teres adoptado uma .net framework com sql server e não um sistema servido por um *nix. ou a razão por não teres escolhido *nix.
Ah ... não se trata de uma luta linux vs windows, mas antes saber um porquê!
Estações de trabalho em windows? A pré existencia de SQL server?
(não sou da area da informática - eng Mecânica - mas estou curioso o porque de o linux ser muitas vezes despejado das grandes "questões", sendo por muitos defendido como "o melhor")
Obrigado
Cumps-
Gass |
| | | | Olá,
Nota: pode parecer estranho o 'historial' resumido que vou fazer, mas as decisões que tomamos normalmente são fundadas em experiências anteriores, e penso que ao fazer este resumo é fácil de perceber essas opções.
Como em todas as questões é preciso balancear os custos e ganhos. Ora bem a aplicação de gestão comercial (de 2000 a 2002) foi feita em Delphi e como o objectivo dela era servir apenas estações de trabalho Windows a opção mais lógica para backend foi o SQL Server. Assim, na altura não havia nenhum 'argumento' para fazer a aplicação 'database independent' nem sequer 'cross-platform'. Desta forma estava uma aplicação concluida apenas com algumas releases de correcção de bugs.
Ainda em 2002 iniciamos um novo projecto (GS) para uma seguradora, no qual tive 'poder' de escolha e de orientação. O objectivo era desenvolver uma aplicação de gestão de seguros (calcular apólices, gerir contas, co-seguro, resseguro, análise, etc) para a Intranet. Porque é que se optou por fazer uma versão web e não desktop? Como era necessário ter a mesma aplicação (mais reduzida) disponivel para clientes externos era óbvio que o ideal era construir uma mesma base que pudesse ser usada pelas duas aplicações. Desta forma a escolha foi usar o .NET Framework (para a base) conjugado com ASP.NET. O facto do mono já existir na altura também deu um empurrão nesta escolha pois apesar de irmos desenvolver em Windows a migração para Linux seria bastante plausível, bastando para isso que durante o desenvolvimento da aplicação evitassemos usar coisas especificas de Windows. A aplicação foi concluida em 2003, e apesar de termos usado também SQL Server como backend a transição para uma plataforma Linux e usando outra BD requer cerca de 5% de alterações no codebase actual.
No entanto como é preciso evoluir, houve a necessidade de em 2003 iniciar o desenvolvimento de várias funcionalidades (suportadas pela aplicação de gestão comercial) para disponibilizar numa Intranet. Sem qualquer dúvida a opção foi usar todos os conhecimentos (e garantias) do projecto anterior e optar por .NET. Seguindo o mesmo método, estamos a criar classes de calculo e acesso aos dados (os business objects) que ficam numa livraria que pode ser reutilizada por qualquer aplicação mas que para já são utilizadas pelo interface web. A grande questão que se colocava aqui era, como reutilizar todo código já feito? A solução foi fácil visto que todo o código da app de gestão estava em SQL, basta que estes business objects sirvam mais como wrappers para as stored procedures de cálculo do que eles mesmos contenham os calculos. Isto vai proporcionar uma transição reutilizavel, permitindo que no final destas classes estarem concluidas se possa reconstruir os interfaces (actualmente em Delphi) para poder ter uma versão da app de gestão para desktop em .NET.
Penso que isto explica o porquê de ter escolhido .NET Framework, e também explicar que no caso do SQL Server não tinha grande volta a dar-lhe. Convém salientar que trabalho numa empresa que como a grande maioria das empresas portuguesas trabalha em e com Windows, e que apesar de se poder pensar que desenvolver em .NET e estar à espera do mono para 'transitar' para Linux seja uma heresia a verdade é que não havia (há?!) uma alternativa óbvia de que desenvolver em Linux daria mais rendimento.
Neste momento os esforços estão concentrados na base da aplicação e no interface web, no entanto seguindo as sugestões que dei, e dentro de alguns testes que já fiz com mono e GTK#, certamente que no final do ano (e correndo tudo dentro do previsto) a versão desktop será iniciada dessa forma.
A minha opinião pode não valer de nada, mas vou tentar explicar o porquê de o Linux sofrer de um antagonismo evidente. O linux é bom, claro que é. Está provado que possui caracteristicas que melhoram significativamente a performance do sistema, sendo desta forma uma opção evidente no desenvolvimento de aplicações de servidor, como o provam vários exemplos.
Por outro lado desenvolver uma aplicação em Windows, que poderá não ter a mesma performance, não é problema pois basta seguir a a velha tradição portuguesa de que se a aplicação está lenta faz-se upgrade ao hardware.
A outra parte é o facto de o Linux não ter uma quota de mercado significativa (e como estamos em Portugal é sobre este que analiso) que permita o desenvolvimento completo de um sistema para Linux, colocando neste tanto a parte servidor como a parte do utilizador.
A alternativa final seria utilizar o Linux como servidor apenas e usar workstations Windows, no entanto aqui surge a parte mais chata que não é propriamente a criação do layer de comunicação entre os dois (no caso de aplicações 3-tier) mas sim o facto de que obrigaria a trabalhar em dois sistemas diferentes, com paradigmas diferentes e técnicas diferentes. É complicado enveredar por este caminho, pois o consumo de tempo tornaria inviável o projecto.
Julgo que o mono será o grande canhão de lançamento para as aplicações em Linux. Não só para criar uma homogenidade entre aplicações no próprio sistema bem como criar aplicações que poderão ser usadas em Windows. Por muito que digam, a verdade é que quem desenvolve uma aplicação gosta que esta seja utilizada, e para já não existe sistema com mais probabilidade de uma aplicação ser usada do que em Windows... assim, o melhor é ir com calma e não stressar, pois com o mono será possivel trazer as melhores aplicações para o Linux.
Cumprimentos,
Fernando Silva
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | Se estiverem à vontade com a linguagem é rápido e simples. Não tem que lidar com problemas de baixo nível, o compilador é o melhor em termos de avisos e erros, portanto detetam-se possíveis bugs com facilidade e, em geral, a plataforma está bem estruturada. Para Linux (e para Windows) existe uma ferramenta, o Eclipse, que é, na minha opinião, a melhor até à data para programar em Java.
|
| | | | | | Falando por experiência própria, o JBuilder é *extremamente* poderoso. Apesar do Eclipse estar a ir em bom ritmo, ainda tem de andar um pouco para acompanhar.
E atenção que não estou a falar apenas em termos de design de interfaces, porque até nem é para isso que o uso.
A borland tem disponível uma versão limitada para uso pessoal (chamam-lhe "Foundation" e não inclui classes da borland e algumas features) mas totalmente funcional que demonstra bem o poder do JBuilder.
--
RMO |
| | | | | Permite-me discordar.. do post a que eu respondi:
"Para Linux (e para Windows) existe uma ferramenta, o Eclipse, que é, na minha opinião, a melhor até à data para programar em Java."
Foi apenas a isto que respondi.. com a *minha* opinião.. pode haver outras :)
--
RMO |
| | | | O eclipse é fabuloso quase que se programa com o rato :P
|
| | | | | (...)quase que se programa com o rato E isso é fabuloso?
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| | | | Se programar bem, é.
Dominus vobiscum |
| | | | Conheço uma cena mais fabulosa ainda que é uma espécie de rato com cento e tal botões, alguns estão marcados com caractéres de "A" a "Z" e permite expressar por palavras aquilo que se quer e dá para fazer uns programas muito bem feitos.
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| | | | é uma espécie de rato com cento e tal botões
É uma rata?!
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | Isso faz-me lembrar dos Wizzards do VB. Vais clicando Next, Next, Next... Dás o nome à aplicação e pronto, já tá, podes vender.
Quando houver merda, contractas alguém que saiba usar um teclado e programar.
|
| | | | | C. Se queres programar módulos para o Linux é mais que recomendável o C, creio que é uma exigência (em C incluo chamadas de ainda mais baixo nível como assembler, que é normal poder ser embebido no código fonte).
Para fazer desenvolvimento rápido no GNU/Linux, recomendo as linguagens do Subject. São linguagens interpretadas, mas muito eficientes, com paradigmas diferentes (pseudo-funcional estilo C com extensões objectuais, objectual, e puramente funcional estilo lisp).
Todas elas tem uma curva de aprendizagem relativamente baixa, e abtraem os programadores de muitos pormenores "incómodos" de linguagens como C (apontadores, tratamento de strings, etc...), muito flexíveis, cheias de funcionalidade útil e sobretudo rápidas para a forma como são executadas.
Gostaria de dominar as 3, mas só tenho tempo para lidar com uma delas, de momento.
|
| | | | | | Acredita que não perdes nada em não saber Scheme...
E digo isto de experiência própria!
Dominus vobiscum |
| | | | Podes justificar a tua afirmação?
|
| | | | Começa tudo na syntax: eu, pessoalmente, detesto a syntax (Lots of Incredibly Stupid Parentheis), o que torna o código maçudo e confuso. É uma linguagem lenta e as API's para gráficos são, regra geral, fracas. Não é OO nativamente, ou seja, foi apenas uns ajustes para ficar OO.
Eu não gosto e não recomendo a ninguém. Usem C/C++/C#, Java, Python, agora tudo o que seja LISP é assustador.
Dominus vobiscum |
| | | | É uma linguagem lenta e as API's para gráficos são, regra geral, fracas.
Descontando um estudo que agora não estou a conseguir encontrar que considerava scheme mais rápido que java "overall" (não é só a velocidade de execução que conta), queres dizer que APIs para gráficos como a Qt ou a Gtk são fracas?
|
| | | | Claro que não estava a comparar Scheme com Java, mas sim com todas as outras. O ser lento no Java é uma desvatangem muitas vezes desprezável. A sua portabilidade é fenomenal.
Considero uma linguagem lenta pelo menos para aquilo que eu a usava (aplicação de algoritmos matemáticos). Muito mais lenta que C/C++ ou Perl/Python, embora estas duas sejam scripting languages
Dominus vobiscum |
| | | | Não é OO nativamente Escapou-me esta, nenhuma LISP é OO mas sim funcional.
|
| | | | Queria fazer aqui um pequeno comentario ao "lisp", se não se importam, para desmistificar umas coisas.
1º - Lisp não é interpretado. A maioria dos sistemas da versao "industrial da linguagem" (Common Lisp) têm compiladores nativos e vários de scheme também.
2º - Os parentesis não são "uma sintaxe estranha" que um gajo academico qualquer inventou. É a "ausencia" de sintaxe que lhe dá aquela representação. Mais precisamente, é uma representação directa da arvore de parsing. Isto é uma funcionalidade.. permite a escrita de macros, algo que nenhuma linguagem para alem do Lisp teve até hoje. Para mais informações sobre a potencialidade das macros, podemos ter outra conversa noutra altura... ou podem perguntar o que quiserem.
3- "Basically, Python can be seen as a dialect of Lisp with "traditional" syntax.."http://www.norvig.com/python-lisp.html"... e portanto SEM macros. Tem a vantagem de estar na moda e ter uma sintaxe ("normal").
4º - Common Lisp pode ter uma eficiencia muito proxima do C/C++ (2vezes mais lenta em determinadas situações) e scheme com algumas extensoes tambem. A linguagem permite declaração dos tipos das variaveis.
5º - Java designed for average programmers..." [Gosling,primeiro white paper sobre java]. Ou seja, foi feita para produção de codigo tipo linha de montagem por funcionarios baratos. Isto nao é negativo, é um objectivo tão bom como outro qualquer. Para alem disso, a maioria das funcionalidades do java foram baseadas no lisp e no smalltalk (tanto que o steele, um dos maiores cromos do lisp, trabalha para a Sun e foi um dos gajos que desenhou o java).
6º e ultimo:
(flame "C++ tambem é C com OO que nao foi desenhado de raiz.. foram uns remendos acrescentados.") ;)
Cumprimentos
|
| | | | C++ com wxWindows é o melhor que podes arranjar. A sério. Faz-te um homem mais feliz. É assim tão bom. Leva algumas semanas para apanhar o jeito, mas compensa muito.
QT também é bom, para quem gosta de ter macros por todo o lado e de ter que préprocessar o código antes de passar ao pre-processador do compilador. E tem o problema das licenças comerciais serem caras.
Esquece o Java. É rápido construir a aplicação com Java, mas é tudo menos rápido a executar (para não falar dos milhares de megas de memória necessários).
Tens outra opção que pessoalmente nunca experimentei, mas pelo que oiço quer-me parecer bastante boa: Delphi (ou neste caso Kylix). Depende do que a equipe sabe programar.
Não te metas nas linguagens de script (perl, python e afins) para isto. Se vais vender a aplicação não queres o código disso à mostra. E torna-se tudo menos fácil instalar uma aplicação nesses moldes (dependência de N módulos, etc).
|
| | | | | | | mas e bastante Bom. Não se pode ver a coisas apenas pelo espectro da linguagem. É necessário ver que o Java não é só uma linguagem de programação mas sim todo um ambiente de programação e conjunto de funcionalidas. No que diz respeito a aplicações distribuidas o java só tem um rival ex: .NET. O código em Java pode ser lento, mas no entanto é portável. No que diz respeito à QT, utilizei-a há pouco tempo para fazer um projecto e fiquei altamente satifeito. O QT designer é um dos melhores programas WYSIWYG que eu já vi para desenhar interfaces, à primeira vista pode parecer complicado a interacção do código dos componentes (GUI) com o código da aplicação, mas é simples. É so criar funcoes e preecher os slots de eventos aquilo tem uma coisa xata, é que ele gera o código dos interface a partir de ficheiros XML e isso aumenta bastante o tempo de compilação, por outro lado essa geração pode ser "customizada" numa simples Makefile A QT é um biblioteca bastante madura, com muitas funcionalidas, conexão a BD, suporte de Thread, etc Isto é so escolher
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | | Mito: o código em Java é lento. Nada disso, é até muito rápido, uma vez que a máquina esteja em funcionamento. Vejam, a propósito, a nova extensão que se espera no 1.5 (Tiger) para reutilizar a máquina virtual, de modo a que a segunda aplicação não demore o mesmo que a primeira para iniciar. O código em Java aproxima-se perigosamente do código em C/C++ depois da fase transitória (o chamado setup and burn-in do hotspot). As bibliotecas são primorosas e a velocidade é muito boa. Repito: a única chatice é o tempo de início da máquina virtual (que demora, é certo). Para processos que correm durante horas --- como oeclipse ou um servidor --- Java é excelente. Vejam que podem estender Java com C, muito embora prefira python + C pessoalmente --- ninguém paga o ctypes.
|
| | | | No que diz respeito à QT, utilizei-a há pouco tempo para fazer um projecto e fiquei altamente satifeito.
Sim, porque não tiveste que usá-lo comercialmente. Senão estarias 500 contos mais pobre.
Claro que se fosse um projecto com mais de um programador, serias (500cts * numero de programadores) mais pobre.
Claro que estamos a falar de uma licença para uma plataforma apenas. Se quiseres portar isso vais ter de hipotecar a casa.
Não havia necessidade.
|
| | | | | na é nem assim: "GPL Versions These are versions of our software governed by the terms of the GPL. " E eu já usei: Swing,GTK,MFC e por fim VB :)) wxWindows, se não tiver um cena que permita desenhar a interface em 10 min como o QTDesiger, xauzinnho :)),
___________________________________ (linooks (at) zmail (dot) pt) |
| | | | E eu já usei: Swing,GTK,MFC e por fim VB :)) wxWindows, se não tiver um cena que permita desenhar a interface em 10 min como o QTDesiger, xauzinnho :))
Sim, se gostas de desenhar GUI's como quem faz bonecos no photoshop, usa VB que ficas bem servido.
|
| | | | | Se vais vender a aplicação não queres o código disso à mostra. Nesse caso podes tirar o python da tua lista porque o python gera .pyc que são bytecode (multiplataforma) e não precisas de distribuir o código para que esses .pyc's funcionem. A única coisa que em python tem que ir em source é o ficheiro que faz o arranque do programa, daí para a frente podes passar o controlo do programa para um .pyc.
Por outro lado o facto da aplicação estar à venda não implica que o código tenha que ser escondido.
"Se um dia, a vida te der as costas... apalpa-lhe o cu." |
| | | | QT também é bom, para quem gosta de ter macros por todo o lado e de ter que préprocessar o código antes de passar ao pre-processador do compilador. E tem o problema das licenças comerciais serem caras.
Não sei de onde vem essa das macros por todo o lado, o QT é até bastante elegante e a utilização do "moc" é necessária para manter essa elegância e até acaba por não ser nada de mais.
Esquece o Java. É rápido construir a aplicação com Java, mas é tudo menos rápido a executar (para não falar dos milhares de megas de memória necessários).
O Java requer "bastante" memória e tem alguma penalização de performance durante os primeiros momentos de execução do programa mas em aplicações de gestão onde a performance não é importante o Java consegue portar-se bastante bem. O Java ainda não atinge o nível de performance ou poupança de recursos de linguagens como o C ou C++ mas a sua lentidão é hoje mais um mito do que uma realidade.
Tens outra opção que pessoalmente nunca experimentei, mas pelo que oiço quer-me parecer bastante boa: Delphi (ou neste caso Kylix). Depende do que a equipe sabe programar.
O Delphi não é mau (bem, eu detesto Pascal mas estou a tentar ser isento aqui) mas o Kylix não é grande coisa, nunca foi bem suportado, tem um aspecto um bocado mal amanhado e aparentemente a Borland perdeu interesse em o manter.
Não te metas nas linguagens de script (perl, python e afins) para isto. Se vais vender a aplicação não queres o código disso à mostra. E torna-se tudo menos fácil instalar uma aplicação nesses moldes (dependência de N módulos, etc).
As dependências de módulos externos podem ser minimizadas por quem desenvolve o programa, é só uma questão de darem uma mãozinha ao utilizador final (incluindo os módulos ou facilitando a sua obtenção). Quanto ao código, este não tem ir à vista, o código Python pode ser transformado em bytecode.
-- Carlos Rodrigues
|
| | | | Não sei de onde vem essa das macros por todo o lado, o QT é até bastante elegante e a utilização do "moc" é necessária para manter essa elegância e até acaba por não ser nada de mais.
Tem macros, não tem? Macros are evil.
E código com macros é tudo menos elegante.
Sei que o QT é bom, mas macros não obrigado.
O Java ainda não atinge o nível de performance ou poupança de recursos de linguagens como o C ou C++ mas a sua lentidão é hoje mais um mito do que uma realidade.
Hum... Sim, para quem tem processadores > 2GHz.
Sejamos realistas. A maioria dos escritóriozinhos ainda tem Pentium 400Mhz com 64Mb de memória.
Essa conversa de "hoje em dia isso não é nada para os processadores actuais" já enjoa.
Se cada vez que tivermos processadores mais potentes usarmos linguagens mais lentas, ficamos sempre na mesma merda! Quando tivermos processadores a 20GHz vamos ter Sistemas operativos em Java e vão correr tão depressa como os Pentium's 400Mhz corriam ontem.
O Delphi não é mau (bem, eu detesto Pascal mas estou a tentar ser isento aqui) mas o Kylix não é grande coisa, nunca foi bem suportado, tem um aspecto um bocado mal amanhado e aparentemente a Borland perdeu interesse em o manter.
Sim, tambem não conheço Pascal o suficiente para comentar. Sei (pelas palavras de outros) que o Delphi é bom, e daí presumi que o Kylix fosse (ou viesse a ser) razoável. Mas se dizes que já não é mantido, lixo com ele. :)
|
| | | | Esquece o Java. É rápido construir a aplicação com Java, mas é tudo menos rápido a executar (para não falar dos milhares de megas de memória necessários). Antes pelo contrário! Numa máquina "normal" (qualquer coisa do género dum Celeron a 500MHz com 256 MB de RAM) quase que não se nota a diferença (em relação ao 'C'), mesmo a executar gráficos ;-) Normalmente a lentidão atribuída ao Java tem a haver com o tempo de inicialização da Máquina Virtual e não com o tempo de execução dos algoritmos, que é muito semelhante. E estou a falar por experiência própria! Quanto ao gasto de memória (que, segundo os padrões actuais, até não é assim tanto) é largamente compensado pelo tempo de desenvolvimento que pode chegar (estimo eu, e antes usava sobretudo o 'C') a um quinto do que demoraria a escrever o mesmo código em 'C', sobretudo em aplicações de maior dimensão.
|
| | | | Numa máquina "normal" (qualquer coisa do género dum Celeron a 500MHz com 256 MB de RAM) quase que não se nota a diferença (em relação ao 'C'), mesmo a executar gráficos
Desculpa, mas isso é mentira. Para além de que 256Mb ainda não é a norma. Apesar de ser a base do mercado, a média de máquinas que encontras nas pequenas empresas ainda tem 128Mb (com sorte). Ora, só a virtual machine já consome grande parte disso.
Quanto ao gasto de memória (que, segundo os padrões actuais, até não é assim tanto)...
É. É muito.
O exemplo máximo disso é a web.
Programa-me um site que tenha muito tráfego em java, e que não precise de uma farm de dual processors por trás.
... é largamente compensado pelo tempo de desenvolvimento que pode chegar (estimo eu, e antes usava sobretudo o 'C') a um quinto do que demoraria a escrever o mesmo código em 'C', sobretudo em aplicações de maior dimensão.
Sim, até aí concordo. Mas porque não usar C++?
As pessoas ainda fazem confusão e associam o C++ ao C...
Com C++ levantas aplicações grandes em muito menos tempo do que em C. Tens a vantagem em relação às outras linguagens que é o facto de teres o poder do controlo a baixo nível. E tens MUITA mão de obra qualificada por aí.
C++ tem evoluído bastante na ultima década (ao contrário da idéia popular de que é uma linguagem dos anos 80) e é hoje muito diferente do que era há 10 anos atrás.
|
| | | | Desculpa, mas isso é mentira. Para além de que 256Mb ainda não é a norma. Apesar de ser a base do mercado, a média de máquinas que encontras nas pequenas empresas ainda tem 128Mb (com sorte). Ora, só a virtual machine já consome grande parte disso. Só tens razão no que diz respeito à memória, mas isso pode sempre ser acrescentado ;-) É. É muito. O exemplo máximo disso é a web. Programa-me um site que tenha muito tráfego em java, e que não precise de uma farm de dual processors por trás. Desculpa, mas dito dessa maneira é muito vago. De qqr maneira podes ver o sítio da Sun, onde eles usam (e abusam) do Java (JSP, Servlets, etc.). Com C++ levantas aplicações grandes em muito menos tempo do que em C. Tens a vantagem em relação às outras linguagens que é o facto de teres o poder do controlo a baixo nível. E tens MUITA mão de obra qualificada por aí. Em muito menos tempo, não! Em menos tempo, talvez. Mas tens que acrescentar o tempo gasto na depuração do código e em C++, é pelo menos tanto como em C, podendo mesmo ultrapassá-lo. Quando se tem que manter dezenas de milhar de linhas de código (e não vejo maneira de fazer uma aplicação de gestão por menos), o Java é uma benção dos deuses: linguagem fortemente tipada, a caixinha de areia e a total ausência de ponteiros, só por si, quase que cortam o tempo de desenvolvimento a metade. Por outro lado, para quem tiver tempo livre (ou sofrer de insónias, o C (ou o C++) devem ser considerados como um forte candidato. Mas uma aplicação de gestão não precisa de ser tão optimizada como um sistema operativo, sendo mais vantajoso a possibilidade de poder instalar a mesma aplicação (sem necessidade de recompilar -- e re-testar!) nos vários S.O. Não resisto a terminar com mais uma acha para a fogueira:
"O C é uma linguagem muito poderosa, mas se não fôr usada com (muito) cuidado pode-nos levar a dar um tiro no pé. O C++ permite-nos reutilizar a bala!" - desculpem, mas não sei quem disse isto...
|
| | | | Só tens razão no que diz respeito à memória, mas isso pode sempre ser acrescentado ;-)
Claro, e quem paga isso?
Inclúis a memória no pacote de software?
Ou metes nos requerimentos do software: "Precisa de 256Mb de memória e Pentium 1GHz para correr"? (e eliminas grande parte dos potenciais compradores)
Desculpa, mas dito dessa maneira é muito vago. De qqr maneira podes ver o sítio da Sun, onde eles usam (e abusam) do Java (JSP, Servlets, etc.)
Hum, e conheces o tamanho da farm por trás disso?
Eu consigo te apontar dezenas de sites de porte médio onde o java aterra. E por estranho que pareça, não consigo encontrar nenhum de grande porte que use sequer isso (tirando talvez a Sun, claro). Se calhar sou eu que não percebo nada disto e o Java rocka.
Em muito menos tempo, não! Em menos tempo, talvez. Mas tens que acrescentar o tempo gasto na depuração do código e em C++, é pelo menos tanto como em C, podendo mesmo ultrapassá-lo.
Desculpa lá, já usaste C++ por um acaso?
Não percebo. Que depuração é essa?
Pensei que não estávamos a falar de aplicações que precisem de performance. Não vejo porquê depurar.
Por outro lado, para quem tiver tempo livre (ou sofrer de insónias, o C (ou o C++) devem ser considerados como um forte candidato.
Não tenho tempo livre nem sofro de insónias. Aliás, o C++ permite-me dormir melhor à noite porque sei que quando houver merda é uma questão de encontrar o bug ou a solução, e não vai depender da implementação da VM, nem de fazer upgrade ao hardware dos clientes todos.
Mas uma aplicação de gestão não precisa de ser tão optimizada como um sistema operativo
Claro, mas falavas tu de depuração. Decide-te.
...sendo mais vantajoso a possibilidade de poder instalar a mesma aplicação (sem necessidade de recompilar -- e re-testar!) nos vários S.O.
Isso é prái o marketing mais merdoso e estúpido que já conheci, e por incrivel que pareça engole milhares de pessoas.
Diz-me. Quantas vezes tiveste de portar uma aplicação na vida?
No meu caso, uso C++ com wxWindows, e compilo o mesmo source em windows e linux. Mas apenas o faço porque prefiro programar em linux e o cliente é Windows.
É muito bonito quando se trata de open-source, ou de telemóveis, portar as aplicações. Aí sim. Agora fala-me de aplicações desktop comerciais que façam sentido portar, por favor.
Gostava de perceber essa "grande vantagem".
Explica-me como é que compensa Portabilidade versus Performance e Requisitos.
|
| | | | Desculpa lá, já usaste C++ por um acaso? Já! E também já usei C! Durante 10 anos! Não percebo. Que depuração é essa? Descobrir onde é que cometemos aquele erro que faz com que o programa se estampe. E em C (e C++) pode durar dias :-( ... em Java, pelo menos, não há ponteiros :-) . Diz-me. Quantas vezes tiveste de portar uma aplicação na vida? Já perdi a conta. Desde o DOS 3.3, as várias versões do Windows, Xenix, Unix (pelo menos 3). Existem mais sistemas que o Windows, Linux e MacOSX. E há também os telelés e PDA's.
|
| | | |
>> Não percebo. Que depuração é essa?
>>
> Descobrir onde é que cometemos aquele erro que faz
> com que o programa se estampe. E em C (e C++) pode
> durar dias :-( ... em Java, pelo menos, não há
>ponteiros :-) .
Pensei que depuração fosse a tradução de "profiling" e não de "debugging". :P
Português não é comigo quando se trata de informática.
Epa, se andas nisto há tantos anos deves saber melhor do que eu que não só de ponteiros se fazem bugs. Já me deparei com bugs que levaram vários dias a descobrir em outras linguagens (ie: sem ponteiros). Java não há de ser a excepção.
>> Diz-me. Quantas vezes tiveste de portar uma aplicação na vida?
>>
> Já perdi a conta. Desde o DOS 3.3, as várias
> versões do Windows, Xenix, Unix (pelo menos 3).
Ok, e quantas vezes tiveste de tornar uma aplicação mais eficiente?
Vou tomar a liberdade de responder por ti, e respondo "ui, millions of times".
Agora diz-me, entre performance e portabilidade, qual preferes se tiveres de escolher?
Já disse algures neste thread que os telemóveis são dos poucos sitios onde a portabilidade é realmente importante, e apenas porque não existe uma API standard entre as marcas.
Se houvesse uma API standard, C/C++ faria muito mais sentido por causa da baixa performance dos cérebros pequeninos (e pouco possantes) dos nossos telemóveis e PDA's. :)
|
| | | | | Seguindo o exemplo das "marcas" que dominam o mercado - afinal o benchmarking deve servir para alguma coisa - devem apostar em VB + Access. Ahhhh... esqueci-me! Era para ser em Linux e falar de linguagens de programação e bases de dados.
Jazzy |
| | | | | | Concordo. Para usar em linux usem o Wine. :) (Ou então não.)
... Ou então não. |
| | | | | Para além de reiterar como escolha possivel a dupla Python + Boa Constructor, serve este post para verificar o forte suporte q o Python começa a ter. Muito diferente de há uns anos atrás (é ir ver posts anteriores do Gildot) onde até havia quem perguntasse "que futuro vais ter com o Python?" :-) Nao era alguem q agora o "apadrinha" :-) ? Cumprimentos Mario Valente
|
| | | | | | Experimenta Tcl/Tk e junta a extensão BLT (esta tem gráficos maravilhosos). Tcl
Sérgio |
| | | | | Vai aqui e vê a data... Acredita q me mantive a par e sei bem qual o melhor. Cumprimentos Mario Valente
|
| | | | | Somos dois a pensar assim, e com essa experiência. Do tipo chanfrado que gosta daquelas coisas todas esquisitas (Linux, Java, Perl, Tcl, Python, C, não C++) passei para o tipo que até afinal sabe umas coisas. Pena é que já tenha saído da Universidade --- hoje é o meu último dia como funcionário da UBI --- e agora chovem pedidis de ajuda. A verdade vem sempre ao cimo. E a verdade é que o Python é uma boa linguagem de prototipagem e de motor de aplicações. Uso a mesma linguagem desde a Web (nevow, em www.twistedmatrix.com, até à programação numérica, passando pela administração de sistemas e pela manipulação de imagens e pelo gnome-python para construção de interfaces gráficas. Por isso, de gozado passaria a gozão, caso fosse pedante. Francisco Colaço
|
| | | | A minha resposta tem mais a ver com os requisitos do que com a pergunta da linguagem de programação.
1. Tempo de desenvolvimento
Se planeias uma aplicação que fará muita coisa, o melhor é pensares de início numa solução baseada na geração automática de código a partir de especificações (modelos de dados e outras especificacões de alto nível). Se descartares esta solução, não só poderás demorar demasiado tempo como até poderás desistir antes de chegar a algum lado.
Sugiro-te que pesquises o mercado para determina ferramentas já existem que podem atender ao teu problema. Começa por este portal sobre geração de código.
Se não encontrares nada que te sirva, pode começar a pensar em desenvolver as tuas próprias ferramentas de geração de código.
Sugiro te vivamente que leias o livro Code Generation in Action. Muito realista e esclarecedor.
2. Manutenção
Se te referes à possibilidade de manter instalações da tua aplicação a correr em vários postos (utilizadores em pontos diferentes da tua rede), sem a dor de cabeça de ter que actualizar o software do lado cliente, considera uma solução baseada em servidor Web. Como o teu cliente é o browser, só o precisas instalar uma vez e não precisas de actualizar nada quando a tua aplicação é actualizada para uma nova versão no servidor que eventualmente vai ficar na mesma rede apesar de até poder ficar noutra parte do mundo.
Quanto à linguagem, qualquer uma que tenha bom suporte a Web pode ser uma boa solução. Eu uso PHP. É uma linguagem pensada especificamente para desenvolver aplicacões para Web.
Inclusivamente eu desenvolvi o meu próprio sistema de geração de código a partir de modelos. É um sistema que parte duma defin ição de modelo de dados em XML e pode-te gerar classes de objectos de acesso aos dados, classes de instalação e actualização do esquema de bases de dados e inclusivamente classes que te processam o formulários Web para manipulação desses dados.
Existem soluções parecidas mas o importante é gastares um bocado de tempo a avaliar as que podem resolver melhor o teu problema.
|
| | | | | | Se planeias uma aplicação que fará muita coisa, o melhor é pensares de início numa solução baseada na geração automática de código a partir de especificações (modelos de dados e outras especificacões de alto nível). Se descartares esta solução, não só poderás demorar demasiado tempo como até poderás desistir antes de chegar a algum lado.
Concordo. A geração automática de código é muito útil quando se começa a construir a aplicação e é necessário criar as classes baseadas nos modelos de dados. No entanto, esta opção não tem a ver directamente com o número de funcionalidades que a aplicação terá mas sim com o tempo que não queremos perder a escrever código de escravo (aquele código que é sempre igual e em que só muda uma variável, exemplo property accessors para variáveis internas).
Se te referes à possibilidade de manter instalações da tua aplicação a correr em vários postos (utilizadores em pontos diferentes da tua rede), sem a dor de cabeça de ter que actualizar o software do lado cliente, considera uma solução baseada em servidor Web. Como o teu cliente é o browser, só o precisas instalar uma vez e não precisas de actualizar nada quando a tua aplicação é actualizada para uma nova versão no servidor que eventualmente vai ficar na mesma rede apesar de até poder ficar noutra parte do mundo.
Apesar de concordar no argumento de que uma aplicação Web é a mais fácil de manter. Convém salientar que uma aplicação web não é a melhor opção para uma aplicação de gestão, a não ser que alguém resolva o problema, por exemplo, de um utilizador que faz cerca de 40 documentos por hora (com várias linhas claro) usando apenas o teclado. Os utilizadores 'escravos' (aqueles que estão no atendimento aos clientes e fazem uma regular introdução de dados no sistema (encomendas, vendas a dinheiro, facturas, etc), muito raramente usam rato e a tecla que mais cedo se estraga é o ENTER.
Applicações web é bom mas não para o módulo de gestão de documentos numa aplicação de gestão comercial.
Quanto à linguagem, qualquer uma que tenha bom suporte a Web pode ser uma boa solução. Eu uso PHP. É uma linguagem pensada especificamente para desenvolver aplicacões para Web.
Concordo. Acabei de fazer um pequeno site composto por versão online de pesquisa e com a parte de administração (uma aplicação web separada), onde usei PHP e foi simples, rápido e eficaz! Mas como é óbvio PHP tem limites... e existem aplicações que não são fáceis de desenvolver com PHP.
Este comentário foi publicado ao abrigo de leis internacionais "How to handle a Troll". |
| | | | Concordo. A geração automática de código é muito útil quando se começa a construir a aplicação e é necessário criar as classes baseadas nos modelos de dados. No entanto, esta opção não tem a ver directamente com o número de funcionalidades que a aplicação terá mas sim com o tempo que não queremos perder a escrever código de escravo (aquele código que é sempre igual e em que só muda uma variável, exemplo property accessors para variáveis internas).
Na minha experiência de desenvolvimento de aplicações de gestão, a maior parte das funcionalidades requer código que pode ser considerado de escravo porque são sempre coisas como formulários, relatórios, interfaces de configuração. Quanto mais funcionalidades tiveres, mais vais precisar de coisas destas que precisam de código de escravo. Pelo que o recurso a ferramentas de geração automática de código vai-te reduzir muito o tempo de desenvolvimento.
Apesar de concordar no argumento de que uma aplicação Web é a mais fácil de manter. Convém salientar que uma aplicação web não é a melhor opção para uma aplicação de gestão, a não ser que alguém resolva o problema, por exemplo, de um utilizador que faz cerca de 40 documentos por hora (com várias linhas claro) usando apenas o teclado. Os utilizadores 'escravos' (aqueles que estão no atendimento aos clientes e fazem uma regular introdução de dados no sistema (encomendas, vendas a dinheiro, facturas, etc), muito raramente usam rato e a tecla que mais cedo se estraga é o ENTER.
Applicações web é bom mas não para o módulo de gestão de documentos numa aplicação de gestão comercial.
Penso que estás a presumir que aplicações Web significa necessáriamente usar apenas interfaces de utilizador baseados apenas em HTML puro. Hoje em dia existem alternativas muito mais flexíveis que viabilizam o interface do tipo de aplicações que estás a pensar. Para além de interfaces baseados em DHTML, applets de Java ou Flash, existe o XWT que apesar de também ser um applet de Java, é algo muito poderoso e pensado especialmente para o tipo de aplicações que estás a pensar. O interface é definido com XML e um dialecto baseado em Javascript para lidar com eventos do interface, e usa XML-RPC ou SOAP para comunicar com servidor para realizar operações interactivas que dependam de acessos ao servidor.
Quanto à linguagem, qualquer uma que tenha bom suporte a Web pode ser uma boa solução. Eu uso PHP. É uma linguagem pensada especificamente para desenvolver aplicacões para Web.
Concordo. Acabei de fazer um pequeno site composto por versão online de pesquisa e com a parte de administração (uma aplicação web separada), onde usei PHP e foi simples, rápido e eficaz! Mas como é óbvio PHP tem limites... e existem aplicações que não são fáceis de desenvolver com PHP.
De repente, não estou a ver que aplicações Web não são fáceis de desenvolver em PHP. Talvez esteja a pensar em alguma dificuldade mais pessoal do que da linguagem. De qualquer modo, sem dares exemplos, não posso comentar.
|
| | | | Boas.
"De repente, não estou a ver que aplicações Web não são fáceis de desenvolver em PHP."
Então, o melhor mesmo é parar para reflectir, pois até hoje não inventaram a linguagem de programação que solucione da melhor forma todos os problemas.
Hints:
- Aplicações que necessitem de ser "performantes";
- Aplicações que envolvam a necessidade de trabalho de/em equipa constante;
- Aplicações que necessitem de escalar para várias máquinas.
@071, Nbk
P.s. - Hey, eu sou o primeiro a concordar que PHP resolve imensos problemas na web. Mas não todos.
|
| | | | Apesar de isso não serem exemplos concretos de aplicacões Web que não podem ser desenvolvidas em PHP, o que dizes confirma o que eu disse antes que talvez o problema esteja na tua dificuldade pessoal de achar soluções usando PHP do que na linguagem em si.
Lembra-te que o PHP é essencialmente uma linguagem de scripting para acesso a recursos de desenvolvimento proporcionados por bibliotecas escritas principalmente em C. Agora se não sabes ou não conheces a melhor forma de resolver os teus problema usando os recursos dessas bibliotecas através de PHP, não podes assumir que seja uma limitação do PHP.
Se tens dificuldade em resolver um problema concreto para uma dada aplicação em Web em PHP, talvez seja melhor expores o teu problema e quem alguém te ajude a resolver devidamente em PHP e assim não ficares a por a culpa no PHP em si.
|
| | | | Boas.
" Apesar de isso não serem exemplos concretos de aplicacões Web que não podem ser desenvolvidas em PHP"."
Eu não disse que não podem ser desenvolvidas usando PHP. Eu disse que existem várias que não são fáceis de resolver usando PHP (ou pelo menos tentei dizer isso mesmo).
"...o que dizes confirma o que eu disse antes que talvez o problema esteja na tua dificuldade pessoal de achar soluções usando PHP do que na linguagem em si."
Estás a ser teimoso.
Nem de propósito, acabei de ler um artigo bem interessante sobre a aplicabilidade do PHP em "large websites":
Experiences of Using PHP in Large Websites
http://www.ukuug.org/events/linux2002/papers/html/php/
Não se trata de conseguir solucionar determinado problema ( que se consegue, claro ), trata-se sim de solucionar da melhor maneira ( menor tempo dispendido à procura da solução, maior rapidez, whatever ).
E por muito que me apelides de ignorante em relação ao PHP, tens de concordar que este não resolve todos os problemas da melhor forma, mesmo conhecendo-o (ao php) muito bem.
@193, Nbk
P.s. - Fazes-me lembrar o último "artista" que apanhei. Grandes teorias de abstração e mais não sei o quê, classes para aqui e para acolá, e vai-se a ver ( aka metê-los na pedra e testar ) e a primeiro coisa que acontece é a base de dados passados uns 5 minutos começa a recusar ligações. Bah.
|
| | | | " Apesar de isso não serem exemplos concretos de aplicacões Web que não podem ser desenvolvidas em PHP"."
Eu não disse que não podem ser desenvolvidas usando PHP. Eu disse que existem várias que não são fáceis de resolver usando PHP (ou pelo menos tentei dizer isso mesmo).
Sim, é verdade, transcrevi mal.
"...o que dizes confirma o que eu disse antes que talvez o problema esteja na tua dificuldade pessoal de achar soluções usando PHP do que na linguagem em si."
Estás a ser teimoso.
Não sei se teimoso seria a palavra, mas insisto que estás a fugir à questão que é de apresentares um exemplo concreto de uma situação de desenvolvimento de Web pela qual tu passaste (não uma outra pessoa qualquer ou algo descrito num artigo teórico ou tendencioso) que demonstre que realmente a melhor solução possível em PHP é limitada e que mudando de linguagem seria melhor solução.
Esta é a tua oportunidade de demonstrar o teu ponto de vista e não ficares meramente a fazer conjecturas baseadas na limitação do teu conhecimento.
Nem de propósito, acabei de ler um artigo bem interessante sobre a aplicabilidade do PHP em "large websites":
Experiences of Using PHP in Large Websites
http://www.ukuug.org/events/linux2002/papers/html/php/
Tem paciência, este artigo foi escrito por alguém que realmente precisa conhecer melhor as soluções de PHP que se usam, que ficam muito para além do conhecimento superficial que o autor demonstra ter.
Ele acha que só porque algumas pessoas usam soluções que apresentam inconvenientes, que o resto das pessoas que desenvolve em PHP tem os conhecimentos tão limitados quanto ele. Não me parece que o autor tenha feito o trabalho de casa.
Inclusivamente parece-me que escreveu o artigo para culpar a linguagem por situações que apenas reflectem a falta de conhecimento do assunto dele.
Não se trata de conseguir solucionar determinado problema ( que se consegue, claro ), trata-se sim de solucionar da melhor maneira ( menor tempo dispendido à procura da solução, maior rapidez, whatever ).
Vá lá, estou à espera do teu exemplo.
E por muito que me apelides de ignorante em relação ao PHP, tens de concordar que este não resolve todos os problemas da melhor forma, mesmo conhecendo-o (ao php) muito bem.
Eu não apelidei ninguém de nada. Ignorantes somos todos nós porque ninguém sabe tudo. O que me parece é que em vez de evitar uma ferramenta porque não a conseguimos usar de maneira satisfatória, penso que seria melhor investigar para procurar saber como solucionar determinados problemas talvez com uma abordagem diferente.
P.s. - Fazes-me lembrar o último "artista" que apanhei. Grandes teorias de abstração e mais não sei o quê, classes para aqui e para acolá, e vai-se a ver ( aka metê-los na pedra e testar ) e a primeiro coisa que acontece é a base de dados passados uns 5 minutos começa a recusar ligações. Bah.
Penso que estás a cometer o mesmo erro do autor do tal artigo ao assumir que todos que usam PHP usam as mesmas soluções com os mesmos inconvenientes que as usadas pelo teu amigo artista.
Seria mais humilde da tua parte assumires que nem tu nem o teu amigo artista souberam de solução melhor em PHP em vez de ficar a culpar a linguagem.
|
| | | | Boas.
Estive para não responder ao comentário, pois não gosto muito de continuar threads onde alguém começa a pedir mostras de alguma capacidade técnica, ou a duvidar dela, do género "a minha pila é maior que a tua". No entanto, vindo o comentário de uma pessoa como o Manuel Lemos, é sempre um prazer escrever meia dúzia de linhas a servir de resposta.
"Não sei se teimoso seria a palavra, mas insisto que estás a fugir à questão que é de apresentares um exemplo concreto de uma situação de desenvolvimento de Web pela qual tu passaste (não uma outra pessoa qualquer ou algo descrito num artigo teórico ou tendencioso) que demonstre que realmente a melhor solução possível em PHP é limitada e que mudando de linguagem seria melhor solução."
Não vou estar aqui a transcrever o meu parco e limitado CV. No entanto vou esforçar-me por dar pelo menos um exemplo bem concreto e pequenino de uma *pequena* aplicação web onde o PHP é visto como sendo limitado.
Tive necessidade de desenvolver à uns tempos atrás uma aplicação web onde introduzindo e submetendo um endereço IP, a aplicação retornava-me o uptime da máquina por detrás do IP indicado (isto é possível de ser feito tendo por base o protocolo tcp, nomeadamente algumas das propriedades e opções que este nos confere). A aplicação está feita, mas não em PHP.
Porquê?
Antes de procurar qualquer tipo de módulo adicional, ou mesmo procurar maneiras de ligar o php a bibliotecas já existentes num vulgar sistema linux que me permitissem manipular pacotes tcp/ip, fui dar uma volta pelas funções sobre sockets no manual do php e encontrei isto:
"Warning - This extension is EXPERIMENTAL. The behaviour of this extension -- including the names of its functions and anything else documented about this extension -- may change without notice in a future release of PHP. Use this extension at your own risk."
:-)
Chega?
"Esta é a tua oportunidade de demonstrar o teu ponto de vista e não ficares meramente a fazer conjecturas baseadas na limitação do teu conhecimento."
Vou voltar a escrever o que escrevi num comentário anterior:
"Não se trata de conseguir solucionar determinado problema ( que se consegue, claro ), trata-se sim de solucionar da melhor maneira ( menor tempo dispendido à procura da solução, maior rapidez, whatever ).
E por muito que me apelides de ignorante em relação ao PHP, tens de concordar que este não resolve todos os problemas da melhor forma, mesmo conhecendo-o (ao php) muito bem."
Acredites ou não, sou capaz de fazer o exemplo anteriormente dado em php. Dá é bem mais trabalho. Será fácil para ti?
"O que me parece é que em vez de evitar uma ferramenta porque não a conseguimos usar de maneira satisfatória, penso que seria melhor investigar para procurar saber como solucionar determinados problemas talvez com uma abordagem diferente."
Isso da investigação deixo para os meus tempos livres. Quando se trata para fazer qq coisa, não vou apostar numa linguagem onde determinada secção/modulo/whatever vem referida como "experimental" desde *quase* sempre ( não tempo para untarrar as versões anteriores do manual de php, mas se duvidares posso confirmar... ).
O que escreves aplica-se aos newbies em php, ou aqueles que "codam" em php usando os templates do dreamweaver, muito nervosos e à minima dificuldade praguejam com o php e mudam de linguagem, não a mim, obrigado.
"Penso que estás a cometer o mesmo erro do autor do tal artigo ao assumir que todos que usam PHP usam as mesmas soluções com os mesmos inconvenientes que as usadas pelo teu amigo artista."
Pensas mal. Estava a tentar demonstrar a velha máxima K.I.S.S. :-)
"Seria mais humilde da tua parte assumires que nem tu nem o teu amigo artista souberam de solução melhor em PHP em vez de ficar a culpar a linguagem."
Lá estás tu. Repara que apanhei o artista, portanto não posso ser assim tão burro... ou posso? :->
@166, Nbk
|
| | | | | De repente, não estou a ver que aplicações Web não são fáceis de desenvolver em PHP. Pois, em principio dá para fazer todas. Assim de repente tb nao estou a ver q aplicacoes web nao sao faceis de fazer em Perl; ou em C; ou em Assembler... Mas, por exemplo, ocorre-me q qualquer aplicação web cientifica que usasse processamento numerico preferia faze-la com Python (e a lib NumPy) do que em PHP. Cumprimentos Mario Valente
|
| | | | | que usasse processamento numerico preferia faze-la com Python (e a lib NumPy) Hoje em dia o NumPy já evoluiu e chama-se numarray.
|
| |
|
