Nota: o post a seguir pode incluir opiniões controversas; portanto, observe que são apenas minhas opiniões e não pretendem ofender ninguém.
Estou programando de alguma forma ou de outra desde cerca de 1999. Inicialmente, usei o R e depois, por volta de 2004, mudei principalmente para o Python.
Para muitas aplicações científicas, por exemplo, a simulação, incluindo MCMC, R e Python são muito lentos e precisam ser acelerados. A maneira usual de fazer isso é estendendo-se com C ou C ++. Para R e Python, foi o que eu fiz, usando a API C de R com C ++ e a biblioteca Boost Python com Python.
No entanto, por várias razões, essa combinação não é a solução ideal. O que é importante na programação, particularmente algoritmos? Expressividade e velocidade, obviamente relacionadas. Quanto mais expressiva uma linguagem, mais rápido ela pode escrever nela.
1) No que diz respeito à expressividade, nem R nem Python são realmente ideais para escrever algoritmos científicos na minha opinião. Eles não são mapeados de perto para o algoritmo subjacente. No entanto, ambos são consideravelmente melhores que o C ++.
2) Gosto de escrever em Python, que é uma linguagem agradável, embora, como observado acima, não seja ideal para trabalhos algorítmicos. No entanto, quando é necessário trabalhar com uma combinação Python / C ++ devido a problemas de velocidade, esse mix se torna consideravelmente menos agradável de se trabalhar. O que geralmente acontece é que primeiro escrevo em Python e, quando tenho algo que está funcionando bem, geralmente descubro que é muito lento (para algum valor subjetivo muito lento). Enfrento então a decisão de gastar algum tempo irracional reescrevendo-o em C ++ ou suportando a lentidão. Em retrospectiva, muitas vezes sinto que seria melhor aguentar a lentidão, especialmente porque as acelerações obtidas são imprevisíveis. Além disso, a interface do Boost Python entre os dois é uma dor de cabeça significativa na manutenção, e ter código em dois idiomas muito diferentes colados como esse é apenas uma distração. Nenhuma crítica ao Boost Python foi planejada, é uma interface tão poderosa quanto se poderia imaginar e funciona praticamente a maior parte do tempo.
Agora, em um mundo ideal, com tempo e recursos ilimitados, nenhum desses problemas seria um grande negócio. No entanto, em projetos científicos em que trabalhei, tive a seguinte experiência.
Se eu tenho ou não colaboradores no projeto, sempre pareço terminar fazendo a grande maioria da computação. Em um total de 5 projetos significativos, eu só tive participação substancial de uma pessoa em um projeto. Aquela pessoa fez mais do que puxar seu peso; ele fez tanto quanto eu ou mais. No entanto, em todos os outros casos, incluindo projetos com vários colaboradores, eu fiz (virtualmente) todo o trabalho computacional. Embora eu possa dizer que não fui abençoado com os melhores colaboradores (parece ser uma mistura de preguiça e incompetência), não está claro para mim se é provável que esse estado de coisas mude no futuro.
O trabalho científico computacional é uma enorme quantidade de esforço e, se não consigo mudar a forma como meus colaboradores se comportam, posso mudar a maneira como trabalho. A melhoria mais importante seria fazer as coisas mais rapidamente. O que me leva à consideração principal aqui: mudar a linguagem para algo menos ortodoxo pode ajudar. Com base em pesquisas anteriores, os candidatos mais prováveis em ordem de probabilidade são Common Lisp e Ocaml. Estou pensando nisso há anos, mas recentemente tenho pensado nisso mais a sério.
Até onde eu sei, poucas pessoas usam CL ou Ocaml para computação científica. Ao pesquisar neste site, encontrei duas referências ao CL (uma era minha) e uma a Ocaml (minha). Ao longo dos anos, tive alguns contatos encorajadores com pessoas aventureiras que trabalham à margem. Em 2008, me deparei com uma resenha do livro "Practical Common Lisp", de Peter Seibel (de minha autoria), de Tamas K. Papp. Isso me chamou a atenção, pois era uma das poucas menções à computação científica para Lisp que eu havia encontrado na rede. Escrevi para Tamas, que respondeu imediatamente de maneira prestativa e encorajadora. Para citá-lo
Minha produtividade de programação provavelmente aumentou dez vezes com o Lisp, mas isso levou cerca de um ano para acontecer e eu ainda estou aprendendo (eu estava indo muito bem depois de dois meses). Portanto, se você estiver trabalhando em algo crítico no tempo, adie a opção.
Você deve perguntar ao pessoal do cll, não sou o único que sabe sobre essas coisas, outros fazem computação científica no Lisp.
Ele também tem um blog e uma página no GitHub .
Outra pessoa com quem me correspondi brevemente (em dezembro de 2006) foi Ira Kalet , que usou o Common Lisp no contexto da oncologia por radiação.
Talvez existam outros que fazem computação científica no Lisp, mas eu não conheço ninguém.
O problema mais comum que as pessoas citam com CL é a falta de bibliotecas. Esse é um problema grave na computação de uso geral, mas pode não ser tanto na computação científica, principalmente nas implementações básicas de algoritmos. Especificamente, posso entender a maior parte do tempo com uma biblioteca matemática básica, incluindo funções de distribuição de probabilidade, uma biblioteca de matriz multidimensional e um conjunto básico de contêineres, como mapa, conjunto, lista etc., como encontrado nas bibliotecas padrão C ++ e Python.
Eu sei menos sobre Ocaml do que sobre CL, mas joguei isso como uma alternativa. É supostamente muito rápido, possui uma implementação gratuita por pesquisadores franceses e parece ser a mais viável da família de idiomas ML para computação científica.
Para concluir, estou me perguntando se outros têm experiência com isso e que pensamentos têm, se houver.
EDIT: Estou interessado principalmente na experiência em primeira mão, no contexto dos problemas que discuti acima. Por exemplo, se você costumava usar Python e C ++ (ou R e C ++) e se mudava para uma linguagem mais obscura, eu ficaria mais interessado em saber sobre suas experiências.
Respostas:
Nós desenvolvemos Julia para exatamente as razões levantadas. Não havia apenas uma linguagem de computação científica de alto nível que também apresentasse um desempenho suficientemente bom, pois você não precisava reescrever partes do seu código no C / Fortran. O design de julia tem uma boa influência de lisp, então você pode achar que gosta, enquanto seus colaboradores podem tratá-lo como um matlab ou R se eles não se importam com as partes funcionais. A desvantagem é que o idioma é novo e ainda não possui todas as bibliotecas necessárias para o uso diário.
Mark, gostaria de adicionar julia ao seu benchmark para ver como nos saímos. Entre na nossa lista de e-mails e deixe-nos saber o que você gostaria de ver na julia para que seja mais útil para você.
fonte
A velocidade, o tamanho e a confiabilidade das linguagens de programação fazem um bom trabalho ao abordar muitas preocupações diferentes expressas na sua "pergunta". Ele compara a velocidade e o tamanho da base de código de várias implementações dos mesmos benchmarks em 33 idiomas!
Eu me tornei um amante de Python principalmente porque é muito mais comum ter tempo de computação em excesso do que tempo para programar. Estou mais do que disposto a desperdiçar ciclos de CPU do que sacrificar uma fatia de tempo que poderia ser dedicada a algo mais interessante.
Além disso, +1 em Julia. Eu acho que posso mudar para ele quando se tornar um pouco mais estável e com amplo suporte, ou seja, quando módulos padrão forem agrupados para o trabalho que eu gosto de fazer.
fonte
Para aplicações científicas do OCaml, consulte, por exemplo
Para Lisp na ciência, veja por exemplo
Estou certo de que existem muitas outras referências. No entanto, não posso citar nenhum projeto de pesquisa importante em que o trabalho computacional foi realizado no OCaml ou no Lisp. Escolher um deles significa trabalhar em relativo isolamento.
Talvez você também esteja interessado em Julia , uma nova linguagem para computação científica atualmente em desenvolvimento, com claras influências do Lisp.
fonte