АНОНАСЫ, РАССКАЖИТЕ В ЧЕМ СУТЬ ФУНКЦИОНАЛЬНОГО ПРОГРАММИРОВАНИЯ?
P.S. ТАК ЧТО БЫ ДАЖЕ ПЕРВОКУРСНИК ПОНЯЛ.
P.P.S. НАХУЯ НУЖНЫ ЛЯМБДЫ? НА ВИД БОЛЕЕ СОКРАЩЁННАЯ ЗАПИСЬ ТОЛЬКО.
1. Проще описываются некоторые задачи, особенно - математические. В математике вообще туго с циклами и переходами.
2. Иммутабельность. В процесс не вмешивается внешняя среда и не влияет на вычисления - никто не поменяет тебе значение переменной посреди процесса.
ПОЧЕМУ ВЕЗДЕ ПИШУТ, ЧТО ЭТО ДЪЯВОЛЬСКИ СЛОЖНО ОСВОИТЬ?
РЕЧЬ НЕ ПРО МАТ ЗАДАЧИ.
Да нихуя там сложного нет. Оно просто другое.
Просто те, кто говорят сложна, путают сложно и непривычно.
Поясните физику за парадигмы программирования. Что-то нигде не нашёл понятного объяснения. Можно в двух словах о каждой.
На плюсах лямбда это просто сахарок, чтоб сделать код более локальным. Например, мне надобно указать предикат для std::find_if. Без лябмбы придется создавать отдельную функцию. А
анонимную лямбду прям впихиваешь в месте использования std::find_if.
Типо чистые функции это спасение от всего
нет
ПАЧЕМУ НЕТ?
ПАЧЕМУ НЕТ?
Задача брошенного камня под углом к горизонту. Ты можешь расписать уравнения кинематики для него, а можешь сводить его энергетический баланс. Или ещё как-нибудь, хуй знает, что ты там выдумаешь. Но результат ты и так и так получишь один и тот же, а вот твой способ решения задачи - это, можно сказать, "паттерн физики".
Потому что на практике побочные эффекты - наименьшая из проблем.
Самый говняк к хуевой организации работы и кривой архитектуре.
Ну и как бонус плюсы и минусы:
Плюсы:
1. Легко тестировать
2. Легко читать
3. Легко реюзать код
4. Легко рефокторить
Минусы:
1. ХУЙ НАПИШЕШЬ, СЕРЬЁЗНО, ПРОСТО ЗАБЕЙ, ОНО ТОГО НЕ СТОИТ.
Программирование = сингулярность большого взрыва где все перемешано, всякие goto и прочая шелуха. Никакого порядка и программы создаваясь сразу же распадаются
Парадигмы программирования = эпохи, которые забирая часть свободы поведения материи, способствуют развитию материи (программам)
То есть, можно сказать, что парадигмы программирования ничего не добавляют, а только убавляют, как бы указывая нам чем мы можем пользоваться, а чем нет
Надеюсь понятно обяснил
Ну это тебе тупо с фирмой не повезло.
Я смузи-быдлопрограммист (ЯП для зуммеров), предлагают вкатиться в Scala.
Заебало RESTы писать.
Это основные конвенциональные пути развития концепций, идей подхода к созданию кода. Мелкие задачи по большей части похуй как решать, гвоздь можно и компьютерным монитором забивать. Но когда проекты огромные, тянутся на десятилетия и ими заняты тысячи человек, нужно с умом подходить. И все, конечно, подходят по разному, у каждого своя философия. Но в ходе естественного отбора, а так же "так исторически сложилось" выживает небольшой ряд концепций.
Тем что на практике то что в чистых функиях тривиально а проблема в эффектах которых все равно дохуя
В итоге лишняя абстракция без задач
Scala нужна просто потому, что она есть, а на jvm других нормальных языков нет, кроме неё и самой java. остальное или помойка, типа котлина от шараш-конторы конченных долбоёбов или зомби, типа groovy.
С понижением зп для меня, но думаю потом смогу получить гешефт с гоев.
Работаю на кровавый ынтерпрайз SAP разработчик, там всем с фирмой не повезло.
Кроме, наверное, тех, кто разрабатывает сами фреймворки и VM для этого самого ынтерпрайза.
Нука поясни своими словами что такое монада
Функциональное программирование это когда тебя в жопу ебут.
Моноид из категории эндофункторов.
Это единственное, что я про них помню
Поясните за ООП. Нахуй оно нужно? Ведь большинство плагинчиков без него написано и все норм
> Хуй напишешь
Написать-то как раз не так сложно. Хуй прочитаешь потом этот код, вот в чем проблема. мимо архитект
Ну охуеть своими словами просто
В пизду, всё лето тщательно учил и конспектировал Луиса Атенсио, в итоге попытался всё это применить на своём пет-проекте и нихуя не получилось, почувствовал себя только дауном каким-то, в пизду это ФП, тем более, что нету нормальных либ на жс, которые бы в полной мере и комбинаторы и линзы и монады и функторы добавляли.
ЛЮБИТЕЛИ SICP ПОЯСНИТЕ.
Не всегда лямбда анонимная, по крайней мере точно не во всех языках.
Чтобы предметную область напилить на независимые друг от друга объекты. Точнее, зависимости будут, но только там, где надо.
Короче, распилить предметную область на конструктор лего, чтобы можно было легко блоки менять, не разъебенивая всю конструкцию к херам.
А потом приходит заказчик с новыми требованиями, и конструкци все равно приходится разъебенивать.
Монада, как я понял, это интерфейс, определяющий, каким образом должны храниться и извлекаться данные, а классы, реализующие этот интерфейс - монадические типы.
Чтобы хуяк-хуяк и в продакшен
Чтобы можно было менять макак на проекте без лишних денежных издержек
вопрос, чё я вообще изучаю? кем я буду на выходе?
омг, как в жс можно добавить монады когда нет нормальных типов?
Для этого не нужно ООП. Web-разработка наглядный пример.
>там всем с фирмой не повезло
соглы, слинял из сапа.
абапишь?
Модульность как архитектурная концепция часто реализуется посредством именно ООП и это не шуточки. И я даже не про паттерны
>>229045708
другими словами, прямо из определения:
ДЛЯ УПРАВЛЕНИЯ СЛОЖНОСТЬЮ
Да, охуенно, щас бы ебаные цепочки функций, где жёстко заданы выходные типы, и метопрограммирование в один ряд ставить
Всем приходится абапить, в той или иной степени, даже консалтам (пусть и в рамках отладки).
А так я BWшник.
Куда слинял?
Ебал apple
Задача:
Есть большое говно
Как сделать так, чтобы говно работало?
Популярное решение: разбить на много маленьких говняшек и заставить их общаться между собой чисто по делу
Тогда можно будет поменять одну говняшку на другую, в другой что-то подлатать и когда всё сломается, тебе не придётся лезть в остальные говняшки, потому что они точно не виноваты
ООП это просто очередная попытка решить эту задачу
Говно это для пидоров, это игрушка и есть, ничего серьёзнее лаб в универе на этом не напишешь.
И? Хуякам в продакшене от этого ни холодно, не жарко. Хуячить можно и без ООП, просто периодически переписывая все нахуй.
Аджайл! Прототипирование! Смузихлебство!
Какая мерзость
И холодно, и жарко, потому что дешевле с ООП
Можно через одно место, есть такой дядька, Луис Атенсио, он показал, через какое, до монад, когда просто про цепочки и конвейеры было мне книжка нравилась, но начиная с функторов и продолжая монадами какое-то натягивание совы на глобус началось, хотя мб тс решает эти проблемы, но чёт хз.
Не поверишь
Удобно. У тебя нет данных отдельно, и отдельно их обработчиков. Ты можешь сказать "Машинка N3, едь", и машинка поедет, потому, что класс Машина знает, что такое "едь". А еще ты можешь сказать, что есть Ездуны - Машина, поезд, велосипед. И сказать "Ездун №1, едь". Тебе похуй, что там под капотом.
Как с дисками в винде - тебе похуй, что это - HDD, флешка, сидюк, или виртуальный диск - благодаря магии полиморфизма и одинаковым интерфейсам ты ко всем ним обращаешься одинаково.
В долгосрочной перспективе - да. Но кого ебет долгосрочная перспектива, когда у тебя проект внедрения, и нужно, чтобы все работало позавчера?
Ты про конвейеры слышал?
Т.е если понравившийся мне плагин я захочу использовать в будущем и свободно его кастомизировать, добавлять в него новые функции лучше сразу переписать его по ООП?
void`ом
Если угадаешь с концепцией - да. Если не угадаешь, то придется переписывать. Чем сильнее неугадаешь, тем больше переписывать.
В ПРОМ-решениях взлетает только во фронтенде.
а все почему? потому что можно это написать, но, как один анон высказался, хуй потом прочитаешь.
типичные фронтенды, обычно (в зависимости от среды), пишутся в концепции WRITE ONCE RUN ONCE
Соответственно, на других языках получается то же самое. на фронте это еще терпимо, а вот бэк, написанный на ФП, можно сразу похоронить при любом изменении, а так же включении нового разработчика.
Особенно в ФП бесит концепция замыканий - тупо костыль, потому что запоминать состояния, оказывается, НАДО - DON'T YOU SAY!
В типовых случаях, в сколько-нибудь сложных проектах (а такие - почти все), получается лестница из N-уровней замыканий, в итоге ООП код на том же языке выглядит проще (SIC!)
Я ГЕШЕФТ С ГОЕВ ПОТОМ ПОЛУЧУ ИЛИ ДАЛЬШЕ СИДЕТЬ МИКРОСЕРВИСЫ КЛЕПАТЬ?
>лучше
Если ты только про себя, то нет
ооОО, брат, я тоже был бивишником.
Теперь дата инженегр.
Скучаешь, небось, в технологиях 20го века?
Веб разработка не предполагает поддержки и развития 2436510. ООП всё таки парадигма, которая заставляет тебя мыслить категориями разделения обязанностей. Хотя у меня в проекте есть класс, в котором 8500 строк и еще примерно столько-же в классах, его обслуживающих.
потом оказывается, что перед высером кто-то наелся ебаных веревочек, и все говняшки ими связаны - пронизаны.
Маня, ты нормальный фронт хоть раз видел? Какое в пизду ооп? Хотя судя по той хуйне, что ты про фронт и бэк пишешь - ответ очевиден...
>>229046354
переписывать по-любому придется, если будет изменение. По этому есть ООП, SOLID и прочая хрень, которая учит, как писать так, чтобы переписывать было проще и дешевле.
Если проект не меняется, он не живет
Миску риса.
не понял претензии
Каким из?
Тоже собираюсь поближе к датасайенсу валить. Но дело движется медленно.
Собственно, я не свалил из BW, потому что пообещали проект на Data Intelligence. Юпитерские ноутбуки, сгребание данных питоном, в общем все, как у людей.
РИС НЕ ЗАВЕЗЛИ, ТОЛЬКО ГРЕЧКУ.
это плохая штука которую могли придумать только в калифорнии.
Это просто макака, у которой начинает гореть от слова ФУЛЛСТЕК.
я работал на дата-саенс год, скучно пездец.
Data Intelligence - говно, как и остальное от САПа. сразу думай, куда валить дальше, вот тебе совет.
Где трудишься, если не секрет?
По поводу замыкание вообще хуйню спизданул. ФП - это не про то, что ничего запоминать не надо, ФП про разделение данных и логики для их обработки, очевидно, блять, что для конфигерирования каррированных абстракция нужны будут замыкания.
На российскую ресурсодобычу.
Свалил из одной, где платят мало, в другую, где платят в 2 раза больше.
> класс, в котором 8500 строк
GOD CLASS называется, антипаттерн
По ЗП, кстати, сильно просел при перекате?
>для конфигерирования каррированных абстракция
Посмотри на окружающий мир - все вокруг взаимосвязано и меняется. И у ООП и у ФП есть свои плюсы и минусы, утверждать что одно превосходит другое может только школотрон или студент, которые ничего реально не писали. Весь большой энтерпрайз почти всегда сидит на ООП, потому что там огромный клубок зависимостей и мутаций объектов. На ФП можно взамен реализовать набор микросервисов с односложными задачами, но в какой-то момент можно будет охуеть от их количества и их менеджмент уже будет не релаебл по ресурсам.
мимо-техлид
Попробуй без функционалки перевести например лист с размером в 10000, в какую нить другую коллекцию, например в мапу.
Не забудь туда еще фильтров пару навернуть ну и и чтобы побыстрее.
Сразу поймешь в чем соль
Молодец, так и надо.
Меня удручает только, что в SAP непонятен карьерный путь (как и во всем ИТ, впрочем).
я в банках тружусь.
удачно выбрал, не просел)
Чё такое лист, чё такое мапа?
Гавновкатыш
> утверждать что одно превосходит другое может только школотрон или студент, которые ничего реально не писали
да ладна?
>ФП - это не про то
> <X> - не для <Y>! <Y> НЕ НУЖНО
вот эту мантру от фанатов того или иного подхода постоянно слышу
Необходимое и достаточное вся хуйня
Жирно, зелено.
Дейкстра делал множество экстраординарных высказываний, если ты слепо им веришь только исходя из его авторитета - попробуй на досуге думать своей головой тоже
0% жира
>в SAP непонятен карьерный путь
Вполне можно работать на поддержке разрабом (а если хочется порулить, начальником отдела) до самой пенсии на не самой плохой ЗП.
Видел пару живых примеров.
Ну и перекат в консалты тоже опция, а там уже вверх по грейдам и фриланс. А SAPовский фриланс (особенно на Европу), сам понимаешь, это не за сраные крохи на апворке биться.
А, типа связанный список и ассоциативный массив, наверное
думал про заграницу перед перекатом, но чето ниче нормального не надумал.
Примеры старичков в управлении тоже видел, но их предельно мало, единицы.
Очень депрессивно все выглядело
как по мне так и с плюсами и с сишкой можно иметь дело. сишарп говно. жаба более менее.
однако считаю чувака более компетентным.
Хуйня еще в том, что часто ту или иную фичу отбрасываешь, а она, ОКАЗЫВАЕТСЯ НУЖНА.
и все катится по пизде, как ФП, так и ООП. Только ООП, при правильном подходе (что тоже, очень не часто), можно без лишней крови изменить. Про ФП в таких случаях писал выше, пара анонов то же самое писали.
>декларативное иммутабельное
Уверен? Не императивное, случайно?
>>229045810
>>229045938
>>229046221
>>229046713
>>229047118
Спасибо ответившим. Жаль что для меня (версталы) половина треда это жесткая абракадабра но уже стало многое понятно.
Абу благословил этот пост.
лол
eval там написано
>Примеры старичков в управлении тоже видел, но их предельно мало, единицы.
Ну дык рано же еще. Первое внедрение в 1994-95 годах было.
А старички - это все-таки ближе к 40 лет стажа.
Мне нечего сказать, когда я пишу маленькие процедуры под каждую задачу, а потом они складываются в другую процедуру, у меня поёт сердечко и всё работает
да к тому времени SAP, особенно BW, совсем перестанут ставить. И так его использует 20 компаний в РФ, а BW уже перестают использовать. ERP еще куда ни шло
Это отлично, когда так работает. У меня у самого так работает, пока оно у меня на руках, и не растет.
А когда появляется сложность, тогда трындец
Процедурный подход не есть плохо. Просто ООП и инфраструктура вокруг него лучше заточена под макак. Нарисовал UML-диаграмму, сгенерил из нее каркас, написал спеки, и нехай макака пустые места заполняет.
>>229048135
>И так его использует 20 компаний в РФ, а BW уже перестают использовать
Бля, не знаю, где там что перестают. Там, где я работаю, BWшников набирают, да и в принципе вакансий по BW не мало. Одно время было, да, когда BW собирались закапывать, особенно с выходом ханы и s/4. Но пока маятник движется в обратном направлении, как и в целом рынок SAP. Но да, в том виде, в котором раньше использовалось BW, теперь не используется. Это уже больше именно data warehouse, как и должно быть, а не ой, у нас что-то отчет долго формируется, давайте запихнем его в BWшный куб.
В смысле? Вообще никогда в своей это не пригодится, если ты умеешь в низкоуровневое программирование?
низкоуровневое, на то и низкоуровневое, что там нет этих абстракций. вот он и гордится.
блин, у меня в автопоиске 10-20 позиций по BW+HANA.
Запрашиваемую мной ЗП не дают еще до собеседования.
Короче, я перспектив че-то там не увидел совсем
200к на руки удалось выбивать + премии-хуемии.
Если ты 250 просил, то там да, сложно. Но это у любых разработчиков сложно, что ты "чистый" абапер, что еще кто.
230 просил. Давали скрепя сердце, и то, на позициях более близких к бизнес-аналитикам/методологам
Угу, знаю, ща вот надо его поведение менять в корне, но браться никто не хочет - все на хую вертели.
>В математике вообще туго с циклами
А как же рекуррентное задание последовательности?
да это типичная херня.
У меня на одном проекте был процедурный код на 1500 строк. Его пытались переписать 4 раза, 4 разных разработчика, в т.ч. я. Не удалось ни разу, так и работает в режиме легаси.
Бывают запущенные случаи
Императивщина - ето как раз циклы.
Да-да, где-то тут потолок и есть, дальше только консалт.
Но, с другой стороны, дата инженегр в банке тоже близок к бизнес-аналитикам.
Я рассматривал укат в консалтинг, но я глянул на то, как Accenture работают (да и сам SAP тоже), и что-то пыл поумерился.
Хуй с ним, с интенсивностью, там же еще обучение пользователей часто вменяют в обязанности, а это пиздец.
Я тебе в рот насру за такие экзерсисы с памятью.
Монада не совсем про типы.
это всё таки не совсем цикл в понимании процедурного ЯП, у него задачи другие - в процедурах цикл может быть и без какого-либо итератора или выходного значения, просто цикл ради повторения одного действия.
простота восприятия и масштабирования
математичность
* легко тестировать
Но это предельно однобокое восприятие парадигмы, на практике всё сильно зависит от задач и проекта.
Полностью всё хуярить на функциональщине верх уебанства, как и излишне усложнять простые решения при помощи ООП.
Именно поэтому современные не эзотерические языки позволяют совмещать два подхода.