É ótimo que Python, Lisp, etc, tenham todas essas funcionalidades que vocês apontaram. Conheço alguns de vocês e sei que têm respaldo para falar.

O comentário do Walter Cruz, sobre excesso de funcionalidades/características que não são usados, não se aplica da mesma forma para uma linguagem/tecnologia. Excesso de funcionalidade é ruim para um produto, e não para uma tecnologia. Programador sabe sempre usar todas as funcionalidades de uma lingaugem (não estou falando de decorar bibliotecas).

Mas os comentários estão focando em funcionalidades e eu estou falando de ecossistema e maturidade observável na indústria.

Eu posso agora criar um produto que tem todas as funcionalidades desejáveis, ser muito melhor que seus concorrentes etc. Infelizmente, a primeira pergunta que vou ouvir quando tentar vende-lo para uma empresa que se preocupa onde pisa é: Quem semelhante a mim já usa isso? É uma perversão terrível do mercado. E leva tempo e suor penetrar esse produto no mercado. No final, o maior valor que o produto/tecnologia pode ter é seu ecossistema, penetração, enfim, maturidade, e não suas funcionalidades.

Naquela análise que fiz, tentei ser independente e frio. Limitei-me a somente relatar o que observei no mercado. Não morro de amores por nada, nem Java. Meu papel é observar e tentar dar sugestões maduras e seguras aos meus clientes, de forma que seja um passo seguro adotar tecnologias abertas, como Java, como Python, como PHP, como Linux. Mas cada um no seu lugar.

O objetivo final é Computação Aberta. E não exatamente os tijolos que a constroem isoladamente.

A coisa já anda tão descambada que já ouvi um ‘consultor’ falar de ‘design pattern da Sun’. Pode uma coisa dessas?

Desconheço Lisp :( , mas os comentários do Bolko me deixaram com água na boca!

Voltando a vaca fria, tem uma frase de um historiador que diz algo como: ‘Os que desconhecem a história estão fadados a repeti-la’. Mas parece que mesmo conhecendo, o homem traça o seu destino de forma a repetir o passado…

No meu trabalho, temos uma porção de formulários web ‘descartáveis’ – Ele é feito, tem seu uso por um certo tempo, depois morre. Um sério candidato a soluções específicas como Django, Turbo Gears, ou até mesmo Rails. Mas a tendência é levar pro lado ‘corporativo’. Mas demos um tempo no Java – a curva seria muito grande e ainda é mais prático fazer em PHP.

O fato de Java ser ‘enterprise’ significa tão somente que ela tem 100% das características que você não precisará em 90% do tempo. E os 10% que você precisa, são absurdamente burocráticos.

Bom seria se os programadores pudessem tomar a decisão. Infelizmente, na maioria das vezes ou não podem ou não tem coragem.

eu acredito muito firmemente que concisão, do jeito que defini acima, leva a um nível de regularidade e legibilidade bem maior que “explícito é melhor que implícito”; é só olhar pra scheme.

(btw: dada a cultura que cerca python, me surpreende que até agora não tenham colocado tipagem estática na linguagem.)

ruby, ao invés de te dizer o que é certo, tenta ser prática e obediente, e consegue (muito bem, por sinal — sou obrigado a confessar que mesmo em lisp não consigo resolver as coisas de forma tão natural e gostosa quanto em ruby).

as grandes vantagens que python tem sobre ruby são documentação decente e suporte a Unicode.

Resumidamente eu acho que Ruby é tão poderosa quanto Python mas tem uma sintaxe que me desagrada.

que usa java realmente nao conhece python… se conhecesse nao falaria isso ou melhor, nao seria mais programador em java e sim em python

=)

1. lisp > ruby > python

python + & = ruby, ruby + & = lisp, & pequeno (e diminuindo)

python > java

python = java + &, & beeeeem grande

3. * 1/3 dos problemas que as pessoas resolvem com Java seriam muito melhor resolvidos em C

* outro 1/3 em {python,ruby,lisp}

* e o restante quer ser Erlang e não sabe

4. O problema de Java não é que a implementação é lenta e a máquina virtual come memória (vsize de `java -version` = 209796KiB). O problema de Java é que a linguagem é horrível. Mesmo que houvesse uma máquina virtual maravilhosa, Java continuaria sendo horrível.

5. Quem diz que Java é bom porque é orientado a objetos não conhece smalltalk ou ruby.

A idéia que os programadores Java tem de orientação a objetos é “coleta lixo e deixa eu encapsular funções com dados”.

6. O prof. Dijkstra escreveu que “PL/I pertence mais ao conjunto de problemas que ao conjunto de soluções”. Java não só pertence mais ao conjunto de problemas, como *cria problemas onde eles não existiam*. A única razão boa para usar Java é se você é pago por linha de código, por número de classes ou por function points. Se Java tivesse sido inventada enquanto Dijkstra era vivo, ele teria desistido de ciência da computação e declarado o campo morto.

7. Tudo que é justificado por ser “profissional” é um lixo. Java inclusive.

8. A fórmula perfeita para criar linguagens de programação está descrita na primeira frase do artigo do Scheme:

> Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.

Se houvesse justiça os caras que criaram Java teria isso tatuado a fogo na testa ao contrário, pra ler todo dia de manhã quando fossem ao banheiro.

9. Você já criou em seu editor de textos macros ou abreviações para certos idiomas comuns? Você já implementou design patterns? Em Lisp você nunca faria isso. Em Lisp o compilador faria isso.

10. Uma linguagem de programação que tenta proteger o programador de seus próprios erros vira burocracia. Burocracia não é apenas tediosa, ela acaba com o KISS e destrói estabilidade, manutenibilidade e poder de expressão. A linguagem de programação ideal é a **mais concisa possível**. Concisão **não** significa usar poucos caracteres (aka Perl), significa usar poucos *conceitos*, poucos *comandos*. A ferramenta definitiva para aumentar concisão é permitir ao programador poder total para alterar a sintaxe da linguagem. Para programar a sintaxe, você precisa que os próprios programas sejam objetos de primeira ordem, facilmente manipuláveis.

Lisp é a única linguagem em que você pode programar a sintaxe. cada programa Lisp é escrito em uma linguagem especial para resolver *aquele* problema.

Lisp *sempre* vai ser a única linguagem em que você pode programar a sintaxe, porque se você acrescentar essa funcionalidade a outra linguagem, você terá em suas mãos Lisp com açúcar sintático. Assim como Unix, Lisp não é uma implementação, é um ideal. Lisp não é uma linguagem; uma linguagem é Lisp.

Os programadores de Haskell acham que Lisp é bom porque é funcional, e Haskell é mais funcional do que Lisp, portanto Haskell é melhor. Mas a vantagem de Lisp não é ser funcional, é ser uma linguagem de programação programável. O estilo funcional é o mais favorecido por Lisp porque francamente ele é o melhor para a maioria dos casos (muito melhor que OO, diga-se de passagem), mas Lisp não existe para você programar funcional, existe para você programar *como quiser*. É trivial implementar imperativo (comandos OpenGL) ou OO (CLOS) ou lógica (não-determinismo) em Lisp. Não no compilador de Lisp, veja bem, *em Lisp*.

De forma geral, vejo o processo de iniciacao no Python sempre da mesma forma (inclusive comigo): rejeicao, suspeita, experimentacao, aceitacao e jubilo ;)