Д
но тут же нет фп
Size: a a a
2020 July 21
Д
тут процедурщина
Д
и очень плохая
MB
А чем кстати отличается процедурщина от фп?
IG
Видимо, редактору сказали "сделай много кода" для версии js, и он просто скопировал user1_add... и user2_add...
S
А чем кстати отличается процедурщина от фп?
Возможно, императивностью 🤔
ИФ
тут процедурщина
Это просто погань какая-то. Поля указывать цифрами. Это какой-то ад 20-летней давности для пластиковых карт с 1кб памяти.
S
Ну и да, в процедурщине не делается упор на чистоту функций
ИФ
А чем кстати отличается процедурщина от фп?
наверное в продурщине принято менять (мутировать) стейт, но я не настоящий сварщик
AO
В фп функция first-class object
AB
А чем кстати отличается процедурщина от фп?
в современных языках границы уже настолько размыты, что оба ярлыка утратили большую часть смысла
TP
А чем кстати отличается процедурщина от фп?
Я думаю впорос стоит поставить по-другому:
«Что ФП добавляет к процедурщине?»
И смотреть на это стоит так: когда-то давно программистам приходилось писать огромные полотна кода где не было ничего кроме инструкций, меток и оператора GOTO, который мог прыгать по этим самым меткам.
Потом подумалось что это не очень удобно и было бы прикольно большую программу собирать из маленьких программ.
Вот вам процедурное программирование (появление процедур/подпрограмм).
А потом уже ооп («че-то всё в одной куче, давайте процедуры сгруппируем по смыслу, положим их в коробочки (объекты) и пусть они между собой сообщениями меняются»)
и фп («а давайте сделаем чтобы одни процедуры передавались в качестве параметров другим процедурам»).
P.S. Никакого таймлайна не соблюдал и понятно что за каждыми подходами были свои идеи. Основная мысль, которую я хотел передать:
парадигмы программирования не противоречат друг другу, каждая просто добавляет что-то к существующим приёмам
«Что ФП добавляет к процедурщине?»
И смотреть на это стоит так: когда-то давно программистам приходилось писать огромные полотна кода где не было ничего кроме инструкций, меток и оператора GOTO, который мог прыгать по этим самым меткам.
Потом подумалось что это не очень удобно и было бы прикольно большую программу собирать из маленьких программ.
Вот вам процедурное программирование (появление процедур/подпрограмм).
А потом уже ооп («че-то всё в одной куче, давайте процедуры сгруппируем по смыслу, положим их в коробочки (объекты) и пусть они между собой сообщениями меняются»)
и фп («а давайте сделаем чтобы одни процедуры передавались в качестве параметров другим процедурам»).
P.S. Никакого таймлайна не соблюдал и понятно что за каждыми подходами были свои идеи. Основная мысль, которую я хотел передать:
парадигмы программирования не противоречат друг другу, каждая просто добавляет что-то к существующим приёмам
M
наверное в продурщине принято менять (мутировать) стейт, но я не настоящий сварщик
Нам в универе на первом курсе говорили, что функции возвращают что-то, а процедуры - нет, но мутят дела со стейтом или сайд-эффектами занимаются.
MK
Объекты хороши для представления устройств.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
TP
Объекты хороши для представления устройств.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
А я думал это всё файл 😄
OR
В duct есть такая вещь, как boundary
MK
А я думал это всё файл 😄
И файл это объект
OR
Вполне можно делать это объектом, ради того, чтобы был некий контракт.
DL
Объекты хороши для представления устройств.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
Коннект к базе это объект. Стандартный вывод - объект.
Вроде бы в этом чате подглядел, не помню кто сказал.
Почему не хэшмапа?
MK
Почему не хэшмапа?
Устройства stateful