Ideias (para um quadro parado)

[pwseo 229]

Olá a todos,

Seria interessante ver alguma actividade neste quadro... Especialmente agora que o Haskell está a ganhar alguma massa crítica e é usado por cada vez mais pessoas, é pena que no Portugal-a-Programar a tendência seja oposta.

Estive a pensar em escrever um tutorial sobre a utilização de monads em Haskell mas o tempo não é muito e portanto vou a passo de caracol (além de não ser propriamente fácil escrever sobre um tema tão grande)

Por isso, pergunto à comunidade: o que acham que deveríamos falar aqui no quadro? Algum tema em especial? Dúvidas que tenham, curiosidades que vos apareçam.. O importante era começarmos a ter alguma actividade aqui, porque até é pena não se falar nada acerca de uma linguagem com tanto para se dizer!

Cumprimentos,

Pedro

[thoga31 610]

Quem sabe alguma coisa do assunto, deveria fazer uns Tutos e How-To's acerca de temas variados, como tu estás a tentar fazer no teu pouco tempo livre. É meio caminho andado para dinamizar o quadro, pois suscita interesse por parte de quem está e quer aprender. São tópicos que se tornam, regra geral, pequenos focos de debate de conhecimentos extremamente frutífero.

[taviroquai 57]

Eu admiro as linguagens funcionais mas depois de conheçer linguagens imperativas (procedimental e orientado a objectos), acabei por não ficar muito à vontade com linguagens funcionais... talvez sejam mais complicadas, não sei... talvez pela sintaxe ou estrutura dos programas...

As minhas preferências vão para C, Java, PHP, Javascript... talvez uns exemplos de pequenos case-studies escritos em Haskell (em comparação de como se escrevem noutras linguagens) sejam muito úteis. Por exemplo a Lista de Tarefas (o famoso TODO), como se faz em haskell? Se possivel uma versão sem recorrer a um SGBD e outra a recorrer a um SGBD.

[thoga31 610]

Para quem prefere e/ou necessita de fazer aplicações quotidianas e de tarefas mais específicas e que requerem coisas como DB's e GUI's, Haskell não será a melhor escolha.

O paradigma funcional tem outros propósitos. Apesar de não ser o melhor para esses fins, é sem dúvida um paradigma que nos obriga, antes de programar de forma diferente, a pensar de forma diferente - talvez esteja aqui uma razão pelo misto de admiração e "complicação" destas linguagens.

Não se dá, em Haskell, simplesmente uma série de ordens sobre o que fazer - compõem-se funções, e criam-se soluções de uma forma totalmente distinta.

Por exemplo, no paradigma estrutural ou OOP tens de indicar ponto por ponto todo o processo para determinar a lista de primos de 2 a N. Em Haskell apenas "indicas" com uma composição de funções como determinar os primos. Uma solução rápida, decerto há outras mais elegantes:

listaprimos n | n >= 2    = 2 : (filter primo [3,5..n])
             | otherwise = []
 where
 primo x = not . any (== 0) . map (x `mod`) $ [2..x `div` 2]

Ou seja, o Haskell está a receber este método: "Crio uma lista dos restos das divisões de x por uma série de divisores (de 2 a x/2), e quando um deles der 0, nego o resultado e devolvo a resposta".

E se quiser não os primos até N, mas sim os primeiros N primos? Alterando-se ligeiramente o código, teremos...

listaprimos n | n >= 2    = takeWhile (<= n) todosprimos
             | otherwise = []

primeirosprimos n = take n todosprimos

todosprimos = 2 : (filter primo [3,5..])
 where
 primo x = not . any (== 0) . map (x `mod`) $ [2..x `div` 2]

Apresenta isto numa linguagem que gostes... Vais andar a dar ordens, uma por uma, em vez de dares "pistas" de como obter a resposta.

Eu também admiro as linguagens funcionais por isto mesmo: criam soluções elegantes e que, no meio da sua "complicação", são, afinal, simples.

Há imensas razões pelas quais é "saudável" estudar uma linguagem funcional. Pode não aparentar ter muita utilidade no dia-a-dia, mas quanto mais não seja a utilidade em exercitar os nossos neurónios.

Editado 15 de Maio de 2013 por thoga31

[pwseo 229]

taviroquai,

Não sei até que ponto aprendeste Haskell, mas o tipo de flexibilidade que dá às funções é absolutamente incomparável com linguagens como C, Java, etc. Se calhar não tiveste contacto com isso... Claro que não é a melhor linguagem para todos os propósitos, tal como qualquer outra linguagem, naturalmente.

Uma comparação directa é, por esse motivo, bastante difícil. São paradigmas completamente diferentes, e isso significa que em qualquer coisa mais complexa que o trivial "Hello, world", haverá divergências consideráveis.

[thoga31 610]

O que o @pwseo disse fez-me lembrar uma coisa...

Por exemplo a Lista de Tarefas (o famoso TODO), como se faz em haskell? Se possivel uma versão sem recorrer a um SGBD e outra a recorrer a um SGBD.

Da mesma forma que não podes esperar que o paradigma estrutural faça o mesmo que o OO (no máximo obténs uma aproximação que deixa um pouco a desejar), muito menos podes esperar que o paradigma funcional faça o mesmo que qualquer um desses dois.

Estás a pedir a uma linguagem puramente funcional que faça algo que só uma linguagem estrutural e OO está plenamente preparada para o fazer. Suponho que em Haskell também dê para fazer, mas aí não estás a utilizar o Haskell na sua essência mais pura.

É quase como pedir a um macaco e a um elefante para subirem a uma árvore tendo por base a mesma grelha de avaliação.

Do mesmo modo, eu podia-te pedir para pegares numa das LP's que disseste que gostas e fazeres aquilo que Haskell faz - good luck

Editado 15 de Maio de 2013 por thoga31

[taviroquai 57]

Acho que interpretaram mal o meu post...

Eu aprendi um pouco de Lisp e não fiz programas complexos. Compreendo que na criação de cada LP elas tiveram um propósito e uma linguagem não serve para tudo.

Quando perguntei como se faz uma TODO LIST estava a ser imparcial e acredito que seja possível faze-lo com Haskell, porque não? Se aceita input do utilizador, e permite uma lista como estrutura de dados, com certeza que dará um bom exemplo das vantagens de Uma linguagem funcional.

Se perguntei é porque queria aprender.

[pwseo 229]

Sim, é perfeitamente possível em Haskell (e de facto simples, até). Já agora, Lisp é funcional, mas muito diferente de Haskell.

O que eu estava a dizer é que uma comparação directa é pouco exequível porque conceptualmente há coisas que não podes fazer nas outras linguagens, sendo por isso impossível comparar.

Quem sabe, talvez um dia destes mostre aqui um protótipo de todo list. A única parte não trivial seria mesmo o tratamento do input do user (ou leitura das tarefas a partir de um ficheiro), mas isso é sempre o mais problemático em qualquer linguagem.

A lógica interna do programa seria simples de implementar. Aqui fica a representação de uma tarefa:

type Done = Bool

data Priority = Low | Normal | High
 deriving (Show, Eq, Ord)

data Task = Task Priority String Done
 derving (Show, Eq)

A partir daqui, podemos utilizar quaisquer funções para manipular listas de Tasks.

Exemplos:

ordenar tarefas por prioridade

byPriority = sortBy (\(Task a _ _) (Task b _ _) -> compare a b)

mostrar as tarefas completas

completed = filter (\(Task _ _ d) -> d)

Claro que isto pode depois ser escrito de formas mais idiomáticas e legíveis...

Editado 15 de Maio de 2013 por pwseo

[taviroquai 57]

Boa pwseo, era mesmo isso que pretendia: ficar com uma idea de como se faz uma TODO em Haskell. Acho que não se deve sobestimar a linguagem especialmente para implememtar uma Todo list.

Sim Lisp é bem diferente.

Ter um exemplo completo era óptimo.

[pwseo 229]

Qualquer dia A ideia também era as pessoas começarem a ganhar um pouco de curiosidade e experimentarem elas próprias.

Uma coisa que não se repara muito é que todas as definições de funções que dei acima eram parciais (ou seja, funções que não receberam todos os seus argumentos) -- esta é uma das inovações de Haskell que deixa outras linguagens a milhas.

Para dar mais um cheirinho da expressividade, algumas alternativas...:

data Task = Task {
 priority :: Priority
, text     :: String
, done     :: Bool
}

completed = filter done

byPriority = sortBy (compare `on` priority)

(Nota: algumas coisas foram omitidas, nomeadamente as instanciações dos tipos de dados nas classes Eq, Ord e Show... afinal de contas, isto é apenas um exemplo)

[thoga31 610]

Só um aparte...

@taviroquai, nós entedemos bem o teu post, possivelmente, e falo pessoalmente, poderei não me ter expressado da melhor forma. Apenas quis dizer aquilo que o @pwseo já resumiu: há muitas coisas que são incomparáveis entre Haskell e as LP's às quais estás mais habituado.

Em Haskell é possível fazer muita coisa, mas algumas delas tornam-se quase que "impraticáveis". A minha visão de Haskell é mesmo algo como "um mundo totalmente à parte"... mas fascinante.

Continuando... xD

[taviroquai 57]

As linhas que definem a Task até me são +/- familiares. A linha do sortBy é que não se parece com nada que conheço, mas as funcionais são conhecidas por fazerem coisas muito poderosas em poucas linhas.

[taviroquai 57]

A minha visão de Haskell é mesmo algo como "um mundo totalmente à parte"... mas fascinante.

Uma coisa é reconhecer as diferenças da linguagem, outra coisa é difundir a linguagem como "um mundo totalmente à parte" e isso contribui para o afastamento de quem desenvolve software. Acho muito mais amigável, e de valor, mostrar o potencial da linguagem em case-studies comuns, como este que discutimos acima.

O que quero dizer é que, seja em que linguagem for, não esquecer a abordagem prática, afinal, os programas servem para resolver problemas do utilizador comum.

Editado 15 de Maio de 2013 por taviroquai

[thoga31 610]

Os meus conhecimentos de Haskell não permitem coisas como aquela que o @pwseo fez, mas permitem-me ter a noção de que há grandes diferenças que valem a pena ser abordadas.

O case-studey abordado baseia-se em algo comum que se faz com linguagens imperativas e OO. Por acaso é algo que o Haskell faz com muita elegância. Para vermos a essência principal do Haskell, que é a composição e flexibilidade de funções, como o @pwseo já deu um cheirinho, será necessário esquecer um pouco o imperativo e abrir o espírito à possibilidade de se voltar a sentir que se está a aprender a programar quase do zero. É das coisas que mais me fascina no Haskell. Eu mesmo já dei um pequeno exemplo com os números primos, mas suponho que aquilo tenhas percebido bem, é relativamente simples para quem está familiarizado com Lisp.

São visões diferentes. Quando me disseram que Haskell era um mundo à parte mas fascinante, do mesmo modo como eu o disse, fiquei interessado, e pretendo aprofundar assim que puder de novo. Mas como em tudo na vida, as visões mudam. Eu tenho a visão mais teórica e do incomum, tu és mais prático.

P.S. - o cansaço e uma série longa de noites não muito bem dormidas têm os seus efeitos. Reflectem-se não só mas também aqui no fórum - não me ando a expressar tão bem como devia e costumava fazer, entre outros... Vale o que vale, mas vale.

Editado 15 de Maio de 2013 por thoga31

[taviroquai 57]

Eu mesmo já dei um pequeno exemplo com os números primos, mas suponho que aquilo tenhas percebido bem, é relativamente simples para quem está familiarizado com Lisp.

Fiz uns exercícios em Lisp em 2000 na universidade... já tou esquecido de Lisp ... e porquê? Porque me familiarizei e me dediquei mais a outras linguagens, talvez se mantivesse a minha persistencia na aprendizagem e uso de Lisp, hoje resolveria os mesmo problemas ainda com Lisp (e talvez integrando com outra linguagem que oferecesse uma UI melhor).

Mas cada linguagem tem o seu valor, por exemplo em relação à UI do browser, um mundo novo ainda está por vir... C foi bastante famoso... hoje Javascript é rei no browser... o que hoje se faz com uma linguagem "amanhã" resolve-se o mesmo problema com outra... isto porque o que interessa é a realização prática e útil para o utilizador final.

Por exemplo, um jogo online que necessite de IA, porque não usar Prolog, Lisp ou Haskell no servidor e Javascript na UI (mais uma ideia para o @pwseo)? Isto é só um exemplo...

Editado 15 de Maio de 2013 por taviroquai

[Betovsky 2]

Desculpem estar a abordar o tópico após tanto tempo, mas a ideia de um tutorial com base numa lista ToDo's não e' assim tão descabida.

A beleza de este tipo de aplicações e' que são muito simples, e permite começar com algo básico e 'complicar' pelo caminho.

Para iniciar pode ser apenas algo que só guarde uma lista de tarefas em memoria, por cada vez que a aplicação e' executada.

Ate chegar a um passo final que se trata de uma camada GUI em html+js a interagir com um serviço rest feito em haskell com uma db por trás.

Possibilidades são bastantes ;P