Algebraic blindness

[Rui Carlos]

Um artigo interessante sobre os problemas de se reutilizarem tipos primitivos em diversos contextos, para não se ter o trabalho de definir um novo.

Citação

Abstract

Algebraic data types make data more flexible, but also prone to a form of generalized Boolean Blindness, making code more difficult to maintain. Luckily, refactoring the issues is completely type-safe.

[...]

https://github.com/quchen/articles/blob/master/algebraic-blindness.md

[pwseo]

O artigo retrata um problema que todos nós já encontrámos noutras linguagens. De facto foi um dos pontos fortes que vi na linguagem desde o início: a maleabilidade dos tipos de dados e o quão barato sai criar novos tipos de dados para melhorar a legibilidade, com ganhos paralelos em termos de verificação pelo compilador.

Nota: pelo que vi, o autor tem ali mais um conjunto de artigos prontos a serem lidos, terei que explorar 😛 (o meu Haskell-fu está fracote e enferrujado).

[nunopicado]

Interessante, sim.

Ainda há dias estive a ler um artigo sobre a mesma temática, embora com soluções diferentes, visto serem também paradigmas diferentes.

http://objectpascalprogramming.com/posts/tipos-primitivos-nos-argumentos/

A conclusão é basicamente a mesma: Tipos primitivos, embora mais simples, têm desvantagens, que podem ser colmatadas com uso de tipos próprios (neste caso, objectos).

[Warrior]

Realmente dá vontade de mover este tópico para outra secção, já que é um problema transversal às várias linguagens.

Nesse artigo até é referido o principal motivo para normalmente não criarmos um sistema ainda mais fortemente tipado quando estamos a programar: na maior parte das linguagens, perdemos todas as funções que estão associadas aos tipos primitivos. É muito bonito indicar que queremos um tipo "Host", mas se depois na prática tivermos que implementar um .getValue que retorna a string original (que na prática é o que usamos sempre), ou se tivermos que implementar os vários métodos da classe String na classe Host, então perdemos toda a vontade em seguir esse caminho.

 

Por acaso agora tenho programado bastante mais em Scala, e a linguagem resolve esse problema de forma maravilhosa: podemos declarar o nosso tipo Host, e declarar algo chamado uma "conversão implícita", por exemplo de Host para String. Dessa forma, podemos passar uma instância de Host para qualquer método que espere uma String, e podemos usar métodos da classe String em Host sem fazer cast (por exemplo, host.split(' ') seria permitido, e os IDEs reconhecem isso e dão suporte). A vantagem é que continuamos a ter um sistema fortemente tipado: qualquer função que espere um Host, tem que receber um Host porque a conversão só é feita num sentido, portanto podem-se apanhar muitos erros de strings (hostnames) mal formatados, etc.

[pwseo]

6 horas atrás, Warrior disse:

Por acaso agora tenho programado bastante mais em Scala, e a linguagem resolve esse problema de forma maravilhosa: podemos declarar o nosso tipo Host, e declarar algo chamado uma "conversão implícita", por exemplo de Host para String.

Solução interessante, é como se fosse um compromisso muito balançado que preserva as vantagens de ambas as abordagens. Pode ser que um dia alguma coisa volte para Haskell nesse sentido também 😛