Functors em Java
Ronie Uliana
Tava de bobeira no fim de semana e fiz isso aqui:
http://github.com/ruliana/YoDaFunkta
Comentários são muito bem vindos. Críticas são especialmente bem vindas :)
[]s
Ronie
Diego Souza
grupo?
--
~dsouza
yahoo!im: paravinicius
gpg key fingerprint: 71B8 CE21 3A6E F894 5B1B 9ECE F88E 067F E891 651E
Diego Souza
>
diferentes? Dado uma categoria A e uma categoria B, podemos ter um
functor relacionando os objetos/morfismos destas duas categorias
F : A -> B.
E todo functor precisaria obeceder duas leis:
1. identidade:
F(id) = { id a | a E F(A) } # o próprio conjunto A se id é um
morfismo identidade sobre o conjunto A
2. distributiva:
F(f . g) = F(f) . F(g)
Embora conheça muito pouco sobre `Category Theory', me parece que um
/Functor filter/ não é um functor (só dei uma olhada rápida no readme).
Mas não tenho certeza. Além disso, provavelmente garantir esses axiomas
no programa não seja muito fácil, nem talvez, interessante.
Quanto a isto:
1. You lose static typing check. There is always a balance between
“power” and “safety”, here I choose “power”. IMHO, static type
checking it’s not that safe, so, for me, it’s a really small price to
pay. But you are not me, it’s better to be warned :)
Você se refere a Java em particular ou todos os sistemas de tipos
estáticos em geral? E o que quer dizer `not that safe'?
Ronaldo Ferraz
R.
Ronie Uliana
Na verdade o YoDaFunkta não é sobre esse tipo de functor aqui:
http://en.wikipedia.org/wiki/Functor, mas sim sobre esse aqui:
http://en.wikipedia.org/wiki/Function_object
Talvez o nome e a apresentação tenha realmente ficado confusa. Acho
melhor esclarecer mais. Dos "functor" puramente função não conheço
muito, é isso que estou estudando ainda. Mas o que já vi de trabalhar
com funções como first class citizens me motivou a fazer a lib. :)
Quem sabe na evolução da coisa como fica? :)
Qdo digo "power" vs "safety", não me refiro a nada específico.
Normalmente temos esses tipos de escolha na vida normal,
principalmente na vida de programador. "Segurança" e "poder" são às
vezes antagônicos, no caso específico dessa lib, tive que escolher.
"Not that safe" significa que na minha humilde opinião, tipagem
estática não previne uma quantidade de erros que valha o esforço. Tipo
certo é legal, mas pra mim o problema maior seria garantir que o
método "onePlusOne" retornasse "2" e não "30" :) (se bem que, se
"onePlusOne" retornar "abacate" vou ter um problemão)
[]s
Ronie
2009/9/29 Diego Souza <dso...@bitforest.org>:
Diego Souza
>
> Diego,
>
> Na verdade o YoDaFunkta não é sobre esse tipo de functor aqui:
> http://en.wikipedia.org/wiki/Functor, mas sim sobre esse aqui:
> http://en.wikipedia.org/wiki/Function_object
>
> Talvez o nome e a apresentação tenha realmente ficado confusa. Acho
> melhor esclarecer mais. Dos "functor" puramente função não conheço
> muito, é isso que estou estudando ainda. Mas o que já vi de trabalhar
> com funções como first class citizens me motivou a fazer a lib. :)
do segundo :-)
Interessante, de qualquer forma os primeiros exemplos me pareciam
Functors válidos, por exemplo F (length) (neste caso mapeia strings em
inteiros).
Pensando bem, acho que o motivo do F (filter) não funcionar como Functor
é provavelmente pelo fato que ele opera na categoria em si (a lista) ao
invés dos elementos. Mas enfim, não vem ao caso.
> Quem sabe na evolução da coisa como fica? :)
>
> Qdo digo "power" vs "safety", não me refiro a nada específico.
> Normalmente temos esses tipos de escolha na vida normal,
> principalmente na vida de programador. "Segurança" e "poder" são às
> vezes antagônicos, no caso específico dessa lib, tive que escolher.
> "Not that safe" significa que na minha humilde opinião, tipagem
> estática não previne uma quantidade de erros que valha o esforço. Tipo
> certo é legal, mas pra mim o problema maior seria garantir que o
> método "onePlusOne" retornasse "2" e não "30" :) (se bem que, se
> "onePlusOne" retornar "abacate" vou ter um problemão)
Certamente vamos concordar que onePlusOne, neste caso, possui o tipo:
onePlusOne :: Int
Tão logo 30 seja uma instância de Int, assim como o é o 2, o programa
está correto no que se refere à tipagem, muito embora não faça o que
promete. Concordo que só ajuda em bugs triviais, mas daí extrapolar que
não vale o esforço me parece um salto grande demais. Afinal, estamos
considerando uma implementação específica:
http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list
Ronie Uliana
>
> On Tue, Sep 29, 2009 at 07:13:39PM -0300, Ronie Uliana wrote:
>>
>> Diego,
>>
>> Na verdade o YoDaFunkta não é sobre esse tipo de functor aqui:
>> http://en.wikipedia.org/wiki/Functor, mas sim sobre esse aqui:
>> http://en.wikipedia.org/wiki/Function_object
>>
>> Talvez o nome e a apresentação tenha realmente ficado confusa. Acho
>> melhor esclarecer mais. Dos "functor" puramente função não conheço
>> muito, é isso que estou estudando ainda. Mas o que já vi de trabalhar
>> com funções como first class citizens me motivou a fazer a lib. :)
>
> Ah sim, são dois assuntos bem diferentes ... não percebi que se tratava
> do segundo :-)
>
> Interessante, de qualquer forma os primeiros exemplos me pareciam
> Functors válidos, por exemplo F (length) (neste caso mapeia strings em
> inteiros).
>
> Pensando bem, acho que o motivo do F (filter) não funcionar como Functor
> é provavelmente pelo fato que ele opera na categoria em si (a lista) ao
> invés dos elementos. Mas enfim, não vem ao caso.
Bom, conforme eu for estudando e aprendendo mais, quem sabe saí um
Functor objeto que funciona como Functor para tipos tb? Inda não sei o
quão convergente podem ser os conceitos :p
>> Quem sabe na evolução da coisa como fica? :)
>>
>> Qdo digo "power" vs "safety", não me refiro a nada específico.
>> Normalmente temos esses tipos de escolha na vida normal,
>> principalmente na vida de programador. "Segurança" e "poder" são às
>> vezes antagônicos, no caso específico dessa lib, tive que escolher.
>
> Ok. Provavelmente o sistema de tipos de Java não ajuda muito também.
>
>> "Not that safe" significa que na minha humilde opinião, tipagem
>> estática não previne uma quantidade de erros que valha o esforço. Tipo
>> certo é legal, mas pra mim o problema maior seria garantir que o
>> método "onePlusOne" retornasse "2" e não "30" :) (se bem que, se
>> "onePlusOne" retornar "abacate" vou ter um problemão)
>
> Mas daí já não é mais um problema de tipos, certo?
>
> Certamente vamos concordar que onePlusOne, neste caso, possui o tipo:
>
> onePlusOne :: Int
>
> Tão logo 30 seja uma instância de Int, assim como o é o 2, o programa
> está correto no que se refere à tipagem, muito embora não faça o que
> promete. Concordo que só ajuda em bugs triviais, mas daí extrapolar que
> não vale o esforço me parece um salto grande demais. Afinal, estamos
> considerando uma implementação específica:
> http://en.wikipedia.org/wiki/Template:Type_system_cross_reference_list
Pode ser o caso... A meu ver, essa história de tipagem é muito gosto
pessoal. Não sei de ninguém que tenha conseguido fazer um estudo que
indicasse se X é melhor que Y ou se compensa X sobre Y. Então vira um
negócio de "opinião devido experiência pessoal". e como cada um tem a
sua as opiniões divergem muito.
Talvez nem seja a questão de se uma coisa compensa ou não. Talvez a
questão seja, na verdade, "quando" a tipagem estática/dinâmica
ajuda/atrapalha. Pq é possível achar exemplos e contraexemplos para
ambos.
Mas o importante é conseguir fazer bons programas com poucos bugs,
pouco esforço e de fácil manutenção, seja lá o que for usado, né? ;)
[]s
Ronie