Discussão sobre IDEs

FeIgansi
(usa Linux Mint)

Enviado em 21/04/2019 - 14:51h

Já que estou sem o que fazer gostaria de iniciar uma guerra, então se puderem me respondam qual é a melhor IDE/editor de texto, quais as que vocês mais gostam e usam no dia-a-dia?

hrcerq
(usa Outra)

Enviado em 21/04/2019 - 15:49h

IDEs são boas para melhorar sua produtividade, mas péssimas para o aprendizado. Para aprender, o melhor é usar diretamente o compilador/interpretador e um editor de texto.

Existem também alguns editores com recursos avançados que podem ser usados como IDE, e essa é minha abordagem favorita. Particularmente, gosto muito do editor Geany. Para programar em C, por exemplo, você pode criar e manipular seu próprio makefile, em vez de usar um gerado automaticamente pela IDE. Isso inclusive deixa seu projeto mais portável.

Por ser extensível, você inclui os plugins que precisa para seu caso específico (ou cria seus plugins, se não tiver um adequado). Existem extensões para controle de projetos, funções de autocompletar, uso de ctags, entre outros. Obviamente, isso é a minha escolha, não estou dizendo que se aplica a todo mundo. Você deve usar a ferramenta que te deixar mais produtivo, mas lembre-se que produtividade é sempre um passo depois do aprendizado.

Para C++, Python, Go, Lua, Shell e mais algumas outras linguagens, eu acho Geany igualmente adequado. Para Java nem tanto, mas... a vida é curta demais para se programar em Java (já que queria iniciar uma guerra...).

---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/

omag0
(usa Debian)

Enviado em 21/04/2019 - 17:28h

Devo discordar de você.
Se voltassemos a 10 anos atrás, essa sua afirmação seria verdadeira. Mas hoje?
Você tem inúmeras formas de aprender, sem precisar ficar sofrendo.

IDE e Editor vai do gosto do freguês. Eu trabalho com Java e Kotlin, nesse quesito a melhor disparada é o IntellIJ da jetbrains.
Também faço uma coisa ou outra com .NET Core, ai recorro ao Rider, também da Jetbrains (apesar de um pouco bugado, é a melhor opção que temos hoje, para programar em linux e mac as soluções microsoft).

Meu inicio e meio de carreira foi com PHP, ai não tem para onde correr, PHPStorm, também da jetbrains.

Eu quase não programo frontEnd, por não gostar. Mas quando preciso, uso o Visual Studio Code com plugins.

De forma geral, no meio coorporativo, As soluções da Jetbrains garanharam muito espaço. São excelentes e por um preço acessível. (pago 100 reais por mês por quase todas as ferramentes, há algumas que são pagas "por fora")

hrcerq
(usa Outra)

Enviado em 21/04/2019 - 17:41h

Não ficou claro nessa explicação. Por que 10 anos atrás faria sentido e hoje não? A propósito, o que seria "ficar sofrendo"? Ter que entender o que está acontecendo seria sofrimento? Pra mim, seria esclarecimento. Não vejo como uma ferramenta que esconde do programador o que verdadeiramente está acontecendo seria uma ajuda.

Se ele já sabe o que está fazendo é uma coisa, mas se ele está em processo de aprendizado, precisa ser obrigado a entender o que está fazendo, e a melhor maneira é não ter nenhuma camada de abstração além do compilador/interpretador (e olhe lá).



Conceito de melhor aí é muito subjetivo. Depende do que você avalia como diferencial em uma ferramenta. Pode ser facilidade, pode ser portabilidade do projeto, pode ser até mesmo consumo de recursos. Tem muita coisa que precisa ser avaliada, e não faz sentido dizer que algo é melhor ou pior se você não tem parâmetros de avaliação.

---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/

omag0
(usa Debian)

Enviado em 21/04/2019 - 18:23h

A - A 10 anos atrás era mais escasso e de pior qualidade o material que se encontrava de forma gratuita (ou mesmo pago) para programar. Sem contar que muitas coisa ainda precisa ser configurado manualmente (na epoca, javaEE ou Spring tinha muita config por xml.... )
Hoje mudou muita coisa na forma de aprendizagem. Você não precisa mais se focar tanto no "como acontece a compilação, como é feita o gerenciamento de recursos, etc) As linguagens esão cada vez mais alto nível. Preocupe-se com sua regra de négocio, e código bem feito vem com leitura e prática.

B - Não é subjetivade. Ja usei outras ferramentas.
As soluções da Jetbrains são "mais bem acabadas" com menos bugs. Possuem vários plugins feitos pela propria empresa, o que diminui consideralmente a quantidade de bugs e conflitos entre plugins.

As ferramentas da propria ide, como code completion, syntax highlight, code navigation, entre outras, são mais precisas que em outras ferramentas.
Entre outras coisas que poderia citar.

E tem outro ponto. Uma coisa é programar um dia outro. Uma hora ou outra do dia.
Outra é programar 8 horas por dia (com as devidas paradas, é claro), de segunda a sexta, ai você tem ideia do ganho de produtividade que essas ferramentas oferecem.

hrcerq
(usa Outra)

Enviado em 21/04/2019 - 19:12h

Você está restringindo a um ambiente de desenvolvimento específico. Não por acaso eu evito Java o máximo possível. Ele é tão burocrático e verboso, que você precisa de IDEs megalomaníacas pra ele não dar errado.



Certo, então tudo se resume a alto nível? Me diga um bom kernel escrito em Java, C#, Python... Peguei pesado com o kernel? Então, talvez um bootloader, quem sabe? Por que em programação de sistemas somos obrigados a usar linguagens de mais baixo nível? Simples, porque são mais eficientes. Quanto mais baixo nível, mais eficiente. Só não proponho fazer tudo em assembly porque não é portável, senão seria mais interessante que C.

Linguagens de alto nível são úteis para prototipar programas ou orquestrar tarefas. Para isso temos Python, Shell, Lua, AWK... Onde Java se encaixa?

Essa mentalidade de não se preocupar em entender é justamente o que tem deixado os programadores desleixados. Vemos programas cada vez mais inchados e propensos a bugs. E não por acaso eles são mais frequentes entre as linguagens que pregam a abstração das complexidades do programa.



Claro que é subjetivo. Foi você que usou, e comparou pelos seus parâmetros. Não necessariamente são os mesmos que os meus ou de qualquer outra pessoa. As virtudes que avalio em um programador são a curiosidade, a paciência e a disposição para aprender aquilo que é necessário. Nunca a pressa ou a fuga do "sofrimento", que neste caso seria o aprendizado.



Novamente, isto foi a sua experiência, e não necessariamente se aplica apenas às ferramentas que você testou. O fato de algo ser "bem acabado" não é atestado absoluto de qualidade (até porque eu não sei o que se pode considerar como "bem acabado"). Por exemplo, eu considero muito mais importante do que a ferramenta ser bem acabada (seja lá o que isso significa), que ela tenha boa documentação, seja altamente extensível, tenha seu código disponível para inspeção e melhorias, e que esteja nos repositórios oficiais da minha distribuição de uso. Ah, e obviamente, que não obrigue outros programadores a usar a mesma ferramenta que eu no mesmo projeto.



Aí está o ponto. Você falou as palavras mágicas: ganho de produtividade. Eu falei em aprendizado. São cenários diferentes. Eu comecei falando justamente que IDEs são boas para o ganho de produtividade. Mas para aprendizado elas são lastimáveis.

---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/

omag0
(usa Debian)

Enviado em 21/04/2019 - 19:53h

Dei um exemplo, mas a maioria das linguagens de mais alto nível, seguem esse mesmo caminho.



Concordo que linguagens de alto nível não se encaixam no seu exemplo - kernel, bootloader, etc (agora, tente fazer uma API com C, C++. Então cada linguagem, seu foco). Mas de maneira proporcional, o mercado absorve mais programadores de linguagens de alto nível. Sempre haverá espaço para ambos, mas a diferença é enorme. Então citei exemplo onde a pobabilidade de encontrar um emprego é maior (claro, isso se a pessoa que perguntou está interessada em programa como trabalho, e não como lazer).
E programador com desleixo ou de forma errada, nada tem haver com "começar com compiladores". Tem mais haver em conhecer a linguagem que está trabalhando e o paradigma que se escolhe trabalhar.




Bem acabado no sentido de, a funcionalidade de fato funcionar. Em algumas IDEs o code navigation hora funciona, hora não. Ja tive experiências ruins com Eclipse e C# pois, o plugin para C# travava "do nada" e era forçado a reinicar o programa. As vezes a funcionalidade/ ferramenta não é intuitiva (configurar um arquivo Mavem no eclipse, você tem que abrir umas 2, 3 abas).


E antes que eu pareça um Javeiro, não sou. Java tem muitosdefeitos que já estou de "s@co cheio", por isso migrei pra kotlin (mas ainda sim, roda na JVM, então no fundo, certas coisas nunca mudam). Por questão de gosto, prefiro e me aperfeiçoei em linguagens de alto nível (foquei em soluções web ERP).
---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/[/quote]

hrcerq
(usa Outra)

Enviado em 21/04/2019 - 20:45h

Se isso é verdade, então temos mais um sinal de que as linguagens de alto nível devem ser evitadas. Mas eu discordo, acho que isso não é verdade para todas as linguagens. Por exemplo, é muito prático trabalhar com virtualenv e conda, na linha de comando mesmo, para gerenciar projetos Python. Isso pode ser integrado a uma IDE também, claro, mas a flexibilidade de usar esse recurso de maneira prática na linha de comando é um exemplo.

Você não precisa configuar trocentos XMLs para isso. Quanto aos frameworks, sempre vai haver alguma coisa pra ser configurada, mas isso não significa que você deva fugir disso e deixar o trabalho a encargo da IDE, se estiver tentando aprender. Depois de aprendido, aí sim, recursos de produtividade serão bem-vindos. Mas cá entre nós, editar um arquivo não dói tanto assim, se comparado a fazer a mesma edição em uma interface gráfica.

A linguagem GO, também é um exemplo interessante, de foco na simplicidade. O objetivo é justamente evitar que se crie um monstro que faz com que você passe mais tempo se preocupando com os problemas do ambiente de desenvolvimento do que com o problema que ele resolveria, propriamente dito.



Concordo sobre cada linguagem ter seu foco. Essa ideia eu apoio totalmente. Ainda assim, isso não tem a ver com APIs. Veja por exemplo, algumas APIs interessantes em C:

https://avro.apache.org/docs/current/api/c/index.html
http://api.zeromq.org/
https://www.geany.org/manual/reference/

Não me parecem coisa de outro mundo. E estão muito bem documentadas. Não citei a do kernel Linux pois já seria um nicho diferente, como você muito bem pontuou.



Penso que a probabilidade de encontrar emprego é onde há mais problemas para serem resolvidos. Se há um motivo claro para certas linguagens ou padrões de desenvolvimento é a geração de emprego. Nesse ponto, realmente tenho que admitir, se não houver problemas para serem resolvidos, o mercado esfria. O problema é que boa parte dos problemas são artificiais, não necessariamente tinham que existir.



Se você trabalha com uma linguagem compilada, precisa sim entender como o compilador funciona. Precisa conhecer as flags que ele pode receber e como elas impactam no código gerado ou no seu fluxo de trabalho. Se uma IDE abstrai isso pra você, talvez seja mais fácil começar, mas você começa sem entender realmente o que está fazendo. Quando usar outra IDE, talvez tenha resultados inesperados por ela usar convenções diferentes da IDE anterior. Se usa uma linguagem interpretada, igualmente precisa entender como o interpretador funciona.



Que bom que você encontrou uma IDE que te ajuda a trabalhar. Mas isso é bem diferente de aprender. Aí estamos falando de produção, não de aprendizado. E continuo achando que isso tudo pode ser bom mas não está acima de uma boa documentação e código disponível. Mas aí já é visão pessoal.



Nada contra linguagens de alto nível. Elas tem seu papel. O que acho ruim é a pessoa escolher uma linguagem porque não quer aprender certas coisas e acha que a linguagem vai abstrair isso pra ela. O mesmo vale para a IDE. Ela pode te ajudar a ganhar produtividade, nunca a ganhar conhecimento. Nisso ela atrapalha.

---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/

danniel-lara
(usa Fedora)

Enviado em 22/04/2019 - 08:09h

eu sou simples , gosto de usar o VIM

cizordj
(usa Debian)

Enviado em 23/04/2019 - 09:00h

Eu sou mais simples ainda, uso o nano, só porque pinta o texto de outra cor.


<---------------------------------------------------------------->
O seu tempo é o único bem que você não recupera

Nerdiarretado
(usa Arch Linux)

Enviado em 23/04/2019 - 14:32h

Essas comparações de qual melhor IDE é um pouco fútil, uma vez que o melhor para mim, não é melhor para o outro, e isso é bem notável nos comentários, cada um com sua preferência. Já gostei bastante do Sublime Text porém pela quantidade de funções e plugins que o VS CODE oferece, fui para lá. Em minha opnião é uma IDE e tanto, e você pode programar em praticamente qualquer linguagem que exista. Digo isso pois estou em um projeto com um professor meu, e tive que instalar o eclipse (versão php), passei quase um mês tentando instalar o xdebug no meu sistema (fora os bugs do eclipse). Em uma simples pesquisa nos plugins, consegui encontrar o xdebug para VS CODE. Mas como disse esse tipo de pergunta é sempre falha. Meu sonho é um dia poder usar o vim, acho muito massa e aumenta seu potencial como programador.

hrcerq
(usa Outra)

Enviado em 23/04/2019 - 20:41h

Boa notícia para você: você está mais perto de realizar seu sonho do que imagina. O vim é muito bem documentado, e há um tutorial excelente dele, o vimtutor, que você executa no terminal e aprende a usar o vim dentro do próprio vim. Em poucas horas vai ficar craque.



Há uma correlação aí, mas não há causalidade. O fato de você usar o vim não é o que vai aumentar o seu potencial, e sim o seu perfil, que terá te levado ao vim. O perfil de quem usa o vim para programar é justamente o de quem não está a procura de uma IDE megalomaníaca, e apenas quer produzir o seu código, não virar um expert em uma IDE específica. Ele é bom para alternar rapidamente entre a edição do código e a sua compilação/execução.

O curioso é que o vim é muito subestimado, ele oferece recursos bastante avançados, e é altamente extensível. Suporta incontáveis tipos de arquivo, e tem comandos pra tudo que você imaginar. Um aspecto interessante do vim é que em vez de usar botões e atalhos pra executar determinadas rotinas, você já usa o próprio comando (com todos os parâmetros que ele tem direito). Ou seja, em vez de esperar o editor oferecer suporte a algum recurso que você precisa, você já vai direto na fonte, que é o comando que as IDEs abstraem.

Só que nem sempre isso é prático. Quando você precisa executar várias vezes um comando, especialmente se tiver que passar vários parâmetros, começa a ter que usar alguns artifícios, como alias e scripts. Aliás, por isso mesmo que existe o utilitário make.

---

Atenciosamente,
Hugo Cerqueira

Devuan - https://devuan.org/