Comments 75
Отвечу сразу всем вопрошающим:
это очень просто
напомню, что в "Началах" Эвклида аксиомы звучат примерно так:
От любой точки до любой точки можно провести прямую линию
И это не помешало вывести из этого всю геометрию.
Так что смотрите на выводы которые следуют, посмотрите на свой код, свой рабочий проект, то как вы управляете командой
Понимаю, что не все могут вот так легко делать следствия, тут всё же не геометрия, а область посложнее, но давайте попробуем на примере оценки языка программирования.
Даже в комментариях под этой статьёй Rust упомянули несколько раз, аж как новые веяния научной мысли, оценим этот язык
Сначала просто пойдём по аксиомам:
Суть языка в ограничении возможностей программиста ради победы над некими ошибками memory safety. Это приводит к появлению множества правил.
Вот вы создатель Rust и решили, что у вас в языке все типы можно перемещать с помощью memcpy. Это незначительное казалось бы ограничение приводит в итоге к двум разным видам копирования (trait clone / copy), появлению ещё одной языковой конструкции Pin нарушающей правила остального языка (такой тип перемещать нельзя) и ещё множеству правил, которые мешают программисту перенести мысль в код
Итак, первая аксиома нарушена, чтобы писать код на Rust придётся учитывать и создавать куда больше сущностей и взаимосвязей, чем на других языках.
Вторая аксиома также нарушена, ведь язык создан для борьбы с так называемым memory safety, хотя сегфолт это проявление ошибки, а не сама ошибка. Создавать целый язык для борьбы с симптомами, вместо причин - это странно
Если язык хочет бороться с причинами логических ошибок, то он должен быть понятнее и выразительнее других языков, так чтобы программист напрямую выражал свои мысли в коде, а не обходя ограничения языка. Если пишущий код постоянно думает не о задаче, а о том как бы это вообще написать - у него будет больше логических ошибок
Аксиома третья - код читают другие люди. В Rust ввиду вышеописанных причин код получается сложнее и рассчитан он на чтение компилятором Rust, который по задумке авторов проверит почти все ошибки. Но про то, что код будут читать и люди думали там вероятно мало. По опросам это один из самых сложных языков для чтения кода из широкоиспользуемых
И наконец четвертая аксиома о переиспользовании кода. Даёт ли язык Rust возможности писать периспользуемые инструменты? Даёт, но хуже чем другие языки с которыми он конкурирует из-за ограничений языка на уровне дженериков. К тому же на Rust куда сложнее написать переиспользуемые структуры данных из-за правил языка, некоторые интерфейсы невозможно реализовать из-за safety правил, как итог, даже стандартная библиотека Rust гораздо более ограничена в возможностях, чем аналогичные структуры данных и алгоритмы в C++
Итог: Rust нарушает все аксиомы SLON
Я сейчас обучаюсь python и могу сказть что одни и те же задачи люди решают по разному. Есть вопрос только в выборе инструментов, языка и метода.
Ни разу не упоминается реактивное программирование. Оно не существует?
Своевременная оптимизация тоже зло?
Ни разу не упоминается реактивное программирование. Оно не существует?
"ну это же просто одна из надстроек"(цэ)
так в статье и квантовая физика не упоминается, она не существует?)
Как и другие два-три десятка парадигм, не считая подвидов и гибридов.
Многие рассуждают о проектах в терминах ООП, ФП или какой-то другой подобной концепции.
Пусть реактивное программирование будет входить в другую подобную концепцию.
Статья ориентирована на немного другое:
А с точки зрения этой статьи - они не дают понимания о чём же действительно нужно думать при разработке, из них не следует прямых практических выводов
Это просто способы структурировать код со своими преимуществами.
Про своевременную оптимизацию:
Это точно не "зло", поэтому она и называется своевременной, то есть, появляющейся в нужный момент, то есть, когда нужна.
Преждевременная - зло, потому что зачем портить дорогу, по которой будешь возвращаться обратно? На обратном пути - пожалуйста. Портить, потому что оптимизация зачастую несёт за собой вид кода из того места (хотя работает просто отлично) для других людей и даже для тебя через пять минут.
-----
И да, я не разбираюсь в вопросе "реактивного программирования", поясните, пожалуйста), буду благодарен. Или ссылочку, где чайнику всё объяснят.
Реактивное программирование заставляет думать про потоки данных.
Осталось дело за малым - договориться о том, что считать своевременным.
Оптимизация никогда не является «своевременной». Она всегда «преждевременная».
Так вот из-за кого у нас весь софт сейчас так сильно тормозит.
хорошо, раскладываем код на определённые части, если этого ещё не сделали. Создаём оптимизированные версии каждой части, выкладываем в релиз, у себя оставляем неоптимизированные, но читаемые версии. Перед следующим релизом переоптимизируем изменённые части.
Выглядит неудобно?
Конечно, но зато вопроса преждевременности и своевременности больше не должно быть... Появляется вопрос актуальности этой идеи.
В чем смысл статьи? Прочитал целый набор банальных и/или общеизвестных утверждений. Не увидел никакой философии.
Отдельное спасибо за "меньше сущностей и меньше взаимодействия". Было смешно.
Прочитал целый набор банальных и/или общеизвестных утверждений
из которых никто не исходит когда занимается программированием, вместо простых и понятных вещей ориентируются на что-то совсем другое и получается соответственно
SOLID, DRY, KISS, YAGNI — всё это давно сформулировано, обосновано и проверено практикой. Но с завидным постоянством появляются новые "революционные принципы", в которых узнаются старые идеи, только под другим соусом. Такое ощущение, что у новичков наступает стадия «изобретения философского велосипеда».
Осталось дождаться, когда кто-то на Хабре представит миру "новаторские архитектурные концепты", а по сути — очередную реинкарнацию паттернов из книги "Банды четырёх". Назовёт их S.T.A.G. или D.O.N.K.E.Y. и объяснит, почему это next big thing.
Конечно, путь проб и ошибок — важная часть роста, но знание классики позволяет экономить годы. И время на псевдооткрытия тоже.
solid - сборник размытых антипаттернов, dry провоцирует оверинжениринг и повышает хрупкость, yagni - девиз безответственных разрабов. Какую ещё глупую аббревиатуру скажете?
dry провоцирует оверинжениринг и повышает хрупкость
вы в своём $mol повторяющиеся операции не выносили в отдельные утилиты, а прям ctrl+c ctrl+v в нужных местах да и всё?
Классика) Кто-то опять решил, что принципы проектирования мешают творить великий монолит на 30 тысяч строк в одном классе.
SRP мешает писать God-классы, где всё: от бизнес-логики до отправки email и рисования графиков.
OCP бесит, потому что расширять — сложно, а переписать всё к чёрту — приятно и быстро (до следующей итерации боли).
LSP — слишком академично, ведь кто в проде проверяет, что Square — не Rectangle? Ну, кроме баг-трекера, конечно.
ISP раздражает, ведь лучше засунуть makeCoffee() в общий интерфейс IWorker, чем подумать, кто реально это должен делать.
DIP вообще анекдот: зачем абстракции, когда можно new MyService() и страдать от tightly coupled ада?
Не нравится SOLID? Не вопрос. Но тогда не удивляйтесь, что рефакторинг вашего кода вызывает PTSD у команды, а тесты пишутся через боль и жертвоприношения)
Подробный анализ принципов SOLID можете найти в этом самопиаре: https://page.hyoo.ru/#!=g5r6ly_999055
Поправочка:
...великий монолит на 30 тысяч строк в одном методе.
Желательно в одну короткую строку, но чтобы задачу выполняло.
Увидел в названии "философия", заинтересовался, прочитал. Мда, и правда "философия".
Никто давно не пытается выводить теорий о том как правильно писать код.
Да ну. А Rust откуда тогда? Как пытались, так и пытаются, только раньше эти попытки было разумно обсуждать со всеми, а теперь, при джунах и прочая - нет.
Что при взгляде с позиции джуна или вообще со стороны, действительно кажется, что пытаются меньше - видно только то, что среди теорий отобрали и толкали в массы. Сначала одни идеи когда главной задачей были вычисления, потом другие, когда главной задачей стала реализация гуйных приблуд, потом третьи, когда ей стала генерация HTML.
Долгое время Главная Задача не менялась, а прямо сейчас ей стала эксплуатация ИИ, но вы этого не видите, ибо соответствующие теории ещё на этапе отбора. Ничего, начнут толкать - мало не покажется.
Сейчас всё изменилось
Ничего не изменилось - как стояла задача контроля над сложностью, так и стоит. Разве что безумным гуглингом, лихой копипастой, а теперь и вайбкодингом, стало можно добиваться большего, иными словами, не решать эту задачу дольше.
Так как мы обсуждаем архитектуру, сразу надо сказать что она имеет смысл только в достаточно больших, изменяющихся проектах.
Ну, как бы см. выше. Засада в том, что любой проект внезапно может превратиться в большой и изменяющийся. Особенно если окажется успешен хоть в каком-то смысле.
Из этого следует такое свойства кода как интуитивность: а интуиция и ход мышления у всех людей разный.
Ну и что? Если человек понимает только себя - с этим к медикам.
Из этого следует другое - логика в коде должна быть, причём единообразным образом. Идеал на большой кодовой базе может быть недостижим, а вот требовать чтобы после внесения любого изменения логика становилась более единообразной - это возможно.
Как без дороги было бы бессмысленно строить магазин, так и если для создания нейросети вам нужно написать свой Numpy - вы даже не начнёте.
Ну, я то может и не начну, а тот же Джобс начинал дважды, с Objective-C и Swift. В отличии от других начинателей, он то точно имел в виду конкретную цель.
Для начала нужно хотя бы осознать важность IT инфраструктуры.
Кому нужно? Моё вот, после пятидесяти лет наблюдений, впечатление - некие лица очень не хотят чтобы в ИТ вообще возникла инфраструктура. И W^X политика - оттуда же. А инфраструктура всё прорывается, вот и приходится заливать её потоком "новых технологий".
Главное что надо понять - нужная архитектура и используемые инструменты зависят от задачи и людей которые задачу выполняют.
Полноту по Тюрингу отменили? Это так только с точки зрения эффективного менеджера который выбирает лучший момент свалить вместе с бонусами.
Засада в том, что да, инструменты и архитектура, понимаемая как грубые архитектурные ошибки совершённые первыми, влияют на конечный вид проекта, а вот в какую сторону - люди уровнем ниже Джобса не скажут.
Нет одного решения подходящего всем, но есть совсем немного основополагающих принципов, их я и попытался изложить в этой статье.
Тут внутреннее противоречие. Основопологающие принципы тоже могут рассматриваться как общее решение. На уровне философии лучше вообще не задумываться о том, что куда подходит. SLON есть - философу большего и не нужно.
Человечеству только предстоит понять как работать в условиях, когда средством производства является человек, но точно не стоит пытаться свести разработку к заводу по производству стандартизованных строк кода, это точно не работает
Человечество всё поняло не позднее появления первых монастырей. И беда в том, что это работает, хотя и, к счастью, не всегда. Системные требования Windows 11 ясно показывают - ещё как работает, особенно в (не)умелых руках.
Полноту по Тюрингу отменили?
ну можете попробовать выбрать для проекта brainfuck как язык, посмотрим как полнота по тьюрингу поможет завершить начинание
Да ну. А Rust откуда тогда?
Эх, молодежь... Ну про Ada хоть почитайте и не позорьтесь.
Сначала идёт создание инструментов для создания проекта. На этом этапе контрпродуктивно вводить много разработчиков в проект, потому что им ещё нечем "строить", а мешать они будут.
мешать они будут и потом, поэтому, оценив риски, нужно еще немного подумать и прийти к некоторой средней численности разработчиков, а потом плясать вокруг неё. в идеале, конечно.
Вопрос про сложность. Сколько GNOME создает структур в памяти для простой кнопки?
Зашел в статью из-за картинки.
Картинку не увидел.
Напомнило один фильм про хасидов - ортодоксальных евреев. Всю свою жизнь проводят в изучении Торы, просиживая в ешивах, заучивая тексты и споря на темы типа "допустимо ли привязывать лодку к рыбе в субботу?"
Вот это оно самое: ООП, не ООП, типизация, не типизация, вот так правильно, а вот так неправильно...
Может быть тут есть настоящие хасиды, пояснят, что фильм это вранье, и на самом деле это Очень Важные Вещи, просто не для всех понятные?
Как и с истинно правильным программированием?
Похоже, что мысли у автора рождались в процесс написания статьи, но с небольшим лагом...
"Но это не точно" - (с).
Ваш слон выглядит странно и некоторые вещи очень очевидны. Да и в чем тут тупик? Может про ООП так много говорят, потому что его насаждали в языках (Java, c#) Я например нахожу его очень удобным и совсем не тупиковым, если вы про это.
Отвечу сразу всем вопрошающим:
это очень просто
напомню, что в "Началах" Эвклида аксиомы звучат примерно так:
От любой точки до любой точки можно провести прямую линию
И это не помешало вывести из этого всю геометрию.
Так что смотрите на выводы которые следуют, посмотрите на свой код, свой рабочий проект, то как вы управляете командой
Понимаю, что не все могут вот так легко делать следствия, тут всё же не геометрия, а область посложнее, но давайте попробуем на примере оценки языка программирования.
Даже в комментариях под этой статьёй Rust упомянули несколько раз, аж как новые веяния научной мысли, оценим этот язык
Сначала просто пойдём по аксиомам:
Суть языка в ограничении возможностей программиста ради победы над некими ошибками memory safety. Это приводит к появлению множества правил.
Вот вы создатель Rust и решили, что у вас в языке все типы можно перемещать с помощью memcpy. Это незначительное казалось бы ограничение приводит в итоге к двум разным видам копирования (trait clone / copy), появлению ещё одной языковой конструкции Pin нарушающей правила остального языка (такой тип перемещать нельзя) и ещё множеству правил, которые мешают программисту перенести мысль в код
Итак, первая аксиома нарушена, чтобы писать код на Rust придётся учитывать и создавать куда больше сущностей и взаимосвязей, чем на других языках.
Вторая аксиома также нарушена, ведь язык создан для борьбы с так называемым memory safety, хотя сегфолт это проявление ошибки, а не сама ошибка. Создавать целый язык для борьбы с симптомами, вместо причин - это странно
Если язык хочет бороться с причинами логических ошибок, то он должен быть понятнее и выразительнее других языков, так чтобы программист напрямую выражал свои мысли в коде, а не обходя ограничения языка. Если пишущий код постоянно думает не о задаче, а о том как бы это вообще написать - у него будет больше логических ошибок
Аксиома третья - код читают другие люди. В Rust ввиду вышеописанных причин код получается сложнее и рассчитан он на чтение компилятором Rust, который по задумке авторов проверит почти все ошибки. Но про то, что код будут читать и люди думали там вероятно мало. По опросам это один из самых сложных языков для чтения кода из широкоиспользуемых
И наконец четвертая аксиома о переиспользовании кода. Даёт ли язык Rust возможности писать периспользуемые инструменты? Даёт, но хуже чем другие языки с которыми он конкурирует из-за ограничений языка на уровне дженериков. К тому же на Rust куда сложнее написать переиспользуемые структуры данных из-за правил языка, некоторые интерфейсы невозможно реализовать из-за safety правил, как итог, даже стандартная библиотека Rust гораздо более ограничена в возможностях, чем аналогичные структуры данных и алгоритмы в C++
Итог: Rust нарушает все аксиомы SLON
Никто давно не пытается выводить теорий о том как правильно писать код.
Может потому, что "теории как правильно писать код" уже вывели в период 30-60-х годов прошлого века?
От примитивной работы одиночки, пусть и с нетривиальными внутренними закономерностями, программирование вышло на уровень всего общества. Теперь это работа всепланетного уровня. Примеры вы знаете, на одном из них вы читаете этот текст.
Ну вот и ответ на заявочку автора в заголовке. Ничего общего между программированием, как понимает это автор, то есть в примитивном смысле написания некоего "кода", и происходящим на самом деле просто нет. Отсюда и весь это безумный плач про потерянное качество и прочую "философию". Просто люди не понимают очевидных вещей, хотя вроде бы изучали в институтах интегралы и прочие непростые штучки.
К сожалению, в обществе царит тотальная безграмотность в области понимания самого общества. И разумеется, если человек не знает, сколько будет дважды два, то он и не способен перейти к каким-нибудь синусам. Так же и с программированием - люди знают лишь техническую сторону, а вот социальную - просто не видят, либо видят краем глаза, но полностью игнорируют. Но именно в социальной части есть все ответы. Подчеркну - все. Но туда тупо не смотрят.
Вывод: всем желающим понимания нужно заниматься ликвидацией собственной безграмотности. И забить на самоуверенность, привитую "пониманием" ООП и тому подобного технического.
Хотя, сказать честно, общество можно рассматривать как техническую систему. Но даже в эту сторону люди не хотят смотреть. Отчасти из-за реально существующей сложности объекта. Но уж извините, вы же умные? Интегралы понимаете? ООП опять же. Вот и включите мозг.
Но да, если дважды два не знаешь, то действительно долго придётся разбираться, особенно если самостоятельно. Вот никто и не разбирается.
ломая совместимость проекта с git
Не могу себе представить, что значит "совместимость с git". Но предполагаю, что если разработчик способен эту совместимость сломать (что бы это ни значило), то ему ещё рано думать о таких вещах, как "философия программирования". Чтобы в программировании строить какую-то философию, сначала нужно постичь культуру разработки.
вам стоит устроиться хотя бы на первую работу и там поймете как можно сломать совместимость с гитом
Последний раз я работал с проектами без гита 9 или 10 лет назад. С тех пор я работал на многих и многих десятках проектов (наверное под сотню), и всегда везде был гит. Каждый день делаю pull, push, commit, rebase, checkout разрешаю конфликты. Иногда делаю reset, clean и cherry pick. Но в упор не понимаю, что такое "несовместимость с гитом". Можете объяснить?
Прямо сейчас очень много компаний либо использующих нечто другое кроме гита, либо не использующих системы контроля версий вообще
Вариантов сломать много - по какой то причине хранить бинарные файлы и картинки в гите и замедлять всё, какие то геймдев проекты
Сделать супер пупер виртуальную файловую систему и сделать так, что без неё проект не работает. У вас ломается и гит и ещё куча инструментов.
Сделать невероятного размера проект без необходимости и напихать туда вообще всё, так чтобы git status шёл 2 минуты, такие специалисты есть в microsoft
Способов много
Ну геймдев понятно. Git в целом не очень полезен для хранения графики, даже векторной. Там, вероятно, есть какие-то свои заморочки. Но я с геймдевом никогда не работал, и понятия не имею, как там у них всё устроено, поэтому гадать не буду.
Что касается всяких гигантов типа майкрософт. Тут же надо понимать, что они пилят многие продукты десятилетиями, и им самим приходится мириться с их legacy и с собственными решениями, принятыми в прошлом, о которых, возможно они сейчас жалеют. В опыте таких компаний важно не то, как они делают, а то, как бы они сами не сделали в следующий раз. Помню была тут на Хабре статья, почему Facebook используют mercurial, а не git. По прочтению этой статьи я пришёл к выводу, что сама по себе идея монорепозиториев - редкостное днище.
Но вот эти случаи, когда копания не использует системы контроля версий в принципе, или загаживает свои репозитории бинарниками, дампами базы, всякими node_modules - это именно отсутствие культуры разработки. Такие способы ведения разработки нельзя рассматривать всерьёз - это просто позор индустрии.
Git в целом не очень полезен для хранения графики, даже векторной.
Ну, не соглашусь. По крайней мере SVG представляет собой XML. Так вот, если git хорошо приспособлен для хранения XML и родственные исходники – HTML например, то значит он хорошо приспособлен и для хранения SVG. Конечно, здесь остается и вопрос о графических редакторах. Если они все время перетасовывают код изображения при малейшем изменении, то конечно такой код отслеживать будет совершенно невозможно. Но ведь, это в силе и для редакторов кода. Благо они обычно управляют код намного лучше.
Формально да, но на практике работа с svg в git ничем не отличается от работы с png или jpeg. Да, есть конечно случаи, когда маленькую SVG можно подредактировать прямо в коде. И потом это можно поревьювить. Можно даже совместно работать над таким файлом - например, один меняет цвет, другой размер. Но это только в каких-то единичных случаях. Главное преимущество гита - возможность совместной работы, когда 10 человек одновременно вносят изменения в один файл и потом это всё можно слить, пусть даже и с конфликтами. Но при работе с SVG такое почти никогда не делают и там принцип "кто последний, тот и папа". Точно такой же принцип, как при работе с бинарными файлами. Да, есть история версий. Да, гитом это удобно доставлять в любую среду. И очень круто, что гит позволяет хранить такие файлы. Но гит не позволяет вести разработку таких файлов. Если мы говорим об исходном коде, то с помощью git blame можно узнать, кто что, когда и почему сделал. При работе с графикой, в том числе и с SVG сравнение двух версий через Git не даст никакой полезной информации.
Именно поэтому сам процесс разработки графики идёт в совершенно других средах, например, Figma. И оттуда попадает в Git уже как готовый артефакт.
Большой xml с большой и сложной вложенностью очень плохо мержится. Глазам и ментальному здоровью очень больно. Хотя мой опыт был не с svg, а с форматом схем camunda.
блобы туда пихайте. побольше размером и меняйте их почаще.
За такое принято ссаной тряпкой по морде бить. И лечить потом это либо удалением ветки, либо переписыванием истории через push --force.
Но тут всё равно есть одно НО. Допустим, кто-то по неопытности закоммитил папку с ежедневными инкрементными бэкапами, и потом работает, каждый день делая git add --all, и никто это не ревьювит. Да, репозиторий раздуется, будет медленно работать. Сам git будет тормозить. Но это всё равно не сделает проект "несовместимым с git". Даже если гитхаб или гитлаб отвалятся, не захотят принимать коммиты, сам гит ведь будет работать.
В гите довольно сильный write amplification - даже минимально измененный блоб (т.е файл) - меняет tree и все tree куда оно входит, а они могут быть довольно большими.
За годы может накопиться довольно много. Именно поэтому столько плясок вокруг монореп -- гит плохо вывозит монорепы, и не абстрагировал сторейдж, что бы хоть что-то могло вывезти.
Т.е по сути проект "несовместимый с гит" это просто большая монорепа.
Впрочем, статья смешная, а комент я написал тоже ради лулзов. По сути вы правы.
А куда делась КДПВ? Я зашел только чтобы увидеть ее полностью. Ее нет, а взамен мутные философии. Автор не делай так!
Есть "Тройки Хоара" для императивного и "Соответствие Карри — Ховарда" для функционального программирования.
Как экономист, как специалист, который мучается из-за очень плохой автоматизации, как специалист, который годами воюет с айтишниками, которые всеми силами мешают мне делать свою автоматизацию, пришел я к следующим выводам:
Надёжных, бесплатных, с открытым кодом инструментов для быстрой автоматизации мышкой уже написано предостаточно, но..!
Всеми правдами и неправдами эти инструменты дискредитируются айтишными компаниями
Причина в экономике, а именно: на разработке удобных и эффективных инструментах много денег не заработаешь, т к если потребители начнут использовать удобный дешёвый и эффективный инструмент, то завтра никому не нужны будут эти айтишные компании.
Корпоративные айтишные решения - это рынок лимонов, продают красивую картинку, под которой навоз.
5. Чтобы поднять свою ценность и эксклюзивность, айтишные компании сознательно усложняют свои решения и используемые инструменты. И нередко врут клиентам, чтобы накрутить цену.
Очень много философских тем можно поднять и изучать, если перешагнуть эту выдуманную сложность ООП и прочее, т.к. это также распространяемая выдуманная сложность компаний и частных лиц, которые на этом зарабатывают. Решения сложности давно имеются и применяются, читайте и изучайте чужой код - это очень интересно и познавательно.
вы просто не видите всю ситуацию целиком. Возможно визуальных инструментов хватает для конкретно ваших задач, что не делает их достаточными для большинства случаев. И уж тем более вы не сталкивались с ситуацией
"тут почти как надо, только мой инструмент не позволяет мелочь X"
"чтооо?! почему 2 мемяца разработки?! Оно же работает ПОЧТИ как надо, нужна всего 1 кнопка!!!"
Универсальные решения или позволяют решить узки спектор задач, или на столько сложны, что зачастую проще написать свое решение узкой задачи, чем настраивать монстров.
Айтишных контор слишком много что-бы описанный вами заговор был возможным. Если продукт действительно нужен платежеспособной аудитории - он бы был успешен
Теория программирования данным-давно имеется. Она называется Математика. Программирование изначально было создано для того, чтобы имеющиеся математические формулы воплотить в реальные вычислительные результаты.
Название языка Fortran расшифровывается как formula translator (перевод формул). Имеется ввиду перевод, переложение математических формул в машинный код.
Но так как большинство обычных программистов на самом деле далеки от математики, и являются всего-лишь инженерами, то и была придумана большущая куча всего для помощи нам, скудоумным. И не стоит расстраиваться по этому поводу, ведь наша основная задача - не теорией заниматься, а решать проблемы бизнеса на практике. И всё.
Ерунда какая-то. Мягко говоря. Я системный программист и у нас было 5 лет математики.
Сводить программирование к математике, это глупо.
Вы, наверное, не дочитали мой комментарий. Я говорил о том, что математика - это теория, стоящая за программированием. Городить что-то другое в плане теории - неэффективно. Надо избавляться от лишних сущностей, а не плодить их. Статистика, матричные вычисления, работа с векторами, большие языковые модели - это всё чистая математика.
Но мы гораздо чаще решаем практические проблемы из реальной жизни. Поэтому, глупо искать какую-то теорию. Искать надо лучшие практики, выбирать среди них те, которые подходят конкретно под вашу задачу. Не нужна особая теория. Если ОП, ФП и прочие занудные догмы обременяют вас, делают процесс разработки невыносимым, выбросить это всё на свалку, оставив только нужные вам кусочки! Я встречал такие странные требования бизнеса, которые сродни выражению 2 х 2 = 5. Какая тут мне поможет теория???
много чего не ложится на математику (по крайней мере не уровня квантовой физики). Например, чтение с диска, ожидание ввода пользователя, сеть и т.п. Да и многие бизнес-процессы плохо формализуются. Так то давно есть функциональные языки программирования и автоматическое доказательство непротиворечивости программы, но что-то чуда не произошло.
Мультиагентные системы на основе нейросетей. Чем не развитие философии. Довольно активно развивается
Да уж...
Есть Дональд Кнут с его "Искусством программирования"
Есть Эдсгер Дейкстра с его "Дисциплиной программирования"
Есть Дэвид Грис с его "Наукой программирования" (фактически - пересказ книги Дейкстра в более строгой форме)
Если говорить о философии, то книга Дейкстра - глубже всех (и откровенно сказать - единственная) в плане философии. Рассматривается ряд задач нарастающей сложности, сопровождаемые логическими рассуждениями и - самое интересное - философскими обоснованиями. В том числе - общего характера. Сразу: книга сложная. Не из-за математики (математика там простая, на уровне начальных понятий матлогики), а как раз там, где математики и нет.
Ну и наконец, жалкое подражание Жану Бодрийяру ("Симулякры и симуляция"):
Программа — это вовсе не то, что скрывает собой истину, — это истина, скрывающая, что её нет. Программа есть истина.
ФП = неизменяемые наборы данных, функции принимают наборы таких данных и возвращают наборы таких данных (да, вопреки заблуждениям это не любой код где есть функции, да и функции иногда не функции, а процедуры, но это тема других статей..)
Мне кажется, вы, мягко говоря, не сильно глубоко погружались в эту тему. В рамках только ФП есть несколько разных подходов и парадигм, которыми люди пытаются пользоваться для написания более-менее поддерживаемых в долгосроке программ. Посмотрите, например, на потрясающую статью (link) А.Гранина (@graninas , если не ошибаюсь?) на тему free monads. Сравните, например, с подходом, на основе polysemy - и все это как альтернатива монадным трансформерам.
ФП или ООП как таковые - это вообще не про философию и не про единственно верный путь к построению архитектур. Это способ структурировать мысли при проектировании. А реальное проектирование начинается позже, когда мы начинаем говорить о паттернах. И в этом свете не вызывает удивления тот факт, что какие-то паттерны из мира ООП вдруг начинают напоминать паттерны из мира ФП (и наоборот).
И, кстати, паттерны могут быть разных масштабов. Скажем, берем паттерн Strategy из GoF - ну прикольно, заменяем ручные if / else if на проход по таблице виртуальных методов. Плюсы понятны, но здесь речь идет про относительно небольшой кусок кода (и поэтому мы все еще говорим про ЯП и ООП). А потом смотрим на паттерн покрупнее, например SEDA. И где тут язык программирования или парадигма? А философия разработки, как ни странно, тут есть.
Философия программирования зашла в тупик