Lançado o primeiro beta do Python 2.4

E para as pessoas que ficarem curiosas sobre a linguagem e quiserem mais informações sobre ela podem dar uma olhada no PythonBrasil (http://www.pythonbrasil.com.br) e participar da nossa comunidade (as instruções para participar da lista de discussão estão na página).

O que seria uma linguagem de programação interativa? todas as linguagens não são interativas?

Interativa no sentido de Programação Interativa. Você tem um shell pra isso. Mas você pode editar seus arquivos .py no seu editor favorito e interpretar 'de uma vez', ou compilar pra bytecode.
http://en.wikibooks.org/wiki/Programming:Python_Interactive_mode
http://www.pythonbrasil.com.br

Tenho uma certa gratidão ao python pois já tinha no Kurumin e eu precisava apenas de sockets. Estava desenvolvendo em Java algo que estava começando a parecer monstruoso. Gostaria de sugerir também o "Dive into Python", que dá boas dicas de como desenvolver, e ainda se rí um bocado com os exemplos do livro...

Mais alguns links para os curiosos (em português):

http://www.async.com.br/projects/python/pnp/
http://lula.dmat.furg.br/~python/aspectos.html
http://pensarpython.incubadora.fapesp.br/portal
http://www.dmat.furg.br/~python/diferente.html

Para quem quiser ler o livro que o colega eje del mal recomendou, basta fazer o download dele no site:

http://diveintopython.org/

O livro está sob a GPL :)

Não é pra começar nenhum flame não... mas é engraçado como um das coisas que faz parte do changelog é o aumento de velocidade de algumas funções, ao recodificá-las em C.

Pergunta séria : Seria muito difícil desenvolver um front-end gcc para o python? Dessa forma, teria o ganho de velocidade de desenvolvimento (usando como linguagem de script e durante o protótipo) e performance, ao compilar o código.

Nenhuma iniciativa nessa área? Tudo que eu conheço é o Jython e o IronPython, mas esses geram o código pra máquinas virtuais... bye bye performance.

Bem, detesto comentar em formato plano. Com dizia o meu amigo Jack, vamos por partes.

1 - Parece que virou um mural de propaganda de sites. Quem me conhece sabe que sou fã de carteirinha do Ruby, mas como me considero um cara relativamente inteligente, participo do txt2tags do Aurélio que é em Python. Para quem não conhece, é só passar em http://txt2tags.sourceforge.net/pt/. Tem até uns gringos usando o t2t para escrever um livro.

2 - Para o Rafael: É claro que C, quando bem utilizado é sinônimo de velocidade, portabilidade e código pequeno. Mas o aspecto velocidade possui diversos ângulos. Deve-se considerar a velocidade aceitável. Se está bom para o usuário, eu quero o máximo de facilidades para o meu desenvolvimento, independente de ficar um pouco mais lento.

Provavelmente é possível desenvolver um front-end para o gcc (afinal, tem até para o Java e parece que estão fazendo um para 'D'). A geração de código para VM pode significar um ganho de performance já que geralmente existe uma compilação JIT. Não cheguei a ver a execução do IronPython, mas acredito que seja boa. Uma solução Quick'n'dirty seria o Psyco. Tem um outro projeto que gera código para a VM do VisualWorks (Smalltalk) com ganho de performance em diversos itens.

Bem, fico por aqui para não escrever muito.

Sem fugir muito do assunto, essa linguagem D parece que vai ser a linguagem do futuro.

Ruby também me parece muito interessante. Mais uma para aprender...

Raphael,

O IronPython é relativamente veloz (pensei que fosse bem pior...), mas o projeto ainda é muito imaturo, com diversos problemas de compatibidade. Só consegui rodar com o Mono 1.0. Vamos ver se ele 'vinga'.

O Jython é muito mais lento. Ele parece ser mesmo um quebra-galho, para ter uma linguagem RAD naquela plataforma.

Falando objetivamente, é (muito) melhor usar o (C)Python.

Indo por partes, também:

1) D ia ser a linguagem do futuro no século passado. Se você gosta de C e acha que D vai ser um espetáculo, use C++. É factível e será mais fácil de você aprender, visto o alcance que este possui.

2) Traduzir código de uma linguagem para C não é sinônimo de desempenho. Já tentou compilar código em Perl para C, por exemplo?

Se você for fazer uma tradução exata do seu programa, o desempenho não vai mudar, pois a semântica vai ser idêntica. Logo, o número de instruções também. E se não for uma tradução exata e sim com otimizações, pode ser feito diretamente no compilador da linguagem, sem ter que passar nada para código em C.

3) Não vejo grande vantagem nas linguagens que possuem um compilador iterativo senão ensinar programação. Conheço várias linguagens que possuem esse recurso e devo ter usado ele no máximo umas duas vezes, para ver como funcionava.

Alguém algum dia pode fazer um compilador iterativo pra C, também. O problema é que não vai ter usabilidade prática, pois é difícil se reduzir um programa em C a expressões bem delimitadas (já que a linguagem não é funcional). Python é melhor nisso - mas não tanto.

4) Front-end para o GCC é sinônimo de portabilidade e várias arquiteturas-alvo, não necessariamente de desempenho. Desenvolver um compilador próprio provavelmente seria uma alternativa que traria velocidade, tanto no programa quanto na compilação.

E é isso.

Indo por partes, também:

1) D ia ser a linguagem do futuro no século passado. Se você gosta de C e acha que D vai ser um espetáculo, use C++. É factível e será mais fácil de você aprender, visto o alcance que este possui.

2) Traduzir código de uma linguagem para C não é sinônimo de desempenho. Já tentou compilar código em Perl para C, por exemplo?

Se você for fazer uma tradução exata do seu programa, o desempenho não vai mudar, pois a semântica vai ser idêntica. Logo, o número de instruções também. E se não for uma tradução exata e sim com otimizações, pode ser feito diretamente no compilador da linguagem, sem ter que passar nada para código em C.

3) Não vejo grande vantagem nas linguagens que possuem um compilador iterativo senão ensinar programação. Conheço várias linguagens que possuem esse recurso e devo ter usado ele no máximo umas duas vezes, para ver como funcionava.

Alguém algum dia pode fazer um compilador iterativo pra C, também. O problema é que não vai ter usabilidade prática, pois é difícil se reduzir um programa em C a expressões bem delimitadas (já que a linguagem não é funcional). Python é melhor nisso - mas não tanto.

4) Front-end para o GCC é sinônimo de portabilidade e várias arquiteturas-alvo, não necessariamente de desempenho. Desenvolver um compilador próprio provavelmente seria uma alternativa que traria velocidade, tanto no programa quanto na compilação.

E é isso.

Indo por partes, também:

1) D ia ser a linguagem do futuro no século passado. Se você gosta de C e acha que D vai ser um espetáculo, use C++. É factível e será mais fácil de você aprender, visto o alcance que este possui.

2) Traduzir código de uma linguagem para C não é sinônimo de desempenho. Já tentou compilar código em Perl para C, por exemplo?

Se você for fazer uma tradução exata do seu programa, o desempenho não vai mudar, pois a semântica vai ser idêntica. Logo, o número de instruções também. E se não for uma tradução exata e sim com otimizações, pode ser feito diretamente no compilador da linguagem, sem ter que passar nada para código em C.

3) Não vejo grande vantagem nas linguagens que possuem um compilador iterativo senão ensinar programação. Conheço várias linguagens que possuem esse recurso e devo ter usado ele no máximo umas duas vezes, para ver como funcionava.

Alguém algum dia pode fazer um compilador iterativo pra C, também. O problema é que não vai ter usabilidade prática, pois é difícil se reduzir um programa em C a expressões bem delimitadas (já que a linguagem não é funcional). Python é melhor nisso - mas não tanto.

4) Front-end para o GCC é sinônimo de portabilidade e várias arquiteturas-alvo, não necessariamente de desempenho. Desenvolver um compilador próprio provavelmente seria uma alternativa que traria velocidade, tanto no programa quanto na compilação.

E é isso.

Indo por partes, também:

1) D ia ser a linguagem do futuro no século passado. Se você gosta de C e acha que D vai ser um espetáculo, use C++. É factível e será mais fácil de você aprender, visto o alcance que este possui.

2) Traduzir código de uma linguagem para C não é sinônimo de desempenho. Já tentou compilar código em Perl para C, por exemplo?

Se você for fazer uma tradução exata do seu programa, o desempenho não vai mudar, pois a semântica vai ser idêntica. Logo, o número de instruções também. E se não for uma tradução exata e sim com otimizações, pode ser feito diretamente no compilador da linguagem, sem ter que passar nada para código em C.

3) Não vejo grande vantagem nas linguagens que possuem um compilador iterativo senão ensinar programação. Conheço várias linguagens que possuem esse recurso e devo ter usado ele no máximo umas duas vezes, para ver como funcionava.

Alguém algum dia pode fazer um compilador iterativo pra C, também. O problema é que não vai ter usabilidade prática, pois é difícil se reduzir um programa em C a expressões bem delimitadas (já que a linguagem não é funcional). Python é melhor nisso - mas não tanto.

4) Front-end para o GCC é sinônimo de portabilidade e várias arquiteturas-alvo, não necessariamente de desempenho. Desenvolver um compilador próprio (em Python) provavelmente seria uma alternativa que traria velocidade, tanto no programa quanto na compilação.

E é isso.

ofranja,

Eu acho que você deveria repetir sua mensagem, caso alguém ainda não tenha entendido.

O dia que você se desentender com o MovableType também, espero estar por perto para sugerir a mesma coisa. :^)

Bem 'ofranja', eu nunca briguei com o MT. Quando acontece alguma coisa estranha, eu salvo o texto, vou dar uma volta e depois vejo se ele está lá. Se não estiver eu envio novamente (mas geralmente está :-)

1. Sobre D, gostaria apenas de citar duas características incorporadas na linguagem: TestUnits e DbC. Qual será a do futuro pouco me interessa. Estarei morto até lá. Por enquanto, utilizo as ferramentas que me agrado.

2. Apenas converter um código de uma linguagem para outra não é sinônimo de velocidade. É claro que se for um laço faraônico fará diferença. Caso contrário não é possível afirmar nada.

3. Quando algém fala em linguagem 'interativa', as únicas que passam pela minha cabeça são Lisp e Smalltalk. Basta ver esse pequeno tutorial para descobrir um pouco mais sobre as linguagens do 'passado'
http://cadafalso.deusexmachina.com.br/flash/editandcontinue.html

Algumas correções:

s/Qual será a do futuro pouco me interessa/Qual será a linguagem do futuro pouco me interessa/

No item 2 apenas concordo com 'ofranja'

Vamos lá... post antes de pegar no sono.

1 - D vai ser a linguagem do futuro é uma afirmação tanto quanto vaga. É o mesmo que dizer que ó Brasil é o país do futuro. Tem potencial, mas não faz parte dos interesses daqueles que podem fazer grandes mudanças.

2 - Perl é compilado? Realmente desconheço um compilador Perl. Só tenho conhecimento do Parrot, e mesmo assim, me parece que a idéia é mais uma máquina virtual. E não concordo muito em dizer que a tradução de um código manteria as mesmas instruções. Uma linguagem interpretada, pela sua própria natureza, tem mais "trabalho" a fazer do que um linguagem compilada. Pense: um programa feito em qq linguagem interpretada (perl, python, scripts shell...) tem que fazer a análise sintática, semântica e léxica de cada instrução, verificar o tipo de variáveis, verificar limites de acesso... tudo isso em runtime. Uma linguagem compilada já tem grande parte desse trabalho feito, e a execução é bem mais "enxuta".

3 - Concordo com o Guaracy em tudo em que ele escreveu, realmente acredito que a linguagem tem que servir ao desenvolvedor, e não o contrário. E entre um sistema de grande performance e um de performance "good enough"... é claro que o que for mais fácil para o desenvolvedor que deve ser escolhido.

4 - Pro ofranja: eu sonhava com um interpretador de C em alguns trabalhos de faculdade. Tive alguns programas ou sistemas que tinham que fazer e que davam pau num trecho da função... Eu queria ter um sistema que: a)salvasse o estado do programa antes de entrar no código que eu estava b) deixasse eu fazer alterações c) seguisse a partir daquele ponto. d) voltasse pro estado que estava salvo. Ficar compilando e rodando o programa até chegar no ponto de falha era um saco, e custava grande parte do meu tempo.

Hoje parte desses problemas podem ser resolvidos com algum *Unit da vida, mas eu costumava fazer um programa que exercia só aquela função, e colocava algumas entradas "hardcoded" pra testar aquilo. Mesmo assim, o ciclo edit-compile-debug era chato, muito chato.

5 - Realmente, o GCC está longe de ser um primor em performance, justamente para garantir a portabilidade e flexibilidade de linguagens. Por essas, quem trabalha com computação de alto desempenho ainda não é muito amigo do GCC. Mesmo assim, o código gerado por ele deve ser *bem* menor e mais rápido do que o de qualquer interpretador.

6 - É claro que tudo isso é só um exercício mental, e bem inútil. A idéia de fazer um compilador gcc para o python é tão prática quanto a de um interpretador para o C. Pode ser bonito e interessante, mas para manter compatibilidade com bibliotecas, versões legadas, interoperabilidade... virtualmente impossível.

Raphael:

2) Perl - e estou falando aqui da versão 5 - possui um compilador para código nativo. É distribuído por padrão (pelo menos no Slackware) e pode ser chamado no console com o comando 'perlcc'. Entretanto, é experimental - e sempre vai ser -, além de gerar código com desempenho semelhante ao código interpretado (vantagem nenhuma, basicamente). E o tamanho do runtime vai às alturas...

Quanto às análises em tempo de execução: no caso do Perl 5, lembro de ter lido em algum lugar que ele gera uma representação do arquivo em memória, e que funcionava de maneira similar a um bytecode. Mas não tenho certeza disso.

5 e 6) Exatamente. Por isso um compilador self-hosting (escrito em Python) seria uma opção mais viável, também.

E é isso.

"Sem fugir muito do assunto, essa linguagem D parece que vai ser a linguagem do futuro."

na minha opnião, python vai ser a linguagem do futuro, mas com a vantagemque já é presente.