Ну я вот выбираю алгоритм "Оплатить заказ, отправить пользователю письмо о заказе" или "Отправить пользователю письмо о заказе, оплатить заказ". Как мне математика в этом поможет?
Как в том анекдоте: если бы этот дуб умел говорить, Наташа, он бы сказал, что он - тополь.
Математика здесь вам поможет понять, что обозначенный вами юз-кейс не является алгоритмом в контексте написания программирования. Программисты под "алгоритмами" понимают последовательность операций в коде для получения требуемых значений. Например, результатов поиска, ближайших адресов или отсортированного списка.
То есть вы в вузе это не изучали, и это не помешало вам работать программистом
Не совсем так. Это не мешает начать кодить. Однако, без этих знаний вы не будете программистом. Только кодером.
Ну так разговор же не о том, в чем вы ориентируетесь, а о том, как часто вы используете эти знания в работе программистом.
Кроме физики, остальные знания используются довольно часто. Несколько раз в день. Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки. Математика, в той или иной мере, используется при выборе алгоритмов. Есть огромная разница между человеком, который может прокрутить в голове различные параметры качества выбранного алгоритма, или оценить применимость выбранной структуры данных, и человеком, который не может этого сделать.
Что же касается физики, то, как минимум, понимать принцип работы компьютерного железа, человек обязан. Трудно работать с программистом, который считает, что в ОЗУ сидят волшебные феи, которые запоминают целые слова и картинки. Не так ли?
Если честно, я не вижу логики в утверждении "Программистам физика обычно в работе не требуется, значит надо закрыть факультеты, которые готовят программистов".
Видимо, это связано с вашими утверждениями о том, что математика программистам не нужна. Поскольку, следуя вашему повествованию, получается, что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания. Хотя, по сути, можно найти кучу примеров, когда простейшие знания математики или теории реляционной модели данных позволяют быстро и эффективно найти решение задачи.
Низкоуровневые и высокоуровневые языки отличает уровень абстракции.
Низкоуровневые языки позволяют писать код, используя только машинные команды для его аллокации и выполнения. То есть, это языки, которые позволяют работать напрямую с устройством выполнения, посредством команд.
Высокоуровневые языки обладают набором инструментов в компиляторах и интерпретаторах, которые позволяют вынести процесс написания машинных команд для часто встречающихся абстракций, под капот. То есть, предлагают абстракции, которые позволяют писать более человекочитаемый код. Например, если вам не нужно выделять вручную область памяти для инкапсуляции, а достаточно просто написать class или struct, определив в нëм области видимости свойств и методов, то это абстракция над машинным кодом. Аналогично, абстрагированию поддаются монады, полиморфизм, реализация структур данных и т.д..
Высокий или низкий уровень языка определяется не просто вставками на ассемблере, а общим стилем написания кода. Либо код, в большей степени, построен на использовании абстракций, либо предлагает выполнять машинные команды для управления устройством исполнения. Так-то, теоретически, мы можем сделать расширение для любого высокоуровнего языка, чтобы на нëм можно было напрямую выполнять машинные команды. Но это не сделает язык низкоуровневым, поскольку, он, так или иначе, будет иметь большой стек абстракций, позволяющих уйти от написания машинных команд в любой момент времени.
З.Ы. это при том, что я, не имея высшего образования, ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе. А вы приходите в ВУЗ и учите тому, что ничего из этого знать не нужно! Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов? А то, смотрю, вузовские разработчики в последнее время лавируют между "институт даëт хорошую базу" и "я учу своих студентов, что математику знать не нужно".
Затем, что техника и IT - это способы автоматизации. Это сферы, которые превращают сложные вещи - в простые. Но происходить это может только тогда, когда появляется простой формальный язык для описания сложных вещей. Научпоп - это, как-раз, метод поиска такого языка.
Другой научно-популярный автор, Бен Орлин, в своей книге "Change is the only constant" (В русской редакции "Время Переменных"), упоминает заслугу Готфрида Лейбница в качестве инноватора математического языка. Орлин подчëркивает, что введение (не изобретение, а популяризация) символов и обозначений, упрощающих математическую запись, оказало значительное влияние на развитие математики. Например, трудно представить себе, как бы мы считали, если бы никто не ввëл символы скобочек для группировки, или символ = для обозначения равенства. Наверное, нам нужно было бы иметь более толстые тетради по математике в школе, чтобы писать эти блоки вычислений без коротких обозначений.
Однако, важной заслугой Лейбница Орлин считает введение обозначения дифференциала (dx). Орлин подчëркивает тот факт, что дифференциал сам по себе сложен тем, что не представляет собой конкретное чило. Поэтому, записывая дифференциал внутри дроби (например, dq/dp), мы подразумеваем отношение функций, а не отношение переменных. То есть, Орлин считает, что введение упрощëнной абстракции значительно снижает порог вхождения в предметную область и даëт ей импульс развития за счëт привлечения сторонников.
Так что, научпоп (если он хороший, качественный) безусловно интересен и важен.
Скорее, неизбежное следствие из инкапсуляции и полиморфизма. Если мы можем собрать функционал в одной области памяти, а в другой - переопределить часть функций, пользуясь ссылками на них, то мы получаем возможность наследования. То есть, мы можем создать копию функционала, пользуясь только ссылками на него, не создавая дубликат кода.
И это подводит нас к интересному выводу: Алан Кэй видел это неизбежное следствие, когда выводил основы ООП. Но ему не нравилась идея переиспользования кода по ссылкам на функции. Он недооценивал эту идею. Поэтому, искусственно исключил из первоначальной концепции.
Вы говорите об ООП в понимании Алана Кэя так, будто это истина в последней инстанции. Но это не так.
Кэй определяет ООП как инкапсуляцию + динамическое связывание. При этом, динамическое связывание можно назвать частным случаем реализации полиморфизма. Просто, Кэй не изучал вопрос полиморфизма. Однако, игнорировать этот вопрос только потому, что ваш любимый автор его не изучал - несколько странно.
Хочется отметить, что полиморфизм не является парадигмо-зааисимой концепцией, и может быть реализован, в том числе, в структурном подходе.
Алан Кэй ошибочно не рассматривал наследование и абстракцию, как принципы ООП, поскольку принципиально не хотел использовать его для создания абстракций и избегания повторов в коде за счëт наследования. Даже задачи, связанные с необходимостью изменения имплементации функции он решал только динамическим связыванием. Однако, уже в 1967 году Кристофер Стрэчи формулирует базовую классификацию полиморфизма. То есть, до создания языка Small talk и, соответственно, до формулирования термина "объектная ориентированность".
И вот, получается, что инкапсуляция возникла до определения Алана Кэя. Полиморфизм возник до определения Алана Кэя. Так в чëм же его заслуга, и насколько корректно ограничивать себя только ко его определением ООП?
Заслуга Алана Кэя состоит только в том, что он ввëл термин ООП впервые для системы разработки, основанной на инкапсуляции и полиморфизме (ограниченном только поздним связыванием). Поэтому, не вижу особого смысла ограничивать ООП только его определением. ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции. Это всë не требует даже поддержки классов или обмена сообщениями. Всë является объектом в ООП? Не факт. С тем же успехом можно говорить, что в ООП всë является абстракцией, а имплементация обеспечивается поздним связыванием. Алан Кэй - не единственный автор, и термин он ввëл исключительно для описания своего Smalltalk. За пределами смолтолка, термин имеет более широкое значение.
Возможно (скорее, точно), вы не только неудачно выразились, но и проигнорировали ту часть моих комментариев, в которых приводились доводы того, что можно выделить три основных парадигмы, а прочие являются или устаревшими, или производными от них.
Что в итоге? Понятие не очень четко сформулированное, есть самые разные взгляды на то сколько парадигм вообще, какие основные, какие специализированные.
Когда мы говорим о парадигме ООП, то мы имеем ввиду вполне конкретные вещи. А именно, возможность инкапсуляции методов и свойств в классы с применением наследования и полиморфизма. Этот подход к организации и проектированию кода стал возможным потому, что однажды удалось добиться сохранения кадра стека вызова функции в динамической памяти. То есть, появилась возможность сохранить состояние вызываемого кода на разных этапах выполнения. Использование ссылок на вложенные функции сделало возможным реализацию полиморфизма (подразумевающего наследование). То есть, этот подход к организации инструкций в коде потенциально не зависит от языка программирования (разумеется, если речь не идёт о логических или декларативных языках, но о них позже).
Структурное программирование - это имплементация теоремы Бёма-Якопини, которая ограничивает использование других способов передачи управления (например, оператора GOTO, по которому проехался в 1968 году Эдсгер Дейкстра).
Так а что же делать с императивным стилем? Я лично не считаю императивное программирование парадигмой. Это как называть Vanila JS фреймворком. Написание последовательных инструкций - это вообще не стиль. Это примитив разработки. Отсутствие структурирования. Когда мы ограничиваем методы передачи управления между отдельными строками кода ветвлениями и циклами, мы автоматически выходим на структурное программирование.
Как вам парадигма "разделяй и властвуй"?
Никак. Это логический паттерн, а не парадигма. Парадигма подразумевает набор правил написания кода, структурирования и оформления, потенциально независимо от языка программирования. То есть, мы можем применить одну из парадигм потенциально в любом языке. Хотите применить ООП в SQL? Пожалуйста! Помимо того, что существует Object-Pl/SQL, некоторые СУБД являются объектно-реляционными и позволяют, например, наследовать таблицы (https://www.cybertec-postgresql.com/en/conditional-foreign-keys-polymorphism-in-sql/). Скажу больше: оператор With в SQL наравне с применением оконных функций и Match/Case, по сути, позволяет применять структурный подход, расширяя декларативно-императивные инструкции языка циклами и ветвлениями. Кроме того, в многие СУБД позволяют писать свои функции, не сохраняющие состояние в процессе выполнения, применять цепочки вызовов функций, что делает SQL с расширениями, в том числе, функциональным языком.
Логические языки я считаю подмножеством функциональных, поскольку они основаны на том же лямбда-исчислении, просто их синтаксис более декларативный. Тот же Пролог, как сообщает беглое гугление, в современных имплементациях имеет ООП-расширения. Просто потому, что есть задачи, которые решаются именно ООП парадигмой, и это-таки настоящая парадигма.
Поэтому, я считаю, что дядюшка Мартин в своей книге "Чистая архитектура" даёт вполне верное определение как понятию Парадигма, так и трём основным существующим парадигмам. Он пишет, что Парадигма - это способ программирования, не зависящий от конкретного языка. Я бы уточнил, что это набор правил по логической организации и структуризации кода, не зависящий от конкретного языка. И это не трудно доказать: структурное программирование является имплементацией теоремы Бёма-Якопини, функциональное программирование - наиболее строгой имплементацией лямбда-исчислений, ООП - это наиболее простой и полный способ организации кода для сохранения промежуточного состояния выполнения, обеспечения наследования и полиморфизма.
Теорема Бёма-Якопини говорит о том, что любой алгоритм может быть оптимизирован до использования основных структур: последовательность, ветвление, цикл. Если некий язык не поддерживает одну из перечисленных структур, то он не полноценен, поскольку на нём не получится выполнить любую задачу.
Лямбда-исчисление тоже тесно связано с полнотой языка, поскольку предполагает наличие рекурсивности и замыканий, отсутствие которых, по сути, делает язык бесполезным. Поэтому, что-то мне подсказывает, что даже в языках, где нет анонимных функций, можно присвоить переменной ссылку на функцию, обеспечив эту самую анонимность (хотя, могу ошибаться - поправьте, если так).
ООП подразумевает, как я уже говорил, инкапсуляцию, наследование, полиморфизм (минимум - без абстракции). И существует оно для решения нескольких задач. Первая задача связана с сохранением состояния вызова функции на разных этапах её выполнения. Вторая задача - избегание повторения кода за счёт наследования или полиморфизма функций, посредством использования ссылок на них. Поэтому, в любом языке, так или иначе, или возможно это реализовать, или возможно расширить язык конструкциями, предлагающими решение этой проблемы. В любом случае, сохраняя состояние исполнения вашей программы, или определяя ссылки на вложенные функции, вы имеете дело с ООП.
Я готов понять разработчиков на ассемблерах, которые отрицают применимость и пользу ООП. Я не могу понять "прогромиздофф на HTML", которые пытаются доказать, что ООП не нужен потому, что декларативные языки - настоящие языки программирования.
Хм. Думаю, вы путаете математическое и чëрно-белое мышление. Язык SQL с расширениями перестаëт быть декларативным, приобретая черты императивного и функционального. Поэтому, со своими расширениями он и определяется в различных источниках, как мультипарадигменный.
Ну, с определëнными допущениями, условиями и расширениями, тьюринг-машину можно собрать теоретически на чëм угодно. Это как Doom, который можно запустить хоть на хвосте собаки.
И всë-таки, я бы поставил под сомнение декларативность некоторых операций, которые делают такие языки, как SQL, тьюринг-полными. Например, операцию with. Он не описывает спецификацию ожидаемого результата, а, по сути, создаëт цикл.
Иэто уже не говоря о том, что есть время выполнения запроса и ограничения рекурсивности. С другой стороны, применимость декларативных языков к решению различных вычислительных задач - это не более чем баловство. Извините, но я не могу рассматривать декларативный подход, как парадигму программирования. Как минимум, потому, что Тьюринг-полнота декларативных языков - опциональна.
Как в том анекдоте: если бы этот дуб умел говорить, Наташа, он бы сказал, что он - тополь.
Математика здесь вам поможет понять, что обозначенный вами юз-кейс не является алгоритмом в контексте написания программирования. Программисты под "алгоритмами" понимают последовательность операций в коде для получения требуемых значений. Например, результатов поиска, ближайших адресов или отсортированного списка.
Не совсем так. Это не мешает начать кодить. Однако, без этих знаний вы не будете программистом. Только кодером.
Кроме физики, остальные знания используются довольно часто. Несколько раз в день. Реляционная теория нужна для проектирования таблиц БД с учëтом нормализации и оптимизации выборки. Математика, в той или иной мере, используется при выборе алгоритмов. Есть огромная разница между человеком, который может прокрутить в голове различные параметры качества выбранного алгоритма, или оценить применимость выбранной структуры данных, и человеком, который не может этого сделать.
Что же касается физики, то, как минимум, понимать принцип работы компьютерного железа, человек обязан. Трудно работать с программистом, который считает, что в ОЗУ сидят волшебные феи, которые запоминают целые слова и картинки. Не так ли?
Видимо, это связано с вашими утверждениями о том, что математика программистам не нужна. Поскольку, следуя вашему повествованию, получается, что вы ходите в ВУЗ, чтобы рассказать студентам о том, что они получают там бесполезные знания. Хотя, по сути, можно найти кучу примеров, когда простейшие знания математики или теории реляционной модели данных позволяют быстро и эффективно найти решение задачи.
Низкоуровневые и высокоуровневые языки отличает уровень абстракции.
Низкоуровневые языки позволяют писать код, используя только машинные команды для его аллокации и выполнения. То есть, это языки, которые позволяют работать напрямую с устройством выполнения, посредством команд.
Высокоуровневые языки обладают набором инструментов в компиляторах и интерпретаторах, которые позволяют вынести процесс написания машинных команд для часто встречающихся абстракций, под капот. То есть, предлагают абстракции, которые позволяют писать более человекочитаемый код. Например, если вам не нужно выделять вручную область памяти для инкапсуляции, а достаточно просто написать class или struct, определив в нëм области видимости свойств и методов, то это абстракция над машинным кодом. Аналогично, абстрагированию поддаются монады, полиморфизм, реализация структур данных и т.д..
Высокий или низкий уровень языка определяется не просто вставками на ассемблере, а общим стилем написания кода. Либо код, в большей степени, построен на использовании абстракций, либо предлагает выполнять машинные команды для управления устройством исполнения. Так-то, теоретически, мы можем сделать расширение для любого высокоуровнего языка, чтобы на нëм можно было напрямую выполнять машинные команды. Но это не сделает язык низкоуровневым, поскольку, он, так или иначе, будет иметь большой стек абстракций, позволяющих уйти от написания машинных команд в любой момент времени.
Идеальный скилл-сэт для продавца Пятëрочки.
З.Ы. это при том, что я, не имея высшего образования, ориентируюсь в области принципов построения реляционных БД, физики, математическом анализе. А вы приходите в ВУЗ и учите тому, что ничего из этого знать не нужно! Так может, следуя вашей логике, следует закрыть факультеты, которые готовят программистов? А то, смотрю, вузовские разработчики в последнее время лавируют между "институт даëт хорошую базу" и "я учу своих студентов, что математику знать не нужно".
Пожалуйста, больше не подпускайте чайлдфри к проектировке.
Юнармейской зорьки.
Продемонстрируйте, пожалуйста, каррирование функции.
Замыкание - это и есть вложенная функция (функция внутри функции).
Затем, что техника и IT - это способы автоматизации. Это сферы, которые превращают сложные вещи - в простые. Но происходить это может только тогда, когда появляется простой формальный язык для описания сложных вещей. Научпоп - это, как-раз, метод поиска такого языка.
Другой научно-популярный автор, Бен Орлин, в своей книге "Change is the only constant" (В русской редакции "Время Переменных"), упоминает заслугу Готфрида Лейбница в качестве инноватора математического языка. Орлин подчëркивает, что введение (не изобретение, а популяризация) символов и обозначений, упрощающих математическую запись, оказало значительное влияние на развитие математики. Например, трудно представить себе, как бы мы считали, если бы никто не ввëл символы скобочек для группировки, или символ = для обозначения равенства. Наверное, нам нужно было бы иметь более толстые тетради по математике в школе, чтобы писать эти блоки вычислений без коротких обозначений.
Однако, важной заслугой Лейбница Орлин считает введение обозначения дифференциала (dx). Орлин подчëркивает тот факт, что дифференциал сам по себе сложен тем, что не представляет собой конкретное чило. Поэтому, записывая дифференциал внутри дроби (например, dq/dp), мы подразумеваем отношение функций, а не отношение переменных. То есть, Орлин считает, что введение упрощëнной абстракции значительно снижает порог вхождения в предметную область и даëт ей импульс развития за счëт привлечения сторонников.
Так что, научпоп (если он хороший, качественный) безусловно интересен и важен.
Замыкание.
Скорее, неизбежное следствие из инкапсуляции и полиморфизма. Если мы можем собрать функционал в одной области памяти, а в другой - переопределить часть функций, пользуясь ссылками на них, то мы получаем возможность наследования. То есть, мы можем создать копию функционала, пользуясь только ссылками на него, не создавая дубликат кода.
И это подводит нас к интересному выводу: Алан Кэй видел это неизбежное следствие, когда выводил основы ООП. Но ему не нравилась идея переиспользования кода по ссылкам на функции. Он недооценивал эту идею. Поэтому, искусственно исключил из первоначальной концепции.
Вы говорите об ООП в понимании Алана Кэя так, будто это истина в последней инстанции. Но это не так.
Кэй определяет ООП как инкапсуляцию + динамическое связывание. При этом, динамическое связывание можно назвать частным случаем реализации полиморфизма. Просто, Кэй не изучал вопрос полиморфизма. Однако, игнорировать этот вопрос только потому, что ваш любимый автор его не изучал - несколько странно.
Хочется отметить, что полиморфизм не является парадигмо-зааисимой концепцией, и может быть реализован, в том числе, в структурном подходе.
Алан Кэй ошибочно не рассматривал наследование и абстракцию, как принципы ООП, поскольку принципиально не хотел использовать его для создания абстракций и избегания повторов в коде за счëт наследования. Даже задачи, связанные с необходимостью изменения имплементации функции он решал только динамическим связыванием. Однако, уже в 1967 году Кристофер Стрэчи формулирует базовую классификацию полиморфизма. То есть, до создания языка Small talk и, соответственно, до формулирования термина "объектная ориентированность".
И вот, получается, что инкапсуляция возникла до определения Алана Кэя. Полиморфизм возник до определения Алана Кэя. Так в чëм же его заслуга, и насколько корректно ограничивать себя только ко его определением ООП?
Заслуга Алана Кэя состоит только в том, что он ввëл термин ООП впервые для системы разработки, основанной на инкапсуляции и полиморфизме (ограниченном только поздним связыванием). Поэтому, не вижу особого смысла ограничивать ООП только его определением. ООП - это комбинация инкапсуляции, полиморфизма, наследования и абстракции. Это всë не требует даже поддержки классов или обмена сообщениями. Всë является объектом в ООП? Не факт. С тем же успехом можно говорить, что в ООП всë является абстракцией, а имплементация обеспечивается поздним связыванием. Алан Кэй - не единственный автор, и термин он ввëл исключительно для описания своего Smalltalk. За пределами смолтолка, термин имеет более широкое значение.
Никак.
Возможно (скорее, точно), вы не только неудачно выразились, но и проигнорировали ту часть моих комментариев, в которых приводились доводы того, что можно выделить три основных парадигмы, а прочие являются или устаревшими, или производными от них.
Когда мы говорим о парадигме ООП, то мы имеем ввиду вполне конкретные вещи. А именно, возможность инкапсуляции методов и свойств в классы с применением наследования и полиморфизма. Этот подход к организации и проектированию кода стал возможным потому, что однажды удалось добиться сохранения кадра стека вызова функции в динамической памяти. То есть, появилась возможность сохранить состояние вызываемого кода на разных этапах выполнения. Использование ссылок на вложенные функции сделало возможным реализацию полиморфизма (подразумевающего наследование). То есть, этот подход к организации инструкций в коде потенциально не зависит от языка программирования (разумеется, если речь не идёт о логических или декларативных языках, но о них позже).
Структурное программирование - это имплементация теоремы Бёма-Якопини, которая ограничивает использование других способов передачи управления (например, оператора GOTO, по которому проехался в 1968 году Эдсгер Дейкстра).
Так а что же делать с императивным стилем? Я лично не считаю императивное программирование парадигмой. Это как называть Vanila JS фреймворком. Написание последовательных инструкций - это вообще не стиль. Это примитив разработки. Отсутствие структурирования. Когда мы ограничиваем методы передачи управления между отдельными строками кода ветвлениями и циклами, мы автоматически выходим на структурное программирование.
Никак. Это логический паттерн, а не парадигма. Парадигма подразумевает набор правил написания кода, структурирования и оформления, потенциально независимо от языка программирования. То есть, мы можем применить одну из парадигм потенциально в любом языке. Хотите применить ООП в SQL? Пожалуйста! Помимо того, что существует Object-Pl/SQL, некоторые СУБД являются объектно-реляционными и позволяют, например, наследовать таблицы (https://www.cybertec-postgresql.com/en/conditional-foreign-keys-polymorphism-in-sql/). Скажу больше: оператор With в SQL наравне с применением оконных функций и Match/Case, по сути, позволяет применять структурный подход, расширяя декларативно-императивные инструкции языка циклами и ветвлениями. Кроме того, в многие СУБД позволяют писать свои функции, не сохраняющие состояние в процессе выполнения, применять цепочки вызовов функций, что делает SQL с расширениями, в том числе, функциональным языком.
Логические языки я считаю подмножеством функциональных, поскольку они основаны на том же лямбда-исчислении, просто их синтаксис более декларативный. Тот же Пролог, как сообщает беглое гугление, в современных имплементациях имеет ООП-расширения. Просто потому, что есть задачи, которые решаются именно ООП парадигмой, и это-таки настоящая парадигма.
Поэтому, я считаю, что дядюшка Мартин в своей книге "Чистая архитектура" даёт вполне верное определение как понятию Парадигма, так и трём основным существующим парадигмам. Он пишет, что Парадигма - это способ программирования, не зависящий от конкретного языка. Я бы уточнил, что это набор правил по логической организации и структуризации кода, не зависящий от конкретного языка. И это не трудно доказать: структурное программирование является имплементацией теоремы Бёма-Якопини, функциональное программирование - наиболее строгой имплементацией лямбда-исчислений, ООП - это наиболее простой и полный способ организации кода для сохранения промежуточного состояния выполнения, обеспечения наследования и полиморфизма.
Теорема Бёма-Якопини говорит о том, что любой алгоритм может быть оптимизирован до использования основных структур: последовательность, ветвление, цикл. Если некий язык не поддерживает одну из перечисленных структур, то он не полноценен, поскольку на нём не получится выполнить любую задачу.
Лямбда-исчисление тоже тесно связано с полнотой языка, поскольку предполагает наличие рекурсивности и замыканий, отсутствие которых, по сути, делает язык бесполезным. Поэтому, что-то мне подсказывает, что даже в языках, где нет анонимных функций, можно присвоить переменной ссылку на функцию, обеспечив эту самую анонимность (хотя, могу ошибаться - поправьте, если так).
ООП подразумевает, как я уже говорил, инкапсуляцию, наследование, полиморфизм (минимум - без абстракции). И существует оно для решения нескольких задач. Первая задача связана с сохранением состояния вызова функции на разных этапах её выполнения. Вторая задача - избегание повторения кода за счёт наследования или полиморфизма функций, посредством использования ссылок на них. Поэтому, в любом языке, так или иначе, или возможно это реализовать, или возможно расширить язык конструкциями, предлагающими решение этой проблемы. В любом случае, сохраняя состояние исполнения вашей программы, или определяя ссылки на вложенные функции, вы имеете дело с ООП.
Я готов понять разработчиков на ассемблерах, которые отрицают применимость и пользу ООП. Я не могу понять "прогромиздофф на HTML", которые пытаются доказать, что ООП не нужен потому, что декларативные языки - настоящие языки программирования.
Хм. Думаю, вы путаете математическое и чëрно-белое мышление. Язык SQL с расширениями перестаëт быть декларативным, приобретая черты императивного и функционального. Поэтому, со своими расширениями он и определяется в различных источниках, как мультипарадигменный.
Уверен, что вы - тоже.
Ну, с определëнными допущениями, условиями и расширениями, тьюринг-машину можно собрать теоретически на чëм угодно. Это как Doom, который можно запустить хоть на хвосте собаки.
И всë-таки, я бы поставил под сомнение декларативность некоторых операций, которые делают такие языки, как SQL, тьюринг-полными. Например, операцию with. Он не описывает спецификацию ожидаемого результата, а, по сути, создаëт цикл.
Иэто уже не говоря о том, что есть время выполнения запроса и ограничения рекурсивности. С другой стороны, применимость декларативных языков к решению различных вычислительных задач - это не более чем баловство. Извините, но я не могу рассматривать декларативный подход, как парадигму программирования. Как минимум, потому, что Тьюринг-полнота декларативных языков - опциональна.
То есть, вы считаете, что приводить мнение технических авторов нельзя только потому, что это апелляция к авторитету?
С ограничениями.