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.