Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
интересует скорость внедрения доработок по сравнению с питоном
Хотелось бы больше информации по поводу сложности сопровождения. Понятно, что каждый желающий в хаскель не залезет, но интересует скорость внедрения доработок по сравнению с питоном. Были ли ситуации, когда надо было делать жуткий рефакторинг?
Есть ли неудобства, связанные с отсутствием java-подобных (или хотя бы PyCharm'оподобных IDE)?
Программы на Haskell быстрее python, php, ruby (и других интерпретируемых языков). Быстрее Erlang/Java (и других vm-based языков). Обычно медленнее Си, хотя я видел несколько случаев, когда компилятор Haskell выдал результат, превосходящий сишный.Нельзя сравнивать производительность языков абстрактно, только для конкретного приложения. Для большинства приложений Haskell будет медленнее Java и почти всегда гораздо медленнее, чем оптимальный Си. У вас многопоточное сетевое приложение? Много биндингов на тот же самый Си? Тут действительно может быть побыстрее Явы.
Для любых практических применений производительности Haskell — за глаза и за уши.
Наверняка я услышу много возмущений от апологетов языка, в том числе от программистов, с которыми я работал. Но, объективная реальность: проекты на Хаскеле пишутся медленнее, чем на Питоне.Это очевидно.
Никогда не думал, что это может быть проблемой, но факт: пол-часа на сборку проекта. На весьма нехилом железе с кучей ядер и сверхбыстрой СХД снизу. Лично меня, после первых моментов гордости «ух ты, у нас наша программа аж пол-часа компилируется» это начало раздражать, потому что мелкий багфикс, и здравствуй, сцена:
С точки зрения менеджера проекта язык программирования оценивается по нескольким метрикам, совершенно отличными от программистских. Для программиста язык и его особенности — едва ли не самая важная вещь, так как именно с ним он проводит большую часть времени. Для остальных членов команды куда важнее происходящее за пределами исходного текста. Сначала это поиск библиотек и подходящих технологий, потом задачи сопровождения, мониторинга, внедрения и отладки.
В компьютерных алгоритмах используемую память обычно высчитывают в o-notation но есть важный фактор — если процессов много, и каждый из них o(1) то сколько памяти будет съедено на сервере? Те самые «плебейские константы», внезапно начинают играть роль.
sysctl: net.ipv6.conf.default.accept_dad = 1 net.ipv6.conf.default.accept_ra = 1 net.ipv6.conf.default.accept_ra_defrtr = 1 net.ipv6.conf.default.accept_ra_pinfo = 1 net.ipv6.conf.default.accept_ra_rtr_pref = 1 net.ipv6.conf.default.accept_redirects = 1
там по-человечьи всё рассказывается — что происходит и даже как это исправитьО, нет. Исправление ошибок компиляции — самый высокий барьер при освоении языка.
vector<int> vec;
vec.push_back( 10 );
vec.push_back( 20 );
for (int i : vec )
{
cout << i;
}
По поим представлениям лисп не бывает компилированный, а работает он в режиме «уютненькой лисп-машины», то есть представить на нём /bin/init в initramfs не получается.
Вы не пробовали убрать make clean из Jenkins?
По поводу количества используемой памяти. Это c учетом использования строгих вычислений там, где это нужно (например), или вы пишите на Haskell, будто он строгий язык, и не паритесь?
Почему вы предпочли persistent-mongodb написание собственной библиотеки?
Аналогичная проблема с прототипированием. Если базовый прототип на питоне появляется чуть ли не копипейстом того, что в интерактивной среде в лаборатории сделал, но в Хаскеле это обычно некое священнодействие, которое на некоторое время уходит самое в себя (типы и т. д.), и только через некоторое время приводит к результату. Если оказывается, что результат «не совсем то, о чём мечтали», то становится это понятно уже ближе к финалу, а не в начале. Таким образом, цена итерации в поиске решения увеличивается, делая весь процесс менее гибким.
Haskell в продакте: Отчёт менеджера проекта