Qual é o desempenho das linguagens funcionais no Android?


10

Este é um caso especial desta questão que considero particularmente pertinente.

Estou trabalhando em um jogo para Android e planejando usar o Scala com a libgdx. Estou planejando fazer um jogo de alto desempenho, mas não necessariamente um jogo de alto desempenho. Eu vi a documentação do libgdx sobre Garbage Collection , e isso me faz pensar:

  1. A programação funcional implica muitos objetos imutáveis.
  2. Portanto, a mutação de um objeto requer a criação de um novo objeto.
  3. Assim, muitos objetos são coletados como lixo, o que prejudica o desempenho.

Esse é um problema intransponível? Existem outros problemas significativos com o estilo funcional no Android?

Respostas:


3

Você pode ficar bem com o Scala, mas realmente não deseja alocar novos objetos com muita frequência . GC sem pausas ainda não é mais que um mito (no Android), e os jogadores não gostam quando seu jogo falha. Mas isso não significa que você não pode se beneficiar do uso de linguagem mais séria - na verdade, pode. E você ficará bem com o "estilo funcional" que não ocorre no ciclo principal do jogo. Além disso, o Scala no próprio Android exige que você lute com alguns problemas extras de compilação, mas depois de aprender, é suportável. E não é muito preciso nomear o Scala como uma linguagem funcional; no entanto, existem alguns recursos relacionados à programação funcional.


2

Para jogos? Evite linguagens funcionais. Todo o seu paradigma não combina bem com os jogos. As linguagens processuais e POO se ajustam melhor às necessidades dos jogos de frequentes mudanças de estado, gerenciamento explícito de memória e recursos, abstração de dados e modelo útil em muitos locais, design orientado a dados em alguns sistemas e assim por diante. Elementos funcionais são uma coisa, uma verdadeira linguagem funcional é outra.

A linguagem funcional com melhor desempenho para Android ainda proporcionará uma experiência de desenvolvimento pior que Java ou C ++. Não porque esses idiomas sejam melhores, mas porque eles são melhores para a tarefa específica em questão. Ferramenta certa para o trabalho e tudo isso.

Isso ocorre em dispositivos móveis, PC, consoles e assim por diante. Ninguém usa linguagens funcionais para jogos. Naughty Dog usa LISP para scripts , mas não o código principal do jogo. Eles não podem. Não funcionaria se eles tentassem.

O mais próximo que a maioria das pessoas obtém são shaders, que são funcionais de alguma maneira, mas são escritos em linguagens altamente processuais como HLSL ou GLSL.


> Para jogos? Evite linguagens funcionais. Interessante que o Google AI Challenge de 2010 tenha sido vencido por um bot do Lisp. Pode não ser bom para escrever jogos, mas aparentemente é bastante útil quando se trata de jogá-los. semanticweb.com/…

Certo. Caso de uso diferente. O LISP é comum para a IA real, que tem pouco a ver com a IA do jogo. A IA do jogo tem tudo a ver com escolhas eficientes que enganam o jogador a ver a inteligência e a fazer um jogo divertido. A IA real é sobre a tomada de decisões realmente inteligentes, as opiniões humanas podem ser condenadas (as inteligentes podem e às vezes parecem idiotas, pois os observadores humanos geralmente não veem o cenário inteiro como a IA).
Sean Middleditch

2
For gaming? Avoid functional languages. Their entire paradigm fails to mesh well with games.Na verdade, eu li alguns artigos de desenvolvedores de jogos de alto nível expressando interesse em programação funcional. Havia um de Tim Sweeney scribd.com/doc/5687/… e John Carmack parece ter um interesse ativo na avaliação de linguagens funcionais e atualmente está realizando uma porta do Wolfenstein 3d em Haskell, tinyurl.com/cnzx57u
James McMahon

Você também tem citação para o Naughty Dog usando apenas o Lisp para scripts? Fiquei com a impressão de que eles tinham um dialeto interno personalizado do Lisp, com um compilador personalizado direcionado para o hardware PS2 e que eles haviam escrito a maioria das séries Jax e Dexter. EDIT: Não importa o que encontrei, gamasutra.com/view/feature/131394/… Practically all of the run-time code (approximately half a million lines of source code) was written in GOAL (Game Object Assembly Lisp)
James McMahon
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.