Я не силен во всех этих теориях, по этому также можно сказать задам вопрос, если что меня поправьте…
В ООП который мейнстрим, важна инкапсуляция, тоесть мы забываем про иммутабельность, в ФП иммутабельность вроде как уже является основопологающей вещью, так как у нас могут быть только вычисляемые выражения. И да согласен что нельзя выкинуть от туда наследование, но к нему надо относиться осторожно, тоесть нельзя переводить наследование на уровень переиспользованию кода, а нужно придерживаться абстракций. В ФП я так понимаю наследования можно добиться через функции высшего порядка, или просто применения разных функций к одним и тем же данным или подобия дженерикам, вполне возможно ФП накладывает более строгий подход.
Я не сильно силен в ФП, от сюда и вопрос, а разве нет подобия наследования в ФП, только оно вполне возможно выглядит иначе?
ох уж… ну прям…
я помню когда-то в юношестве тоже творчеством восторгался, рисование, игра на гитаре в группе, программирование…
творчество это очень интересно конечно, но только от него выхлопа как правило 8%, а остальное в помойку, с годами это проходит и приходит понимание…
А тут уж инженерная работенка… и да, оно еще интереснее, творческий процесс не пропадает, но пропадает бесполезное творчество. Надо сделать так что бы уложиться в ограничения ПО, и паттерны тут не спасают), и можно форкнуть стороннюю либу, и послать пул реквест)
На мой взгляд юношеский максимализм и нытье, не в обиду автору(хотя конечно понимаю что слова обидные, уж извините)
вспоминаю свое прошлое…
изучение было с С, потом С++, потом Java…
сейчас в основом Haskell, все хорошо.
Было время когда я почти полгода рефакторил проект, просто пипец был лютейщий… ад.
Пытался привести это в порядок и оставить после себя читаемый код.
Потом я уже писал свой код и вроде доработки после меня шли нормально, ну я надеюсь))
Потом попался код как в первом случае… о боже я тяжело его воспринимал, вспоминая как я легко читал бредятину из первого случая, просто тогда я привык.
Вопрос на засыпку, а писать легко читаемый код это не искусство случаем?
возьмем этот вопрос с другой стороны. Зачем если можно добиться перфоменса на одном языке… как то в друг использовать другой, надо всех обучить и т.д., в таких случаях перфоменса нет, надо добавить еще одно усложнение…
ООП языки во многом дают возможность решать проблемы императивно, даны инструменты… я к тому за что топит Егор Бугаенко в поисках идеальных ОО языков программирования. Но мыслить как ООП программист и как он будет делать другой вопрос.
Хотя я убеждаюсь в том что лучше мешать ООП и ФП, пока мое субъективное мнение.
Golang подходит почти всем, кому, нужен перфоманс в скорости по сравнению со скриптовыми языками, такими как ruby, python, php и даже javascript..., но он не нужен тем кто работает с java, с#…
Простая причина, это почти либа при которой можно девелопить вещи имея стандартные средства для микросервисов, быстро изучается, тяжело отстрелить себе ногу…
а синтаксис и питоновцы, хотя самому нравится питон… могу предположить что go еще более строгий и минимум скрывает своих задвигов за сахаром, как это делают другие интерпретируемые языки
Ну так ООП и ФП направлены… не верно пишу и говорю, все это направлено на упрощение, на легкую поддерживаемость, не все практику ООП и ФП могут дать легкость понимания кода. Но все мы боремся со сложностью…
Пример не удачный, как наверное и любой пример без контекста.
Но скорее я сейчас говорю о том как быстрее и легче решить задачу.
Воспринимать это как объект(ООП), как процесс(ФП), как просто должное и не городить абстракции вокруг задачи(императивное...)?
Это довольно спорный тезис. Как же разносторонность мышления?
разносторонность субъективная вещь на мой взгяд, есть опыт, а он как раз субъективен.
Ради интереса возьмем размышления такого адепта как Егор Бугоенко и его отношением к ООП, но ведь во многих вопросах он прав, но чисто в технических нет(от сюда и так много споров и негодований), какое решение мы применим, скорее всего такое которое нам ближе)
Примерные пруфы…
Но опять берем в расчет бизнес.
Легкость обучения, легкость сопровождения, легкость входа в проект.
Разве не пруфы?, тяжело сопоставить с другими ЯП, разве минус языка? нет, это огромный плюс, но плюс для кого? для программиста со стажем у которого есть желание и потребность как у инженера повысить свою планку, или у джуна повысить свою зп… зыбки эти холивары
Тут скорее проблема в практике, то есть думать по разному сложно, человек ищет одну сторону мышления, а потом применяет еще дополнительные если у него есть такая возможность, для этого и нужна практика.
Допустим нам надо решить проблему 2+2. Мы можем думать в формате ООП и скормить объекту x,y конструктору, но можем передать аргументы в функцию, а можем просто из функции без параметров вернуть 4.
Как правильно поступить?
В одном из методов нам нужно создать класс отвечающий за инкапсуляцию и т.д…
В другом чистую функцию…
В дгугом просто забить и выполнить задание.
Но с другой стороны, легко объяснить не процесс формирования цифр, передачи параметров, а скорее проще объяснить состояние инкаплсулированного стейта в объекте, при всем при этом, легко в голове почти у каждого среднестатистического человека укладывается ограниченный контекст, особенно если предметная область еще не близка.
Вот даже поспорить не могу, по одной причине, если я сам до конца многие подходы не понимаю, то вряд-ли могу объяснить просто.
Хотя те вещи которые я объясняю они на мой взгляд читабелнее.
Но факт остается фактом… Моя не очень сильная компетенция в данном вопросе может родить непонимание.
Извиняюсь, может влез в диалог не красиво и поспешно.
Но, есть огромное но, это бизнес, не всегда получается удерживать высококвалифицированных программистов, а еще есть задачи которые должны решать менее оплачиваемые программисты, не потому как я этого хочу, но есть просто бизнес. И именно этому бизнесу так удобнее. Golang для ниши serviceSide более успешен. Со своим низким порогом входа, вспоминаю шутку «Программисты делают все что бы они были не нужны», а так же вспоминаю прочитанную историю когда Си программисты считались низкоквалифицированными и Asm было профессионально, а Си уныло и детский сад. Куда катиться бизнес, туда катиться и программирование и спорить об этом бесполезно
Что касается golang, то его синтаксис, его подход далек от простоты, все же это язык для программистов. Но именно для программистов он прост как 2 рубля.
От сюда наверное и хайп вокруг него, особенно когда нужно разрабатывать проекты с большой скорость, в своей нише, да еще и с программистами далекими от 7-10 лет стажа(цифры примерно на бум). Лично этим он меня и подкупает, просто изучить, просто объяснить, ну и бизнес вроде страдать не должен с его скоростью развития, хотя в проде еще не использовал.
В ООП который мейнстрим, важна инкапсуляция, тоесть мы забываем про иммутабельность, в ФП иммутабельность вроде как уже является основопологающей вещью, так как у нас могут быть только вычисляемые выражения. И да согласен что нельзя выкинуть от туда наследование, но к нему надо относиться осторожно, тоесть нельзя переводить наследование на уровень переиспользованию кода, а нужно придерживаться абстракций. В ФП я так понимаю наследования можно добиться через функции высшего порядка, или просто применения разных функций к одним и тем же данным или подобия дженерикам, вполне возможно ФП накладывает более строгий подход.
Я не сильно силен в ФП, от сюда и вопрос, а разве нет подобия наследования в ФП, только оно вполне возможно выглядит иначе?
я помню когда-то в юношестве тоже творчеством восторгался, рисование, игра на гитаре в группе, программирование…
творчество это очень интересно конечно, но только от него выхлопа как правило 8%, а остальное в помойку, с годами это проходит и приходит понимание…
А тут уж инженерная работенка… и да, оно еще интереснее, творческий процесс не пропадает, но пропадает бесполезное творчество. Надо сделать так что бы уложиться в ограничения ПО, и паттерны тут не спасают), и можно форкнуть стороннюю либу, и послать пул реквест)
На мой взгляд юношеский максимализм и нытье, не в обиду автору(хотя конечно понимаю что слова обидные, уж извините)
1) Люди и взаимодействие важнее процессов и инструментов;
изучение было с С, потом С++, потом Java…
сейчас в основом Haskell, все хорошо.
Было время когда я почти полгода рефакторил проект, просто пипец был лютейщий… ад.
Пытался привести это в порядок и оставить после себя читаемый код.
Потом я уже писал свой код и вроде доработки после меня шли нормально, ну я надеюсь))
Потом попался код как в первом случае… о боже я тяжело его воспринимал, вспоминая как я легко читал бредятину из первого случая, просто тогда я привык.
Вопрос на засыпку, а писать легко читаемый код это не искусство случаем?
если и так все ок, и продукт укладывается в функционал который от него требуют?
Хотя я убеждаюсь в том что лучше мешать ООП и ФП, пока мое субъективное мнение.
Простая причина, это почти либа при которой можно девелопить вещи имея стандартные средства для микросервисов, быстро изучается, тяжело отстрелить себе ногу…
а синтаксис и питоновцы, хотя самому нравится питон… могу предположить что go еще более строгий и минимум скрывает своих задвигов за сахаром, как это делают другие интерпретируемые языки
Извините за такой абстрактный ответ
Но скорее я сейчас говорю о том как быстрее и легче решить задачу.
Воспринимать это как объект(ООП), как процесс(ФП), как просто должное и не городить абстракции вокруг задачи(императивное...)?
разносторонность субъективная вещь на мой взгяд, есть опыт, а он как раз субъективен.
Ради интереса возьмем размышления такого адепта как Егор Бугоенко и его отношением к ООП, но ведь во многих вопросах он прав, но чисто в технических нет(от сюда и так много споров и негодований), какое решение мы применим, скорее всего такое которое нам ближе)
Но опять берем в расчет бизнес.
Легкость обучения, легкость сопровождения, легкость входа в проект.
Разве не пруфы?, тяжело сопоставить с другими ЯП, разве минус языка? нет, это огромный плюс, но плюс для кого? для программиста со стажем у которого есть желание и потребность как у инженера повысить свою планку, или у джуна повысить свою зп… зыбки эти холивары
Допустим нам надо решить проблему 2+2. Мы можем думать в формате ООП и скормить объекту x,y конструктору, но можем передать аргументы в функцию, а можем просто из функции без параметров вернуть 4.
Как правильно поступить?
В одном из методов нам нужно создать класс отвечающий за инкапсуляцию и т.д…
В другом чистую функцию…
В дгугом просто забить и выполнить задание.
Хотя те вещи которые я объясняю они на мой взгляд читабелнее.
Но факт остается фактом… Моя не очень сильная компетенция в данном вопросе может родить непонимание.
Но, есть огромное но, это бизнес, не всегда получается удерживать высококвалифицированных программистов, а еще есть задачи которые должны решать менее оплачиваемые программисты, не потому как я этого хочу, но есть просто бизнес. И именно этому бизнесу так удобнее. Golang для ниши serviceSide более успешен. Со своим низким порогом входа, вспоминаю шутку «Программисты делают все что бы они были не нужны», а так же вспоминаю прочитанную историю когда Си программисты считались низкоквалифицированными и Asm было профессионально, а Си уныло и детский сад. Куда катиться бизнес, туда катиться и программирование и спорить об этом бесполезно
Что касается golang, то его синтаксис, его подход далек от простоты, все же это язык для программистов. Но именно для программистов он прост как 2 рубля.
От сюда наверное и хайп вокруг него, особенно когда нужно разрабатывать проекты с большой скорость, в своей нише, да еще и с программистами далекими от 7-10 лет стажа(цифры примерно на бум). Лично этим он меня и подкупает, просто изучить, просто объяснить, ну и бизнес вроде страдать не должен с его скоростью развития, хотя в проде еще не использовал.