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



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

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

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

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

И вот в таком кураже последние 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-е годы такой подход был принят за основной стандарт, то мы бы не испытывали сейчас столько негатива и растерянности с существующим зоопарком языков и подходов.

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

Вы можете помочь и перевести немного средств на развитие сайта



Комментарии (236):

  1. vilgeforce
    /#10751878 / +3

    «Всё в окружающем мире состоит из мельчайших неделимых химических элементов» — как-то, мягко говоря, несовременно. Вам не кажется?

    • Moriline
      /#10751944 / -1

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

      • vilgeforce
        /#10751960 / +2

        А взаимодействие химических элементов, получается, изучено хорошо и до конца?

        • Moriline
          /#10751970 / -1

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

          • vilgeforce
            /#10751976 / +1

            Вы уже закрыли проекты типа Folding@home за ненадобностью? Нет — почитайте что-нибудь про современную химию. Насколько я помню, даже в неорганике находят что-то новое. Успехов в самообразовании.

            • Moriline
              /#10751994 / -2

              Даю ссылку. Каким образом проект распред. вычислений относится к химии? Ну кроме моделирования и предсказания какой-то теории? Вот и докажите в отдельной статье в чём я не прав. Приведите свои доводы и доказательства своих слов. Расскажите в статье КАКИЕ новые законы, теории и типы или виды реакций были открыты в химии? А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.

              • picul
                /#10752040 / +2

                А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.
                А Ваша статья такие высказывания не напоминает?

              • vilgeforce
                /#10752096

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

  2. oam2oam
    /#10751958

    Когда приходится рассматривать ООП, то есть два подхода — в одном ОБЪЕКТ это именно что род переменной или константы, а одинаковые в чем-то типы объединяются в КЛАССы (этот подход характерен для таких языков, как Ада и Haskell). В другом подходе ОБЪЕКТ считается экземпляром максимально абстрактного типа (вообщем-то явно не упоминаемого сами знаете кого) — это С++ и Ява (в ней вообще есть только один корневой класс Object). Но ведь на самом деле программиста уместно рассматривать как человека, который на специализированном языке описывает предметную область (литературное программирование), а вовсе не создающего объектную картину мира — ведь в начале было слово это мы же говорим «текст программы»… А вот дальше все пошло как-то не так — действительно, если вы читали первую большую книгу Страуструпа, то наверно, вас тоже вдохновлял пример окон или матриц и операций с ними — но в том-то и дело, что методы и операции не являются (как это обычно изображают, помещая их внутрь класса) элементами объекта! Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю… И так практически постоянно — да, удобно определять операции над объектом как объектные операции, но это-то и вводит в заблуждение — мне кажется, тут лежат истоки разрастания кода и появления ошибок. В то же время создание исчерпывающей системы типов, описывающей предметную область, вводит род языка, на котором задача легче формулируется и решается (если посмотреть на Пролог — то решается автоматически, нужно лишь точно сформулировать ее).

    • Moriline
      /#10751968 / -2

      Спасибо за хороший и объемный комментарий! Программист программирует и воспроизводит предметную область (а для этого ему нужно её описать — и это важно!), реализует алгоритмы её поведения с внешними объектами и между собой. Сама по себе предметная область и должна начинаться именно с мельчайших частиц, которые имеют своё поведение и других объектов, которые производят действия над другими объектами и далее вверх. Так если брать за основу какой-то промежуточный объект — то вниз мы спуститься сможем с большим трудом и (в нашем случае химия) предметная область лишится реализации и воспроизведения. Страуструпа я не читал к сожелению. Дождитесь 2 части — там будет код на Java и я думаю что смогу показать и доказать как это реализуется на практике.

      • akryukov
        /#10752106 / +1

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

        • Moriline
          /#10752160

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

    • CrazyFizik
      /#10752334

      а вовсе не создающего объектную картину мира

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

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

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

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

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

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

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

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

      Вы наверное фанат декларативного программирования :-) Угадал? :-)

      • oam2oam
        /#10753736

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

        • CrazyFizik
          /#10754746

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


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


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


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


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


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

        • CrazyFizik
          /#10754758

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


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

          • oam2oam
            /#10754832

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

  3. scoffer-by
    /#10751962 / -3

    Восхитительно! Благоговейно снимаю шляпу. Но местная фауна сейчас вас порвет в клочья, как Тузик грелку.

    • Moriline
      /#10752064 / -1

      Спасибо за комментарий! Уже пытается рвать. Им то ли скучно, то ли поняли что можно нести всякий бред и не отвечать за это. А о доказательствах своих высказываний даже не задумываются. Печально такое читать…

      • scoffer-by
        /#10752090 / +1

        А вы сомневались, публикуя такое. Это все-равно, что в мечети заявить, что аллаха нет. Жуткая ересь.

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

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

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

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

        • Moriline
          /#10752110 / -1

          Согласен. Жуть просто. Некоторые личности даже не понимают что такое факты и что нужно доказывать, а что нет. Похоже я не раскрыл тему плоской Земли и розовых единорогов о которых так любит высказывать своё никому не нужное мнение здешняя публика( не вся конечно!). Мало иметь ум в голове — надо ещё уметь им правильно пользоваться. А то по-набирают по объявлению программистов и мучайся потом с ними.

          • picul
            /#10752118 / -1

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

          • Zam_dev
            /#10752414

            Мне одному кажется, что если вы со scoffer-by (еще?) не знакомы (лично), то непременно следует это сделать

  4. lair
    /#10751998 / +5

    И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.

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


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

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


    Факты

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


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


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

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


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

    • Moriline
      /#10752012 / -3

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

      • picul
        /#10752036 / +3

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

      • akryukov
        /#10752112

        «А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод.

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

      • lair
        /#10752144 / +1

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

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


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


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

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


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

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


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

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


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

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

        • Moriline
          /#10752186 / -1

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

          • lair
            /#10752198

            Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!

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


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

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


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

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


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

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


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

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

            • Moriline
              /#10752290

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

              • lair
                /#10752292

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

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


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

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

                • Moriline
                  /#10752320

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

                  • lair
                    /#10752328

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

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


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


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


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

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


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

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


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

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

                  • lair
                    /#10752344

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

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

                  • 0xd34df00d
                    /#10752464

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

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

              • lair
                /#10752308

                Потому что моё определение может ответить на ВСЕ вопросы о языке

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

                • Moriline
                  /#10752336

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

                  • lair
                    /#10752340

                    Я не давал определения языка

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


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

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


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

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

      • geher
        /#10752174 / +1

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

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

        • Moriline
          /#10752196

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

          • lair
            /#10752202

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

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

            • Moriline
              /#10752270

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

              • lair
                /#10752274

                Только какая от этого эффективность в решении задач?

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

          • geher
            /#10753062

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

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


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

        • CrazyFizik
          /#10752384

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

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

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

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

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

          • geher
            /#10753094

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

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


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

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

            • CrazyFizik
              /#10754774

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


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

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

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

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

              • Druu
                /#10754872

                > Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать.

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

      • 0xd34df00d
        /#10752462

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

        Какая математика истинная, с аксиомой выбора или без неё?

        • Moriline
          /#10752584

          Спасибо за комментарий. Раскройте Ваш вопрос более полнее и точнее. А то Ваш вопрос вызывает больше вопросов, чем ответ на него.

          • 0xd34df00d
            /#10752606

            Я, если честно, даже не знаю, как его как-то полнее раскрыть.

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

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

            • Moriline
              /#10752680

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

              • 0xd34df00d
                /#10754236

                А что учёные говорят по этому поводу?

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

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

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

                • Moriline
                  /#10754292

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

                  • 0xd34df00d
                    /#10754316 / +1

                    Это вы, видимо, на другой мой комментарий про фазовое пространство, ну да ладно.

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

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

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

    • CrazyFizik
      /#10752364

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


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

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

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

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

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

      • lair
        /#10752372

        А зачем их собственно много?

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


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

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

        • CrazyFizik
          /#10752412

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

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

          Любишь металл: 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++ с примерно одинаковой эффективностью (средняя температура по больнице).

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

          • lair
            /#10752420

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


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

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

            • Zam_dev
              /#10752432

              Основная мысль автора понятна, с точки зрения точных наук — истина одна… но в искусстве нет точности. Кажись, ЯП где то между ними)

              • Moriline
                /#10752442

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

                • Zam_dev
                  /#10752444

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

                  • Moriline
                    /#10752594

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

                • Zam_dev
                  /#10752456

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


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

                • 0xd34df00d
                  /#10752472

                  Так математика и есть искусство.

            • CrazyFizik
              /#10752434

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

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

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

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

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

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

              • lair
                /#10753080

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

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

          • 0xd34df00d
            /#10752470

            Хочешь безопасно: Жаба или 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 и медленные, возвращаемся в самое начало, берем всякие бусты и лаппаки, и…

            Пойду символьные вычисления на лапаках делать, ага.

            • Druu
              /#10752476

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

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

              • 0xd34df00d
                /#10752560

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

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

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

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

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

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

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

                Там ещё можно забавные параллели с квантором существования и прочими Карри-Говардами привести.

                • 0xd34df00d
                  /#10752600

                  Поигрался ещё, можно, например, слить вместе два списка, сохраняя информацию о типах, чего вы никогда не сделаете на экзистеншионалах в хаскель-стиле:

                  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)
                  


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

                  Забавно, надо ещё поиграться.

                  • CrazyFizik
                    /#10754784

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

                    Тыц!

                    • 0xd34df00d
                      /#10754788

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

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

                • Druu
                  /#10754884

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

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

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

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

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

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

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

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

            • CrazyFizik
              /#10754780

              Вы как-то сильно рефлексируйте. Не надо так.
              image

              • 0xd34df00d
                /#10754790

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

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

      • lair
        /#10752374

        А зачем их собственно много?

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

        • CrazyFizik
          /#10752426

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

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

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

          • Moriline
            /#10752438

            Браво! Отличный комментарий! Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии. Взять хотя бы SQL с его стандартами — ну разве не красота? Правда каждая реализация норовит его расширить, но стараются держаться в разумных пределах. Примерно так и должно быть с остальными языками. Должен быть стандарт.

            • lair
              /#10753086

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

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


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

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

      • Moriline
        /#10752392

        Спасибо за подробные комментарии! Ваша помощь очень пригодилась! Напишите еще свои мысли или замечания к статье, если они у Вас есть.

      • 0xd34df00d
        /#10752466

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

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

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

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

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

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

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

        • CrazyFizik
          /#10754778

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

          Не вижу логической связи между моим сообщением и Вашими комментариями.
          Что общего между карандашом и ботинком? :-)

          • 0xd34df00d
            /#10754792

            Обычно предложения, построенные по структуре «A имеет B — C», где A — некоторый объект, B — его свойство, C — наблюдаемый факт, имеют один из двух смыслов: либо C обосновывает B, либо B постулируется, а C описывается как следствие. Я говорил о первой интерпретации, но можно обсудить и вторую, конечно же.

  5. smallplushbear
    /#10752016

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

    • Moriline
      /#10752024

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

      • smallplushbear
        /#10752052

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

        • Moriline
          /#10752068

          Именно это я в статье и говорю. Да, нужна точка отчёта. Я пытаюсь. Но ведь кто-то тоже должен сделать попытку. Почему не Вы?

  6. picul
    /#10752028 / +1

    Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании? Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей. А вот Ваши «доказательства» и «объяснения» — они то и не нужны никому от слова «совсем».

    В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
    Интересно, откуда такие цифры?
    Факты:
    Относятся к реальному миру, а не к программированию.
    несколько принципов:
    Похожи на смесь Coding Style Guide и какого-то очередного шаблона проектирования, которые вы так ненавидите.
    Гипотеза:
    Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.

    P. S. Почему в качестве ЯП для «доказательства гипотезы» выбрана Java? Она ведь полностью объектно-ориентирована, а судя по Вашей статье, хуже ООП может быть только ФП)

    • Moriline
      /#10752048

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

      • picul
        /#10752100

        1. Можете пожалуйста конкретно указать статью? Ссылок очень много, и в основном это просто холиварные статьи.
        2. Задача языка — предоставить удобный программисту инструментарий для решения задач. «Доказательства» и «объяснения» на каждом шагу — это не очень удобно.
        3. Так если истина едина, зачем целых 6 языков?)
        4. Программирование занимается симуляцией процессов в окружающей среде, потому что просчитывать каждый атом во Вселенной Вам никаких машин не хватит. И я нахожусь не в истории, а в реальности, и задачи решаю соответствующие. А про программирование до нашей эры ИМХО Вы написали не на тот ресурс.
        5. Это все, что Вам удалось родить после простыни про научный подход и оскорбления признанных ученых?

  7. Mikluho
    /#10752140

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

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

    ps
    Истина одна, но она никому не нужна, потому правд много и именно ими пользуются живые люди. Почему так — почитайте философов…

  8. Moriline
    /#10752146 / -1

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

    • vdasus
      /#10752204

      :: язык не решает задач! Задачи решает алгоритм
      Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам. Как-то: развитой инструментарий, широкий набор готовых библиотек или компонентов (что тоже, де-факто, входит в понятие языка в моей терминологии), наличию разработчиков,…

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

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

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

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

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

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

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

      • Moriline
        /#10752238

        Спасибо за развёрнутый комментарий.
        Как я и писал в статье — проблема в том что программисты спорят основываясь уже на реализации, а не на теории и науке. В этом большая разница! Грубо говоря в ЯП сейчас тихий ужас из-за описанной мною истории их создания. Если Вы начнёте мыслить с точки зрения основ программирования, его истории, задач и целей и каким образом именно наука, а не религия дало всё то, что нас сейчас окружает и какие подходы использовала, то признаете что рациональное зерно в этой статье всё таки есть. А лучше всего прочитать статью внимательно, походить по ссылкам, книгу почитать и комментарии мои и вдуматься в сказанное. Сделать это — большая и трудная работа, но она необходима. А терпением для этого мало кто может похвастаться.
        1. «Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам.» — написано в этом комментарии.
        2. «Хотите я вам покажу большой объект, который будет легко понимать и читать.» — Ответ действительно очевиден. «Если сильно захотеть — можно в космос полететь!». Только вот в науке и реальном мире сложное, по определению, не может быть проще простого.

    • picul
      /#10752294 / +1

      1. Читать кучу статей с заявлениями «все фигня, давай по новой, но я не знаю как» — да, лень. А Вам лень предоставить конкретный материал, который является подкреплением Вашей точки зрения?
      2. Как Вы хотите, что бы кто-то понял Вашу точку зрения, если сами не способны понять чужую? Язык предоставляет средства для решения задачи — это значит, что он предоставляет семантические конструкции, которыми программист может выразить свои мысли. В императивном программировании это разные инструкции, которые со временем оформили в процедуры, которые со временем объединили с данными и назвали классами. В функциональном это функции, которые не используют каких-то состояний, а выдают результирующие значения только на основе своих аргументов. ( Примеры поверхностные, но, надеюсь, Вы понимаете, о чем я. ) Задача языка — сделать так, что бы программисту было удобно пользоваться этими средствами, которые язык предоставляет, а также что-бы эта легкость использования не повлияла на качество программы, которая на языке будет написана. Соответствие каким-то наукам — это очень второстепенная задача.
      3. Это лучшая научная аргументация, которую Вы можете предоставить?
      4. А, так значит «научный подход» — это выбросить компьютеры и работать на изобретениях 19-ого века? Или нет? Просто Вы так и не объяснили.
      5. Например

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

  9. ijsgaus
    /#10752192

    Я согласен с коллегой, то что сейчас происходит с ООП семейством языков — это медленный конец. Но Ваше восприятие парадигм — напрягает. Дело в том, что все ошибки ООП языков, о которых вы пишите, совершенно не связаны с МАТЕМАТИЧЕСКИМ ОТСУТСТВИЕМ теории. К сожалению, это действительно личные предпочтения их авторов. Но и ваш концепт, к сожалению, на мой взгляд, неполноценен, как раз из за полного отсутсвия мат теории. Все же идеи забытого и спрятанного Хаскеля, много лет шедшего рядом, но по другому, с ВЕЛИКОЛЕПНОЙ математикой и доказательностью — хороший пример именно основательного научного труда, на который нужно и следует опираться. И прежде всего на теорию категорий.

    • Moriline
      /#10752218

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

      • 0xd34df00d
        /#10752548

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

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

        • Moriline
          /#10752616

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

          • 0xd34df00d
            /#10754242

            Значит, я не так понял ваш предыдущий комментарий, увы.

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

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

            В конце концов, термин «фазовое пространство» вам что-нибудь говорит?

  10. geher
    /#10752194

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

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


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

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


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

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

    • Moriline
      /#10752208

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

      • geher
        /#10753314

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

        • CrazyFizik
          /#10754796

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


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

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

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

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

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

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

    • Deosis
      /#10752822

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

      • geher
        /#10753426

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

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


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

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


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

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

  11. visirok
    /#10752212

    Так вышло, что я немного знаю автора лично. Сначала он с поразительной быстротой подготавливал и публиковал обьёмные куски кода в комментариях к одной из моей статей. А в другой статье заметил пару досадных опечаток и через личку написал мне о них. Я был инициатором разгора. Разговор получился долгим, интересным и полным острых дискуссий.
    Это я пишу к тому, чтобы заверить читателей в том, что автор осень крепкий профессионал с большим опытом работы в разного типа проектов.
    Как я понимаю, там то и накопилась у него та боль, которую он выплеснул в этой статье.
    Тем не менее, Уважаемые Критики и Уважаемый Автор, давайте стараться уважать мнение друг-друга, даже если мы с ним и не согласны.
    Я тоже не согласен с многими тезисами автора. К сожалению, на Хабре отсутствует возможность «расщепить» статью на отдельные тезисы и структурно обсуждать их по-отдельности. (А кстати, кто-нибудь знает что-нибудь подобное на других форумных площадках?). Поэтому я свои комментарии к отдельным тезисам буду делать в виде отдельных комментариев.

    • rg_software
      /#10752646 / +1

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

      • visirok
        /#10752848

        Я не знаю состав команды автора.
        Но я Вас понимаю. К сожалению, автор в своём стиле общения не одинок. Это какая-то печалящая меня мода последних лет.
        Я, например, знаю хорошо одного коллегу, с высоким уровнем культуры и интересного собеседника, который почему-то считает, что это здорово писать Email в лексике пятикласника с добавлением профессиональных терминов.
        Ещё я раньше слушал подкаст Радио-Т. Ведущим не отнять профессионализма, да и темы интересные. Но я понял, что хамская манера разговора, пренебрежительные оценки чужих мнений и достижений, нецензурная лексика — это не моё. И перестал их слушать.
        Боюсь, что автор потерял не только Вас в качестве комментатора.

  12. Inobelar
    /#10752246

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

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

    • Moriline
      /#10752250

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

    • geher
      /#10753504

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

  13. SedovDP
    /#10752254 / +1

    Думаю, вы слишком буквально понимаете термины «объект» и «наследование».

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

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

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

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

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

    • Moriline
      /#10752266

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

      • lair
        /#10752268

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

        • Moriline
          /#10752300

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

          • lair
            /#10752304

            А объект — это всегда физ. сущность.

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


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

            • Moriline
              /#10752356

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

              • Moriline
                /#10752358

                АВМ — тоже нематериальная сущность? И перфокарта тоже? Учите историю.

                • lair
                  /#10752362

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

              • lair
                /#10752360

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

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


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

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


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

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


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

                • Moriline
                  /#10752380

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

                  • lair
                    /#10752390

                    У меня научное и материальное определение объекта

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


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

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


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

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


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

                    Нет, программирование сводится к созданию компьютерной программы (я не хочу сейчас вдаваться в развернутый спор "программирование 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").

          • 0xd34df00d
            /#10752552

            Абстракция — это результат мышления и обобщения после наблюдения за какими-то свойствами реальных объектов и выделения из них существенных определений и признаков.

            Наблюдение за какими реальными объектами и сущностями привело к такой абстракции, как, например, изоморфизм Карри-Говарда? Арифметика кардиналов? Арифметика ординалов?

            • Moriline
              /#10752754

              "" — над числами. Как и вся база математики. Здесь же написано: «Порядковые числа были введены Георгом Кантором в 1883 году как способ описания бесконечных последовательностей, а также классификации множеств, обладающих определенной упорядоченной структурой.[1] Он случайно открыл порядковые числа, работая над задачей, связанной с тригонометрическими рядами. » Основой математики(и геометрии) является число. Все остальные абстракции лишь следствие попыток объяснить окружающий мир. Начиная с круга и треугольника(станет потом геометрией и тригонометрией), множествами и точкой с прямой(которая потом станет декартовой системой координат). Надеюсь понятно объяснил.

              • EvilBlueBeaver
                /#10752898

                У нас числа стали внезапно реальными объектами? Покажите мне, пожалуйста, как выглядит 2 в реальном мире.

                • Moriline
                  /#10753036

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

                  • EvilBlueBeaver
                    /#10753046

                    Число — это абстрактное понятие, а не реальный объект. 2 руки — это 2 руки, а не число 2. Щупая 2 руки вместо одной, вы будете щупать все так же руки, а не число 2.
                    Больше того скажу, в Полинезии существуют народы, которые не знают данной абстракции. У них натурально для каждого существительного есть отдельные слова для разного количества. То есть отдельное слово для одной овцы, отдельное слово для двух овец. Аналогично с деревьями. И они не находят общих признаков у двух овец и двух деревьев.

                    • Moriline
                      /#10753060

                      Там же: «Понятие числа возникло в глубокой древности из практической потребности людей и усложнялось в процессе развития человечества. Область человеческой деятельности расширялась и соответственно, возрастала потребность в количественном описании и исследовании. Сначала понятие числа определялось теми потребностями счёта и измерения, которые возникали в практической деятельности человека, всё более впоследствии усложняясь. Позже число становится основным понятием математики, и потребности этой науки определяют дальнейшее развитие этого понятия.» И дальше можете прочитать. Так что это говорит о народах Полинезии? Другими словами число — это количественная характеристика объектов. Вы как живой объект в количестве 1 штуки существуете и Вас можно посчитать и выразить в виде особого символа, верно?

                      • EvilBlueBeaver
                        /#10753074

                        Еще раз. Есть народы, у которых нет этой абстракции. То есть 2 дерева физически существуют, а числа 2 нет. Да и в вашей же цитате написано, что число — это понятие.
                        Следуя вашей логике слово — это тоже реальный объект, потому что в той или иной форме он существует у всех народов?

                        • Moriline
                          /#10753108

                          «Следуя вашей логике слово — это тоже реальный объект». Нет. Это не реальный объект, только если не воспринимать его как звуковые колебания.

                          • lair
                            /#10753494

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

                  • lair
                    /#10753098

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

                    • PashaNedved
                      /#10753222

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

                      • lair
                        /#10753248 / +1

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

                        • PashaNedved
                          /#10753278 / -1

                          Как же не реальный? Вот я его вижу «два», «2». Я наблюдаю за этим объектом, и если я не сошел с ума, то он реален.

                          • EvilBlueBeaver
                            /#10753322

                            Вы вообще отличаете абстракцию от реального объекта? Для какого-то китайца «два» — это непонятные закорючки, но с понятием 2 он, очевидно, знаком.

                            • PashaNedved
                              /#10753458 / -2

                              Если есть абстракция, то есть и реальный объект. Абстрактных объектов не существует.

                              • EvilBlueBeaver
                                /#10753470

                                Откуда такой замечательный вывод? Математика вообще по своей сути набор различных абстракций, причем далеко не всем из них удается сопоставить реальные объекты. Если вы уйдете чуть дальше арифметики — вы это поймете.

                          • lair
                            /#10753324

                            "Реальный" в значении "материальный". Извините, если ввел вас в заблуждение неточной формулировкой.

                • PashaNedved
                  /#10753204

                  Выглядит точно также, как в вашем комментарии.

                  • EvilBlueBeaver
                    /#10753250 / +1

                    То есть 2 — это кучка пикселей на мониторе? Соответственно на бумаге 2 — это другое 2? А если я скажу 2 вслух — это будет третье?

                    • PashaNedved
                      /#10753282 / -1

                      Наверное, этого будет один и тот же объект.

                      • mayorovp
                        /#10753304 / +1

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

                        • PashaNedved
                          /#10753358

                          Это если их рассматривать, как кучку пикселей и звуковых колебаний. Я же смотрю на это, как на исчисление.

                          • mayorovp
                            /#10753422 / +1

                            Исчисление — это что-то абстрактное. А защищаемый сейчас вами автор статьи, напомню, запретил объектам быть абстрактными.

                            • PashaNedved
                              /#10753528

                              Исчисление — это что-то абстрактное

                              Да, но «2» уже не абстрактное, но обобщенное.
                              Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.

                              • EvilBlueBeaver
                                /#10753550

                                Окей, а число Пи абстрактное? Если нет — покажите его в реальном мире.

                                • PashaNedved
                                  /#10753600 / -1

                                  Куда вас понесло? Число пи — это не тоже самое, что и 3,14…

                                  • EvilBlueBeaver
                                    /#10753610

                                    А что же тогда пи и какой реальный объект по типу «два — это две руки» ему можно сопоставить?

                                    • PashaNedved
                                      /#10753654

                                      От вас одни вопросы, в том числе и провокационные… Давайте теперь я задам вопрос или несколько, почему вы считаете, что «2» не реальный объект?

                                      • EvilBlueBeaver
                                        /#10753690

                                        Потому что все, что вы описывали, не является именно числом 2. Нет физического объекта — который является числом 2.
                                        Если взять пример с двумя руками — тут все очевидно, как были руки, так и остались, отдельного физического объекта 2 не появилось.
                                        Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.

                                        • PashaNedved
                                          /#10753776

                                          Потому что все, что вы описывали, не является именно числом 2.

                                          Но «два» и «2» можно рассматривать как равнозначные?
                                          Нет физического объекта — который является числом 2.
                                          Значит теперь уже физического… а раньше было реального.
                                          Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.
                                          К двум яблокам на столе можно прибавить 3 груши, чтобы получилось 5 фруктов.

                                          • EvilBlueBeaver
                                            /#10753830 / +1

                                            Но «два» и «2» можно рассматривать как равнозначные?

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

                                            Значит теперь уже физического… а раньше было реального.

                                            Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?
                                            И даже если вам не нравится термин «физический», то и реального объекта «2» не появилось, появилась другая рука.

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

                                            Как из 5 фруктов выделить непосредственно физическийреальный объект «5»? Но вообще хорошо, что тут вы сами двигаетесь в сторону абстракции. Если прибавить 2 грузовика к 3 стаканам сока, то 5 чего получится?

                                            • PashaNedved
                                              /#10754180 / -1

                                              Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?

                                              А вы считали, что это синонимы?
                                              Как из 5 фруктов выделить непосредственно физическийреальный объект «5»?

                                              Зачем его выделять?
                                              Если прибавить 2 грузовика к 3 стаканам сока, то 5 чего получится?

                                              5 абсурдов! :)
                                              Есть такой фильм «Роковое число 23», главный герой повсюду наблюдал число 23. Он считал предметы и получалось 23, складывал числа — получалось 23, число 23 было везде.
                                              23 было объектом его воображения. Он абстрагировался от всего конкретного и ему не важно было чего там 23, его волновало только 23.

                                          • SedovDP
                                            /#10754072

                                            А если 2 яблока умножить на 3 груши?
                                            Получится 6 фруктов?

                                            • PashaNedved
                                              /#10754198

                                              Я так не умею! :(
                                              Но ведь не было никаких яблок и груш, вернее они не являлись объектами наблюдения, были только фрукты их мы и складывали.

                                          • 0xd34df00d
                                            /#10754260

                                            А кстати, фрукт — это объект или абстракция?

                                            • PashaNedved
                                              /#10754322

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

                                              • 0xd34df00d
                                                /#10754340

                                                Можно пример ситуации, когда фрукт — конкретный объект? Особенно хотелось бы иметь возможность осязать этот конкретный объект в этой ситуации.

                                                • PashaNedved
                                                  /#10754384

                                                  В чем подкол-то? :) Возьмите с прилавка в супермаркете любой фрукт — вот и конкретный объект.

                                                  • 0xd34df00d
                                                    /#10754402

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

                                                    • PashaNedved
                                                      /#10754408

                                                      Все не так, я выше давал поясняющий комментарий

                                                      Но ведь не было никаких яблок и груш, вернее они не являлись объектами наблюдения, были только фрукты их мы и складывали.

                                                      • 0xd34df00d
                                                        /#10754418

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

                                                        • PashaNedved
                                                          /#10754488

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

                                                          • 0xd34df00d
                                                            /#10754532

                                                            И если вам вместо яблок дадут апельсины, вы не расстроитесь?

                                                            • PashaNedved
                                                              /#10754850

                                                              Смотрите не со стороны покупателя, а со стороны продавца.

                                            • geher
                                              /#10754612

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

                              • lair
                                /#10753574

                                Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.

                                То есть вы тоже считаете, что объект может быть только физической сущностью (и, следовательно, число 2 — не объект)?

                                • PashaNedved
                                  /#10753632 / -1

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

                                  • lair
                                    /#10753636

                                    Я не придерживаюсь ни этого мнения ни противоположного.

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


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

                                    Да нет, это очень простой вопрос, ответ на который уже неоднократно озвучен в разных терминологических системах.

                                    • PashaNedved
                                      /#10753686 / -2

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

                                      Ну значит не совпало. Или совпало… Это не имеет большого значения. Я не пытаюсь защищать автора статьи — это имело значение в том комментарии.

      • SedovDP
        /#10754032

        Упрощенный пример.
        Определим класс: КоммерческаяФирма.
        Создадим экземпляр класса: Фирма (ООО, LTD)
        У объекта Фирма свойства: счет, обороты по счету, учередители, директор, место регистрации, фактический адрес и т. д. И методы: получить деньги, перечислить деньги, отгрузить товар, принять заказы и т. п.
        Объект Фирма может взаимодействовать с другими объектами фирмами, банками, людьми.

        Является ли при этом Фирма физическим объектом?

        • Moriline
          /#10754104 / -1

          Спасибо за комментарий.
          С точки зрения науки и реальности Фирма не является физическим объектом.
          С точки зрения программирования Фирма является объектом.

  14. visirok
    /#10752258

    Немного истории. С чего всё началось? Сначала было ....

    Это очень интересная тема. Существуют обьёмные и очень интересных книги по истории, например, паровозов. В них рассматривается эволюция отдельных блоков, их разновидности и т.д. А вот об отдельных аспектах программирования, например истории баз данных, я не встречал.
    Я лично убеждён, что прогресс популярных языков программирования примерно до 90-х годов определялся в основном развитием теории и практики построения компилчторов. Я думаю также, что С# был первым языком, когда вначале была собрана командв признанных на тот момент специалистов, которые не бросились в спорах писать первый вариант компилятора, а довольно долго подготавливали спецификацию для первой версии языка.
    До сих пор создание совсем новых языков дело ужасно трудоёмкое и определяется базой накопленных знаний и умений.
    Другими словами, при создании языков сначала появлялись технические возможности, а потом для них придумывались красивые интерпретации. Например — фактическое прикрепление функций к стркутурам в С назвали Обьектом. А могли бы назвать Атомом. На эту тему, кстати, есть байка, что закрепившийся в UML термин Актер на самом деле следствие ошибки переводчика со шведского. Эта штука должна называться Роль.

  15. visirok
    /#10752298

    Если абстрагироваться от некоторых спорных тезисов и порой не очень научных формулировок, то в сухом остатке получается, что автор пытается призвать подумать над Универсальным Языком Программирования (УЯП), который будет способен моделировать всё в мире. Но попытка создать Универсальный Язык Моделирования (UML) уже предпринималась. Попытка была весьма серьёзная и привела к серьёзным результатам.
    Может вместо создания нового УЯП стоит подумать как применить UML, например xUML (Executable UML)?

    • lair
      /#10752306

      Если абстрагироваться от [...] не очень научных формулировок

      Это в посте, который призывает к научному подходу? Ну то есть абстрагироваться от самой сути поста?


      автор пытается призвать подумать над Универсальным Языком Программирования (УЯП), который будет способен моделировать всё в мире.

      Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?

      • visirok
        /#10753608

        Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?

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

        • geher
          /#10753628

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

        • lair
          /#10753634

          Моделирование — построение модели.
          Программирование — построение программы (снова, я избегаю спора "программирование vs разработка").


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


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

          • visirok
            /#10753986

            Я думаю, при программировании важно различать три класса моделей:
            1) «Формальную» или «официальную» модель предметной области. Иногда эти модели описаны в книгах, статьях, документах.
            2) «Приватную» модель предметной области в голове программиста. Она отличается от первой модели по многим параметрам. По полноте, структуре и «природе» (из чего состоит). На самом деле про эту модель можно мало что сказать конкретного, кроме того что они субьективно существуют и «кристаллизируются» в процессе написания программы.
            3) Модель программы (или системы) которая может быть формально отражена в докуметации, получена из кода или просто возникает в голове всякого, кто должен программу писать, расширять, тестировать и т.д.

            • lair
              /#10754010

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


              И, главное, какое это имеет отношение к обсуждению?

              • visirok
                /#10754048

                Вы отличались удивительной выдержкой и культурой ведения дискуссии в своих комментариях к этому посту. Не понижайте планку. Я — не доцент. Хотя и не воспринимаю это как обиду :-)
                А к обсуждению это имеет вот какое отношение. Ваша фраза:

                Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?

                А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации? Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?
                Как мне представляется, выплеснутая автором боль и происходит из этой дилемы.

                • lair
                  /#10754058

                  Я — не доцент.

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


                  А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации?

                  Нет. Он должен по возможности хорошо выражать намерения программиста.


                  Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?

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


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

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

                  • visirok
                    /#10754122

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

                    • lair
                      /#10754138

                      Нет, вы неправильно меня поняли.


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


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

                      • visirok
                        /#10754186

                        С моей точки зрения прогресс майнстримовых языков программирования как раз и мотивировался желанием «поднять их уровень» от битов до нынешних Java/C#/Scala/Kotlin и т.д. Мне посчастливилось этот прогресс пережить/перепробовать.
                        Но неудолетворённость нынешним состоянием остаётся. Проблему хочется решать. Делать это можно по-разному.
                        Можно как алхимики пробовать и за счёт эмпирических правил и озарений всё же двигаться вперёд.
                        А можно по-научному. Но и тут без озарений не обойтись, похоже.
                        Научный подход применительно к программированию не должен сильно отличаться от подходов в других областях.

                        • lair
                          /#10754188

                          А можно по-научному.

                          Это как? Конкретно?


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

                          В каких "других областях"? Что такое "научный подход" в пошиве одежды?

                          • visirok
                            /#10754512

                            Что такое «научный подход» в пошиве одежды?

                            Ну например для начала могу подарить Вам и всем дочитавшим до этого места два способа стать миллиордером уже к осени, занимаясь пошивом… дамских джинс.
                            Способ первый. Я не специалист по дамским джинсам, но как я понимаю, сейчас модно показывть голые щиколотки. А до этого было модно показывать самый нижний позвонок. А ещё — коленки сквозь искусственные прорехи.
                            Так вот — научитесь предугадывать, что будет нравиться дамам ближайшей осенью, свяжитесь с производителями и станете миллиардером.
                            Способ второй: Представте себе. Приходит дама в магазин, видит модный фасон джинс. Меряет — меряет, а потом говорит разочарованно продавцу — эти жмут внизу, а эти вверху, потому никакие не куплю. А продавец ей говорит: а Вы зайдите в вон ту кабинку, там Вас сканер отсканирует, а завтра приходите за джинсами. Только это будет стоить дополнительно X процентов.
                            Придумайте технологию — и разбогатеете.
                            Но вряд ли кто-нибудь к осени эти задачи решит. Но решат, я думаю. И непременно с помощью научного подхода.
                            Какие основные шаги:
                            1) точно сформуриловать проблемы/цели
                            2) построить адекватную модель предметной области с релевантными обьектами, релевантными состояниями, взаимосвязями, параметрами воздействия и функциями действия.
                            3) поиск решения на уровне модели и проверка решений на практике.
                            Конкретно по первому сценарию. Что значит физиологически, что джинсы нравятся? Это зависит от времени суток, национальности, культурного уровня, возвраста?
                            Можно функцию «нравится» оцифровать? Можно её интерполировать/экстраполировать?
                            И т.д.
                            Убедил?

                            • lair
                              /#10754614

                              Убедил?

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


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

                              • visirok
                                /#10754664

                                Я не вижу в вашем описании ничего научного.

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

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

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

                                • lair
                                  /#10754688

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

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


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


                                  Начинать-то надо с определения, что такое "научный подход".


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

                                  Это какая-то очень выигрышная лотерея, вы не находите?

                                  • visirok
                                    /#10754918

                                    Но вам это не удалось.

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

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

                                    Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды. Наши программисткие боли — сладкий сон по сравнению с ними.

                                    • lair
                                      /#10754936

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

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


                                      А прогнозирование моды — вы вообще понимаете, что мода создается, а не меняется сама по себе?


                                      Меня устраивает определение из Википедии.

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


                                      Собственно, в программировании тоже есть проблемы с объективностью.


                                      Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды.

                                      Вам "попадалась статья", а я с некоторыми знаком лично (причем как и дизайнерами, так и с теми, кто шьет).

    • Moriline
      /#10752954

      Спасибо за комментарий. Что-то подобное как xUML уже сделали — Дракон. Там есть и схемы и алгоритмы.

      • visirok
        /#10753594

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

  16. pPiter
    /#10752386

    Спасибо!

    • Moriline
      /#10752398

      На здоровье! Пишите подробнее — что понравилось, какие вызвало вопросы, что не понравилось и не логично.

  17. Druu
    /#10752468

    > И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.

    image

    ЗЫ: автор, хотелось бы узнать, ты TaPL (http://newstar.rinet.ru/~goga/tapl/tapl-toc.html) осилил?

  18. pankraty
    /#10752538

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

    Полностью согласен! Взять хотя бы
    В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.

    • Moriline
      /#10752670

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

      • akryukov
        /#10752704

        После ознакомления со стандартами SQL, можно приступить к ознакомлению vendor-specific особенностей каждой конкретной СУБД. Например LIMIT в стандарте отсутствует, т.к. противоречит реляционной теории, но при этом реализован у большинства вендоров.
        В итоге получается, что SQL вроде бы один и тот же, а на самом деле их несколько десятков.

        • Moriline
          /#10752718

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

          • akryukov
            /#10752752

            Можете сами оценить в списке на википедии.
            Если учесть, что СУБД постоянно дорабатываются, то в каждой новой версии появляются новые надстройки. Так можно насчитать уже и сотню-другую диалектов SQL.


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

      • lair
        /#10753102

        Здесь я говорю что в итоге низкоуровневый язык должен быть один(имея ввиду его синтаксис)

        Нет, вы там говорите, что вообще язык должен быть один.

  19. MaxxONE
    /#10752642

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

    • Moriline
      /#10752706

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

      • MaxxONE
        /#10753180 / +1

        У вас нет науки в статье. Есть лишь софистика. Вы предлагаете новую парадигму программирования, основываясь на сомнительных предпосылках.
        Можно было бы взять в качестве исходных фактов другие высказывания, звучащие столь же научно, и плясать уже от них, с иными результатами. Все эти факты из химии и физики (сильно упрощенные, и к тому же верные лишь отчасти) — на каком основании именно их вы приняли за постулаты своей теории? Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?
        Далее, от исходных данных вы сразу же перешли к положениям своей теории. Как вы пришли к этим выводам? Вот вы пишете:

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

        — где этот анализ, где вот это всё? Я из тех же самых положений за день могу родить с десяток столь же блестящих подходов к программированию. И, к сожалению, столь же сомнительных.
        Наука — это не то, что звучит научно. Это не аргументация фразами из учебника. Это не то, что у вас в статье написано — у вас пример псевдонаучной статьи. У меня, честно говоря, возникают ассоциации с творчеством разных фриков — от физики/химии/etc.
        Я вижу, что вы нормально относитесь к критике. Или пытаетесь, по крайней мере. Я бы хотел дать вам конструктива. Но трудно в рамках комментариев всё расписать, поэтому я ограничусь одним советом: почитайте о настоящей науке. Почитайте Фейнмана. Прочтите Гарри Поттер и методы рационального мышления — вот эту книгу я настоятельно рекомендую. Прочтите, хотя бы последнюю, до того, как писать следующую публикацию. Это все, что я могу вам сказать, не ввязываясь в полемику.

        • Moriline
          /#10753996

          Спасибо за комментарий. Дайте ответ на один лишь вопрос:
          1. «Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?»
          Разве физика и химия не описывают вселенную?

          • MaxxONE
            /#10754250 / +1

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

            • Moriline
              /#10754280

              Большое спасибо! Значит я плохо написал статью и недостаточно точно и понятно выразил свои мысли и сделал несколько ошибок и недочётов, не указал причинно-следственные связи между фактами и утверждениями и конечным выводом.

              • MaxxONE
                /#10754300

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

  20. akryukov
    /#10752710

    Любопытно наблюдать, что статей "Умные мысли, часть 1" на хабре сильно больше, чем статей "Умные мысли, часть 2". Причем в комментариях к статье 1 автор довольно часто обещает развернуть свои мысли в статье №2 или даже написать целый цикл статей.

  21. Deosis
    /#10752782

    Довольно странное впечатление от статьи.


    • Вы ссылаетесь на математику, физику и химию как на пример точных наук. Но при этом не учитываете, что даже там были ошибочные теории.
      Например, теория о теплороде в физике.
      Или механика Ньютона, которой до сих пор пользуются, хотя она немного "не точна".
    • Наука в большинстве своем занимается предсказаниями: при заданных начальных условиях будет определенный результат.
      Ваши же предположения очень спорны.
      1. Исключение абстракций, наоборот, может увеличить размер кода. Потому что, если у вас 10 типов объектов, то вам понадобится 10 типов списков конкретных объектов. Для каждого типа списка объектов придется писать почти одинаковый код.
      2. Антипаттерны вредны вообще, но на размер кода они влияют слабо. Сервис-локатор убирает много кода для предоставления зависимости там, где она нужна.
      3. Язык APL, на нем программы могут быть ощутимо короче, но понятнее от этого они не становятся.
    • В принципах собраны как требования к языку, так и к стилю написания программ.
      Последний особенно противоречив. Если ваш воображаемый язык заставит следовать этому принципу, то как вы будете разрешать конфликт, в котором у меня все работает, а у коллеги не запускается/компилируется, только потому, что у меня монитор стоит вертикально?

    • Moriline
      /#10752874

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

  22. klvov
    /#10752878

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

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

    Ну а на практике, мне кажется, постепенно будет все двигаться в сторону языково-ориентированного программирования, то есть конструирования DSL под конкретную область, и дальше оно там может прижиться, как SQL, или там постепенно приживаться (как XML, который потом довольно скоро переизобрели как JSON).

    • 0xd34df00d
      /#10754290

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

      Почему? См. теория типов.

  23. HomunCulus
    /#10752926 / +1

    Эффект Даннинга-Крюгера во всей красе помноженный на хамство. Автор смешал все в кучу, декларативное с императивным. На любые вопросы, тыкает прочитайте определение. Схоластика в 21 веке. При чем о философии науки даже и не слышал :) про математику, абстракции, языки программирования и прочее даже говорить не хочется. Хочется развидеть.

    Что правильнее Лямбда исчисление Черча, машины Тьюринга, или вообще циклические теги? Очень мило, если бы не хамство, выглядели попытки натянуть математические концепты на «химические элементы»

    горшочек не вари.

    lurkmore.net/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%9E%D0%A1

    является совокупностью бредово-казённо-абсурдных высказываний наподобие:

    Процессор Пентиум — это логическое устройство. Любое действие процессора определяется логикой этого процесса.

    Горлов А. В.


    vs.
    Факты:

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

  24. Vlad_fox
    /#10753342

    статье место не в «песочнице», а в «спам» или «прокрастинация». Нечего таком у взрослому и состоявшемуся ноучному автору делать в песочнице.

  25. oam2oam
    /#10753778

    Мне после прочтения всех комментариев (и своих тоже :) пришло в голову простое соображение — как же так получилось, что языки программирования строго научные есть, а автор искренне считает (и видимо с ним все согласны), что их нет. Ну то есть я так полагаю (возможно и неправильно), что научное программирование опирается на какую-либо научную теорию. Так вот — язык пролог опирается на метод резолюций, а язык Gallina (COQ) на исчисление высказываний и позволяет синтезировать программы (ага, на ocaml!) прямо из построенного доказательства…

    • Moriline
      /#10753966

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

      • oam2oam
        /#10754176

        ну уж Gallina — то точно является способом записи научной теории и даже выбрана в качестве инструмента для записи новой теории всего математики! Что же касается пролога — это никак не метод доказательства теорем, а вполне живой и развивающийся язык программирования (да, да, с веб-сервером и блек-джеком, графическим интерфесом и многим другим ...). Но тут я не могу сказать, что вы понимаете под научной теорией? Является ли булева алгебра таковой? Или исчисления высказываний недостаточно? Или… в общем, тут я ничего не могу сказать, пока мы не выясним, что такое научная теория и чем она отличается от ненаучной или от не теории…

        • Moriline
          /#10754264

          «Что же касается пролога — это никак не метод доказательства теорем, а вполне живой и развивающийся язык программирования» — я не за пролог говорил, а за метод на котором он основан. Вот цитата: «Язык пролог действительно опирается на этот метод. Но что из себя этот метод представляет?» Научная теория — это система понятий, законов и принципов, наиболее полно описывающая структуру предмета исследования.(ссылка, структура и функции теории). Булева алгебра не теория. Это скорее набор аксиом и операций применяемый ко множествам. а псевдонаука — это имитация под науку с целью её опорочить и выдать желаемое за действительное.

  26. Moriline
    /#10754118 / -1

    Особо впечатлительным и ранимым людям это лучше не смотреть и не читать: What's Wrong With Object-Oriented Programming? и Объектно ориентированное программирование в 2018

    • picul
      /#10754514 / +1

      Как эти материалы подкрепляют Вашу, до конца не выраженную, точку зрения?

  27. samsergey
    /#10754510 / +1

    Очень странное обсуждение! Целая статья о "научном программировании", 200 комментариев, жаркие споры и ни разу не прозвучали волшебные слова: "денотационная семантика", "аксиоматическая семантика", "изоморфизм Карри-Говарда", "формальная верификация". Зато есть "ООП", "ФП", "хочешь странного: Хаскель и всякие F#"… Неужели никому в этой дискуссии не интересно именно научное программирование, а не ваяние формочек?

    • picul
      /#10754522

      Интересно, вот только после всех 200 комментариев лично я так и не нашел определения «научного программирования».

    • 0xd34df00d
      /#10754536 / +1

      Ну, вообще-то некоторые из этих слов вполне себе звучали. Равно как и возражения на тему процитированного вами высказывания о «странном».

      • samsergey
        /#10754712 / +1

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

        • 0xd34df00d
          /#10754718

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

    • Druu
      /#10754892

      Дискурс же задается обсуждаемой статьей. А автор статьи не в курсе про эти ваши семантики с прости хоспаде изамарфизмами.

  28. netch80
    /#10754576 / +1

    Вот начал это писать ещё утром, потом убежал на работу… думаю, повторю процентов 90 уже написанного.

    > Сначала идет теория, а за ней практика.

    Это только в варианте рассмотрения через школьные учебники о том, что было 2000 лет назад, кажется, что «сначала идёт теория». Сначала таки шла практика, потом на неё «натягивалась» (в почти прямом смысле) теория, и именно поиск подходящей теории занимал значительное время.

    Чтобы это осознать во всей полноте, надо обратиться к первоисточникам. Например, как выглядели в оригинале работы тех же греков, или Ньютона с Лейбницем. Огромное количество совершенно посторонних, с современной точки зрения, действий, сотни необоснованных утверждений. Катастрофически несовершенный аппарат, вплоть до обозначений (почитайте аль-Хорезми, хотя бы в хорошем переводе, но с обозначениями того времени; почитайте Фибоначчи; сравните знаки Ньютона, Лейбница, Эйлера, их современников с современными). Реальная теоретическая база это уже XIX и XX век. Матанализ приведён в стройную концепцию из свалки разнородного мусора Коши со товарищи. Геометрия — примерно тогда же. Самые теоросновы математики — уже в XX веке, включая жуткие поражения от Гёделя и прочих.

    Да, вслед за теорией идёт новая практика. На процентов 90, я бы сказал — когда за счёт теории получается выкинуть кучу мусора из практики и банально освободить место в мозгах. Но она всё равно проверяется той же практикой, и критерии практические. Если бы определение прямого угла треугольником 3-4-5 давало бы дикую погрешность из-за неидеальности используемых деревянных палок, никто бы его не применял. Тысячи таких потенциальных практик погибли в безвестности из-за проблем неустойчивости решения.

    В CS мы находимся на достаточно раннем этапе этого процесса. Да, это не значит, что надо сидеть на берегу реки и ждать, пока теории сами проплывут мимо. Надо изобретать, даже если 99% этого рассыпется в пыль, перекрытое лучшим или просто не выживя. Но говорить, что нет прогресса и нет теории… как-то смешно.

    > Введение объекта должно было быть теоретически обосновано.

    Теоретическое обоснование любой практики — это удел студентов под руководством замшелых преподавателей, которые методом вбивания метрового клина в голову пытаются хоть как-то научить обосновывать, а иначе не умеют. Какое теоретическое обоснование включения бензонасоса в поставку автомобиля? Насос что-то обеспечивает, и его ставят. Или не ставят. Может показаться, что аналогия хромает. Но на самом деле вся инженерная практика основана на подобных решениях. 99% это копирование предыдущих решений и интуитивное определение сущностей и возможных решений. 1% — да, теория, но прилагаемая уже к практическим идеям (насос должен быть мембранный, клапанный, турбинный? какой должен быть запас мощности? и т.п.) ООП — то же самое. С момента возникновения общей концепции есть немного принципиальных различий по сути: это давать самостоятельную жизнь каждому объекту (стиль Simula/Smalltalk, стандартные симуляции такого подхода в Erlang с компанией, etc.) или нет (C++, Java, C#, Swift и ещё тысячи их); принципиальность неизменяемости, где она полезна и как; ценность наследуемости и полиморфизма.

    Если тут и будет какая-то теория, позволяющая реализовать решение по задаче, то она будет похожа не на математику, а на ТРИЗ: простая общая база и толстая библиотека типовых решений.

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

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

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

    Методы обеспечения ссылаемости на такую общую реализацию могут быть самыми разными. Где-то это таблица виртуальных методов, как в C++, и как следствие — проблема общей базы в DAG наследников (см. множественное наследование и виртуальный базовый класс). Где-то в прототипе можно перечислить все методы явно. Где-то нет «методов», а есть привязанные логически функции. И вот тут уже начинается область, в которой сотни работ по теоретической проработке схем этих привязок, их преимуществ и недостатков; обычно оно скрывается под вывеской теории типов данных. Вероятно, Вы просто не знаете о них… что ж, пора ознакомиться.

    Но, тем не менее, наследование — такая штука, которая пролазит везде. Даже там, где от неё стараются отбиваться руками и ногами. Потому что таки удобно. А дальше начинается околотеоретический поиск, как же лучше его уложить в конкретное прокрустово ложе…

    Про NULL пропущу, потому что связанные с ним проблемы хорошо обозначены и решаются. Что за «реакционные объекты», совсем не понял. Хотелось бы пояснений.

    И, кстати: во всей статье только один пример положительно упомянутого имени — шумного агрессивного евангелиста с откровенно однобокими, зато громко рекламируемыми решениями. «Это ж-ж-ж неспроста».

    Ждём следующих обещанных статей, но начало уже вызывает пессимизм.