Никому ведь на самом деле не нужна функциональщина - а нужно работающее решение. И по большей части, заказчику все равно, на чем написано, если забыть про одну вещь - кто потом это будет сопровождать. А если не забывать - то я видел сколько угодно проектов, которые невозможно на скалу переписать, потому что никто ее достаточно хорошо не знает.
Вот там где я могу, я ее легко и непринужденно применяю, и меня мое посредственное ее знание не сильно смущает. Насчет знания - я где-то в top 95% сдававших тест по ней на Linkedin. В итоге я оцениваю рынок скалистов как весьма странный и ненадежный, если можно так выразиться.
Против идеи ничего не имею, идея норм. Я про то, что стримы (в отличие от циклов) хорошо параллелятся, но не всегда, а скажем если в них нет вот таких вот операций.
Ну, вообще говоря, в стриме нет естественного индекса объекта. Если вам хочется - сделайте стрим из пар (индекс, объект), либо как вы поступили, либо zipWithIndex. И имейте при этом в виду, что как только вы начнете обработку стрима параллелить, ваш атомик возможно станет бутылочным горлышком :)
Затем что это упрощает некоторые вещи с точки зрения функций высших порядков. Потому что иметь везде унарные функции местами удобнее. Ну например map - вас же не смущает, что у map в сигнатуре унарная функция, вместо многих разных map с функциями разной -арности?
Про пример ничего сказать не хочу, вполне допускаю, что игрушечный пример и правда плох. И я готов согласиться, что придумать хороший пример и правда сложно, и что каррирование это не то, что применяется на повседневной основе - все скорее правда.
Ну как бы, если вы попробуете жить без этого всего, то тоже будет боль. Просто она возможно будет менее заметна, потому что все будет более привычно. Возможно, кто-то даже с ней живет, и не замечает. Ну вот зачем далеко ходить - я только вчера переписывал кучки кода кое-за кем, и мне больно видеть в коде циклы по индексу, потому что я привык уже много лет пользоваться стримами - даже по той простой причине. что операции со стримом яснее выражают намерения программиста. Для меня даже этого достаточно, а есть много людей, которые вообще не понимают, о чем это все, какие такие намерения?
Вообще, я понимаю что для автора его собственное творение - самое лучшее :) Но реально не мешало бы сравнить хотя бы с парочкой других продуктов, которых мне кажется далеко не парочка, во-первых, потому что Java 8 уже 10 лет как вышла в релиз (а пререлизы были много раньше), и кто только не писал подобное за это время, и во-вторых, потому что потребности в этом достаточно очевидны.
В типичном современном языке далеко не все можно выразить формально, поэтому контакт штука немного условная. И да, конечно принимающей - у нее же сломается то?
Они были сформулированы в терминах ООП, и ретранслируются в этих же терминах. Это не значит, что их нельзя расширить на другие парадигмы (другой вопрос - нужно ли). В функциональной парадигме все сильно проще в некотором смысле, поэтому там и не особо есть потребность какие-то принципы формулировать (хотя наверняка можно сформулировать принципы, упрощающие сопровождение и понимание, и вероятно другие).
Если у вас есть чистая функция, то SRP по факту соблюдается автоматически - ответственность в том, чтобы вычислить результат. Побочных эффектов и деятельности нет. Интерфейс - это сигнатура функции (для чистой функции на 100%). LSP - ну опять же, для чистой функции подстановка вместо одной функции другой, совместимой про сигнатуре, не должна ломать тех кто использует (другое дело, что есть вещи, невыразимые сигнатурой).
Команда по подбору персонала может без колебаний ответить на вопрос, какой процент ее целей был достигнут,
Только это ничего не говорит о том, что набрали хороших работников, а не например болванов, которых пришлось уволить до окончания испытательного срока. Т.е. суть-то в общем та же самая - они умеют что-то измерять, но это измерение не имеет прямого отношения к реальному качеству их результата (как только набираем мы разработчиков, а не дворников, т.е. задача набора чуть усложняется).
Поддержу. Одним из самых полезных моих решений по рефакторингу был вынос скриптов из файлов с данными, чтобы они были плагином excel. А потом вынос исходников в VCS, и сборка плагина из них. Чтобы было версионирование и история изменений.
Заметьте, я не говорил что VBA это плохо. Это зависит от многого. Даже тот монстр на 120 тыщ строк, что я переписывал - он работал, и он при этом был написан непрофессиональным программистом. И большАя часть моих трудностей по переписыванию была вызвана отсутствием автора и документации - т.е. я не понимал бизнес-смысла написанного.
И насчет JS я тоже скорее согласен - опять же, заметьте, я не предлагал на него переходить, я предлагал на c#.
Строго говоря, они не только для ООП. Ну т.е. понятно, что если в языке нет наследования, и объектов, некоторые вещи в нем обязательно будут сформулированы иначе. Но общую идею вполне можно выделить. Ну вот давайте глянем на LSP. LSP вообще говоря про типы. А типы это совсем не обязательно ООП, это все что угодно, в функциональном языке они тоже есть.
Да. Вы правы, это и правда есть в русской версии, я правда не понимаю, почему это значительно ниже по тексту, потому что это и есть цель всех принципов.
Ну раз уж у нас цель упростить понимание, поддержку и расширение, из этого почти автоматически следует, что это не универсальные принципы, если нам и так легко понимать, поддерживать и расширять, то нам SOLID не нужно. Ну или сейчас не нужно - понятно, что если вы наймете в команду новых людей, особенно более низкой квалификации, то упрощение понимания для вас станет актуальным.
И еще нюанс, которого на мой взгляд многое может прояснить: по сути, все пять принципов сводятся к одному - нужно чтобы вносимые изменения были локальны. Т.е. новая функциональность не должна размазываться по всему коду. SOLID, которые по большей части говорят о слабой связности модулей, как раз эту локальность и обеспечивают - все по разному, но суть в общем-то одна.
Спасибо, но всё же пока не нашёл ответа на свой вопрос.
А вы сформулируйте вопрос четче. Пока не очень понятно, что вам непонятно.
Наследники должны соблюдать контракт. Иначе использование наследника сломает логику существующего кода в том месте, где использовался предок. В этом и цель - расширение кода путем создания класса наследника не должно ломать существующий код, который использует предка.
К сожалению, типы данных, включая сигнатуры методов, в существующих языках, недостаточно мощные, чтобы полностью описать контракт. Поэтому часть контракта описывается неформально, и не может быть проверена компилятором. Там где контракт сводится к сигнатуре функции, где функции чистые, то есть скажем в функциональных языках, LSP не имеет особого смысла - сигнатура совпадает - значит функцию можно использовать вот тут вместо другой. И это может проверить компилятор.
Все те статьи, что вы нашли, в большинстве своем страдают тем же недостатком, что и данная - они забывают за примерами кода основное назначение принципов, которое очень простое - чтобы код легко сопровождался и расширялся, при расширении не должно ломаться то, что уже написано ранее.
Вы возможно сами не заметили, но вы опустили в тексте то самое основное, для чего принципы нужны. Попробуйте например открыть статью про SOLID в английской википедии, и прочитайте первый абзац. Вы там найдете то самое "зачем", которое в вашем тексте на много страниц отсутствует. И когда вы это найдете, вы возможно для себя тоже поймете простую вещь:
Но цель статьи, ещё раз - совсем новичков с SOLID познакомить.
что может и не надо знакомить новичков с этим? Чтобы нормально понять данные принципы, надо на практике столкнуться с теми проблемами, которые они решают. А у новичков чаще всего такие проблемы просто не стоят.
И что самое смешное - понимание этого самого "зачем" как раз дает ответ на вопрос, нужно ли принципы эти пихать везде и всюду. Еще раз - смысл "зачем" нормально укладывается в один абзац. Попробуйте найти ответ сами.
Ну, сами-то советы по большей части вполне очевидные (хотя по этой же причине одновременно и банальные). Например, что не стоит думать, будто работодатели ждут вас, бакалавров, с распростертыми объятиями. Но они ведь и правда не ждут? В среднем.
Откуда автор может знать? Да ниоткуда, сочиняет из головы. Стоит ли этим советам верить? Я думаю вы и так знаете ответ - нет, полностью не стоит, но кому-то может пригодится. К ним лучше относиться как к личному мнению автора, чем они собственно и являются.
Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
плагины на VBA можно писать и в грамотном современном виде
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
Никому ведь на самом деле не нужна функциональщина - а нужно работающее решение. И по большей части, заказчику все равно, на чем написано, если забыть про одну вещь - кто потом это будет сопровождать. А если не забывать - то я видел сколько угодно проектов, которые невозможно на скалу переписать, потому что никто ее достаточно хорошо не знает.
Вот там где я могу, я ее легко и непринужденно применяю, и меня мое посредственное ее знание не сильно смущает. Насчет знания - я где-то в top 95% сдававших тест по ней на Linkedin. В итоге я оцениваю рынок скалистов как весьма странный и ненадежный, если можно так выразиться.
Против идеи ничего не имею, идея норм. Я про то, что стримы (в отличие от циклов) хорошо параллелятся, но не всегда, а скажем если в них нет вот таких вот операций.
Ну, вообще говоря, в стриме нет естественного индекса объекта. Если вам хочется - сделайте стрим из пар (индекс, объект), либо как вы поступили, либо zipWithIndex. И имейте при этом в виду, что как только вы начнете обработку стрима параллелить, ваш атомик возможно станет бутылочным горлышком :)
Затем что это упрощает некоторые вещи с точки зрения функций высших порядков. Потому что иметь везде унарные функции местами удобнее. Ну например map - вас же не смущает, что у map в сигнатуре унарная функция, вместо многих разных map с функциями разной -арности?
Про пример ничего сказать не хочу, вполне допускаю, что игрушечный пример и правда плох. И я готов согласиться, что придумать хороший пример и правда сложно, и что каррирование это не то, что применяется на повседневной основе - все скорее правда.
Но неясного-то в нем что?
Ну как бы, если вы попробуете жить без этого всего, то тоже будет боль. Просто она возможно будет менее заметна, потому что все будет более привычно. Возможно, кто-то даже с ней живет, и не замечает. Ну вот зачем далеко ходить - я только вчера переписывал кучки кода кое-за кем, и мне больно видеть в коде циклы по индексу, потому что я привык уже много лет пользоваться стримами - даже по той простой причине. что операции со стримом яснее выражают намерения программиста. Для меня даже этого достаточно, а есть много людей, которые вообще не понимают, о чем это все, какие такие намерения?
Вообще, я понимаю что для автора его собственное творение - самое лучшее :) Но реально не мешало бы сравнить хотя бы с парочкой других продуктов, которых мне кажется далеко не парочка, во-первых, потому что Java 8 уже 10 лет как вышла в релиз (а пререлизы были много раньше), и кто только не писал подобное за это время, и во-вторых, потому что потребности в этом достаточно очевидны.
В типичном современном языке далеко не все можно выразить формально, поэтому контакт штука немного условная. И да, конечно принимающей - у нее же сломается то?
Они были сформулированы в терминах ООП, и ретранслируются в этих же терминах. Это не значит, что их нельзя расширить на другие парадигмы (другой вопрос - нужно ли). В функциональной парадигме все сильно проще в некотором смысле, поэтому там и не особо есть потребность какие-то принципы формулировать (хотя наверняка можно сформулировать принципы, упрощающие сопровождение и понимание, и вероятно другие).
Если у вас есть чистая функция, то SRP по факту соблюдается автоматически - ответственность в том, чтобы вычислить результат. Побочных эффектов и деятельности нет. Интерфейс - это сигнатура функции (для чистой функции на 100%). LSP - ну опять же, для чистой функции подстановка вместо одной функции другой, совместимой про сигнатуре, не должна ломать тех кто использует (другое дело, что есть вещи, невыразимые сигнатурой).
Только это ничего не говорит о том, что набрали хороших работников, а не например болванов, которых пришлось уволить до окончания испытательного срока. Т.е. суть-то в общем та же самая - они умеют что-то измерять, но это измерение не имеет прямого отношения к реальному качеству их результата (как только набираем мы разработчиков, а не дворников, т.е. задача набора чуть усложняется).
Поддержу. Одним из самых полезных моих решений по рефакторингу был вынос скриптов из файлов с данными, чтобы они были плагином excel. А потом вынос исходников в VCS, и сборка плагина из них. Чтобы было версионирование и история изменений.
Заметьте, я не говорил что VBA это плохо. Это зависит от многого. Даже тот монстр на 120 тыщ строк, что я переписывал - он работал, и он при этом был написан непрофессиональным программистом. И большАя часть моих трудностей по переписыванию была вызвана отсутствием автора и документации - т.е. я не понимал бизнес-смысла написанного.
И насчет JS я тоже скорее согласен - опять же, заметьте, я не предлагал на него переходить, я предлагал на c#.
Строго говоря, они не только для ООП. Ну т.е. понятно, что если в языке нет наследования, и объектов, некоторые вещи в нем обязательно будут сформулированы иначе. Но общую идею вполне можно выделить. Ну вот давайте глянем на LSP. LSP вообще говоря про типы. А типы это совсем не обязательно ООП, это все что угодно, в функциональном языке они тоже есть.
Ну куда копать, примерно понятно. Скажем, вот: https://books.japila.pl/spark-sql-internals/expressions/ScalaUDF/#one-argument-udf
Да. Вы правы, это и правда есть в русской версии, я правда не понимаю, почему это значительно ниже по тексту, потому что это и есть цель всех принципов.
Ну раз уж у нас цель упростить понимание, поддержку и расширение, из этого почти автоматически следует, что это не универсальные принципы, если нам и так легко понимать, поддерживать и расширять, то нам SOLID не нужно. Ну или сейчас не нужно - понятно, что если вы наймете в команду новых людей, особенно более низкой квалификации, то упрощение понимания для вас станет актуальным.
И еще нюанс, которого на мой взгляд многое может прояснить: по сути, все пять принципов сводятся к одному - нужно чтобы вносимые изменения были локальны. Т.е. новая функциональность не должна размазываться по всему коду. SOLID, которые по большей части говорят о слабой связности модулей, как раз эту локальность и обеспечивают - все по разному, но суть в общем-то одна.
А вы сформулируйте вопрос четче. Пока не очень понятно, что вам непонятно.
Наследники должны соблюдать контракт. Иначе использование наследника сломает логику существующего кода в том месте, где использовался предок. В этом и цель - расширение кода путем создания класса наследника не должно ломать существующий код, который использует предка.
К сожалению, типы данных, включая сигнатуры методов, в существующих языках, недостаточно мощные, чтобы полностью описать контракт. Поэтому часть контракта описывается неформально, и не может быть проверена компилятором. Там где контракт сводится к сигнатуре функции, где функции чистые, то есть скажем в функциональных языках, LSP не имеет особого смысла - сигнатура совпадает - значит функцию можно использовать вот тут вместо другой. И это может проверить компилятор.
Все те статьи, что вы нашли, в большинстве своем страдают тем же недостатком, что и данная - они забывают за примерами кода основное назначение принципов, которое очень простое - чтобы код легко сопровождался и расширялся, при расширении не должно ломаться то, что уже написано ранее.
Вы возможно сами не заметили, но вы опустили в тексте то самое основное, для чего принципы нужны. Попробуйте например открыть статью про SOLID в английской википедии, и прочитайте первый абзац. Вы там найдете то самое "зачем", которое в вашем тексте на много страниц отсутствует. И когда вы это найдете, вы возможно для себя тоже поймете простую вещь:
что может и не надо знакомить новичков с этим? Чтобы нормально понять данные принципы, надо на практике столкнуться с теми проблемами, которые они решают. А у новичков чаще всего такие проблемы просто не стоят.
И что самое смешное - понимание этого самого "зачем" как раз дает ответ на вопрос, нужно ли принципы эти пихать везде и всюду. Еще раз - смысл "зачем" нормально укладывается в один абзац. Попробуйте найти ответ сами.
Ну, сами-то советы по большей части вполне очевидные (хотя по этой же причине одновременно и банальные). Например, что не стоит думать, будто работодатели ждут вас, бакалавров, с распростертыми объятиями. Но они ведь и правда не ждут? В среднем.
Откуда автор может знать? Да ниоткуда, сочиняет из головы. Стоит ли этим советам верить? Я думаю вы и так знаете ответ - нет, полностью не стоит, но кому-то может пригодится. К ним лучше относиться как к личному мнению автора, чем они собственно и являются.
Так и не понял из текста, что же скрывается под "множество терабайтов и миллиарды строк". Это мешает понять, какими же реально масштабами они оперируют.
Только отчасти. VBA все равно останется устаревшим языком, с кучкой странных по сегодняшним временам решений. Чуть лучше сделать можно - но страдать все равно придется.
Если автор переписал 100 строк в 380, то мне приходилось переписывать 120 тысяч строк кода, которые были намного сложнее, чем работа с данными внутри листов таблицы. Там были и файловая система, и шина данных, и сложный UI.
Если у вас реально стоит задача переписать в современном виде - возьмите и перепишите на C#, будет намного, намного лучше.
О, давайте-давайте, будем ждать.