Uma linguagem de programação pode te tornar estúpido?

[quote=sergiotaborda][quote=Thiagosc][quote=sergiotaborda]As linguagens de programação permitem a criação de novos simbolos, mas não de novos meta-simbolos. Por exemplo, classes eu crio quantas quiser, mas para criar o conceito de anotação é preciso mudar a estrutura interna da linguagem/plataforma

Isso não acontece em uma lingua normal (que não de programação). É por isso que é linguagem de programação e não lingua de programação…[/quote]

Você quer dizer “linguagens mainstream”. Linguagens baseadas no Lisp permitem criar coisas totalmente novas. É possível, por exemplo, até customizar o reader que vai ler o código e transformá-lo em um grafo para ser interpretado.[/quote]

Não conheço muito de Lisp, mas pelo que sei ele usa o paradigma funcional baseado em funções lambda.
Pode modificar a formar como o código é definido (sintax) ? pode adicionar annotations ,por exemplo ?
Ou seja, mudar a linguagem em si ? Acho que não…

Costumizar o reader é modificar algo que já existe. A questão é , consegue fazer criando algo novo ?[/quote]

Por incrível que pareça, pode! :slight_smile: Basta usar as macros do Lisp para que você mude a sintaxe da linguagem ou mesmo adicione novas features.
É assim que são criados diversos dialetos do Lisp, como por exemplo o Arc. Show de bola o negócio.

[quote=kicolobo][quote=sergiotaborda]

Não conheço muito de Lisp, mas pelo que sei ele usa o paradigma funcional baseado em funções lambda.
Pode modificar a formar como o código é definido (sintax) ? pode adicionar annotations ,por exemplo ?
Ou seja, mudar a linguagem em si ? Acho que não…

Costumizar o reader é modificar algo que já existe. A questão é , consegue fazer criando algo novo ?[/quote]

Por incrível que pareça, pode! :slight_smile: Basta usar as macros do Lisp para que você mude a sintaxe da linguagem ou mesmo adicione novas features.
É assim que são criados diversos dialetos do Lisp, como por exemplo o Arc. Show de bola o negócio.[/quote]

Legal…
Eu posso dizer ao parser/compilador que a sintaxe @Transaction deve fazer o codigo X sobre o codigo Y ?

http://www.defmacro.org/ramblings/lisp-ducati.html

Vale dar uma conferida 8)

[quote=kicolobo]
Por incrível que pareça, pode! :slight_smile: Basta usar as macros do Lisp para que você mude a sintaxe da linguagem ou mesmo adicione novas features.
É assim que são criados diversos dialetos do Lisp, como por exemplo o Arc. Show de bola o negócio.[/quote]

Uhm… não. Macros permitem criar bastante liberdade com sintaxe (não liberdade completa) mas dialetos de Lisp (pelo menos os mais comuns) não são gerados com macros, são linguagens diferentes com implementações diferentes. Lisp não é funcional mas Scheme é, por exemplo. Clojure tem memória transacional, e por aí vai.

[quote=pcalcado][quote=kicolobo]
Por incrível que pareça, pode! :slight_smile: Basta usar as macros do Lisp para que você mude a sintaxe da linguagem ou mesmo adicione novas features.
É assim que são criados diversos dialetos do Lisp, como por exemplo o Arc. Show de bola o negócio.[/quote]

Uhm… não. Macros permitem criar bastante liberdade com sintaxe (não liberdade completa) mas dialetos de Lisp (pelo menos os mais comuns) não são gerados com macros, são linguagens diferentes com implementações diferentes. Lisp não é funcional mas Scheme é, por exemplo. Clojure tem memória transacional, e por aí vai.[/quote]

Lisp É funcional e todo Common Lisp tem, por definição, um sistema de macros (caso contrário não é Common Lisp). Clojure não é Lisp, pois não usa Cons cells e não implementa o padrão ANSI. Raro é encontrar um Lisp que não tenha macros, pois esta é uma das principais vantagens.

Sim, no Lisp há liberdade para se alterar o processamento da sintaxe além de macros (veja readtable e reader macros).

Lisp deixa Ruby, Python e todas essas linguagens da moda no chinelo.

EDIT: Macros tornam possível um nível de metaprogramação inigualável em comparação com outras linguagens que não usam S expressions. Recebe-se código como dados e gera-se mais código baseado nisso. Um sistema de Annotations seria facilmente implementado ao se definir novas macros que ao serem invocadas gerassem o código para atualizar as estruturas apropriadas, de forma transparente ao desenvolvedor.

Outro exemplo, o padrão ANSI não estabelece AOP, mas seria facilmente implementável com o uso de macros. Sem a necessidade de alteração alguma na VM.

Eu geralmente não respondo troll mas este pode ser informativo…

Não. Lisp é uma linguagem inventada em 1950 que originou uma miríade de linguagens parecidas. Lisp não é (era) funcional. Common Lisp não é funcional -tem a special form set para começo de conversa. Linguagens puramente funcionais não têm estado mutável.

Essa fase mostra que você está fazendo uma confusão enorme entre Common Lisp (uma linguagem da família, assim como Scheme é outra linguagem da mesma família) e a família de linguagens Lisp. Além disso eu não falei em lugar algum que CL ou Lisp não possuem macros então seu comentário está, no mínimo, fora de contexto.

[quote=Thiagosc]
Clojure não é Lisp, pois não usa Cons cells[/quote]

Clojure é um dialeto de Lisp. Eu nunca vi nenhuma definição formal do que é ser ou não er parte da família de linguagens mas creio que isso estará muito mais ligado à s-expressions do que com a existência de con (que nada mais é do que uma função que retorna o primeiro elemento de uma lista ligada). Ainda que fosse relevante, Clojure possui os conceitos básicos de lista do lisp original (e, mais uma vez, lisp original != Common Lisp). con é first, car é rest e cons continua cons. Só o menmônico mudou, uma sequence em Clojure é análoga a uma lista em outros Lisps.

Claro que ela não implementa ANSI, quem é definido pelo padrão é Common Lisp(uma das linguagens da família) e não Lisp (a família).

E…?

Reader macros são macros, então dizer que estão “além de macros” é, no mínimo, estranho.

Uma linguagem nao é considerada funcional pela ausencia de estado mutavel, mas por permitir que programas sejam escritos de forma a retornar valor ao inves de alterar estado. A questao de ser pura ou nao sempre vai depender da linguagem oferecer um modelo pra gerenciar estado, como é o caso de transactions em clojure e monads em haskell.

Nesse sentido todo o lisp é funcional, como tb sao consideradas ouras linguagens, como Ruby e Python.

[quote=pcalcado][quote=Thiagosc]
Lisp É funcional
[/quote]

Não. Lisp é uma linguagem inventada em 1950 que originou uma miríade de linguagens parecidas. Lisp não é (era) funcional. Common Lisp não é funcional -tem a special form set para começo de conversa. Linguagens puramente funcionais não têm estado mutável.[/quote]

Não há nenhum special form “set” em Common Lisp. Existe uma “setq” para atribuição que não é tão usada assim, assim como em Scheme existem outras formas de se fazer a mesmas coisa (i.e., atribuição em escopos léxicos ou dinâmicos). Se Scheme é funcional então Lisp é funcional.

Uma linguagem puramente funcional, i.e., completamente sem efeitos colaterais e cujas funções retornam sempre os mesmos valores para os mesmos parâmetros, seria inútil. Pode ser interessante do ponto de vista acadêmico e matemático para se testar algoritmos, mas se queremos desenvolver produtos comercializáveis precisamos de efeitos colaterais. Exemplos de efeito colateral: um jogo de computador que altera o estado da memória para exibir diferentes tipos de imagens, uma aplicação que altera estruturas de dados para assim poder exibir um relatório, etc.

[quote=pcalcado]

Essa fase mostra que você está fazendo uma confusão enorme entre Common Lisp (uma linguagem da família, assim como Scheme é outra linguagem da mesma família) e a família de linguagens Lisp. Além disso eu não falei em lugar algum que CL ou Lisp não possuem macros então seu comentário está, no mínimo, fora de contexto.[/quote]

Common Lisp não é linguagem, mas sim uma especificação.

A família de linguagens Lisp conta com muitos dialetos cujas principais features foram reunidas no que se denominou “Common Lisp”. A especificação surgiu justamente para se definir um denominador comum entre os Lisps, mas nada impede que diferentes implementações tenham features extras.

Um Lisp sem CLOS, sem condition system, sem macros, sem “loop” não é Lisp, pois geralmente essas são as features mais reconhecidas por quem desenvolve nessa linguagem.

Portanto se Clojure não conta com essas coisas, não é um Lisp. Pode ser algo inspirado no Lisp, mas diferente. Assim como o criador do Ruby pode ter se inspirado em Scheme, mas Ruby jamais poderia ser considerado da família “Scheme”.

[quote=pcalcado]

[quote=Thiagosc]
Clojure não é Lisp, pois não usa Cons cells[/quote]

Clojure é um dialeto de Lisp. Eu nunca vi nenhuma definição formal do que é ser ou não er parte da família de linguagens mas creio que isso estará muito mais ligado à s-expressions do que com a existência de con (que nada mais é do que uma função que retorna o primeiro elemento de uma lista ligada). Ainda que fosse relevante, Clojure possui os conceitos básicos de lista do lisp original (e, mais uma vez, lisp original != Common Lisp). con é first, car é rest e cons continua cons. Só o menmônico mudou, uma sequence em Clojure é análoga a uma lista em outros Lisps.[/quote]

O que as pessoas se esquecem é nos anos 80 pessoas competentes já criaram o Common Lisp justamente para evitar a fragmentação do mercado. Eles pegaram aquelas features mais importantes encontradas em diversos dialetos e estabeleceram-nas como padrão.

Existem diversas coisas não especificadas (como reflection por exemplo, ou bibliotecas mais abrangentes), mas o núcleo básico é aquele. Cons cells são como o código é construído pelo leitor, o que permite fácil manipulação da estrutura pelo desenvolvedor (é uma árvore/grafo feita de singly linked lists, portanto posso facilmente adicionar novas listas em posições, extendê-la, separá-la em partes, etc). Se um vetor é usado, o que permite acesso direto pelo índice, como posso alterá-lo sem precisar realocar outro vetor de maior ou menor tamanho? Isso é um detalhe de implementação, mas esses detalhes influenciam no desenvolvimento, porque o desenvolvedor em Lisp tem acesso ao código como se fossem dados. Portanto a estrutura dos dados importa.

O Clojure é mais uma tentativa de quem não conhece Lisp de fazer um “Lisp melhor” baseado em suas próprias misconceptions, utilizando-se do nome “Lisp” para se auto-promover e para promover a sua nova linguagem.

[quote=pcalcado]

Claro que ela não implementa ANSI, quem é definido pelo padrão é Common Lisp(uma das linguagens da família) e não Lisp (a família).[/quote]

Common Lisp não é uma linguagem, mas sim uma especificação.

[quote=pcalcado]

Reader macros são macros, então dizer que estão “além de macros” é, no mínimo, estranho.[/quote]

Não, não são. Procure se informar. O Reader no Common Lisp é customizável, pode-se alterar o código que lê os caracteres ou usar novos caracteres com significados diferentes.

Se macros são tão boas assim, o que há de ruim em usá-las de forma pesada no C para “deixá-lo com a minha cara”?

Fazer um lisp melhor neste eu entendo por fazer um lisp que roda na JVM.

Mas quais seriam os equivocos na sua opiniao, principalmente em relacao ao reader nao ser tao customizavel?

[quote=cmoscoso]
Uma linguagem nao é considerada funcional pela ausencia de estado mutavel, mas por permitir que programas sejam escritos de forma a retornar valor ao inves de alterar estado. A questao de ser pura ou nao sempre vai depender da linguagem oferecer um modelo pra gerenciar estado, como é o caso de transactions em clojure e monads em haskell.

Nesse sentido todo o lisp é funcional, como tb sao consideradas ouras linguagens, como Ruby e Python.[/quote]

Eu simplifiquei a afirmação acima mas o que faz uma linguagem ser considerada funcional é o fato de que suas funções se comportam como funções matemáticas, onde não existe estado mutável e, por isso, toda a comunicação é feita retornando valores. Pela sua definição qualquer linguagem com procedimentos (procedimentos != função) é funcional.

O que Haskell usa, monads, são um “truque” (descrito elo próprio Meijer) para permitir alteração de estado. Tem uma explicação simples no wikibooks:

[quote=http://en.wikibooks.org/wiki/Programming:Haskell_monads]
Input/Output needs bind

[…]

Performing input/output in a purely functional language like Haskell has long been a fundamental problem. How to implement operations like getChar which returns the latest character that the user has typed or putChar c which prints the character c on the screen? Giving getChar the type getChar :: Char is not an option, since a pure function with no arguments must be constant. We somehow have to capture that getChar also performs the side effect of interacting with the user. Likewise, a type putChar :: Char -> () is useless since the only value this function can return has to be ().

The breakthrough came when it was realized[4] that monads, […] can be used to elegantly deal with side effects. The idea is to give our two primitive operations the types

getChar :: IO Char
putChar :: Char -> IO ()

and interpret a value of type IO a as a computation or action that performs a side effect before returning the value a. This is rather abstract, so a more concrete way is to interpret IO as a state transformer

type IO a = World -> (a, World)

that acts on and changes the “state of the world”. In other words, printing a character takes the world and returns one where the character has been printed and reading a character returns a world where the character has been read[/quote]

Não importa se é usada ou não (na verdade ela não é “tão usada” diretamente pelo programador), a existência de estado mutável faz com que ela não seja funcional. Eu não programo em Scheme para firmar nada além do que conta a documentaçào ma ara CL recomendo o ‘Practical Common Lisp’, que é uma leitura excelente e possui versão online gratuita:

Common Lisp é uma linguagem tanto quando Java é uma linguagem. Common Lisp é uma especificação tanto quanto Java é uma especificação.

O resto da sua mensagem é completamente baseado na teoria de que Common Lisp é uma espécie de unificação do Lisp. Bom, não é. Qualquer referência vai te mostrar que Common Lisp, Alisp, ELisp, Arc, Scheme e Clojure são linguagens diferentes pertencentes a mesma família então vou poupar o trabalho.

http://community.schemewiki.org/?scheme-faq-general
http://www.lispniks.com/faq/faq.html#s7q1

Acho que esse video cabe bem aqui neste post !!!

[size=20]; )[/size] hahahhhhhhaaaaa !!!

[size=12]Ruby on Rails vs Java - RailsEnvy.com Commerical[/size]
[youtube]http://www.youtube.com/watch?v=PQbuyKUaKFo&feature=related[/youtube]

Macros de C são um animal completamente diferente de Lisp. As macros de C são pouca coisa além de simples substituidores de texto burros.

Common Lisp é uma especificação, tanto que as implementações tem nomes diferentes, tais como:

http://common-lisp.net/~dlw/LispSurvey.html

  • Allegro CL
  • Armed Bear CL
  • CMU CL
  • Corman CL
  • Embedded CL
  • GNU CL
  • GNU CLISP
  • LispWorks
  • Scieneer CL
  • Steel Bank CL

Como eu disse, linguagens puramente funcionais são inúteis. Lisp é tão funcional quanto Ruby, Scheme e outras, ou seja, funcional o suficiente para ser útil.

Que bom então que você percebeu que, ao contrário do que tinha falado antes, Common Lisp não é uma unificação de Lisp e sim apenas um dos muitos dialetos derivados do Lisp original (como eles mesmo dizem no FAQ, aliás). Como você bem notou Common Lisp tem várias implementações, assim como Java.

Bom, é sua palavra contra Haskell, que é puramente funcional:

http://www.haskell.org/haskellwiki/Introduction#Does_anyone_use_functional_programming.3F

Recomendo que você revisite o tópico sobre monads para entender como uma linguagem puramente funcional (como Haskell ou Erlang) pode ser útil.

esse tipo de discussão é inútil. saber tudo de uma linguagem de programação não te deixa bom programador.

Algumas particularidades são de importantes observações, então o debate torna-se válido, o que acho que você deva estar fazendo confusão sobre programação em si, e não é isso que estamos aqui colocando aqui, e sim da aplicação sobre o melhor uso da tecnologia.

Desculpe, não quero julgar ninguém…mas só vejo discussão sobre “Lisp é funcional ou não”, isso é melhor que aquilo. Não vejo como isso pode ajudar alguém.

[quote=pcalcado][quote=Thiagosc]
Common Lisp é uma especificação, tanto que as implementações tem nomes diferentes, tais como:
[/quote]

Que bom então que você percebeu que, ao contrário do que tinha falado antes, Common Lisp não é uma unificação de Lisp e sim apenas um dos muitos dialetos derivados do Lisp original (como eles mesmo dizem no FAQ, aliás). Como você bem notou Common Lisp tem várias implementações, assim como Java.[/quote]

Common Lisp se chama “Common” justamente porque é um denominador comum entre vários Lisps. Na época em que a especificação foi feita existiam (e ainda existem) diversas implementações com diversas features diferentes e incompatíveis com as demais. A motivação do Common Lisp foi justamente estabelecer um padrão comum para o mercado Lisp.

[quote=pcalcado]

Bom, é sua palavra contra Haskell, que é puramente funcional:

http://www.haskell.org/haskellwiki/Introduction#Does_anyone_use_functional_programming.3F

Recomendo que você revisite o tópico sobre monads para entender como uma linguagem puramente funcional (como Haskell ou Erlang) pode ser útil.[/quote]

Usar Haskell como parâmetro do que é e não é funcional é como querer usar Smalltalk para delimitar o que é OO e dizer “Java não é OO”.

Java não é um OO muito católico, mas é OO. Não como implementado em outras linguagens, e não como visualizado pelos criadores do conceito de OO, mas é uma implementação de OO.

Basta entender o que significa “puramente funcional” para entender as óbvias limitações para um uso mais sério. Alguns podem ter contornado de alguma forma essas limitações, mas elas não deixaram de existir.

Curiosamente, os mesmos que acham que Lisp não é funcional, pasmém, acham que Ruby e Scheme são funcionais.