A Ruby é uma linguagem funcional?

Se uma linguagem é ou não uma linguagem funcional não é importante. Programação funcional é uma tese, melhor explicada por Philip Wadler (a essência da programação funcional) e John Hughes (Por Que a programação funcional importa).

Uma pergunta significativa é, ' quão agradável é Ruby para alcançar a tese de programação funcional? A resposta é "muito mal".

Falei sobre isto recentemente. Aqui estão os slides.

O Ruby suporta funções de Nível Superior (Ver Array#map, injecte, & select), mas continua a ser uma linguagem imperativa e orientada a objectos.

Uma das principais características de uma linguagem funcional é evitar um estado mutável. Linguagens funcionais não têm o conceito de uma variável como você teria em Ruby, C, Java, ou qualquer outra linguagem imperativa. Outra característica chave de uma linguagem funcional é que ela se concentra em definir um programa em termos de"o que", em vez de"como". Ao programar em uma linguagem OO, nós escrevemos classes e métodos para esconder a implementação (o" como") do" o que " (o nome da classe/método), mas no final esses métodos ainda são escritos usando uma sequência de declarações. Em uma linguagem funcional, você não especifica uma sequência de execução, mesmo no nível mais baixo.

Eu submeto que o suporte,ou ter a capacidade de programar em uma linguagem em um estilo funcional não faz uma linguagem funcional.

Eu posso até escrever código Java em um estilo funcional se eu quiser ferir meus colegas, e eu mesmo alguns meses semanas depois.

Ter uma linguagem funcional não é apenas sobre o que você pode fazer, tais como funções de Ordem Superior, Funções de primeira classe e currying. É também sobre o que você não pode Fazer, Como efeitos secundários em funções puras.

Isto é importante porque é uma grande parte da razão pela qual os programas funcionais são, ou o código funcional em generel é, mais fácil de raciocinar. E quando o código é mais fácil de raciocinar, os bugs ficam mais rasos e flutuam para a superfície conceitual onde podem ser corrigidos, o que por sua vez dá menos código de bugs.

O Ruby é orientado por objectos no seu núcleo, por isso mesmo que tenha um suporte razoavelmente bom para um estilo funcional, não é em si um estilo funcional. idioma.

Essa é a minha opinião não científica.

Editar: Em retrospectiva e tendo em conta os comentários finos que recebi a esta resposta até agora, penso que a comparação orientada para o objeto versus funcional é uma comparação de maçãs e laranjas.

O verdadeiro diferenciador é o de ser dado na execução, ou não. Linguagens funcionais têm a expressão como sua construção linguística primária e a ordem de execução é muitas vezes indefinida ou definida como sendo preguiçoso. A execução rigorosa é possível, mas só é usada quando necessário. Em uma linguagem comunicativa, a execução estrita é o padrão e enquanto a execução preguiçosa é possível, muitas vezes é descuidado de fazer e pode ter resultados imprevisíveis em muitos casos de borda.

É a minha opinião não científica.

Ruby é uma linguagem multi-paradigma que suporta um estilo funcional de programação.

A Ruby terá de cumprir os seguintes requisitos para ser "verdadeiramente" funcional.

Valores imutáveis: uma vez que uma" variável " é definida, ela não pode ser alterada. Em Ruby, isso significa que você efetivamente tem que tratar variáveis como constantes. O não é totalmente suportado na linguagem, você terá que congelar cada variável manualmente.

Sem efeitos secundários: quando se passa um dado valor, uma função deve sempre devolver o mesmo resultado. Isto anda de mãos dadas com ter valores imutáveis; uma função nunca pode tomar um valor e mudá-lo, pois isso estaria causando um efeito colateral que é tangencial para retornar um resultado.

Funções de ordem superior: estas são funções que permitem funções como argumentos, ou usam funções como valor de retorno. Esta é, sem dúvida, uma das características mais críticas de qualquer linguagem funcional.

A curtição está a transformar uma função que requer múltiplas funções. argumentos em uma função que leva um argumento. Isto vai de mãos dadas com a aplicação de função parcial, que está transformando uma função multi-argumento em uma função que leva menos argumentos do que ele fez originalmente.

Recursão: looping chamando uma função de dentro de si. Quando você não tem acesso a dados mutáveis, a recursão é usada para construir e executar a construção de dados em cadeia. Isto é porque looping não é um conceito funcional, pois requer variáveis a serem passadas. em torno de armazenar o estado do loop em um determinado momento.

Preguiçoso-avaliação, ou retardado-avaliação: atrasar o processamento dos valores até o momento em que é realmente necessário. Se, por exemplo, você tiver algum código que gerou uma lista de números Fibonacci com a avaliação preguiçosa ativada, isso não seria realmente processado e calculado até que um dos valores no resultado fosse exigido por outra função, como puts.

Proposta (apenas um pensamento) Eu seria de é ótimo ter algum tipo de definição para ter uma diretiva mode para declarar arquivos com paradigma funcional, exemplo

Modo "funcional"

Ruby é uma linguagem orientada a objetos, que pode suportar outros paradigmas (funcionais, imperativos, etc). No entanto, como tudo em Ruby é um objeto, é principalmente uma linguagem OO.

Exemplo:

"Olá".reverso () = "olleh", toda cadeia é uma instância de objeto de cadeia e assim por diante.

LeiaAqui ou Aqui

Depende da sua definição de "linguagem funcional". Pessoalmente, penso que o termo é, em si mesmo, bastante problemático quando usado como um absoluto. São mais aspectos para ser uma "linguagem funcional" do que meras características da linguagem e a maioria depende de onde você está olhando. Por exemplo, a cultura em torno da língua é muito importante a este respeito. Incentiva um estilo funcional? E as bibliotecas disponíveis? Eles encorajam você a usá-los em um funcional caminho? A maioria das pessoas chamaria o esquema de uma linguagem funcional, por exemplo. Mas e o Common Lisp? Para além do problema de múltiplos nomes e da eliminação de tail-call garantida (que algumas implementações de CL também suportam, dependendo das configurações do compilador), não há muito que torne o esquema como uma linguagem mais adequada à programação funcional do que o Lisp comum, e ainda assim, a maioria dos Lisps não chamaria CL de uma linguagem funcional. Por quê? Porque a cultura que a rodeia depende fortemente das características imperativas de CL (como a macro LOOP, por exemplo, que a maioria dos Esquemadores provavelmente desaprovaria). Por outro lado, um programador C pode considerar CL uma linguagem funcional. A maioria dos códigos escritos em qualquer dialeto Lisp é certamente muito mais funcional em estilo do que o seu bloco usual de código C, afinal de contas. Da mesma forma, Scheme é uma linguagem muito imperativa em comparação com Haskell. Portanto, acho que nunca pode haver uma resposta definitiva sim/não. Se chamar uma linguagem funcional ou não depende muito do seu ponto de vista.

A Ruby também não é uma linguagem multi-paradigmática. Multi-paradigma tende a ser usado por pessoas que querem rotular sua linguagem favorita como algo que é útil em muitas áreas diferentes.

Eu descreveria Ruby é uma linguagem de script orientada a objetos. SIM, funções são objetos de primeira classe (tipo de), mas isso realmente não faz dela uma linguagem funcional. IMO, devo acrescentar.

A recursão é comum na programação funcional. Quase qualquer linguagem suporta recursão, mas algoritmos recursivos são muitas vezes ineficazes se não há nenhuma chamada de cauda otimização (TCO).

As linguagens de programação funcionais são capazes de otimizar a recursão da cauda e podem executar esse código em espaço constante. Algumas implementações em Ruby otimizam a recursão de cauda, as outras Não, mas em geral implementações em Ruby não são necessárias para fazer o TCO. Ver a Ruby actua Optimização De Chamadas?

Então, se você escrever algum estilo funcional Ruby e confiar em TCO de alguma implementação em particular, seu código pode ser muito ineficaz em outro interpretador Ruby. Acho que é por isso que Ruby não é uma linguagem funcional (nem Python).

Estritamente falando, não faz sentido descrever uma linguagem como "funcional"; a maioria das linguagens são capazes de programação funcional. Até o C++ é.

O estilo funcional é mais ou menos um subconjunto de características imperativas da linguagem, suportado com açúcar sintático e algumas optimizações de compiladores como imutabilidade e achatamento de cauda-recursão,

[[1] este último é, sem dúvida, um pormenor técnico de execução-específico e não tem nada a ver com a linguagem actual. O x64 C# 4.0 compilador faz a otimização de cauda-recursão, enquanto o x86 não faz por qualquer razão estúpida.

O açúcar sintático geralmente pode ser trabalhado em torno de alguma extensão ou outra, especialmente se a linguagem tem um pré -ompilador programável (ou seja, C's #define).

Pode ser um pouco mais significativo perguntar: "a linguagem suporta programação imperativa?", e a resposta, por exemplo com Lisp, é "não".

Por favor, dê uma olhada no início do Livro: "A-Great-Ruby-eBook". Ele discute o tópico muito específico que você está perguntando. Você pode fazer diferentes tipos de programação em Ruby. Se você quiser programar funcionalmente, você pode fazê-lo. Se queres programar de forma imperativa, podes fazê-lo. É uma questão de definição como o Ruby funcional no final é. Por favor, veja a resposta do Usuário camuflada.