#процедурное_программирование — Public Fediverse posts

[Перевод] Что такое Реактивное Программирование

Реактивность может значительно упростить реализацию надёжных программ. Давайте рассмотрим, что нам нужно для её реализации и какие парадигмы реактивного программирования бывают… Отреагировать на статью

https://habr.com/ru/articles/1033088/

#реактивное_программирование #функциональное_программирование #объектное_программирование #процедурное_программирование

Лингвистическая относительность в программировании — как наше мышление определяет выбор языка и стиль кодирования

Поводом к написанию предыдущей статьи «Шаблоны и принципы деления кода на классы» послужил случай с начинающим программистом, который обратился ко мне за помощью. Однако та история получила неожиданное продолжение, ставшее, в свою очередь, одной из предпосылок уже для этой статьи. И видимо, волей судьбы или просто по забавному стечению обстоятельств, эта история оказалась напрямую связана с комментариями к первой статье, где в ходе жаркого диалога я затронул тему мышления и восприятия кода разработчиком. Так родилась идея поделиться накопившимися за 10-летний стаж наблюдениями и плодами размышлений: - Как стиль написания кода отражает образ мышления разработчика. - Как разработчики воспринимают код программы. - Почему один язык программирования, что называется, «заходит», а другой - нет.

https://habr.com/ru/companies/cinimex/articles/1013914/

#коддинг #java #python #программирование #функциональное_программирование #процедурное_программирование #ооп #ооп_программирование #языки_программирования #языки

Классификация парадигм программирования

Здравствуйте, меня зовут Дмитрий Карловский и я.. придерживаюсь следующей парадигмы мышления: всякое определение должно иметь чёткую границу между тем, что ему соответствует, и тем, что не соответствует. К сожалению, часто можно встретить споры о пересекающихся определениях, словно они взаимоисключают друг друга. Не менее часто можно встретить ложную дилемму между двумя терминами не покрывающими всё множество сущностей. Что ж, позвольте внести ясность и предложить вам непротиворечивую классификацию парадигм - подходов к написанию кода, во многом определяющих способ мышления человека по донесению задачи до кремниевого исполнителя. Аспекты классификации

https://habr.com/ru/articles/905292/

#Декларативное_программирование #Императивное_программирование #Функциональное_программирование #Процедурное_программирование #Реактивное_программирование #Интерактивное_программирование #Структурное_программирование #Множественная_диспетчеризация #Обобщенное_программирование #ооп

Путаясь в замыканиях

В комментах к статье " Синглтон - корень всех зол ", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании " все функции - синглтоны " (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что " функции не синглтоны, потому что существуют замыкания ". Я, конечно, " сварщик не настоящий " - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции. На мой субъективный взгляд, при таких вводных, нет никаких доводов за то, чтобы в приложении иметь более одного экземпляра чистой функции. Какой смысл иметь два экземпляра функции, если она не имеет побочных эффектов - для одних и тех же входных данных всегда возвращает один и тот же результат, вне зависимости от внешних условий? Ну? Вот и я думаю, что никакого. Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.

https://habr.com/ru/articles/875608/

#фунциональное_программирование #процедурное_программирование #замыкания #шаблоны_проектирования #внедрение_зависимостей #ооп