VidaGeek.net

Linux, Open-source, Programação e Produtividade

Aqui na nossa série de linguagens de programação (sem posts já faz um tempo), já falamos de Ruby, mas ainda não de Python. O ideal seria falar de Python antes mas, graças a uma palestra interessante que assisti online, resolvi fazer alguns comentários e críticas a cada uma delas.

Antes de mais nada, é importante entender quais as bases e as motivações de cada uma dessas duas linguagens. Ambas as linguagens têm como metas permitir código bonito, legível e o mais simples possível. Mas o critério de bonito e legível difere para cada uma delas. De acordo com o Zen do Python (numa tradução livre):

[...]
Casos especiais não são tão especiais para quebrarmos as regras.
[...]
Quando se deparar com uma ambiguidade, não ceda à tentação de tentar adivinhar.
Deveria haver uma, e preferencialmente só uma, maneira óbvia de fazer algo.
[...]
Se a implementação é difícil de explicar, não é uma boa ideia.
[...]

Já o Ruby, de acordo com o próprio criador Yukihiro Matsumoto:

[...] é simples na aparência, mas muito complexo no interior, tal como o corpo humano.

Nota-se que isso contraria a parte da simplicidade de implementação do Zen do Python. E nota-se isso também em bibliotecas famosas escritas em Ruby, como o ActiveRecord, por exemplo. Você já tentou entender a implementação da classe ActiveRecord::Base?

Além disso, Ruby herdou de Perl, uma de suas fontes de inspiração, a ideia de ter várias formas de fazer uma mesma coisa. E também tem alguns casos especiais de sintaxe, como a invocação de um setter (que pode ser com espaço antes do igual, apesar de o nome do setter não ter esse espaço), os parênteses opcionais na invocação de um método ou as chaves opcionais num hash passado como argumento.

Agora, minha opinião

Acho que é bom ter mais de um jeito de fazer a mesma coisa, como o Ruby possibilita. Um jeito só de fazer a mesma coisa, a meu ver, tem a vantagem de facilitar um pouco a leitura do código, graças à uniformidade. Mas, por outro lado, nos comunicamos uns com os outros numa língua que permite expressar uma mesma ideia de muitas formas diferentes, e mesmo assim nos entendemos, não? É claro que às vezes com alguma dificuldade, mas na maioria das vezes por causa da ambiguidade da língua. E liberdade de expressão também é importante em programação!

Por outro lado, as peculiaridades da sintaxe de Ruby não me agradam; acho que tornam a linguagem mais difícil de compreender. Os casos especiais são muitos e, às vezes, deixam o programador confuso quanto à necessidade de chaves, por exemplo.

Uma característica muito importante que a linguagem Ruby deveria ter, mas só Python tem, são argumentos rotulados. Em Ruby, costuma-se utilizar um hash para suprir essa necessidade, o que, convenhamos, não é muito elegante.

Um ponto sobre o qual ainda não tenho uma opinião muito elaborada é sobre a modificação de classes e métodos em tempo de execução. Em Ruby, ela é implícita: se você declarar uma classe com o mesmo nome de uma que já existe, você estará modificando a existente. Em Python, ela é explícita: você só pode modificar a classe existente se você escrever código específico para isso; se você declarar uma classe com o mesmo nome de uma já existente, você está criando outra classe. Por um lado, acho bom deixar explícito que você está modificando uma classe existente. Mas, por outro lado, faz sentido ter duas classes diferentes com o mesmo nome?

E você, qual a sua opinião? Quais são suas críticas a cada uma dessas linguagens?

Posts Relacionados:

  • FISL 10: Seaside versus Rails
  • Linguagens de Programação - C
  • Linguagens de programação - Ruby
  • Rails Vs Java e PHP
  • Linguagens de programação - Smalltalk
  • Linguagens de Programação - Basic
  • Lambda the Ultimate
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Aplicações para a Internet que se comunicam umas com as outras é algo mais do que comum. Ou sua aplicação consome algo que outra produz ou ela produz algo para outra consumir.

    É bem fácil testar o que sua aplicação produz. Basta subir um servidor local, fazer uma requisição para o endereço correspondente e processar o resultado. Mas, por outro lado, como testar que sua aplicação consome o que outra produz adequadamente?

    É claro que não vamos querer depender da aplicação remota de verdade. Queremos deixar os testes automatizados o mais isolados possível dos recursos externos. Então vamos, provavelmente, querer que o objeto responsável por fazer as requisições para fora não as faça de verdade e que devolva dados semelhantes aos da aplicação real.

    Um jeito de fazer isso seria “embrulhar” a comunicação com a Internet numa classe nossa e, nos testes, mockar essa classe e passar essa classe mockada para as classes (ou os métodos) que precisam dela. É possível fazer isso em qualquer linguagem que suporte orientação a objetos.

    Em Ruby ainda temos uma outra possibilidade. Como as classes são abertas, podemos re-escrever os métodos da classe Net::HTTP, por exemplo. Assim, não precisamos criar um embrulho; podemos utilizar sempre a classe do sistema.

    Pois também não precisamos fazer isso na mão. A gem FakeWeb permite mockar requisições para determinadas URIs com um código bastante sucinto. Por exemplo, se você quiser que seu programa receba “olá mundo” quando fizer uma requisição do tipo GET para a URI http://foo.com/bar, basta escrever antes do código que executa a requisição:


    FakeWeb.register_uri(:get, "http://foo.com/bar", :body => "olá mundo")

    Em Java também é possível fazer algo parecido com um pouco de magia negra, desde que controlemos a criação do objeto responsável pela requisição. Mas, a meu ver, a primeira abordagem resulta num código mais desacoplado. Qual a sua opinião?

    Posts Relacionados:

  • Atualizando o RubyGems no Mac
  • FISL 8.0: Wireless Meshing with OLPC
  • Eleições via Internet?
  • Firefox começa a dominar Europa
  • Aplicações portáveis em C/C++
  • Os criadores do Skype atacam novamente…
  • Algumas impressões de JavaME
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    FISL 10: Primeiro dia, organização e dojo

    A décima edição do FISL começou ontem, na PUC-RS, em Porto Alegre. A localização não é novidade, mas a data terrível atrapalhou bastante as caravanas das universidades públicas. A citar, o IME-USP que, no ano passado, foi a maior caravana do FISL com mais de 50 pessoas, teve meras 14 pessoas vindo de ônibus conosco.

    Após uma sugestão (muito mal recebida) de mover o FISL para uma cidade que ofereça mais recursos, como Curitiba, houve promessas de, no ano que vem, termos um lugar melhor para realizar esse evento. Disseram que a governadora do Rio Grande do Sul estaria aqui, ontem, na abertura do evento. Não vi, mas não duvido. No horário da abertura, ocorria um Coding Dojo organizado pela galera do DojoSP no estande da Locaweb - ontem foi em Python, hoje, segundo o Daniel Cukier da Locaweb, será em Ruby.

    Se você não sabe o que é um coding dojo, apareça na sessão hoje, às 13h na sala MSL-PR, ou dê uma olhada nos posts:

    FISL 9.0: Coding Dojo
    Screencast do Coding Dojo

    O Jonas assistiu uma palestra com um desembargador brasileiro e o senador que escreveu o projeto de lei que rege sobre crimes virtuais. Mais tarde, ele vai escrever um post completo contando o conteúdo em detalhes. Parece que foi bastante interessante.

    Pena, que a organização do FISL impediu que os palestrantes respondessem uma pergunta bastante pertinente sobre o que o Governo tem em mente para impedir a interpretação errônea da lei, que poderia prejudicar pessoas. Impediu, porque, depois de a pergunta ser feita, o coordenador de mesa declarou que o tempo acabou. O palestrante pediu para responder apenas essa pergunta (que é extremamente pertinente) e recebeu um claro “Não.” na cara. Feio, organização do FISL, muito feio.

    Mais feio ainda impedir palestrantes de entrar na sala VIP (sala dos palestrantes) no final da tarde de ontem porque “a sala está reservada para as autoridades da abertura”. Palestrantes contam com a sala também para fazer coisas pertinentes ao FISL - terminar sua palestra, por exemplo!

    Que era o caso do Luiz, aqui do Vidageek, e do Fabio Kung. Eles vão se degladiar numa palestra hoje, às 16h na sala fisl6 (41-E), comparando os frameworks de desenvolvimento web Rails (Ruby) e Seaside (Smalltalk). Atenção no horário e local! A programação mudou e não alteraram na grade - é no espaço que parece estar vazio às 16h de hoje.

    Aliás, falando na grade de palestras… organização, se tem gaps vazios em algumas salas de palestras, por que não passaram mais algumas palestras inscritas e refutadas — muitas vezes, sem nem notas, nem comentários ou razões reais para não terem passado. Ouvi de um palestrante que passou na “segunda chamada” que ele tinha 4 aceitações fortes, uma rejeição fraca e não passou. Bizarro, hein? Outros nem receberam as notas ainda.

    Um grupo de pessoas da USP sugeriu trocar o sistema pobre de submissão e avaliação de palestras que se usa atualmente pelo sistema que é usado na organização todas as conferências mundiais da Debian. A organização disse que era tarde de mais pra isso - e a submissão de palestras não estava aberta ainda.

    Muitos por quês e muitas críticas. Fica uma sugestão: colocar mais pessoas de outros Estados na organização. Muita gente está achando que a organização está regionalista de mais. E isso é, provavelmente, a parte mais fácil de resolver.

    Posts Relacionados:

  • Dojo de Carro
  • FISL 9.0: Coding Dojo
  • Inscrição de Caravanas para o FISL 8
  • FISL 8.0
  • Séries
  • Evento de metodologias ágeis: Falando em Agile
  • Screencast do Coding Dojo
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

    Ruby e Rails no Mundo Real

    Rer 2009
    O Ruby e Rails no Mundo Real aconteceu em São Paulo neste sábado (04/04/09) em São Paulo. O evento começou com uma grande decepção: um evento com 130 programadores Ruby/Rails mas sem internet Wireless, ou seja, nada de Twitter, E-mails e instalação de gems. As tomadas também eram poucas e foi preciso revezar entre três notes (eu, Fabsn e Flores).

    Mas nem tudo foi ruim no evento. Ganhamos uma apostila com (quase todos) slides das palestras e pudemos ver tecnologias como XMPP4R e Jabber (apesar de uma palestra maçante na quantidade de códigos) e várias formas de programação de Ruby para Desktop (como Shoes, Ruby-GTK, FXRuby e RubyCocoa) e ainda sobre o testes (algo bem batido, mas que apresentou o Remarkable - uma série de matchers para RSpec).

    Num âmbito menos técnico, vimos uma palestra muito divertida e interessante sobre outsorcing - como ganhar dinheiro trabalhando para os gringos via internet. Foi apresentado o já clássico Ruby Learning para quem está começando a aprender a linguagem. Em particular, uma palestra de empreendedorismo com Ruby foi deplorável.

    No final, o guru Fabio Kung salvou o evento (que apesar de ter algumas coisas boas, dava a sensação de que o dinheiro tinha sido mal investido) apresentando uma fantástica palestra sobre metaprogramação em Ruby - ou o que ele chamou de magia negra. Utilizando a ParseTree (a mesma do RFactor), Kung mostrou coisas absurdas como fazer o algoritmo map reduce do Google, obter incríveis informações do seu código (como complexidade e más práticas de programação).

    Uma cobertura mais detalhada pode ser encontrada no Ruby Inside Brasil (apesar de divergimos de algumas opiniões). O evento foi organizado pelo Grupo de Usuários de Ruby de São Paulo (GURU-SP), um grupo animado que vale a pena conhecer. Apesar de tudo, achamos que valeu a iniciativa do grupo em fazer este evento.

    Posts Relacionados:

  • Rails Vs Java e PHP
  • FISL 9.0: Entrando nos trilhos - Introdução a Ruby on Rails
  • FISL 10: Agilidade e Qualidade de Projetos com Ruby on Rails
  • Rails Summit
  • Autores
  • Uma gem para testar aplicações que se comunicam com a Internet
  • Atualizando o RubyGems no Mac
  • Acompanhe-nos por RSS, por Email ou via Twitter.
    Veja como ter um desconto no Dreamhost: um excelente servidor web.

  • 13 Comments
  • Filed under: Eventos, Opiniao, Ruby