É ó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.

É ó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.

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.

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.