Quais são as maiores diferenças entre F # e Scala?

59

F # e Scala são linguagens de programação funcional que não forçam o desenvolvedor a usar apenas tipos de dados imutáveis. Ambos têm suporte para objetos, podem usar bibliotecas escritas em outros idiomas e executadas em uma máquina virtual. Ambos os idiomas parecem basear-se no ML.

Quais são as maiores diferenças entre o F # e o Scala, apesar de o F # ter sido projetado para .NET e o Scala para a plataforma Java?

programming-languages comparison functional-programming f# scala Jonas
fonte
2
Se você pode votar e achar que essa é uma pergunta útil ou que possui respostas úteis abaixo, vote. Os sites StackExchange precisam de votos para criar uma boa comunidade. Você pode dar 30 votos por dia, não os desperdice. Especialmente usuários com alta reputação e baixa contagem de votos dados, leia isto: meta.programmers.stackexchange.com/questions/393/…
Maniero
functional programming langugages that don't force the developer to only use immutable datatypes- existe algum, exceto talvez línguas de brinquedo?
Ingo
11
@ Ingo, se você acha que ML e Ocaml não se qualificam como linguagens de programação funcional porque permitem mutabilidade, talvez você deva ajustar sua definição!
Frank Shearar
3
+ Frank, você deve ter entendido mal: quero dizer, até Haskell tem tipos de dados mutáveis. Portanto, eu ainda gostaria de saber quais idiomas o @Jonas talvez tenha em mente que forçariam um a usar apenas tipos de dados imutáveis?
Ingo

Respostas:

61

Principais diferenças:

  • Scala e F # combinam programação imperativa para OO e programação funcional em um idioma. Sua abordagem para a unificação de paradigmas é muito diferente. Scala tenta fundir os dois paradigmas em um (chamamos de paradigma funcional do objeto), enquanto o F # fornece os dois paradigmas lado a lado. Por exemplo, tipos de dados algébricos em F # são construções puramente funcionais, sem OO'ness, enquanto ADTs em Scala ainda são classes e objetos regulares. (Nota: No processo de compilação para o bytecode do CLR, até os ADTs do F # se tornam classes e objetos, mas não são visíveis para o programador do F # no nível de origem.

  • O F # possui inferência completa do tipo Hindley-Milner. Scala tem inferência parcial de tipo. O suporte para subtipagem e OO puro torna impossível a inferência de tipo de estilo Hindley-Milner para Scala.

  • Scala é uma linguagem muito mais minimalista que o F #. Scala tem um conjunto ortogonal muito pequeno de construções que são reutilizadas em todo o idioma. O F # parece introduzir uma nova sintaxe para cada pequena coisa, tornando-se muito pesado em relação à Scala. (Scala tem 40 palavras-chave, enquanto F # tem 97. Isso deve lhe dizer uma coisa. :-)

  • Sendo o F # uma linguagem da Microsoft, possui um excelente suporte IDE na forma de Visual Studio. As coisas não são tão boas no lado do Scala. O plug-in do Eclipse ainda não está bom. O mesmo vale para o plug-in do NetBeans. O IDEA parece ser a sua melhor aposta no momento, embora nem sequer se aproxime do que você obtém com os Java IDEs. (Para os fãs do Emacs, existe o ENSIME. Ouvi muitas coisas boas sobre este pacote, mas ainda não o experimentei.)

  • O Scala possui um sistema do tipo muito mais poderoso (e complexo) que o F #.

Outras diferenças:

  • As funções F # são exibidas por padrão. Em Scala, o curry está disponível, mas não é usado com muita frequência.

  • A sintaxe do Scala é uma mistura da linguagem Java, Standard ML, Haskell, Erlang e muitas outras linguagens. A sintaxe do F # é inspirada nos de OCaml, C # e Haskell.

  • O Scala suporta tipos e classes superiores. F # não.

  • Scala é muito mais acessível a DSLs que F #.

PS: Eu amo Scala e F #, e espero que eles se tornem idiomas predominantes de suas respectivas plataformas no futuro. :-)

desaparecido
fonte
6
Essa resposta perpetua vários conceitos errôneos. Vou enumerar cada um por sua vez. Você disse que "tipos de dados algébricos em F # são construções puramente funcionais sem OO'ness neles", mas tipos de dados algébricos em F # são apenas classe e, em particular, eles suportam o aumento com instância e membros estáticos / propriedades OO.
quer
7
Você diz "Scala tenta fundir os dois paradigmas em um (nós chamamos de paradigma funcional do objeto)", mas o Scala não possui eliminação geral de chamadas de cauda e, consequentemente, qualquer código funcional não trivial (incluindo quase todos os idiomas funcionais convencionais, como passagem de continuação). estilo e desatando o nó recursivo) são propensos a empilhar transbordamentos no Scala e, portanto, são praticamente inúteis.
quer
4
@ JonHarrop: Scala não trata ADTs especialmente. Eles são tratados como aulas regulares. Lá Some(2)em Scala tem tipo Some[Int]e não Option[Int]qual é IMO indesejável. Por outro lado, o F # possui uma sintaxe e um tratamento especiais para ADTs e, portanto, pode inferir corretamente o tipo de Some 2as int option. Portanto, a codificação F # de ADTs é melhor que a de Scala (IMO, é claro). Não tentei sugerir que é inferior e lamento se isso aconteceu dessa maneira.
missingfaktor
9
@ JonHarrop: A falta de TCO na JVM não incomodou muitos desenvolvedores Scala. Confie em mim, não é um problema tão grande quanto parece. Na maioria das vezes, estamos usando funções de ordem superior, em vez de recursão explícita. E a maioria das funções de ordem superior no Scala são implementadas em termos de loops, e não de recursão. Portanto, a falta de TCO se torna quase imaterial.
missingfaktor
8
Eu sinto que toda essa resposta é um pouco tendenciosa para Scala. Por exemplo, Scala é uma linguagem muito mais minimalista que o F #, que parece contrariar seu argumento / ponto posterior de um sistema de tipos mais complexo.
Adam Gent
9
  • O F # é determinado em aspectos funcionais, enquanto o scala é baseado em aspectos orientados a objetos.
  • O F # tem melhor suporte a IDE com o Visual studio, enquanto o plug-in eclipse do Scala é para IDE de código aberto e comparativamente mais lento.
  • O F #, sendo mais parecido com o ML do que o Scala, tem uma sensação lambda mínima de cálculo da mesma forma que o OCaml, o ML Padrão e o Scheme. F # parece ser uma linguagem consideravelmente mais simples.
Ayush Goyal
fonte
4
"F # parece ser uma linguagem consideravelmente mais simples." << Não, não é. É muito maior que Scala. Eu deveria escrever um artigo sobre esse assunto há algum tempo.
precisa saber é o seguinte
4
"Scala é baseado em aspectos orientados a objetos." << Errado. Scala tenta fundir OOP E programação funcional. Pessoalmente, raramente uso seus recursos orientados a objetos. A maior parte do que fazemos é puramente funcional.
precisa saber é o seguinte
@missingfaktor: "É muito maior que o Scala". Qual o tamanho das gramáticas?
Jon Harrop 4/11
11
Não sei se as coisas mudaram. Scala nas rochas IntelliJ, com o plugin ainda de código aberto.
Colliot
0

Um ponto pequeno, porém importante, é a licença: Scala é BSD (praticamente a licença de software livre mais permissiva que existe), o F # costumava ser "contrato de licença de fonte compartilhada de pesquisa da Microsoft", mas hoje é um produto comercial (de acordo com @Lorenzo abaixo, embora não tenha conseguido encontrar contratos de licença mais específicos em nenhum lugar).

Joonas Pulakka
fonte
3
Na verdade, o F # agora é de código aberto e o Scala agora é um produto comercial da empresa Scala Solutions, de Martin Odersky.
quer
4
@ Jon Harrop: Acho que a Scala Solutions está vendendo apenas ferramentas, serviços, treinamento etc. relacionados à Scala. A linguagem em si ainda parece estar sob a licença BSD.
Joonas Pulakka
2
@Joonas: Exatamente, o mesmo vale para F #.
quer
5
@ JonHarrop: Scala continua sendo de código aberto. Por favor, não espalhe informações erradas.
precisa saber é o seguinte
2
@missingfaktor: Eu não disse que o Scala era de código fechado.
21912 Jon Jonop