Здравствуйте, elmal, Вы писали:
E>На уже среднем проекте сдохнешь на Лиспе. Будут проблемы с отладкой, с читаемостью, хреновой IDE, отсутствием автокомплита и т.д. Плюс, хоть это и наименьшая из всех проблем, производительность кода будет ниже раза в 3 по сравнению с Java. Синтаксис, куча скобочек. Конечно молодец, что смотришь другие парадигмы и языки. Но это снова метания и искания. Lisp подобные языки да, нужно знать. SICP вообще крайне желательно читать в обязательном порядке, хоть и хрен заставишь кого. Нужно знать подходы, которые там применяются. Но потом нужно не фигачить весь проект на Lisp. А нужно перенимать хорошие практики и использовать там, где надо. На языке с более удачным синтаксисом, в котором нормальная IDE, в котором гораздо лучшая читабельность кода.
Есть большая разница между "слышал про lisp" и "пишу на лиспе". Про ide и разницу в производительности- всё мимо. Есть поддержка, производительность не хуже жавской, AOT компиляция, выразительность, краткость и т.д.
Сложность в головах программистов, покусанных OOP, и жавистов, покусанных спрингом.
Здравствуйте, SaprXM, Вы писали:
Тё>>Но как тогда добавить фана в программизм? Блин хочется напиться, но боюсь не поможет.
SXM>имел я дело поддерживать код уволившегося ведущего разработчика, который любил внедрять функциональное программирование, ублюдок SXM>месяца 2 вычищал всю его срань из проекта
Вот не граммар наци, но блин, без запятой (или точки) получается что "Ублюдок месяца 2 вычищал всю его срань из проекта"
Здравствуйте, Тёмчик, Вы писали:
Тё>Есть большая разница между "слышал про lisp" и "пишу на лиспе". Про ide и разницу в производительности- всё мимо. Есть поддержка, производительность не хуже жавской, AOT компиляция, выразительность, краткость и т.д. Тё>Сложность в головах программистов, покусанных OOP, и жавистов, покусанных спрингом.
У нас как раз один из разработчиков тестил для прикола производительность clojure. Взял тупо один алгоритм (дейкстры, если что, это тебе не реверс списков, это как раз полезный алгоритм, тем более в нашей области), написанный изначально в функциональном стиле на языке ML, и в лоб его писал на куче языков, тоже в функциональном стиле. Плюс там до черта других бенчмарков. Плюс еще профайлером побегал, у нас профайлером все пользоваться умеют, хоть и это редчайший навык для программиста. И если там явные косяки, вроде когда узким местом оказывается hashCode — оптимизировал. Так что знаю о чем говорю. Плюс он еще потребление памяти тестировал, там тоже не все хорошо. Плюс у нас как раз некритичные задачи один из разработчиков пишет как раз на clojure. Так что можно заценить и поддерживаемость, и читаемость кода. Выразительность и краткость мы вполне умеем делать на любых языках, все выглядит примерно одинаково. И если что, clojure пробовали даже в проде использовать, правда на фронтэнде. И про IDE не мимо, пробовали и на emacs после осваивания его в течение более трех лет, и с помощью плагина к IDE. Просто есть с чем сравнивать.
Здравствуйте, Somescout, Вы писали:
SXM>>имел я дело поддерживать код уволившегося ведущего разработчика, который любил внедрять функциональное программирование, ублюдок SXM>>месяца 2 вычищал всю его срань из проекта
S>Вот не граммар наци, но блин, без запятой (или точки) получается что "Ублюдок месяца 2 вычищал всю его срань из проекта"
Видимо, SaprXM не любит языки программирования, в которых статементы заканчиваются точкой с запятой.
Здравствуйте, CreatorCray, Вы писали:
Тё>> Под наименьший общий знаменатель заставляют подстраиваться. CC>И правильно делают, потому что бизнесу важна поддерживаемость кода.
Хм... у функционального стиля с поддерживаемостью кода как раз все хорошо.
Когда функциональный стиль применяется к месту и по делу, конечно.
Здравствуйте, landerhigh, Вы писали:
L>Когда функциональный стиль применяется к месту и по делу, конечно.
Проблема не с функциональным стилем как таковым. Проблема с динамической типизацией. Чтобы нормально писать на динамически типизированных языках — нужно в обязательном плане хреначить TDD. Без тестов будет полный швах. Автокомплит хочется. Можешь начать писать closure spec, тогда автокомплит будет. Но есть одно но. Если ты будешь фигачить с охрененно высоким покрытием тестами и спецификацией — у тебя будет до хрена кода, который тоже нужно поддерживать. И окажется это более многословно чем если фигачить со статической. Больше кода пишешь, больше напрягаешься, больше нужно держать в голове, оказывается меньше производительность.
Здравствуйте, vsb, Вы писали:
vsb>>>Работай там, где тебе никто не будет указывать, на чём писать. Я могу хоть на Rust-е писать, лишь бы в сроки укладывался.
Тё>>Это где? Какая предметная область?
vsb>Маленькая компания, где ты единственный разработчик. Предметная область, думаю, не существенна.
А если завтра — не дай Бог — маленькая компания будет вынуждена повесить на двери большой амбарный замок
Кому ты будешь нужен, со своим МаттиасомРустом?
Здравствуйте, elmal, Вы писали:
E>У нас как раз один из разработчиков тестил для прикола производительность clojure. Взял тупо один алгоритм (дейкстры, если что, это тебе не реверс списков, это как раз полезный алгоритм, тем более в нашей области), написанный изначально в функциональном стиле на языке ML, и в лоб его писал на куче языков, тоже в функциональном стиле.
Можешь про результаты рассказать?
Здравствуйте, elmal, Вы писали:
E>Проблема не с функциональным стилем как таковым. Проблема с динамической типизацией. Чтобы нормально писать на динамически типизированных языках — нужно в обязательном плане хреначить TDD.
Ты так говоришь, будто в этом есть что-то плохое.
E>Без тестов будет полный швах.
Это безотносительно языка.
E>Если ты будешь фигачить с охрененно высоким покрытием тестами и спецификацией — у тебя будет до хрена кода, который тоже нужно поддерживать.
Я давно фигачу с охрененно высоким покрытием тестами, не вижу проблемы, если честно.
Здравствуйте, elmal, Вы писали:
E>У нас как раз один из разработчиков тестил для прикола производительность clojure. Взял тупо один алгоритм (дейкстры, если что, это тебе не реверс списков, это как раз полезный алгоритм, тем более в нашей области), написанный изначально в функциональном стиле на языке ML, и в лоб его писал на куче языков, тоже в функциональном стиле. Плюс там до черта других бенчмарков. Плюс еще профайлером побегал, у нас профайлером все пользоваться умеют, хоть и это редчайший навык для программиста. И если там явные косяки, вроде когда узким местом оказывается hashCode — оптимизировал. Так что знаю о чем говорю. Плюс он еще потребление памяти тестировал, там тоже не все хорошо. Плюс у нас как раз некритичные задачи один из разработчиков пишет как раз на clojure. Так что можно заценить и поддерживаемость, и читаемость кода. Выразительность и краткость мы вполне умеем делать на любых языках, все выглядит примерно одинаково. И если что, clojure пробовали даже в проде использовать, правда на фронтэнде. И про IDE не мимо, пробовали и на emacs после осваивания его в течение более трех лет, и с помощью плагина к IDE. Просто есть с чем сравнивать.
Я ниасилил emacs и ещё много чего не осилил (atom как пример). Cursive для жавской экосистемы вполне оказался пригоден, AOT компиляция из мавена отлавливает явные проблемы, а юнит тесты покрывают функциональность. Но я не научился делать clojure на clojure- выходило нечто вроде кальки с жавы на клоюру. Вот когда наступит просветление- тогда с краткостью будет получше. Насчёт "пользоваться профайлером", перед этим нужно понимать временную сложность алгоритма. И только если непонятно, отчего где-то какая-то фигня творится, прибегать к помощи профилировщика.
Здравствуйте, elmal, Вы писали:
E> Если ты будешь фигачить с охрененно высоким покрытием тестами и спецификацией — у тебя будет до хрена кода, который тоже нужно поддерживать. И окажется это более многословно чем если фигачить со статической. Больше кода пишешь, больше напрягаешься, больше нужно держать в голове, оказывается меньше производительность.
Можно чуть подробнее на счет того, что считается "охрененно высоким покрытием тестами"? В общем случае, покрытие 75% и выше позволяют уверенно поддерживать кодовую базу как статически так и динамически типизированную. Ну а то что меньше, на любом языке с любой типизацией можно автоматически считать тяжело поддерживаемым легаси-кодом на следующий день после написания.
Здравствуйте, vsb, Вы писали:
vsb>Работай там, где тебе никто не будет указывать, на чём писать. Я могу хоть на Rust-е писать, лишь бы в сроки укладывался.
Удовольствия работать на пиратском корабле нет, пусть даже и капитаном
Здравствуйте, AlexGin, Вы писали:
vsb>>Маленькая компания, где ты единственный разработчик. Предметная область, думаю, не существенна.
AG>А если завтра — не дай Бог — маленькая компания будет вынуждена повесить на двери большой амбарный замок AG>Кому ты будешь нужен, со своим МаттиасомРустом?
Ну если говорить в контексте Clojure и других JVM-языков, обычно их знание подразумевает знание Java на экспертном уровне, поэтому в худшем случае пойдёшь работать Java-разработчиком. Если это Rust, вероятно будет даунгрейд до С++. А так согласен, помнить про такую возможность надо в любом случае.
Здравствуйте, msorc, Вы писали:
M>Можешь про результаты рассказать?
Там было весело. Исходный алгоритм на ML 27 секунд. Kotlin 17, Scala 22. Clojure 3 секунды. Начали разбираться какого черта. Выяснилось что не совсем корректно, там все языки кроме Clojure выполняли для всего огроменного массива действия, которые не нужны, а в clojure пошло все лениво и ненужные действия не пошли. Исправили на ленивость везде — Kotlin, Scala — меньше секунды, где то полторы секунды. Теперь врубили наоборот неленивость в Clojure. 87 секунд, то есть более чем в 3 раза медленнее. Начали оптимизировать, перевели строки в кейворды, 34 секунды. Пока еще развлекаемся . В любом случае это не серьезный бенчмарк а чисто по приколу.
Здравствуйте, Тёмчик, Вы писали:
Тё>Сложность в головах программистов, покусанных OOP, и жавистов, покусанных спрингом.
Сказал Тема, покусанный визитором.
Мой личный опыт общения с функциональщиной (F#) тоже говорит о том, что в серьезных командных проектах от нее никакой пользы, кроме вреда. Хочется писать поделки для себя — пиши на чем хочешь. А для команды важна поддерживаемость кода, а не удовольствие, которое получает его автор в процессе его написания.
P.S. Если что, я тоже в середине 2000-ых был любителем поизголяться — поиспользовать бустовые лямбды в плюсах, когда их никто в команде не использовал, парсер на boost::spirit'е запилить, и т.п. И оно даже работало нормально, вот только, часть потом повыпиливали нафиг после моего ухода на фриланс.
SXM>>>имел я дело поддерживать код уволившегося ведущего разработчика, который любил внедрять функциональное программирование, ублюдок SXM>>>месяца 2 вычищал всю его срань из проекта
S>>Вот не граммар наци, но блин, без запятой (или точки) получается что "Ублюдок месяца 2 вычищал всю его срань из проекта"
ARK>Видимо, SaprXM не любит языки программирования, в которых статементы заканчиваются точкой с запятой.
и кстати HR на основании подобных рассуждений и принимают решения
Здравствуйте, Lexey, Вы писали:
L>Мой личный опыт общения с функциональщиной (F#) тоже говорит о том, что в серьезных командных проектах от нее никакой пользы, кроме вреда. Хочется писать поделки для себя — пиши на чем хочешь. А для команды важна поддерживаемость кода, а не удовольствие, которое получает его автор в процессе его написания.
Странно... На конференциях по функциональным языкам полно представителей успешных команд. И из Европы, и из Штатов. На хлеб с икрой хватает...
Здравствуйте, Lexey, Вы писали:
L>Сказал Тема, покусанный визитором.
Сказал lexey, получивший душевную травму от ниасиленного visitor-а.
L>Мой личный опыт общения с функциональщиной (F#) тоже говорит о том, что в серьезных командных проектах
Считать серьезность проекта по поголовью, всё равно что считать квалификацию программиста по числу лет.
Здравствуйте, Lexey, Вы писали:
L>P.S. Если что, я тоже в середине 2000-ых был любителем поизголяться — поиспользовать бустовые лямбды в плюсах, когда их никто в команде не использовал, парсер на boost::spirit'е запилить, и т.п. И оно даже работало нормально, вот только, часть потом повыпиливали нафиг после моего ухода на фриланс.
А ты уверен, что проблема была в лямбдах и спирите, а не в том, что в целом была хрень неподдержаваемая? Ну, там, ни юнит-тестов, ни вменяемых комментариев и везде плохо пахнущий код?
M>Странно... На конференциях по функциональным языкам полно представителей успешных команд. И из Европы, и из Штатов. На хлеб с икрой хватает...
Ну пусть тогда Тёмчик пошлёт жавистов с их дурацкими запросами и пойдет работать на успешную команду функциональщиков, не? А жависты со своими приземлёнными запросами пусть сами вошкаются.
