Примітка. Наступний пост може містити суперечливі думки, тому, будь ласка, зауважте, що вони є лише моєю думкою і не мають на меті когось образити.
Я програмую в тій чи іншій формі приблизно з 1999 року. Спочатку я використовував R, а потім, близько 2004 року, здебільшого перейшов на Python.
Для багатьох наукових застосувань, наприклад, моделювання, включаючи такі речі, як MCMC, і R, і Python, занадто повільні, і їх потрібно прискорити. Звичайний спосіб зробити це шляхом розширення на C або C ++. І для R, і для Python це те, що я зробив, використовуючи API API C з C ++ і бібліотеку Boost Python з Python.
Однак з різних причин ця комбінація не є ідеальним рішенням. Що важливо в програмуванні, особливо в алгоритмах? Виразність і швидкість, які, звичайно, пов'язані між собою. Чим виразніша мова, тим швидше в ній можна писати.
1) Що стосується виразності, то, на мою думку, ні R, ні Python не є ідеальними для написання наукових алгоритмів. Вони не тісно відображають основний алгоритм. Однак обидва вони значно кращі, ніж C ++.
2) Мені подобається писати на Python, що є приємною мовою, хоча, як зазначено вище, вона не ідеальна для алгоритмічної роботи. Однак, коли доводиться працювати з комбінацією Python / C ++ через проблеми зі швидкістю, ця суміш стає набагато менш приємною для роботи. Зазвичай відбувається те, що я спочатку пишу на Python, і коли у мене є щось, що добре працює, часто виявляю, що це занадто повільно (для певного суб'єктивного значення занадто повільно). Тоді я зіткнувся з рішенням витратити якусь необгрунтовану кількість часу на перезапис його на C ++, або змирився з повільністю. Заднім числом я часто відчуваю, що мені було б краще змиритися з повільністю, тим більше, що отримані скорочення непередбачувані. Крім того, інтерфейс Boost Python між ними є суттєвим головним болем, і наявність коду на двох дуже різних мовах, склеєних так, як це просто відволікає. Жодна критика щодо Boost Python не передбачала, це настільки потужний інтерфейс, як можна було б уявити, і він майже просто працює більшу частину часу.
Зараз, в ідеальному світі, з необмеженим часом та ресурсами, жодна з цих проблем не була б серйозною справою. Однак у наукових проектах, над якими я працював, я мав такий досвід.
Незалежно від того, чи є у мене співпрацівники над проектом, мені завжди здається, що я роблю переважну більшість обчислень. Всього в 5 важливих проектах я брав лише значну участь в одному проекті. Та одна людина зробила більше, ніж тягла свою вагу; він зробив стільки, скільки я чи більше. Однак у всіх інших випадках, включаючи проекти з декількома співробітниками, я виконав (практично) всю обчислювальну роботу. Хоча я можу сказати, що мене не благословляли найкращі співпрацівники (це здається сумішшю лінощів та некомпетентності), мені не ясно, чи може цей стан справ змінитися в майбутньому.
Обчислювальна наукова робота - це величезна кількість зусиль, і якщо я не можу змінити поведінку своїх співробітників, я можу змінити спосіб роботи. Найважливішим вдосконаленням було б швидше зробити справи. Що приводить мене до основної уваги, а саме те, що переключення мов на щось менш ортодоксальне може допомогти. Виходячи з минулих досліджень, найбільш імовірними кандидатами за порядком вірогідності є Common Lisp та Ocaml. Я про це думав роками, але останнім часом про це думав серйозніше.
Наскільки я можу сказати, мало хто використовує або CL, або Ocaml для наукових обчислень. Шукаючи цей сайт, я знайшов дві згадки про CL (один був моїм) і один на Ocaml (шахта). У мене були кілька заохочувальних контактів протягом багатьох років з людьми, що працюють на заходах. У 2008 році я натрапив на огляд книги Петра Сейбела «Практичний звичайний ліс» (яким я володію) Тамаса К. Паппа. Це привернуло мою увагу, оскільки це була одна з небагатьох згадок про наукові обчислення для Lisp, які я натрапив на мережу. Я написав Тамасу, який негайно відповів корисно і підбадьорливо. Цитувати його
Моя продуктивність програмування, ймовірно, зросла в десятки разів з Lisp, але це зайняло близько року, і я все ще вчуся (я все-таки добре працював через 2 місяці). Тож якщо ви працюєте над чимось критичним часом, відкладіть перемикач.
Вам слід подумати про запитання людей на cll, я не єдиний, хто знає про ці речі, інші роблять наукові обчислення на Lisp.
Він також має блог та сторінку GitHub .
Іншою людиною, з якою я коротко переписувався (у грудні 2006 року), була Іра Калет , яка використовувала Common Lisp у контексті променевої онкології.
Можливо, є інші, хто займається науковими обчисленнями на Ліспі, але я нікого не знаю.
Найпоширеніша проблема, з якою люди посилаються на CL - це відсутність бібліотек. Це серйозна проблема в обчисленні загального призначення, але може бути не стільки в наукових обчисленнях, особливо на основі впровадження алгоритмів. Зокрема, я можу отримати більшу частину часу основну математичну бібліотеку, включаючи функції розподілу ймовірностей, багатовимірну бібліотеку масивів та основний набір контейнерів, наприклад, карту, набір, список тощо, як це знайдено в стандартних бібліотеках C ++ та Python.
Про Ocaml я знаю навіть менше, ніж про CL, але вклав це як альтернативу. Це, мабуть, дуже швидко, має одну безкоштовну реалізацію французькими дослідниками, і, здається, є найбільш життєздатною із сімейства мов ML для наукових обчислень.
На закінчення мені цікаво, чи мають інші з цим досвід і які думки у них є, якщо такі є.
EDIT: Мене найбільше цікавить досвід з перших рук, в контексті проблем, про які я говорив вище. Наприклад, якщо ви використовували Python і C ++ (або R і C ++) і перейшли на більш незрозумілу мову, мені було б найбільше цікаво почути ваш досвід.