Научное программирование: часть 1

Наука в программировании — быль или реальность? Сколько её в языках и почему идут холивары о приемуществах одних языков над другими? Если интересно — прошу под кат.

Давным-давно идут «священные войны» в которых обсуждаются и критикуются различные подходы в написании программ и в самом программировании, критикуется в основном Объектно-Ориентированное Программирование(раз, два, три).

Егор Бугаенко критикует ООП на практических примерах(раз, два, видео), используя идеи Девида Уэста и, как я понял, недавно пошел в сторону теории. Эффективность этих споров стремится к нулю. Почему? Потому что все эти споры ведутся уже на основе реализаций каких-то мыслей, практик и мнений отдельных людей, а не на основе теоретических работ. Научного метода и подхода с его теориями, гипотезами, аксиомами, экспериментами, доказательствами и фактами в последнее время в этих спорах и «войнах» нет от слова вообще!

В математике, как и в любой другой науке, любые теоремы и теории требуют доказательств. Как пример: Теорема Пифагора. Сначала идет теория, а за ней практика. В программировании такого подхода не придерживаются уже несколько десятков лет. Всё заменено догмами и мнением отдельных личностей, которых иногда называют «евангелистами» или «пророками». Они своим словоблудием продвигают в массы только нужные им идеи, не заботясь ни о теории, ни о доказательствах (Посмотрите конференции и презентации по ИТ). Где здесь наука, а где религия? И не скатываемся ли мы в мракобесие и веру в слова написанные давно и не требующих доказательств? Слышали про сторонников плоской Земли? Ничего не напоминает по части подходов по убеждению и упоротости?

И вот в таком кураже последние 30-40 лет программисты, ослепленные религиозными убеждениями от проповедников ООП или ФП, строили абстракции поверх других абстракций, новые языки поверх других языков, новые фреймворки и библиотеки поверх старых. А зачем это все было нужно? Ради упрощения и производительности своей работы по написанию программ. Только этот путь привел в тупик. Потому что вместо упрощения получили усложнение и изучение теперь не алгоритмов, а API и документации к очередному модному фреймворку, а может и нескольким. Теперь баги стали искать не только в своем коде, но и в чужом. Отладку кода приходится делать через тонны прокси, паттернов архитектуры и шаблонов проектирования, хелперов, фреймворков и библиотек. И, как показывают исследования, выигрыша в скорости написания кода от применения ООП нет вообще.

Немного истории. С чего всё началось? Сначала было процедурное программирование, затем структурное и за ним на сцену вышло императивное программирование. Некоторые люди додумались ввести понятие объекта — так родилось обьектно-ориентированное программирование. И в этот момент произошел крутой поворот повернувший всю индустрию в то состояние, в котором мы сейчас находимся.

Введение объекта должно было быть теоретически обосновано. Но этого не произошло. Вместо этого каждый язык внедрял понятие объекта по своему. И каждый разработчик языка трактовал постулаты ООП на свой вкус и цвет. Особо упоротые фундаменталисты придумали Функциональное Программирование основанное на математике, списках и функциях высшего порядка. Звучит серьезно и даже немного научно обосновано, ведь математика — вещь нужная и полезная, только вот какое отношение к реальному миру имеют списки и функции?

Какие задачи решает чистое ФП без использования состояний и есть ли это оптимальный, удобный и правильный способ со стороны человека — вот такой вопрос нужно задать «пророкам» ФП. И его задают (раз, два).

Разработчики функциональных языков начали применять у себя некоторые парадигмы из ООП для того, чтобы выйти из области прикладных задач по математике в область задач реального мира. В ответ некоторые ООП языки реализовали у себя парадигмы из ФП. И «Смешались в кучу кони, люди » (с)

В итоге реализация чистых парадигм ООП и ФП в текущих языках как в песне — «Я его слепила из того что было, а что было то и полюбила»! И получается, что без теоретических работ и научной базы, все эти языки лишь плод фантазий и желаний их разработчиков. И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.

Могу предположить, что когда вводили понятие объекта — за основу приняли то, что видели вокруг себя — человека и животных. И в этом была главная ошибка которая позже вырастет до огромных размеров! Таким образом, возможно, появилось наследование(предок-потомок и связь между ними объясняется наследованием, но как быть с другими объектами в мире? И что значит само определение слова «наследование» в реальном мире? Кровь и ДНК? Азотистые основания?). Как остальные термины, а именно абстракция, инкапсуляция и полиморфизм, относятся именно к ООП? А предоставить доказательства такой связи как-то не потрудились. Ведь написать можно что угодно и звучит логично, только проблема в том, что приведенные аргументы к ООП отношения не имеют. Ведь в ООП была сделана логическая ошибка —(неполная индукция) был произведен переход от одного частного случая ко всему общему множеству. Чтобы это показать, приведу пример — если можно за основу взять только живых существ с наследованием, то почему же, следуя этой же логике, не взять за основу планету или целую галактику? Ведь планета или галактика тоже наследница других объектов из космоса и имеет состояние и какое-то поведение. Или все горы представить как объекты без наследования и практически без поведения.

Почему любой объект должен или может использовать наследование от другого объекта кто-то потрудился объяснить и доказать? Ударение на слове «доказать»!

Ведь если начинаешь сильно задумываться над этим, то возникает смутное предчувствие: здесь не обошлось без обмана, манипуляций и ошибок! Ведь ценность слов оценивается по возможности их логически и аргументированно доказать опираясь на факты и данные. Иначе можно придумывать какой угодно бред вплоть до розовых единорогов! Или по-другому — чем ваши слова отличаются от слов религиозного фанатика-экстремиста сбежавшего из психбольницы?

Но так было не всегда. Вот примеры научного подхода:

1. книга «Электронные цифровые машины и программирование» А.И. Китова.

2. теорема Бёма — Якопини.

Не так много как хотелось бы, и, возможно, где-то есть еще много примеров научных работ, но их найти очень сложно. Подавляющее большинство пользуется всякими «библиями» и статьями для аргументации и дискуссий(в реальности это даже слишком громкое слово для этого процесса).

Попробуем применить к программированию науку и опираться только на её достижения, результаты и методы.

Введем базовые определения для терминов:

Обьект — наименьшая неделимая сущность, также известная нам как химический элемент, имеющая множество свойств и множество моделей поведения реализуемые через методы. У объекта есть 2 типа методов: 1) для получения его свойств, 2) для изменения его состояния.

Модель поведения — интерфейс для взаимодействия с объектом.

Процесс — вид взаимодействия над элементами(гравитация, свет, нагревание, излучение).

Факты:

1. Всё в окружающем мире состоит из мельчайших неделимых химических элементов и поэтому за основу главного объекта необходимо брать именно химический элемент обладающий множеством моделей поведения.

2. Химические элементы могут объединяться во множества.

3. Химические элементы взаимодействуют между собой (реакция), находятся под действием разных процессов.

4. Каждый химический элемент имеет свое состояние на каком-то промежутке времени и может его менять под воздействием внешних процессов.

5. Процессы также являются объектами или их множеством и с помощью своей модели поведения могут изменять химические элементы.

Приняв за основу изложенные факты и данные, проанализировав свойства и поведение элементов, их взаимодействие и процессы между ними, выделим несколько принципов:

1. Есть 2 типа объектов: элементарные(атомарные) и реакционные(процессные). Элементарные объекты могут, при соблюдении определенных условий, возвращать из методов, меняющих их состояние, новые объекты.

2. Реакционные объекты знают интерфейсы объектов с которыми работают.

3. Все свойства объекта должны быть определены как приватные и неизменяемые, объекты как публичные и неизменяемые, а методы только публичные.

4. Существует только один тип проверяемого исключения — Exception.

5. У элементов нет такого понятия как NULL. Вместо этого должен быть или 0, пустая строка, массив с одним элементом или пустая коллекция элементов.

6. У элементов нет наследования ни в каком виде.

7. Также нет аннотаций, приведения типов, внутренних и локальных классов, анонимных классов и лямбд, Enum-ов, статических методов и атрибутов.

8. Нет абстрактных классов и методов.

9. Элементарные объекты не могут возвращать данные которые могут быть изменены. Можно только попросить этот объект что-то с ними сделать — так как только он отвечает за их хранение и изменение. Изменение элементарного объекта происходит только с помощью реакционного объекта.

10. Для хранения состояния необходимо использовать структуры данных, такие как массивы, очереди, коллекции, списки и мапы.

11. Объекты вступающие в реакцию друг с другом могут вернуть другой обьект или изменить свое состояние.

12. Структуры данных очень важны. Реакционные объекты могут принимать в качестве параметров метода множество(коллекцию) разных объектов и могут возвращать множество разных объектов как результат работы метода.

13. Методы используют формальную логикувысказываниями, алгеброй логики и логическими операциями) и циклы выраженную в виде синтаксиса языка, для работы с данными и возвращают результат или изменяют состояние объекта (или его множества).

14. Тело метода должно занимать от 1 до 10 строчек кода без пропусков.

15. Тело класса должно занимать от 5 строк до 2 высот экрана монитора без пропусков. Чем меньше тело класса и метода — тем лучше.

Гипотеза:

1. Если исключить из ЯП (Язык Программирования) возможность наследования, статические методы и атрибуты, абстрактные классы, то в проекте код станет минимум на 10-20 процентов меньше.

2. Если исключить из кода в проекте все антишаблоны проектирования, то код станет минимум на 10-15 процентов меньше.

3. Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять.

4. Тестирование объектов будет проходить быстрее (см п.3).

5. Отладка метода будет проходить быстрее (см п.3).

6. Написание новых классов будет проходить быстрее (см п.3)

Таким образом, приняв во внимание факты, принципы и созданную гипотезу(если она подтвердится экспериментально), мы можем вывести свою Элементарную или Атомную теорию программирования.

Если бы в 60-е и 70-е годы такой подход был принят за основной стандарт, то мы бы не испытывали сейчас столько негатива и растерянности с существующим зоопарком языков и подходов.

В следующей части будем экспериментально доказывать нашу гипотезу и дополнять теорию. Задавайте вопросы по теории в комментариях. Серьезно отнеситесь к этому делу и думайте.
Поделиться публикацией
Комментарии 373
    +6
    «Всё в окружающем мире состоит из мельчайших неделимых химических элементов» — как-то, мягко говоря, несовременно. Вам не кажется?
      –2
      В чём именно «несовременность»? В наличии ещё более мелких частиц? Нейтронов, протонов и позитронов? А может кварков? Возможно, я не уточнил, что речь идет о химии и химических элементах, а не о квантовой физике? Дело в том, что учёные еще плохо ( не до конца изучили) знают модели их поведения и взаимодействия. И поэтому их брать за основу ещё рано. Возможно их очередь настанет через несколько десятков лет — вот тогда и поговорим.
        +4
        А взаимодействие химических элементов, получается, изучено хорошо и до конца?
          –4
          Да. Входит в школьную программу химии. Я согласен, что открывают новые элементы и реакции, но базовые процессы изучены, я думаю, хорошо. Классификация и систематизация имеющихся на данный момент элементов я думаю сложилась в полноценную картину.
            +3
            Вы уже закрыли проекты типа Folding@home за ненадобностью? Нет — почитайте что-нибудь про современную химию. Насколько я помню, даже в неорганике находят что-то новое. Успехов в самообразовании.
              –3
              Даю ссылку. Каким образом проект распред. вычислений относится к химии? Ну кроме моделирования и предсказания какой-то теории? Вот и докажите в отдельной статье в чём я не прав. Приведите свои доводы и доказательства своих слов. Расскажите в статье КАКИЕ новые законы, теории и типы или виды реакций были открыты в химии? А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.
                +4
                А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.
                А Ваша статья такие высказывания не напоминает?
                  +1
                  Автор, научитесь читать что пишут про тот же фолдинг, чем они занимаются и какое отношение это имеет к химии. Потом подумайте об этом на фоне «базовые процессы изучены, я думаю, хорошо». Вот как научитесь читать — беритесь писать.
        +1
        Когда приходится рассматривать ООП, то есть два подхода — в одном ОБЪЕКТ это именно что род переменной или константы, а одинаковые в чем-то типы объединяются в КЛАССы (этот подход характерен для таких языков, как Ада и Haskell). В другом подходе ОБЪЕКТ считается экземпляром максимально абстрактного типа (вообщем-то явно не упоминаемого сами знаете кого) — это С++ и Ява (в ней вообще есть только один корневой класс Object). Но ведь на самом деле программиста уместно рассматривать как человека, который на специализированном языке описывает предметную область (литературное программирование), а вовсе не создающего объектную картину мира — ведь в начале было слово это мы же говорим «текст программы»… А вот дальше все пошло как-то не так — действительно, если вы читали первую большую книгу Страуструпа, то наверно, вас тоже вдохновлял пример окон или матриц и операций с ними — но в том-то и дело, что методы и операции не являются (как это обычно изображают, помещая их внутрь класса) элементами объекта! Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю… И так практически постоянно — да, удобно определять операции над объектом как объектные операции, но это-то и вводит в заблуждение — мне кажется, тут лежат истоки разрастания кода и появления ошибок. В то же время создание исчерпывающей системы типов, описывающей предметную область, вводит род языка, на котором задача легче формулируется и решается (если посмотреть на Пролог — то решается автоматически, нужно лишь точно сформулировать ее).
          –3
          Спасибо за хороший и объемный комментарий! Программист программирует и воспроизводит предметную область (а для этого ему нужно её описать — и это важно!), реализует алгоритмы её поведения с внешними объектами и между собой. Сама по себе предметная область и должна начинаться именно с мельчайших частиц, которые имеют своё поведение и других объектов, которые производят действия над другими объектами и далее вверх. Так если брать за основу какой-то промежуточный объект — то вниз мы спуститься сможем с большим трудом и (в нашем случае химия) предметная область лишится реализации и воспроизведения. Страуструпа я не читал к сожелению. Дождитесь 2 части — там будет код на Java и я думаю что смогу показать и доказать как это реализуется на практике.
            +1

            Ну вообще программистразработчик не воспроизводит предметную область, а моделирует ее.
            То есть выделяет значимые характеристики системы и описывает правила их изменения. Точность соответствия программной модели реальному миру зависит от задачи. Довольно часто углубляться до мельчайших частиц нет никакой необходимости.
            Зачем реализовывать атомы и молекулы в программе по расчету заработной платы?

              0
              Спасибо за комментарий. Со всем согласен, кроме терминов «воспроизведения» и «моделирования». Вы можете сказать что под ними подразумеваете и чем они отличаются? Кстати хорошая книга на этот счёт есть.
            +1
            а вовсе не создающего объектную картину мира

            Вообще первый объектный язык — SIMULA (SIMUlation LAnguage) был создан именно что для описания объектной картины мира и последующей её симуляции. Сам язык был создан для научно-исследовательских задач, а не для прикладных… потом уже всякие Страуструпы и Аланы Кейны переврали его, кто как мог :-)

            в ней вообще есть только один корневой класс Object

            А еще там есть примитивные типы: byte, short, int, long, char, float, double и boolean, которые живут сами по себе. Забудете про разницу между Long и long — наткнетесь на упаковку-распаковку.

            Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю…

            Хз, наверное как посмотреть: математически для каждого множества определяется свой набор арифметических операций, порой с особыми правилами (например, умножение матриц), так что арифметические операции именно что являются свойствами множества, то бишь классов и типов по программерски

            В другом подходе ОБЪЕКТ

            Вот в этом то вся бяда. Нет точных определений, т.е. да, действительно, у ООП есть проблема с фундаментальным теоретическим обоснованием.

            который на специализированном языке описывает предметную область

            Вы наверное фанат декларативного программирования :-) Угадал? :-)
              0
              Нет, не угадали :) Но вот что я за очень долгое время программирования понял — если задача сложна для понимания, надо ее попробовать записать на прологе, если удается — ты понял задачу, если нет — думай дальше…
              Но декларативный стиль очень люблю, поэтому два самых любимых (но не самых используемых!) языка — пролог и ада. Вот посмотришь на свою же программу, написанную лет 20 назад в декларативном стиле — и все достаточно ясно и понятно.
              Но на практике деньги приносит чистый С (по заветам старой школы), ну еще Ява…
              Однако с++ я изучал в далеком 91 году, с тех пор он разве что сильно ухудшился… ну вот разве что подход Qt остался, мне кажется, очень хорошим.
              Я предпочитаю не рисковать и не писать сложные системы и тем более сложные алгоритмы на с++. На яве — да, писал и пишу, но там все понятно и просто. А когда мне приводят примеры на с++, я долго выискиваю там собственно задачу, а потом оказывается, что это очень-очень простая вещь, но обильно завернутая в шелуху синтаксиса и темплейтов. Не даром есть шутка (шутка ли?), что одним из стимулов создания С++ было заставить больше платить программистам, чтобы системы разрастались и их было сложно отлаживать…
              Я, кстати, вообще думаю чисто объектно-логически, но вот именно ООП для выражения мыслей ну никак не подходит! Ну не знаю, как так вот выходит…
              И мне кажется, что более правильно синтезировать программу автоматически из ее доказательства (вот там и ошибок нет и отладки обычно нет — по крайней мере связанной с алгоритмом). Но под программированием ведь еще понимают (а часто только и именно) создание интефейсов с человеком — ну там всякие окна, стили и т.д… Ну вот для этого событийный подход + объекты в смысле переменные как раз больше подходит, все равно алгоритмов там нет (и хорошо)…
                0

                За синтезом программы я думаю будущее. Собственно кое-чего уже есть: Компиляторы и кодогенераторы.


                С С++ да, грустно, недавно пытался прочитать драфт стандарта C++ 17...1600+ страниц текста… Расширенный стандарт Паскаля — 200 страниц, у Фортрана 2008 — 600+ (а ведь там есть куча встроенных математических операторов, которыми в других языках даже не пахнет).


                Но что касается ООП… ну я хз. Проблема в терминологии, Вирт вон породил целую линейку языков: Модула, Оберон, где были модули, инкапсуляция и интерфейсы и он не считал шо это какое-то ООП — просто развитый модульный подход.
                Что же касается конкретно объектов — ну я хз. Все равно удобнее все представлять набором каких-то независимых сущностей, имеющих свое поведение, возьмем например какую-нибудь САУ: там будет объект управления, который что-то получает на вход и как-то на это реагирует (а уж что там за код внутри объекта — это никого не касается, ибо инкапсуляция) и есть регулятор — тоже ведь объект: на вход получает ошибку рассогласования, а на выходе — сигнал управления для объекта управления.
                И просто процедурами здесь не проканает, т.к., например,PID регулятор должен хранить интеграл ошибки, а еще помнить предыдущие отсчеты (шоб продифференцировать) и таких регуляторов системе будет дохрена и больше — так что пусть это будут объекты, которые хранят свои внутренние состояния и имеют свою логику поведения. Более того: Типов регуляторов будет много и каждый из них будет работать по своему. И просто их задекларировать не получиться: вся соль регуляторов и ОУ именно во внутренней логике (а она многообразна и ценность представляет именно конкретный алгоритм/формула, т.е. способ решения). А вот наследованию здесь уже будет не место: во-первых наследование ломает инкапсуляцию, во-вторых наследование усложняет сопровождение: мы не увидим в исходниках наследника свойства и методы родителя — придется всю цепочку изучать, в-третьих, само по себе наследование работает несколько тупо — оно всегда идет по принципу расширения, но реальное наследование (не только биологическая) — это вообще-то комбинация свойств родителя, ну и в-четвертых, если уровней наследования больше одного, то со временем классы становятся сильно хрупкими… Композиция компонентов и реализация интерфейсов — наше все :-)


                Я вообще предлагаю смотреть на любую софтину именно как на систему автоматического управления: общая логика, что мы дёрнули штурвал самолета или ткнули мышкой в кнопку — не меняется. Тут же и вылезает более подходящее представление: Data Flow и Control Blocks которые сидят на этих потоках.


                С Дженериками и шаблонами все несколько сложнее (но в итоге то сводится все просто к универсальным коллекциям, которых 3.5 штуки).


                В общем тут проблема скорее всего в том, что слишком дофина наплодили в ООП всяких бредовых идей, а реально то многого то и не надо.

                  0

                  И кстати еще один момент. Доказательство и написание программы через вывод доказательства.
                  Проблема с доказательством в том, что их меньше чем практических проблем. Реально основная масса алгоритмов работают на эвристических приемах — никакого строго математического доказательства/обоснования для них нет или оно появляется куда позже чем сам алгоритм. А вот для чего уже есть заготовленные доказательства — уже давно реализованы во всяких стандартных библиотеках. Мы такую же ситуацию наблюдаем в физике — большая ее часть, чистая эмпирика, под которую потом подводили теорию, на основе которой что-то пытались предсказать, после чего на основе предсказаний получали новый практический опыт и так далее по кругу.


                  Т.е. со строгим формальным подходом мы столкнемся с параличом в ряде практических задач.

                    0
                    Вполне согласен, что с синтезом программ имеются (и имелись) очень большие проблемы! Вот самая главная — практически нет людей, кто бы понимал хоть что-нибудь в формальном доказательстве… Тут все еще грустнее, чем в физике :)
                    Представьте, что вместо написания какого-нибудь хелло-ворда надо написать (!) и доказать теорему хелло-ворд (!)… Мне вот было и вначале трудно, и сейчас. Так что я остановился на имеющей практическое значение верификации (иногда доказательстве) программ, так сказать постфактум.
              –2
              Восхитительно! Благоговейно снимаю шляпу. Но местная фауна сейчас вас порвет в клочья, как Тузик грелку.
                –4
                Спасибо за комментарий! Уже пытается рвать. Им то ли скучно, то ли поняли что можно нести всякий бред и не отвечать за это. А о доказательствах своих высказываний даже не задумываются. Печально такое читать…
                  +6
                  А вы сомневались, публикуя такое. Это все-равно, что в мечети заявить, что аллаха нет. Жуткая ересь.

                  В свое время известный гуру программирования Эдсгер Вибе Дейкстра сказал:
                  «Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.» Сейчас в этом высказывании надо только заменить Бейсик на Java Script, и все станет актуальным.

                  Массовая профессия с низким порогом вхождения. Никому в голову не придет, что школьник или студент первого курса будет самостоятельно, скажем, рассчитывать аэродинамику крыла самолета, или проектировать сложный электронный прибор. Для этого надо закончить профильный институт, поработать в КБ под руководством наставника над реальными проектами. Плюс, в классической инженерной деятельности есть четкое разделение между проектом и изготовлением опытного образца. Передается документация с подписями, утверждениями и пр. Нормоконтроль и всякая другая бюрократия. Если конструктор ошибся и в цехе приходится дорабатывать кувалдой, то такой специалист долго не проработает. А в программировании второй этап сводится к компиляции, да и то не всегда.

                  Институтские преподаватели программирования вряд ли в массе своей сами специалисты в этой области.

                  Волосы встают дыбом при чтении здесь высказываний, что надо предъявить доказательства необходимости контроля типов и параметров процедур. Чудовищная деградация.
                    –1
                    Согласен. Жуть просто. Некоторые личности даже не понимают что такое факты и что нужно доказывать, а что нет. Похоже я не раскрыл тему плоской Земли и розовых единорогов о которых так любит высказывать своё никому не нужное мнение здешняя публика( не вся конечно!). Мало иметь ум в голове — надо ещё уметь им правильно пользоваться. А то по-набирают по объявлению программистов и мучайся потом с ними.
                      –1
                      А почему Вы считаете, что знаете, что нужно доказывать, а что нет? А почему Вы считаете, что Ваше мнение кому-то нужно? А Вы то сам хоть программист?
                        +2
                        Мне одному кажется, что если вы со scoffer-by (еще?) не знакомы (лично), то непременно следует это сделать
                  +14
                  И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.

                  А почему не должно? Почему должно быть так мало языков?


                  Обьект — наименьшая неделимая сущность, также известная нам как химический элемент, имеющая множество свойств и множество моделей поведения реализуемые через методы. У объекта есть 2 типа методов: 1) для получения его свойств, 2) для изменения его состояния.

                  А теперь, значит, зададимся вопросами: что такое "свойство", что такое "состояние", что такое "поведение", и что такое "метод". А то у вас базовое определение прямо сразу опирается на неопределенные понятия.


                  Факты

                  Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.


                  В частности, даже формально "поэтому за основу главного объекта необходимо брать именно химический элемент" — это не факт, а вывод (и вывод спорный).


                  выделим несколько принципов:

                  … тоже ни на чем не основанных.


                  Иными словами, вы заявили, что пытаетесь применить науку, но в реальности все, что вы делаете — это (не очень успешно) придаете своим размышлениям наукообразие.

                    –10
                    Спасибо за вопросы! По пунктам:
                    «А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод. Также как и наличие разных теорий может быть очень много, но правильная только одна.
                    «что такое „свойство“, что такое „состояние“,» — потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.
                    «Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.» — Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.
                    «В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968
                    По итогу — если Вы не согласны, то докажите своё мнение.
                      +7
                      Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.
                      Бремя доказывания Ваших фактов лежит на Вас. Пока Вы их не доказали — они всего лишь флуд, а значит то, что флуд разводить начали Вы — это научно доказанный факт.
                        +2
                        «А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод.

                        Ну ладно. Но почему 2 низкоуровневых, а не один? Почему 3 или 4, а не один? Почему это должны быть разные языки? Чем в вашей терминологии отличаются высокоуровневые языки от низкоуровневых?

                          +6
                          потому что исходя из определения что «истина только одна» я и сделал такой вывод.

                          Почему-то идея об единственности истины никак не мешает существованию множества языков общения. Почему тогда для языков программирования должны быть другие правила?


                          Язык программирования — это инструмент, средство решение задачи. Вокруг нас много разных средств транспорта, много разных фотоаппаратов (и не просто разных моделей, а радикально конструктивно разных устройств), много фасонов одежды и много способов прикрепить что-нибудь к чему-нибудь. Так почему языков программирования должно быть 6, а не множество?


                          потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.

                          Подождите, что "это" утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше "базовое определение".


                          Вот Вы и докажите, что приведенные мною факты таковыми не являются.

                          И эти люди запрещают мне ковыряться в носу будут рассказывать про научный метод? Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?


                          «В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968

                          В комментарии по ссылке нет ничего, что превратило бы вывод "Всё [...] состоит из [...] и поэтому [...] необходимо брать именно [...]" в факт, за который вы это выдаете.


                          По итогу — если Вы не согласны, то докажите своё мнение.

                          Не, так не работает. Вы делаете утверждения, вы их и доказываете. Пока что вы не справились даже с вопросами к вашему первому "базовому определению" (могу повторить, если надо) и первому "факту". Какой смысл обсуждать остальное, если первичные посылки ложны?

                            –5
                            «Почему-то идея об единственности истины никак не мешает существованию множества языков общения. Почему тогда для языков программирования должны быть другие правила?» Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!
                            «Язык программирования — это инструмент, средство решение задачи.» — У Вас неверное определение. Почитайте этот комментарий.
                            «Подождите, что „это“ утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше „базовое определение“.» — поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки, потому как Вы, похоже, будете спрашивать меня и о том, что такое союз «и»!
                            «Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?» Я знаю на ком лежит бремя и знаю про чайник Рассела. То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?
                              +3
                              Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!

                              Я готов согласиться, что из разных целей вытекают разные правила. Но почему языков программирования должно быть мало?


                              У Вас неверное определение. Почитайте этот комментарий.

                              А почему вдруг приведенное в этом комментарии определение более верное, чем мое?


                              поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки,

                              И эти ссылки согласованы с вашим определением объекта и не содержат неопределенных понятий? Нет и нет.


                              То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц

                              Вам нужно привести обоснование ваших утверждений и выводов, потому что иначе они выглядят необоснованными.


                              наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?

                              Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так). Так что да, это тоже придется обосновывать. Но это, на самом деле, скучно — а интересно, почему объект в программировании обязан соотноситься с неделимой частицей в реальном мире.

                                –4
                                1. «Но почему языков программирования должно быть мало?» Внимательно читайте что такое ЯП, для чего он нужен в моём комментарии. Вам лень читать и думать?
                                2. «А почему вдруг приведенное в этом комментарии определение более верное, чем мое?» Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.
                                3. «Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так)» — в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно! Читайте тут: Отношение понятий.
                                  +1
                                  Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.

                                  Эм, нет. В частности, ваше определение языка не способно ответь на вопрос, почему языков должно быть мало.


                                  в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно!

                                  А почему нас должно интересовать определение из химии и ограничение на химические процессы?

                                    –4
                                    1. Потому что только один язык сможет решать задачи эффективнее других. В какой-то момент их может быть и больше, но в итоге эффективность переноса алгоритма в инструкции для исполнительного устройства у каждого человека одинаковы.
                                    2. А Вас и не интересует. И других разработчиков языков тоже. И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье. Почему нужно ограничение читайте в моих комментариях.
                                      +4
                                      Потому что только один язык сможет решать задачи эффективнее других.

                                      Вне зависимости от определения, это утверждение ошибочно (или, по крайней мере, недоказуемо).


                                      Во-первых, даже для одной задачи наблюдаемо, что есть больше одного эффективного инструмента для ее решения (как-то: для задачи коммуникации между людьми существует более одного языка, для задачи сверления дыр в стене есть более одной дрели).


                                      Во-вторых, есть более одной задачи, решаемой языком программирования, и эти задачи, очевидно, могут решаться разными языками с разной эффективностью; нет никакого способа показать, что есть один язык, решающий все задачи заведомо эффективнее других языков, включая специализированные.


                                      эффективность переноса алгоритма в инструкции для исполнительного устройства у каждого человека одинаковы

                                      Ну а это-то наблюдаемо ошибочно: разные люди по-разному реализуют один и тот же алгоритм даже на одном языке.


                                      И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье.

                                      Однако нигде по ссылкам не будет объяснения, почему использование определения из химии предотвратило бы произошедшее.


                                      Почему нужно ограничение читайте в моих комментариях.

                                      Там нет объяснения, почему ограничение на химические процессы оправдано.

                                        +2
                                        только один язык сможет решать задачи эффективнее других.

                                        Еще, кстати, я не вижу способа формально это предположение опровергнуть, поэтому, согласно критерию Поппера, оно… ненаучно (по крайней мере, не является научной эмпирической теорией).

                                          +3
                                          А Вас и не интересует. И других разработчиков языков тоже. И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье. Почему нужно ограничение читайте в моих комментариях.

                                          Меня интересует, например, теория типов и всякая такая наркомания, но к вашему выводу я не прихожу. В чём я ошибаюсь?
                                        +2
                                        Потому что моё определение может ответить на ВСЕ вопросы о языке

                                        Я, кстати, внезапно заметил, что, собственно, никакого определения языка вы не привели. Или я пропустил что-то?

                                          –1
                                          Вы невнимательно читаете. Я не давал определения языка, я описывал его цели и задачи:
                                          Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат).
                                          И тут:
                                          2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
                                          Тут правильнее сказать не «обеспечивать», а «транслировать» мыслительный процесс в машинные инструкции с помощью языка конечно.
                                            +1
                                            Я не давал определения языка

                                            Значит, ваше определение не может ответить на все вопросы, потому что его просто не существует.


                                            Другими словами — язык не решает задач!

                                            Почему же, решает. Он решает как минимум задачу выражения алгоритма для вычислительного устройства (и это не единственная задача).


                                            Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.

                                            Как уже говорилось выше, понятие "эффективности" пока что объективно неизмеримо, и поэтому не имеет никакого преимущества перед настолько же субъективным понятием "удобства" (в значении "язык программирования удобен для программиста"). Поэтому я не вижу никаких оснований считать вашу формулировку ("[языки должны] эффективно транслировать мыслительный процесс человека в машинные инструкции") более правильной чем "[языки должны] быть удобным для их пользователей".

                                  +5
                                  Также как и наличие разных теорий может быть очень много, но правильная только одна.

                                  Неверно. Правильных теорий может быть много. просто у них будут свои области применимости.
                                  Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
                                  Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.

                                    –3
                                    Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ. Существующие теории в физике объясняют всего лишь часть устройства мира и его процессов, но не весь целиком. Значит учёные не выработали ещё такую теорию которая бы это сделала на данный момент времени. Ведь раньше люди думали что Земля плоская. Хотя, похоже, даже сейчас особо одарённые так думают.
                                      +4
                                      Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.

                                      Зато есть теории, обладающие достаточной предсказательной силой, чтобы быть успешно применимыми на практике. Что, кстати, доказывает, что языков программирования успешно может быть много.

                                        –1
                                        В том то и дело, что наклепать в большом количестве можно сколько угодно. И теорий и языков программирования. И только несколько языков из почти 2 сотен используются интенсивно и активно. Только какая от этого эффективность в решении задач? А сколько теорий происхождения человека у религий? А у науки? Так где более эффективный подход?
                                          +4
                                          Только какая от этого эффективность в решении задач?

                                          А вы уже нашли способ объективного измерения эффективности решения задач с помощью языка программирования?

                                        0
                                        Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.

                                        Нет гарантированно истинных теорий.
                                        Правильных много.
                                        При этом теория является правильной только для тех задач, которые она позволяет решать с приемлемой точностью.


                                        Кстати о плоской Земле, в задачах, когда кривизна поверхности не сильно сказывается на результате, она вполне себе принимается плоской (например, в задачах, связанных с прокладыванием маршрута).

                                        +1
                                        Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.

                                        Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.

                                        Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.

                                        Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн. В каких-то условиях можно упростить вычисления и пренебречь некоторыми особенностями: чисто волновое описание является опять таки частным случаем: просто для того что бы нам рассчитать антенны, нам не нужно городить формулы из квантовой электродинамики, а вот для описания фотоэффекта чисто волновое представление уже не проканает.

                                        Физика — она как Шрек, который как луковица :-) представляет из себя слои разных теорий разной степени приближенности к одной основной (пока неизвестной). Реально то теорий сейчас всего две — квантовая механика, да теория относительности, остальные можно рассматривать как их производные, да частные случаи и то, это только потому что КМ и ОТО не очень совместимы друг с другом.
                                          –1
                                          Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.

                                          Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.
                                          Другой вопрос, что эта разница не превышает требуемую точность, но разница все равно есть.
                                          Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным). В некоторых случаях оно даже прокатывало. Но по одному вопросу (вероятность повторного слияния и дальнейшее движение после слияния) не прокатило. Пришлось учитывать релятивистские спецэффекты.


                                          Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн

                                          Это уже третья теория, объединяющая наработки первых двух.
                                          Но при решении большого класса задач учитывать в модели все сразу не надо. А потому откатываемся назад, к одной из двух старых теорий.

                                            0
                                            Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.


                                            Угу изменение размеров из-за релятивистских эффектов велосипедиста будут на несколько порядков меньше ковалентного радиуса атома водорода и будут полностью замаскированы тепловыми флуктуациями — поправки преобразований Лоренца при малых скоростях становятся бесконечно малыми и стремятся к нулю, т.е. по-простому лишены какого-то физического смысла. Только софистики ради такие вещи можно обсуждать.

                                            Все эти эффекты становятся более-менее измеримыми только на космических скоростях. Вот на изменения перигелия Меркурия — мы увидим расхождение с классической механикой, наблюдая как резвятся черепахи — даже физически замерить не сможем.

                                            В ОТО и СТО классическая механика Ньютона является предельным частным случаем и справедлива для движения в относительно слабых гравитационных полях и при малых скоростях.

                                            Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным).
                                            Это наверное были какие-то неправильные СМИ у которых какие-то неправильные новости. Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать. Так шо я даже хз, че там можно намоделировать задействовав ньютоновскую механику… вероятно ничего
                                              0
                                              > Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать.

                                              Вообще-то в ньютоновской теории тяготения черные дыры тоже вполне себе есть, и у них даже радиус совпадает с шварцшильдовским.
                                                –1

                                                Физики заодно переопределили понятие частного случая?
                                                Частный случай, это когда результат совпадает точно, а не когда погрешностью можно пренебречь или ее нельзя измерить.


                                                А с черными дырами все намного проще. Моделировалось не то, что происходит в самой черной дыре, и даже не то, как происходит сам процесс слияния, а всего лишь то, как они перемещаются в пространстве, из чего оценивалась вероятность слияния.
                                                И рассматривали черные дыры как просто очень тяжелые предметы. И они вели себя в рассматриваемых случаях в основном вполне по правилам ньютоновской механики с достаточно большой и заметной, но приемлемой для ученых погрешностью.
                                                С первыми слияниями, как я понял, у них вполне сошлось. А вот с повторными не срослось. Пришлось задействовать более сложную теорию.

                                          +5
                                          Также как и наличие разных теорий может быть очень много, но правильная только одна.

                                          Какая математика истинная, с аксиомой выбора или без неё?
                                            0
                                            Спасибо за комментарий. Раскройте Ваш вопрос более полнее и точнее. А то Ваш вопрос вызывает больше вопросов, чем ответ на него.
                                              +4
                                              Я, если честно, даже не знаю, как его как-то полнее раскрыть.

                                              Ну вот вы говорите, что правильная теория только одна. Я вот вас спрашиваю, какая теория множеств правильная, ZF или ZFC?

                                              Есть ещё и другие альтернативные аксиоме выбора аксиомы, позволяющие тоже доказывать всякие полезные и интуитивно очевидные факты, но с чуть меньшим количеством всякой неинтуитивной ерунды, но это уже другой разговор.
                                                0
                                                «Я вот вас спрашиваю, какая теория множеств правильная, ZF или ZFC?» — А что учёные говорят по этому поводу? В вики написано: «К этой системе аксиом часто добавляют аксиому выбора, и называют системой Цермело — Френкеля с аксиомой выбора (ZFC).» — получается что ZFC всего лишь надстройка над ZF?
                                                  0
                                                  А что учёные говорят по этому поводу?

                                                  Какие? Математики? Ну, противники аксиомы выбора аксиому выбора опровергнуть не смогли ;)

                                                  получается что ZFC всего лишь надстройка над ZF?

                                                  Выводы из ZF не являются подмножеством выводов из ZFC, это разные теории. В одной вы можете слепить из одной сферы две, разрезав её на конечное число кусков, в другой — нет. В одной у бесконечномерных пространств есть базисы, в другой — нет. В одной любое множество можно вполне упорядочить, в другой — нет. В конце концов, в одной ясно, зачем нужна формальная теория вероятности с сигма-алгебрами, а в другой — не очень.
                                                    0
                                                    Нет, не говорит. Просветите пожалуйста. Насколько я догадываюсь, хранение состояния реализовано через функцию и хитрое условие хранения переменной и её изменения. Я прав?
                                                      +6
                                                      Это вы, видимо, на другой мой комментарий про фазовое пространство, ну да ладно.

                                                      Нет никакого хранения состояния, есть просто множество всех возможных состояний. Вам не нужно хранить состояние, если у вас они есть все возможные, и особенно если вы можете записать правило изменения состояния (а вы можете, потому что по предположению ваша задача алгоритмизуема).

                                                      В конце концов, можно на википедии почитать. А ещё можно вспомнить, например, про формальное определение рекурсии, про трансфинитную индукцию и прочие подобные вещи, тоже навевающие мысли о состоянии.

                                                      И, к сожалению, не могу не воздержаться от такой ремарки. Вот мы тут в комментариях к статье про научный подход к программированию. Тема статьи накладывает определённые ожидания к уровню научной и математической культуры автора, коли уж он собирается заниматься формализацией программирования. Но куда не тыкни — как-то не густо. Про разные теории в математике никак, про понятие состояния и фазового пространства в физике никак (а даже я, долбанный примат, с теормеха на втором курсе это помню), про вышеупомянутые всякие трансфинитные индукции-рекурсии, готов поспорить, тоже никак. Ну и особенно забавно, что те люди, которые в этом всём как-то шарят, не горят желанием химией измерить программирование, а садятся и пишут папиры про теорию типов, или пишут свои системы типов, и так далее.
                                          0
                                          А почему не должно? Почему должно быть так мало языков?


                                          А зачем их собственно много? Я еще понимаю ассемблер — он для каждого процессора свой нужен, хотя один фиг, все ассемблеры (по крайней мере для одного типа вычислительных машин) будут пересекаться друг с другом основным набором команд.

                                          А вон у совсем брутальных хардварщиков языка вообще два — Verilog, да VHDL, да их производные и справляются как-то.

                                          А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.

                                          Собственно реально массово используемых действительно не так уж и много языков, а все современные языки происходят либо от Fortran'а и его прямых потомков: Algol и Basic, либо от более поздних независимых веток: APL, Lisp (точнее IPL), COMIT и Cobol (точнее FLOW-MATIC) — больше чойт на память и не приходит, либо их комбинации.

                                          С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли, но между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)
                                            +1
                                            А зачем их собственно много?

                                            Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.


                                            Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.

                                            Ну так вкусовщина — это же совершенно валидный аргумент. До тех пор, пока одной из задач языка программирования будет передача намерения одного программиста другому программисту, выбор языка (и стиля письма) будет обусловлен в том числе и сугубо субъективными факторами.

                                              0
                                              Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.

                                              Ну их все равно реально используемых не так много:

                                              Любишь металл: C, да ассемблеры

                                              Любишь тяжелый металл: VHDL, да Verilog

                                              Хочешь быстро: C/C++ или Fortran, между ними правда таки есть специализация.

                                              Хочешь безопасно: Жаба или C#, ну еще Delphi. А что лучше: Жаба или дотНЕТ вопрос скорее религиозного толка (хотя хз, когда видишь, шо в Жабе Stack потомок Vector, который потомок ArrayList — становится грустно).

                                              Хочешь странного: F#, Haskell, Scala… хот вон уже в C# тоже вон есть LINQ, всякие анонимные функции и прочий ужас…

                                              Любишь Яблоко: они вообще за тебя определяют на каком ЯП сейчас модно кодить, сейчас вроде бы Swift, но я в яблочных делах не разбираюсь.

                                              Хочешь больше свободы: Пухтоны, да ЖабаСкрипты всякие… хотя вон в C# есть var, dinamic и куча другого сахара, снова он тут…

                                              Любишь математику: Matlab, Mathematica, Mapple, R и т.п., хе-хе, они уже не general purpose и медленные, возвращаемся в самое начало, берем всякие бусты и лаппаки, и…

                                              Работаешь в бухгалтерии: гхм, 1С, да VBA (а еще говорят, что Cobol до сих пор используют, но я не видел).

                                              Любишь гуишки: Qt, хотя под .NET есть всякие devexpress, arction lightningchart…

                                              Хочешь веб… а вот про веб я ничего не знаю. Ну еще у базистов парочка своих языков.

                                              Ну и и несколько новых, на которых пишет 3.5 анононимуса (в силу разных причин): D, Rust, Julia. Вот они ниче так себе, но не мейнстрим, увы :-(

                                              Ну собственно все. Еще и мультиплатформенность нынче уже не такая проблема.
                                              Не такой уж и большой выбор получается, но одновременно инструментов уже столько что-бы впасть в паралич разработчика. Но вообще, если у разработчика стальные яйца, то я думаю он может все писать исключительно на C/C++ с примерно одинаковой эффективностью (средняя температура по больнице).

                                              Большое обилие языков все же скорее это результат процесса их эволюции.
                                                0

                                                Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?


                                                Большое обилие языков все же скорее это результат процесса их эволюции.

                                                … что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до "одного-двух" видов.

                                                  0
                                                  Основная мысль автора понятна, с точки зрения точных наук — истина одна… но в искусстве нет точности. Кажись, ЯП где то между ними)
                                                    –1
                                                    Уверен что программирование даже частично искусством называть нельзя ( хотя несколько лет назад я сам так думал). Здесь прагматический подход, логика, математика, опыт, специфическая психология работы. Нельзя прийти, написать какую-то белиберду и сказать: Я так вижу! Я так чувствую! Меня муза посетила…
                                                      0

                                                      Нет, Вам никак не погубить ту романтику, что я испытываю к ЯП… ни с математикой, ни с химией и т.п. ничего подобного я не испытывал!) А что стало причиной гибели Вашей страсти, любопытно было бы услышать.

                                                        0
                                                        А я и не пытался ничего губить! Я же написал что из себя это искусство и романтика представляет всего лишь «специфическую психологию работы» программиста. В этом нет ничего плохого или унизительного. Вам просто нравится заниматься любимым делом больше других и Вы от этого получаете наслаждение. Как получают другие люди от других видов профессий.
                                                        0

                                                        Вы же сами написали "Особо упоротые фундаменталисты придумали Функциональное Программирование основанное на математике", подразумевая рак, щуку и лебедя… может исключим тогда уж доконца однобокость восприятия, в перечеслении составляющих программирования.


                                                        "Меня муза посетила…" неужели не было никогда озарения после долгого периода мучений — Вы точно программист?)

                                                          0
                                                          Так математика и есть искусство.
                                                        0
                                                        Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?

                                                        Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.

                                                        … что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до «одного-двух» видов.

                                                        Ну кстати я такой фигней немного занимаюсь (только с другого бока) там на самом деле видовое разнообразие испытывает периода взрывного роста и обеднения. Ну а один вырвавшийся вперед вид начинает вытеснять остальные. Гхм, кролики и коты в Австралии — местная флора и фауна от них офигела. Тех же кроликов пытаются можно сказать биологическим оружием теперь истреблять.

                                                        image
                                                        Автор: CSIRO, CC BY 3.0, Ссылка

                                                        Но эт я отвлекся. Да, на самом деле я думаю развитие языков похоже на биологическую эволюцию.
                                                          +1
                                                          Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.

                                                          А не важно, нишевые они или нет (хотя за определение некоторых языков как "нишевых" с вами многие бы и поспорили), важно, что они есть и у них есть применение (собственно, не бывает нишевых языков без соответствующей ниши), для которого они лучше других. Что лишний раз доказывает полезность существования многих языков.

                                                        0
                                                        Хочешь безопасно: Жаба или C#, ну еще Delphi.

                                                        Эти языки не делают вообще ничего для безопасности (если не сравнивать с голыми сями или C++98, конечно). Сравните с более выразительными языками с более адекватной системой типов.

                                                        Хочешь странного: F#, Haskell, Scala… хот вон уже в C# тоже вон есть LINQ, всякие анонимные функции и прочий ужас…

                                                        Да, хаскель — это про анонимные функции. И стопицот способов написать факториалы ещё, небось. Именно так.

                                                        Не про строгую систему типов, не про чистоту, не про if it compiles after refactoring, it works, а про лямбды и прочий ужас.

                                                        Хочешь больше свободы: Пухтоны, да ЖабаСкрипты всякие… хотя вон в C# есть var, dinamic и куча другого сахара, снова он тут…

                                                        Свобода — это отсутствие статических типов? Ну ок,

                                                        Dyna : Type
                                                        Dyna = (a : Type ** a)
                                                        
                                                        dyna : a -> Dyna
                                                        dyna x = (_ ** x)
                                                        
                                                        data MyData = SomeCtor | OtherCtor
                                                        
                                                        dynaList : List Dyna
                                                        dynaList = [dyna 42, dyna "meh", dyna OtherCtor]
                                                        


                                                        Ма, смотри, у меня динамическая типизация в одном из строжайше типизированных языков!

                                                        На типах матчиться нельзя, правда, потому что parametricity и type erasure после тайпчекинга, но не все считают это корректным и достаточным обоснованием (и я не считаю), и есть ресёрч на тему систем типов, позволяющих потом матчиться на первый компонент dependent pair.

                                                        Любишь математику: Matlab, Mathematica, Mapple, R и т.п., хе-хе, они уже не general purpose и медленные, возвращаемся в самое начало, берем всякие бусты и лаппаки, и…

                                                        Пойду символьные вычисления на лапаках делать, ага.
                                                          0
                                                          > Ма, смотри, у меня динамическая типизация в одном из строжайше типизированных языков!

                                                          Не, ну динамика, это когда можно невозбранно сложить строку с числом (например dynamic в шарпе это позволяет). А вы же в данном случае никаких операций к dyna применить не можете, то есть фактически моделируете подтипирование на экзистеншоналах (вполне статическое), так?
                                                            +1
                                                            Не, ну динамика, это когда можно невозбранно сложить строку с числом (например dynamic в шарпе это позволяет).

                                                            Вы динамику со строгостью тут случаем не путаете? А то у вас питон получается не очень динамический.

                                                            А вы же в данном случае никаких операций к dyna применить не можете

                                                            Зависит. Я, увы, не могу паттерн-матчить на типах (см. последующий абзац в предыдущем комментарии), поэтому написать функцию вроде
                                                            justStrings : List Dyna
                                                            justStrings = filter f dynaList
                                                              where
                                                                f : Dyna -> Bool
                                                                f (String ** _) = True
                                                                f _ = False
                                                            

                                                            у вас не получится. При этом (опять же, см. последующий абзац в предыдущем комментарии) каких-то теоретических причин не иметь это в системе типов нет, кто-то там что-то ресёрчит на тему.

                                                            то есть фактически моделируете подтипирование на экзистеншоналах (вполне статическое), так?

                                                            О, как раз нет, и в этом принципиальное различие! На экзистеншиалах вы стираете исходный тип и в лучшем случае знаете, что значение реализует какой-нибудь тайпкласс. А тут у вас именно что динамика в питон-стиле (где рядом с каждым значением лежит его тип) — список зависимых пар, где первое значение — тип, а второе — значение этого типа. При этом тип любой пары одинаков, и вы его знаете.

                                                            Там ещё можно забавные параллели с квантором существования и прочими Карри-Говардами привести.
                                                              0
                                                              Поигрался ещё, можно, например, слить вместе два списка, сохраняя информацию о типах, чего вы никогда не сделаете на экзистеншионалах в хаскель-стиле:
                                                              dynaList : List Dyna
                                                              dynaList = [dyna 42, dyna "meh", dyna OtherCtor]
                                                              
                                                              otherList : List Dyna
                                                              otherList = [dyna "wut", dyna 13.0, dyna SomeCtor]
                                                              
                                                              zipped : List Dyna
                                                              zipped = zipWith f dynaList otherList
                                                                where
                                                                  f : Dyna -> Dyna -> Dyna
                                                                  f (_ ** x) (_ ** y) = dyna (x, y)
                                                              


                                                              *Dyna> zipped
                                                              [((Integer, String) ** (42, "wut")), ((String, Double) ** ("meh", 13.0)), ((MyData, MyData) ** (OtherCtor, SomeCtor))] : List (a : Type ** a)
                                                              


                                                              В принципе, можно сделать функцию, которая будет складывать вам числа со строками, но тогда тайпчекер потребует, чтобы вы статически доказали, что вы динамически делаете все нужные проверки в том или ином виде (иными словами, ей нужно будет передать доказательство, что типы можно складывать). И тут я уже как-то запутался, что есть статическая типизация, а что — динамическая.

                                                              Забавно, надо ещё поиграться.
                                                                0
                                                                И тут я уже как-то запутался, что есть статическая типизация, а что — динамическая.

                                                                Тыц!
                                                                  0
                                                                  Спасибо, узнал очень много нового для себя!

                                                                  Так какой вид типизации в примере выше, особенно с последующей ремаркой?
                                                                0
                                                                > Вы динамику со строгостью тут случаем не путаете? А то у вас питон получается не очень динамический.

                                                                Нет. Оговорюсь, под «когда можно невозбранно сложить строку с числом» подразумевалось, что это запрещено статически (программа не скомпилируется). В питоне это запрещено, но динамически, в рантайме.

                                                                > О, как раз нет, и в этом принципиальное различие! На экзистеншиалах вы стираете исходный тип и в лучшем случае знаете, что значение реализует какой-нибудь тайпкласс. А тут у вас именно что динамика в питон-стиле

                                                                Но вы же не можете никаких операций к этому типу применить. То есть это аналог вполне статического Object из вполне статической джавы. В динамике вы должны иметь возможность применить к объекту любые операции (опять же — речь о статических проверках, в рантайме, конечно, операция может и не быть успешно выполнено, главное что компилятор вам даст написать такую программу).

                                                                И, более того:
                                                                > Я, увы, не могу паттерн-матчить на типах

                                                                Даже если бы могли — это не было бы динамикой все равно. В динамике проверок типов (при компиляции) в принципе нет и потому вам вообще матчить ничего не надо. Вы просто берете и применяете любую ф-ю к любому аргументу.

                                                                > И тут я уже как-то запутался, что есть статическая типизация, а что — динамическая.

                                                                Ну, общепринято, что когда типы проверяет компилятор до рантайма — это типизация статическая, а когда типы проверяются в рантайме — то это динамическая.
                                                                  0
                                                                  В динамике проверок типов (при компиляции) в принципе нет и потому вам вообще матчить ничего не надо.

                                                                  Так эта функция (и соответствующий паттерн) и будет выполняться в рантайме!

                                                                  Ну, общепринято, что когда типы проверяет компилятор до рантайма — это типизация статическая, а когда типы проверяются в рантайме — то это динамическая.

                                                                  Ну тут типы проверяете вы в рантайме, а компилятор в компилтайме проверяет, что вы их проверяете в рантайме.
                                                                    0
                                                                    Ну тут типы проверяете вы в рантайме, а компилятор в компилтайме проверяет, что вы их проверяете в рантайме.

                                                                    Ну это как в typescript, например. То есть статика :)
                                                                    В случае динамики компилятор ничего не проверяет.

                                                                      0
                                                                      Почему? В том же питоне среда выполнения гарантирует наличие этих проверок «по построению», а здесь я просто руками строю такую же среду, а статический тайпчекер мне в этом помогает.

                                                                      По сравнению с классической статической типизацией в хаскель/идрис/мл-стиле, где после тайпчекинга у вас вообще никакой информации о типах (пока сами не попросите через какой Typeable), здесь вам именно что нужны типы, и вы именно что в рантайме будете проверять, что в одной Dyna лежит число, в другой — строка, и так далее.
                                                                        0
                                                                        Почему? В том же питоне среда выполнения гарантирует наличие этих проверок «по построению»

                                                                        Но она не проверяет их наличие. Они просто есть. Если бы их не было — никто не помешал бы программе скомпилироваться. В случае, например, тайпскрипта, если вы руками не напишете эту проверку, то программа не скомпилируется.


                                                                        здесь вам именно что нужны типы, и вы именно что в рантайме будете проверять, что в одной Dyna лежит число, в другой — строка, и так далее.

                                                                        Ну так это отличается чем-то от статических типов с подтипированием и occurrence typing? Я могу для dyna выполнить операцию без проверки? Именно эта возможность и определяет, динамика у вас или нет.

                                                                          0
                                                                          Они просто есть. Если бы их не было — никто не помешал бы программе скомпилироваться. В случае, например, тайпскрипта, если вы руками не напишете эту проверку, то программа не скомпилируется.

                                                                          А если это случай какого-нибудь JS, когда проверки формально тоже есть, но неявные приведения очень неочевидны, и поэтому, насколько я знаю, люди пишут проверки руками?

                                                                          Ну так это отличается чем-то от статических типов с подтипированием и occurrence typing?

                                                                          Я сходу вообще не вижу связи с этими двумя видами типизации.

                                                                          Я могу для dyna выполнить операцию без проверки?

                                                                          Без динамической? Только не затрагивающую семантику этого типа (например, взять два Dyna и сделать Dyna из их пары, см. пример выше).

                                                                          Именно эта возможность и определяет, динамика у вас или нет.

                                                                          В моей ментальной модели динамичность типизации определяется там, когда именно происходит проверка, при компиляции или при выполнении.
                                                                            0
                                                                            > А если это случай какого-нибудь JS, когда проверки формально тоже есть, но неявные приведения очень неочевидны, и поэтому, насколько я знаю, люди пишут проверки руками?

                                                                            Тогда это динамика. Потому что скомпилируется все, что угодно.

                                                                            > Я сходу вообще не вижу связи с этими двумя видами типизации.

                                                                            ТАк а отличие-то в чем? Ну что можно написать в одной и нельзя в другой?

                                                                            > Без динамической?

                                                                            Да.

                                                                            > Только не затрагивающую семантику этого типа

                                                                            Ну вот. То есть у вас просто аналог типа Тор.

                                                                            > В моей ментальной модели динамичность типизации определяется там, когда именно происходит проверка, при компиляции или при выполнении.

                                                                            Ну вот ваш дина проверяется при компиляции. Именно компилятор проверяет, а не применяете ли вы к дина операции, которые нельзя применять к дина. Если бы он это не проверял (или проверка бы сводилась к тому, что применять можно все операции, что эффективно эквивалентно отсутствию проверки), то была бы динамика. Короче, если вы можете написать со своей дина какой-то код, который не скомпилируется из-за ошибки типов — то это явно не динамика.
                                                              –3
                                                              Вы как-то сильно рефлексируйте. Не надо так.
                                                              image
                                                                +2
                                                                Вы высказываете набор утверждений, с некоторыми из которых я не согласен. Я отвечаю на эти ваши утверждения некоторыми комментариями. Вы бы, что ли, ответили на эти самые комментарии, а то, как вы говорите, не надо так.

                                                                Пикабушных картинок нету, извините, подставьте что-нибудь сами.
                                                          0
                                                          А зачем их собственно много?

                                                          Но на самом деле, я просто считаю эту подмену вопроса некорректной. "Зачем много языков" — может быть и низачем, черт знает. "Должно быть мало языков" — э, почему вдруг внезапно? Из "низачем не надо много" никак не вытекает "должно быть мало".

                                                            0
                                                            Не. Ну языков все равно должно быть больше 1-ой штуки. Шоб была конкуренция и не вернули рабовладельческий строй.

                                                            Ну еще вкус и цвет, есть вот например люди, которые скобочки любят…

                                                            Но в итоге, даже если языков будет 10 конкурирующих между собой, то в своей основе они будут мало различаться. Собственно это мы сейчас это и наблюдаем: во все языки напихивают как можно больше самых разных парадигм программирования и технологий. Единственная проблема действительно в… эээ… в строгости определения понятия ООП и как меняются на него взгляды (опять таки — эволюция языков и подходов) и реализации.
                                                              –3
                                                              Браво! Отличный комментарий! Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии. Взять хотя бы SQL с его стандартами — ну разве не красота? Правда каждая реализация норовит его расширить, но стараются держаться в разумных пределах. Примерно так и должно быть с остальными языками. Должен быть стандарт.
                                                                +3
                                                                Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии.

                                                                Вы не находите, что вы противоречите себе же, в той части, где "должен быть один максимально эффективный язык"?


                                                                Взять хотя бы SQL с его стандартами — ну разве не красота?

                                                                Нет, не красота. После того, как попробуешь на этом "стандартном" языке порешать задачи из реальной жизни, любовь к стандарту резко пропадает.

                                                            –1
                                                            Спасибо за подробные комментарии! Ваша помощь очень пригодилась! Напишите еще свои мысли или замечания к статье, если они у Вас есть.
                                                              +1
                                                              А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.

                                                              Мне бы очень хотелось, чтобы люди, так считающие, на секунду задумались о том, что бы случилось с индустрией, если бы другие люди, считающие точно так же, но лет на 60 раньше, где-нибудь в 50-х, таки навязали бы эту точку зрения.

                                                              С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли

                                                              Не вижу логической связи между строгим образованием и глубиной/широтой проникновения приёмов.

                                                              между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)

                                                              И что из этого следует? Хаскель вычеркнуть, а уж всякие идрисы и агды — тем более?

                                                              Ну так оставить один javascript тогда, на нём орды программистов. Правда, топикстартер будет не очень счастлив такой интерпретации его тезиса, учитывая его же комментарии выше, ну да ладно.
                                                                0
                                                                Не вижу логической связи между строгим образованием и глубиной/широтой проникновения приёмов.

                                                                Не вижу логической связи между моим сообщением и Вашими комментариями.
                                                                Что общего между карандашом и ботинком? :-)
                                                                  0
                                                                  Обычно предложения, построенные по структуре «A имеет B — C», где A — некоторый объект, B — его свойство, C — наблюдаемый факт, имеют один из двух смыслов: либо C обосновывает B, либо B постулируется, а C описывается как следствие. Я говорил о первой интерпретации, но можно обсудить и вторую, конечно же.
                                                            +1

                                                            Обнаучить процесс программирования — цель благая. Научным методом доказать правильность, эффективность и превосходство одной из парадигм — достойная цель.
                                                            Предлагаю начать с первого вопроса: "Что такое программирование?".
                                                            Боюсь, ответ будет почти там-же, где и определение "Искусственный интеллект".
                                                            Упрется все в "Интеллект".
                                                            Спрашивал в институте им. Бехтерева — пока молчат…

                                                              –1
                                                              Хороший вопрос — тянет на отдельную статью и даже научный труд! Тяжело будет — зато достойный целой жизни. Но боюсь опять набегут личности, не отвечающие за свои слова, и не поняв ни фактов ни логики начнут гадить. Но это останавливать не должно.
                                                                +4

                                                                Я это к тому, что прежде чем включать научный метод и математику, необходима точка отсчета. А её нет. Лет уже больше 50 как нет. И без её наличия ни научный метод ни математика не применимы.

                                                                  –2
                                                                  Именно это я в статье и говорю. Да, нужна точка отчёта. Я пытаюсь. Но ведь кто-то тоже должен сделать попытку. Почему не Вы?
                                                              +3
                                                              Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании? Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей. А вот Ваши «доказательства» и «объяснения» — они то и не нужны никому от слова «совсем».
                                                              В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
                                                              Интересно, откуда такие цифры?
                                                              Факты:
                                                              Относятся к реальному миру, а не к программированию.
                                                              несколько принципов:
                                                              Похожи на смесь Coding Style Guide и какого-то очередного шаблона проектирования, которые вы так ненавидите.
                                                              Гипотеза:
                                                              Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.

                                                              P. S. Почему в качестве ЯП для «доказательства гипотезы» выбрана Java? Она ведь полностью объектно-ориентирована, а судя по Вашей статье, хуже ООП может быть только ФП)
                                                                –1
                                                                Спасибо за вопросы! По пунктам:
                                                                1. «Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании?» До определённого момента это было нужно и было доказано и обосновано логически, теоретически и экспериментально, а после нет. Почитайте ссылки которые я привел — хотя бы по-диагонали чтобы понять масштаб проблемы.
                                                                2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
                                                                3. «Интересно, откуда такие цифры?» — habrahabr.ru/post/353408/#comment_10752012
                                                                4. «Относятся к реальному миру, а не к программированию.» — а чем занимается программирование Вы задумывались? Ведь программирование было ещё до ЭВМ и автоматов. Подумайте в эту сторону и в историю углубитесь.
                                                                5. «Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.» — Вы невнимательно прочли. Вот оригинал: «3. Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять.» Не код, а объекты! Это большая разница.
                                                                  +1
                                                                  1. Можете пожалуйста конкретно указать статью? Ссылок очень много, и в основном это просто холиварные статьи.
                                                                  2. Задача языка — предоставить удобный программисту инструментарий для решения задач. «Доказательства» и «объяснения» на каждом шагу — это не очень удобно.
                                                                  3. Так если истина едина, зачем целых 6 языков?)
                                                                  4. Программирование занимается симуляцией процессов в окружающей среде, потому что просчитывать каждый атом во Вселенной Вам никаких машин не хватит. И я нахожусь не в истории, а в реальности, и задачи решаю соответствующие. А про программирование до нашей эры ИМХО Вы написали не на тот ресурс.
                                                                  5. Это все, что Вам удалось родить после простыни про научный подход и оскорбления признанных ученых?
                                                                +3
                                                                Как, опять??
                                                                Ну сколько же можно мучить парадигмы программирования. Тем более не предлагая альтернативы…
                                                                Я, как и многие тут, не увидел в вашем тексте ни намёка на «научное программирование», только лишь странные, ничем не подтверждённые, измышления, и яркое желание изнасиловать сложившиеся методики программирования.
                                                                Задавать вопрос «А зачем вам это вообще», наверно бессмысленно.
                                                                Потому задам другой: а с чего вы решили, что предлагаемый вами подход будет хоть кому-то полезен? Где ваше научное или маркетинговое исследование?
                                                                Сколько я знаю языков программирования и историй их создания — авторы почти всех (или даже совсем всех...) реально используемых языков при создании очередного ЯП руководствовались вполне конкретными целями и решали вполне конкретные проблемы. И ЯП становился популярным именно тогда, когда пользователи этого ЯП, сиречь программисты, ощущали оную пользу и всячески благодарили автора(ов).
                                                                Следуя реалиям жизни, вам стоит создать таки свой ЯП и представить его миру, выстоять под градом камней и затем уж получить заслуженные почести.
                                                                Ну или хотя бы, опишите и докажите теорию, согласно которой выбранные подход к ООП является наиболее эффективным по ряду критериев… Или хоть выведите и обоснуйте эти критерии, проранжируйте по ним существующие ЯП, сделайте выводы…
                                                                Да, кстати, приведённые вами примеры научного подхода ярко демонстрирую то, чего в вашем тексте нету…

                                                                И да, напоследок, про реальную жизнь: плохой программист напишет каку на любом, сколь угодно совершенном ЯП, а хороший пособен сделать конфетку на любом ЯП, которым он владеет. И как вы в эту реалию впихнёте превосходство вашего подхода — тоже интересный вопрос :).

                                                                ps
                                                                Истина одна, но она никому не нужна, потому правд много и именно ими пользуются живые люди. Почему так — почитайте философов…
                                                                  –3
                                                                  1. Вам лень читать? Серьезно? Вы на тот ресурс зашли?
                                                                  2. «Задача языка — предоставить удобный программисту инструментарий для решения задач» — Опять Вы придумываете небылицы! «инструментарий» — это автомат, процессор, какой-либо механизм, IDE на худой конец. Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат). Что здесь трудно понять? Почитайте что-нибудь для разнообразия прежде чем так выражаться.
                                                                  3. Зачем?
                                                                  4. «Программирование занимается симуляцией процессов в окружающей среде» — Я же Вам ответил и дал направление, но из-за лени Вы не потрудились ни изучить историю, ни напрячь мозг и начали выдавать сказки про симуляцию. Ада Лавлейс и Бэббидж тоже занималась симуляцией? Как Вам не стыдно такое даже печатать?
                                                                  5. «оскорбления признанных ученых» — где я это сделал можете указать?
                                                                    0
                                                                    :: язык не решает задач! Задачи решает алгоритм
                                                                    Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам. Как-то: развитой инструментарий, широкий набор готовых библиотек или компонентов (что тоже, де-факто, входит в понятие языка в моей терминологии), наличию разработчиков,…

                                                                    :: Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять
                                                                    Хотите я вам покажу большой объект, который будет легко понимать и читать. И сделаю вам код где много крохотных объектов, но вы замучаетесь пытаться понять что происходит? Конечно я не собираюсь этого делать — вопрос риторический и ответ на него очевиден.

                                                                    Я склонен согласиться с теми, кто считает что язык (всю экосистему) выбирают под задачи и разнообразие языков это добро. Вот это мне быстрее и удобнее выразить на такой платформе, а вот это — на такой. И многообразие языков (экосистем) это хорошо. Хочешь ИИ — питон какой-нибудь, хочешь быстро и удобно написать веб приложение — .net (особенно core), SPA? Vue, React (js), хочешь то — Си, хочешь сё — с++,… f# и т.д. Каждая экосистема появилась не просто так. И я бы не отделял абстрактный в вакууме язык от того что он несет с собой. И, главное, почему это самое «несу с собой» появилось.

                                                                    Дайте мне задачу — я объясню почему ее надо решать на выборе из таких-то платформ (языков)

                                                                    Появление, скажем, .core позволяет мне легко и красиво за день делать то, что раньше я делал месяцами.

                                                                    Включить мозг, читать очень много книг, лекций, статей, курсов, потом долго учиться применять самое умное из того что вы прочитали, придумывать свое и вы сможете писать отличный код на любом языке. И еще важный момент — не спать. Держать руку на пульсе. Но это не только у нас, айтишников. Ключевой момент — программированию надо серьезно учиться. Если вы умеете *программировать* — язык или платформа перестают быть важным моментом. Мне, например, не очень важно на чем писать (есть тонкие моменты, но это не для тут).

                                                                    Боязнь множества языков от осознания что мы просто не успеваем за развитием. Посмотрите что творится в мире фронтенда. Это же какой-то ужас… Но надо понять что хороший программист это не знаток реакта. Хороший программист тот, кто понимает почему код надо организовывать так, а не иначе. Что надо писать тесты и это не лишнее время, а наоборот его сильная экономия, что… Поэтому надо перестать бояться, начать изучать паттерны, подходы, идеи. Изучить синтаксис — недолго. Изучить идею (зная основные тенденции) — тоже недолго. Узнать тонкости… тут зависит от разработчика, наличия «у кого спросить» и поставленных задач, но, опять же не все так страшно.

                                                                    Прочитал Ваш пост по диагонали потому, что почти в каждой строчке есть спорный момент, так что если я вообще не понял суть — прошу извинить.
                                                                      –2
                                                                      Спасибо за развёрнутый комментарий.
                                                                      Как я и писал в статье — проблема в том что программисты спорят основываясь уже на реализации, а не на теории и науке. В этом большая разница! Грубо говоря в ЯП сейчас тихий ужас из-за описанной мною истории их создания. Если Вы начнёте мыслить с точки зрения основ программирования, его истории, задач и целей и каким образом именно наука, а не религия дало всё то, что нас сейчас окружает и какие подходы использовала, то признаете что рациональное зерно в этой статье всё таки есть. А лучше всего прочитать статью внимательно, походить по ссылкам, книгу почитать и комментарии мои и вдуматься в сказанное. Сделать это — большая и трудная работа, но она необходима. А терпением для этого мало кто может похвастаться.
                                                                      1. «Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам.» — написано в этом комментарии.
                                                                      2. «Хотите я вам покажу большой объект, который будет легко понимать и читать.» — Ответ действительно очевиден. «Если сильно захотеть — можно в космос полететь!». Только вот в науке и реальном мире сложное, по определению, не может быть проще простого.
                                                                      +2
                                                                      1. Читать кучу статей с заявлениями «все фигня, давай по новой, но я не знаю как» — да, лень. А Вам лень предоставить конкретный материал, который является подкреплением Вашей точки зрения?
                                                                      2. Как Вы хотите, что бы кто-то понял Вашу точку зрения, если сами не способны понять чужую? Язык предоставляет средства для решения задачи — это значит, что он предоставляет семантические конструкции, которыми программист может выразить свои мысли. В императивном программировании это разные инструкции, которые со временем оформили в процедуры, которые со временем объединили с данными и назвали классами. В функциональном это функции, которые не используют каких-то состояний, а выдают результирующие значения только на основе своих аргументов. ( Примеры поверхностные, но, надеюсь, Вы понимаете, о чем я. ) Задача языка — сделать так, что бы программисту было удобно пользоваться этими средствами, которые язык предоставляет, а также что-бы эта легкость использования не повлияла на качество программы, которая на языке будет написана. Соответствие каким-то наукам — это очень второстепенная задача.
                                                                      3. Это лучшая научная аргументация, которую Вы можете предоставить?
                                                                      4. А, так значит «научный подход» — это выбросить компьютеры и работать на изобретениях 19-ого века? Или нет? Просто Вы так и не объяснили.
                                                                      5. Например
                                                                      чем ваши слова отличаются от слов религиозного фанатика-экстремиста сбежавшего из психбольницы?
                                                                      Это не совсем прямое оскорбление, но Вы смешали с грязью практически все парадигмы программирования ( над которыми работали эти самые ученые ), при этом не удосужились не аргументировать свою точку зрения, ни предложить альтернативу, ни даже постесняться в выражениях. Я считаю, что это оскорбление.
                                                                      +1
                                                                      Я согласен с коллегой, то что сейчас происходит с ООП семейством языков — это медленный конец. Но Ваше восприятие парадигм — напрягает. Дело в том, что все ошибки ООП языков, о которых вы пишите, совершенно не связаны с МАТЕМАТИЧЕСКИМ ОТСУТСТВИЕМ теории. К сожалению, это действительно личные предпочтения их авторов. Но и ваш концепт, к сожалению, на мой взгляд, неполноценен, как раз из за полного отсутсвия мат теории. Все же идеи забытого и спрятанного Хаскеля, много лет шедшего рядом, но по другому, с ВЕЛИКОЛЕПНОЙ математикой и доказательностью — хороший пример именно основательного научного труда, на который нужно и следует опираться. И прежде всего на теорию категорий.
                                                                        0
                                                                        Спасибо за комментарий!
                                                                        Но я хотел бы уточнить что не только математической теории, а нет научной теории. Потому как математика не до конца сможет смоделировать предметную область(хоть без неё никуда не деться ни в мире, ни в науке) с её поведением и состоянием.
                                                                          0
                                                                          Потому как математика не до конца сможет смоделировать предметную область(хоть без неё никуда не деться ни в мире, ни в науке) с её поведением и состоянием.

                                                                          Я бы посмотрел, как вы научно моделируете что-нибудь без математики.
                                                                            0
                                                                            Я не утверждал что без математики моделирование может обойтись. Я сказал что с её помощью моделирование и происходит. Видите разницу? Другими словами: чистая математика — не может смоделировать предм. область потому что в этой области есть состояния. А у математики состояния нет. Надеюсь понятно объяснил.
                                                                              0
                                                                              Значит, я не так понял ваш предыдущий комментарий, увы.

                                                                              Другими словами: чистая математика — не может смоделировать предм. область потому что в этой области есть состояния. А у математики состояния нет.

                                                                              Состояние можно рассматривать как функцию из множества нужной мощности в множество допустимых значений параметров системы.

                                                                              В конце концов, термин «фазовое пространство» вам что-нибудь говорит?
                                                                        +1
                                                                        Могу предположить, что когда вводили понятие объекта — за основу приняли то, что видели вокруг себя — человека и животных. И в этом была главная ошибка которая позже вырастет до огромных размеров! Таким образом, возможно, появилось наследование(предок-потомок и связь между ними объясняется наследованием, но как быть с другими объектами в мире?

                                                                        Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов. И предок-потомок тут скорее со стороны деревьев (не живых, а вполне математических) появились, поскольку классификация в ООП обычно строится как дерево (множественное наследование несколько "портит" "деревянную" картинку, но отношения предок-потомок сохраняются).


                                                                        И что значит само определение слова «наследование» в реальном мире? Кровь и ДНК? Азотистые основания?).

                                                                        Определение слова "наследование" в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.


                                                                        Как остальные термины, а именно абстракция, инкапсуляция и полиморфизм, относятся именно к ООП?

                                                                        Это инструменты для построения системы классификации объектов, т.е. инструменты для написания ОО программы. Можно и без них, но с ними легче как-то, чем без каких бы то ни было инструментов. Туда же можно отнести интерфейсы, сообщения, события и прочие средства реализации взаимодействия между объектами в соответствии с построенной моделью предметной области.

                                                                          –1
                                                                          Спасибо большое за комментарий!
                                                                          1. «Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов.» — Раскройте поподробнее эту тему, пожалуйста, в свете термина "наследование" и принципа подстановки Лисков.
                                                                          2. «Определение слова „наследование“ в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.» — А как быть с наукой и научным определением? Я же указал ДНК и азотистые основания! И примеры приводил про горы для кого? Какие такие «ценности» и «признаки»? Мне прямо сюда ссылки дать или сами найдёте и почитаете что такое наследование?
                                                                            +2
                                                                            1. Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).
                                                                              Упомянутый принцип подстановки всего лишь требует, чтобы поведение объекта подкласса не противоречило поведению, описанному в базовом классе.
                                                                            2. Никакой особой науки тут нет. Есть всего лишь средства описания модели предметной области, приближенные к средствам естественного языка, чтобы программист мог "сказать" компьютеру, что он хочет смоделировать.
                                                                              Отчасти это напоминает набор инструментов некоего мастера, который должен сделать, например, ремонт в квартире. Никакого научного обоснования того, какой именно инструмент и какие именно материалы мастер выберет для ремонта, быть не может.
                                                                              Он выберет удобный вариант для себя, позволяющий реализовать хотелки заказчика.
                                                                              В частности для задачи сверления дырки в стене он может выбирать из большого списка инструментов (дрель, ударная дрель, дрель-шуруповерт, перфоратор) опираясь на такие субъективные оценки, как удобство, или случайные, как, например, пропадание напряжения в розетке и наличия в аккумуляторном исполнении только дрели-шуруповерта.
                                                                              А вот при планировании ремонта мастер может озадачмться вполне научно обоснованными вопросами на тему вроде "выдержит ли балка вес" или "какое сечение должен иметь провод, чтобы не расплавился от нагрузки" (понятно, что он не будет проводить изысканий сам, а воспользуеься готовыми ответами). Туда же могут относиться решения в плане выбора цветовой гаммы (если оно не противоречит хотелкам заказчика).
                                                                              0
                                                                              Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).


                                                                              А вот смотрите, а что мешает вместо наследования использовать наборы общих компонентов? Компонент написан один раз, а используется во многих классах. Composition vs Inheritance, все дела.

                                                                              Упомянутый принцип подстановки всего лишь требует, чтобы поведение объекта подкласса не противоречило поведению, описанному в базовом классе.

                                                                              И тут мы пишем override или new…

                                                                              Вот кстати lair где-то тут уже писал о терминологии: наследование, состояние и т.д. и т.п. Допустим у нас есть вот такой метод у родителя:
                                                                              public int DoAdd(int adder)
                                                                              {
                                                                                  return privateSelfVarible + adder;
                                                                              }

                                                                              а у потомка:
                                                                              public new int DoAdd(int adder)
                                                                              {
                                                                                  return privateSelfVarible - adder;
                                                                              }

                                                                              Я вот думаю, что поведение наследника изменилась, более того — оно стало противоречить методу родительского класса (было сложение, стало вычитание), а сигнатура метода осталась таже. Если думайте, что на практике так не бывает… ну я думаю, что Вы так не думайте :-)
                                                                              Можно еще и new опустить и проинкрементировать счетчик предупреждений :-)
                                                                              И когда я такое вижу, то думаю «А чем наследование от класса лучше реализации интерфейса/-ов?»

                                                                                0
                                                                                А вот смотрите, а что мешает вместо наследования использовать наборы общих компонентов? Компонент написан один раз, а используется во многих классах. Composition vs Inheritance, все дела.

                                                                                Тут есть два момента. Решаемых, но все же.
                                                                                Во-первых, мелкая логическая неувязка. Мы отходим от иерархической классификации, когда объекты подклассов одновременно относятся и к некоторому общему классу.
                                                                                Например, имеем класс "окно". Имеем подклассы (классы, наследующие "окно") — "окно такое" и "окно сякое". При этом объекты обоих классов могут рассматриваться как объекты класса "окно".
                                                                                При отсутствии наследования получаем пару независимых классов "окно такое" и "окно сякое", а для предотвращения дублирования кода еще и третий класс "что-то общее для всех окон".


                                                                                Во-вторых, мы теряем возможность без лишних телодвижений автоматически получить от всех окон что-то, заложенное в общей части. Придется городить дополнительный код для того, чтобы класс использовал то, что ранее просто наследовалось.


                                                                                Не то, чтобы это было серьезной проблемой, но оно есть.


                                                                                Я вот думаю, что поведение наследника изменилась, более того — оно стало противоречить методу родительского класса

                                                                                Такое противоречие обычно указывает на ошибку классификации, т.е. мы ввели в обобщающий класс что-то, на самом деле не являющееся общим для подклассов.

                                                                            0

                                                                            Каждый сам для себя выбирает определение ООП.
                                                                            Можно рассматривать объекты как исполнители контрактов.
                                                                            Контракт (интерфейс, АТД) — способ взаимодействия с объектом. (Абстракция)
                                                                            Нам не важно, как устроен объект, главное, что он исполняет контракт. (Инкапсуляция)
                                                                            Если есть два разных объекта, исполняющих один контракт, то нам не обязательно различать их. (Полиморфизм)
                                                                            Тогда обычное наследование — это наследование контрактов и их реализации.
                                                                            Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.

                                                                              0
                                                                              Каждый сам для себя выбирает определение ООП.

                                                                              У всех этих определений есть общая часть — моделирование предметной области в виде набора взаимодействующих объектов.


                                                                              Тогда обычное наследование — это наследование контрактов и их реализации.

                                                                              Это уже детали. Главное, что наследуется нечто общее для подклассов, которое и описано в базовом классе.


                                                                              Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.

                                                                              А это не вопрос ООП, а вопрос построения классификации в рамках модели.
                                                                              Если более общий класс описывает реализацию, то наследуется реализация. Если только контракт, то наследуется только контракт. Что мы в базовый класс поместили, то и наследуется.

                                                                            0
                                                                            Так вышло, что я немного знаю автора лично. Сначала он с поразительной быстротой подготавливал и публиковал обьёмные куски кода в комментариях к одной из моей статей. А в другой статье заметил пару досадных опечаток и через личку написал мне о них. Я был инициатором разгора. Разговор получился долгим, интересным и полным острых дискуссий.
                                                                            Это я пишу к тому, чтобы заверить читателей в том, что автор осень крепкий профессионал с большим опытом работы в разного типа проектов.
                                                                            Как я понимаю, там то и накопилась у него та боль, которую он выплеснул в этой статье.
                                                                            Тем не менее, Уважаемые Критики и Уважаемый Автор, давайте стараться уважать мнение друг-друга, даже если мы с ним и не согласны.
                                                                            Я тоже не согласен с многими тезисами автора. К сожалению, на Хабре отсутствует возможность «расщепить» статью на отдельные тезисы и структурно обсуждать их по-отдельности. (А кстати, кто-нибудь знает что-нибудь подобное на других форумных площадках?). Поэтому я свои комментарии к отдельным тезисам буду делать в виде отдельных комментариев.
                                                                              +2
                                                                              Честно говоря, я вот думал вставить пару мыслей, но потом обратил внимание на откровенно хамскую манеру общения и решил, что ну его, я не мазохист. Интересно, как можно иметь большой опыт работы с таким подходом к диалогу? Он с роботами что ли имеет дело только?
                                                                                +1
                                                                                Я не знаю состав команды автора.
                                                                                Но я Вас понимаю. К сожалению, автор в своём стиле общения не одинок. Это какая-то печалящая меня мода последних лет.
                                                                                Я, например, знаю хорошо одного коллегу, с высоким уровнем культуры и интересного собеседника, который почему-то считает, что это здорово писать Email в лексике пятикласника с добавлением профессиональных терминов.
                                                                                Ещё я раньше слушал подкаст Радио-Т. Ведущим не отнять профессионализма, да и темы интересные. Но я понял, что хамская манера разговора, пренебрежительные оценки чужих мнений и достижений, нецензурная лексика — это не моё. И перестал их слушать.
                                                                                Боюсь, что автор потерял не только Вас в качестве комментатора.
                                                                              0
                                                                              Если исключить из ЯП (Язык Программирования) возможность наследования, статические методы и атрибуты, абстрактные классы, то в проекте код станет минимум на 10-20 процентов меньше.

                                                                              Не могу согласится (как закоренелый c++-вик). В качестве простого примера, посоветую посмотреть на Go — там отсутствуют шаблоны/генерики, и это порождает огромное дублирование кода (boilerplate и "церемонию").

                                                                                –1
                                                                                Спасибо за комментарий. Но не могу согласиться — этот самый код просто выносится в отдельный класс(или объект) и по мере необходимости вызывается. Если Вам не сложно — приведите примеры дублирования и как это выглядит на 2 языках. Я потом покажу как можно это сделать по другому.
                                                                                  0

                                                                                  Просто придется перейти от иерархической классификации к выделению общего в самостоятельный класс и включению соответствующего поля в классы, которым нужно это общее.
                                                                                  Это позволяет решить некоторые проблемы разработки ценой ухода от интуитивно более понятной иерархической классификации.

                                                                                    0
                                                                                    Я неправильно составил этот пункт (и этот пункт будет изменён). Есть 3 варианта: новый код будет меньше, равен или больше чем с перечисленными признаками. Всё зависит от методологии, глубины иерархии наследования, количества потомков, масштаба логики и т.д.
                                                                                    И в большинстве случаев объем кода будет расти. Но это даст простоту в его анализе, использованию и пониманию, гибкости создания объектов и их изменения. И как заметил пользователь geher — нужно создавать отдельные классы для таких случаев, а не формировать предка в иерархии в виде абстрактного класса.
                                                                                    +2
                                                                                    Думаю, вы слишком буквально понимаете термины «объект» и «наследование».

                                                                                    ООП — это скорее стремление к классификации, типизации и определению подмножеств. Которые обладают схожими или одинаковыми свойствами и методами. Классы объектов подобны классам, отрядам и семействам в биологии. И такие же несовершенные. Как любая классификация.

                                                                                    К тому же, объект может вообще не быть физической сущностью. Например государство, организация, вид науки или искусства.

                                                                                    Сам метод ООП неидеальный. Так как мы пытаемся создать идеальную модель неидеального мира. Какбы написать идеальную инструкцию для исполнителя.

                                                                                    Языков же в реальном мире такое же множество, как и в программировании. Профессиональный язык хирурга отличается от языка портного или сапожника. Хотя они работают похожими инструментами, производят похожие операции — результат работы разный.

                                                                                    P. S. Ничего личного. Когда публикуете статьи на серьёзные научные темы, желательно соблюдать правила пунктуации и орфографии.
                                                                                      –1
                                                                                      Спасибо за комментарий.
                                                                                      А как по другому понимать ООП? Каждый сейчас в комментариях ООП понимает по своему и поэтому лепят от себя такие выверты и логические несуразицы, что волосы встают дыбом. Введение науки в программирование и определение терминов, с теориями ( и доказательствами), гипотезами приведёт к тому что мы знаем что Земля круглая со спутниками на орбите, а не верим, что она плоская и вокруг летают розовые единороги.
                                                                                      «Профессиональный язык хирурга отличается от языка портного или сапожника.» — У них то и задачи разные и ПОЭТОМУ и отличается!
                                                                                      «К тому же, объект может вообще не быть физической сущностью.» — Неверно. Такого с точки зрения науки не может быть — это или физическая сущность или это просто некая абстракция.
                                                                                        +1

                                                                                        Ну так абстракция — это и есть тот объект, который не физическая сущность.

                                                                                          –1
                                                                                          Никак не успокоитесь? Может хватит нести бред? Абстракция — это результат мышления и обобщения после наблюдения за какими-то свойствами реальных объектов и выделения из них существенных определений и признаков. А объект — это всегда физ. сущность.
                                                                                            +1
                                                                                            А объект — это всегда физ. сущность.

                                                                                            Только в рамках какой-то специфической терминологической системы, которой, возможно, пользуетесь вы, но не пользуюсь я (и не пользуется вся наука). Вот вам классическое определение: "Объект — философская категория, выражающая нечто, на что направлена практическая или познавательная деятельность субъекта (наблюдателя)". Философская категория — это не физическая сущность.


                                                                                            Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями) говорить, что объект — всегда физическая сущность? Если пользоваться этим определением, то в программировани объектов просто нет (и не может быть).

                                                                                              –2
                                                                                              1. «но не пользуюсь я (и не пользуется вся наука). Вот вам классическое определение». А как же другие определения? Даю ссылку — читайте все определения чуть ниже и не обманывайте ни меня ни других.
                                                                                              2. «Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями)» — Вы издеваетесь? Читайте что такое программирование в книге Китова которую я привел и не занимайтесь выдумыванием бреда.
                                                                                                –1
                                                                                                АВМ — тоже нематериальная сущность? И перфокарта тоже? Учите историю.
                                                                                                  +1

                                                                                                  Перфоркарта — это не программа (точно так же, как книга — это не повесть). Что касается АВМ — да, это прекрасно, но неактуально. Если хотите, я оговорюсь: подавляющее большинство современного программирования оперирует нематериальными сущностями.

                                                                                                  +1
                                                                                                  А как же другие определения?

                                                                                                  А вот так. Я уже сказал вам: определения существуют только в рамках терминологической системы, и в разных терминологических системах они могут не совпадать. Нет никаких оснований считать, что выбранная вами терминологическая система правильнее, чем любая другая.


                                                                                                  Даю ссылку — читайте все определения чуть ниже и не обманывайте ни меня ни других.

                                                                                                  Так там как раз прекрасно видно, что далеко не все определения сводятся к физической сущности, так что вы только подтверждаете мой тезис.


                                                                                                  Читайте что такое программирование в книге Китова которую я привел

                                                                                                  А почему я должен считать эту книгу авторитетным источником?


                                                                                                  (заметим в скобках, что определения программирования я там не нашел. Но вот вам случайная цитата: "Программирование состоит из двух основных этапов: составления логической схемы программы [...] и составления
                                                                                                  программы". И программа, и логическая ее схема — нематериальные сущности. Если вы, конечно, не считаете программой ее запись...)

                                                                                                    0
                                                                                                    1. «А вот так. Я уже сказал вам: определения существуют только в рамках терминологической системы, и в разных терминологических системах они могут не совпадать.» — Поразительный ответ! У меня научное и материальное определение объекта, а у Вас философское. Удачи Вам в программировании с таким подходом!
                                                                                                    2. «А почему я должен считать эту книгу авторитетным источником?» — Не считайте. Вам это не нужно. Вы же понятия не имеете кто это такой и чем авторитетен по сравнению с другими.
                                                                                                    3. «так что вы только подтверждаете мой тезис» — Не манипулируйте! Я не подтверждал ваш тезис. Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.
                                                                                                    4. «И программа, и логическая ее схема — нематериальные сущности» — Да прекратите бред нести?! А хранятся они где? А что из себя представляют?
                                                                                                    Вы же даже не понимаете какой бред сами же несёте!
                                                                                                    Так по-вашему программирование сводится только к написанию алгоритма? А дальше-то что происходит? Подскажу — 0 и 1. А это что такое знаете? Как они становятся материальными и главное где?
                                                                                                      +4
                                                                                                      У меня научное и материальное определение объекта

                                                                                                      "Научное"? Согласно какому критерию научности?


                                                                                                      Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.

                                                                                                      Это не делает ваш термин более правильным, чем мой.


                                                                                                      Да прекратите бред нести?! А хранятся они где? А что из себя представляют?

                                                                                                      А какое это имеет значение? Когда я строю алгоритм, я оперирую именно нематериальными объектами, и их последующее физическое представление в виде электронов и/или электромагнитных полей меня волнует мало.


                                                                                                      Так по-вашему программирование сводится только к написанию алгоритма?

                                                                                                      Нет, программирование сводится к созданию компьютерной программы (я не хочу сейчас вдаваться в развернутый спор "программирование vs разработка"). За небольшими уже упомянутыми исключениями, компьютерные программы — нематериальные объекты ("комбинация компьютерных инструкций и данных", "синтаксическая единица, которая соответствует правилам определённого языка программирования, состоящая из определений и операторов или инструкций, необходимых для определённой функции, задачи или решения проблемы", "structured collection of instruction sequences that perform a specific task when executed by a computer", "Every computer program is a model, hatched in the mind, of a real or mental process").

                                                                                                  –2
                                                                                                  АВМ — тоже нематериальная сущность? И перфокарта тоже? Учите историю.
                                                                                                  0
                                                                                                  Абстракция — это результат мышления и обобщения после наблюдения за какими-то свойствами реальных объектов и выделения из них существенных определений и признаков.

                                                                                                  Наблюдение за какими реальными объектами и сущностями привело к такой абстракции, как, например, изоморфизм Карри-Говарда? Арифметика кардиналов? Арифметика ординалов?
                                                                                                    –2
                                                                                                    "" — над числами. Как и вся база математики. Здесь же написано: «Порядковые числа были введены Георгом Кантором в 1883 году как способ описания бесконечных последовательностей, а также классификации множеств, обладающих определенной упорядоченной структурой.[1] Он случайно открыл порядковые числа, работая над задачей, связанной с тригонометрическими рядами. » Основой математики(и геометрии) является число. Все остальные абстракции лишь следствие попыток объяснить окружающий мир. Начиная с круга и треугольника(станет потом геометрией и тригонометрией), множествами и точкой с прямой(которая потом станет декартовой системой координат). Надеюсь понятно объяснил.
                                                                                                      +3
                                                                                                      У нас числа стали внезапно реальными объектами? Покажите мне, пожалуйста, как выглядит 2 в реальном мире.
                                                                                                        –3
                                                                                                        Они ими и были: 2 любых предмета. 2 руки или ноги. Имеется ввиду что число — это количество каких-либо физических объектов. Не убедил? Может это поможет: «Число́ — основное понятие математики, используемое для количественной характеристики, сравнения, нумерации объектов и их частей.»?
                                                                                                          +3
                                                                                                          Число — это абстрактное понятие, а не реальный объект. 2 руки — это 2 руки, а не число 2. Щупая 2 руки вместо одной, вы будете щупать все так же руки, а не число 2.
                                                                                                          Больше того скажу, в Полинезии существуют народы, которые не знают данной абстракции. У них натурально для каждого существительного есть отдельные слова для разного количества. То есть отдельное слово для одной овцы, отдельное слово для двух овец. Аналогично с деревьями. И они не находят общих признаков у двух овец и двух деревьев.
                                                                                                            –2
                                                                                                            Там же: «Понятие числа возникло в глубокой древности из практической потребности людей и усложнялось в процессе развития человечества. Область человеческой деятельности расширялась и соответственно, возрастала потребность в количественном описании и исследовании. Сначала понятие числа определялось теми потребностями счёта и измерения, которые возникали в практической деятельности человека, всё более впоследствии усложняясь. Позже число становится основным понятием математики, и потребности этой науки определяют дальнейшее развитие этого понятия.» И дальше можете прочитать. Так что это говорит о народах Полинезии? Другими словами число — это количественная характеристика объектов. Вы как живой объект в количестве 1 штуки существуете и Вас можно посчитать и выразить в виде особого символа, верно?
                                                                                                              +3
                                                                                                              Еще раз. Есть народы, у которых нет этой абстракции. То есть 2 дерева физически существуют, а числа 2 нет. Да и в вашей же цитате написано, что число — это понятие.
                                                                                                              Следуя вашей логике слово — это тоже реальный объект, потому что в той или иной форме он существует у всех народов?
                                                                                                                –2
                                                                                                                «Следуя вашей логике слово — это тоже реальный объект». Нет. Это не реальный объект, только если не воспринимать его как звуковые колебания.
                                                                                                                  +3

                                                                                                                  … означает ли это, что слово — вообще не объект, поскольку, как вы утверждаете, объекты бывают только физическими сущностями?

                                                                                                                    0
                                                                                                                    Слово, как и число, как и символ — всё это абстрактные объекты.
                                                                                                              0

                                                                                                              Эм, прямо в процитированном вами определении сказано "число — [...] понятие". Понятие — не "реальный объект" никаким образом, это понятие.

                                                                                                                –1
                                                                                                                Это не отменяет того, что оно существует.
                                                                                                                  +1

                                                                                                                  Понятие "два" — существует, с этим никто не спорит. А реального объекта "два" — не существует.

                                                                                                                    –3
                                                                                                                    Как же не реальный? Вот я его вижу «два», «2». Я наблюдаю за этим объектом, и если я не сошел с ума, то он реален.
                                                                                                                      0
                                                                                                                      Вы вообще отличаете абстракцию от реального объекта? Для какого-то китайца «два» — это непонятные закорючки, но с понятием 2 он, очевидно, знаком.
                                                                                                                        –3
                                                                                                                        Если есть абстракция, то есть и реальный объект. Абстрактных объектов не существует.
                                                                                                                          0
                                                                                                                          Откуда такой замечательный вывод? Математика вообще по своей сути набор различных абстракций, причем далеко не всем из них удается сопоставить реальные объекты. Если вы уйдете чуть дальше арифметики — вы это поймете.
                                                                                                                            0
                                                                                                                            А откуда берутся абстракции? Либо из других абстракции, либо из реальных объектов.
                                                                                                                              0

                                                                                                                              То, что абстракция "берется из" реальных объектов, не означает, что каждой абстракции можно сопоставить реальный (физический, материальный) объект.

                                                                                                                                –1
                                                                                                                                По моему, каждой абстракции можно сопоставить физический объект, посредством производных объектов.
                                                                                                                                  0
                                                                                                                                  Хотя, если Бог создал все, тогда да — не каждой.
                                                                                                                                    0

                                                                                                                                    Я боюсь, у вас свое понимание слова "сопоставить".


                                                                                                                                    Рассмотрим, значит, такую милую абстракцию как период (такая наименьшая музыкальная форма). Какой физический объект вы ей сопоставите? Или, что веселее, возьмем саму абстракцию музыкальной формы — какой физический объект ей соответствует?

                                                                                                                                      0
                                                                                                                                      Во первых, я не знаю, что такое музыкальный период и музыкальная форма.
                                                                                                                                      Во вторых,
                                                                                                                                      Музыкальная форма… многозначный музыкальный термин...
                                                                                                                                        0

                                                                                                                                        Хорошо, а что такое предложение в русском языке — вы знаете?


                                                                                                                                        (кстати, а чему мешает многозначность термина?)

                                                                                                                                          –1
                                                                                                                                          кстати, а чему мешает многозначность термина?

                                                                                                                                          А вы сами попробуйте сопоставить 3 значения (описанные в первом абзаце этой статьи на википедии) между собой. Несмотря на то, что все они относятся к музыке, сходств у них гораздо меньше чем различий, особенно если первое или второе сопоставлять с третьим.

                                                                                                                                          Если вы мне пытаетесь доказать или объяснить, что мое мнение ошибочно, то вы это делаете не тем способом. Я — это частный случай.

                                                                                                                                          Я боюсь, у вас свое понимание слова «сопоставить».

                                                                                                                                          Провести параллели, найти сходства и различия.
                                                                                                                                            0
                                                                                                                                            А вы сами попробуйте сопоставить 3 значения (описанные в первом абзаце этой статьи на википедии) между собой. Несмотря на то, что все они относятся к музыке, сходств у них гораздо меньше чем различий, особенно если первое или второе сопоставлять с третьим.

                                                                                                                                            Тем не менее первые два из них (третье нас не очень интересует, потому что это дисциплина, и полное ее название выглядит не так. Впрочем, дисциплина, не являясь абстракцией, тоже не является физическим объектом.) оба являются абстракцией (разной абстракцией, но не суть). Поэтому они с равным успехом могут служить иллюстрацией моего тезиса.


                                                                                                                                            Провести параллели, найти сходства и различия.

                                                                                                                                            Так вот, во фразе EvilBlueBeaver "Математика вообще по своей сути набор различных абстракций, причем далеко не всем из них удается сопоставить реальные объекты" и в моей фразе "[не] каждой абстракции можно сопоставить реальный (физический, материальный) объект" используется другое понимание этого слова, а именно "провести однозначное двунаправленное соответствие".

                                                                                                                                              0

                                                                                                                                              А вы тут когда обсуждаете сопоставление абстракциям реального объекта, то что под этим подразумеваете вообще? Что можно, формально, построить какую-то функцию из множества абстракций в множество конкретных объектов? Ну, кажется, можно, буду сопоставлять интегралам яблоки, а топологическим пространствам — велосипеды, например. Или это должна быть не любая функция, а какая-то особенная?

                                                                                                                                                0
                                                                                                                                                Или это должна быть не любая функция, а какая-то особенная?

                                                                                                                                                "Какая-то особенная". Я не знаю формального названия таких функций, но, если вкратце, это должна быть пара функций f1: A -> C и f2: C -> A (где C — это конкретные объекты, A — это абстракции), такая, что f2(f1(x)) = x и f1(f2(y)) = y.

                                                                                                                                                  0

                                                                                                                                                  Ну вот я там просопоставлял интегралам груши и все такое. Устроит вас такое отображение? Если нет, то чем?


                                                                                                                                                  Если я правильно понимаю термин, то не полностью: для биекции необходимо, чтобы множества были равномощными, нам же достаточно, чтобы взаимно однозначное отображение было для каждого элемента из множества абстракций (точнее говоря, я утверждаю, что такого отображения нет)

                                                                                                                                                  Это называется "иньективное отображение", ака "вложение".

                                                                                                                                                    0
                                                                                                                                                    Ну вот я там просопоставлял интегралам груши и все такое. Устроит вас такое отображение? Если нет, то чем?

                                                                                                                                                    Тем, что эта функция не будет выполняться для всего множества интегралов (множество интегралов — оно вообще счетное?); таким образом, будут абстракции (интегралы), не сопоставленные с реальными объектами (грушами), а это именно то, что мы пытались доказать.

                                                                                                                                                      0
                                                                                                                                                      Тем, что эта функция не будет выполняться для всего множества интегралов (множество интегралов — оно вообще счетное?); таким образом, будут абстракции (интегралы), не сопоставленные с реальными объектами (грушами), а это именно то, что мы пытались доказать.

                                                                                                                                                      Ну давайте возьмем не только реальные груши, но еще и те, которые я в принципе могу вырастить. В рамках обсуждения это вполне достаточная "реальность", мне кажется.

                                                                                                                                                        0
                                                                                                                                                        Ну давайте возьмем не только реальные груши, но еще и те, которые я в принципе могу вырастить.

                                                                                                                                                        Я подозреваю, что мощность этого множества все равно будет меньше мощности множества интегралов. Но не суть, впрочем.


                                                                                                                                                        Давайте лучше учтем тот факт, что в множестве абстракций еще есть абстракция "фрукт", которую мы (точнее, я) тоже сопоставили с грушей. Теперь функция из пространства реальных объектов в пространство абстракций имеет два значения.

                                                                                                                                                          0
                                                                                                                                                          множество интегралов — оно вообще счетное?

                                                                                                                                                          Смотря каких. Неопределённых над полиномами — |A × B|, где A — множество коэффициентов, скорее всего, равное R и потому континуальное в вашей теории, B — множество степеней в полиноме, обычно счётное, итого континуум.

                                                                                                                                                          Определённых, впрочем, тоже континуум.

                                                                                                                                                          С другой стороны, про груши — интересный философский вопрос. Множество генотипов максимум счётно, но на фенотип, наверное, влияет окружение, осадки там всякие, количество солнца, и считать это счётным или континуальным множеством параметров — хрен его знает.
                                                                                                                                                            0
                                                                                                                                                            С другой стороны, про груши — интересный философский вопрос. Множество генотипов максимум счётно, но на фенотип, наверное, влияет окружение, осадки там всякие, количество солнца, и считать это счётным или континуальным множеством параметров — хрен его знает.

                                                                                                                                                            Вы сейчас считаете варианты груш (не важно, генотипы или фенотипы), а считать надо экземпляры (т.е., конкретные груши, которые можно подержать в руках).

                                                                                                                                                              0
                                                                                                                                                              Что значит «можно подержать в руках»? В некоторых интерпретациях это вообще конечное множество, потому что жизнь слишком коротка для всех груш.
                                                                                                                                                                0

                                                                                                                                                                Так я ровно на эту конечность и намекаю.

                                                                                                                                                                  0
                                                                                                                                                                  Ну так все интегралы вы тоже не возьмёте.
                                                                                                                                                                    0

                                                                                                                                                                    В этом выгодное отличие абстракции от физического объекта.

                                                                                                                                                            0
                                                                                                                                                            > Давайте лучше учтем тот факт, что в множестве абстракций еще есть абстракция «фрукт», которую мы (точнее, я) тоже сопоставили с грушей.

                                                                                                                                                            Ну а я ее с грушей не сопоставлял. Я ее сопоставил с вон тем воздушным шариком, так что все в порядке.

                                                                                                                                                            > (т.е., конкретные груши, которые можно подержать в руках)

                                                                                                                                                            Ну допустим размер груш непрерывно меняется от Х (самая маленькая груша), до Y (самая большая). Значит, по вариации этого параметра, множество груш, которые в принципе можно вырастить и подержать в руках — вполне континуально.

                                                                                                                                                            Но вас тут смущает именно проблема мощностей, а не то, что интегралам сопоставляются велосипеды, грушам — воздушные шарики и т.д.?
                                                                                                                                                              0
                                                                                                                                                              Я ее сопоставил с вон тем воздушным шариком, так что все в порядке.

                                                                                                                                                              Не, не в порядке: с воздушными шариками уже сопоставлено нормальное распределение.


                                                                                                                                                              (вообще, мощность множества абстракций выглядит больше множества реальных вещей)


                                                                                                                                                              Но вас тут смущает именно проблема мощностей, а не то, чт