Python, Zope and Plone Experiments

18 de junho agora é #dornelesday

2011-06-18T21:37:00.007-03:00

Hoje é um dia muito especial, pois hoje é dia de homenagear uma grande pessoa: Dorneles Treméa. Pois ele, com seus gestos simples, paciência, perseverança e generosidade, se tornou um exemplo para muitas pessoas, no mundo todo, dentro da comunidade de Software Livre e mais especificamente na comunidade Python e Plone.

Apesar de ter nos deixado tão jovem, o tempo é relativo, por isso, tenho certeza que ele deixou uma marca profunda na vida de todos que conviveram com ele. Seja pela paz e alegria que ele transmitia, sempre de bom humor nas mais difíceis situações, seja pela disposição eu ajudar quem lhe pedia auxílio, seja pela dedicação que tinha pela sua família.

Por isso, para mim e para muitas pessoas, o dia 18 de junho é a partir de hoje #dornelesday, que representa um dia para refletir sobre tudo de bom que nosso colega e amigo trouxe para nós com seu exemplo de vida. Que todo dia possamos nos inspirar com esse exemplo e possamos aprender, um pouco que seja, com este legado.

Na verdade não é fácil seguir seu exemplo, não é fácil ajudar as pessoas como ele ajudava, não é fácil estar sempre de bom humor como ele sempre estava. Mas é por isso que é tão importante essa homenagem, não somente para valorizar o que ele nos trouxe, mas principalmente para conseguir passar esse exemplo adiante, para outras pessoas e assim tornar o mundo em que vivemos um lugar melhor para todos nós.

Viva o Deo (@dorneles)! Viva o #dorndeleday! Que sua luz continue brilhando forte de onde quer que você esteja, como sempre brilhou por aqui! Agradeço imensamente a oportunidade que tive de conviver contigo.

RelStorage: ZODB usando backend relacional (SGDBs)

2009-08-27T09:50:00.075-03:00

Introdução

O ZODB (banco de dados orientado à objetos para aplicalções Python), originalmente criado como um componente do servidor de Aplicação Zope2 (Z Object Publishing Environment), foi desenvolvido com o conceito de "Storage Layer", o qual abstrai o tipo de backend responsável pela persistência dos objetos.

Historicamente, o primeiro Storage Layer desenvolvido para o ZODB foi FileStorage, que tem como objetivo ser simples e robusto, e por isso armazena todos os objetos e transações um único arquivo de forma sequencial. Para acessar os objetos através do seu caminho na hieraquia de objetos do ZODB (ex: obj2 = root['obj1']['obj2'] ), o FileStorage cria um arquivo auxiliar de índice e que deve estar completamente na memória para que o desempenho seja adequado.

Compartilhando o ZODB

Mais tarde, devido a necessidade de compartilhar um mesmo banco de dados por diversas instâncias de uma aplicação (ou diversas aplicações), foi desenvolvido o ZEO (Zope Enterprise Objetcts), que é composto por um servidor RPC que fornece acesso via rede a um ou mais bancos de dados ZODB em FileStorage.

Segue abaixo um de acesso ao ZODB com ZEO e ClientStorage retirado do ZODB Guide:

from ZEO import ClientStorage
from ZODB import DB
import transaction

# modificar essa linha de acordo com a configuração do servidor ZEO
addr = 'zeoserver.example.com', 1975
storage = ClientStorage.ClientStorage(addr)
db = DB(storage)
conn = db.open()
root = conn.root()

# vamos armazenar uma lista e um dicionário no objeto raiz
root['lista'] = ['a', 'b', 1.0, 3]
root['dicionario'] = {'a':1, 'b':4}

# o ZODB é um banco ACID e transacional, é preciso fazer o commit
# no caso do ZOPE, esse commit é automático caso exista uma exceção não tratada
transaction.commit()

Dessa forma, cada instância da aplicação cliente acessa o ZEO usando o Storage Layer ClientStorage para se concectar ao banco de dados compartilhado pelo servidor ZEO. Para o tratamento de concorrência, o ZEO / ZODB utiliza um mecanismo "otimista" de controle de conflitos entre transações que acessam os mesmo objetos, se um conflito ocorrer, uma exceção do tipo "ConflictError" é levantada para avisar o problema a aplicação cliente.

O conjunto de ZEO + FileStorage e aplicação cliente (Zope por exemplo) + ClientStorage permite que os mesmos arquivos de dados ZODB no formato FileStorage sejam acessados simultanemente para criação de Clusters, muito usados para aumentar o desempenho de sites de alto tráfego que usam Zope/Plone, por exemplo.

Essa combinação, apesar de ser a única alternativa para "compartilhar" o ZODB por várias instâncias de uma aplicação, possui algumas limitações de escalabilidade e redundância:

O ZEO é uma aplicação Python e devido ao GIL (Global Lock Interpreter) ele somente consegue ser escalonado em uma CPU por vez e, por isso, não aproveita melhor os sistemas com vários processadores/núcleos. Essa limitação prejudica a escalabilidade do backend e pode ser percebida quando muitas instâncias da aplicação precisam acessar ou gravar dados ao mesmo tempo.

A Zope Corp possui um componente proprietário, o Zope Replication Services, que é vendido separadamente para replicação de bases de dados ZODB + FileStorage, possibilitando replicar em tempo real o servidor ZEO, conseguindo então uma solução de alta disponibilidade, porém o custo é alto e proibitivo para a maioria das organizações e situações de uso do ZODB.

Quanto mais objetos no ZODB, maior o arquivo de índice do FileStorage e, em alguns casos de grandes bases de dados, a inicialização pode ser bem demorada, principalmente se for necessário recriar esse índice.

Surge o RelStorage

Foi com objetivo de atacar essas deficiências e seguindo a idéia do BerkeleyStorage, que foi desenvolvido RelStorage (inicialmente chamado de PGStorage) o qual suporta o aramazenamento dos objetos opacos do ZODB (no formato de byte-code python), em bases de dados relacionais.

Isso significa que esses objetos não podem ser consultados diretamente através do banco de dados relacional (ex: realizando consultas para reltórios), mas apenas pelo ZODB (aplicações Python), o qual ao ser configurado com RelStorage, sabe como recuperar e gravar os objetos, de forma transparente, que estão persistidos em um backend relacional e que substitui o ZEO + FileStorage na tarefa de compartilhar o ZODB por diversas instâncias da mesma aplicação ou diversas aplicações.

Atualmente existem "adapters" no RelStorage para armazenar bases de dados ZODB em três diferentes backends relacionais: MySQL, PostgreSQL e Oracle. Novas servidores de banco de dados podem ser integrados atrvés da implementação de um novo adapter.

Segue um exemplo simples para configuração de um banco de dados ZODB com RelStorage e usando o PostgreSQLAdapter, lembrando que é preciso primeiro criar o banco de dados no PostgreSQL e o RelStorage inicializa as tabelas no primeiro acesso:


import transaction
from ZODB.DB import DB

from relstorage.relstorage import RelStorage
from relstorage.adapters.postgresql import PostgreSQLAdapter

# alterar a configuração de acordo com o banco de dados no PostgreSQL
dsn = "dbname='ruda' user='ruda' host='localhost' password='12345'"

adapter = PostgreSQLAdapter(dsn)
storage = RelStorage(adapter)
db = DB(storage)
conn = db.open()
root = conn.root()

# vamos armazenar uma lista e um dicionário no objeto raiz
root['lista'] = ['a', 'b', 1.0, 3]
root['dicionario'] = {'a':1, 'b':4}

transaction.commit()

Desempenho e Alta Disponibilidade

Os testes realizados por Shane Hataway (criados do RelStorage) indicam que o RelStorage possui um desempenho superiror ao ZEO tanto na leitura quanto na gravação, e que esse ganho aumenta quanto maior concorrência de acesso ao ZODB. É importante notar que é possível fazer um tunning no ZEO que melhora seu desempenho, porém o problema de escalabilidade decorrente do GIL, tente a tornar o ZEO mais lento em ambientes de alta concorrêcia, como por exemplo sites Zope/Plone que possuem muitas instâncias Zope.

Além disso, devido ao uso de bases de dados relacionais, as bases de dados ZODB armazenadas com RelStorage podem ser replicadas usando as ferramentas disponíveis em cada SGDB. Por esse motivo, o RelStorage passa a ser uma alternativa interessante para criação de ambientes de alta disponibilidade que usam o ZODB, novamente, grandes portais Zope/Plone são um público em potecial.

Estabilidade, Migração e Integração

O RelStorage pode ser considerado estável e já está sendo usado em produção por diversos sites, incluindo um grande portal Zope/Plone que usa RelStorage com Oracle e foi um dos patrocinadores da implementação desse novo Storage para ZODB.

Além disso, RelStorage possui uma excelente cobertura de testes e inclui em sua distribuição uma ferramenta (zodbconvert.py) para migração de bases de dado do formato FileStorage para RelStorage (MySQLAtapter, PostgresSQLAdapter e OracleAdapter) e vice-versa.

As opções do arquivo de configuração para migração usando zodbconvert.py são semlhantes as opções usadas na configuração de cada adapter do RelStorage (cada um possui opções distintas). No caso do PostgreSQL a configuração (migration.conf) seria:


<filestorage>
 path /tmp/Data.fs
</filestorage>

<relstorage>
 <postgresql>
   dsn dbname='ruda' user='ruda' host='localhost' password='12345'
 </postgresql>
</relstorage>

Para realizar a migração, em um ambiente Zope/Plone configurado via Buildout, basta executar os seguintes comandos no shell, assumindo a versão 1.2.0b2 do RelStorage:

$ cd meu_diretorio_buildout
$ ./bin/zopepy ./eggs/RelStorage-1.2.0b2-py2.4.egg/relstorage/zodbconvert.py /tmp/migration.conf

Finalmente, já existe suporte no pacote plone.recipe.zope2instance para que o RelStorage seja configurado com Buildout para automatização do deploy de aplicações Zope/Plone. Porém, para uso com Plone 2.5 (Zope 2.9) e Plone 3.x (Zope 2.10), é necessário incluir o repositório com versões modificadas do ZODB 3.7 e 3.8 para suportar o RelStorage. Já no Plone 4.x (Zope 2.12) que virá com o ZODB 3.9, não será preciso usar a versão com patch pois o mesmo já foi aplicado no repositório oficial da nova versão do ZODB.

Conclusão

Com RelStorage podemos criar ambientes que necessitam de maior desempenho e disponibildiade do ZODB, substituindo o ZEO e consequentemente algumas de suas limitações. Grandes portais desenvolvidos em Plone podem aproveitar esses recursos, principalmente em ambientes nos quais são usados clusters Zope e que tem o requisito de maior alto desempenho e redundância.

Embora ainda não exista informações divulgadas sobre sites que usam o RelStorage, incluindo detalhes sobre ganhos de desempenho e escalabilddade que demostrem claramente as vantagens da sua adoção, dependendo do ambiente a possibilidade de replicação on-line já seria um motivo suficiente para justificar a migração para o RelStorage.

Python Brasil [5]! Sigam /pythonbrasil no Twitter

2009-08-16T22:54:00.004-03:00

Essa é rapidinha, mas tem mais de 140 caracteres! :-)

Para melhor divulgar as informações a respeito da Conferência Python Brasil [5], tanto sobre os preparativos, bem como as dicas, avisos e acontecimentos durante o evento, foi criada a conta @pythonbrasil no Twitter específica para isso!

Então.. sigam @pythonbrasil e nos vemos em Caxias do Sul!

Como explodir seu buildout com Plone 2.5 e Five 1.4?

2009-04-12T22:55:00.006-03:00

Já faz algum tempo que a melhor forma de realizar deploy de projetos Plone passou a ser a utilização da ferramenta zc.buildout, também chamada apenas de buildout. É realmente incrível como ela facilita a tarefa de criar ambientes tanto para produção como desenvolvimento de forma simples, rápida e fácil, mesmo nos mais complexos cenários.

Tudo isso graças a sua arquitetura, a qual permite a utilização de diferentes receitas (recipes), desde que elas sejam publicadas como um pacote Python no PyPi, e assim podem ser reutilizadas por qualquer um que necessite da mesma funcionalidade. Na verdade, o buildout pode (e deve) ser usado por quaisquer projetos, não se limitando apenas ao Zope e seus compatriotas como o Plone e Grok, e já vem sendo usado em projetos Django também.

Porém, existem vantagens e desvantagens de se utilizar o buildout para o deploy de projetos de software. Na minha opinião, as vantagens são muito maiores que as desvantagens. A principal vantagem é a capacidade de se criar ambientes de forma controlada, facéis de serem reproduzidos e estáveis (a depender da configuração usada). E a principal desvantagem é a dependência da ferramenta (buildout) sem ter conhecimento de como o deploy do ambiente funciona a ponto de poder identificar e reparar as falhas e problemas que ocorrem quando algum conflito, atualização de pacote ou incompatibilidade interferem no seu funcionamento.

De fato, existem armadilhas que podem ocorrer e acredito que muitos usuários do buildout já devem ter odiado ele quando as coisas começam a dar errado e não se sabe por que. Ontem mesmo que recebi um email de um amigo, relatando um problema com o buildout, e por incrível coincidência, ele já havia ocorrido comigo, por isso, eu já tinha a solução.

Foi então que percebi que era hora de compartilhar o problema e a solução a fim de ajudar qualquer um que venha a se deparar com essa situação no futuro. O cenário é o seguinte: instalação do Plone 2.5 (e Zope 2.9) com buildout, porém utilizando o Five 1.4 ao invés do Five 1.3 que vem originalmente com o Zope 2.9.

A armadilha é a seguinte: quando modificamos a versão do Five, não estamos fazendo nada de errado, pois a versão 1.4 foi feita para ser compatível com o Zope 2.9. Esse é também um pré requisito para diversos pacotes adicionais do Plone que necessitam de funcionlidades da ZCA e do Framework Zope 3 que não são suportados pela versão 1.3 do Five.

Porém, a receita de instalação do Zope para o Plone 2.5 (plone.recipe.zope2instance), não está preparada para essa situação e o sintoma do problema apenas aparece na tentativa de iniciar ou reiniciar a instância, gerando uma falha na localização de algumas diretivas ZCML, como por exemplo:

ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/genericsetup', u'registerProfile')

De fato, quando um erro como esse ocorre, fica difícil identificar qual é a real causa. Nesse momento é que odiamos o buildout com todas as forças. Mas não se desespere, existe luz no fim do tunel! Ao investigar a situação a fundo descobri uma forma simples, fácil e indolor de evitar quaisquer surpresas em ambientes Plone 2.5 com Five 1.4, apenas adicionando as seguintes linhas ao seu arquivo buildout.cfg:


[commands]
 recipe = plone.recipe.command
command = 
 cp ${productdistros:location}/Five/skel/site.zcml ${instance:location}/etc

Não se esqueça também de incluir a seção "commands" depois de "instance" na seção principal do buildout.cfg.
Essa configuração assume que você esteja instalando o Five 1.4 em [productdistros] usando seu link para download e instalação automática.

Como pode ser observado pelo trecho acima, estamos usando a receita plone.recipe.command que nos permite executar qualquer tipo de comando shell para copiar a versão correta (que vem com o Five 1.4) do arquivo site.zcml para o diretório etc da instância Zope. A depender da configuração das suas instâncias, pode ser necessário ajustar o comando, assim como, se você já possui uma versão especial de configuração do arquivo site.zcml, o comando também deve ficar diferente.

Espero que essa dica ajude outras pessoas a conhecer o buildout e a resolver e evitar esse tipo de problemas em ambientes com o Plone 2.5 e Five 1.4, e de quebra, serva como um exemplo de utilização da receita plone.recipe.command.

Social Network Research and Plone

2008-01-30T11:30:00.000-03:00

I will have the next 6 months to develop a framework to help fast delivery of Social Network Services - SNS, it's the implementation task of my final work graduate research and has the title: Social Network Services: component based framework. And, because I have been using Plone in some projects to deliver Content Management Applications, like: company and community web sites, intranets, etc, in the last three years (ruda_porto IRC nick), I decide to use it as a base system to construct a SNS application framework.

Of course that is not a simple task, since Social Networks Services Applications can be used for friendship, academic, professional or some kind of specialized networks, but the central point will be study the hole application domain (problem scope) and implement a framework (solution scope) to abstract social network core objects and features in a way it will be easy to extend and integrate with Plone content management core products and other third-part products for things like members, tagging, blog, wiki, audio, video, photos, files and so on.

The main focus and effort will be in walk forward to make Plone a social oriented application out-of-box installing a core set of packages, thus offering the creation of social networks that share information and content among social actors with Plone. And perhaps implementing a framework that fits academic and Plone community needs at same time is a risk and a great opportunity at same time, using small components help to isolate the general problem in a set of core packages will be a foundation to create Plone social network sites and applications.

The next step forward in my research is the creation of two questions list, one for end users of SNS sites and other Plone developers and users. The first must help to discover what users like and dislike in some existent SNS sites and so grasp functional requirements. The second is more difficult, but it intent is try to discover functional and non-functional requirements that can made the framework easy to extend and deliver SNS applications when integrated with Plone.

I'm was waiting an opportunity make all that information public available in the Plone community and after the post from Alexander Limi: 18 Things I Wish Were True About Plone, talking about social network path for Plone, I decide to make it and try to explain the scope of my research and my vision about Plone social integration and begin a discussion of how it (and other existent projects) can improve Plone social experience.

Thanks for all folks that spend time contributing to Plone and who are responsible to made this amazing community! I will appreciate all commenting! :-)

Manipulando arquivos grandes em Python

2007-10-07T19:35:00.000-03:00

Marcelo Toledo escreveu um artigo comparando a sua implmentação em C de um corretor ortográfico poposto por Peter Norgiv com a versão original em Python.

Porém Marcelo Toledo ao realizar essa comparação não levou em consideração que o exemplo desenvolvido por Peter Norvig era apensa um protótipo. Sendo assim, ele resolveu comparar ambos os programas, em C e Python, utilizando arquivos cada vez maiores e ilustrando a diferença de performance entre eles.

No código de Peter Norvig ele lê o arquivo de uma vez. Dá para imaginar o que acontenceu, baixa performance e "crash" com arquivos maiores de 100M devido a falta de RAM. :-(
Essa é a linha na qual o programa de Peter Norvig lê o arquivo e processa ele:

NWORDS = train(words(file('big.txt').read()))

Infelizmente Marcelo Toledo não procurou saber qual era o "bug" do código, deixando no ar uma idéia de que C é robusto é Python é uma linguagem não confiável.

Como eu fui questionado por um colega (Robson Peixoto) sobre o "porque" do problema com o código do corretor ortográfico. Resolvi então escrever um pequeno script que copia arquivos binários da forma correta. E assim fica claro que Python não tem problemas em manipular arquivos maiores que 100MB. ;-)

Segue um teste de uso do script copyfile.py

ruda@zion /tmp $ du -sh livecd-i686-installer-2007.0.iso
416M    livecd-i686-installer-2007.0.iso

ruda@zion /tmp $ time ./copyfile.py livecd-i686-installer-2007.0.iso teste.iso

real    0m39.708s
user    0m4.517s
sys     0m3.747s

Ou seja, sem usar muita CPU e nem mesmo RAM, esse script demorou 40
segundos para copiar um arquivo de 416MB, ou seja, 10MB/s aproximadamente.

Abaixo o código do script copyfile.py

#!/bin/env python
# -*- coding: utf-8 -*-
import sys

try:
   origem = sys.argv[1]
   destino = sys.argv[2]
except IndexError:
   print "Modo de usar: copyfile.py origem destino"
   sys.exit(1)

#Exemplo de leitura e gravação de arquivos grandes - usando modo binário
input = file(origem, 'rb')
output = file(destino, "wb")
for line in input:
   output.write(line)

#Fechando os arquivos
input.close()
output.close()

Grupo de Usuários Python - Bahia

2007-09-15T15:59:00.000-03:00

Atenção,

Eu convido todos os baianos de sangue ou de coração (como eu) e que
adoram Python a participar da criação do Grupo de Usuários Python -
Bahia.

Essa iniciativa faz parte de um conjunto de ações importantes que a
Associação Python Brasil vem coordenando para a divulgação de Python
em todo o território nacional. E visa criar e fortalecer comunidades
as regionais.

Eu tomei a iniciativa de criar uma lista de discussão para o Grupo de
Usuários Python - Bahia e convido todos os interessados a ingressar
através do endereço:

http://groups.google.com/group/grupy-ba

A idéia é se organizar para um primeiro encontro no começo de outubro.
Porém também estamos tentando inserir algo sobre Python na programação
do II ENSL que vai ser em Aracaju, e se tivermos vários membros da
comunidade presentes, já seria um ótimo momento para isso. ;-)

PyConBrasil [3] - catalizando a comunidade Python

2007-09-03T17:25:00.000-03:00

A comunidade de usuários Python no Brasil tem muitos motivos para comemorar. Pois além da excelente qualidade da PyConBrasil [3], tivemos consolidação da Associação Python Brasil, criada a três mêses atrás.

Algumas pessoas envolvidas com Software Livre já brincavam comigo quando eu falava sobre a comunidade Python, com comentários do tipo: "A comunidade Python no Brasil tem apenas um punhado e desenvolvedores". Parece que agora as piadas vão ter que mudar pois esse tipo de comentário vai sair de moda. ;-)

O que ficou claro durante o evento é como Python tem crescido dentro do mundo acadêmico científico e deve crescer cada vez mais, pois a simplicidade, legibilidade e flexibilidade de Python quando somada a sua ampla bilioteca e a fácil integração com C e C++ são uma combinação perfeita para esses domínios de aplicação e um público em que o foco não é programar, mas sim desenvolver ferramentas e soluções para problemas da pesquisa científica.

Apesar de eu ter perdido a palestra de Flávio Coelho - Python na Ciência, por estar ministrando um treinamento de Zope3 durante a manhã de sábado, fiquei sabendo de toda a repercursão e logo que os vídeos do evento estejam disponíveis vou dar uma conferida. Porém JS conseguiu um exemplar do livro Computação Científica com Python e eu aproveitei e li os capítulos iniciais que fazem uma introdução a Python e gostei muito do que vi e recomento.

Flávio realizou um post em seu blog sobre o evento e suas impressões da comunidade, comentando sobre a qualidade do evento e o nível das apresentaões em geral e mais especificamente na área científica. Além de observar em relação a receptividade de todos os principais membros da comunidade, o que eu vejo como uma grande virtude que cada um de nós precisa exercitar.

Eu sempre comento com as pessoas sobre o primeiro contato que tive com a comunidade Python durante o FISL 5.0, no espaço reservado para o encontro das comunidades. Foi ncrível a receptividade de todos,e não foi difícil logo se sentir em casa ao lado de pessoas que eu havia conhecido há algumas horas.

Esse catalizador humano é fundamental para o fortalecimento da comunidade, usando os eventos de Software Livre em geral e de forma mais específica a PyConBrasil, para aglutinar as pessoas interessadas em trocar suas experiências com o uso da linguagem Python e em trabalhar conjuntamente para a divulgação e promoção da linguagem Python no Brasil e com a associação isso deve melhorar ainda mais.

Eu agradeço a todos os que já trabalharam de alguma forma em prol desses objetivos, especialmente para aqueles que tem trabalhado muito durantes anos (não vou citar nomes :-)), e espero continuar participando e colaborando de alguma forma, ajudando os novos membros a se sentirem em casa.

Sejam bem vindos e viva a Associação Python Brasil e não deixem de comparecer PyConBrasil [4] !!

ps: Algumas fotos da confraternização da comunidade.

Threads e Eventos para calcular se um número é primo

2007-05-20T20:43:00.000-03:00

Segue um pequeno programa que fiz para experimentar o uso Threads e Eventos do módulo threading de Python. A minha idéia foi definir um evento que pode estar ativo ou não e que controla o início e o término do processamento de cada Thread.

Ao dividir o trabalho de calcular se um número é primo em várias linhas de controle (Threads), teoricamente seria possível melhorar o tempo de processamento. Porém como essa aplicação é CPU bound , e como um processo do interpretador Python não permite que suas Threads executem de forma simultânea, cada qual em uma CPU ou núcleo físico, na prática esse exemplo acaba não sendo muito útil para esse caso, a não ser como prova de conceito.

Se a aplicação trabalhasse com o uso de entrada e saída, ou seja, IO bound, então já seria mais interessante, pois enquanto uma Thread poderia estar bloqueada fazendo a leitura ou gravação em um disco, enviando ou recebendo dados via rede ou esperando o resultado de uma consulta no banco de dados, as outras Threads poderiam estar executando, ocupando mais a CPU e consequentemente diminuindo o tempo total de execução do programa.

Segue link para acesso ao código, já que não consegui manter a formatação usando o editor do blogspot ou mesmo carregando o fonte do HTML gerado pelo Scite. :-(

Python, Scheme e ML - Uma análise comparativa das linguagens de programação

2007-04-30T16:13:00.000-03:00

Durante o FLISOL Salvador 2007 , evento em que participei apresentando uma palestra sobre Python, decidi que era hora de começar a escrever. Já fazia mais de um mês que eu havia decidido começar a escrever um blog sobre minhas experiências usando a linguagem Python, o servidor de aplicação Zope e CMS Plone. O nome já estava registrado: python-blog.blogspot.com, e o que mais estava faltando? Iniciativa. ;-)

Na primeira postagem estou publicando um artigo que escrevi juntamente com dois colegas na disciplina de Engenharia e Software I (2006.2). Escrevê-lo me ajudou enxergar o quão poderosas são as linguagens funcionais e o quanto Python herda desse paradigma. Além disso cheguei a conclusão que as linguagens funcionais deveriam ser mais ensinadas nos cursos de Ciência da Computação, talvez até com primeira linguagem! :-o

Python, Scheme e ML

Uma análise comparativa das linguagens de programação.

Faculdade Ruy Barbosa

Rudá Porto Filgueiras, Sergio Pacheco, Adrienne Nogueira

Disciplina de Engenharia de Software I – 2006.2

Curso de Bacharelado em Ciência da Computação – Faculdade Ruy Barbosa(FRB)

Rua Theodomiro Batista, 422 – Rio Vermelho – Cep: 41.940-320 – Salvador – BA

rudazz@gmail.com, sergiorpacheco@gmail.com, adrieness_eu@yahoo.com.br

1. Resumo

As linguagens de programação tem uma importância fundamental na nossa capacidade de expressar idéias e resolver problemas. A análise de diferentes linguagens possibilita o avaliação das escolhas realizadas em tempo de projeto, utilizando os critérios e conceitos da Engenharia de Software para entender as escolhas dos projetistas e o resultado desas escolhas em cada linguagem.

Palavras-chave: Linguagem de Programação, ML, Lisp, Scheme, Python, Projeto de Linguagem

2. Introdução

Esse artigo se propõe a comparar as características de três diferentes linguagens de programação. Scheme e ML são linguagens fundamentadas no paradigma funcional, de amplo uso, possuem diversas implementações e são muito utilizadas na área de matemática, lógica e inteligência artificial. A terceira e última linguagem é Python, que se diferencia por ser de propósito geral, multiparadigma e influenciada pelas lições de design de importantes linguagens, tais como: Ada, Scheme, SmalTalk, Módula 3.

Para realizar esse comparativo, selecionamos algumas características a serem estudadas e comparadas entre as linguagens. Isso nos permitirá avaliar as escolhas realizadas em tempo de projeto e seus benefícios e/ou contra-partidas utilizando os critérios da Engenharia de Software como parâmetro. As características abordadas são: simplicidade global, intruções de controle, suporte para abstração, manipulação de exceções e verificação de tipos.

3. Simplicidade global

“A simplicidade global de uma linguagem afeta diretamente a sua legibilidade”, Sebesta (2005). As linguagens do paradigma funcional se fundamentam na simplicidade do conceito matemático de função, elementos e conjuntos. Em especial Scheme, que no seu projeto tem por objetivo ser minimalista, mantendo número de instruções básicas e palavras reservadas restritas ao mínimo necessário e ao mesmo tempo compatível com LISP.

Python se apoia nas idéias do projeto de Scheme para se manter simples e ao ser comparada com outras linguagens imperativas, em geral, possui menos instruções básicas e palavras reservadas, o que contribui para o seu fácil aprendizado. Assim como Scheme, Python procura implementar apenas um modo correto de se executar uma determinada operação, isso fortalece a simplicidade e consequentemente a legibilidade da linguagem.

ML não possui um grau de simplicidade global tão alto quanto Scheme, pois permite a programação imperativa e a declaração de tipos, embora não obrigue essa definição. Scheme não possui tipos de dados e apoia-se na conceito de átomos (elementos) e listas (conjuntos) para abstrair suas estruturas de dados. Todas estas linguagens são de alto nível, com alta capacidade de abstração o que torna essa simplicidade poderosa e expressiva.

4. Instruções de controle

As instruções de controle são utilizadas para construir desvios e organizar o fluxo da execução dos programas. Nas linguangens imperativas, existem estruturas de controle para realizar a repetição e a seleção de determinados trechos de código a serem executados.

Python possui um conjunto reduzido de estruturas de controle, de forma a reduzir a complexidade da linguagem. Além disso a forma de expressar um loop for para percorer elementos de uma lista ou dicionário ou qualquer objeto que implemente alguns métodos especiais é simples e poderosa. Como ML, Python possui o recurso de compreensão de listas.

Scheme e ML possuem instruções de seleção simples as repetições são implementadas através da recursividade. Em Scheme a pilha de recursão não aumenta de acordo com a sua execução, o que garante que o espaço utilizado será constante, tornando a recursão mais segura e eficiente.

ML também possui recursos do paradigma imperativo, e por isso, possui instruções de controle semelhantes a linguagem C++, como if, else, case. Além disso seu mecanismo de seleção baseados em encontro de padrões pode ser utlizado para selecionar parte da função que será executada a depender do valor recebido como parâmetro.

Exemplos:

Python – compreensão de listas:

lista = [1, 2, 3 ,4 ,5 ,6 ,7 ,8 ,9, 10]

lista = [x for x in lista if x % 2 = 0]

[2, ,4 ,6, 8 , 10]

Scheme – condicional e repetição com recursão

(DEFINE (factorial n)

(IF (= n 0)

(* n (fatorial (- n 1)))))

ML – encontro de padrões:

datatype shape =

point

| circle of real

| box of (real * real)

fun area (point) = 0.0

| area (circle r) = pi * sqr (r)

| area (box(w,h)) = w * h

5. Suporte para abstração

“A abstração é a capacidade de modelar um problema de maneira a se concentrar nos aspectos importantes para esse sistema ou trecho expecífico de código, omitindo detalhes e facilitando a manipulaçãos das entidades ao separar as definições do que um programa faz, dos detalhes sobre como ele é implementado.”, Watt, David A. (1989).

O suporte para abstração em uma linguagem está relacionado a capacidade de definição de novos tipos de dados abstratos, denominada abstração de dados. Além disso, também está relacionada com a possibilidade de se abstrair um processo utilizando funções e procedimentos no paradigma funcional e imperativo.

O paradigma orientado a objetos funde esses dois conceitos ao permitir a definição de classes, com suas propriedades e métodos. E isso possui um impacto importante na capacidade de escrita e na confiabilidade, facilitando o reuso de código e a legibilidade.

As linguagens ML, Scheme e Python tratam as funções como tipos de dados de primeira ordem, o que as permite passar uma função como parâmetro de outras funções, armazenar funções como atributos ou elementos de uma estrutura de dados ou lista e também retorná-las como resultado de uma expressão, o que permite a criação de abstrações mais poderosas.

Um exemplo dessa capacidade é o uso da função interna map que mapeia os elementos de um conjunto aos elementos de um novo conjunto utilizando uma função que é passada como parâmetro e que será aplicada a cada elemento do conjunto inicial para gerar o novo conjunto.

Exemplos:

map(sqrt [1, 2, 3, 4])

Scheme

(MAP SQRT '(1 2 3 4))

Python

map(math.sqrt, [1,2,3,4])

Em todos os exemplos acima o resultado será uma nova lista contendo a raiz quadrada dos elementos da lista passada como parâmentro.

6. Verificação de Tipos

Tradicionalmente na Engenharia de Software o sistema de verificação de tipos de uma linguagem de programação é classificado em dois grupos principais: estaticamente (fortemente) tipadas ou dinâmicamente (fracamente) tipadas. A capacidade de verificação de tipos de uma linguagem afeta diretamente a sua confiabilidade.

Porém algumas linguagens, como Python, não se enquadram nesse modelo, pois são dinâmicamente tipadas e ao mesmo tempo fortemente tipadas. Surgindo então uma diferenciação da definição tradicional onde podemos definir as linguagens como estáticamente ou dinâmicamente tipadas e fortemente ou fracamente tipadas.

As linguagens estaticamente tipadas são aquelas no qual toda a variável, função e parâmentros tem um tipo bem definido, declarado pelo programador, e ela realiza a verficação de tipos em tempo de compilação.

Já nas linguagens dinamicamente tipadas, somente os valores tem tipos de dados definidos (tipos latentes), ou seja, uma variável ou parâmetro não tem um tipo definido e pode conter valores de diferentes tipos em diferentes momentos. Isso implica que a verificação de tipos deve ser realizada em tempo de execução.

ML é uma linguagem estaticamente tipada e que possui um sistema de inferência de tipos robusto, tornando opcional a declaração de tipos. Scheme e Python são dinamicamente tipadas e também possuem a inferência dos tipos. Porém em todas elas o sistema de verficação de tipos não realiza a conversão implícita de um tipo de dados para outro, leventando uma exceção quando tipos inconsistentes são utilizados.

Python realiza uma nova vinculação de nome e espaço a cada attribuição de valor a uma variável, inferindo o tipo de dados do valor recebido. Além disso ela não possui definição de tipos nos parâmetros de funções ou métodos, deixando a cargo no programador o tratamento dos tipos recebidos e retornados.

Exemplos:

Scheme

(+ 10 “16”)

;The object “16”, passed as the second argument to integer-add, is not the correct type.

Python

10 + “16”

TypeError: unsupported operand type(s) for +: 'int' and 'str'

10 + “16”;

! Type clash: expression of type string cannot have type int

Podemos observar que não há a sobrecarga do operador “+” para concaternar uma string com um inteiro e a exceção levantada é resultado do sistema de verificação de tipos.

7. Manipulação de exceções

Durante o desenvolvimento de um programa, diferentes tipos de erros precisam ser previstos e tratados para que se alcance um grau de confiabiliade adequado a cada necessidade, evitanto que o programa seja finalizado de forma inesperada.

Porém, se a linguagem utilizada não suportar nativamente o recurso de manipulação de execeções, quanto mais verificações forem necessárias, mais complexo o código vai ficar, e isso terá um impacto direto na legibilidade e no custo de implementação e manutenção.

ML, Scheme e Pyhon tem o suporte nativo ao tratamento de exceções, incluindo a definição de novos tipos de execeção. Scheme tem o suporte a exceções integrado ao seu interpretador de comandos, permitindo que o programador decida o que fazer quando uma exceção não tratada é levantada. As exceções em ML sempre são de tipo e podem ter um valor e um efeito associado.

Em Python as exceções definidas pelo usuário utilizam o conceito de herança da orientação a objetos. Exception é a classe base na qual todas as outras exceções são derivadas. E como existe a unificação entre classes e tipos, e subclasses são subtipos, ao tratar uma exceção de um determinada classe todas as subclasses dessa exceção também serão tratadas.

8. Conclusão

Ao analisar as linguagens e comparar suas características percebemos que as escolhas em realizadas em tempo de projeto determinam as características das linguagens e os domínios para os quais elas serão mais indicadas.

ML e Scheme por serem fundamentadas no paradigma funcional, possuem uma excelente capacidade de escrita para o domínio da matemático, lógico e para sistemas simbólicos. Python foi desenvolvida para ser uma linguagem de propósito geral e consegue alcançar esse objetivo ao englobar o paradigma funcional, orientado a objetos e imperativo.

ML possui um alto grau de confiabilidade por ser estaticamente tipada e possuir um mecanismo de exceções nativo e um excelente suporte para abstração. Além disso ML permite o uso de estrturas das linguagens imperativas, aumentando a capacidade de escrita para domínios mistos que utilizem modelos formais e lógicas de negócios.

Python possui um grau de flexibilidade muito alto e isso tem impacto na sua confiabilidade, mas que é contrabalanceado com um modelo de objetos elegante, tratamento de exceções nativo e orientado a objetos e alta capacidade de abstração e recursos da programação funcional. A sua capacidade de escrita é alta para domínio de negócios e domínios mistos.

Segue abaixo um quadro resumo das características das linguagens:

Scheme

Python

Simplicidade Global

paradigma imperativo

padronização

biblioteca padrão extensa e inconsistente entre versões

Minimalista

padronização

tipos de dados latentes

Minimalista

paradigma imperativo

unificação entre tipos e classes

Instruções de controle

estruturas semelhante as linguagens imperativas

encontro de padrões

Compreensão de listas

Recursividade para repetição

Recursividade eficiente

Estruturas de seleção simples e múltipla

Possui um conjunto reduzido de estruturas de controle: for, while, if e with.

Recursividade limitada

Compreensão de listas

Suporte a abstração

tratam as funções como tipos de dados de primeira ordem

programação funcional

estruturas e registros

tratam as funções como tipos de dados de primeira ordem

programação funcional

listas dinâmicas

Tudo é objeto e tipo de dado de primeira ordem

orientação a objetos elegante e consistente

Herança múltipla

Verificações de Tipos

Estaticamente tipada

inferência dos tipos

não realiza a conversão implícita de tipos

permite a declaração do tipo de uma variável

Dinâmicamente tipada

inferência dos tipos

não realiza a conversão implícita de tipos

tipos de dados latentes

Dinâmicamente tipada

inferência dos tipos

não realiza a conversão implícita de tipos

tipos de dados latentes

Manipulação de Exceções

suporte nativo ao tratamento de exceções.

Exceções podem conter valores e eventos associados

suporte nativo ao tratamento de exceções.

suporte implícito integrado ao interpretador de comandos.

9. Bibliografia

SEBESTA, Robert W. , Concepts of Programming Languages 7 ed.

WATT, David A. , Programming Language Concepts and Paradigms 1 ed.

DRAKE, Fred L., editor, Python Reference Manual - Release 2.5
19th September, 2006 http://docs.python.org/ref/ref.html

HARPER, Robert, Programming in Standard ML (WORKING DRAFT OF AUGUST 25, 2006.) - http://www.cs.cmu.edu/~rwh/smlbook/online.pdf

ABELSON, Harold, Structure and Interpretation of Computer Programs, http://mitpress.mit.edu/sicp/full-text/book/book.html

Wikipédia, a enciclopédia livre,

http://pt.wikipedia.org/wiki/Programa%C3%A7%C3%A3o_funcional

http://en.wikipedia.org/wiki/Python_%28programming_language%29

http://en.wikipedia.org/wiki/Scheme_%28programming_language%29

http://en.wikipedia.org/wiki/ML_language

acessado em 10/11/2006.