Сначала в общем, потом разжевал всё как для младенца.
Да, вы хорошо разжевали свой fail с ерлангом и фп.
По вашим комментам видно, что вы имеете мало опыта в разработке и много опыта в болтологии. Ещё раз повторю — вы троль, да ещё и опасный, так как располагаете большим количеством свободного времени.
Вы в третий раз проявляете чудеса телепатии. Может отбросите эзотерику и займетесь самообразованием?
Я рассказал о своём конкретном опыте, вы же теоритизируете в вакууме.
Значит, ваши обобщенные рассуждения в первых комментариях были недоразумением? Ок.
Думаю для молодых разработчиков полезнее практический опыт.
То, что вы описали, не может являться для кого бы то ни было «практическим опытом». По вашему описанию с побочными эффектами и прочим видно, что вы не хотите мучиться, изучать, менять свое императивное мышление. Напротив, в вас родилась, судя по слову «бесит», ненависть к ФП и ерлангу в частности. Плохой пример для подражания.
Вы очевидно теоретик, и с практикой редко сталкиваетесь, так же очевидно что вы пишете код в одиночку а не работаете с большой командой командой
Чудеса да и только.
Тут спорить бесполезно делайте как вам нравится
Тут читают молодые люди, которые «находятся в поиске». И такие посты как ваш оригинальный комментарий могут их смутить (по себе помню). Поэтому имхо спорить с подобным полезно.
я сказал что бесит меня в ФП подходе, постарался выделить не специфичные для эрланга моменты.
А вы не думали, что это специфичные проблемы связаны только с вами, вашим знанием ФП и вашим опытом использования ерланга? Думаю, некорректно на таком материале делать обобщенные утверждения про все ФП.
Не вижу смысла копипастить сюда километровый лог, неужели это не очевидно? Одно дело, если вы видите в стэктрейсе полную картину происходящего, и совсем другое если некоторые кадры отсутствуют из-за оптимизации.
Значит, у вас были проблемы со стэктрейсом в ерланге? Т.е. это какая-то другая конкретная проблема вас и ерланга, не имеющая отношения ни к ФП вообще, ни к другим функциональным языкам? А проблему вы решили? Спрашивали на stackoverflow, например? Что вам ответили?
Геморой с сайд-эффектами
Можете немного поподробнее?
какие подробности вас интересуют? Сайд-эфекты в ФП один большой геморой, если их количество велико, то проще задачу реализовать в императивном стиле, это более естественно, иначе вы лишаетесь многих приимуществ функционального подхода.
Т.е. в вашей программе на ерланге вы используете много мест с сайд эффектами, что привело к тому, что вам неудобно на этом языке контролировать сложность программы? При чем тут ФП?
Даже если вы пишете код в одиночку:
— вы не застрахованы от ошибок
— кода становится больше, энтропия возрастает
— вы многое можете забыть в коде который вы писали полгода назад
Ну а в реальной жизни код пишется командой и энтропия ещё сильнее возрастает.
Я не понял, к чему это. Пропущу.
А вообще ни кто не застрахован от ошибок, но зависший сервер — это слишком высокая цена, в питоне например вам надо сиииильно постараться чтобы сделать такое,
Я не понял как взаимосвязана страховка от ошибок и питон.
Кроме того, понять из-за чего именно и в какой момент произошло зацыкливание, не самая тривиальная задача.
В смыле, для вас рекурсивные алгоритмы являются проблемой и неискоренимой причиной ошибок?
P.S. не думал что мой коммент вызовет столько вопросов.
И не зря вызвало. Как выясняется, ваш оригинальный пост был рефлексией, отражающей ваши вполне конкретные и частные проблемы с ерлангом и рекурсией и не распространяются на ФП в общем случае.
ФП идеально подходит для одних задач ПП — для других, есть задачи, которые можно реализовать и так и так, с определёнными оговорками. Нет универсального подхода для всего! Все же снают что у серебрянных пуль начинка чаще всего, пардон, из говна. У любого программиста должны быть на вообружении оба подхода и он должен уметь грамотно применять их для решения конкретных задач вот и всё.
Без обид. Вы не можете этого утверждать, т.к. для того, чтобы сравнивать, необходимо сначала изучить мат.часть, хорошо знать и тот и этот подход.
Вы видимо издеваетесь))) Я и не говорю что разницы нет, и верить мне вам не за чем так как я использую питон и эрланг в продакшене и разница для меня очевидна =).
Нисколько. Можете прочитать вместо «разделять» «противопоставлять».
А вы, зачем-то копипастите текст из википедии))
Сам набрал. Никуда при этом не подглядывал. Тема то старая.
1. Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
2. Геморой с сайд-эффектами
3. Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
4. Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Ответил выше.
Если этого вам мало могу продолжить уже конкретно по Эрлангу.
Не писал на нем ничего. Но надеюсь, вы сможете сформулировать проблему безотносительно к конкретному фп языку. Или у вас именно ерланг вызвал проблемы?
Спрашиваю не просто так, а действительно интересно.
Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
Не замечал ни в Common LIsp-е, ни в clojure. Можете привести пример?
Геморой с сайд-эффектами
Можете немного поподробнее?
Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
Это согласен. Просто нужно учитывать, что при использовании фп языка меняется не только синтаксис, но и парадигма программирования. В этом то и смысл.
Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Что значит «рекурсия вышла из-под контроля »? Это же ваш код — как написали, так и работает. При чем тут фп?
Выхода два: или пользоваться ОО-языком для решения задач с большим количеством сайд-эфектов, или изобретать монады
Ваш вывод неверен. Вы ошибаетесь, разделяя программирование с побочными эффектами и функциональное программирование. ФП и побочные эффекты — вещи перпендикулярные. Есть отдельное понятие pure functions, с помощью которых реализуется программирование без побочных эффектов. Например, в хаскеле соблюдается «чистота» (монады нужны), а в той же схеме или clojure — нет (необходимости монад нет).
Вы, как и автор статьи путаете мягкое с холодным.
Нельзя противопоставлять процедурное и функционально программирование. Это просто два разных подхода для решения насущных задач.
Разделять процедурное программирование и фп можно и нужно. Различие между данными подходами колоссальные. ПП это императивное программирование, где весь код представляет собой пошаговое изменение глобального/локального состояния программы. ФП — это композиционное/декларативное программирование с помощью функций (с побочным эффектом или нет). ПП это высокоуровневое продолжение ассемблера. ФП идет из математики. Эффективное ФП возможно благодаря таким свойствам ФЯ, как функции высокого порядка/функции — граждане первого класса, рекурсия (с оптимизацией хвостовой рекурсии), замыкание. Поверьте, разница между ФП и ПП подходами к решению просто громадная.
Однако забывают про ограничения ФП. Например в реальном мире есть монитор и принтер, которые являются «разделяемыми ресурсами» как и воздух и земля по который мы ходим. И вот тут начинаются проблемы
В тексте есть вывод про ограничения, но нет аргументов и примеров.
DSL ничем не лучше, чем ClojureQL и подобные библиотеки.
Нам нужен был язык запросов, работающий именно с нашими генерируемыми данными (таблицы, поля). Также хотелось, чтобы было реализовано одно из наших требований: получение данных из связанных по внешним ключам таблиц (в orm-е джавы это было очень удобно).
Да, в select-e sql полностью генерируется и скармливается соответствующей функции из clojure.java.jdbc. Вообще, для всех функций backend-ом является она.
К сожалению, никакой предметной области нет. Таблицы и их минимальное содержание были придуманы только для примера.
Записи типа :join это ключевые параметры функции select (мы решили не использовать where, join и пр. в виде отдельных функций). Вектор в векторе из-за того, что в join-е могут участвовать несколько таблиц, где описание «соединения» каждой представлено в виде вектора [таблица [условия_связи]]. В данном случае в векторе описание только одной таблицы.
Согласен, описания остальных функций нет. Позже добавлю кратко.
Вот пруф. Не позорьтесь.
Да, вы хорошо разжевали свой fail с ерлангом и фп.
Вы в третий раз проявляете чудеса телепатии. Может отбросите эзотерику и займетесь самообразованием?
Значит, ваши обобщенные рассуждения в первых комментариях были недоразумением? Ок.
То, что вы описали, не может являться для кого бы то ни было «практическим опытом». По вашему описанию с побочными эффектами и прочим видно, что вы не хотите мучиться, изучать, менять свое императивное мышление. Напротив, в вас родилась, судя по слову «бесит», ненависть к ФП и ерлангу в частности. Плохой пример для подражания.
Правильное решение.
Чудеса да и только.
Тут читают молодые люди, которые «находятся в поиске». И такие посты как ваш оригинальный комментарий могут их смутить (по себе помню). Поэтому имхо спорить с подобным полезно.
Когда?
А вы не думали, что это специфичные проблемы связаны только с вами, вашим знанием ФП и вашим опытом использования ерланга? Думаю, некорректно на таком материале делать обобщенные утверждения про все ФП.
Значит, у вас были проблемы со стэктрейсом в ерланге? Т.е. это какая-то другая конкретная проблема вас и ерланга, не имеющая отношения ни к ФП вообще, ни к другим функциональным языкам? А проблему вы решили? Спрашивали на stackoverflow, например? Что вам ответили?
Т.е. в вашей программе на ерланге вы используете много мест с сайд эффектами, что привело к тому, что вам неудобно на этом языке контролировать сложность программы? При чем тут ФП?
Я не понял, к чему это. Пропущу.
Я не понял как взаимосвязана страховка от ошибок и питон.
В смыле, для вас рекурсивные алгоритмы являются проблемой и неискоренимой причиной ошибок?
И не зря вызвало. Как выясняется, ваш оригинальный пост был рефлексией, отражающей ваши вполне конкретные и частные проблемы с ерлангом и рекурсией и не распространяются на ФП в общем случае.
Без обид. Вы не можете этого утверждать, т.к. для того, чтобы сравнивать, необходимо сначала изучить мат.часть, хорошо знать и тот и этот подход.
Нисколько. Можете прочитать вместо «разделять» «противопоставлять».
Сам набрал. Никуда при этом не подглядывал. Тема то старая.
Ответил выше.
Не писал на нем ничего. Но надеюсь, вы сможете сформулировать проблему безотносительно к конкретному фп языку. Или у вас именно ерланг вызвал проблемы?
Не замечал ни в Common LIsp-е, ни в clojure. Можете привести пример?
Можете немного поподробнее?
Это согласен. Просто нужно учитывать, что при использовании фп языка меняется не только синтаксис, но и парадигма программирования. В этом то и смысл.
Что значит «рекурсия вышла из-под контроля »? Это же ваш код — как написали, так и работает. При чем тут фп?
А что вас конкретно бесит в фп и чем там неудобно пользоваться?
Ваш вывод неверен. Вы ошибаетесь, разделяя программирование с побочными эффектами и функциональное программирование. ФП и побочные эффекты — вещи перпендикулярные. Есть отдельное понятие pure functions, с помощью которых реализуется программирование без побочных эффектов. Например, в хаскеле соблюдается «чистота» (монады нужны), а в той же схеме или clojure — нет (необходимости монад нет).
Разделять процедурное программирование и фп можно и нужно. Различие между данными подходами колоссальные. ПП это императивное программирование, где весь код представляет собой пошаговое изменение глобального/локального состояния программы. ФП — это композиционное/декларативное программирование с помощью функций (с побочным эффектом или нет). ПП это высокоуровневое продолжение ассемблера. ФП идет из математики. Эффективное ФП возможно благодаря таким свойствам ФЯ, как функции высокого порядка/функции — граждане первого класса, рекурсия (с оптимизацией хвостовой рекурсии), замыкание. Поверьте, разница между ФП и ПП подходами к решению просто громадная.
В тексте есть вывод про ограничения, но нет аргументов и примеров.
З.Ы. Код требует хорошей переработки, т.к. писался в начале изучения языка.
Никакого противопоставления нет. Наоборот, важнен паттерн, а его реализация для пользователя не важна и даже не видна.
(defn factors [number]
(filter #(is-factor? % number) (range 1 number)))
Также можно «удешевить» sum-factors:
(defn sum-factors [number]
(apply + (factors number)))
Нам нужен был язык запросов, работающий именно с нашими генерируемыми данными (таблицы, поля). Также хотелось, чтобы было реализовано одно из наших требований: получение данных из связанных по внешним ключам таблиц (в orm-е джавы это было очень удобно).
К сожалению, никакой предметной области нет. Таблицы и их минимальное содержание были придуманы только для примера.
Записи типа :join это ключевые параметры функции select (мы решили не использовать where, join и пр. в виде отдельных функций). Вектор в векторе из-за того, что в join-е могут участвовать несколько таблиц, где описание «соединения» каждой представлено в виде вектора [таблица [условия_связи]]. В данном случае в векторе описание только одной таблицы.
Согласен, описания остальных функций нет. Позже добавлю кратко.