Ainda não vi uma definição sobre o que seria uma linguagem elegante, então lá vai a minha:
Uma linguagem elegante é baseada em primitivas simples e extensíveis e, principalmente, sem muitas exceções.
Segundo esta definição Ruby, Smalltalk e LISP são elegantes. Java é um pouco, C# com suas centenas de exceções (sobrecarregar + é diferente de sobrecarregar [], dentre outras várias exceções) não é.
Uma linguagem elegante é simples e compacta. É de se esperar que não tenha sobrecarga de operadores, mas isso não é verdade. O problema das pessoas com sobrecarga de operadores é porque elas vêem isso como uma quebra da rule of least surprise. Essa regra diz (implora, eu diria) para não surpreendermos nossos usuários modificando o mundo que eles já conhecem para que uma ação traga consequências não esperadas. Por exemplo imagine que você vai modificar um programa como o ls para dar mais performance (uau, você é bom!). Faça o que quiser mas não mude os parâmetros de entrada e saída ou você vai quebrar um zilhão de programas e scripts pelo mundo todo. Caso introduza uma feature nova faça o usuário explicitamente solicitar por ela (passando um flag no estilo ls -lira –my-fancy-new-feature) e mantenha o default como o antigo.
E onde entra sobrecarga de operadores nisso? Lá no seu primeiro curso de programação (ou no seu primeiro livro se você opta pelo caminho mais difícil) deve ter aprendido sobre literais, variáveis, condicionais e… operadores. Operadores são caracteres especiais com uma função bem definida na linguagem, por exemplo o operador de divisão, de resto, de adição…
Em Java, quando você chama:
String texto = "abc".toUpperCase();
É fundamentalmente diferente de quando chama:
int numero = 12 + 24;
Porque um método e um operador são coisas diferentes e você aprendeu a pensar desta forma. Se amanhã eu puder sobrescrever o operador + para que escreva algo na tela você vai se surpreender porque não era isso que o manual da linguagem te disse.
Ainda assim, existem muitas ocasiões onde sobrecarga de operador são mais que convenientes, são semânticos. Imagine o exemplo do nosso BigDecimal:
BigDecimal a = new BigDecimal("100");
BigDecimal b = new BigDecimal("300");
Some os dois. Ok, você é um programador Java esperto e sabe que vai ter que fazer algo como:
BigDecimal resultado = a.add(b);
Mas disso até me dizer que é melhor que usar ‘+’ é outra história.
Mas e a simplicidade? Não é legal termos um conjunto pequeno de operadores que faz coisas previsíveis e que servem na maioria das vezes? Sim, é! Mas num mundo onde tudo migra para mais expressividade, com Model-Driven Development e Domain-Specific Languages ter este tipo de limitação não é interessante. As melhores linguagens para construir DSLs são as mais flexíveis e por acaso as mais elegantes, que coincidência, não? E como Ruby, que se enquadra nestes dois aspectos, lida com isso?
Simples. Em Ruby não existem operadores, pelo menos não como você está acostumado em Java, operadores são apenas apelidos para métodos. A vantagem disso é que se muda o modelo mental, a partir do momento que você sabe que um operador e um método são a mesma coisa você tem com operadores o mesmo cuidado que tem com métodos. Ao chamar add() do BigDecimal você tem que saber se o método vai retornar o resultado como um objeto separado, se vai modificar os objetos passados como parâmetros, etc. Como você faz isso? Lendo a documentação até se familiarizar com a classe e seu idioma. Após familiarizado você começa a usar sem pensar.
E quando você espera estar lidando com uma classe que sobrescreve um operador e na verdade recebe como parâmetro uma subclasse dela? Sem problemas! Se o autor seguiu os princípios básicos da Orientação a Objetos, que derivam do Design by Contract e o Princípio de Substituição de Liskov a subclasse tem que obedecer o contrato da classe-pai, e se você obedeceu os mesmos princípios não precisa de nada que não esteja no contrato.
Esse tipo de resistência com funcionalidades é o tipo de coisa que se elimina aprendendo várias linguagens e estudando suas motivações. Existem algumas linguagens como as citadas que merecem ser estudas ainda que você nunca as vá utilizar de fato. Elas abrem a sua cabeça.
Estou trabalhando em projetos C# agora e aquela funcionalidade de definir uma classe “partial” é uma aberração que eles colocaram na sintaxe por motivos puramente da IDE deles. Não dá pra levar a Microsoft a sério desse jeito.
Operadores também são métodos em C++ e nem por isso evitaram os problemas.
Quais problemas, Fábio?
>> …Se amanhã eu puder sobrescrever o operador + para que escreva algo na tela você vai se surpreender porque não era isso que o manual da linguagem te disse…
>> E quando você espera estar lidando com uma classe que sobrescreve um operador e na verdade recebe como parâmetro uma subclasse dela? Sem problemas! Se o autor seguiu os princípios básicos da Orientação a Objetos…
Acho que você não entendeu o ponto principal do post. Quando você tem uma linguagem extensível o manual da linguagem não vai te dizer o que fazer neste caso.
Passe a pensar em operadores como métodos e não há mais problemas. Qual ‘manual’ te diz o que o método String.split() faz? É este mesmo manual que te diz o que o método String.+ faz.
Se o autor não seguir princípios básicos da orientação a objetos como Liskov você vai ter muito mais problemas que isso. Se a pessoa não obedece o contrato de um método chamar qualquer método, seja ele um operador ou não, é perigoso.
Em suma: suas observações derivam do fato de que você considera operadores e métodos como coisas diferentes. Em Java é assim, em C# é assim mas a propsota das plataformas dinâmicas (muitas mais velhas que Java ou C++) é se livrar deste pensamento.
O problema está em dar liberdade demais a programadores que não possuem nenhuma consciência, então parte do projeto fica de uma forma e a continuação pode virar um CAOS.
Fico em dúvidas, acho o recurso interessante, mas á malefícios com isso também .
Kenobi, pense de quantas maneiras diferentes você dá liberdades perigosas para um programador pedindo para ele simplesmente implementar uma action do Struts (ou coisa que o valha). Imagine que ele acabou de ler um artigo sobre classloaders customizados e teve idéias… interessantes…