Qual o desktop?

O Linux dispõe de desktops bastante avançados como o gnome, kde e xfce, que o colocam no páreo com os sistemas comerciais. Entretanto, para o usuário mais avançado, os desenvolvedores, estes ambientes deixam um pouco a desejar.
Por que isso acontece? Primeiramente, o desenvolvedor de software muitas vezes executa comandos não-repetitivos, com variações, que se fazem necessárias para exercitar os programas em desenvolvimento, ou testá-los de forma diferente visando descobrir falhas no funcionamento (bugs).

Poderíamos criar menus gráficos para muitas dessas tarefas, de forma a torná-las mais agradáveis visualmente, mas imaginem um simples ./configure, que pode ter opções como --enable-shared, --with-debug=2, --with-x e tantas outras opções, na realidade muitos milhares, se levarmos em conta a multitude de programas que se utilizam dessa ferramenta (autoconf). E não existe somente uma forma de compilação possível. Desde os simples Makefiles que precisam ser editados manualmente para se adaptar a cada instalação em particular, até os Imakefiles que usam a ferramenta Imake originada com o sistema de janelas X.
O que significa isso? Significa que um desenvolvedor não pode se dar ao luxo de não abrir um terminal, seja ele um xterm, Eterm, rxvt, ou qualquer outro, de preferência um que tenha boa visibilidade (sem tantos backgrounds ou transparência para não prejudicar a visualização). Ora, se precisamos abrir um xterm para praticamente tudo que faremos, para que desejamos menus gráficos elegantes e bem dispostos que (quase) nunca iremos usar?

Ambientes de desenvolvimento integrados

A mesma síndrome de guificação dos ambientes de desenvolvimento nos foi herdada da saudosa Borland (que está sendo comprada pela Corel), mas felizmente não teve o mesmo sucesso no Linux. Isso é notório porque os ambientes de desenvolvimento integrados como o xwpe, KDevelop CodeForge, gIDE e tantos outros, praticamente não são encontrados em programas reais escritos pela comunidade. Desafio qualquer um a testar qualquer destas ferramentas e comparar a produtividade a um programa (não-trivial) escrito "à mão" com um sistema decente de makefiles. A explicação é simples: nenhum desses ambientes realmente evita o programador de conhecer o que está fazendo, somente elimina algumas linhas digitadas e em troca produz um código realmente criptográfico para ser remendado em seguida. Assim sendo, é melhor comecar a escrever o código diretamente de forma limpa e organizada e não modificar a saida de um destes programas, inifinitamente mais "burros" que a mais limitada das inteligências humanas.
Afinal há alguma utilidade nesses gui-builders? Acredito que eles fiquem limitados a aplicações "de brinquedo", didáticas, ou como um primeiro degrau para os noviços que estão se introduzindo à programação em algumas das linguagens do mundo real (principalmente C).

Ferramentas do programador

Que ferramentas devo aprender para aumentar minha produtividade? Ah! Chegamos ao ponto. Se você realmente quer ficar produtivo, inicie aprendendo C, make, e se possível, yacc e lex.
Ora, yacc e lex? Mas eu não pretendo escrever um compilador? Por incrível que pareça, a maioria dos programas que escrevemos analisam alguma entrada (numa determinada organização) e produzem uma saida (numa outra organização), ou sejam, funcionam como um filtro. E isto é uma forma de compilação, mesmo que primitiva em alguns casos. Protocolos de comunicação, edição de textos, conversões, afinal quase tudo tem algo comum aos compiladores.

Se você pretende escrever aplicações para a console (ou o xterm e derivativos), é bom se preparar bem com (n)curses, uma biblioteca especializada para isso. Caso escolha escrever guis, minha preferência pessoal é usar uma linguagem de scripting como o tcl/tk, mas acho admirável também o python. Infelizmente perl não pode obter minha recomendação, apesar de achá-la maravilhosa como substituto dos shells do unix.

Conclusões

Finalmente, um bom desenvolvedor, não só no ambiente unix/linux, mas de maneira geral, deve ser poliglota. Além de linguagems de programação tradicionais como C/C++, pascal/módula/oberon, etc, ele deve estar familiarizado com as várias linguagens de scripting existentes, e em especial com os shells (bash, csh, tcsh), pois ele irá deparar-se inúmeras vezes com aplicações já escritas nessas linguagens. Ademais, ele deverá se sentir confortável com ferramentas como sed, awk (outra linguagem para scripts), ferramentas para controle de versão como o PRCS, RCS ou o CVS (entre muitas outras), e dominar um bom editor de textos. Apesar de ser fã do vim, não quero provocar (novamente) a famosa discussão vi/emacs aqui. Qualquer editor decente é suficiente.

Se você pretende ser algo mais que um simples usuário "clicador de ícones", prepare seu ambiente de trabalho, de preferência o mais leve possível, e concentre-se nas ferramentas.