[Moscow.pm] А почему не Perl?

[Vladimir Timofeev]

2016-04-25 21:23 GMT+03:00 Alex Chistyakov <alexclear на gmail.com>:
>
>
> 2016-04-25 21:19 GMT+03:00 Vladimir Timofeev <vovkasm на gmail.com>:
>>
>> 2016-04-25 21:15 GMT+03:00 Alexander Q <qalexx на gmail.com>:
>> > Haskell! Надежность результата и лёгкость рефакторинга непревзойдённые.
>> >
>>
>> Эмм... это конечно моё личное мнение, но:
>> 1. Время компиляции, очень долгое.
>
Несчастный pandoc у меня на сервере собирается больше часа, даже C++
быстрее компилируется.

>
> У Scala, скорее всего, время компиляции будет еще хуже.
Да, простенький djinni очень долго компилируется.

> А OCaml коллеги ругают за плохое состояние библиотек.
Тоже странное... вроде haxe на нём написан, если память не изменяет.
Других реальных проектов не знаю.

Но дело не в этом, а в том, что на "динамическом нетипизированном
языке", когда менеджер прости "чуть-чуть" подкрутить "вот здесь", вы
правите тест, подкручиваете и всё, можно в продакшн. А с
функциональным языком, придётся всю модель перестраивать и упихивать
туда неидеальность реального мира.

>
>
>>
>> 2. Программистов мало.
>
>
> А на Perl много?
> Программистов вообще мало.
> Нейрохирургов тоже немного - что же теперь?
>
На Perl больше, чем на любом функциональном языке программирования.

>
>>
>> 3. По моему опыту (чтение исходников и конфигурирование xmonad), с
>> рефакторингом и пониманием кода всё плохо. А есть автоматические
>> средства рефакторинга и нормальный IDE?
>
>
> Автоматические средства рефакторинга это большое зло.
>
По моему опыту, это оптимизация моей производительности, как
программиста. А значит и результата заказчику.

>
>>
>> 4. Очень легко написать очень медленный или жадный до памяти код.
>
>
> А на PHP, допустим, разве сложно?
>
Не сложно, и на Perl не сложно )))
Как там было?
sub next_day { sleep 86400; }

Но для меня функциональный язык программирования выглядит почти как
SQL в смысле предсказания скорости и потребности в памяти. На
процедурном, же просто описывается последовательность действий, что в
большинстве случаев более предсказуемо по вычислительным затратам.

-- 
Vladimir Timofeev <vovkasm на gmail.com>