 |
gildot |
 |
| |
| | Hoje no IRC: Finding Python's Holy Grail | | |  | Contribuído por jmce em 20-11-01 18:35
do departamento just-in-time | |  | |  | | |  Esperando ainda apanhar alguns dos leitores a tempo: hoje das 19:00 às 20:00 (UTC e em Portugal) David Ascher, um dos autores do Learning Python, irá falar sobre os últimos desenvolvimentos da linguagem Python e responder a questões sobre a mesma, numa sessão de IRC, em irc.activestate.com (6667), canal #chat. Para poder participar é necessário estar registado na ASPN...
Actualização: Está já acessível uma transcrição da conversa. | | | | | | < Lockheed Martin, Pentágono e Linux | Quanto estariam os leitores do Gildot dispostos a pagar > | | gildot Login | | | Referências | | |
| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | 2 l8te! :-( Alguem assistiu? Ha' algum log do chat? Eu conheco o David e sei que o gajo pesca daquilo. BTW, ha' alguem a usar Python em .pt?
|
| | | | | por Anonimo Cobarde em 21-11-01 1:43 GMT (#2)
|
| Bem .. eu uso python porque estou a ser obrigado a isso, para fazer trabalhos em A.I. o que eu tenho a dizer ... não gosto!! O sistema da documentação do API confuso .. acho que é terrivelmente lento, detesto a aquela cena da identação (em vez das chavetas) para delimitar blocos de funções e etc .. não aconselho
|
| | | | Velocidade: para linguagem interpretada despacha-se bem.
Docstrings: É fixe para coisas como software auto-documentado mas para gerar documentação concordo contigo, é algo menos que prático: não permite documentar convenientemente variáveis nem eliminar da documentação funções que não são suposto ser utilizadas.
Indentação: Adoro. Obriga os programadores a escrever código legivel. Para mim, a indentação é um hábito, logo, é só uma questão de não escrever as chavetas que fecham.
De resto, eu ADORO Python! É simples, flexivel e bem estruturado.
Uma coisa muito bem feita é a organização dos módulos, que podem ser organizados hierarquicamente.
O modelo de objectos, em que tudo é um objecto (incluido os módulos, as classes, as funções...) e em que os atributos (membros para quem não usa Python) são determinados dinamicamente permite umas brincadeiras fixes.
Do lado menos bom, todo este dinamismo implica a quase ausência de static checking, o que pode dificultar o debuging.
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | python é uma linguagem muito bem conseguida e elegante. porquê? porque enquanto é pouco verbosa (= nao precisas de escrever muito para realizar uma ideia) mantem a claridade (é facil de perceber o que foi escrito).
mas gostos nao se discutem, e se nao gostas de python, é pena que sejas obrigado a trabalhar nisso, mas infelizmente essa situacao acontece frequentemente: a maior parte das pessoas acaba por ter de programar/ou trabalhar de um modo geral, em coisas que nao gosta.
no que diz respeito ao desenvolvimento/programacao, et al, a forma de combater este homogeneidade é usar compatibilidade multi plataforma. Aqui plataforma aplica-se ao nivel das linguagens / sistemas que se usam (software), e nao ao nivel de hardware. essa compatibilidade é facil do ponto de vista tecnico, mas quase impossivel na pratica, porque obriga a chegar a standards, usos comuns, o que tem sido provado ser impossivel ao longo dos anos. por exemplo, o parrot de que se falava no chat, é suposto ser uma virtual machine generica. a ideia é qualquer scr1pting language produzir bytecode que é corrido por essa VM. esta ideia, implementada numa vertente mais abrangente, faria com que qualquer linguagem pudesse interagir com codigo escrito noutras linguagens, alem de se ter um sistema completamente independente do hardware usado (o que ja acontece nas linguages que têm um interpretador/virtual machine ,whatever por tras).
curioso, é ver que acabamos por cair em problemas ciclicos e solucoes ciclicas, mas cujos niveis a que surgem, vao variando com o tempo: o problema em unificar VMs, ter bytecodes comuns, etc... de agora, sao equivalentes a ter assemblers e machine opcodes diferentes no passado. se todos os fabricantes de CPUs tivessem convencionado um assembler comum (até podiam ter opcodes e formatos internos diferentes), muitos dos problemas de compatibilidade nunca teriam existido (bom: *alguns* problemas de compatibilidade nao teriam surgido-- provavelmente iria continuar a haver a saga dos formatos binarios acima do hw-level diferntes, etc...)
-- carlos |
| | | | Não é assim tão simples construir uma Máquina Virtual genérica e depois compilar diferentes linguagens em byte-code para essa VM. Existem demasiadas diferenças, diferentes mecanismos que teriam de ser sopurtados. E provavelmente a próxima linguagem a ser concebida não ia caber na VM.
E o problema não se limita à VM mas também ao resto da plataforma. Não basta teres o interpretador de Python mas também toda a colecção de módulos que vão ser necessários (e nem existe um standard quanto a isso).
Uma das caracteristicas de Java é que não é apenas uma linguagem mas também uma plataforma. Python é apenas uma linguagem.
Quanto à questão do assembler comum: depois de compreenderes uma máquina ao ponto de conseguires fazer algo em assembly dela, aprender a sintaxe do assembler é um pormenor. Além do mais, como o próprio código é absolutamente não portável, que mal faz que os assemblers usem sintaxes diferentes?
Remember to be the Killer, not the Victim! (Nuklear Girl) |
| | | | | "BTW, ha' alguem a usar Python em .pt?" Há!... :^)
Assim de repente (cat `find ...` | wc) conto 162 mil linhas de python meu que sobrevivem aqui nesta máquina.
|
| | | | | BTW, ha' alguem a usar Python em .pt? Claro. www.oninet.pt está (quase) todo feito em Python/Zope. Cumprimentos Mario Valente
|
| |
|
