Небольшой ответ на ответы на мои "наезды" на хаскель

[love5an]

Сейчас я опишу одну из главных причин по которым я недолюблюваю Ъ ф.п, и люблю CL.


Понимаете, рассуждая о развитии IT-индустрии, можно провести аналогию с классической промышленностью.

В истории классической промышленности были периоды когда всё делали единично и ручками. Я мог бы сравнить такие периоды с ранним развитием IT. Со временами расцвета UNIX или DOS. С языками вроде Си.

Потом были периоды рабовладельческого строя и раннего капитализма, когда любую задачу закидывали необходимым количеством человеков. Я бы сказал, что сейчас в IT-индустрии как раз такой подобный период, со всеми этими Java и PHP.

Но в итоге, во всех развитых странах промышленность пришла к автоматизации. И производит продукты лучше, быстрее и качественнее, чем когда-либо.

И IT-индустрию ждет когда-нибудь то же самое, то есть массовая автоматизация, программы которые пишут программы(понимаете, к чему я клоню, да?), и это неминуемо.

Я смотрю на языки функционального программирования, вроде хаскеля, как на, ну не знаю, алмазные лопаты. Выглядят красиво, конечно, прочностью обладают неслабой, но что они могут сделать против таких детищ автоматизированной промышленности, как отбойные молотки и экскаваторы?

Я не вижу, как ф.п. может помочь с если уж не уменьшением, то хотя бы со сдерживанием растущей сложности софта. Я вижу ф.п. как модный фетиш, и ничего более, и поэтому время от времени на него наезжаю, т.к. бессмысленные фетиши меня раздражают, т.к. бессмысленные фетиши это может быть круто в дизайне шмоток, например, но не в инженерии.

Кстати, скоро напишу на хабр статью о макросах и метапрограммировании в лиспе, как только продумаю её.

Comments

[grouzen.livejournal.com]

А я вот не соглашусь, потому как считаю, что изучают такие языки, для расширения знаний о других подходах к решению задач, для широты кругозора, так сказать. Правда, наверное есть и такие для кого это фетиш.

[love5an.livejournal.com]

да не, изучать то для расширения кругозора это отлично.

Но разве не видно, что сейчас о ф.п. в интернете говорят как чуть ли не о серебряной пуле? Меня вот это раздражает.

[grouzen.livejournal.com]

Я, признаться, этого не вижу. Хотя нет, бывает говорят, что мол fp хорошо паралеллится и тд, но это все какие-то не очень серьезные разговоры без каких либо серьезных докозательств.

[xeno-by.livejournal.com]

Вау, очень приятно найти единомышленника. Мне, например, очевидно, как полезно применить ФВП в своей работе. С остальным, в основном, проблемы. Аппликативные функторы, монады, комбинаторы разные - полезны, на мой взгляд, в особенных частных случаях, а так чтобы что-то еще из тру ФП настолько же изменило мой взгляд на программирование, как ФВП... Не знаю, блин.

Пусть говорят

[temiy.pip.verisignlabs.com (from livejournal.com)]

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

Пусть уверуют в функциональщину, обломаются там, потом уверуют в метапрограммирование, а потом, глядишь, и понимание придет.

[xeno-by.livejournal.com]

С нетерпением жду обещанной статьи, ибо сейчас я как раз занимаюсь реализацией макросов для Скалы: https://raw.github.com/xeno-by/kepler/master/papers/2011-10-29-RuProjectKepler.pdf. Кстати, интересно будет узнать твое мнение по поводу слайдов и проекта.

[love5an.livejournal.com]

окей, почитаю сегодня, отпишусь

[nikita-timofeev.livejournal.com]

В том-то и дело что по сравнению с Java, PHP, C*, Python Haskell и есть автоматизация. И кстати, что такое Ъ ф.п.?

[love5an.livejournal.com]

труЪ ф.п.
ну хаскель тот же

[nikita-timofeev.livejournal.com]

Haskell? Тут вот какое дело. Строгая статическая (или просто статическая, уже не помню) типизация накладывает слишком сильные ограничения на λ-исчисление и лишает его полноты. Таким образом Haskell как язык функциональный не вполне Ъ. Но никого (кроме codedot) это не волнует. Ты же в основном предъявляешь претензии к системе типов (которая к Ъ ФП имеет отношение довольно опосредованное) и к категориям и монадам (которые имеют уже в определённом смысле опосредованное отношение к самому Haskell). Так что причём тут ФП совершенно не понятно (в scheme вроде бы нет ни монад, ни статической типизации, а вполне себе функциональный язык). Разве что речь идёт о нормальном порядке вычислений…

[frotmnenogi.livejournal.com]

У кого мозги работают в итеративном варианте, а у кого в функциональном - восприятие ЯП сугубо индивидуально.

[9zloy.livejournal.com]

Кстати, итеративность человеческий мозг понимает хорошо, тогда как с рекурсией проблемы. Это связано с тем, что в реальной жизни человек почти не сталкивается с рекурсией. Такое исследование было проведено лет 20 назад, когда изучали, почему у программистов проблемы с рекурсией.

[(Anonymous)]

Аналогия разработки ПО и промышленности ложная. Потому, что вы говорите об автоматизации производства, а производство ПО и так полностью автоматизировано: изготовление - получение маш.кода, а тиражирование - простое копирование данных. Нужно проводить аналогии говоря о развитии R&D и проектирования, потому что разработка ПО только из этого и состоит, без всякого этапа "строительство" или "массовое производство". А труд инженера, проектирующего автомобили автоматизирует не конвейер, точно также и экскаватор - автоматизирует не труд архитектора.

[love5an.livejournal.com]

R&D, если проводить аналогии с промышленностью, это SA, разработка архитектуры, и да, оно тоже требует автоматизации, и сейчас ее автоматизация тоже в зачаточной стадии.

Но является ли написание кода R&D? Нет, это как раз ближе именно к строительству. Я в основном как раз об этом и говорю.

Это дело автоматизированно на текущий момент, очень и очень слабо. Хотя и имеются некоторые подвижки(Да, компиляторы ЯВУ это инструмент автоматизации. Или, например, современные IDE - рефакторинг, автодополнение, статический анализ и т.п. Кстати там вот выше сказали что хаскель вносит некоторую автоматизацию в разработку, по сравнению с java - может быть, но всё это нивелируется мощными инструментами, доступными java-разработчикам).
Но это все мелочи, по сравнению с тем, как автоматизированы современные конвейеры.

У меня один из основных источников вдохновения, в плане будущего проекта, и вообще будущей области деятельности в целом, это DMS Software Reengineering Toolkit
http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Вот, см. например видео с Google Tech Talk о ней, и вообще о компании, которая ее производит:
http://www.youtube.com/watch?v=C-_dw9iEzhA

[asvil (from livejournal.com)]

Очень согласен с разбивкой на периоды.
И не обязательно что автоматизация наступит с использованием cl, но она не избежна, просто потому, что программа пишущая программу не требует зарплаты, и не болеет, и не кочевряжится:) Это же знаменитый очевидный закон капиталистов.
Надо будет сделать такую программу пишущую программы, а потом поднять среди программистов волну с "требованием долей компаний" с целью грабить караваны^W^W стимулировать спрос со стороны капиталистов.

А потом все по новой:
придет отрасль, в которой только возможен человеческий труд,
люди туда ломанутся,
произойдет пузырь инвестиций,
более умные люди позже начнут автоматизировать
капиталисты всех заменят роботами.

вы будете смьеяться...

[(Anonymous)]

но сейчас в "развитых капиталистических странах" в ряде случаешь отходят от автоматизации, и возвращают людей за конвейер. Автоматы ломаются, их обслуживание далеко не дешево, отсутствует гибкость в мощностях, как при применении "тупой" рабочей силы.

Re: вы будете смьеяться...

[tomcatkins.livejournal.com]

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

То есть индустрии люди выгоднее роботов, но именно благодаря роботам.

Поэтому, видимо, декларативное/функциональное программирование и существует в режиме "ни жив ни мертв" - как proof of concept что незаменимых нет. И как запасной вариант.

[(Anonymous)]

Так неумно, что я настроил фильтр в своём ридере.

[love5an.livejournal.com]

Писать об этом мне совершенно необязательно - мне всё-равно.

[usovalx.livejournal.com]

Хорошо, а если посмотреть на это с другой стороны?

Как уже заметили написание кода ближе к инженерной деятельности чем к машиностроению. И если посмотреть с этой стороны то динамические системы как раз больше похожи на кустарную разработку: тут скотчем примотали, там тестом подпёрли ;)

[love5an.livejournal.com]

>И если посмотреть с этой стороны то динамические системы как раз больше похожи на кустарную разработку: тут скотчем примотали, там тестом подпёрли

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

Все сложные системы превращаются в итоге в склеенную соплями кучу с миллионом подпорок.
С этом только автоматизация(метапрограммирование) может справиться в какой-то мере.

[love5an.livejournal.com]

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

Применять ф.п. вместо инструментов, которые во втором подходе используются - тоже не получится, потому что ф. языки банально на порядок сложнее всяких Java и PHP.

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

[kika.livejournal.com]

Этот наезд на ФП семантически эквивалентен наезду на Лисп за то что в нем много скобочек (что, вообще говоря, правда, их там на самом деле много).

[max630.livejournal.com]

Я по-прежнему не верю что напрямую писать макросы может быть продуктивно. Необходимы фичи на более высоком уровне, как следует продуманные и реализванные.

Ленивое применение - как раз одна из таких фич. Которая, кстати, покрывает 90% макросов, да?

Статические типы - вторая. Большинство кода можно типизировать статически. Кстати, по мере того как ты runtime-генерацию S-выражений заменяешь на более структурированные элементы - это можно сделать во всё больших местах. Как обходить места где простые системы типов не применимы - можно обсуждать. Haskell предлагает какие-то решения. Тебе они могут не нравиться, но если вместо ты предлагаешь выкинуть типы совсем - многие тебя не поймут.

[(Anonymous)]

> Ленивое применение - как раз одна из таких фич. Которая, кстати, покрывает 90% макросов, да?

Она не покрывает даже 1% макросов, да.

> Статические типы - вторая. Большинство кода можно типизировать статически.

Можно много чего. Вопрос - нужно ли? Чекер может верифицировать программу и доказать ее соответствие спецификациям, но спецификации всегда не полны. Если же спецификации хотя бы близки к полноте, то сложность спецификаций приближается к сложности программного кода - как следствие, в спецификациях будет не меньше ошибок, чем в программном коде. И встает вопрос о том, чтобы верифицировать спецификации - то есть писать спецификации спецификаций. Здесь я вижу один путь - доказывать о программе какие-то отдельные интересные факты. То есть - динамическая типизация с опциональной управляемой статикой. Полная же статика - это как колоть орехи микроскопом. Причем тогда, когда микроскопа нет - то есть мы должны для начала этот микроскоп придумать, спроектировать, произвести - и только потом расколоть наш орех.