Давным-давно идут «священные войны» в которых обсуждаются и критикуются различные подходы в написании программ и в самом программировании, критикуется в основном Объектно-Ориентированное Программирование(раз, два, три).
Егор Бугаенко критикует ООП на практических примерах(раз, два, видео), используя идеи Девида Уэста и, как я понял, недавно пошел в сторону теории. Эффективность этих споров стремится к нулю. Почему? Потому что все эти споры ведутся уже на основе реализаций каких-то мыслей, практик и мнений отдельных людей, а не на основе теоретических работ. Научного метода и подхода с его теориями, гипотезами, аксиомами, экспериментами, доказательствами и фактами в последнее время в этих спорах и «войнах» нет от слова вообще!
В математике, как и в любой другой науке, любые теоремы и теории требуют доказательств. Как пример: Теорема Пифагора. Сначала идет теория, а за ней практика. В программировании такого подхода не придерживаются уже несколько десятков лет. Всё заменено догмами и мнением отдельных личностей, которых иногда называют «евангелистами» или «пророками». Они своим словоблудием продвигают в массы только нужные им идеи, не заботясь ни о теории, ни о доказательствах (Посмотрите конференции и презентации по ИТ). Где здесь наука, а где религия? И не скатываемся ли мы в мракобесие и веру в слова написанные давно и не требующих доказательств? Слышали про сторонников плоской Земли? Ничего не напоминает по части подходов по убеждению и упоротости?
И вот в таком кураже последние 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)
oam2oam
12.04.2018 18:49Когда приходится рассматривать ООП, то есть два подхода — в одном ОБЪЕКТ это именно что род переменной или константы, а одинаковые в чем-то типы объединяются в КЛАССы (этот подход характерен для таких языков, как Ада и Haskell). В другом подходе ОБЪЕКТ считается экземпляром максимально абстрактного типа (вообщем-то явно не упоминаемого
сами знаете кого) — это С++ и Ява (в ней вообще есть только один корневой класс Object). Но ведь на самом деле программиста уместно рассматривать как человека, который на специализированном языке описывает предметную область (литературное программирование), а вовсе не создающего объектную картину мира — ведьв начале было словоэто мы же говорим «текст программы»… А вот дальше все пошло как-то не так — действительно, если вы читали первую большую книгу Страуструпа, то наверно, вас тоже вдохновлял пример окон или матриц и операций с ними — но в том-то и дело, что методы и операции не являются (как это обычно изображают, помещая их внутрь класса) элементами объекта! Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю… И так практически постоянно — да, удобно определять операции над объектом как объектные операции, но это-то и вводит в заблуждение — мне кажется, тут лежат истоки разрастания кода и появления ошибок. В то же время создание исчерпывающей системы типов, описывающей предметную область, вводит род языка, на котором задача легче формулируется и решается (если посмотреть на Пролог — то решается автоматически, нужно лишь точно сформулировать ее).Moriline Автор
12.04.2018 19:04-2Спасибо за хороший и объемный комментарий! Программист программирует и воспроизводит предметную область (а для этого ему нужно её описать — и это важно!), реализует алгоритмы её поведения с внешними объектами и между собой. Сама по себе предметная область и должна начинаться именно с мельчайших частиц, которые имеют своё поведение и других объектов, которые производят действия над другими объектами и далее вверх. Так если брать за основу какой-то промежуточный объект — то вниз мы спуститься сможем с большим трудом и (в нашем случае химия) предметная область лишится реализации и воспроизведения. Страуструпа я не читал к сожелению. Дождитесь 2 части — там будет код на Java и я думаю что смогу показать и доказать как это реализуется на практике.
akryukov
12.04.2018 20:39+1Ну вообще
программистразработчик не воспроизводит предметную область, а моделирует ее.
То есть выделяет значимые характеристики системы и описывает правила их изменения. Точность соответствия программной модели реальному миру зависит от задачи. Довольно часто углубляться до мельчайших частиц нет никакой необходимости.
Зачем реализовывать атомы и молекулы в программе по расчету заработной платы?Moriline Автор
12.04.2018 21:24Спасибо за комментарий. Со всем согласен, кроме терминов «воспроизведения» и «моделирования». Вы можете сказать что под ними подразумеваете и чем они отличаются? Кстати хорошая книга на этот счёт есть.
CrazyFizik
13.04.2018 00:10а вовсе не создающего объектную картину мира
Вообще первый объектный язык — SIMULA (SIMUlation LAnguage) был создан именно что для описания объектной картины мира и последующей её симуляции. Сам язык был создан для научно-исследовательских задач, а не для прикладных… потом уже всякие Страуструпы и Аланы Кейны переврали его, кто как мог :-)
в ней вообще есть только один корневой класс Object
А еще там есть примитивные типы: byte, short, int, long, char, float, double и boolean, которые живут сами по себе. Забудете про разницу между Long и long — наткнетесь на упаковку-распаковку.
Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю…
Хз, наверное как посмотреть: математически для каждого множества определяется свой набор арифметических операций, порой с особыми правилами (например, умножение матриц), так что арифметические операции именно что являются свойствами множества, то бишь классов и типов по программерски
В другом подходе ОБЪЕКТ
Вот в этом то вся бяда. Нет точных определений, т.е. да, действительно, у ООП есть проблема с фундаментальным теоретическим обоснованием.
который на специализированном языке описывает предметную область
Вы наверное фанат декларативного программирования :-) Угадал? :-)oam2oam
13.04.2018 15:44Нет, не угадали :) Но вот что я за очень долгое время программирования понял — если задача сложна для понимания, надо ее попробовать записать на прологе, если удается — ты понял задачу, если нет — думай дальше…
Но декларативный стиль очень люблю, поэтому два самых любимых (но не самых используемых!) языка — пролог и ада. Вот посмотришь на свою же программу, написанную лет 20 назад в декларативном стиле — и все достаточно ясно и понятно.
Но на практике деньги приносит чистый С (по заветам старой школы), ну еще Ява…
Однако с++ я изучал в далеком 91 году, с тех пор он разве что сильно ухудшился… ну вот разве что подход Qt остался, мне кажется, очень хорошим.
Я предпочитаю не рисковать и не писать сложные системы и тем более сложные алгоритмы на с++. На яве — да, писал и пишу, но там все понятно и просто. А когда мне приводят примеры на с++, я долго выискиваю там собственно задачу, а потом оказывается, что это очень-очень простая вещь, но обильно завернутая в шелуху синтаксиса и темплейтов. Не даром есть шутка (шутка ли?), что одним из стимулов создания С++ было заставить больше платить программистам, чтобы системы разрастались и их было сложно отлаживать…
Я, кстати, вообще думаю чисто объектно-логически, но вот именно ООП для выражения мыслей ну никак не подходит! Ну не знаю, как так вот выходит…
И мне кажется, что более правильно синтезировать программу автоматически из ее доказательства (вот там и ошибок нет и отладки обычно нет — по крайней мере связанной с алгоритмом). Но под программированием ведь еще понимают (а часто только и именно) создание интефейсов с человеком — ну там всякие окна, стили и т.д… Ну вот для этого событийный подход + объекты в смысле переменные как раз больше подходит, все равно алгоритмов там нет (и хорошо)…CrazyFizik
14.04.2018 01:28За синтезом программы я думаю будущее. Собственно кое-чего уже есть: Компиляторы и кодогенераторы.
С С++ да, грустно, недавно пытался прочитать драфт стандарта C++ 17...1600+ страниц текста… Расширенный стандарт Паскаля — 200 страниц, у Фортрана 2008 — 600+ (а ведь там есть куча встроенных математических операторов, которыми в других языках даже не пахнет).
Но что касается ООП… ну я хз. Проблема в терминологии, Вирт вон породил целую линейку языков: Модула, Оберон, где были модули, инкапсуляция и интерфейсы и он не считал шо это какое-то ООП — просто развитый модульный подход.
Что же касается конкретно объектов — ну я хз. Все равно удобнее все представлять набором каких-то независимых сущностей, имеющих свое поведение, возьмем например какую-нибудь САУ: там будет объект управления, который что-то получает на вход и как-то на это реагирует (а уж что там за код внутри объекта — это никого не касается, ибо инкапсуляция) и есть регулятор — тоже ведь объект: на вход получает ошибку рассогласования, а на выходе — сигнал управления для объекта управления.
И просто процедурами здесь не проканает, т.к., например,PID регулятор должен хранить интеграл ошибки, а еще помнить предыдущие отсчеты (шоб продифференцировать) и таких регуляторов системе будет дохрена и больше — так что пусть это будут объекты, которые хранят свои внутренние состояния и имеют свою логику поведения. Более того: Типов регуляторов будет много и каждый из них будет работать по своему. И просто их задекларировать не получиться: вся соль регуляторов и ОУ именно во внутренней логике (а она многообразна и ценность представляет именно конкретный алгоритм/формула, т.е. способ решения). А вот наследованию здесь уже будет не место: во-первых наследование ломает инкапсуляцию, во-вторых наследование усложняет сопровождение: мы не увидим в исходниках наследника свойства и методы родителя — придется всю цепочку изучать, в-третьих, само по себе наследование работает несколько тупо — оно всегда идет по принципу расширения, но реальное наследование (не только биологическая) — это вообще-то комбинация свойств родителя, ну и в-четвертых, если уровней наследования больше одного, то со временем классы становятся сильно хрупкими… Композиция компонентов и реализация интерфейсов — наше все :-)
Я вообще предлагаю смотреть на любую софтину именно как на систему автоматического управления: общая логика, что мы дёрнули штурвал самолета или ткнули мышкой в кнопку — не меняется. Тут же и вылезает более подходящее представление: Data Flow и Control Blocks которые сидят на этих потоках.
С Дженериками и шаблонами все несколько сложнее (но в итоге то сводится все просто к универсальным коллекциям, которых 3.5 штуки).
В общем тут проблема скорее всего в том, что слишком дофина наплодили в ООП всяких бредовых идей, а реально то многого то и не надо.
CrazyFizik
14.04.2018 01:48И кстати еще один момент. Доказательство и написание программы через вывод доказательства.
Проблема с доказательством в том, что их меньше чем практических проблем. Реально основная масса алгоритмов работают на эвристических приемах — никакого строго математического доказательства/обоснования для них нет или оно появляется куда позже чем сам алгоритм. А вот для чего уже есть заготовленные доказательства — уже давно реализованы во всяких стандартных библиотеках. Мы такую же ситуацию наблюдаем в физике — большая ее часть, чистая эмпирика, под которую потом подводили теорию, на основе которой что-то пытались предсказать, после чего на основе предсказаний получали новый практический опыт и так далее по кругу.
Т.е. со строгим формальным подходом мы столкнемся с параличом в ряде практических задач.
oam2oam
14.04.2018 07:17Вполне согласен, что с синтезом программ имеются (и имелись) очень большие проблемы! Вот самая главная — практически нет людей, кто бы понимал хоть что-нибудь в формальном доказательстве… Тут все еще грустнее, чем в физике :)
Представьте, что вместо написания какого-нибудь хелло-ворда надо написать (!) и доказать теорему хелло-ворд (!)… Мне вот было и вначале трудно, и сейчас. Так что я остановился на имеющей практическое значение верификации (иногда доказательстве) программ, так сказать постфактум.
scoffer-by
12.04.2018 18:51-3Восхитительно! Благоговейно снимаю шляпу. Но местная фауна сейчас вас порвет в клочья, как Тузик грелку.
Moriline Автор
12.04.2018 20:11-1Спасибо за комментарий! Уже пытается рвать. Им то ли скучно, то ли поняли что можно нести всякий бред и не отвечать за это. А о доказательствах своих высказываний даже не задумываются. Печально такое читать…
scoffer-by
12.04.2018 20:31+1А вы сомневались, публикуя такое. Это все-равно, что в мечети заявить, что аллаха нет. Жуткая ересь.
В свое время известный гуру программирования Эдсгер Вибе Дейкстра сказал:
«Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.» Сейчас в этом высказывании надо только заменить Бейсик на Java Script, и все станет актуальным.
Массовая профессия с низким порогом вхождения. Никому в голову не придет, что школьник или студент первого курса будет самостоятельно, скажем, рассчитывать аэродинамику крыла самолета, или проектировать сложный электронный прибор. Для этого надо закончить профильный институт, поработать в КБ под руководством наставника над реальными проектами. Плюс, в классической инженерной деятельности есть четкое разделение между проектом и изготовлением опытного образца. Передается документация с подписями, утверждениями и пр. Нормоконтроль и всякая другая бюрократия. Если конструктор ошибся и в цехе приходится дорабатывать кувалдой, то такой специалист долго не проработает. А в программировании второй этап сводится к компиляции, да и то не всегда.
Институтские преподаватели программирования вряд ли в массе своей сами специалисты в этой области.
Волосы встают дыбом при чтении здесь высказываний, что надо предъявить доказательства необходимости контроля типов и параметров процедур. Чудовищная деградация.Moriline Автор
12.04.2018 20:41-1Согласен. Жуть просто. Некоторые личности даже не понимают что такое факты и что нужно доказывать, а что нет. Похоже я не раскрыл тему плоской Земли и розовых единорогов о которых так любит высказывать своё никому не нужное мнение здешняя публика( не вся конечно!). Мало иметь ум в голове — надо ещё уметь им правильно пользоваться. А то по-набирают по объявлению программистов и мучайся потом с ними.
picul
12.04.2018 20:45-1А почему Вы считаете, что знаете, что нужно доказывать, а что нет? А почему Вы считаете, что Ваше мнение кому-то нужно? А Вы то сам хоть программист?
Zam_dev
13.04.2018 01:49Мне одному кажется, что если вы со scoffer-by (еще?) не знакомы (лично), то непременно следует это сделать
lair
12.04.2018 19:26+5И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
А почему не должно? Почему должно быть так мало языков?
Обьект — наименьшая неделимая сущность, также известная нам как химический элемент, имеющая множество свойств и множество моделей поведения реализуемые через методы. У объекта есть 2 типа методов: 1) для получения его свойств, 2) для изменения его состояния.
А теперь, значит, зададимся вопросами: что такое "свойство", что такое "состояние", что такое "поведение", и что такое "метод". А то у вас базовое определение прямо сразу опирается на неопределенные понятия.
Факты
Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.
В частности, даже формально "поэтому за основу главного объекта необходимо брать именно химический элемент" — это не факт, а вывод (и вывод спорный).
выделим несколько принципов:
… тоже ни на чем не основанных.
Иными словами, вы заявили, что пытаетесь применить науку, но в реальности все, что вы делаете — это (не очень успешно) придаете своим размышлениям наукообразие.
Moriline Автор
12.04.2018 19:39-3Спасибо за вопросы! По пунктам:
«А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод. Также как и наличие разных теорий может быть очень много, но правильная только одна.
«что такое „свойство“, что такое „состояние“,» — потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.
«Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.» — Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.
«В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968
По итогу — если Вы не согласны, то докажите своё мнение.picul
12.04.2018 19:50+3Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.
Бремя доказывания Ваших фактов лежит на Вас. Пока Вы их не доказали — они всего лишь флуд, а значит то, что флуд разводить начали Вы — это научно доказанный факт.
akryukov
12.04.2018 20:42«А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод.
Ну ладно. Но почему 2 низкоуровневых, а не один? Почему 3 или 4, а не один? Почему это должны быть разные языки? Чем в вашей терминологии отличаются высокоуровневые языки от низкоуровневых?
lair
12.04.2018 21:12+1потому что исходя из определения что «истина только одна» я и сделал такой вывод.
Почему-то идея об единственности истины никак не мешает существованию множества языков общения. Почему тогда для языков программирования должны быть другие правила?
Язык программирования — это инструмент, средство решение задачи. Вокруг нас много разных средств транспорта, много разных фотоаппаратов (и не просто разных моделей, а радикально конструктивно разных устройств), много фасонов одежды и много способов прикрепить что-нибудь к чему-нибудь. Так почему языков программирования должно быть 6, а не множество?
потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.
Подождите, что "это" утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше "базовое определение".
Вот Вы и докажите, что приведенные мною факты таковыми не являются.
И эти люди
запрещают мне ковыряться в носубудут рассказывать про научный метод? Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?
«В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968
В комментарии по ссылке нет ничего, что превратило бы вывод "Всё [...] состоит из [...] и поэтому [...] необходимо брать именно [...]" в факт, за который вы это выдаете.
По итогу — если Вы не согласны, то докажите своё мнение.
Не, так не работает. Вы делаете утверждения, вы их и доказываете. Пока что вы не справились даже с вопросами к вашему первому "базовому определению" (могу повторить, если надо) и первому "факту". Какой смысл обсуждать остальное, если первичные посылки ложны?
Moriline Автор
12.04.2018 21:46-1«Почему-то идея об единственности истины никак не мешает существованию множества языков общения. Почему тогда для языков программирования должны быть другие правила?» Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!
«Язык программирования — это инструмент, средство решение задачи.» — У Вас неверное определение. Почитайте этот комментарий.
«Подождите, что „это“ утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше „базовое определение“.» — поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки, потому как Вы, похоже, будете спрашивать меня и о том, что такое союз «и»!
«Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?» Я знаю на ком лежит бремя и знаю про чайник Рассела. То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?lair
12.04.2018 21:59Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!
Я готов согласиться, что из разных целей вытекают разные правила. Но почему языков программирования должно быть мало?
У Вас неверное определение. Почитайте этот комментарий.
А почему вдруг приведенное в этом комментарии определение более верное, чем мое?
поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки,
И эти ссылки согласованы с вашим определением объекта и не содержат неопределенных понятий? Нет и нет.
То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц
Вам нужно привести обоснование ваших утверждений и выводов, потому что иначе они выглядят необоснованными.
наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?
Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так). Так что да, это тоже придется обосновывать. Но это, на самом деле, скучно — а интересно, почему объект в программировании обязан соотноситься с неделимой частицей в реальном мире.
Moriline Автор
12.04.2018 23:291. «Но почему языков программирования должно быть мало?» Внимательно читайте что такое ЯП, для чего он нужен в моём комментарии. Вам лень читать и думать?
2. «А почему вдруг приведенное в этом комментарии определение более верное, чем мое?» Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.
3. «Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так)» — в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно! Читайте тут: Отношение понятий.lair
12.04.2018 23:30Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.
Эм, нет. В частности, ваше определение языка не способно ответь на вопрос, почему языков должно быть мало.
в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно!
А почему нас должно интересовать определение из химии и ограничение на химические процессы?
Moriline Автор
13.04.2018 00:041. Потому что только один язык сможет решать задачи эффективнее других. В какой-то момент их может быть и больше, но в итоге эффективность переноса алгоритма в инструкции для исполнительного устройства у каждого человека одинаковы.
2. А Вас и не интересует. И других разработчиков языков тоже. И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье. Почему нужно ограничение читайте в моих комментариях.lair
13.04.2018 00:10Потому что только один язык сможет решать задачи эффективнее других.
Вне зависимости от определения, это утверждение ошибочно (или, по крайней мере, недоказуемо).
Во-первых, даже для одной задачи наблюдаемо, что есть больше одного эффективного инструмента для ее решения (как-то: для задачи коммуникации между людьми существует более одного языка, для задачи сверления дыр в стене есть более одной дрели).
Во-вторых, есть более одной задачи, решаемой языком программирования, и эти задачи, очевидно, могут решаться разными языками с разной эффективностью; нет никакого способа показать, что есть один язык, решающий все задачи заведомо эффективнее других языков, включая специализированные.
эффективность переноса алгоритма в инструкции для исполнительного устройства у каждого человека одинаковы
Ну а это-то наблюдаемо ошибочно: разные люди по-разному реализуют один и тот же алгоритм даже на одном языке.
И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье.
Однако нигде по ссылкам не будет объяснения, почему использование определения из химии предотвратило бы произошедшее.
Почему нужно ограничение читайте в моих комментариях.
Там нет объяснения, почему ограничение на химические процессы оправдано.
lair
13.04.2018 00:20только один язык сможет решать задачи эффективнее других.
Еще, кстати, я не вижу способа формально это предположение опровергнуть, поэтому, согласно критерию Поппера, оно… ненаучно (по крайней мере, не является научной эмпирической теорией).
0xd34df00d
13.04.2018 03:53А Вас и не интересует. И других разработчиков языков тоже. И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье. Почему нужно ограничение читайте в моих комментариях.
Меня интересует, например, теория типов и всякая такая наркомания, но к вашему выводу я не прихожу. В чём я ошибаюсь?
lair
12.04.2018 23:50Потому что моё определение может ответить на ВСЕ вопросы о языке
Я, кстати, внезапно заметил, что, собственно, никакого определения языка вы не привели. Или я пропустил что-то?
Moriline Автор
13.04.2018 00:11Вы невнимательно читаете. Я не давал определения языка, я описывал его цели и задачи:
Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат).
И тут:
2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
Тут правильнее сказать не «обеспечивать», а «транслировать» мыслительный процесс в машинные инструкции с помощью языка конечно.lair
13.04.2018 00:17Я не давал определения языка
Значит, ваше определение не может ответить на все вопросы, потому что его просто не существует.
Другими словами — язык не решает задач!
Почему же, решает. Он решает как минимум задачу выражения алгоритма для вычислительного устройства (и это не единственная задача).
Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
Как уже говорилось выше, понятие "эффективности" пока что объективно неизмеримо, и поэтому не имеет никакого преимущества перед настолько же субъективным понятием "удобства" (в значении "язык программирования удобен для программиста"). Поэтому я не вижу никаких оснований считать вашу формулировку ("[языки должны] эффективно транслировать мыслительный процесс человека в машинные инструкции") более правильной чем "[языки должны] быть удобным для их пользователей".
geher
12.04.2018 21:36+1Также как и наличие разных теорий может быть очень много, но правильная только одна.
Неверно. Правильных теорий может быть много. просто у них будут свои области применимости.
Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.Moriline Автор
12.04.2018 21:53Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ. Существующие теории в физике объясняют всего лишь часть устройства мира и его процессов, но не весь целиком. Значит учёные не выработали ещё такую теорию которая бы это сделала на данный момент времени. Ведь раньше люди думали что Земля плоская. Хотя, похоже, даже сейчас особо одарённые так думают.
lair
12.04.2018 22:03Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.
Зато есть теории, обладающие достаточной предсказательной силой, чтобы быть успешно применимыми на практике. Что, кстати, доказывает, что языков программирования успешно может быть много.
Moriline Автор
12.04.2018 22:56В том то и дело, что наклепать в большом количестве можно сколько угодно. И теорий и языков программирования. И только несколько языков из почти 2 сотен используются интенсивно и активно. Только какая от этого эффективность в решении задач? А сколько теорий происхождения человека у религий? А у науки? Так где более эффективный подход?
lair
12.04.2018 22:57Только какая от этого эффективность в решении задач?
А вы уже нашли способ объективного измерения эффективности решения задач с помощью языка программирования?
geher
13.04.2018 11:56Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.
Нет гарантированно истинных теорий.
Правильных много.
При этом теория является правильной только для тех задач, которые она позволяет решать с приемлемой точностью.
Кстати о плоской Земле, в задачах, когда кривизна поверхности не сильно сказывается на результате, она вполне себе принимается плоской (например, в задачах, связанных с прокладыванием маршрута).
CrazyFizik
13.04.2018 01:10Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн. В каких-то условиях можно упростить вычисления и пренебречь некоторыми особенностями: чисто волновое описание является опять таки частным случаем: просто для того что бы нам рассчитать антенны, нам не нужно городить формулы из квантовой электродинамики, а вот для описания фотоэффекта чисто волновое представление уже не проканает.
Физика — она как Шрек, который как луковица :-) представляет из себя слои разных теорий разной степени приближенности к одной основной (пока неизвестной). Реально то теорий сейчас всего две — квантовая механика, да теория относительности, остальные можно рассматривать как их производные, да частные случаи и то, это только потому что КМ и ОТО не очень совместимы друг с другом.geher
13.04.2018 12:10Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.
Другой вопрос, что эта разница не превышает требуемую точность, но разница все равно есть.
Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным). В некоторых случаях оно даже прокатывало. Но по одному вопросу (вероятность повторного слияния и дальнейшее движение после слияния) не прокатило. Пришлось учитывать релятивистские спецэффекты.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн
Это уже третья теория, объединяющая наработки первых двух.
Но при решении большого класса задач учитывать в модели все сразу не надо. А потому откатываемся назад, к одной из двух старых теорий.CrazyFizik
14.04.2018 02:38Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.
Угу изменение размеров из-за релятивистских эффектов велосипедиста будут на несколько порядков меньше ковалентного радиуса атома водорода и будут полностью замаскированы тепловыми флуктуациями — поправки преобразований Лоренца при малых скоростях становятся бесконечно малыми и стремятся к нулю, т.е. по-простому лишены какого-то физического смысла. Только софистики ради такие вещи можно обсуждать.
Все эти эффекты становятся более-менее измеримыми только на космических скоростях. Вот на изменения перигелия Меркурия — мы увидим расхождение с классической механикой, наблюдая как резвятся черепахи — даже физически замерить не сможем.
В ОТО и СТО классическая механика Ньютона является предельным частным случаем и справедлива для движения в относительно слабых гравитационных полях и при малых скоростях.
Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным).
Это наверное были какие-то неправильные СМИ у которых какие-то неправильные новости. Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать. Так шо я даже хз, че там можно намоделировать задействовав ньютоновскую механику… вероятно ничегоDruu
14.04.2018 09:26> Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать.
Вообще-то в ньютоновской теории тяготения черные дыры тоже вполне себе есть, и у них даже радиус совпадает с шварцшильдовским.
0xd34df00d
13.04.2018 03:50Также как и наличие разных теорий может быть очень много, но правильная только одна.
Какая математика истинная, с аксиомой выбора или без неё?Moriline Автор
13.04.2018 08:03Спасибо за комментарий. Раскройте Ваш вопрос более полнее и точнее. А то Ваш вопрос вызывает больше вопросов, чем ответ на него.
0xd34df00d
13.04.2018 08:14Я, если честно, даже не знаю, как его как-то полнее раскрыть.
Ну вот вы говорите, что правильная теория только одна. Я вот вас спрашиваю, какая теория множеств правильная, ZF или ZFC?
Есть ещё и другие альтернативные аксиоме выбора аксиомы, позволяющие тоже доказывать всякие полезные и интуитивно очевидные факты, но с чуть меньшим количеством всякой неинтуитивной ерунды, но это уже другой разговор.Moriline Автор
13.04.2018 09:03«Я вот вас спрашиваю, какая теория множеств правильная, ZF или ZFC?» — А что учёные говорят по этому поводу? В вики написано: «К этой системе аксиом часто добавляют аксиому выбора, и называют системой Цермело — Френкеля с аксиомой выбора (ZFC).» — получается что ZFC всего лишь надстройка над ZF?
0xd34df00d
13.04.2018 18:53А что учёные говорят по этому поводу?
Какие? Математики? Ну, противники аксиомы выбора аксиому выбора опровергнуть не смогли ;)
получается что ZFC всего лишь надстройка над ZF?
Выводы из ZF не являются подмножеством выводов из ZFC, это разные теории. В одной вы можете слепить из одной сферы две, разрезав её на конечное число кусков, в другой — нет. В одной у бесконечномерных пространств есть базисы, в другой — нет. В одной любое множество можно вполне упорядочить, в другой — нет. В конце концов, в одной ясно, зачем нужна формальная теория вероятности с сигма-алгебрами, а в другой — не очень.Moriline Автор
13.04.2018 19:17Нет, не говорит. Просветите пожалуйста. Насколько я догадываюсь, хранение состояния реализовано через функцию и хитрое условие хранения переменной и её изменения. Я прав?
0xd34df00d
13.04.2018 19:26+1Это вы, видимо, на другой мой комментарий про фазовое пространство, ну да ладно.
Нет никакого хранения состояния, есть просто множество всех возможных состояний. Вам не нужно хранить состояние, если у вас они есть все возможные, и особенно если вы можете записать правило изменения состояния (а вы можете, потому что по предположению ваша задача алгоритмизуема).
В конце концов, можно на википедии почитать. А ещё можно вспомнить, например, про формальное определение рекурсии, про трансфинитную индукцию и прочие подобные вещи, тоже навевающие мысли о состоянии.
И, к сожалению, не могу не воздержаться от такой ремарки. Вот мы тут в комментариях к статье про научный подход к программированию. Тема статьи накладывает определённые ожидания к уровню научной и математической культуры автора, коли уж он собирается заниматься формализацией программирования. Но куда не тыкни — как-то не густо. Про разные теории в математике никак, про понятие состояния и фазового пространства в физике никак (а даже я, долбанный примат, с теормеха на втором курсе это помню), про вышеупомянутые всякие трансфинитные индукции-рекурсии, готов поспорить, тоже никак. Ну и особенно забавно, что те люди, которые в этом всём как-то шарят, не горят желанием химией измерить программирование, а садятся и пишут папиры про теорию типов, или пишут свои системы типов, и так далее.
CrazyFizik
13.04.2018 00:49А почему не должно? Почему должно быть так мало языков?
А зачем их собственно много? Я еще понимаю ассемблер — он для каждого процессора свой нужен, хотя один фиг, все ассемблеры (по крайней мере для одного типа вычислительных машин) будут пересекаться друг с другом основным набором команд.
А вон у совсем брутальных хардварщиков языка вообще два — Verilog, да VHDL, да их производные и справляются как-то.
А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Собственно реально массово используемых действительно не так уж и много языков, а все современные языки происходят либо от Fortran'а и его прямых потомков: Algol и Basic, либо от более поздних независимых веток: APL, Lisp (точнее IPL), COMIT и Cobol (точнее FLOW-MATIC) — больше чойт на память и не приходит, либо их комбинации.
С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли, но между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)lair
13.04.2018 00:53А зачем их собственно много?
Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.
Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Ну так вкусовщина — это же совершенно валидный аргумент. До тех пор, пока одной из задач языка программирования будет передача намерения одного программиста другому программисту, выбор языка (и стиля письма) будет обусловлен в том числе и сугубо субъективными факторами.
CrazyFizik
13.04.2018 01:48Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.
Ну их все равно реально используемых не так много:
Любишь металл: 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
13.04.2018 01:54Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?
Большое обилие языков все же скорее это результат процесса их эволюции.
… что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до "одного-двух" видов.
Zam_dev
13.04.2018 02:16Основная мысль автора понятна, с точки зрения точных наук — истина одна… но в искусстве нет точности. Кажись, ЯП где то между ними)
Moriline Автор
13.04.2018 02:48Уверен что программирование даже частично искусством называть нельзя ( хотя несколько лет назад я сам так думал). Здесь прагматический подход, логика, математика, опыт, специфическая психология работы. Нельзя прийти, написать какую-то белиберду и сказать: Я так вижу! Я так чувствую! Меня муза посетила…
Zam_dev
13.04.2018 03:07Нет, Вам никак не погубить ту романтику, что я испытываю к ЯП… ни с математикой, ни с химией и т.п. ничего подобного я не испытывал!) А что стало причиной гибели Вашей страсти, любопытно было бы услышать.
Moriline Автор
13.04.2018 08:08А я и не пытался ничего губить! Я же написал что из себя это искусство и романтика представляет всего лишь «специфическую психологию работы» программиста. В этом нет ничего плохого или унизительного. Вам просто нравится заниматься любимым делом больше других и Вы от этого получаете наслаждение. Как получают другие люди от других видов профессий.
Zam_dev
13.04.2018 03:30Вы же сами написали "Особо упоротые фундаменталисты придумали Функциональное Программирование основанное на математике", подразумевая рак, щуку и лебедя… может исключим тогда уж доконца однобокость восприятия, в перечеслении составляющих программирования.
"Меня муза посетила…" неужели не было никогда озарения после долгого периода мучений — Вы точно программист?)
CrazyFizik
13.04.2018 02:19Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?
Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.
… что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до «одного-двух» видов.
Ну кстати я такой фигней немного занимаюсь (только с другого бока) там на самом деле видовое разнообразие испытывает периода взрывного роста и обеднения. Ну а один вырвавшийся вперед вид начинает вытеснять остальные. Гхм, кролики и коты в Австралии — местная флора и фауна от них офигела. Тех же кроликов пытаются можно сказать биологическим оружием теперь истреблять.
Автор: CSIRO, CC BY 3.0, Ссылка
Но эт я отвлекся. Да, на самом деле я думаю развитие языков похоже на биологическую эволюцию.lair
13.04.2018 12:06Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.
А не важно, нишевые они или нет (хотя за определение некоторых языков как "нишевых" с вами многие бы и поспорили), важно, что они есть и у них есть применение (собственно, не бывает нишевых языков без соответствующей ниши), для которого они лучше других. Что лишний раз доказывает полезность существования многих языков.
0xd34df00d
13.04.2018 04:04Хочешь безопасно: Жаба или 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
13.04.2018 04:19> Ма, смотри, у меня динамическая типизация в одном из строжайше типизированных языков!
Не, ну динамика, это когда можно невозбранно сложить строку с числом (например dynamic в шарпе это позволяет). А вы же в данном случае никаких операций к dyna применить не можете, то есть фактически моделируете подтипирование на экзистеншоналах (вполне статическое), так?0xd34df00d
13.04.2018 07:39Не, ну динамика, это когда можно невозбранно сложить строку с числом (например dynamic в шарпе это позволяет).
Вы динамику со строгостью тут случаем не путаете? А то у вас питон получается не очень динамический.
А вы же в данном случае никаких операций к dyna применить не можете
Зависит. Я, увы, не могу паттерн-матчить на типах (см. последующий абзац в предыдущем комментарии), поэтому написать функцию вроде
justStrings : List Dyna justStrings = filter f dynaList where f : Dyna -> Bool f (String ** _) = True f _ = False
у вас не получится. При этом (опять же, см. последующий абзац в предыдущем комментарии) каких-то теоретических причин не иметь это в системе типов нет, кто-то там что-то ресёрчит на тему.
то есть фактически моделируете подтипирование на экзистеншоналах (вполне статическое), так?
О, как раз нет, и в этом принципиальное различие! На экзистеншиалах вы стираете исходный тип и в лучшем случае знаете, что значение реализует какой-нибудь тайпкласс. А тут у вас именно что динамика в питон-стиле (где рядом с каждым значением лежит его тип) — список зависимых пар, где первое значение — тип, а второе — значение этого типа. При этом тип любой пары одинаков, и вы его знаете.
Там ещё можно забавные параллели с квантором существования и прочими Карри-Говардами привести.0xd34df00d
13.04.2018 08:10Поигрался ещё, можно, например, слить вместе два списка, сохраняя информацию о типах, чего вы никогда не сделаете на экзистеншионалах в хаскель-стиле:
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
14.04.2018 02:580xd34df00d
14.04.2018 03:07Спасибо, узнал очень много нового для себя!
Так какой вид типизации в примере выше, особенно с последующей ремаркой?
Druu
14.04.2018 09:37> Вы динамику со строгостью тут случаем не путаете? А то у вас питон получается не очень динамический.
Нет. Оговорюсь, под «когда можно невозбранно сложить строку с числом» подразумевалось, что это запрещено статически (программа не скомпилируется). В питоне это запрещено, но динамически, в рантайме.
> О, как раз нет, и в этом принципиальное различие! На экзистеншиалах вы стираете исходный тип и в лучшем случае знаете, что значение реализует какой-нибудь тайпкласс. А тут у вас именно что динамика в питон-стиле
Но вы же не можете никаких операций к этому типу применить. То есть это аналог вполне статического Object из вполне статической джавы. В динамике вы должны иметь возможность применить к объекту любые операции (опять же — речь о статических проверках, в рантайме, конечно, операция может и не быть успешно выполнено, главное что компилятор вам даст написать такую программу).
И, более того:
> Я, увы, не могу паттерн-матчить на типах
Даже если бы могли — это не было бы динамикой все равно. В динамике проверок типов (при компиляции) в принципе нет и потому вам вообще матчить ничего не надо. Вы просто берете и применяете любую ф-ю к любому аргументу.
> И тут я уже как-то запутался, что есть статическая типизация, а что — динамическая.
Ну, общепринято, что когда типы проверяет компилятор до рантайма — это типизация статическая, а когда типы проверяются в рантайме — то это динамическая.
CrazyFizik
14.04.2018 02:52Вы как-то сильно рефлексируйте. Не надо так.
0xd34df00d
14.04.2018 03:09Вы высказываете набор утверждений, с некоторыми из которых я не согласен. Я отвечаю на эти ваши утверждения некоторыми комментариями. Вы бы, что ли, ответили на эти самые комментарии, а то, как вы говорите, не надо так.
Пикабушных картинок нету, извините, подставьте что-нибудь сами.
lair
13.04.2018 00:59А зачем их собственно много?
Но на самом деле, я просто считаю эту подмену вопроса некорректной. "Зачем много языков" — может быть и низачем, черт знает. "Должно быть мало языков" — э, почему вдруг внезапно? Из "низачем не надо много" никак не вытекает "должно быть мало".
CrazyFizik
13.04.2018 02:02Не. Ну языков все равно должно быть больше 1-ой штуки. Шоб была конкуренция и не вернули рабовладельческий строй.
Ну еще вкус и цвет, есть вот например люди, которые скобочки любят…
Но в итоге, даже если языков будет 10 конкурирующих между собой, то в своей основе они будут мало различаться. Собственно это мы сейчас это и наблюдаем: во все языки напихивают как можно больше самых разных парадигм программирования и технологий. Единственная проблема действительно в… эээ… в строгости определения понятия ООП и как меняются на него взгляды (опять таки — эволюция языков и подходов) и реализации.Moriline Автор
13.04.2018 02:38Браво! Отличный комментарий! Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии. Взять хотя бы SQL с его стандартами — ну разве не красота? Правда каждая реализация норовит его расширить, но стараются держаться в разумных пределах. Примерно так и должно быть с остальными языками. Должен быть стандарт.
lair
13.04.2018 12:08Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии.
Вы не находите, что вы противоречите себе же, в той части, где "должен быть один максимально эффективный язык"?
Взять хотя бы SQL с его стандартами — ну разве не красота?
Нет, не красота. После того, как попробуешь на этом "стандартном" языке порешать задачи из реальной жизни, любовь к стандарту резко пропадает.
Moriline Автор
13.04.2018 01:18Спасибо за подробные комментарии! Ваша помощь очень пригодилась! Напишите еще свои мысли или замечания к статье, если они у Вас есть.
0xd34df00d
13.04.2018 03:57А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Мне бы очень хотелось, чтобы люди, так считающие, на секунду задумались о том, что бы случилось с индустрией, если бы другие люди, считающие точно так же, но лет на 60 раньше, где-нибудь в 50-х, таки навязали бы эту точку зрения.
С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли
Не вижу логической связи между строгим образованием и глубиной/широтой проникновения приёмов.
между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)
И что из этого следует? Хаскель вычеркнуть, а уж всякие идрисы и агды — тем более?
Ну так оставить один javascript тогда, на нём орды программистов. Правда, топикстартер будет не очень счастлив такой интерпретации его тезиса, учитывая его же комментарии выше, ну да ладно.CrazyFizik
14.04.2018 02:50Не вижу логической связи между строгим образованием и глубиной/широтой проникновения приёмов.
Не вижу логической связи между моим сообщением и Вашими комментариями.
Что общего между карандашом и ботинком? :-)0xd34df00d
14.04.2018 03:12Обычно предложения, построенные по структуре «A имеет B — C», где A — некоторый объект, B — его свойство, C — наблюдаемый факт, имеют один из двух смыслов: либо C обосновывает B, либо B постулируется, а C описывается как следствие. Я говорил о первой интерпретации, но можно обсудить и вторую, конечно же.
smallplushbear
12.04.2018 19:40Обнаучить процесс программирования — цель благая. Научным методом доказать правильность, эффективность и превосходство одной из парадигм — достойная цель.
Предлагаю начать с первого вопроса: "Что такое программирование?".
Боюсь, ответ будет почти там-же, где и определение "Искусственный интеллект".
Упрется все в "Интеллект".
Спрашивал в институте им. Бехтерева — пока молчат…Moriline Автор
12.04.2018 19:45Хороший вопрос — тянет на отдельную статью и даже научный труд! Тяжело будет — зато достойный целой жизни. Но боюсь опять набегут личности, не отвечающие за свои слова, и не поняв ни фактов ни логики начнут гадить. Но это останавливать не должно.
smallplushbear
12.04.2018 20:01Я это к тому, что прежде чем включать научный метод и математику, необходима точка отсчета. А её нет. Лет уже больше 50 как нет. И без её наличия ни научный метод ни математика не применимы.
Moriline Автор
12.04.2018 20:15Именно это я в статье и говорю. Да, нужна точка отчёта. Я пытаюсь. Но ведь кто-то тоже должен сделать попытку. Почему не Вы?
picul
12.04.2018 19:45+1Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании? Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей. А вот Ваши «доказательства» и «объяснения» — они то и не нужны никому от слова «совсем».
В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
Интересно, откуда такие цифры?
Факты:
Относятся к реальному миру, а не к программированию.
несколько принципов:
Похожи на смесь Coding Style Guide и какого-то очередного шаблона проектирования, которые вы так ненавидите.
Гипотеза:
Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.
P. S. Почему в качестве ЯП для «доказательства гипотезы» выбрана Java? Она ведь полностью объектно-ориентирована, а судя по Вашей статье, хуже ООП может быть только ФП)Moriline Автор
12.04.2018 19:58Спасибо за вопросы! По пунктам:
1. «Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании?» До определённого момента это было нужно и было доказано и обосновано логически, теоретически и экспериментально, а после нет. Почитайте ссылки которые я привел — хотя бы по-диагонали чтобы понять масштаб проблемы.
2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
3. «Интересно, откуда такие цифры?» — habrahabr.ru/post/353408/#comment_10752012
4. «Относятся к реальному миру, а не к программированию.» — а чем занимается программирование Вы задумывались? Ведь программирование было ещё до ЭВМ и автоматов. Подумайте в эту сторону и в историю углубитесь.
5. «Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.» — Вы невнимательно прочли. Вот оригинал: «3. Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять.» Не код, а объекты! Это большая разница.picul
12.04.2018 20:381. Можете пожалуйста конкретно указать статью? Ссылок очень много, и в основном это просто холиварные статьи.
2. Задача языка — предоставить удобный программисту инструментарий для решения задач. «Доказательства» и «объяснения» на каждом шагу — это не очень удобно.
3. Так если истина едина, зачем целых 6 языков?)
4. Программирование занимается симуляцией процессов в окружающей среде, потому что просчитывать каждый атом во Вселенной Вам никаких машин не хватит. И я нахожусь не в истории, а в реальности, и задачи решаю соответствующие. А про программирование до нашей эры ИМХО Вы написали не на тот ресурс.
5. Это все, что Вам удалось родить после простыни про научный подход и оскорбления признанных ученых?
Mikluho
12.04.2018 21:12Как, опять??
Ну сколько же можно мучить парадигмы программирования. Тем более не предлагая альтернативы…
Я, как и многие тут, не увидел в вашем тексте ни намёка на «научное программирование», только лишь странные, ничем не подтверждённые, измышления, и яркое желание изнасиловать сложившиеся методики программирования.
Задавать вопрос «А зачем вам это вообще», наверно бессмысленно.
Потому задам другой: а с чего вы решили, что предлагаемый вами подход будет хоть кому-то полезен? Где ваше научное или маркетинговое исследование?
Сколько я знаю языков программирования и историй их создания — авторы почти всех (или даже совсем всех...) реально используемых языков при создании очередного ЯП руководствовались вполне конкретными целями и решали вполне конкретные проблемы. И ЯП становился популярным именно тогда, когда пользователи этого ЯП, сиречь программисты, ощущали оную пользу и всячески благодарили автора(ов).
Следуя реалиям жизни, вам стоит создать таки свой ЯП и представить его миру, выстоять под градом камней и затем уж получить заслуженные почести.
Ну или хотя бы, опишите и докажите теорию, согласно которой выбранные подход к ООП является наиболее эффективным по ряду критериев… Или хоть выведите и обоснуйте эти критерии, проранжируйте по ним существующие ЯП, сделайте выводы…
Да, кстати, приведённые вами примеры научного подхода ярко демонстрирую то, чего в вашем тексте нету…
И да, напоследок, про реальную жизнь: плохой программист напишет каку на любом, сколь угодно совершенном ЯП, а хороший пособен сделать конфетку на любом ЯП, которым он владеет. И как вы в эту реалию впихнёте превосходство вашего подхода — тоже интересный вопрос :).
ps
Истина одна, но она никому не нужна, потому правд много и именно ими пользуются живые люди. Почему так — почитайте философов…
Moriline Автор
12.04.2018 21:14-11. Вам лень читать? Серьезно? Вы на тот ресурс зашли?
2. «Задача языка — предоставить удобный программисту инструментарий для решения задач» — Опять Вы придумываете небылицы! «инструментарий» — это автомат, процессор, какой-либо механизм, IDE на худой конец. Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат). Что здесь трудно понять? Почитайте что-нибудь для разнообразия прежде чем так выражаться.
3. Зачем?
4. «Программирование занимается симуляцией процессов в окружающей среде» — Я же Вам ответил и дал направление, но из-за лени Вы не потрудились ни изучить историю, ни напрячь мозг и начали выдавать сказки про симуляцию. Ада Лавлейс и Бэббидж тоже занималась симуляцией? Как Вам не стыдно такое даже печатать?
5. «оскорбления признанных ученых» — где я это сделал можете указать?
vdasus
12.04.2018 22:05:: язык не решает задач! Задачи решает алгоритм
Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам. Как-то: развитой инструментарий, широкий набор готовых библиотек или компонентов (что тоже, де-факто, входит в понятие языка в моей терминологии), наличию разработчиков,…
:: Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять
Хотите я вам покажу большой объект, который будет легко понимать и читать. И сделаю вам код где много крохотных объектов, но вы замучаетесь пытаться понять что происходит? Конечно я не собираюсь этого делать — вопрос риторический и ответ на него очевиден.
Я склонен согласиться с теми, кто считает что язык (всю экосистему) выбирают под задачи и разнообразие языков это добро. Вот это мне быстрее и удобнее выразить на такой платформе, а вот это — на такой. И многообразие языков (экосистем) это хорошо. Хочешь ИИ — питон какой-нибудь, хочешь быстро и удобно написать веб приложение — .net (особенно core), SPA? Vue, React (js), хочешь то — Си, хочешь сё — с++,… f# и т.д. Каждая экосистема появилась не просто так. И я бы не отделял абстрактный в вакууме язык от того что он несет с собой. И, главное, почему это самое «несу с собой» появилось.
Дайте мне задачу — я объясню почему ее надо решать на выборе из таких-то платформ (языков)
Появление, скажем, .core позволяет мне легко и красиво за день делать то, что раньше я делал месяцами.
Включить мозг, читать очень много книг, лекций, статей, курсов, потом долго учиться применять самое умное из того что вы прочитали, придумывать свое и вы сможете писать отличный код на любом языке. И еще важный момент — не спать. Держать руку на пульсе. Но это не только у нас, айтишников. Ключевой момент — программированию надо серьезно учиться. Если вы умеете *программировать* — язык или платформа перестают быть важным моментом. Мне, например, не очень важно на чем писать (есть тонкие моменты, но это не для тут).
Боязнь множества языков от осознания что мы просто не успеваем за развитием. Посмотрите что творится в мире фронтенда. Это же какой-то ужас… Но надо понять что хороший программист это не знаток реакта. Хороший программист тот, кто понимает почему код надо организовывать так, а не иначе. Что надо писать тесты и это не лишнее время, а наоборот его сильная экономия, что… Поэтому надо перестать бояться, начать изучать паттерны, подходы, идеи. Изучить синтаксис — недолго. Изучить идею (зная основные тенденции) — тоже недолго. Узнать тонкости… тут зависит от разработчика, наличия «у кого спросить» и поставленных задач, но, опять же не все так страшно.
Прочитал Ваш пост по диагонали потому, что почти в каждой строчке есть спорный момент, так что если я вообще не понял суть — прошу извинить.Moriline Автор
12.04.2018 22:33Спасибо за развёрнутый комментарий.
Как я и писал в статье — проблема в том что программисты спорят основываясь уже на реализации, а не на теории и науке. В этом большая разница! Грубо говоря в ЯП сейчас тихий ужас из-за описанной мною истории их создания. Если Вы начнёте мыслить с точки зрения основ программирования, его истории, задач и целей и каким образом именно наука, а не религия дало всё то, что нас сейчас окружает и какие подходы использовала, то признаете что рациональное зерно в этой статье всё таки есть. А лучше всего прочитать статью внимательно, походить по ссылкам, книгу почитать и комментарии мои и вдуматься в сказанное. Сделать это — большая и трудная работа, но она необходима. А терпением для этого мало кто может похвастаться.
1. «Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам.» — написано в этом комментарии.
2. «Хотите я вам покажу большой объект, который будет легко понимать и читать.» — Ответ действительно очевиден. «Если сильно захотеть — можно в космос полететь!». Только вот в науке и реальном мире сложное, по определению, не может быть проще простого.
picul
12.04.2018 23:31+11. Читать кучу статей с заявлениями «все фигня, давай по новой, но я не знаю как» — да, лень. А Вам лень предоставить конкретный материал, который является подкреплением Вашей точки зрения?
2. Как Вы хотите, что бы кто-то понял Вашу точку зрения, если сами не способны понять чужую? Язык предоставляет средства для решения задачи — это значит, что он предоставляет семантические конструкции, которыми программист может выразить свои мысли. В императивном программировании это разные инструкции, которые со временем оформили в процедуры, которые со временем объединили с данными и назвали классами. В функциональном это функции, которые не используют каких-то состояний, а выдают результирующие значения только на основе своих аргументов. ( Примеры поверхностные, но, надеюсь, Вы понимаете, о чем я. ) Задача языка — сделать так, что бы программисту было удобно пользоваться этими средствами, которые язык предоставляет, а также что-бы эта легкость использования не повлияла на качество программы, которая на языке будет написана. Соответствие каким-то наукам — это очень второстепенная задача.
3. Это лучшая научная аргументация, которую Вы можете предоставить?
4. А, так значит «научный подход» — это выбросить компьютеры и работать на изобретениях 19-ого века? Или нет? Просто Вы так и не объяснили.
5. Например
чем ваши слова отличаются от слов религиозного фанатика-экстремиста сбежавшего из психбольницы?
Это не совсем прямое оскорбление, но Вы смешали с грязью практически все парадигмы программирования ( над которыми работали эти самые ученые ), при этом не удосужились не аргументировать свою точку зрения, ни предложить альтернативу, ни даже постесняться в выражениях. Я считаю, что это оскорбление.
ijsgaus
12.04.2018 21:50Я согласен с коллегой, то что сейчас происходит с ООП семейством языков — это медленный конец. Но Ваше восприятие парадигм — напрягает. Дело в том, что все ошибки ООП языков, о которых вы пишите, совершенно не связаны с МАТЕМАТИЧЕСКИМ ОТСУТСТВИЕМ теории. К сожалению, это действительно личные предпочтения их авторов. Но и ваш концепт, к сожалению, на мой взгляд, неполноценен, как раз из за полного отсутсвия мат теории. Все же идеи забытого и спрятанного Хаскеля, много лет шедшего рядом, но по другому, с ВЕЛИКОЛЕПНОЙ математикой и доказательностью — хороший пример именно основательного научного труда, на который нужно и следует опираться. И прежде всего на теорию категорий.
Moriline Автор
12.04.2018 22:15Спасибо за комментарий!
Но я хотел бы уточнить что не только математической теории, а нет научной теории. Потому как математика не до конца сможет смоделировать предметную область(хоть без неё никуда не деться ни в мире, ни в науке) с её поведением и состоянием.0xd34df00d
13.04.2018 07:25Потому как математика не до конца сможет смоделировать предметную область(хоть без неё никуда не деться ни в мире, ни в науке) с её поведением и состоянием.
Я бы посмотрел, как вы научно моделируете что-нибудь без математики.Moriline Автор
13.04.2018 08:23Я не утверждал что без математики моделирование может обойтись. Я сказал что с её помощью моделирование и происходит. Видите разницу? Другими словами: чистая математика — не может смоделировать предм. область потому что в этой области есть состояния. А у математики состояния нет. Надеюсь понятно объяснил.
0xd34df00d
13.04.2018 18:57Значит, я не так понял ваш предыдущий комментарий, увы.
Другими словами: чистая математика — не может смоделировать предм. область потому что в этой области есть состояния. А у математики состояния нет.
Состояние можно рассматривать как функцию из множества нужной мощности в множество допустимых значений параметров системы.
В конце концов, термин «фазовое пространство» вам что-нибудь говорит?
geher
12.04.2018 21:53Могу предположить, что когда вводили понятие объекта — за основу приняли то, что видели вокруг себя — человека и животных. И в этом была главная ошибка которая позже вырастет до огромных размеров! Таким образом, возможно, появилось наследование(предок-потомок и связь между ними объясняется наследованием, но как быть с другими объектами в мире?
Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов. И предок-потомок тут скорее со стороны деревьев (не живых, а вполне математических) появились, поскольку классификация в ООП обычно строится как дерево (множественное наследование несколько "портит" "деревянную" картинку, но отношения предок-потомок сохраняются).
И что значит само определение слова «наследование» в реальном мире? Кровь и ДНК? Азотистые основания?).
Определение слова "наследование" в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.
Как остальные термины, а именно абстракция, инкапсуляция и полиморфизм, относятся именно к ООП?
Это инструменты для построения системы классификации объектов, т.е. инструменты для написания ОО программы. Можно и без них, но с ними легче как-то, чем без каких бы то ни было инструментов. Туда же можно отнести интерфейсы, сообщения, события и прочие средства реализации взаимодействия между объектами в соответствии с построенной моделью предметной области.
Moriline Автор
12.04.2018 22:09Спасибо большое за комментарий!
1. «Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов.» — Раскройте поподробнее эту тему, пожалуйста, в свете термина "наследование" и принципа подстановки Лисков.
2. «Определение слова „наследование“ в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.» — А как быть с наукой и научным определением? Я же указал ДНК и азотистые основания! И примеры приводил про горы для кого? Какие такие «ценности» и «признаки»? Мне прямо сюда ссылки дать или сами найдёте и почитаете что такое наследование?geher
13.04.2018 13:26- Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).
Упомянутый принцип подстановки всего лишь требует, чтобы поведение объекта подкласса не противоречило поведению, описанному в базовом классе. - Никакой особой науки тут нет. Есть всего лишь средства описания модели предметной области, приближенные к средствам естественного языка, чтобы программист мог "сказать" компьютеру, что он хочет смоделировать.
Отчасти это напоминает набор инструментов некоего мастера, который должен сделать, например, ремонт в квартире. Никакого научного обоснования того, какой именно инструмент и какие именно материалы мастер выберет для ремонта, быть не может.
Он выберет удобный вариант для себя, позволяющий реализовать хотелки заказчика.
В частности для задачи сверления дырки в стене он может выбирать из большого списка инструментов (дрель, ударная дрель, дрель-шуруповерт, перфоратор) опираясь на такие субъективные оценки, как удобство, или случайные, как, например, пропадание напряжения в розетке и наличия в аккумуляторном исполнении только дрели-шуруповерта.
А вот при планировании ремонта мастер может озадачмться вполне научно обоснованными вопросами на тему вроде "выдержит ли балка вес" или "какое сечение должен иметь провод, чтобы не расплавился от нагрузки" (понятно, что он не будет проводить изысканий сам, а воспользуеься готовыми ответами). Туда же могут относиться решения в плане выбора цветовой гаммы (если оно не противоречит хотелкам заказчика).
CrazyFizik
14.04.2018 03:39Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).
А вот смотрите, а что мешает вместо наследования использовать наборы общих компонентов? Компонент написан один раз, а используется во многих классах. 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
13.04.2018 10:05Каждый сам для себя выбирает определение ООП.
Можно рассматривать объекты как исполнители контрактов.
Контракт (интерфейс, АТД) — способ взаимодействия с объектом. (Абстракция)
Нам не важно, как устроен объект, главное, что он исполняет контракт. (Инкапсуляция)
Если есть два разных объекта, исполняющих один контракт, то нам не обязательно различать их. (Полиморфизм)
Тогда обычное наследование — это наследование контрактов и их реализации.
Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.geher
13.04.2018 13:51Каждый сам для себя выбирает определение ООП.
У всех этих определений есть общая часть — моделирование предметной области в виде набора взаимодействующих объектов.
Тогда обычное наследование — это наследование контрактов и их реализации.
Это уже детали. Главное, что наследуется нечто общее для подклассов, которое и описано в базовом классе.
Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.
А это не вопрос ООП, а вопрос построения классификации в рамках модели.
Если более общий класс описывает реализацию, то наследуется реализация. Если только контракт, то наследуется только контракт. Что мы в базовый класс поместили, то и наследуется.
visirok
12.04.2018 22:14Так вышло, что я немного знаю автора лично. Сначала он с поразительной быстротой подготавливал и публиковал обьёмные куски кода в комментариях к одной из моей статей. А в другой статье заметил пару досадных опечаток и через личку написал мне о них. Я был инициатором разгора. Разговор получился долгим, интересным и полным острых дискуссий.
Это я пишу к тому, чтобы заверить читателей в том, что автор осень крепкий профессионал с большим опытом работы в разного типа проектов.
Как я понимаю, там то и накопилась у него та боль, которую он выплеснул в этой статье.
Тем не менее, Уважаемые Критики и Уважаемый Автор, давайте стараться уважать мнение друг-друга, даже если мы с ним и не согласны.
Я тоже не согласен с многими тезисами автора. К сожалению, на Хабре отсутствует возможность «расщепить» статью на отдельные тезисы и структурно обсуждать их по-отдельности. (А кстати, кто-нибудь знает что-нибудь подобное на других форумных площадках?). Поэтому я свои комментарии к отдельным тезисам буду делать в виде отдельных комментариев.
rg_software
13.04.2018 08:40+1Честно говоря, я вот думал вставить пару мыслей, но потом обратил внимание на откровенно хамскую манеру общения и решил, что ну его, я не мазохист. Интересно, как можно иметь большой опыт работы с таким подходом к диалогу? Он с роботами что ли имеет дело только?
visirok
13.04.2018 10:18Я не знаю состав команды автора.
Но я Вас понимаю. К сожалению, автор в своём стиле общения не одинок. Это какая-то печалящая меня мода последних лет.
Я, например, знаю хорошо одного коллегу, с высоким уровнем культуры и интересного собеседника, который почему-то считает, что это здорово писать Email в лексике пятикласника с добавлением профессиональных терминов.
Ещё я раньше слушал подкаст Радио-Т. Ведущим не отнять профессионализма, да и темы интересные. Но я понял, что хамская манера разговора, пренебрежительные оценки чужих мнений и достижений, нецензурная лексика — это не моё. И перестал их слушать.
Боюсь, что автор потерял не только Вас в качестве комментатора.
Inobelar
12.04.2018 22:36Если исключить из ЯП (Язык Программирования) возможность наследования, статические методы и атрибуты, абстрактные классы, то в проекте код станет минимум на 10-20 процентов меньше.
Не могу согласится (как закоренелый c++-вик). В качестве простого примера, посоветую посмотреть на Go — там отсутствуют шаблоны/генерики, и это порождает огромное дублирование кода (boilerplate и "церемонию").
Moriline Автор
12.04.2018 22:39Спасибо за комментарий. Но не могу согласиться — этот самый код просто выносится в отдельный класс(или объект) и по мере необходимости вызывается. Если Вам не сложно — приведите примеры дублирования и как это выглядит на 2 языках. Я потом покажу как можно это сделать по другому.
geher
13.04.2018 14:12Просто придется перейти от иерархической классификации к выделению общего в самостоятельный класс и включению соответствующего поля в классы, которым нужно это общее.
Это позволяет решить некоторые проблемы разработки ценой ухода от интуитивно более понятной иерархической классификации.
SedovDP
12.04.2018 22:40+1Думаю, вы слишком буквально понимаете термины «объект» и «наследование».
ООП — это скорее стремление к классификации, типизации и определению подмножеств. Которые обладают схожими или одинаковыми свойствами и методами. Классы объектов подобны классам, отрядам и семействам в биологии. И такие же несовершенные. Как любая классификация.
К тому же, объект может вообще не быть физической сущностью. Например государство, организация, вид науки или искусства.
Сам метод ООП неидеальный. Так как мы пытаемся создать идеальную модель неидеального мира. Какбы написать идеальную инструкцию для исполнителя.
Языков же в реальном мире такое же множество, как и в программировании. Профессиональный язык хирурга отличается от языка портного или сапожника. Хотя они работают похожими инструментами, производят похожие операции — результат работы разный.
P. S. Ничего личного. Когда публикуете статьи на серьёзные научные темы, желательно соблюдать правила пунктуации и орфографии.Moriline Автор
12.04.2018 22:49Спасибо за комментарий.
А как по другому понимать ООП? Каждый сейчас в комментариях ООП понимает по своему и поэтому лепят от себя такие выверты и логические несуразицы, что волосы встают дыбом. Введение науки в программирование и определение терминов, с теориями ( и доказательствами), гипотезами приведёт к тому что мы знаем что Земля круглая со спутниками на орбите, а не верим, что она плоская и вокруг летают розовые единороги.
«Профессиональный язык хирурга отличается от языка портного или сапожника.» — У них то и задачи разные и ПОЭТОМУ и отличается!
«К тому же, объект может вообще не быть физической сущностью.» — Неверно. Такого с точки зрения науки не может быть — это или физическая сущность или это просто некая абстракция.lair
12.04.2018 22:52Ну так абстракция — это и есть тот объект, который не физическая сущность.
Moriline Автор
12.04.2018 23:42Никак не успокоитесь? Может хватит нести бред? Абстракция — это результат мышления и обобщения после наблюдения за какими-то свойствами реальных объектов и выделения из них существенных определений и признаков. А объект — это всегда физ. сущность.
lair
12.04.2018 23:47А объект — это всегда физ. сущность.
Только в рамках какой-то специфической терминологической системы, которой, возможно, пользуетесь вы, но не пользуюсь я (и не пользуется вся наука). Вот вам классическое определение: "Объект — философская категория, выражающая нечто, на что направлена практическая или познавательная деятельность субъекта (наблюдателя)". Философская категория — это не физическая сущность.
Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями) говорить, что объект — всегда физическая сущность? Если пользоваться этим определением, то в программировани объектов просто нет (и не может быть).
Moriline Автор
13.04.2018 00:331. «но не пользуюсь я (и не пользуется вся наука). Вот вам классическое определение». А как же другие определения? Даю ссылку — читайте все определения чуть ниже и не обманывайте ни меня ни других.
2. «Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями)» — Вы издеваетесь? Читайте что такое программирование в книге Китова которую я привел и не занимайтесь выдумыванием бреда.Moriline Автор
13.04.2018 00:40АВМ — тоже нематериальная сущность? И перфокарта тоже? Учите историю.
lair
13.04.2018 00:43Перфоркарта — это не программа (точно так же, как книга — это не повесть). Что касается АВМ — да, это прекрасно, но неактуально. Если хотите, я оговорюсь: подавляющее большинство современного программирования оперирует нематериальными сущностями.
lair
13.04.2018 00:42А как же другие определения?
А вот так. Я уже сказал вам: определения существуют только в рамках терминологической системы, и в разных терминологических системах они могут не совпадать. Нет никаких оснований считать, что выбранная вами терминологическая система правильнее, чем любая другая.
Даю ссылку — читайте все определения чуть ниже и не обманывайте ни меня ни других.
Так там как раз прекрасно видно, что далеко не все определения сводятся к физической сущности, так что вы только подтверждаете мой тезис.
Читайте что такое программирование в книге Китова которую я привел
А почему я должен считать эту книгу авторитетным источником?
(заметим в скобках, что определения программирования я там не нашел. Но вот вам случайная цитата: "Программирование состоит из двух основных этапов: составления логической схемы программы [...] и составления
программы". И программа, и логическая ее схема — нематериальные сущности. Если вы, конечно, не считаете программой ее запись...)Moriline Автор
13.04.2018 01:051. «А вот так. Я уже сказал вам: определения существуют только в рамках терминологической системы, и в разных терминологических системах они могут не совпадать.» — Поразительный ответ! У меня научное и материальное определение объекта, а у Вас философское. Удачи Вам в программировании с таким подходом!
2. «А почему я должен считать эту книгу авторитетным источником?» — Не считайте. Вам это не нужно. Вы же понятия не имеете кто это такой и чем авторитетен по сравнению с другими.
3. «так что вы только подтверждаете мой тезис» — Не манипулируйте! Я не подтверждал ваш тезис. Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.
4. «И программа, и логическая ее схема — нематериальные сущности» — Да прекратите бред нести?! А хранятся они где? А что из себя представляют?
Вы же даже не понимаете какой бред сами же несёте!
Так по-вашему программирование сводится только к написанию алгоритма? А дальше-то что происходит? Подскажу — 0 и 1. А это что такое знаете? Как они становятся материальными и главное где?lair
13.04.2018 01:16У меня научное и материальное определение объекта
"Научное"? Согласно какому критерию научности?
Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.
Это не делает ваш термин более правильным, чем мой.
Да прекратите бред нести?! А хранятся они где? А что из себя представляют?
А какое это имеет значение? Когда я строю алгоритм, я оперирую именно нематериальными объектами, и их последующее физическое представление в виде электронов и/или электромагнитных полей меня волнует мало.
Так по-вашему программирование сводится только к написанию алгоритма?
Нет, программирование сводится к созданию компьютерной программы (я не хочу сейчас вдаваться в развернутый спор "программирование 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").
Moriline Автор
13.04.2018 00:49-1АВМ — тоже нематериальная сущность? И перфокарта тоже? Учите историю.
0xd34df00d
13.04.2018 07:29Абстракция — это результат мышления и обобщения после наблюдения за какими-то свойствами реальных объектов и выделения из них существенных определений и признаков.
Наблюдение за какими реальными объектами и сущностями привело к такой абстракции, как, например, изоморфизм Карри-Говарда? Арифметика кардиналов? Арифметика ординалов?Moriline Автор
13.04.2018 09:36"" — над числами. Как и вся база математики. Здесь же написано: «Порядковые числа были введены Георгом Кантором в 1883 году как способ описания бесконечных последовательностей, а также классификации множеств, обладающих определенной упорядоченной структурой.[1] Он случайно открыл порядковые числа, работая над задачей, связанной с тригонометрическими рядами. » Основой математики(и геометрии) является число. Все остальные абстракции лишь следствие попыток объяснить окружающий мир. Начиная с круга и треугольника(станет потом геометрией и тригонометрией), множествами и точкой с прямой(которая потом станет декартовой системой координат). Надеюсь понятно объяснил.
EvilBlueBeaver
13.04.2018 10:50У нас числа стали внезапно реальными объектами? Покажите мне, пожалуйста, как выглядит 2 в реальном мире.
Moriline Автор
13.04.2018 11:45Они ими и были: 2 любых предмета. 2 руки или ноги. Имеется ввиду что число — это количество каких-либо физических объектов. Не убедил? Может это поможет: «Число? — основное понятие математики, используемое для количественной характеристики, сравнения, нумерации объектов и их частей.»?
EvilBlueBeaver
13.04.2018 11:51Число — это абстрактное понятие, а не реальный объект. 2 руки — это 2 руки, а не число 2. Щупая 2 руки вместо одной, вы будете щупать все так же руки, а не число 2.
Больше того скажу, в Полинезии существуют народы, которые не знают данной абстракции. У них натурально для каждого существительного есть отдельные слова для разного количества. То есть отдельное слово для одной овцы, отдельное слово для двух овец. Аналогично с деревьями. И они не находят общих признаков у двух овец и двух деревьев.Moriline Автор
13.04.2018 11:56Там же: «Понятие числа возникло в глубокой древности из практической потребности людей и усложнялось в процессе развития человечества. Область человеческой деятельности расширялась и соответственно, возрастала потребность в количественном описании и исследовании. Сначала понятие числа определялось теми потребностями счёта и измерения, которые возникали в практической деятельности человека, всё более впоследствии усложняясь. Позже число становится основным понятием математики, и потребности этой науки определяют дальнейшее развитие этого понятия.» И дальше можете прочитать. Так что это говорит о народах Полинезии? Другими словами число — это количественная характеристика объектов. Вы как живой объект в количестве 1 штуки существуете и Вас можно посчитать и выразить в виде особого символа, верно?
EvilBlueBeaver
13.04.2018 12:02Еще раз. Есть народы, у которых нет этой абстракции. То есть 2 дерева физически существуют, а числа 2 нет. Да и в вашей же цитате написано, что число — это понятие.
Следуя вашей логике слово — это тоже реальный объект, потому что в той или иной форме он существует у всех народов?Moriline Автор
13.04.2018 12:15«Следуя вашей логике слово — это тоже реальный объект». Нет. Это не реальный объект, только если не воспринимать его как звуковые колебания.
lair
13.04.2018 14:09… означает ли это, что слово — вообще не объект, поскольку, как вы утверждаете, объекты бывают только физическими сущностями?
lair
13.04.2018 12:11Эм, прямо в процитированном вами определении сказано "число — [...] понятие". Понятие — не "реальный объект" никаким образом, это понятие.
PashaNedved
13.04.2018 12:52Это не отменяет того, что оно существует.
lair
13.04.2018 13:02+1Понятие "два" — существует, с этим никто не спорит. А реального объекта "два" — не существует.
PashaNedved
13.04.2018 13:18-1Как же не реальный? Вот я его вижу «два», «2». Я наблюдаю за этим объектом, и если я не сошел с ума, то он реален.
EvilBlueBeaver
13.04.2018 13:27Вы вообще отличаете абстракцию от реального объекта? Для какого-то китайца «два» — это непонятные закорючки, но с понятием 2 он, очевидно, знаком.
PashaNedved
13.04.2018 14:00-2Если есть абстракция, то есть и реальный объект. Абстрактных объектов не существует.
EvilBlueBeaver
13.04.2018 14:04Откуда такой замечательный вывод? Математика вообще по своей сути набор различных абстракций, причем далеко не всем из них удается сопоставить реальные объекты. Если вы уйдете чуть дальше арифметики — вы это поймете.
lair
13.04.2018 13:27"Реальный" в значении "материальный". Извините, если ввел вас в заблуждение неточной формулировкой.
PashaNedved
13.04.2018 12:44Выглядит точно также, как в вашем комментарии.
EvilBlueBeaver
13.04.2018 13:03+1То есть 2 — это кучка пикселей на мониторе? Соответственно на бумаге 2 — это другое 2? А если я скажу 2 вслух — это будет третье?
PashaNedved
13.04.2018 13:19-1Наверное, этого будет один и тот же объект.
mayorovp
13.04.2018 13:24+1Кучка пикселей на мониторе и набор звуковых колебаний обладают очевидно различными физическими характеристиками, а потому один физическим объектом не могут быть ну никак.
PashaNedved
13.04.2018 13:38Это если их рассматривать, как кучку пикселей и звуковых колебаний. Я же смотрю на это, как на исчисление.
mayorovp
13.04.2018 13:50+1Исчисление — это что-то абстрактное. А защищаемый сейчас вами автор статьи, напомню, запретил объектам быть абстрактными.
PashaNedved
13.04.2018 14:21Исчисление — это что-то абстрактное
Да, но «2» уже не абстрактное, но обобщенное.
Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.EvilBlueBeaver
13.04.2018 14:26Окей, а число Пи абстрактное? Если нет — покажите его в реальном мире.
PashaNedved
13.04.2018 14:38-1Куда вас понесло? Число пи — это не тоже самое, что и 3,14…
EvilBlueBeaver
13.04.2018 14:43А что же тогда пи и какой реальный объект по типу «два — это две руки» ему можно сопоставить?
PashaNedved
13.04.2018 15:06От вас одни вопросы, в том числе и провокационные… Давайте теперь я задам вопрос или несколько, почему вы считаете, что «2» не реальный объект?
EvilBlueBeaver
13.04.2018 15:20Потому что все, что вы описывали, не является именно числом 2. Нет физического объекта — который является числом 2.
Если взять пример с двумя руками — тут все очевидно, как были руки, так и остались, отдельного физического объекта 2 не появилось.
Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.PashaNedved
13.04.2018 16:02Потому что все, что вы описывали, не является именно числом 2.
Но «два» и «2» можно рассматривать как равнозначные?
Нет физического объекта — который является числом 2.
Значит теперь уже физического… а раньше было реального.
Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.
К двум яблокам на столе можно прибавить 3 груши, чтобы получилось 5 фруктов.EvilBlueBeaver
13.04.2018 16:20+1Но «два» и «2» можно рассматривать как равнозначные?
Только в рамках русского языка. Тому, кто не знает русский язык, понятие 2 может быть знакомо, а вот слово «два» нет. Более того, ему и цифра 2 может быть незнакома, а до двух сосчитать он сможет. Но я уже выше писал, что существуют народы, которые и этого не смогут.
Значит теперь уже физического… а раньше было реального.
Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?
И даже если вам не нравится термин «физический», то и реального объекта «2» не появилось, появилась другая рука.
К двум яблокам на столе можно прибавить 3 груши, чтобы получилось 5 фруктов.
Как из 5 фруктов выделить непосредственнофизическийреальный объект «5»? Но вообще хорошо, что тут вы сами двигаетесь в сторону абстракции. Если прибавить 2 грузовика к 3 стаканам сока, то 5 чего получится?PashaNedved
13.04.2018 18:34-1Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?
А вы считали, что это синонимы?
Как из 5 фруктов выделить непосредственно физическийреальный объект «5»?
Зачем его выделять?
Если прибавить 2 грузовика к 3 стаканам сока, то 5 чего получится?
5 абсурдов! :)
Есть такой фильм «Роковое число 23», главный герой повсюду наблюдал число 23. Он считал предметы и получалось 23, складывал числа — получалось 23, число 23 было везде.
23 было объектом его воображения. Он абстрагировался от всего конкретного и ему не важно было чего там 23, его волновало только 23.
SedovDP
13.04.2018 17:46А если 2 яблока умножить на 3 груши?
Получится 6 фруктов?PashaNedved
13.04.2018 18:41Я так не умею! :(
Но ведь не было никаких яблок и груш, вернее они не являлись объектами наблюдения, были только фрукты их мы и складывали.
0xd34df00d
13.04.2018 19:04А кстати, фрукт — это объект или абстракция?
PashaNedved
13.04.2018 19:32Это смотря с какой стороны посмотреть, одно не противоречит другому. Так как пришлось обобщить груши и яблоки до фруктов, значит абстракция. В дальнейшем фрукт можно рассматривать, как конкретный объект.
0xd34df00d
13.04.2018 19:40Можно пример ситуации, когда фрукт — конкретный объект? Особенно хотелось бы иметь возможность осязать этот конкретный объект в этой ситуации.
PashaNedved
13.04.2018 20:23В чем подкол-то? :) Возьмите с прилавка в супермаркете любой фрукт — вот и конкретный объект.
0xd34df00d
13.04.2018 20:38Я пошёл в супермаркет и взял с прилавка любой фрукт, он с красной кожурой, размером с кулак и довольно твёрдый. Я правильно понимаю, что фрукт — это яблоко? И когда вы выше пишете, что вы складываете три яблока с двумя апельсинами и получаете пять фруктов, то вы получаете пять яблок?
PashaNedved
13.04.2018 20:42Все не так, я выше давал поясняющий комментарий
Но ведь не было никаких яблок и груш, вернее они не являлись объектами наблюдения, были только фрукты их мы и складывали.
0xd34df00d
13.04.2018 20:44Я не могу представить ситуацию, когда есть только фрукты. Обычно всё же есть конкретные яблоки, груши и прочие подобные вещи (которые, кстати, тоже в известном смысле абстракция).
PashaNedved
13.04.2018 21:50В 90-х с лотков продавали фрукты или овощи взвешивая все в одном пакете, если цена за килограмм была одинаковая. Не повсеместно конечно, но и не сказать чтобы это было редкостью.
geher
13.04.2018 23:07Не фрукт — конкретный объект, а конкретный объект — фрукт.
Называя конкретный объект фруктом мы просто его относим тем самым к классу фруктов.
Так что фрукт в мире яблок и прочих апельсинов — это все-таки абстракция, слово.
С другой стороны, фрукт — это конкретный нематериальный объект (да-да, абстракции могут быть объектами, если они рассматриваются в пространстве абстракций, и для них вводятся новые абстракции, чтобы классифицировать эти абстракции-объекты) — слово русского языка (заимствованное, но все же).
lair
13.04.2018 14:32Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.
То есть вы тоже считаете, что объект может быть только физической сущностью (и, следовательно, число 2 — не объект)?
PashaNedved
13.04.2018 14:52-1Я не придерживаюсь ни этого мнения ни противоположного. По моему слишком обобщенный вопрос, чтобы дать на него правильный ответ или составить мнение близкое к истине.
lair
13.04.2018 14:54Я не придерживаюсь ни этого мнения ни противоположного.
Тогда, извините, но вы не можете говорить, что ваше мнение с автором совпало, потому что вы не придерживаетесь мнения, которого придерживается автор.
По моему слишком обобщенный вопрос, чтобы дать на него правильный ответ
Да нет, это очень простой вопрос, ответ на который уже неоднократно озвучен в разных терминологических системах.
PashaNedved
13.04.2018 15:18-2Тогда, извините, но вы не можете говорить, что ваше мнение с автором совпало, потому что вы не придерживаетесь мнения, которого придерживается автор.
Ну значит не совпало. Или совпало… Это не имеет большого значения. Я не пытаюсь защищать автора статьи — это имело значение в том комментарии.
SedovDP
13.04.2018 17:32Упрощенный пример.
Определим класс: КоммерческаяФирма.
Создадим экземпляр класса: Фирма (ООО, LTD)
У объекта Фирма свойства: счет, обороты по счету, учередители, директор, место регистрации, фактический адрес и т. д. И методы: получить деньги, перечислить деньги, отгрузить товар, принять заказы и т. п.
Объект Фирма может взаимодействовать с другими объектами фирмами, банками, людьми.
Является ли при этом Фирма физическим объектом?
Moriline Автор
13.04.2018 17:59-1Спасибо за комментарий.
С точки зрения науки и реальности Фирма не является физическим объектом.
С точки зрения программирования Фирма является объектом.
visirok
12.04.2018 22:41Немного истории. С чего всё началось? Сначала было ....
Это очень интересная тема. Существуют обьёмные и очень интересных книги по истории, например, паровозов. В них рассматривается эволюция отдельных блоков, их разновидности и т.д. А вот об отдельных аспектах программирования, например истории баз данных, я не встречал.
Я лично убеждён, что прогресс популярных языков программирования примерно до 90-х годов определялся в основном развитием теории и практики построения компилчторов. Я думаю также, что С# был первым языком, когда вначале была собрана командв признанных на тот момент специалистов, которые не бросились в спорах писать первый вариант компилятора, а довольно долго подготавливали спецификацию для первой версии языка.
До сих пор создание совсем новых языков дело ужасно трудоёмкое и определяется базой накопленных знаний и умений.
Другими словами, при создании языков сначала появлялись технические возможности, а потом для них придумывались красивые интерпретации. Например — фактическое прикрепление функций к стркутурам в С назвали Обьектом. А могли бы назвать Атомом. На эту тему, кстати, есть байка, что закрепившийся в UML термин Актер на самом деле следствие ошибки переводчика со шведского. Эта штука должна называться Роль.
visirok
12.04.2018 23:38Если абстрагироваться от некоторых спорных тезисов и порой не очень научных формулировок, то в сухом остатке получается, что автор пытается призвать подумать над Универсальным Языком Программирования (УЯП), который будет способен моделировать всё в мире. Но попытка создать Универсальный Язык Моделирования (UML) уже предпринималась. Попытка была весьма серьёзная и привела к серьёзным результатам.
Может вместо создания нового УЯП стоит подумать как применить UML, например xUML (Executable UML)?lair
12.04.2018 23:49Если абстрагироваться от [...] не очень научных формулировок
Это в посте, который призывает к научному подходу? Ну то есть абстрагироваться от самой сути поста?
автор пытается призвать подумать над Универсальным Языком Программирования (УЯП), который будет способен моделировать всё в мире.
Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
visirok
13.04.2018 14:41Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
Тогда уж пойти ещё глубже и попытаться понять, чем различаются моделирование и программирование. А Вы как думаете?geher
13.04.2018 14:50Моделирование — это часть процесса программирования.
Написание программы на ЯП — описание модели для компьютера, чтобы тот ее просчитал.
При этом следует понимать, что модель, которую строит для себя программист, не обязана быть всеобъемлющей. Она должна содержать в себе ровно ту часть предметной области, которая необходима для решения конкретной задачи.
lair
13.04.2018 14:53Моделирование — построение модели.
Программирование — построение программы (снова, я избегаю спора "программирование vs разработка").
Программа может включать в себя модель (и обычно включает), но (а) не вся программа есть модель и (б) модель не обязательно является целью программы.
Аналогично, модель может быть исполнимой, но не обязана быть таковой.
Таким образом, мы имеем две различных деятельности, которые в какой-то своей части пересекаются, но имеют и непересекающиеся области.
visirok
13.04.2018 17:23Я думаю, при программировании важно различать три класса моделей:
1) «Формальную» или «официальную» модель предметной области. Иногда эти модели описаны в книгах, статьях, документах.
2) «Приватную» модель предметной области в голове программиста. Она отличается от первой модели по многим параметрам. По полноте, структуре и «природе» (из чего состоит). На самом деле про эту модель можно мало что сказать конкретного, кроме того что они субьективно существуют и «кристаллизируются» в процессе написания программы.
3) Модель программы (или системы) которая может быть формально отражена в докуметации, получена из кода или просто возникает в голове всякого, кто должен программу писать, расширять, тестировать и т.д.lair
13.04.2018 17:27А зачем, бишь? Нет, понятно, что "порядок и учет", и некоторые доценты очень любят классификации, но какой в этом практический смысл?
И, главное, какое это имеет отношение к обсуждению?
visirok
13.04.2018 17:38Вы отличались удивительной выдержкой и культурой ведения дискуссии в своих комментариях к этому посту. Не понижайте планку. Я — не доцент. Хотя и не воспринимаю это как обиду :-)
А к обсуждению это имеет вот какое отношение. Ваша фраза:
Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации? Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?
Как мне представляется, выплеснутая автором боль и происходит из этой дилемы.lair
13.04.2018 17:41Я — не доцент.
А я и не про вас. Это один из моих научных руководителей, на тот момент времени как раз доцент, говорил такое про себя каждый раз, когда вводил нам очередную классификацию чего-нибудь по новому признаку.
А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации?
Нет. Он должен по возможности хорошо выражать намерения программиста.
Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?
Программисту так или иначе придется подгонять свои ментальные модели под тот инструментарий, которым он пользуется.
Как мне представляется, выплеснутая автором боль и происходит из этой дилемы.
Как мне представляется, "эта дилемма" не имеет никакого отношения к "научности" программирования.
visirok
13.04.2018 18:10Не сцелью придраться к словам, а с целью точнее понять Вашу позицию. Кавычки в последнем предложении важны?
Я правильно Вас понял, что Вы не считаете, что названная дилема существует, а также не считаете что в программировании возможна научность (научный подход?)lair
13.04.2018 18:17Нет, вы неправильно меня поняли.
Я считаю, что в программировании есть проблема несоответствия языка, используемого программистом, тому, что программист хочет выразить на этом языке — однако я не уверен, что эта проблема имеет отношение к ментальной модели программиста (в частном понимании ментальной модели как ментальной модели домена).
Я не имею мнения по поводу "научности" в программировании, потому что я пока не услышал разумного определения, что же такое "научный подход" применительно к программированию.
visirok
13.04.2018 18:37С моей точки зрения прогресс майнстримовых языков программирования как раз и мотивировался желанием «поднять их уровень» от битов до нынешних Java/C#/Scala/Kotlin и т.д. Мне посчастливилось этот прогресс пережить/перепробовать.
Но неудолетворённость нынешним состоянием остаётся. Проблему хочется решать. Делать это можно по-разному.
Можно как алхимики пробовать и за счёт эмпирических правил и озарений всё же двигаться вперёд.
А можно по-научному. Но и тут без озарений не обойтись, похоже.
Научный подход применительно к программированию не должен сильно отличаться от подходов в других областях.lair
13.04.2018 18:38А можно по-научному.
Это как? Конкретно?
Научный подход применительно к программированию не должен сильно отличаться от подходов в других областях.
В каких "других областях"? Что такое "научный подход" в пошиве одежды?
visirok
13.04.2018 21:57Что такое «научный подход» в пошиве одежды?
Ну например для начала могу подарить Вам и всем дочитавшим до этого места два способа стать миллиордером уже к осени, занимаясь пошивом… дамских джинс.
Способ первый. Я не специалист по дамским джинсам, но как я понимаю, сейчас модно показывть голые щиколотки. А до этого было модно показывать самый нижний позвонок. А ещё — коленки сквозь искусственные прорехи.
Так вот — научитесь предугадывать, что будет нравиться дамам ближайшей осенью, свяжитесь с производителями и станете миллиардером.
Способ второй: Представте себе. Приходит дама в магазин, видит модный фасон джинс. Меряет — меряет, а потом говорит разочарованно продавцу — эти жмут внизу, а эти вверху, потому никакие не куплю. А продавец ей говорит: а Вы зайдите в вон ту кабинку, там Вас сканер отсканирует, а завтра приходите за джинсами. Только это будет стоить дополнительно X процентов.
Придумайте технологию — и разбогатеете.
Но вряд ли кто-нибудь к осени эти задачи решит. Но решат, я думаю. И непременно с помощью научного подхода.
Какие основные шаги:
1) точно сформуриловать проблемы/цели
2) построить адекватную модель предметной области с релевантными обьектами, релевантными состояниями, взаимосвязями, параметрами воздействия и функциями действия.
3) поиск решения на уровне модели и проверка решений на практике.
Конкретно по первому сценарию. Что значит физиологически, что джинсы нравятся? Это зависит от времени суток, национальности, культурного уровня, возвраста?
Можно функцию «нравится» оцифровать? Можно её интерполировать/экстраполировать?
И т.д.
Убедил?
lair
13.04.2018 23:11Убедил?
Нет. Я не вижу в вашем описании ничего научного. Вы можете построить объективный способ опровергнуть ту или иную гипотезу про "что такое джинсы нравятся"?
(при этом, что характерно, ненаучные способы "предугадывать, что будет нравиться" — а, точнее, формировать спрос — есть, и это ровно то, чем занимаются модельеры)
visirok
14.04.2018 00:02Я не вижу в вашем описании ничего научного.
Разумеется за несколько минут нельзя серьёзно сформулировать план действий в рамках научного подхода. В моём экспромте я попытался показать, что научный подход при пошиве одежды возможен. Так же как и при разработке программы управления складом.
Другое дело, есть ли у нас на это время и деньги в нашей суетной жизни.
Вы можете построить объективный способ опровергнуть ту или иную гипотезу про «что такое джинсы нравятся»?
Насчёт обьективного способа вопрос очень сложный. Не возмусь. Но примерно понятно, как такие гипотезы проверять статистически. Но одно дело примерно представлять, а другое — профессионально провести. Для этого нужна помощь профессионалов.
Попытки эмпирически, по-наитию формировать спрос действительно постоянно предпринимаются. Но успех, как я понимаю, как у алхимиков. То есть как в лотерее.lair
14.04.2018 00:19В моём экспромте я попытался показать, что научный подход при пошиве одежды возможен.
Но вам это не удалось. Вы привели совершенно обывательские подходы, которые к науке как таковой никакого отношения не имеют.
По большому счету, ровно то же самое, что произошло с автором поста, просто у него — в программировании, а у вас — в пошиве одежды.
Начинать-то надо с определения, что такое "научный подход".
Попытки эмпирически, по-наитию формировать спрос действительно постоянно предпринимаются. Но успех, как я понимаю, как у алхимиков. То есть как в лотерее.
Это какая-то очень выигрышная лотерея, вы не находите?
visirok
14.04.2018 10:39Но вам это не удалось.
Ну это Вы в полемическом запале. К сожалению, сам я в этой жизни уже этим вопросом вряд ли буду заниматься. Но я ожидаю, уже скоро мы услышим о прорывах в обоих описанных направлениях (прогнозирование моды и автоматизация индувидуального пошива одежды). И науки при этом потребуется много.
Начинать-то надо с определения, что такое «научный подход».
Меня устраивает определение из Википедии. Правда, если посмотреть ту же статью на других языках, детали сильно отличаются. Это определение я брал за основу.
Это какая-то очень выигрышная лотерея, вы не находите?
Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды. Наши программисткие боли — сладкий сон по сравнению с ними.lair
14.04.2018 10:53Но я ожидаю, уже скоро мы услышим о прорывах в обоих описанных направлениях (прогнозирование моды и автоматизация индувидуального пошива одежды).
Понимаете ли, автоматизация индпошива — это не научный подход, точно так же, как не является научным подходом станок, который режет доску на куски заданного размера. Это просто… автоматизация.
А прогнозирование моды — вы вообще понимаете, что мода создается, а не меняется сама по себе?
Меня устраивает определение из Википедии.
Ну так по этому определению научного подхода в пошиве одежды быть не может, потому что (а) нет научного сообщества и (б) невыполнимо требование объективности.
Собственно, в программировании тоже есть проблемы с объективностью.
Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды.
Вам "попадалась статья", а я с некоторыми знаком лично (причем как и дизайнерами, так и с теми, кто шьет).
Moriline Автор
13.04.2018 11:18Спасибо за комментарий. Что-то подобное как xUML уже сделали — Дракон. Там есть и схемы и алгоритмы.
visirok
13.04.2018 14:37Насколько я понимаю, Дракон недоступен широкой публике и ограничен русскоязычным синтаксисом. Так или иначе, xUML или Дракон — почему не отталкиваться от подобного подхода, взяв за основу используемые там понятия? А вдруг окажется, что всё уже изобретено?
Druu
13.04.2018 03:59> И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
ЗЫ: автор, хотелось бы узнать, ты TaPL (http://newstar.rinet.ru/~goga/tapl/tapl-toc.html) осилил?
pankraty
13.04.2018 06:58Они своим словоблудием продвигают в массы только нужные им идеи, не заботясь ни о теории, ни о доказательствах
Полностью согласен! Взять хотя бы
В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
Moriline Автор
13.04.2018 08:57Здесь я говорю что в итоге низкоуровневый язык должен быть один(имея ввиду его синтаксис), но ниже обсуждаются другие варианты. Если есть сомнения то посмотрите стандарты SQL
akryukov
13.04.2018 09:11После ознакомления со стандартами SQL, можно приступить к ознакомлению vendor-specific особенностей каждой конкретной СУБД. Например LIMIT в стандарте отсутствует, т.к. противоречит реляционной теории, но при этом реализован у большинства вендоров.
В итоге получается, что SQL вроде бы один и тот же, а на самом деле их несколько десятков.Moriline Автор
13.04.2018 09:17Здесь я об этом и говорю. И в случае с LIMIT — это и есть некая надстройка или дополнительное расширение к стандарту. Неужели прямо десятки реализаций?
akryukov
13.04.2018 09:36Можете сами оценить в списке на википедии.
Если учесть, что СУБД постоянно дорабатываются, то в каждой новой версии появляются новые надстройки. Так можно насчитать уже и сотню-другую диалектов SQL.
Благодаря такому многообразию инструментов, становится возможно выбрать тот, который удовлетворяет конкретным ограничениям конкретного проекта.
lair
13.04.2018 12:12Здесь я говорю что в итоге низкоуровневый язык должен быть один(имея ввиду его синтаксис)
Нет, вы там говорите, что вообще язык должен быть один.
MaxxONE
13.04.2018 08:40Вы говорите о важности научного подхода, и вместе с тем навязываете свои жутко субъективные представления о программировании. Это же прямо противоположные вещи. Все равно что заявить о внедрении научного подхода на государственном уровне, и потому всем гражданам немедленно следует записаться в церковь Летающего Макаронного Монстра. Не надо так.
Moriline Автор
13.04.2018 09:12«Вы говорите о важности научного подхода, и вместе с тем навязываете свои жутко субъективные представления о программировании.» — приведите пример субъективизма в статье. В комментариях эти моменты не обсуждались?
MaxxONE
13.04.2018 12:38+1У вас нет науки в статье. Есть лишь софистика. Вы предлагаете новую парадигму программирования, основываясь на сомнительных предпосылках.
Можно было бы взять в качестве исходных фактов другие высказывания, звучащие столь же научно, и плясать уже от них, с иными результатами. Все эти факты из химии и физики (сильно упрощенные, и к тому же верные лишь отчасти) — на каком основании именно их вы приняли за постулаты своей теории? Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?
Далее, от исходных данных вы сразу же перешли к положениям своей теории. Как вы пришли к этим выводам? Вот вы пишете:
Приняв за основу изложенные факты и данные, проанализировав свойства и поведение элементов, их взаимодействие и процессы между ними
— где этот анализ, где вот это всё? Я из тех же самых положений за день могу родить с десяток столь же блестящих подходов к программированию. И, к сожалению, столь же сомнительных.
Наука — это не то, что звучит научно. Это не аргументация фразами из учебника. Это не то, что у вас в статье написано — у вас пример псевдонаучной статьи. У меня, честно говоря, возникают ассоциации с творчеством разных фриков — от физики/химии/etc.
Я вижу, что вы нормально относитесь к критике. Или пытаетесь, по крайней мере. Я бы хотел дать вам конструктива. Но трудно в рамках комментариев всё расписать, поэтому я ограничусь одним советом: почитайте о настоящей науке. Почитайте Фейнмана. Прочтите Гарри Поттер и методы рационального мышления — вот эту книгу я настоятельно рекомендую. Прочтите, хотя бы последнюю, до того, как писать следующую публикацию. Это все, что я могу вам сказать, не ввязываясь в полемику.Moriline Автор
13.04.2018 17:24Спасибо за комментарий. Дайте ответ на один лишь вопрос:
1. «Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?»
Разве физика и химия не описывают вселенную?MaxxONE
13.04.2018 18:59+1Я говорил не об этих науках в целом, а о ваших исходных фактах, которые вы выдернули из этих наук. И я говорил не о том, что эти факты не описывают вселенную, а о том, что они не полно ее описывают.
И дело-то вообще не в этом. Я пытался найти причинно следственную связь между вашими предпосылками и выводами. И не нашел.Moriline Автор
13.04.2018 19:11Большое спасибо! Значит я плохо написал статью и недостаточно точно и понятно выразил свои мысли и сделал несколько ошибок и недочётов, не указал причинно-следственные связи между фактами и утверждениями и конечным выводом.
MaxxONE
13.04.2018 19:21Дело-то не столько в этих, по сути, технических моментах. Дело, кмк, в вашем подходе к предмету изучения. Серьезно, начните с литературы, которую я посоветовал. Она, по сути, художественная, и прочитается легко — но при этом даст богатейшую пищу для размышлений. После неё вы намного лучше поймете, почему вашу статью приняли в штыки. И поймете, в каком направлении стоит двигаться дальше, в плане выработки научного подхода.
akryukov
13.04.2018 09:16Любопытно наблюдать, что статей "Умные мысли, часть 1" на хабре сильно больше, чем статей "Умные мысли, часть 2". Причем в комментариях к статье 1 автор довольно часто обещает развернуть свои мысли в статье №2 или даже написать целый цикл статей.
Deosis
13.04.2018 09:48Довольно странное впечатление от статьи.
- Вы ссылаетесь на математику, физику и химию как на пример точных наук. Но при этом не учитываете, что даже там были ошибочные теории.
Например, теория о теплороде в физике.
Или механика Ньютона, которой до сих пор пользуются, хотя она немного "не точна". - Наука в большинстве своем занимается предсказаниями: при заданных начальных условиях будет определенный результат.
Ваши же предположения очень спорны.
- Исключение абстракций, наоборот, может увеличить размер кода. Потому что, если у вас 10 типов объектов, то вам понадобится 10 типов списков конкретных объектов. Для каждого типа списка объектов придется писать почти одинаковый код.
- Антипаттерны вредны вообще, но на размер кода они влияют слабо. Сервис-локатор убирает много кода для предоставления зависимости там, где она нужна.
- Язык APL, на нем программы могут быть ощутимо короче, но понятнее от этого они не становятся.
- В принципах собраны как требования к языку, так и к стилю написания программ.
Последний особенно противоречив. Если ваш воображаемый язык заставит следовать этому принципу, то как вы будете разрешать конфликт, в котором у меня все работает, а у коллеги не запускается/компилируется, только потому, что у меня монитор стоит вертикально?
Moriline Автор
13.04.2018 10:30Спасибо за развернутый комментарий!
1. «Вы ссылаетесь на математику, физику и химию как на пример точных наук.» — Действительно, были разные теории и некоторые из них были ошибочные, и будут ещё в будущем другие — и все они будут пытаться объяснить происходящие вокруг процессы и явления. А как это наука сейчас делает? С помощью научного метода(и это большое достижение!) чтобы избежать ложных подходов при доказательствах и появлению псевдонауки.
2. «Наука в большинстве своем занимается предсказаниями: при заданных начальных условиях будет определенный результат.» — Не совсем верно. Научная теория может или обязана делать предсказания. И об этом я буду писать во второй части. 1 и 2 пункты я буду доказывать на примерах кода. 3 пункт — Вы полностью правы. Ведь это просто вопрос синтаксиса и реализации именно языка.
3. «В принципах собраны как требования к языку, так и к стилю написания программ.» — Справедливо замечено.
Еще нет «моего» языка и я даже не упоминал о его реализации.
4. «Если ваш воображаемый язык заставит следовать этому принципу, то как вы будете разрешать конфликт, в котором у меня все работает, а у коллеги не запускается/компилируется, только потому, что у меня монитор стоит вертикально?» — я не понял вопроса. При чем здесь монитор? Можете раскрыть вопрос?
- Вы ссылаетесь на математику, физику и химию как на пример точных наук. Но при этом не учитываете, что даже там были ошибочные теории.
klvov
13.04.2018 10:34Вау, место для философских дискуссий. Меня вот тоже в компьютерной науке больше интересует не та часть, котороая про О большое и оптимизацию алгоритмов, а та, которая про лингвистику. И я тоже, как и автор, искренне считаю, что назначение ЯП — это помочь выразить программисту то, что он хочет от компьютера в краткой и понятной форме. Другое дело, у меня есть стойкое ощущение, что процесс построения ЯП не формализуется, и математику сюда тащить бесполезно. То есть процесс создания дизайна ЯП — это творческий процесс, сродни сочинению музыки (мне так кажется).
Очень важная концепция — то, что в лингвистике называется гипотезой Сепира-Уорфа, она примерно состоит в том, что язык, которым мы пользуемся, является инструментом для мышления, и сама его структура оказывает влияние на то, что мы в принципе можем подумать. Многие программисты знают это на опыте (попробуйте на Haskell написать что-нибудь, если до этого писали только на процедурных, если не верите).
Ну а на практике, мне кажется, постепенно будет все двигаться в сторону языково-ориентированного программирования, то есть конструирования DSL под конкретную область, и дальше оно там может прижиться, как SQL, или там постепенно приживаться (как XML, который потом довольно скоро переизобрели как JSON).0xd34df00d
13.04.2018 19:16Другое дело, у меня есть стойкое ощущение, что процесс построения ЯП не формализуется, и математику сюда тащить бесполезно. То есть процесс создания дизайна ЯП — это творческий процесс, сродни сочинению музыки (мне так кажется).
Почему? См. теория типов.
HomunCulus
13.04.2018 11:06+1Эффект Даннинга-Крюгера во всей красе помноженный на хамство. Автор смешал все в кучу, декларативное с императивным. На любые вопросы, тыкает прочитайте определение. Схоластика в 21 веке. При чем о философии науки даже и не слышал :) про математику, абстракции, языки программирования и прочее даже говорить не хочется. Хочется развидеть.
Что правильнее Лямбда исчисление Черча, машины Тьюринга, или вообще циклические теги? Очень мило, если бы не хамство, выглядели попытки натянуть математические концепты на «химические элементы»
горшочек не вари.
lurkmore.net/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%9E%D0%A1
является совокупностью бредово-казённо-абсурдных высказываний наподобие:
Процессор Пентиум — это логическое устройство. Любое действие процессора определяется логикой этого процесса.
Горлов А. В.
vs.
Факты:
1. Всё в окружающем мире состоит из мельчайших неделимых химических элементов и поэтому за основу главного объекта необходимо брать именно химический элемент обладающий множеством моделей поведения.
Vlad_fox
13.04.2018 13:35статье место не в «песочнице», а в «спам» или «прокрастинация». Нечего таком у взрослому и состоявшемуся ноучному автору делать в песочнице.
oam2oam
13.04.2018 16:02Мне после прочтения всех комментариев (и своих тоже :) пришло в голову простое соображение — как же так получилось, что языки программирования строго научные есть, а автор искренне считает (и видимо с ним все согласны), что их нет. Ну то есть я так полагаю (возможно и неправильно), что научное программирование опирается на какую-либо научную теорию. Так вот — язык пролог опирается на метод резолюций, а язык Gallina (COQ) на исчисление высказываний и позволяет синтезировать программы (ага, на ocaml!) прямо из построенного доказательства…
Moriline Автор
13.04.2018 17:16Спасибо за комментарий. Язык пролог действительно опирается на этот метод. Но что из себя этот метод представляет? Научную теорию или метод доказательства теорем через поиск противоречий, то есть набор логических правил?
oam2oam
13.04.2018 18:33ну уж Gallina — то точно является способом записи научной теории и даже выбрана в качестве инструмента для записи новой
теории всегоматематики! Что же касается пролога — это никак не метод доказательства теорем, а вполне живой и развивающийся язык программирования (да, да, с веб-сервероми блек-джеком, графическим интерфесом и многим другим ...). Но тут я не могу сказать, что вы понимаете под научной теорией? Является ли булева алгебра таковой? Или исчисления высказываний недостаточно? Или… в общем, тут я ничего не могу сказать, пока мы не выясним, что такое научная теория и чем она отличается от ненаучной или от не теории…Moriline Автор
13.04.2018 19:04«Что же касается пролога — это никак не метод доказательства теорем, а вполне живой и развивающийся язык программирования» — я не за пролог говорил, а за метод на котором он основан. Вот цитата: «Язык пролог действительно опирается на этот метод. Но что из себя этот метод представляет?» Научная теория — это система понятий, законов и принципов, наиболее полно описывающая структуру предмета исследования.(ссылка, структура и функции теории). Булева алгебра не теория. Это скорее набор аксиом и операций применяемый ко множествам. а псевдонаука — это имитация под науку с целью её опорочить и выдать желаемое за действительное.
Moriline Автор
13.04.2018 18:07-1Особо впечатлительным и ранимым людям это лучше не смотреть и не читать: What's Wrong With Object-Oriented Programming? и Объектно ориентированное программирование в 2018
samsergey
13.04.2018 21:57+1Очень странное обсуждение! Целая статья о "научном программировании", 200 комментариев, жаркие споры и ни разу не прозвучали волшебные слова: "денотационная семантика", "аксиоматическая семантика", "изоморфизм Карри-Говарда", "формальная верификация". Зато есть "ООП", "ФП", "хочешь странного: Хаскель и всякие F#"… Неужели никому в этой дискуссии не интересно именно научное программирование, а не ваяние формочек?
picul
13.04.2018 22:08Интересно, вот только после всех 200 комментариев лично я так и не нашел определения «научного программирования».
0xd34df00d
13.04.2018 22:14+1Ну, вообще-то некоторые из этих слов вполне себе звучали. Равно как и возражения на тему процитированного вами высказывания о «странном».
samsergey
14.04.2018 00:50+1Я воспользовался поиском этих ключевых слов :) при заявленной теме они должны быть повсюду! Это красивая тема. И нет необходимости всем программистам в неё залезать, но мы все стоим на плечах тех, кто создает её уже лет пятьдесят.
0xd34df00d
14.04.2018 01:01Я бы тоже ожидал это увидеть, да прямо в статье, вместо слов про кураж, религиозное ослепление и всякие такие эмоции.
Druu
14.04.2018 09:50Дискурс же задается обсуждаемой статьей. А автор статьи не в курсе про эти ваши семантики с прости хоспаде изамарфизмами.
netch80
13.04.2018 22:36+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 пропущу, потому что связанные с ним проблемы хорошо обозначены и решаются. Что за «реакционные объекты», совсем не понял. Хотелось бы пояснений.
И, кстати: во всей статье только один пример положительно упомянутого имени — шумного агрессивного евангелиста с откровенно однобокими, зато громко рекламируемыми решениями. «Это ж-ж-ж неспроста».
Ждём следующих обещанных статей, но начало уже вызывает пессимизм.
vilgeforce
«Всё в окружающем мире состоит из мельчайших неделимых химических элементов» — как-то, мягко говоря, несовременно. Вам не кажется?
Moriline Автор
В чём именно «несовременность»? В наличии ещё более мелких частиц? Нейтронов, протонов и позитронов? А может кварков? Возможно, я не уточнил, что речь идет о химии и химических элементах, а не о квантовой физике? Дело в том, что учёные еще плохо ( не до конца изучили) знают модели их поведения и взаимодействия. И поэтому их брать за основу ещё рано. Возможно их очередь настанет через несколько десятков лет — вот тогда и поговорим.
vilgeforce
А взаимодействие химических элементов, получается, изучено хорошо и до конца?
Moriline Автор
Да. Входит в школьную программу химии. Я согласен, что открывают новые элементы и реакции, но базовые процессы изучены, я думаю, хорошо. Классификация и систематизация имеющихся на данный момент элементов я думаю сложилась в полноценную картину.
vilgeforce
Вы уже закрыли проекты типа Folding@home за ненадобностью? Нет — почитайте что-нибудь про современную химию. Насколько я помню, даже в неорганике находят что-то новое. Успехов в самообразовании.
Moriline Автор
Даю ссылку. Каким образом проект распред. вычислений относится к химии? Ну кроме моделирования и предсказания какой-то теории? Вот и докажите в отдельной статье в чём я не прав. Приведите свои доводы и доказательства своих слов. Расскажите в статье КАКИЕ новые законы, теории и типы или виды реакций были открыты в химии? А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.
picul
vilgeforce
Автор, научитесь читать что пишут про тот же фолдинг, чем они занимаются и какое отношение это имеет к химии. Потом подумайте об этом на фоне «базовые процессы изучены, я думаю, хорошо». Вот как научитесь читать — беритесь писать.