Охх… да вы жирный троль то)))
Слово «бесит» употребили вы, меня оно покоробило и я сделал вам замечание
Сначала в общем, потом разжевал всё как для младенца.
По вашим комментам видно, что вы имеете мало опыта в разработке и много опыта в болтологии. Ещё раз повторю — вы троль, да ещё и опасный, так как располагаете большим количеством свободного времени. И кормить вас я больше не собираюсь.
Ох… я не буду продолжать холиварить, сапиэнти сат
Вы очевидно теоретик, и с практикой редко сталкиваетесь, так же очевидно что вы пишете код в одиночку а не работаете с большой командой командой
Тут спорить бесполезно делайте как вам нравится
Вы сказали что бесит вас в ПП подходе, я сказал что бесит меня в ФП подходе, постарался выделить не специфичные для эрланга моменты. А если брать сам эрланг, то до знакомства с ним в «боевых» условиях я встречал множество хвалебных отзывов о нём, некоторые товарищи даже утверждали что на этом языке можно написать всё что угодно гораздо проще и быстрее чем на чём-то ещё. Теперь подобные высказывания у меня ни чего кроме смеха не вызывают.
Итак о том что меня бесит в эрланге:
1. Очень мало готового кода, для решения повседневных задач, очень часто приходится городить велосипеды. Особенно умиляют ответы на стэковерфлоу из серии
— «Как сделать эту очевидную штуку?»
— «Элементарно, дорогой друг, надо всего-то написать вот эти тридцать строк кода и всё»
а то что это из коробки доступно чуть менее чем везде очень доставляет
2. Жуткий геморой с рекордами — этот очевидный костыль за 20 лет ни кто не исправил, работать с ними очень неудобно
3. После питона меня раздражает консоль ерланга, в которую я не могу так просто засунуть кусок кода и поиграться с ним, но это наверно субъективно, хотя всё равно не очень удобно.
4. Патерн актор хорош для построения инфраструктуры или для создания системы с готовым ТЗ, которая будет работать продолжительное время без сильного изменения логики, в реально веб аппликейшене, всё очень часто и порой радикально меняется и в какой-то момент понимаешь что больше думаешь о том «как это сделать» чем о том «что собственно надо сделать» Ну и в общем решать все проблемы одним паттерном — глупо.
5. Геморой с utf, в коде невозможно нормально с ним работать.
6. Строки — листы интов. Отдельная песня
Не хочу, чтобы создалось впечатление, что я ненавижу эрланг)) У него есть оочень много сильных сторон
1. Машины на разных концах планеты я легко и прозрачно могу заставить работать вместе, не задумываясь о протоколах и безопасности, если последнее меня беспокоит, я легко могу настроить коммуникации между нодами как мне нравится
2. Супер мощная, умная и быстрая виртуальная машина, (видимо поэтому появился elixir)
3. Паттернматчинг, особенно с бинарями, оочень удобно
4. Комуникация между потоками при помощи «записочек» =), единственный минус — дедлоки, но это скорее редкость и в основном по глупости, в остальном одни плюсы.
5. Легковесные потоки
Это далеко не полный список, просто то что сразу могу вспомнить.
Ну и лично моё мнение erlang — язык для создания инфраструктуры, он был задуман и долгое время использовался исключительно для данной цели и он делает это на 5+
Это не универсальный язык, и использовать его для «всего» — это как отвёрткой в зубах ковырятся — вроде можно, но оочень неприятно. Хотя надо отдать должное, в опенсорсе он не так давно и, я думаю, по прошествии какого-то времени большую часть проблем пофиксят.
И на десерт, на лурке классно сказано (прошу прощение за мат):
Любители выебнуться писать на Эрланге хвастаются тем, что могут наплодить кучу потоков, работающих быстрее света, но мы-то знаем, что за все это время они наплодили чуть менее, чем нихуя программ. lurkmore.to/Erlang
Не замечал ни в Common LIsp-е, ни в clojure. Можете привести пример?
Не вижу смысла копипастить сюда километровый лог, неужели это не очевидно? Одно дело, если вы видите в стэктрейсе полную картину происходящего, и совсем другое если некоторые кадры отсутствуют из-за оптимизации.
Геморой с сайд-эффектами
Можете немного поподробнее?
какие подробности вас интересуют? Сайд-эфекты в ФП один большой геморой, если их количество велико, то проще задачу реализовать в императивном стиле, это более естественно, иначе вы лишаетесь многих приимуществ функционального подхода.
Что значит «рекурсия вышла из-под контроля »? Это же ваш код — как написали, так и работает. При чем тут фп?
Даже если вы пишете код в одиночку:
— вы не застрахованы от ошибок
— кода становится больше, энтропия возрастает
— вы многое можете забыть в коде который вы писали полгода назад
Ну а в реальной жизни код пишется командой и энтропия ещё сильнее возрастает.
А вообще ни кто не застрахован от ошибок, но зависший сервер — это слишком высокая цена, в питоне например вам надо сиииильно постараться чтобы сделать такое,
Кроме того, понять из-за чего именно и в какой момент произошло зацыкливание, не самая тривиальная задача.
P.S. не думал что мой коммент вызовет столько вопросов. Всё что я хотел сказать — выбирайте инструмент соответствующий задаче, ФП идеально подходит для одних задач ПП — для других, есть задачи, которые можно реализовать и так и так, с определёнными оговорками. Нет универсального подхода для всего! Все же снают что у серебрянных пуль начинка чаще всего, пардон, из говна. У любого программиста должны быть на вообружении оба подхода и он должен уметь грамотно применять их для решения конкретных задач вот и всё.
Ниже ответил, процитирую тут
1. Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
2. Геморой с сайд-эффектами
3. Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
4. Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Вы не очень внимательны =)
Противопоставлять != Разделять
«Поверьте, разница между ФП и ПП подходами к решению просто громадная»
Вы видимо издеваетесь))) Я и не говорю что разницы нет, и верить мне вам не за чем так как я использую питон и эрланг в продакшене и разница для меня очевидна =). А вы, зачем-то копипастите текст из википедии))
Странно что вы спрашиваете меня про ограничения ФП, если вы писали что-то сложнее «hello-world»
1. Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
2. Геморой с сайд-эффектами
3. Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
4. Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Если этого вам мало могу продолжить уже конкретно по Эрлангу.
Вот насчёт паттернматчинга спорить не буду, его действительно нехватает и это бесспорно очень удобная штука.
Но лямбды, лист компрехеншн и прочие функциональные приёмы давно перекочевали в ОО-языки. Своим прошлым комментом я просто хотел сказать что в функциональном программировании тоже есть много чего что «бесит» и чем пользоваться неудобно.
Вы, как и автор статьи путаете мягкое с холодным.
Нельзя противопоставлять процедурное и функционально программирование. Это просто два разных подхода для решения насущных задач. И то что на протяжении десятилетий они существуют вместе, как бы намекает об этом.
Есть много задач которые элегантно решаются с помощью, например Erlang'a, с другой стороны если начать его использование повсеместно, то появляется куча головной боли, которой с применением ОО-подхода не было бы.
Многие, кто приступает к изучению функциональных языков, видят как хорошо, порой, задачи из реального мира ложаться на код. Однако забывают про ограничения ФП. Например в реальном мире есть монитор и принтер, которые являются «разделяемыми ресурсами» как и воздух и земля по который мы ходим. И вот тут начинаются проблемы =)
Выхода два: или пользоваться ОО-языком для решения задач с большим количеством сайд-эфектов, или изобретать монады
Так что каждой задаче — свой инструмент.
Я бы сформулировал более кратко:
1. Учись и эксперементируй.
2. Не бойся совершать ошибки
3. Не верь наслово
Как-то так))) А вообще надо статью скинуть нашему тимлиду =))
Да, проект можно назвать русским (но не российским). Но я говорил о том, что ресурс набрал популярность и начал зарабатывать деньги за рубежом (южная америка а потом и остальной испаноговорящий мир).
Насчёт «истерично» это я слишком резко выразился, просто слишком лично и субъективно.
Поросёнок пётр это знаменитый мем, я хотел оставить ссылку, но хабр не разрешает мне, так как карма -1 =)) lurkmore.to/%D0%9F%D0%BE%D1%80%D0%BE%D1%81%D1%91%D0%BD%D0%BE%D0%BA_%D0%9F%D1%91%D1%82%D1%80
А вообще я бы убрал из заголовка вашего поста «в социальных сетях» и получилась бы чистая правда =)))
«Почему сайты знакомств, во всем мире забытые, у нас до сих пор привлекают тысячи новых пользователей каждый день? „
Автор явно не в теме. Посмотрите на badoo.com, хотя Андрей Андреев и русский(грузин =)), ресурс начал свою жизнь за бугром и в этом году под другим брэндом начал экспансию в штаты. по количеству пользователей он рвёт вконтактий как тузик грелку, а по revenue и динамике его роста всец соц. сети рф.
У меня сложилось впечатление, что у автора просто осенний приступ синдрома “поросёнка Петра»
Всё слишком лично, истирично и необоснованно.
Слово «бесит» употребили вы, меня оно покоробило и я сделал вам замечание
Сначала в общем, потом разжевал всё как для младенца.
По вашим комментам видно, что вы имеете мало опыта в разработке и много опыта в болтологии. Ещё раз повторю — вы троль, да ещё и опасный, так как располагаете большим количеством свободного времени. И кормить вас я больше не собираюсь.
Вы очевидно теоретик, и с практикой редко сталкиваетесь, так же очевидно что вы пишете код в одиночку а не работаете с большой командой командой
Тут спорить бесполезно делайте как вам нравится
Итак о том что меня бесит в эрланге:
1. Очень мало готового кода, для решения повседневных задач, очень часто приходится городить велосипеды. Особенно умиляют ответы на стэковерфлоу из серии
— «Как сделать эту очевидную штуку?»
— «Элементарно, дорогой друг, надо всего-то написать вот эти тридцать строк кода и всё»
а то что это из коробки доступно чуть менее чем везде очень доставляет
2. Жуткий геморой с рекордами — этот очевидный костыль за 20 лет ни кто не исправил, работать с ними очень неудобно
3. После питона меня раздражает консоль ерланга, в которую я не могу так просто засунуть кусок кода и поиграться с ним, но это наверно субъективно, хотя всё равно не очень удобно.
4. Патерн актор хорош для построения инфраструктуры или для создания системы с готовым ТЗ, которая будет работать продолжительное время без сильного изменения логики, в реально веб аппликейшене, всё очень часто и порой радикально меняется и в какой-то момент понимаешь что больше думаешь о том «как это сделать» чем о том «что собственно надо сделать» Ну и в общем решать все проблемы одним паттерном — глупо.
5. Геморой с utf, в коде невозможно нормально с ним работать.
6. Строки — листы интов. Отдельная песня
Не хочу, чтобы создалось впечатление, что я ненавижу эрланг)) У него есть оочень много сильных сторон
1. Машины на разных концах планеты я легко и прозрачно могу заставить работать вместе, не задумываясь о протоколах и безопасности, если последнее меня беспокоит, я легко могу настроить коммуникации между нодами как мне нравится
2. Супер мощная, умная и быстрая виртуальная машина, (видимо поэтому появился elixir)
3. Паттернматчинг, особенно с бинарями, оочень удобно
4. Комуникация между потоками при помощи «записочек» =), единственный минус — дедлоки, но это скорее редкость и в основном по глупости, в остальном одни плюсы.
5. Легковесные потоки
Это далеко не полный список, просто то что сразу могу вспомнить.
Ну и лично моё мнение erlang — язык для создания инфраструктуры, он был задуман и долгое время использовался исключительно для данной цели и он делает это на 5+
Это не универсальный язык, и использовать его для «всего» — это как отвёрткой в зубах ковырятся — вроде можно, но оочень неприятно. Хотя надо отдать должное, в опенсорсе он не так давно и, я думаю, по прошествии какого-то времени большую часть проблем пофиксят.
И на десерт, на лурке классно сказано (прошу прощение за мат):
Не вижу смысла копипастить сюда километровый лог, неужели это не очевидно? Одно дело, если вы видите в стэктрейсе полную картину происходящего, и совсем другое если некоторые кадры отсутствуют из-за оптимизации.
какие подробности вас интересуют? Сайд-эфекты в ФП один большой геморой, если их количество велико, то проще задачу реализовать в императивном стиле, это более естественно, иначе вы лишаетесь многих приимуществ функционального подхода.
Даже если вы пишете код в одиночку:
— вы не застрахованы от ошибок
— кода становится больше, энтропия возрастает
— вы многое можете забыть в коде который вы писали полгода назад
Ну а в реальной жизни код пишется командой и энтропия ещё сильнее возрастает.
А вообще ни кто не застрахован от ошибок, но зависший сервер — это слишком высокая цена, в питоне например вам надо сиииильно постараться чтобы сделать такое,
Кроме того, понять из-за чего именно и в какой момент произошло зацыкливание, не самая тривиальная задача.
P.S. не думал что мой коммент вызовет столько вопросов. Всё что я хотел сказать — выбирайте инструмент соответствующий задаче, ФП идеально подходит для одних задач ПП — для других, есть задачи, которые можно реализовать и так и так, с определёнными оговорками. Нет универсального подхода для всего! Все же снают что у серебрянных пуль начинка чаще всего, пардон, из говна. У любого программиста должны быть на вообружении оба подхода и он должен уметь грамотно применять их для решения конкретных задач вот и всё.
1. Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
2. Геморой с сайд-эффектами
3. Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
4. Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Противопоставлять != Разделять
Вы видимо издеваетесь))) Я и не говорю что разницы нет, и верить мне вам не за чем так как я использую питон и эрланг в продакшене и разница для меня очевидна =). А вы, зачем-то копипастите текст из википедии))
Странно что вы спрашиваете меня про ограничения ФП, если вы писали что-то сложнее «hello-world»
1. Из-за оптимизации хвостовой рекурсии стэктрейсы (и без того запутанные) становятся сложно-читаемыми
2. Геморой с сайд-эффектами
3. Постоянный вопрос «А есть ли у меня в данном участке кода все необходимые данные? Чёрт, надо их прокинуть через несколько вызовов, совершенно других функций или использовать какой-нибудь другой манёвр с бубном»
4. Редко, но очень «метко» вы можете залипнуть в логи и даже остановить сервант, потому-что где-то любимая вами рекурсия вышла из-под контроля и сожрала весь проц/память
Если этого вам мало могу продолжить уже конкретно по Эрлангу.
Но лямбды, лист компрехеншн и прочие функциональные приёмы давно перекочевали в ОО-языки. Своим прошлым комментом я просто хотел сказать что в функциональном программировании тоже есть много чего что «бесит» и чем пользоваться неудобно.
Нельзя противопоставлять процедурное и функционально программирование. Это просто два разных подхода для решения насущных задач. И то что на протяжении десятилетий они существуют вместе, как бы намекает об этом.
Есть много задач которые элегантно решаются с помощью, например Erlang'a, с другой стороны если начать его использование повсеместно, то появляется куча головной боли, которой с применением ОО-подхода не было бы.
Многие, кто приступает к изучению функциональных языков, видят как хорошо, порой, задачи из реального мира ложаться на код. Однако забывают про ограничения ФП. Например в реальном мире есть монитор и принтер, которые являются «разделяемыми ресурсами» как и воздух и земля по который мы ходим. И вот тут начинаются проблемы =)
Выхода два: или пользоваться ОО-языком для решения задач с большим количеством сайд-эфектов, или изобретать монады
Так что каждой задаче — свой инструмент.
1. Учись и эксперементируй.
2. Не бойся совершать ошибки
3. Не верь наслово
Как-то так))) А вообще надо статью скинуть нашему тимлиду =))
Насчёт «истерично» это я слишком резко выразился, просто слишком лично и субъективно.
Поросёнок пётр это знаменитый мем, я хотел оставить ссылку, но хабр не разрешает мне, так как карма -1 =))
lurkmore.to/%D0%9F%D0%BE%D1%80%D0%BE%D1%81%D1%91%D0%BD%D0%BE%D0%BA_%D0%9F%D1%91%D1%82%D1%80
А вообще я бы убрал из заголовка вашего поста «в социальных сетях» и получилась бы чистая правда =)))
Автор явно не в теме. Посмотрите на badoo.com, хотя Андрей Андреев и русский(грузин =)), ресурс начал свою жизнь за бугром и в этом году под другим брэндом начал экспансию в штаты. по количеству пользователей он рвёт вконтактий как тузик грелку, а по revenue и динамике его роста всец соц. сети рф.
У меня сложилось впечатление, что у автора просто осенний приступ синдрома “поросёнка Петра»
Всё слишком лично, истирично и необоснованно.