суббота, 29 января 2011 г.

[prog.thoughs] Некоторое послесловие к затянувшемуся LOR-овскому спору

LOR-овский флейм, о котором я писал в начале недели (и не только писал, но и активно поддерживал), все еще развивается. Временами, обдумывая приводящиеся там аргументы, а так же поведение его участников, я ловлю себя на следующих мыслях.


Во-первых, чем больше функциональное программирование (ФП) проникает в массы, тем больше я склоняюсь к тому, что ФП – это только манипуляция функциями без побочных эффектов. Другие практически используемые вещи из функциональных языков – в первую очередь это алгебраические типы данных (АлгТД) и паттерн-матчинг – вполне могут себя отлично чувствовать в обычных императивных языках. Поэтому не очень понятно, почему сейчас они считаются характерной чертой ФП.

Кстати говоря, уже можно наблюдать, как потихоньку императивные языки обзаводятся элементами из функциональных языков: лямбда функции в C# и C++0x, паттерн-матчинг и case-классы в гибридной Scala. Обобщенное программирование в C++, которое давным-давно существует и активно используется, так же давно переносит элементы функционального программирования в насквозь императивный, да еще и низкоуровневый язык.

C++, к тому же, является хорошим примером самого что ни есть мейнстримового и промышленного языка программирования, в котором хоть какое-то внимание уделено иммутабельности и средствам контроля за побочными эффектами – это я сейчас о const-ах и const-методах. По крайней мере, по сравнению с теми же Java, C#, Python, Ruby и даже Scala, в языке есть хоть какие-то средства контроля за модификацией состояния. А на примере D можно увидеть, как эти средства получают дальнейшее развитие – вплоть до чистых функций без побочных эффектов.

Так что я надеюсь, что в дальнейшем мейнстримовые языки (в первую очередь, наверное, C#, а так же молодые конкуренты C++, вроде Go и D) будут обзаводиться поддержкой паттерн-матчинга и каких-то более-менее мощных (по сравнению с Паскалевскими записями с вариантами) форм АлгТД. И эти средства найдут такое же широкое применение в обычных императивных языках, как теперешние switch/case (которые, надо заметить, тоже не сразу появились).

Не знаю, правда, как быстро до мейнстрима дойдут более хардкорные штуки вроде теории типов. Дойдут, наверное, в какой-то упрощенной форме лет через -надцать.


Во-вторых, проникновение ФП в широкие массы очень сильно напоминает мне аналогичное проникновение ООП, которое в своей деревне мне довелось наблюдать где-то начиная с 1994-го года, а на Западе он начался намного раньше.

По началу ООП применяло очень небольшой количество продвинутых и “рубивших фишку” программистов. Они более-менее успешно справлялись со сложными задачами и умудрялись применять ООП грамотно и по делу. Может быть потому, что у многих тогда был большой опыт обычного процедурного/структурного программирования (а у некоторых и логического, поскольку в те годы Пролог был сильно популярен на просторах СНГ). А так же чувство меры, чтобы не плести ОО-иерархии классов там, где можно было написать несколько подпрограмм.

Но потом к этому делу подключились более широкие массы. В основном, молодежь, вроде меня. У нас не было опыта в прошлом, и мы нисколько не задумывались о том, насколько новой или не новой вещью является ООП. Багаж знаний был нулевым, поэтому нам было без разницы, изучать ли ООП, или структурное/модульное программирование.

Как следствие, с ООП случился явный over-use. Наследование и полиморфизм пихали направо и налево. Если что-то нужно было написать, то писали это сразу на объектах, чтобы затем расхлебывать последствия. Даже лозунг тогда ходил – “В мире нет ничего, кроме объектов!” :) Как апупеоз этого лозунга – языки программирования Eiffel и Java, в которых даже невозможно было сделать простую свободную функцию – ее нужно было обязательно запихнуть в какой-нибудь класс.

Что случилось потом? Толстенные толмуды о том, что такое ООП и как его готовить. Паттерны проектирования. Огромное количество статей на тему ООП. Специализированные конференции и сайты. Километровые флеймы на профильных ресурсах о том, кто правильнее понимает и применяет ООП, православно ли множественное наследование и еретичны ли ромбовидные иерархии классов. После чего изрядное количество публикаций о провалах при использовании ООП, а так же серьезная критика в перемешку с жестокими личными разочарованиями. Даже ярлык начал ходить -- “ООП головного мозга” :) В итоге закономерное понимание того, что OO is not silver bullet :)

Сейчас, видимо, тоже самое начинает происходить с ФП. Еще несколько лет назад его тихонько и более-менее успешно применяло некоторое количество продвинутых и “рубивших фишку” программистов. Может быть потому, что у многих из них тогда был большой опыт обычного ООП программирования, а так же серьезная математическая подготовка. И чувство меры, чтобы не плести кружева из функций высшего порядка и простыней из паттерн-матчинга.

Но потом к этому делу подключились более широкие массы. В основном, молодежь, у которой нет большого опыта в прошлом, и которая нисколько не задумывается о том, насколько новой или не новой вещью является ФП… Далее по тексту :)

Так что лично я начинаю готовиться к эпохе FP over use, с появлением толстенных толмудов, паттернов проектирования, публикаций и многокилометровых флеймов между неофитами о православности монад и еретичности побочных эффектов :)

5 комментариев:

Rustam комментирует...

Да все идет к тому что будут рулить гибриды, а чистые ФЯ как и чистые ООЯ останутся на обочине.

Ну и насчет паттерн матчинга (ML разновидности) в отличии от switch он по сути легко и полностью заменяет if поэтому и начинается вымывание if из кода, я например по себе это замечаю.

Rustam комментирует...

И вообще там на ЛОРе я не вижу спора ФЯ vs ОО там по большей части идет спор о стилях написания кода, все это конечно важно, но гавнокодность от стиля вообще не зависит, вот сейчас по работе читаю исходники VCL ну чистейший говнокод (главное заразный сам начинаю так писать :( ), километровые функции, не единого комментария, юнит тесты отсутствуют как класс, но ошибок по большему счету для такой достаточно крупной библиотеки и такого стиля очень мало. А раньше приходилось видеть почти идеально расписанные библиотеки которые не работали :)

eao197 комментирует...

@Rustam:

>вот сейчас по работе читаю исходники VCL ну чистейший говнокод (главное заразный сам начинаю так писать :( ), километровые функции, не единого комментария, юнит тесты отсутствуют как класс, но ошибок по большему счету для такой достаточно крупной библиотеки и такого стиля очень мало.

В фотографии этот феномен особенно хорошо заметен: есть два слабопересекающихся множества фотографов -- первые много знают о фотографии, вторые делают потрясающие снимки :)

Так же и в программировании -- отличные программы зачастую пишут далеко не самые блестящие программисты.

PS. VCL -- это борландовский Visual Control Library?

Rustam комментирует...

Это да "теоретики" и "практики" везде есть :)

VCL да бывший борландовский. Вообще паскаль все-таки очень читабелен, близко к питону, я вот на нем ничего серьезного никогда ни писал, а читаю без проблем, притом не тривиальный код.

eao197 комментирует...

@Rustam:

я на Паскале, по сути, и научился программировать. А на книжку по Module-2 в свое время чуть ли не половину стипендии отдал :)

Поэтому с тех пор очень положительно отношусь к языкам с Паскале-подобным синтаксисом вроде Ruby или Eiffel-я.