• Caro Visitante, por que não gastar alguns segundos e criar uma Conta no Fórum Valinor? Desta forma, além de não ver este aviso novamente, poderá participar de nossa comunidade, inserir suas opiniões e sugestões, fazendo parte deste que é um maiores Fóruns de Discussão do Brasil! Aproveite e cadastre-se já!

Linguagem de Programação e Compiladores: Dicas e preferências

Elring

Depending on what you said, I might kick your ass!
Olá a todos! Estou no início da minha faculdade de Sistemas de Programação e, recentemente comecei a aprender a Linguagem C. Confesso que entrei em pânico no início e agora estou gostando. Gostaria de saber dos colegas que compiladores são mais fáceis de utilizar, uso o Code Blocks, mas não gosti muito. Sei que há outros, como o Notepad++, nas não aprendi a instalar a bagaça. Se puderem deixar aqui suas experiências em Linguagem de programação (pode ser Python, Perl (segundo meu professor, é pra cachorro louco :lol: ), Java, ASP.Net), vai ser de grande ajuda, pois vou estudá-las até o fim do curso.
 
Sou analista de sistemas, formado em 2005 em Sistemas de Informação - como tecnólogo. Mas antes, eu tinha estudado desenvolvimento de sistemas na ETESP.

Provei um pouco de cada linguagem de programação. Pascal e C, quando eu estava aprendendo a programar, e C quando eu fiz um curso de verão na USP sobre estruturas de programação; Delphi, a minha primeira ferramenta de desenvolvimento visual, Visual Basic .Net quando eu aprendi orientação a objetos, ASP e PHP para criar alguns sites. Vi um pouco de Python, quando eu fiz um mini curso para criação de jogos.
Vi bastante Java, onde estudei um pouco de J2EE.
E Visual Basic, a linguagem que mais uso aqui no trabalho e que tenho mais experiência.

Sei que há outros, como o Notepad++, nas não aprendi a instalar a bagaça.
Não sei se entendi certo, mas Notepad++ não é compilador. É só um editor de texto.
 
então, precisa entender alguns conceitos beeeeeeeem resumidos:

compilador - cria um executável a partir de um código fonte
IDE - interface para auxiliar na tarefa de criar o código

vc provavelmente tá procurando uma IDE legal. eu pessoalmente gosto do vi, mas tem umas mais user-friendly como Dev-CPP (free), NetBeans (free) e Visual C++ express (versão free com limitações chatas). Esses são pra C, que acredito, é a melhor linguagem pra estudar.

perl é uma linguagem interpretada extremamente simples que não precisa de um compilador. se você vai trabalhar algum dia com ambientes unix, essa linguagem vai ser pau pra toda obra. melhor dominá-la, se é o plano - e não é bicho de sete cabeças como foi apresentado.

a minha recomendação é que vc vire o deus do C e do Perl, para depois partir pra Java. Java, tecnicamente falando, não é muito difícil. para vc ficar bom em java, vc deve dominar mais conceitos do que ser extremamente prolixo na linguagem. entretanto, em curso superior, normalmente, infelizmente a abordagem de Java é extremamente simples e foca mais sintaxe e afins do que conceitos de concorrência, EE, etc etc etc; pergunte ao seu professor se vcs vão estudar algum framework no decorrer do curso. Se a resposta for negativa, comece a se organizar para estudar por conta e/ou fazer alguns cursos extras.
 
Não se assuste. Programação é uma coisa apaixonante se você for contaminado. Eu comecei escrevendo sobre linguagens de programação e compiladores e, sem perceber, acabei com um texto que vai servir para uns três anos da sua faculdade :) Use o que você conseguir aproveitar.

---

Para começar, separe as coisas umas das outras: linguagem, compilador, editor de texto e IDE. C é a linguagem; GCC é um compilador; Gedit, vim, emacs, etc. são editores de texto; Eclipse e Netbeans são IDEs. Como o objetivo é didático, recomendo não começar usando IDEs -- use o compilador manualmente e entenda como ele funciona. Só depois parta para uma IDE.

Aprenda C (não confunda com C++, são linguagens diferentes embora muitas pessoas inventam de misturar as coisas logo no começo, isso não é nada didático). Mesmo que você não vá programar em C profissionalmente, é importante saber usá-lo para coisas que exigem desempenho ou alguma proximidade do hardware. Mas não acredite em ningué que diz "tudo que for escrito em C é rápido": é possível escrever código extremamente ineficiente em C, mais lento que o código equivalente em linguagens interpretadas, se o programador não souber o que está fazendo, mas aí está parte da importância dele no aprendizado. Nas mãos de um programador experiente, C é imbatível para muitas coisas.

Muito código importante hoje é escrito em C (sistemas operacionais, compiladores servidores web, de bancos de dados, os interpretatores e máquinas virtuais de virtualmente qualquer outra linguagem) e existe um bocado de oportunidades de trabalho nessa área -- eu desenvolvo software embarcado para equipamentos de rede, quase tudo em C.

Os livros didáticos normalmente só ensinam como usar a biblioteca padrão C, mas estude algumas bibliotecas mais práticas quando ganhar confiança. Código do mundo real raramente se limita à bibioteca padrão. Veja as funções POSIX (a API nativa do Linux e outros Unices) e só depois brinque um pouco com a GTK+ -- ela é fantástica, mas não é simples. Exige um bocado de conhecimento além de C; para começo de conversa, ela é orientada a objeto em C (novamente, não é C++). Não se assuste com esse o termo: você terá uma cadeira de orientação a objetos lá pelo segundo ou terceiro semestre do seu curso, e muitos professores parecem ignorar que orientação a objetos é uma forma de projetar software, não um recurso exclusivo das linguagens orientadas a objeto (Java, etc).

Note que há uma separação entre o compilador C e o pré-processador. Muitos livros e professores deixam isso passar.

Pegue um Linux ou o FreeBSD e entenda o ecossistema; o que cada componente faz, como as bibliotecas, processos e daemons se relacionam, etc. Isso é importantíssimo. Há vários sistemas virtualização (como o VirtualBox) que você pode usar para fuçar e experimentar sem arriscar a instalação do seu sistema operacional normal ou ter que dedicar um segundo computador só para isso. Aprenda a usá-los!

Aprenda como funcionam os build-systems para o compilador. Compilar programas não-triviais é não-trivial (!), e provavelmente você vai esberar em alguns deles nas experimentações que sugeri no parágrafo anterior... há muita coisa importante em sequências como "./configure && make && make install" ! Entenda separar programas complexos em módulos, como escrever um Makefile e usá-lo para automatizar a compilação dos seus programas.

Aprenda algumas linguagens interpretadas de nível mais elevado, Python e Java são dois bons exemplos. Elas tem bibliotecas padrões imensas e já vem "de fábrica" com coisas que, em C, você teria que criar do zero ou procurar bibliotecas externas. Estude as diferenças entre as linguagens, como elas lidam com tipos de dados e com a memória. Aprenda a diferença entre tipagem forte e fraca e estática e dinâmica. Estude como as máquinas virtuais dessas linguagens se comportam e porque elas são ótimas para muitas coisas e péssimas para outras tantas.

Eu tenho alguns projetos envolvendo uma linguagem chamada Lua e recomendo (meio parcialmente) que você estude-a. Ela é extremamente elegante (um conceito interessante para linguagens de programação, você verá) e tem recursos muito poderosos, mesmo que não o pareçam a primeira vista -- não se assuste com os termos, mas coisas como closures, funções como objetos de primeira classe e co-rotinas são a base de muitas construções de alto nível.

PHP é uma linguagem horrível que serve para fazer coisas ótimas. Estude-a para entender o que há e errado e porque é difícil fazer a coisa certa com ela. Mas você precisará de algum conhecimento da arquitetura da Web e do funcionamento do HTTP antes.

Depois de tudo isso, aprenda LISP. Sim, Common LISP, aquela linguagem assustadora e cheia de parênteses que você provavelmente não usará profissionalmente (escrevo isso apesar de eu ter usado AutoLISP por alguns anos no meu emprego anterior) mas que tem todos os recursos das linguagens modernas. O valor didático de conhecê-la é imenso. Talvez você passe a encher suas frases de parênteses depois disso.

Aprenda algoritmos. Não aquela coisa de portugol (ainda usam esse termo?) , mas os conceitos subjacentes. Você provavelmente terá uma cadeira de análise de algoritmos depois de alguma de ciência da computação teórica -- "a Ciência da Computação está para computadores assim como a Astronomia está para telescópios" como (acho) dizia o Dijkstra. Muitas coisas ficam mais claras sabendo a diferença entre O(1), O(n), (n^m) e O (m^n), O(n!), etc.

Aprenda estrutura de dados e como implementá-las na linguagem de escolha. Conseguir organizar informação em uma forma adequada ao processamento é fundamental. Você terá cadeiras de estruturas de dados durante dois ou três semestres. Saber quando usar um vetor, lista, fila, árvore, hash, etc. é importante, mesmo que depois tudo que você faça será enfiar esses dados em um banco de dados -- que implementará essas estruturas, então você precisará saber delas para

Aprenda a pensar paralelamente. Você terá uma ou duas cadeiras de programação paralela ou algo assim. Isso não é novidade, mas separar a execução de um programa em segmentos semi-independentes é fundamental para aproveitar os processadores multi-core que são padrões hoje ou distribuir programas imensos e complexos entre vários computadores.

Se isso não te assustou ainda, não se preocupe. Dá para aprender a programar em 10 anos :) (mas esse texto é sério e vale a leitura!)

Aprenda a usar um sistema de controle de versão. Esse tipo de ferramenta é fundamental para qualquer desenvolvimento sério e qualquer empresa da área precisa usar uma delas (*) para qualquer código não-trivial. Sugiro o Git, que é prático, rápido, fácil de usar, distribuído e é usado por montes de projetos de alta estirpe.

Um sistema de versionamento distruido é interessante porque você pode ter várias instâncias do repositório espalhadas em computadores diferentes, com pessoas diferentes ou hospedadas em sites específicos (como o GitHub) compartilhando código e o histórico do projeto entre si. A utilidade disso pode não ficar clara no começo, mas acredite: quando você descobrir, não conseguirá mais viver sem.

Outras opções são o Mercurial, Bazaar e Subversion -- esse último não é distribuído e mostra sinais de cansaço, mas funciona bem para alguns estilos de projeto (o MUD é o único dos meus projetos que não migrei para o Git exatamente porque ele cai nessa categoria). Há alguns sistemas (muito bem) pagos como o ClearCase e o Perforce que estão fora de cogitação para o seu caso, mas você pode encontrar eles em uso em alguma empresa em que trabalhar. Ah, fuja do CVS como se fosse a praga!

Pegue código de software open source e estude como eles funcionam; faça mudanças e brinque. Acompanhe o desenvolvimento de alguns deles e veja como a equipe se relaciona, como features são planejadas e implementadas e como bugs são corrigidos.

(*) Há quem não use, mas não conto esse tipo de desenvolvedor entre os "profissionais da área".
 
Sou analista de sistemas, formado em 2005 em Sistemas de Informação - como tecnólogo. Mas antes, eu tinha estudado desenvolvimento de sistemas na ETESP.

Provei um pouco de cada linguagem de programação. Pascal e C, quando eu estava aprendendo a programar, e C quando eu fiz um curso de verão na USP sobre estruturas de programação; Delphi, a minha primeira ferramenta de desenvolvimento visual, Visual Basic .Net quando eu aprendi orientação a objetos, ASP e PHP para criar alguns sites. Vi um pouco de Python, quando eu fiz um mini curso para criação de jogos.
Vi bastante Java, onde estudei um pouco de J2EE.
E Visual Basic, a linguagem que mais uso aqui no trabalho e que tenho mais experiência.


Não sei se entendi certo, mas Notepad++ não é compilador. É só um editor de texto.

Isso explica a razão de eu ter apertado F8 feito um doido e não ter acontecido nada! Eu achei que fosse defeito ou bug do PC.

então, precisa entender alguns conceitos beeeeeeeem resumidos:

compilador - cria um executável a partir de um código fonte
IDE - interface para auxiliar na tarefa de criar o código

vc provavelmente tá procurando uma IDE legal. eu pessoalmente gosto do vi, mas tem umas mais user-friendly como Dev-CPP (free), NetBeans (free) e Visual C++ express (versão free com limitações chatas). Esses são pra C, que acredito, é a melhor linguagem pra estudar.

perl é uma linguagem interpretada extremamente simples que não precisa de um compilador. se você vai trabalhar algum dia com ambientes unix, essa linguagem vai ser pau pra toda obra. melhor dominá-la, se é o plano - e não é bicho de sete cabeças como foi apresentado.

a minha recomendação é que vc vire o deus do C e do Perl, para depois partir pra Java. Java, tecnicamente falando, não é muito difícil. para vc ficar bom em java, vc deve dominar mais conceitos do que ser extremamente prolixo na linguagem. entretanto, em curso superior, normalmente, infelizmente a abordagem de Java é extremamente simples e foca mais sintaxe e afins do que conceitos de concorrência, EE, etc etc etc; pergunte ao seu professor se vcs vão estudar algum framework no decorrer do curso. Se a resposta for negativa, comece a se organizar para estudar por conta e/ou fazer alguns cursos extras.

Valeu pelas dicas, vou baixar o Dev-CPP e o NetBeans para testar e ver como é! Então, Perl não é difícil como meu professor disse, vou dar uma olhada mais atenta nela e ver alguns tuturiais!

Não se assuste. Programação é uma coisa apaixonante se você for contaminado. Eu comecei escrevendo sobre linguagens de programação e compiladores e, sem perceber, acabei com um texto que vai servir para uns três anos da sua faculdade :) Use o que você conseguir aproveitar.

---

Para começar, separe as coisas umas das outras: linguagem, compilador, editor de texto e IDE. C é a linguagem; GCC é um compilador; Gedit, vim, emacs, etc. são editores de texto; Eclipse e Netbeans são IDEs. Como o objetivo é didático, recomendo não começar usando IDEs -- use o compilador manualmente e entenda como ele funciona. Só depois parta para uma IDE.

Aprenda C (não confunda com C++, são linguagens diferentes embora muitas pessoas inventam de misturar as coisas logo no começo, isso não é nada didático). Mesmo que você não vá programar em C profissionalmente, é importante saber usá-lo para coisas que exigem desempenho ou alguma proximidade do hardware. Mas não acredite em ningué que diz "tudo que for escrito em C é rápido": é possível escrever código extremamente ineficiente em C, mais lento que o código equivalente em linguagens interpretadas, se o programador não souber o que está fazendo, mas aí está parte da importância dele no aprendizado. Nas mãos de um programador experiente, C é imbatível para muitas coisas.

Muito código importante hoje é escrito em C (sistemas operacionais, compiladores servidores web, de bancos de dados, os interpretatores e máquinas virtuais de virtualmente qualquer outra linguagem) e existe um bocado de oportunidades de trabalho nessa área -- eu desenvolvo software embarcado para equipamentos de rede, quase tudo em C.

Os livros didáticos normalmente só ensinam como usar a biblioteca padrão C, mas estude algumas bibliotecas mais práticas quando ganhar confiança. Código do mundo real raramente se limita à bibioteca padrão. Veja as funções POSIX (a API nativa do Linux e outros Unices) e só depois brinque um pouco com a GTK+ -- ela é fantástica, mas não é simples. Exige um bocado de conhecimento além de C; para começo de conversa, ela é orientada a objeto em C (novamente, não é C++). Não se assuste com esse o termo: você terá uma cadeira de orientação a objetos lá pelo segundo ou terceiro semestre do seu curso, e muitos professores parecem ignorar que orientação a objetos é uma forma de projetar software, não um recurso exclusivo das linguagens orientadas a objeto (Java, etc).

Note que há uma separação entre o compilador C e o pré-processador. Muitos livros e professores deixam isso passar.

Pegue um Linux ou o FreeBSD e entenda o ecossistema; o que cada componente faz, como as bibliotecas, processos e daemons se relacionam, etc. Isso é importantíssimo. Há vários sistemas virtualização (como o VirtualBox) que você pode usar para fuçar e experimentar sem arriscar a instalação do seu sistema operacional normal ou ter que dedicar um segundo computador só para isso. Aprenda a usá-los!

Aprenda como funcionam os build-systems para o compilador. Compilar programas não-triviais é não-trivial (!), e provavelmente você vai esberar em alguns deles nas experimentações que sugeri no parágrafo anterior... há muita coisa importante em sequências como "./configure && make && make install" ! Entenda separar programas complexos em módulos, como escrever um Makefile e usá-lo para automatizar a compilação dos seus programas.

Aprenda algumas linguagens interpretadas de nível mais elevado, Python e Java são dois bons exemplos. Elas tem bibliotecas padrões imensas e já vem "de fábrica" com coisas que, em C, você teria que criar do zero ou procurar bibliotecas externas. Estude as diferenças entre as linguagens, como elas lidam com tipos de dados e com a memória. Aprenda a diferença entre tipagem forte e fraca e estática e dinâmica. Estude como as máquinas virtuais dessas linguagens se comportam e porque elas são ótimas para muitas coisas e péssimas para outras tantas.

Eu tenho alguns projetos envolvendo uma linguagem chamada Lua e recomendo (meio parcialmente) que você estude-a. Ela é extremamente elegante (um conceito interessante para linguagens de programação, você verá) e tem recursos muito poderosos, mesmo que não o pareçam a primeira vista -- não se assuste com os termos, mas coisas como closures, funções como objetos de primeira classe e co-rotinas são a base de muitas construções de alto nível.

PHP é uma linguagem horrível que serve para fazer coisas ótimas. Estude-a para entender o que há e errado e porque é difícil fazer a coisa certa com ela. Mas você precisará de algum conhecimento da arquitetura da Web e do funcionamento do HTTP antes.

Depois de tudo isso, aprenda LISP. Sim, Common LISP, aquela linguagem assustadora e cheia de parênteses que você provavelmente não usará profissionalmente (escrevo isso apesar de eu ter usado AutoLISP por alguns anos no meu emprego anterior) mas que tem todos os recursos das linguagens modernas. O valor didático de conhecê-la é imenso. Talvez você passe a encher suas frases de parênteses depois disso.

Aprenda algoritmos. Não aquela coisa de portugol (ainda usam esse termo?) , mas os conceitos subjacentes. Você provavelmente terá uma cadeira de análise de algoritmos depois de alguma de ciência da computação teórica -- "a Ciência da Computação está para computadores assim como a Astronomia está para telescópios" como (acho) dizia o Dijkstra. Muitas coisas ficam mais claras sabendo a diferença entre O(1), O(n), (n^m) e O (m^n), O(n!), etc.

Aprenda estrutura de dados e como implementá-las na linguagem de escolha. Conseguir organizar informação em uma forma adequada ao processamento é fundamental. Você terá cadeiras de estruturas de dados durante dois ou três semestres. Saber quando usar um vetor, lista, fila, árvore, hash, etc. é importante, mesmo que depois tudo que você faça será enfiar esses dados em um banco de dados -- que implementará essas estruturas, então você precisará saber delas para

Aprenda a pensar paralelamente. Você terá uma ou duas cadeiras de programação paralela ou algo assim. Isso não é novidade, mas separar a execução de um programa em segmentos semi-independentes é fundamental para aproveitar os processadores multi-core que são padrões hoje ou distribuir programas imensos e complexos entre vários computadores.

Se isso não te assustou ainda, não se preocupe. Dá para aprender a programar em 10 anos :) (mas esse texto é sério e vale a leitura!)

Aprenda a usar um sistema de controle de versão. Esse tipo de ferramenta é fundamental para qualquer desenvolvimento sério e qualquer empresa da área precisa usar uma delas (*) para qualquer código não-trivial. Sugiro o Git, que é prático, rápido, fácil de usar, distribuído e é usado por montes de projetos de alta estirpe.

Um sistema de versionamento distruido é interessante porque você pode ter várias instâncias do repositório espalhadas em computadores diferentes, com pessoas diferentes ou hospedadas em sites específicos (como o GitHub) compartilhando código e o histórico do projeto entre si. A utilidade disso pode não ficar clara no começo, mas acredite: quando você descobrir, não conseguirá mais viver sem.

Outras opções são o Mercurial, Bazaar e Subversion -- esse último não é distribuído e mostra sinais de cansaço, mas funciona bem para alguns estilos de projeto (o MUD é o único dos meus projetos que não migrei para o Git exatamente porque ele cai nessa categoria). Há alguns sistemas (muito bem) pagos como o ClearCase e o Perforce que estão fora de cogitação para o seu caso, mas você pode encontrar eles em uso em alguma empresa em que trabalhar. Ah, fuja do CVS como se fosse a praga!

Pegue código de software open source e estude como eles funcionam; faça mudanças e brinque. Acompanhe o desenvolvimento de alguns deles e veja como a equipe se relaciona, como features são planejadas e implementadas e como bugs são corrigidos.

(*) Há quem não use, mas não conto esse tipo de desenvolvedor entre os "profissionais da área".

Esse texto vai ser meu guia durante todo o meu curso! Valeu, chefe! Agora já tenho um norteador do que usar e estudar :issoaih:
 
Dei uma fuçada em alguns e gostei mais dos aplicativos para o sistema Linux, mais especificamente para o Ubuntu. E gostei demais da linguegem Python! O tutorial que peguei foi centenas de vezes mais explicativo do que as aulas de C :dente:

Aqui, o tutorial:

Ver anexo Aprenda_a_Programar-Luciano_Ramalho.pdf
 
Vendo o post do dermeister me faz ver que eu realmente não aprendi quase nada de programação.
E infelizmente não falo isto só para pagar um pau. Eu aprendi quase nada destes tópicos (ou cadeiras, como você escreveu), tanto na facu, quanto no ensino técnico.

E olha que, um tempo atrás, eu fiz um curso de verão na USP, sobre tópicos de programação. Durou apenas 2 meses e passou um pouco dos conceitos de estruturas de dados e algoritmos. Mal consegui acompanhar, e meu irmão, que também é analista, abandonou o curso.

Será que ainda tenho salvação, mesmo fora da faculdade?
 
Um adendo ao que o dermeister escreveu é: se atualize, conheça profissionais e blogs sobre programação que ajudam muito a entender os problemas, a filosofia por trás também. não estou falando daquele blog que comenta "dicas para configurar tal plugin" esse é um outro tipo de blog que ajuda bastante, mas falo de coisas mais abstratas.. =)
Se realmente o bug da programação "te pegar". Faça algo que acrescente à tua coragem técnica e aprenda a escrever testes unitários, mas entenda o pq deles serem tão importantes e tão defendidos por diversos luminares da área. (se precisar de referências, me avisa)

Finalmente, no final de todo esse aprendizado, tente participar de algum grupo de software craftsmanship, é um conceito antigo (craftsmanship) mas a ideia é que programação em determinado contexto não é produção em massa e sim uma arte, algo que buscando o exemplo de um mestre e descobrindo as "tricks of the trade" com ele, com mentoring mais forte, o artesão consegue se aperfeiçoar na arte, é bem interessante.
 
inicie uma pós de especialização em engenharia de software. a PUC-SP tem umas possibilidades boas.

Olha, não sei se simplesmente iniciar uma pós em engenharia de software vai ajudar o Clown.. as dicas do dermeister (e as minhas, humildemente) são para aprender a arte mas sem necessariamente a necessidade de um estudo formal. Não sou contra, mas o que escrevemos não é salientado atualmente nos cursos acadêmicos que eu vi não..
 
Olha, não sei se simplesmente iniciar uma pós em engenharia de software vai ajudar o Clown.. as dicas do dermeister (e as minhas, humildemente) são para aprender a arte mas sem necessariamente a necessidade de um estudo formal. Não sou contra, mas o que escrevemos não é salientado atualmente nos cursos acadêmicos que eu vi não..
somente isso é claro que não vai ajudar. "estudo formal" é interessante se e somente se conduzido com um bom planejamento de estudos por conta. o lance é que esse curso da puc tem um método bem legal, apesar de ser meio caro.
 
Ah, fuja do CVS como se fosse a praga!
Dermeister, por que você não gosta do CVS?

Foi o único controlador de versões que minha equipe usou. O que há de vantajoso em usar outra ferramenta como SubVersion?
Qual é sua opinião pessoal?
 
Um resumo dos meus problemas com o CVS, mais ou menos em ordem de chateação, e uns comentários de como o Git e o Subversion tratam os casos:

- Ele versiona arquivos, não o repositório. O CVS não controla versões sobre o repositório ou sobre uma árvore de diretórios, mas sobre arquivos individuais. Cada arquivo tem seu número de revisão e um commit que altera vários deles simplesmente coloca uma cópia dos metadados em cada arquivo. Ao contrário do que acontece com o Git e o SVN, não há uma forma prática de dizer "mostre o que o commit x mudou em todos os arquivos". O jeito é indicar datas e horas ou "passar a régua" colocando um tag para marcar a revisão. O problema é que ...

- ... tags e branches são lentos e "caros". Dadas as limitações do formato do repositório (herdado do RCS), criar uma tag nova implica em modificar *todos* os arquivos de dados guardados no repositório (aqueles arquivos ",v"), colocando uma entrada que relaciona o nome da tag à revisão específica que aquele arquivo estava no momento. Criar um branch é algo parecido, mas implica também em aumentar uma casa no número da versão (se o seu arquivo está na versão "1.5", a versão do branch vira algo como "1.5.1". Um branch feito dessa versão vira "1.5.1.1" e assim vai). O processo é lento em função do número de arquivos no repositório (não tente importar projetos imensos como o Linux nele!).

No Git, branches e tags são meros nomes para o objeto que representa o commit e podem ser criados aos montes, local e remotamente, sem deixar o repositório lento. Você pode criar branches locais para testes, experimentação, trabalhos em andamento, etc. e apagá-los e fundi-los depois que tudo estiver pronto. É fantástico ;)

Os branches do Subversion são coisas um pouco diferentes e estritamente falando, vendo apenas pela forma como os dados são armazenados no repositório, ele não "tem" branches ou tags: estes são, basicamente, cópias de um diretório para as quais o cliente dá uma interpretação especial. Criar um branch ou uma tag é uma operação de tempo constante, quase instantânea, onde a quantidade de dados no repositório não importa.

- Não há controle sobre cópia e movimentação de arquivos. A cópia de um arquivo é indistinguível de uma adição nova, não há nenhuma referência ao arquivo antigo e ao seu histórico. Renomear ou mover um arquivo implica basicamente em readicionar o arquivo com o novo nome/local e apagar o anterior, o que quebra o histórico em dois e deixa essa alteração nada óbvia. Outros sistemas resolvem esse problema de formas diferentes -- o SVN, por exemplo, mantém um controle interno, no repositório, de cópias de arquivos e trata renames como uma cópia do original para o novo seguida do apagamento do original (o histórico da cópia aponta para o original). O Git trabalha com base nos hashes dos arquivos e usa-os para detectar cópias e renames dura a leitura do histórico; tem até um nível de similaridade para aquivos que foram renomeados e alterados depois (caso clássico quando se faz refactoring de código).

- É impossível fazer o merge de qualquer coisa não trivial no CVS, e mesmo merges comuns disparam montes de conflitos desnecessários. Isso é triste. O repositório também não consegue guardar um registro de merge (vendo apenas pelos dados armazenados no repositório, não existe distinção alguma entre o resultado de um merge e uma revisão comum). Também não existe controle sobre merges múltiplos em um branch -- imagine que você criou um branch para implementar um recurso novo e precisa sincronizá-lo periodicamente com o branch principal: você terá que controlar manualmente, com tags, os intevalos de revisões que já foram mesclados. Junte isso com o problema que é criar tags montes de tags só para essa razão... Merges que envolvam arquivos renomeados (usando o truque acima) falham das formas mais bizarras possíveis.

O Git lida *muito* bem com merges (incluindo os com renames) e merges múltiplos são tratados naturalmente. cada commit no Git pode ter zero ou mais "pais", e ele usa isso para registrar cada merge feito e, na exibição, separar as mudanças geradas como resultado do merge daquelas inseridas manualmente (para resolver um conflito, por exemplo).
attachment.php
O Subversion ainda tem alguns problemas com merges (o registro de merges, por exemplo, só foi adicionado na versão 1.5 e é claramente um pensamento posterior), mas funciona relativamente bem. Mas merges com renames falham e exigem intervenção manual.

- Commits não são operações atômicas. Se você envia um commit que é interrompido por alguma razão (falha de rede, comum em repositórios remotos acessados sobre SSH) o repositório fica bloqueado até você rodar um comando administrativo (não lembro qual) para remover os locks. Não chega a ser um problema tão grave quando se trabalha em uma rede local onde essas falhas são raras, mas a fragilidade do repositório é desagradável. Todos os outros sistemas que eu conheço tem repositórios mais robustos que evitam esses problemas (Git, Subversion. Mercurial, Bazaar e Fossil, pelo menos).

- O CVS precisa falar com o servidor para qualquer operação, incluindo diffs, o que deixa as coisas *muito* lentas. O Subversion mantém alguns dados locais, diffs em relação à revisão pai não precisam de ajuda do servidor, etc. O Git é distribuído e sempre tem uma cópia local do repositório inteiro, o que evita todos esses problemas.

- Não existe compressão de arquivos binários. Sério. Cada alteração feita em um binário implica em guardar uma cópia completa dos dados no repositório, sem compressão delta. Git e SVN tratam todos os arquivos como binários e não tem esses problemas -- formatos de arquivo normalmente tornam o delta inútil, mas ao menos eles funcionam bem os os arquivos bem-comportados.



Como você tem experiência com o CVS, o Subversion é a opção mais próxima. Uma das metas dele é manter o workflow próximo ao do CVS para facilitar migrações, exceto onde isso é um problema.

A forma de trabalho do Git é um tanto diferente da do CVS, e para melhor. O fato dele ser distribuído abre possibildades que não existem para os sistemas centralizados (branches locais, por exemplo, são fantásticos para salvar trabalhos em andamento e coisas que ainda não estão prontas para enviar para o servidor). Ele aplicou muitas ideias que andavam em discussão quando foi projetado e recomendo fortemente estudar como ele funciona. Se quiseres, veja como ele guarda os dados no repositório: em termos de design, aquilo é de uma elegância enorme. Esse é o meu preferido ;)

Há o Mercurial e o Bazaar também, mas não tenho muita experiência com eles... basicamente só os uso para acompanhar alguns projetos. Um outro mais experimental é o Fossil, que mistura controle de versão, bugtracking, wiki e um servidor web no mesmo sistema. Não acho que ele é adequado para projetos maiores, mas tem coisas bem interessantes aparecendo nele.
 

Anexos

  • git-merge.png
    git-merge.png
    319,5 KB · Visualizações: 243
Bacana o controle e histórico de merges que vc mostrou. Parece que as ferramentas que você mencionou são bem mais completas.

Cara, o versionamento mais adequado pra minha situação eu sinceramente não sei se existe. Pelo que sei, tanto o Subversion quanto os outros trabalham com cópias locais de trabalho. E isso me ferra um monte.

Na verdade, o que eu precisava era de uma cópia de trabalho única onde vários usuários pudessem mexer. Claro, quando um desenvolvedor alocasse o arquivo para alteração ninguém mais pode mexer.

Não consigo trabalhar dessa maneira com o CVS e não sei se conseguiria com algum outro. Não quero ficar criando cópias locais. Quero um workspace único, entende o que eu quero dizer? Só um workspace e um repositório remoto, mas com suporte a múltiplos usuários (com registro dos autores de cada versão, etc).

Isso é possível com alguma ferramenta?
 
Que tópico excelente! Depois vou lê-lo com calma e inteiro.

Embora eu saiba muito pouco sobre o assunto e tenha pouca experiência na área, eu gosto muito de tudo quanto refira-se à programação, compilação e compiladores. Comecei a aprender Python e Awk, conheço bastante de Shell Script e tempos atrás comecei a aprender C. Sou usuário Linux e uso, como IDE o KDevelop e como compilador o GCC.

Um livro clássico para o aprendizado de C é o "The C Programming Language", dos criadores dessa linguagem de programação: Dennis M. Ritchie e Brian W. Kernighan.


[]'s!
 
Eu acredito que o dermeister falou muito bem.

Eu tenho tendência de fazer o máximo possível dos códigos manualmente.

Gosto que o código dos meus programas sejam o mais limpo e organizado possível, e algumas IDEs geram códigos que nem sempre seguem esse padrão de qualidade e organização.

Por conta disso eu prefiro editores de texto que somente fazem coloração de sintaxe.

Para quem está começando, eu recomendo o mínimo possível de ferramentas. Caso queira programar em C, um simples editor como Vi e um compilador GCC é mais do que suficiente na minha opinião.

Eu sempre incentivo o uso de Linux na programação, porque além de ser um sistema operacional robusto e gratuito, oferece ótimas ferramentas de programação e possuí código fonte aberto, que permite um complemento nos estudos através da sua leitura. Mas é perfeitamente possível aprender com o Windows. Somente questão de gosto.

Em relação a algoritmos, sempre estude. A maior dificuldade na criação de um programa não é na linguagem de programação, e sim na lógica.

Lord Leonan.
 
Aqui um site muito foda:http://projecteuler.net/

No começo eu achava que todos esses problemas poderiam sair usando matemática pura, consegui resolver alguns assim*, mas chegou uma hora que percebi que estava fazendo um trabalho desnecessário :dente:.

Por isso resolvi aprender a programar, mas ainda tô num nível bem básico.

* 1, 5 e 6. Deu até pra encontrar a quantidade de dígitos do número do problema 16 usando a característica do logaritmo decimal, mas ainda não pensei nenhum modo de calcular a soma dos dígitos. :mrgreen:
 
Última edição:

Valinor 2023

Total arrecadado
R$2.404,79
Termina em:
Back
Topo