C?: C? Não seria melhor escolher algo mais apropriado, com Python, Ruby, Java, C#, etc?

Desempenho não é problema. Em um programa desse tipo, os gargalos de desempenho é sempre I/0, seja com o disco (que vai ser feita pelo banco de dados, e não pelo programa em si) e com vídeo (que vai ser feita pela GTK). Os dois são, portanto, independentes da linguagem escolhida para a implementação do sistema.

Em termos de portabilidade, C provavelmente é a menos indicada. Não é difícil portar um sistema em C bem escrito de uma plataforma para outra. Mas, com linguagens de mais alto nível é bem mais fácil.

Em termos de conhecimento... quem conhece C consegue programar pelo menos em Python ou Ruby sem quase nenhum esforço adicional. Java ou C# já seriam um pouco mais complicado.

Na minha opinião, escolher C para um projeto desses é um erro grave de projeto.

Deixa o cara fazer o que quis: Deixa o cara fazer o que quiser com o projeto dele. Quando ele terminar tu reescreve em Pythonby#.Net

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Carlos Wagner - São Luís / MA

Não vejo problemas em escolh: Não vejo problemas em escolher C. Eu vejo problemas em gerar relatórios em Gtk. Digo relatórios apresentáveis, exportando em vários formatos, etc. Sei que existem algumas bibliotecas para Gtk que geram relatórios, mas deixam muito a desejar. Bem, acho que é isso.

Estes Kde-likes de plantão!!: Estes Kde-likes de plantão!!!

Aff sem flames por favor!!!

Vejo problemas: Eu vejo problemas sim. Se alguém aqui já fez uma aplicação relativamente grande em C e depois passou a utilizar outra linguagem like java, python, etc, sabe o quanto de tempo se perde com C com coisas típicas da linguagem (o que torna mto mais trabalhoso o processo).
Se ainda fosse algo do s.o., tudo bem. Mas um aplicativo comercial, não vejo realmente o pq.

Ananias: newbie em C: Amigo

Falar que é dificil portar código escrito em C/C++ é ignorância... Este programa (visão artificial:http://am.esalq.usp.br/cv/contour_prove01.jpg) e este (Opengl 3D: http://am.esalq.usp.br/cv/mech3d.jpg) rodam em Windows/Linux sem 1 alteração no fonte.


Você pode argumentar que fazer uma GUI em linguagem de script (ex: Python + GTK) pode ser mais produtivo, e implementar bibliotecas que exijam performance em C é vantajoso. Que nem o ER diz no seu "The art of Unix programming", da mesma forma que escrever um S.O. em C (e não asm) era uma quebra de paradigma em 1972, hoje o novo paradigma é escrever GUIs em linguagem de script.


Justifique suas opiniões com fatos e lógica, não por preferências pessoais.


Até


Adenilson

Tambem acho que C nao eh a me: Tambem acho que C nao eh a melhor opcao, mas essa colocacao do CWagner foi perfeita!!!

Cássio R. Es_kelsen
cassio@br-mono.org

Pow: seja específico: Aaff, este é o meu último post, eu juro! Concordo que o C/C++ dá mais trabalho, e que otimizar sem necessidade é o caminho mais curto para o inferno (citando Steve Heller, "Optimizing C++").

Agora... dizer que sistemas grandes não podem ser escritos em C... você já ouviu falar no tal do Linux? Me parece que ele tem alguns milhões de LOC.

O que me irrita é nego que teve 6 meses de C na faculdade fazer pose de expert na linguagem. Pow: o que são coisas típicas de linguagem? Você nem se dá ao trabalho de citar!

Seriam, por acaso:

a) Ponteiros: a parte mais interessante da linguagem, porém como um bom canivete suíço você tem que saber usar.

b) Alocação dinâmica: o que garante seu programa usar somente o que precisa de recursos, não que nem uns apps em Java que ao carregar comem perto de 60 MB de RAM!



Adenilson

Um Novo Paradigma: Não estou interessado aqui em provar qual a melhor Linguagem. O Desenvolvimento de Software passou por muitas evoluções. Exatamente, C foi escolhida para ser a linguagem preferida (em seu tempo) de sistemas operacionais e outros softwares de baixo nível (contato imediato com a camada de hardware). Hoje em dia esses softwares são escritos em sua maioria utilizando-se a linguagem C++, pois esta suporta o conceito de orientação a objetos. Bom, um projeto em uma linguagem orientada a objetos é concerteza mais fácil de manter do quem em uma linguagem estruturada, por isso os softwares de gestão atualmente estão passando por um reviravolta, aqueles escritos em linguagem estruturada estão migrando para linguagens como Java. C# é uma ótima opção (se possível sobre a plataforma Mono). Ponteiros! é um problema sim, pois o programador, no lugar de se preocupar com a lógica de negócio do sistema que tenta implementar, deve gastar boa parte do seu tempo cuidando para a memória não "explodir" (pois se ele não gastar esse tempo, concerteza problemas de memória virão). Ninguém se torna um programador em 6 meses, seja qual for a linguagem). Programar é muito mais do que conhecer a linguagem, a sintaxe. O programador tem que fazer as decisões certas no tempo certo ( a melhor estratégia para atacar o problema).
C tem o seu charme, toda linguagem é mais adequada a um determinado uso. Acredito que para escrever software de gestão, C e nem C++ sejam mais adequadas do que Java ou C# (as outras eu não digo, pois não conheço).

Só mais uma coisa: Se o projeto for em Java ou em C#, concerteza eu vou contribuir
...
heheheheheheh

Faz em PHP-GTK, que é a melh: Faz em PHP-GTK, que é a melhor linguagem do mundo do universo inteiro para a minha opnião. Hahahhaha

Concordo com o CWagner. Faz com o que quiser (apesar de também concordar que talvez outras linguagens fossem mais FÁCEIS de implementar, e até de arrumar contribuição para o projeto, tendo em vista o foco dele)... :D

Gestão COmercial em PHP-GTK: Se vc quiser colaborar com uma Gestão Comercial GPL já existente e feita em PHP-GTK visite http://linuxstok.sourceforge.net

[]'s
Eduardo RBS
http://linuxstok.sourceforge.net

Erro grave de projeto: Na minha opinião, escolher C para um projeto desses é um erro grave de projeto.

Concordo contigo, e acrescento que acho terrivelmente improdutivo todo o bafafá que aparece (por exemplo, nessa discussão aqui no br-linux) quando uma coisa dessas é dita. Será que as pessoas não percebem que isso não é um ataque a elas e sim à decisão? Têm que levar isso pro lado pessoal?
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Muda só o "Makefile": Adenilson, eu sou um grande ignorante na área de programação =P, mas o "Makefile" tem que ser mudado. Por exemplo, só é possível compilar o MPlayer no FreeBSD com o GNU Make; Caso você queira compilar com o "make" tradicional do FreeBSD, terá que mudar o "Makefile" do MPlayer. A mesma coisa seria para Windows e outros sistemas...

A preferência pelas novas linguagens de alto-nível (Java, PHP, Python, Ruby, C#, etc...) deve ser porque elas são fáceis, interpretadas e "OS Independent"! E mesmo com todas essas vantagens, eu ainda sou um amante da linguagem Assembly! ;-)

CONCERTEZA?: Vá se ferrar... Você escreveu concerteza três vezes! PQP! É separado COM CERTEZA, seu jumento!

Eles têm razão!: Olá,

Venho há muito tempo fazendo soluções (de certa forma pequenas, porém integradas) para uso total de Linux nas empresas da minha região. Comecei com C + GTK+ em 96/97, depois passei para C++ + GTKmm em 98/99 e venho dando continuidade com este último em vários projetos. Já esperimentei PHP+GTK, Python+GTK, Java e até C#.Net (o cliente quem pediu, ele sempre tem razão e eu faço!). Agora quero passar tudo o que tenho em C++ + GTKmm para GTK# (Mono), que acho que será o mais razoável pensando-se em sistemas de gestão e pelo que venho lendo à respeito do mesmo. Java também é uma boa pedida.
Acabei adquirindo com o tempo bastante experiência nessa área e podemos compartilhar muitas coisas. Meu real interesse é passar tudo para PostgreSQL e GTK#, sendo que será necessário "conversar" também com os banco de dados MySQL e Oracle, além de alguns módulos para importar dados de arquivo Jet (mdb/mda tipicamente), DBF (Clipper) e alguns DAT (Cobol, Flexdata, etc), que é praticamente crucial para convencer/simular para com o empresariado.
Se estiver de acordo, podemos começar uma discussão na lista que criou "i-com-users@lists.sourceforge.net", da qual já faço parte, para darmos início ao tão sonhado projeto.


[]'s

Claudio

Um peregrino de problemas; Um pergaminho de soluções.

Banco de Dados: Sobre o banco de dados a utilizar, será que um banco utilizando SQLite não seria uma alternativa melhor ao MySQL? Creio que seria menor, mais simples e adequado ao software proposto.

Tem gente que já faz isso: O LinuxStok por padrão usa o SQLite, mas o usuário poderá optar pelo MySQL (os drivers para PostgreSQL e FireBird ainda estão sendo desenvolvidos).
A grande vantagem do SQLite, principalmente para pequenas empresas, é a facilidade de instalação. No caso do LinuxStok o usuário vai se preocupar apenas em instalar o programa, visto que o SQLite já virá embutido.

[]'s
Eduardo RBS
http://linuxstok.sourceforge.net

BD: Se vc for fazer em Java, dá pra usar o HSQLDB que é embutido e java-puro.

Assembly: Assembly, C, todas essas linguagens tem seu nicho, e nisso elas são imbatíveis :)

Se fizer em Java, pode utiliz: Se fizer em Java, pode utilizar frameworks de persistencia como o Hibernate. Daí teria toda a liberdade de trocar de banco sem ter que mudar nada no código, apenas em arquivos de configuração. Eu escolheria Java porque:
- Existem inumeros frameworks eficientes, eficazes e maduros
- Struts ou JSF para WEB/MVC
- XWork para Desktop/MVC
- SWT, Swing, Thinlets como widgets para aplicações Desktop
- Spring e/ou EJB para camada de negocios
- Hibernate ou JDO para persistencia
- Servidores de aplicação J2EE gratuitos GPL/LGPL
- JBoss
- JonAS
- Container WEB
- Tomcat
- Jetty
- Excelentes IDEs
- Eclipse
- Netbeans
- Excelente suporte a orientação a aspectos
- AspectJ
- Aspectwerktz
- JBoss AOP
- Grupos de desenvolvimento consolidados
- JBoss group
- Apache Software Foundation
- OpenSymphony
- Codehaus
- Eclipse.org
- Object WEB
- 99% OO (tirando os tipos primitivos, hehehe)
- Padrões de projeto consolidados
- Multi plataforma
- Multi fornecedor

Eu escolho C/C++ pq: : Eu escolho C/C++ pq:
1 - nao preciso saber 348957345 siglas/tecnologias terminadas com J para dizer que minha linguagem eh capaz de fazer algo. Basta meu editor de texto e meu compilador.
2 - Ter APIs para QUALQUER banco de dados descente. E uma coisinha chamada PRECOMPILADORES (e ainda botam banca falando de performance em DB... ehhehehe, entao tah, ne?!).
4 - Ter as melhores libs e compiladores escritas na minha linguagem: GTK, Blitz++, IC, Perl RegExp C Lib, etc etc etc etc etc
3 - comunidade? copy/paste aqui da estatistica do sourceforge sobre numero_de_projetos X linguagens.
4 - ganhar muito dinheiro nas costas dos ignorantes que pensam que fazer portabilidade em codigo fonte eh magica.
5 - Ponteiros. Ponteiros. e Ponteiros. Deus abençoe o sonho que fez ou Brian ou Kernighan sonhar com Ponteiros!
6 - Nao ter uma lesma nojenta mexendo na sua memoria (programadores que nao saber desalocar a propria memoria nao sao programadores, sao 'caga-codigos') (e pior: dando a ilusao que nao esta deixando escapar memoria! AHAHAHAHAHAHAHAHAHA).
7 - TEMPLATES (agora sim estamos falando de OO de verdade: http://erdani.org/book/main.html)
8 - Ter tudo q qualquer outra linguagem diz ter e pensa q soh eles teem... pois somos modestos e sabemos que quem faz o mundo girar a mais de 30 anos SOMOS NOS!!

Estes códigos bretereiros, m: Estes códigos bretereiros, maçanetas,

Só falam não fazem nada e só ficam metendo pitaco, um dia que um de vocês ajudarem em algo mais do que ficar discutindo hipocrisia, me falem!!!
Bando de de ignorantes, só sabem discutir, ajudar ninguêm quiere.

Newbie em C?: Newbie?

Você já programou com GTK em C, para ver o inferno que é? Cada vez que você cria um objeto, tem que usar a função gtk_???_new, enquanto em Python isso é transparente.

Além disso, qualquer função para manipular um objeto do Gtk em C você tem que usar a função gtk_TipoDoObjeto_Ação (referênciaParaOObjeto, argumentos), enquanto em Python você resume isso para referência.ação (argumentos)

Não é só isso. Sempre que você quer aplicar uma ação a um tipo de objeto você tem que voltar para o devhelp, procurar qual é o nome da função que aplica aquela ação naquele tipo de objeto, etc, etc, etc.

É chato. É demorado. É até desencorojador. Se você já tivesse usado C e Python para programar com Gtk, você entederia exatamente o que eu estou dizendo. O conceito de programação gráfica é muito ligado à orientação a objeto, e, por mais que a Gtk faça um bom trabalho para implementar orientação a objeto em C, nunca vai ficar tão natural quanto uma linguageem que seja naturalmente OO. Evidentemente, se você já tivesse usado GTK, saberia disso. Não é a toa que a grande maioria dos novos programas para Gnome desenvolvidos pelo pessoal do gnome.org seja escrito em Python, ou C#.

Essa argumentação não serve só para C: A grande maioria dos seus argumentos também serviriam para justificar escolher Assembly para escrever um programa desse tipo. Se, partindo dos seus argumentos, algo tão idiota pode ser deduzido, podemos concluir que seus argumentos são falsos.

C é bom para muitas coisas. Para escrever um kernel, por exemplo. Ou um servidor Web. Ou um back-end de um banco de dados. Mas, para uma aplicação front-end definitivamente não. Escolha a ferramenta certa para o trabalho certo. Não se apegue tanto a uma ferramenta a ponto de achar que ela é a melhor e mais indicada para todos os trabalhos. Caso contrário, você pode acabar tentando usar um martelo para aparafusar um parafuso.

Siages - Sistema Aberto de Gestão Empresarial Solis: A iniciativa é válida, mas talvez fosse mais produtivo participar do Siages, um projeto similar, feito por desenvolvedores brasileiros que tem o mesmo objetivo. Uma versão do produto foi noticiada dias atrás aqui no Br-Linux.

Visite o projeto em http://siages.solis.coop.br

gestao comercial: bom pessoal sei que nao é o melhor lugar para perguntar isso
mas é o seguinte trabalho num distribuidor de alimentação e temos um programinha muito ruim lá gostaria de saber se alguém tem alguma experiencia com consignações pois isso é uma pedra no meu sapato desde já agradeço

Ilusão...: Uma coisa me irritou um pouco:

3 - comunidade? copy/paste aqui da estatistica do sourceforge sobre numero_de_projetos X linguagens.
16331 projetos em Java, 16445 em C++ e 15684 em C. Me parece mais empate técnico...

Além disso, praticamente todos os pontos que você apontou são falsos ou irrelevantes. O ponto 2 é tão verdadeiro para java quanto para C/C++. E quanto a desempenho, existem compilações que podem ser feitas com bytecode em runtime (com código gerenciado) que não são possíveis com código compilado, não-gerenciado. Em muitos casos java pode ser mais rápido que C ou C++ por conta disso. 4 também é uma razão boboca, basta poder usar em Java que não importa a linguagem em que a biblioteca foi escrita (e existe MUITA biblioteca pra java... até assusta). 5 - ponteiros são corda pra se enforcar e segundo estatísticas verossímeis que ouvi falar, razão de 80% dos bugs em C, que por sua vez tem 80% ou mais do tempo de desenvolvimento dedicado a consertar bugs. Não lembro a fonte e não vou jurar sobre essas estatísticas, mas parecem *muito* com a minha experiência de programação profissional. Templates são legais, mas Java 1.5 tem algo parecido chamado Generics.

Mas o que eu acho extremamente errado é esse tipo de abordagem "selecionada" de argumentos. Poxa, é verdade, existem linguagens muito ruins e linguagens muito boas. As muito ruins merecem ser expostas, e até a abordagem apenas combativa não é tão ruim. Agora, sair desfilando esse monte de abobrinha unilateral? Se vai falar da linguagem, fale dos méritos técnicos dela e explique direitinho (como os eternos flamejadores de python), não crie esse tanto de razões nonsense.

Java está longe de ser perfeita. Mas C++ também. Se eu for programar um aplicativo de janelas razoavelmente complexo hoje a partir do zero, acho que prefiro aprender uma linguagem tipo ruby ou python do zero e então desenvolver nela: uma semana de aprendizado valerá o tempo economizado na programação e depuração. Se eu for programar uma aplicação web corporativa que tenha que ser escalável, vou escolher J2EE. Se for pequena, PHP. Se for uma aplicação genérica em que a portabilidade seja ultra-importante, Java. Se for algo científico ou mais complicado para um propósito específico, C ou C++. Se for linha de comando, C. E daí por diante... essas são minhas preferências pessoais para linguagens, quer dizer, sou eu que prefiro assim, e alguns parâmetros ainda podem mudar as escolhas, como: se estou desenvolvendo para um cliente, eu posso ter que usar a linguagem que o pessoal que ele emprega entende.

Escolha a sua linguagem. Mencione os méritos técnicos dela e os deméritos das outras, se quiser. Mas faça isso de maneira científica e imparcial. Falar que Java - JUSTO JAVA! - não tem uma comunidade grande o suficiente foi dose...
--
LinuxFUD, o TIRA-TEIMA dos ataques ao software livre: http://linuxfud.org

Concordo desde que...: Bem, meu objetivo não era comparar tecnologias e sim mostrar o que temos em Java, mas se você partiu por aí, tenho argumentos para rebater.

1 - nao preciso saber 348957345 siglas/tecnologias terminadas com J para dizer que minha linguagem eh capaz de fazer algo. Basta meu editor de texto e meu compilador.
=== Em Java também tenho esta opção, basicamente preciso de:
* J2SDK - Kit de desenvolvimento que traz a maquina virtual e compilador.
* Editor de texto ASCII.

Sem essa, estamos no empate aqui.

2 - Ter APIs para QUALQUER banco de dados descente. E uma coisinha chamada PRECOMPILADORES (e ainda botam banca falando de performance em DB... ehhehehe, entao tah, ne?!).
=== Sim, temos o JDBC, praticamente todos os bancos de dados utilizados implementam a API do JDBC, fazendo o acesso universal. O que quis colocar quando falei sobre banco de dados é independecia de dialetos. Se usar o Hibernate, a mesma aplicação que roda em oracle vai rodar em MySQL, modificando apenas configurações.

4 - Ter as melhores libs e compiladores escritas na minha linguagem: GTK, Blitz++, IC, Perl RegExp C Lib, etc etc etc etc etc
=== Temos tudo isso em Java, inclusive o GTK, REGEXP, etc.

3 - comunidade? copy/paste aqui da estatistica do sourceforge sobre numero_de_projetos X linguagens.
=== Isso não quer dizer muita coisa, o que quis colocar é que a comunidade Java tras grandes empresas e grupos consolidados.

4 - ganhar muito dinheiro nas costas dos ignorantes que pensam que fazer portabilidade em codigo fonte eh magica.
=== Em Java, pego o mesmo binario (bytecode) e rodo em qualquer lugar que tenha máquina virtual. Temos máquinas virtuais disponiveis em ambientes que variam de Mainframe até celulares (MIDP).

5 - Ponteiros. Ponteiros. e Ponteiros. Deus abençoe o sonho que fez ou Brian ou Kernighan sonhar com Ponteiros!
=== Pode ser bom para fazer drivers, bibliotecas de baixo nivel, acesso ao Sistema Operacional, mas definitivamente, uma aplicação comercial não pode parar por causa de uma memoria mal alocada.

6 - Nao ter uma lesma nojenta mexendo na sua memoria (programadores que nao saber desalocar a propria memoria nao sao programadores, sao 'caga-codigos') (e pior: dando a ilusao que nao esta deixando escapar memoria! AHAHAHAHAHAHAHAHAHA).
=== É eu sou um caga código, não mexo com ponteiros há anos.

7 - TEMPLATES (agora sim estamos falando de OO de verdade: http://erdani.org/book/main.html)
=== Java 5.0 traz os Generics, hey, mas isso é C++, não C. tsc, tsc, tsc.

8 - Ter tudo q qualquer outra linguagem diz ter e pensa q soh eles teem... pois somos modestos e sabemos que quem faz o mundo girar a mais de 30 anos SOMOS NOS!!
=== Os tempos mudam meu amigo! Queremos eficiencia e eficacia, queremos nos preocupar com as regras de negocio, não com detalhes tecnicistas!