Comments 373
А то ваши выпады напоминают высказывания мнения которое никому не обломилось и ценности не имеет.А Ваша статья такие высказывания не напоминает?
Ну вообще программистразработчик не воспроизводит предметную область, а моделирует ее.
То есть выделяет значимые характеристики системы и описывает правила их изменения. Точность соответствия программной модели реальному миру зависит от задачи. Довольно часто углубляться до мельчайших частиц нет никакой необходимости.
Зачем реализовывать атомы и молекулы в программе по расчету заработной платы?
а вовсе не создающего объектную картину мира
Вообще первый объектный язык — SIMULA (SIMUlation LAnguage) был создан именно что для описания объектной картины мира и последующей её симуляции. Сам язык был создан для научно-исследовательских задач, а не для прикладных… потом уже всякие Страуструпы и Аланы Кейны переврали его, кто как мог :-)
в ней вообще есть только один корневой класс Object
А еще там есть примитивные типы: byte, short, int, long, char, float, double и boolean, которые живут сами по себе. Забудете про разницу между Long и long — наткнетесь на упаковку-распаковку.
Если уж быть последовательными, то операция сложения не принадлежит матрице, скорее уж она принадлежит какому-нибудь вычислителю…
Хз, наверное как посмотреть: математически для каждого множества определяется свой набор арифметических операций, порой с особыми правилами (например, умножение матриц), так что арифметические операции именно что являются свойствами множества, то бишь классов и типов по программерски
В другом подходе ОБЪЕКТ
Вот в этом то вся бяда. Нет точных определений, т.е. да, действительно, у ООП есть проблема с фундаментальным теоретическим обоснованием.
который на специализированном языке описывает предметную область
Вы наверное фанат декларативного программирования :-) Угадал? :-)
За синтезом программы я думаю будущее. Собственно кое-чего уже есть: Компиляторы и кодогенераторы.
С С++ да, грустно, недавно пытался прочитать драфт стандарта C++ 17...1600+ страниц текста… Расширенный стандарт Паскаля — 200 страниц, у Фортрана 2008 — 600+ (а ведь там есть куча встроенных математических операторов, которыми в других языках даже не пахнет).
Но что касается ООП… ну я хз. Проблема в терминологии, Вирт вон породил целую линейку языков: Модула, Оберон, где были модули, инкапсуляция и интерфейсы и он не считал шо это какое-то ООП — просто развитый модульный подход.
Что же касается конкретно объектов — ну я хз. Все равно удобнее все представлять набором каких-то независимых сущностей, имеющих свое поведение, возьмем например какую-нибудь САУ: там будет объект управления, который что-то получает на вход и как-то на это реагирует (а уж что там за код внутри объекта — это никого не касается, ибо инкапсуляция) и есть регулятор — тоже ведь объект: на вход получает ошибку рассогласования, а на выходе — сигнал управления для объекта управления.
И просто процедурами здесь не проканает, т.к., например,PID регулятор должен хранить интеграл ошибки, а еще помнить предыдущие отсчеты (шоб продифференцировать) и таких регуляторов системе будет дохрена и больше — так что пусть это будут объекты, которые хранят свои внутренние состояния и имеют свою логику поведения. Более того: Типов регуляторов будет много и каждый из них будет работать по своему. И просто их задекларировать не получиться: вся соль регуляторов и ОУ именно во внутренней логике (а она многообразна и ценность представляет именно конкретный алгоритм/формула, т.е. способ решения). А вот наследованию здесь уже будет не место: во-первых наследование ломает инкапсуляцию, во-вторых наследование усложняет сопровождение: мы не увидим в исходниках наследника свойства и методы родителя — придется всю цепочку изучать, в-третьих, само по себе наследование работает несколько тупо — оно всегда идет по принципу расширения, но реальное наследование (не только биологическая) — это вообще-то комбинация свойств родителя, ну и в-четвертых, если уровней наследования больше одного, то со временем классы становятся сильно хрупкими… Композиция компонентов и реализация интерфейсов — наше все :-)
Я вообще предлагаю смотреть на любую софтину именно как на систему автоматического управления: общая логика, что мы дёрнули штурвал самолета или ткнули мышкой в кнопку — не меняется. Тут же и вылезает более подходящее представление: Data Flow и Control Blocks которые сидят на этих потоках.
С Дженериками и шаблонами все несколько сложнее (но в итоге то сводится все просто к универсальным коллекциям, которых 3.5 штуки).
В общем тут проблема скорее всего в том, что слишком дофина наплодили в ООП всяких бредовых идей, а реально то многого то и не надо.
И кстати еще один момент. Доказательство и написание программы через вывод доказательства.
Проблема с доказательством в том, что их меньше чем практических проблем. Реально основная масса алгоритмов работают на эвристических приемах — никакого строго математического доказательства/обоснования для них нет или оно появляется куда позже чем сам алгоритм. А вот для чего уже есть заготовленные доказательства — уже давно реализованы во всяких стандартных библиотеках. Мы такую же ситуацию наблюдаем в физике — большая ее часть, чистая эмпирика, под которую потом подводили теорию, на основе которой что-то пытались предсказать, после чего на основе предсказаний получали новый практический опыт и так далее по кругу.
Т.е. со строгим формальным подходом мы столкнемся с параличом в ряде практических задач.
В свое время известный гуру программирования Эдсгер Вибе Дейкстра сказал:
«Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.» Сейчас в этом высказывании надо только заменить Бейсик на Java Script, и все станет актуальным.
Массовая профессия с низким порогом вхождения. Никому в голову не придет, что школьник или студент первого курса будет самостоятельно, скажем, рассчитывать аэродинамику крыла самолета, или проектировать сложный электронный прибор. Для этого надо закончить профильный институт, поработать в КБ под руководством наставника над реальными проектами. Плюс, в классической инженерной деятельности есть четкое разделение между проектом и изготовлением опытного образца. Передается документация с подписями, утверждениями и пр. Нормоконтроль и всякая другая бюрократия. Если конструктор ошибся и в цехе приходится дорабатывать кувалдой, то такой специалист долго не проработает. А в программировании второй этап сводится к компиляции, да и то не всегда.
Институтские преподаватели программирования вряд ли в массе своей сами специалисты в этой области.
Волосы встают дыбом при чтении здесь высказываний, что надо предъявить доказательства необходимости контроля типов и параметров процедур. Чудовищная деградация.
И таких языков больше сотни! А так быть не должно! В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
А почему не должно? Почему должно быть так мало языков?
Обьект — наименьшая неделимая сущность, также известная нам как химический элемент, имеющая множество свойств и множество моделей поведения реализуемые через методы. У объекта есть 2 типа методов: 1) для получения его свойств, 2) для изменения его состояния.
А теперь, значит, зададимся вопросами: что такое "свойство", что такое "состояние", что такое "поведение", и что такое "метод". А то у вас базовое определение прямо сразу опирается на неопределенные понятия.
Факты
Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.
В частности, даже формально "поэтому за основу главного объекта необходимо брать именно химический элемент" — это не факт, а вывод (и вывод спорный).
выделим несколько принципов:
… тоже ни на чем не основанных.
Иными словами, вы заявили, что пытаетесь применить науку, но в реальности все, что вы делаете — это (не очень успешно) придаете своим размышлениям наукообразие.
«А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод. Также как и наличие разных теорий может быть очень много, но правильная только одна.
«что такое „свойство“, что такое „состояние“,» — потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.
«Это не факты, а ваши утверждения, которые ничем не более обоснованы, чем другие утверждения в области программирования.» — Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.
«В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968
По итогу — если Вы не согласны, то докажите своё мнение.
Вот Вы и докажите, что приведенные мною факты таковыми не являются. В статье или в комментариях, а не высказывайте никому не нужное мнение и не разводите флуд.Бремя доказывания Ваших фактов лежит на Вас. Пока Вы их не доказали — они всего лишь флуд, а значит то, что флуд разводить начали Вы — это научно доказанный факт.
«А почему не должно? Почему должно быть так мало языков?» — потому что исходя из определения что «истина только одна» я и сделал такой вывод.
Ну ладно. Но почему 2 низкоуровневых, а не один? Почему 3 или 4, а не один? Почему это должны быть разные языки? Чем в вашей терминологии отличаются высокоуровневые языки от низкоуровневых?
потому что исходя из определения что «истина только одна» я и сделал такой вывод.
Почему-то идея об единственности истины никак не мешает существованию множества языков общения. Почему тогда для языков программирования должны быть другие правила?
Язык программирования — это инструмент, средство решение задачи. Вокруг нас много разных средств транспорта, много разных фотоаппаратов (и не просто разных моделей, а радикально конструктивно разных устройств), много фасонов одежды и много способов прикрепить что-нибудь к чему-нибудь. Так почему языков программирования должно быть 6, а не множество?
потому что это утверждает наука и экспериментальные наблюдения над элементами и ВСЕМИ объектами.
Подождите, что "это" утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше "базовое определение".
Вот Вы и докажите, что приведенные мною факты таковыми не являются.
И эти люди запрещают мне ковыряться в носу будут рассказывать про научный метод? Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?
«В частности, даже формально» — habrahabr.ru/post/353408/#comment_10751968
В комментарии по ссылке нет ничего, что превратило бы вывод "Всё [...] состоит из [...] и поэтому [...] необходимо брать именно [...]" в факт, за который вы это выдаете.
По итогу — если Вы не согласны, то докажите своё мнение.
Не, так не работает. Вы делаете утверждения, вы их и доказываете. Пока что вы не справились даже с вопросами к вашему первому "базовому определению" (могу повторить, если надо) и первому "факту". Какой смысл обсуждать остальное, если первичные посылки ложны?
«Язык программирования — это инструмент, средство решение задачи.» — У Вас неверное определение. Почитайте этот комментарий.
«Подождите, что „это“ утверждает наука? Я задал вопрос об определениях четырех понятий, которые входят в ваше „базовое определение“.» — поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки, потому как Вы, похоже, будете спрашивать меня и о том, что такое союз «и»!
«Бремя доказательства лежит на утверждающем; или вы никогда не слышали про чайник Рассела?» Я знаю на ком лежит бремя и знаю про чайник Рассела. То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?
Потому что назначение языков общения и языка программирования разные. Природа их возникновения разная и цель у них разная. Вот почему одних много, а других ДОЛЖНО быть мало!
Я готов согласиться, что из разных целей вытекают разные правила. Но почему языков программирования должно быть мало?
У Вас неверное определение. Почитайте этот комментарий.
А почему вдруг приведенное в этом комментарии определение более верное, чем мое?
поведение раз, поведение два, свойство, состояние и метод. Мне приходится приводить эти ссылки,
И эти ссылки согласованы с вашим определением объекта и не содержат неопределенных понятий? Нет и нет.
То есть мне нужно привести в пример научные статьи о том, что наш мир состоит из мельчайших неделимых частиц
Вам нужно привести обоснование ваших утверждений и выводов, потому что иначе они выглядят необоснованными.
наш мир состоит из мельчайших неделимых частиц потому как Вы это пропустили в школе?
Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так). Так что да, это тоже придется обосновывать. Но это, на самом деле, скучно — а интересно, почему объект в программировании обязан соотноситься с неделимой частицей в реальном мире.
2. «А почему вдруг приведенное в этом комментарии определение более верное, чем мое?» Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.
3. «Кстати, когда я учился в школе химические элементы не были неделимыми (и краткий экскурс в википедию говорит, что сейчас это тоже так)» — в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно! Читайте тут: Отношение понятий.
Потому что моё определение может ответить на ВСЕ вопросы о языке, а ваше нет.
Эм, нет. В частности, ваше определение языка не способно ответь на вопрос, почему языков должно быть мало.
в химии принято определять химический элемент как неделимую частицу состоящую из атомов. То есть химическими процессами элемент разложить на составляющие невозможно!
А почему нас должно интересовать определение из химии и ограничение на химические процессы?
2. А Вас и не интересует. И других разработчиков языков тоже. И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье. Почему нужно ограничение читайте в моих комментариях.
Потому что только один язык сможет решать задачи эффективнее других.
Вне зависимости от определения, это утверждение ошибочно (или, по крайней мере, недоказуемо).
Во-первых, даже для одной задачи наблюдаемо, что есть больше одного эффективного инструмента для ее решения (как-то: для задачи коммуникации между людьми существует более одного языка, для задачи сверления дыр в стене есть более одной дрели).
Во-вторых, есть более одной задачи, решаемой языком программирования, и эти задачи, очевидно, могут решаться разными языками с разной эффективностью; нет никакого способа показать, что есть один язык, решающий все задачи заведомо эффективнее других языков, включая специализированные.
эффективность переноса алгоритма в инструкции для исполнительного устройства у каждого человека одинаковы
Ну а это-то наблюдаемо ошибочно: разные люди по-разному реализуют один и тот же алгоритм даже на одном языке.
И что же в итоге получилось после введения абстракций, розовых пони и вакханалии в реализациях? Это Вы можете узнать пройдя по ссылкам в статье.
Однако нигде по ссылкам не будет объяснения, почему использование определения из химии предотвратило бы произошедшее.
Почему нужно ограничение читайте в моих комментариях.
Там нет объяснения, почему ограничение на химические процессы оправдано.
только один язык сможет решать задачи эффективнее других.
Еще, кстати, я не вижу способа формально это предположение опровергнуть, поэтому, согласно критерию Поппера, оно… ненаучно (по крайней мере, не является научной эмпирической теорией).
Потому что моё определение может ответить на ВСЕ вопросы о языке
Я, кстати, внезапно заметил, что, собственно, никакого определения языка вы не привели. Или я пропустил что-то?
Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат).
И тут:
2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
Тут правильнее сказать не «обеспечивать», а «транслировать» мыслительный процесс в машинные инструкции с помощью языка конечно.
Я не давал определения языка
Значит, ваше определение не может ответить на все вопросы, потому что его просто не существует.
Другими словами — язык не решает задач!
Почему же, решает. Он решает как минимум задачу выражения алгоритма для вычислительного устройства (и это не единственная задача).
Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
Как уже говорилось выше, понятие "эффективности" пока что объективно неизмеримо, и поэтому не имеет никакого преимущества перед настолько же субъективным понятием "удобства" (в значении "язык программирования удобен для программиста"). Поэтому я не вижу никаких оснований считать вашу формулировку ("[языки должны] эффективно транслировать мыслительный процесс человека в машинные инструкции") более правильной чем "[языки должны] быть удобным для их пользователей".
Также как и наличие разных теорий может быть очень много, но правильная только одна.
Неверно. Правильных теорий может быть много. просто у них будут свои области применимости.
Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.
Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.
Зато есть теории, обладающие достаточной предсказательной силой, чтобы быть успешно применимыми на практике. Что, кстати, доказывает, что языков программирования успешно может быть много.
Не может быть много правильных теорий. Приведённые Вами примеры говорят ровно о том, что ДО СИХ ПОР ЕДИНОЙ ПРАВИЛЬНОЙ ТЕОРИИ НЕТ.
Нет гарантированно истинных теорий.
Правильных много.
При этом теория является правильной только для тех задач, которые она позволяет решать с приемлемой точностью.
Кстати о плоской Земле, в задачах, когда кривизна поверхности не сильно сказывается на результате, она вполне себе принимается плоской (например, в задачах, связанных с прокладыванием маршрута).
Ту же ньютоновскую механику до сих пор более чем успешно применяют на практике, хотя она не согласуется с теорией относительности.
Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Свет рассматривают в зависимости от задачи как электромагнитную волну или как поток частиц. Тоже вполне успешно.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн. В каких-то условиях можно упростить вычисления и пренебречь некоторыми особенностями: чисто волновое описание является опять таки частным случаем: просто для того что бы нам рассчитать антенны, нам не нужно городить формулы из квантовой электродинамики, а вот для описания фотоэффекта чисто волновое представление уже не проканает.
Физика — она как Шрек, который как луковица :-) представляет из себя слои разных теорий разной степени приближенности к одной основной (пока неизвестной). Реально то теорий сейчас всего две — квантовая механика, да теория относительности, остальные можно рассматривать как их производные, да частные случаи и то, это только потому что КМ и ОТО не очень совместимы друг с другом.
Ньютоновская механика — частный случай СТО для малых скоростей. СТО — частный случай ОТО без учета гравитации.
Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.
Другой вопрос, что эта разница не превышает требуемую точность, но разница все равно есть.
Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным). В некоторых случаях оно даже прокатывало. Но по одному вопросу (вероятность повторного слияния и дальнейшее движение после слияния) не прокатило. Пришлось учитывать релятивистские спецэффекты.
Теория тут тоже одна и они [элементарные частицы] проявляют одновременно и свойства частиц, и свойства волн
Это уже третья теория, объединяющая наработки первых двух.
Но при решении большого класса задач учитывать в модели все сразу не надо. А потому откатываемся назад, к одной из двух старых теорий.
Ньютоновская механика не может быть частным случаем СТО, поскольку они дают разный результат даже на малых скоростях.
Угу изменение размеров из-за релятивистских эффектов велосипедиста будут на несколько порядков меньше ковалентного радиуса атома водорода и будут полностью замаскированы тепловыми флуктуациями — поправки преобразований Лоренца при малых скоростях становятся бесконечно малыми и стремятся к нулю, т.е. по-простому лишены какого-то физического смысла. Только софистики ради такие вещи можно обсуждать.
Все эти эффекты становятся более-менее измеримыми только на космических скоростях. Вот на изменения перигелия Меркурия — мы увидим расхождение с классической механикой, наблюдая как резвятся черепахи — даже физически замерить не сможем.
В ОТО и СТО классическая механика Ньютона является предельным частным случаем и справедлива для движения в относительно слабых гравитационных полях и при малых скоростях.
Кстати, не так давно пробегала новость, как ньютоновскую механику задействовали при моделировании поведения черных дыр (считать намного проще, а результат в силу большого размера лаптя ожидался адекватным).
Это наверное были какие-то неправильные СМИ у которых какие-то неправильные новости. Черные дыры — фича исключительно ОТО, ни в СТО, ни тем более классической механике такие объекты просто невозможно описать. Так шо я даже хз, че там можно намоделировать задействовав ньютоновскую механику… вероятно ничего
Вообще-то в ньютоновской теории тяготения черные дыры тоже вполне себе есть, и у них даже радиус совпадает с шварцшильдовским.
Физики заодно переопределили понятие частного случая?
Частный случай, это когда результат совпадает точно, а не когда погрешностью можно пренебречь или ее нельзя измерить.
А с черными дырами все намного проще. Моделировалось не то, что происходит в самой черной дыре, и даже не то, как происходит сам процесс слияния, а всего лишь то, как они перемещаются в пространстве, из чего оценивалась вероятность слияния.
И рассматривали черные дыры как просто очень тяжелые предметы. И они вели себя в рассматриваемых случаях в основном вполне по правилам ньютоновской механики с достаточно большой и заметной, но приемлемой для ученых погрешностью.
С первыми слияниями, как я понял, у них вполне сошлось. А вот с повторными не срослось. Пришлось задействовать более сложную теорию.
А почему не должно? Почему должно быть так мало языков?
А зачем их собственно много? Я еще понимаю ассемблер — он для каждого процессора свой нужен, хотя один фиг, все ассемблеры (по крайней мере для одного типа вычислительных машин) будут пересекаться друг с другом основным набором команд.
А вон у совсем брутальных хардварщиков языка вообще два — Verilog, да VHDL, да их производные и справляются как-то.
А для языков высокого уровня — действительно нет никакой фундаментальной причины плодиться и размножаться, кроме как различия платформ (а их не так уж и много). Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Собственно реально массово используемых действительно не так уж и много языков, а все современные языки происходят либо от Fortran'а и его прямых потомков: Algol и Basic, либо от более поздних независимых веток: APL, Lisp (точнее IPL), COMIT и Cobol (точнее FLOW-MATIC) — больше чойт на память и не приходит, либо их комбинации.
С точки зрения работы над ошибками и наличия строгого обоснования, самые подкованные это APL и Lisp — их приемы много куда проникли, но между тем я что-то не вижу орд программистов на Scheme (хотя именно на нем идет обучение в MIT) и Haskell со всякими F# (на Scala вроде как кто-то пишет)
А зачем их собственно много?
Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.
Т.е. все то многообразие что мы наблюдаем — просто разная степень кривизны реализации, да вкусовщина.
Ну так вкусовщина — это же совершенно валидный аргумент. До тех пор, пока одной из задач языка программирования будет передача намерения одного программиста другому программисту, выбор языка (и стиля письма) будет обусловлен в том числе и сугубо субъективными факторами.
Чтобы был выбор инструментов. И чтобы было легко опробовать новую идею.
Ну их все равно реально используемых не так много:
Любишь металл: 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++ с примерно одинаковой эффективностью (средняя температура по больнице).
Большое обилие языков все же скорее это результат процесса их эволюции.
Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?
Большое обилие языков все же скорее это результат процесса их эволюции.
… что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до "одного-двух" видов.
Нет, Вам никак не погубить ту романтику, что я испытываю к ЯП… ни с математикой, ни с химией и т.п. ничего подобного я не испытывал!) А что стало причиной гибели Вашей страсти, любопытно было бы услышать.
Вы же сами написали "Особо упоротые фундаменталисты придумали Функциональное Программирование основанное на математике", подразумевая рак, щуку и лебедя… может исключим тогда уж доконца однобокость восприятия, в перечеслении составляющих программирования.
"Меня муза посетила…" неужели не было никогда озарения после долгого периода мучений — Вы точно программист?)
Перечисленный список все равно явно длиннее, чем 3-4 языка, не правда ли?
Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.
… что, если проводить параллели с эволюцией в живой природе, наводит на мысли о саморегулируемости этого процесса. Почему-то никто не требует от природы сокращения разнообразия до «одного-двух» видов.
Ну кстати я такой фигней немного занимаюсь (только с другого бока) там на самом деле видовое разнообразие испытывает периода взрывного роста и обеднения. Ну а один вырвавшийся вперед вид начинает вытеснять остальные. Гхм, кролики и коты в Австралии — местная флора и фауна от них офигела. Тех же кроликов пытаются можно сказать биологическим оружием теперь истреблять.
Автор: CSIRO, CC BY 3.0, Ссылка
Но эт я отвлекся. Да, на самом деле я думаю развитие языков похоже на биологическую эволюцию.
Ну там все равно в итое C/C++, Жаба и дотНЕТ всепожирающие языки. Остальные — чисто нишевые и дополнительные.
А не важно, нишевые они или нет (хотя за определение некоторых языков как "нишевых" с вами многие бы и поспорили), важно, что они есть и у них есть применение (собственно, не бывает нишевых языков без соответствующей ниши), для которого они лучше других. Что лишний раз доказывает полезность существования многих языков.
Не, ну динамика, это когда можно невозбранно сложить строку с числом (например dynamic в шарпе это позволяет). А вы же в данном случае никаких операций к dyna применить не можете, то есть фактически моделируете подтипирование на экзистеншоналах (вполне статическое), так?
Нет. Оговорюсь, под «когда можно невозбранно сложить строку с числом» подразумевалось, что это запрещено статически (программа не скомпилируется). В питоне это запрещено, но динамически, в рантайме.
> О, как раз нет, и в этом принципиальное различие! На экзистеншиалах вы стираете исходный тип и в лучшем случае знаете, что значение реализует какой-нибудь тайпкласс. А тут у вас именно что динамика в питон-стиле
Но вы же не можете никаких операций к этому типу применить. То есть это аналог вполне статического Object из вполне статической джавы. В динамике вы должны иметь возможность применить к объекту любые операции (опять же — речь о статических проверках, в рантайме, конечно, операция может и не быть успешно выполнено, главное что компилятор вам даст написать такую программу).
И, более того:
> Я, увы, не могу паттерн-матчить на типах
Даже если бы могли — это не было бы динамикой все равно. В динамике проверок типов (при компиляции) в принципе нет и потому вам вообще матчить ничего не надо. Вы просто берете и применяете любую ф-ю к любому аргументу.
> И тут я уже как-то запутался, что есть статическая типизация, а что — динамическая.
Ну, общепринято, что когда типы проверяет компилятор до рантайма — это типизация статическая, а когда типы проверяются в рантайме — то это динамическая.
Ну тут типы проверяете вы в рантайме, а компилятор в компилтайме проверяет, что вы их проверяете в рантайме.
Ну это как в typescript, например. То есть статика :)
В случае динамики компилятор ничего не проверяет.
Почему? В том же питоне среда выполнения гарантирует наличие этих проверок «по построению»
Но она не проверяет их наличие. Они просто есть. Если бы их не было — никто не помешал бы программе скомпилироваться. В случае, например, тайпскрипта, если вы руками не напишете эту проверку, то программа не скомпилируется.
здесь вам именно что нужны типы, и вы именно что в рантайме будете проверять, что в одной Dyna лежит число, в другой — строка, и так далее.
Ну так это отличается чем-то от статических типов с подтипированием и occurrence typing? Я могу для dyna выполнить операцию без проверки? Именно эта возможность и определяет, динамика у вас или нет.
Тогда это динамика. Потому что скомпилируется все, что угодно.
> Я сходу вообще не вижу связи с этими двумя видами типизации.
ТАк а отличие-то в чем? Ну что можно написать в одной и нельзя в другой?
> Без динамической?
Да.
> Только не затрагивающую семантику этого типа
Ну вот. То есть у вас просто аналог типа Тор.
> В моей ментальной модели динамичность типизации определяется там, когда именно происходит проверка, при компиляции или при выполнении.
Ну вот ваш дина проверяется при компиляции. Именно компилятор проверяет, а не применяете ли вы к дина операции, которые нельзя применять к дина. Если бы он это не проверял (или проверка бы сводилась к тому, что применять можно все операции, что эффективно эквивалентно отсутствию проверки), то была бы динамика. Короче, если вы можете написать со своей дина какой-то код, который не скомпилируется из-за ошибки типов — то это явно не динамика.
А зачем их собственно много?
Но на самом деле, я просто считаю эту подмену вопроса некорректной. "Зачем много языков" — может быть и низачем, черт знает. "Должно быть мало языков" — э, почему вдруг внезапно? Из "низачем не надо много" никак не вытекает "должно быть мало".
Ну еще вкус и цвет, есть вот например люди, которые скобочки любят…
Но в итоге, даже если языков будет 10 конкурирующих между собой, то в своей основе они будут мало различаться. Собственно это мы сейчас это и наблюдаем: во все языки напихивают как можно больше самых разных парадигм программирования и технологий. Единственная проблема действительно в… эээ… в строгости определения понятия ООП и как меняются на него взгляды (опять таки — эволюция языков и подходов) и реализации.
Добавлю ещё что из низкоуровневых языков один будет для объектов, а второй для математических и научных вычислений. Но если статических возможностей у первого не будет, то от второго он будет мало чем отличаться — всего лишь другой синтаксис, более приближенный к научной терминологии.
Вы не находите, что вы противоречите себе же, в той части, где "должен быть один максимально эффективный язык"?
Взять хотя бы SQL с его стандартами — ну разве не красота?
Нет, не красота. После того, как попробуешь на этом "стандартном" языке порешать задачи из реальной жизни, любовь к стандарту резко пропадает.
Обнаучить процесс программирования — цель благая. Научным методом доказать правильность, эффективность и превосходство одной из парадигм — достойная цель.
Предлагаю начать с первого вопроса: "Что такое программирование?".
Боюсь, ответ будет почти там-же, где и определение "Искусственный интеллект".
Упрется все в "Интеллект".
Спрашивал в институте им. Бехтерева — пока молчат…
В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.Интересно, откуда такие цифры?
Факты:Относятся к реальному миру, а не к программированию.
несколько принципов:Похожи на смесь Coding Style Guide и какого-то очередного шаблона проектирования, которые вы так ненавидите.
Гипотеза:Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.
P. S. Почему в качестве ЯП для «доказательства гипотезы» выбрана Java? Она ведь полностью объектно-ориентирована, а судя по Вашей статье, хуже ООП может быть только ФП)
1. «Хотелось бы поинтересоваться, на основе чего был сделан вывод, что то, что вы называете «научным подходом», вообще кому либо нужно в программировании?» До определённого момента это было нужно и было доказано и обосновано логически, теоретически и экспериментально, а после нет. Почитайте ссылки которые я привел — хотя бы по-диагонали чтобы понять масштаб проблемы.
2. «Языки проектируются с двумя приоритетами: уметь решать поставленные перед ними задачи и быть удобными для их пользователей.» — Ни «перед ними», а перед человеком! А он уже с помощью алгоритмов и исполнителя(ЭВМ) эту проблему решает. Ни «быть удобными для их пользователей», а эффективно обеспечивать мыслительный процесс человека в машинные инструкции.
3. «Интересно, откуда такие цифры?» — habrahabr.ru/post/353408/#comment_10752012
4. «Относятся к реальному миру, а не к программированию.» — а чем занимается программирование Вы задумывались? Ведь программирование было ещё до ЭВМ и автоматов. Подумайте в эту сторону и в историю углубитесь.
5. «Основана на том, что в программировании самым лучшим кодом является самый короткий, а это не так.» — Вы невнимательно прочли. Вот оригинал: «3. Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять.» Не код, а объекты! Это большая разница.
2. Задача языка — предоставить удобный программисту инструментарий для решения задач. «Доказательства» и «объяснения» на каждом шагу — это не очень удобно.
3. Так если истина едина, зачем целых 6 языков?)
4. Программирование занимается симуляцией процессов в окружающей среде, потому что просчитывать каждый атом во Вселенной Вам никаких машин не хватит. И я нахожусь не в истории, а в реальности, и задачи решаю соответствующие. А про программирование до нашей эры ИМХО Вы написали не на тот ресурс.
5. Это все, что Вам удалось родить после простыни про научный подход и оскорбления признанных ученых?
Ну сколько же можно мучить парадигмы программирования. Тем более не предлагая альтернативы…
Я, как и многие тут, не увидел в вашем тексте ни намёка на «научное программирование», только лишь странные, ничем не подтверждённые, измышления, и яркое желание изнасиловать сложившиеся методики программирования.
Задавать вопрос «А зачем вам это вообще», наверно бессмысленно.
Потому задам другой: а с чего вы решили, что предлагаемый вами подход будет хоть кому-то полезен? Где ваше научное или маркетинговое исследование?
Сколько я знаю языков программирования и историй их создания — авторы почти всех (или даже совсем всех...) реально используемых языков при создании очередного ЯП руководствовались вполне конкретными целями и решали вполне конкретные проблемы. И ЯП становился популярным именно тогда, когда пользователи этого ЯП, сиречь программисты, ощущали оную пользу и всячески благодарили автора(ов).
Следуя реалиям жизни, вам стоит создать таки свой ЯП и представить его миру, выстоять под градом камней и затем уж получить заслуженные почести.
Ну или хотя бы, опишите и докажите теорию, согласно которой выбранные подход к ООП является наиболее эффективным по ряду критериев… Или хоть выведите и обоснуйте эти критерии, проранжируйте по ним существующие ЯП, сделайте выводы…
Да, кстати, приведённые вами примеры научного подхода ярко демонстрирую то, чего в вашем тексте нету…
И да, напоследок, про реальную жизнь: плохой программист напишет каку на любом, сколь угодно совершенном ЯП, а хороший пособен сделать конфетку на любом ЯП, которым он владеет. И как вы в эту реалию впихнёте превосходство вашего подхода — тоже интересный вопрос :).
ps
Истина одна, но она никому не нужна, потому правд много и именно ими пользуются живые люди. Почему так — почитайте философов…
2. «Задача языка — предоставить удобный программисту инструментарий для решения задач» — Опять Вы придумываете небылицы! «инструментарий» — это автомат, процессор, какой-либо механизм, IDE на худой конец. Вы не читаете что я уже писал про язык — «эффективно обеспечивать мыслительный процесс человека в машинные инструкции.» Другими словами — язык не решает задач! Задачи решает алгоритм, который выразили с помощью языка в инструкции к исполнительному устройству, и само исполнительное устройство(процессор, станок, автомат). Что здесь трудно понять? Почитайте что-нибудь для разнообразия прежде чем так выражаться.
3. Зачем?
4. «Программирование занимается симуляцией процессов в окружающей среде» — Я же Вам ответил и дал направление, но из-за лени Вы не потрудились ни изучить историю, ни напрячь мозг и начали выдавать сказки про симуляцию. Ада Лавлейс и Бэббидж тоже занималась симуляцией? Как Вам не стыдно такое даже печатать?
5. «оскорбления признанных ученых» — где я это сделал можете указать?
Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам. Как-то: развитой инструментарий, широкий набор готовых библиотек или компонентов (что тоже, де-факто, входит в понятие языка в моей терминологии), наличию разработчиков,…
:: Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять
Хотите я вам покажу большой объект, который будет легко понимать и читать. И сделаю вам код где много крохотных объектов, но вы замучаетесь пытаться понять что происходит? Конечно я не собираюсь этого делать — вопрос риторический и ответ на него очевиден.
Я склонен согласиться с теми, кто считает что язык (всю экосистему) выбирают под задачи и разнообразие языков это добро. Вот это мне быстрее и удобнее выразить на такой платформе, а вот это — на такой. И многообразие языков (экосистем) это хорошо. Хочешь ИИ — питон какой-нибудь, хочешь быстро и удобно написать веб приложение — .net (особенно core), SPA? Vue, React (js), хочешь то — Си, хочешь сё — с++,… f# и т.д. Каждая экосистема появилась не просто так. И я бы не отделял абстрактный в вакууме язык от того что он несет с собой. И, главное, почему это самое «несу с собой» появилось.
Дайте мне задачу — я объясню почему ее надо решать на выборе из таких-то платформ (языков)
Появление, скажем, .core позволяет мне легко и красиво за день делать то, что раньше я делал месяцами.
Включить мозг, читать очень много книг, лекций, статей, курсов, потом долго учиться применять самое умное из того что вы прочитали, придумывать свое и вы сможете писать отличный код на любом языке. И еще важный момент — не спать. Держать руку на пульсе. Но это не только у нас, айтишников. Ключевой момент — программированию надо серьезно учиться. Если вы умеете *программировать* — язык или платформа перестают быть важным моментом. Мне, например, не очень важно на чем писать (есть тонкие моменты, но это не для тут).
Боязнь множества языков от осознания что мы просто не успеваем за развитием. Посмотрите что творится в мире фронтенда. Это же какой-то ужас… Но надо понять что хороший программист это не знаток реакта. Хороший программист тот, кто понимает почему код надо организовывать так, а не иначе. Что надо писать тесты и это не лишнее время, а наоборот его сильная экономия, что… Поэтому надо перестать бояться, начать изучать паттерны, подходы, идеи. Изучить синтаксис — недолго. Изучить идею (зная основные тенденции) — тоже недолго. Узнать тонкости… тут зависит от разработчика, наличия «у кого спросить» и поставленных задач, но, опять же не все так страшно.
Прочитал Ваш пост по диагонали потому, что почти в каждой строчке есть спорный момент, так что если я вообще не понял суть — прошу извинить.
Как я и писал в статье — проблема в том что программисты спорят основываясь уже на реализации, а не на теории и науке. В этом большая разница! Грубо говоря в ЯП сейчас тихий ужас из-за описанной мною истории их создания. Если Вы начнёте мыслить с точки зрения основ программирования, его истории, задач и целей и каким образом именно наука, а не религия дало всё то, что нас сейчас окружает и какие подходы использовала, то признаете что рациональное зерно в этой статье всё таки есть. А лучше всего прочитать статью внимательно, походить по ссылкам, книгу почитать и комментарии мои и вдуматься в сказанное. Сделать это — большая и трудная работа, но она необходима. А терпением для этого мало кто может похвастаться.
1. «Язык не решает задач. Язык *подходит* для решения задач или нет. Он может подходить или не подходить по совершенно разным причинам.» — написано в этом комментарии.
2. «Хотите я вам покажу большой объект, который будет легко понимать и читать.» — Ответ действительно очевиден. «Если сильно захотеть — можно в космос полететь!». Только вот в науке и реальном мире сложное, по определению, не может быть проще простого.
2. Как Вы хотите, что бы кто-то понял Вашу точку зрения, если сами не способны понять чужую? Язык предоставляет средства для решения задачи — это значит, что он предоставляет семантические конструкции, которыми программист может выразить свои мысли. В императивном программировании это разные инструкции, которые со временем оформили в процедуры, которые со временем объединили с данными и назвали классами. В функциональном это функции, которые не используют каких-то состояний, а выдают результирующие значения только на основе своих аргументов. ( Примеры поверхностные, но, надеюсь, Вы понимаете, о чем я. ) Задача языка — сделать так, что бы программисту было удобно пользоваться этими средствами, которые язык предоставляет, а также что-бы эта легкость использования не повлияла на качество программы, которая на языке будет написана. Соответствие каким-то наукам — это очень второстепенная задача.
3. Это лучшая научная аргументация, которую Вы можете предоставить?
4. А, так значит «научный подход» — это выбросить компьютеры и работать на изобретениях 19-ого века? Или нет? Просто Вы так и не объяснили.
5. Например
чем ваши слова отличаются от слов религиозного фанатика-экстремиста сбежавшего из психбольницы?Это не совсем прямое оскорбление, но Вы смешали с грязью практически все парадигмы программирования ( над которыми работали эти самые ученые ), при этом не удосужились не аргументировать свою точку зрения, ни предложить альтернативу, ни даже постесняться в выражениях. Я считаю, что это оскорбление.
Но я хотел бы уточнить что не только математической теории, а нет научной теории. Потому как математика не до конца сможет смоделировать предметную область(хоть без неё никуда не деться ни в мире, ни в науке) с её поведением и состоянием.
Могу предположить, что когда вводили понятие объекта — за основу приняли то, что видели вокруг себя — человека и животных. И в этом была главная ошибка которая позже вырастет до огромных размеров! Таким образом, возможно, появилось наследование(предок-потомок и связь между ними объясняется наследованием, но как быть с другими объектами в мире?
Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов. И предок-потомок тут скорее со стороны деревьев (не живых, а вполне математических) появились, поскольку классификация в ООП обычно строится как дерево (множественное наследование несколько "портит" "деревянную" картинку, но отношения предок-потомок сохраняются).
И что значит само определение слова «наследование» в реальном мире? Кровь и ДНК? Азотистые основания?).
Определение слова "наследование" в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.
Как остальные термины, а именно абстракция, инкапсуляция и полиморфизм, относятся именно к ООП?
Это инструменты для построения системы классификации объектов, т.е. инструменты для написания ОО программы. Можно и без них, но с ними легче как-то, чем без каких бы то ни было инструментов. Туда же можно отнести интерфейсы, сообщения, события и прочие средства реализации взаимодействия между объектами в соответствии с построенной моделью предметной области.
1. «Наследование в ООП определяет вопросы классификации объектов, а не происхождение видов.» — Раскройте поподробнее эту тему, пожалуйста, в свете термина "наследование" и принципа подстановки Лисков.
2. «Определение слова „наследование“ в реальном мире многозначно. Это и передача ценностей от умершего, и получение признаков от родительских организмов, и общие признаки при построении классификации в ООП.» — А как быть с наукой и научным определением? Я же указал ДНК и азотистые основания! И примеры приводил про горы для кого? Какие такие «ценности» и «признаки»? Мне прямо сюда ссылки дать или сами найдёте и почитаете что такое наследование?
- Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).
Упомянутый принцип подстановки всего лишь требует, чтобы поведение объекта подкласса не противоречило поведению, описанному в базовом классе. - Никакой особой науки тут нет. Есть всего лишь средства описания модели предметной области, приближенные к средствам естественного языка, чтобы программист мог "сказать" компьютеру, что он хочет смоделировать.
Отчасти это напоминает набор инструментов некоего мастера, который должен сделать, например, ремонт в квартире. Никакого научного обоснования того, какой именно инструмент и какие именно материалы мастер выберет для ремонта, быть не может.
Он выберет удобный вариант для себя, позволяющий реализовать хотелки заказчика.
В частности для задачи сверления дырки в стене он может выбирать из большого списка инструментов (дрель, ударная дрель, дрель-шуруповерт, перфоратор) опираясь на такие субъективные оценки, как удобство, или случайные, как, например, пропадание напряжения в розетке и наличия в аккумуляторном исполнении только дрели-шуруповерта.
А вот при планировании ремонта мастер может озадачмться вполне научно обоснованными вопросами на тему вроде "выдержит ли балка вес" или "какое сечение должен иметь провод, чтобы не расплавился от нагрузки" (понятно, что он не будет проводить изысканий сам, а воспользуеься готовыми ответами). Туда же могут относиться решения в плане выбора цветовой гаммы (если оно не противоречит хотелкам заказчика).
Использование наследования в классификации объектов позволяет выделить наиболее общие детали внешнего интерфейса и внутреннего поведения группы объектов и реализовать их однократно в рамках базового класса и не описывая их повторно для подклассов. Также оно позволяет использовать любые объекты, относящиеся к унаследованным от базового классам (по сути подклассам базового класса), не зная о принадлежности объекта к конкретному подклассу (достаточно знания о принадлежности к базовому классу).
А вот смотрите, а что мешает вместо наследования использовать наборы общих компонентов? Компонент написан один раз, а используется во многих классах. Composition vs Inheritance, все дела.
Упомянутый принцип подстановки всего лишь требует, чтобы поведение объекта подкласса не противоречило поведению, описанному в базовом классе.
И тут мы пишем override или new…
Вот кстати lair где-то тут уже писал о терминологии: наследование, состояние и т.д. и т.п. Допустим у нас есть вот такой метод у родителя:
public int DoAdd(int adder)
{
return privateSelfVarible + adder;
}а у потомка:
public new int DoAdd(int adder)
{
return privateSelfVarible - adder;
}Я вот думаю, что поведение наследника изменилась, более того — оно стало противоречить методу родительского класса (было сложение, стало вычитание), а сигнатура метода осталась таже. Если думайте, что на практике так не бывает… ну я думаю, что Вы так не думайте :-)
Можно еще и new опустить и проинкрементировать счетчик предупреждений :-)
И когда я такое вижу, то думаю «А чем наследование от класса лучше реализации интерфейса/-ов?»
А вот смотрите, а что мешает вместо наследования использовать наборы общих компонентов? Компонент написан один раз, а используется во многих классах. Composition vs Inheritance, все дела.
Тут есть два момента. Решаемых, но все же.
Во-первых, мелкая логическая неувязка. Мы отходим от иерархической классификации, когда объекты подклассов одновременно относятся и к некоторому общему классу.
Например, имеем класс "окно". Имеем подклассы (классы, наследующие "окно") — "окно такое" и "окно сякое". При этом объекты обоих классов могут рассматриваться как объекты класса "окно".
При отсутствии наследования получаем пару независимых классов "окно такое" и "окно сякое", а для предотвращения дублирования кода еще и третий класс "что-то общее для всех окон".
Во-вторых, мы теряем возможность без лишних телодвижений автоматически получить от всех окон что-то, заложенное в общей части. Придется городить дополнительный код для того, чтобы класс использовал то, что ранее просто наследовалось.
Не то, чтобы это было серьезной проблемой, но оно есть.
Я вот думаю, что поведение наследника изменилась, более того — оно стало противоречить методу родительского класса
Такое противоречие обычно указывает на ошибку классификации, т.е. мы ввели в обобщающий класс что-то, на самом деле не являющееся общим для подклассов.
Каждый сам для себя выбирает определение ООП.
Можно рассматривать объекты как исполнители контрактов.
Контракт (интерфейс, АТД) — способ взаимодействия с объектом. (Абстракция)
Нам не важно, как устроен объект, главное, что он исполняет контракт. (Инкапсуляция)
Если есть два разных объекта, исполняющих один контракт, то нам не обязательно различать их. (Полиморфизм)
Тогда обычное наследование — это наследование контрактов и их реализации.
Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.
Каждый сам для себя выбирает определение ООП.
У всех этих определений есть общая часть — моделирование предметной области в виде набора взаимодействующих объектов.
Тогда обычное наследование — это наследование контрактов и их реализации.
Это уже детали. Главное, что наследуется нечто общее для подклассов, которое и описано в базовом классе.
Собственно, в ООП многим не нравится наследование реализации, так как фактически вместо одного изолированного типа появляется целая иерархия, изменять которую приходится целиком.
А это не вопрос ООП, а вопрос построения классификации в рамках модели.
Если более общий класс описывает реализацию, то наследуется реализация. Если только контракт, то наследуется только контракт. Что мы в базовый класс поместили, то и наследуется.
Это я пишу к тому, чтобы заверить читателей в том, что автор осень крепкий профессионал с большим опытом работы в разного типа проектов.
Как я понимаю, там то и накопилась у него та боль, которую он выплеснул в этой статье.
Тем не менее, Уважаемые Критики и Уважаемый Автор, давайте стараться уважать мнение друг-друга, даже если мы с ним и не согласны.
Я тоже не согласен с многими тезисами автора. К сожалению, на Хабре отсутствует возможность «расщепить» статью на отдельные тезисы и структурно обсуждать их по-отдельности. (А кстати, кто-нибудь знает что-нибудь подобное на других форумных площадках?). Поэтому я свои комментарии к отдельным тезисам буду делать в виде отдельных комментариев.
Но я Вас понимаю. К сожалению, автор в своём стиле общения не одинок. Это какая-то печалящая меня мода последних лет.
Я, например, знаю хорошо одного коллегу, с высоким уровнем культуры и интересного собеседника, который почему-то считает, что это здорово писать Email в лексике пятикласника с добавлением профессиональных терминов.
Ещё я раньше слушал подкаст Радио-Т. Ведущим не отнять профессионализма, да и темы интересные. Но я понял, что хамская манера разговора, пренебрежительные оценки чужих мнений и достижений, нецензурная лексика — это не моё. И перестал их слушать.
Боюсь, что автор потерял не только Вас в качестве комментатора.
Если исключить из ЯП (Язык Программирования) возможность наследования, статические методы и атрибуты, абстрактные классы, то в проекте код станет минимум на 10-20 процентов меньше.
Не могу согласится (как закоренелый c++-вик). В качестве простого примера, посоветую посмотреть на Go — там отсутствуют шаблоны/генерики, и это порождает огромное дублирование кода (boilerplate и "церемонию").
Просто придется перейти от иерархической классификации к выделению общего в самостоятельный класс и включению соответствующего поля в классы, которым нужно это общее.
Это позволяет решить некоторые проблемы разработки ценой ухода от интуитивно более понятной иерархической классификации.
И в большинстве случаев объем кода будет расти. Но это даст простоту в его анализе, использованию и пониманию, гибкости создания объектов и их изменения. И как заметил пользователь geher — нужно создавать отдельные классы для таких случаев, а не формировать предка в иерархии в виде абстрактного класса.
ООП — это скорее стремление к классификации, типизации и определению подмножеств. Которые обладают схожими или одинаковыми свойствами и методами. Классы объектов подобны классам, отрядам и семействам в биологии. И такие же несовершенные. Как любая классификация.
К тому же, объект может вообще не быть физической сущностью. Например государство, организация, вид науки или искусства.
Сам метод ООП неидеальный. Так как мы пытаемся создать идеальную модель неидеального мира. Какбы написать идеальную инструкцию для исполнителя.
Языков же в реальном мире такое же множество, как и в программировании. Профессиональный язык хирурга отличается от языка портного или сапожника. Хотя они работают похожими инструментами, производят похожие операции — результат работы разный.
P. S. Ничего личного. Когда публикуете статьи на серьёзные научные темы, желательно соблюдать правила пунктуации и орфографии.
А как по другому понимать ООП? Каждый сейчас в комментариях ООП понимает по своему и поэтому лепят от себя такие выверты и логические несуразицы, что волосы встают дыбом. Введение науки в программирование и определение терминов, с теориями ( и доказательствами), гипотезами приведёт к тому что мы знаем что Земля круглая со спутниками на орбите, а не верим, что она плоская и вокруг летают розовые единороги.
«Профессиональный язык хирурга отличается от языка портного или сапожника.» — У них то и задачи разные и ПОЭТОМУ и отличается!
«К тому же, объект может вообще не быть физической сущностью.» — Неверно. Такого с точки зрения науки не может быть — это или физическая сущность или это просто некая абстракция.
Ну так абстракция — это и есть тот объект, который не физическая сущность.
А объект — это всегда физ. сущность.
Только в рамках какой-то специфической терминологической системы, которой, возможно, пользуетесь вы, но не пользуюсь я (и не пользуется вся наука). Вот вам классическое определение: "Объект — философская категория, выражающая нечто, на что направлена практическая или познавательная деятельность субъекта (наблюдателя)". Философская категория — это не физическая сущность.
Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями) говорить, что объект — всегда физическая сущность? Если пользоваться этим определением, то в программировани объектов просто нет (и не может быть).
2. «Более того, вам не кажется смешным в рамках обсуждения программирования (которое заведомо оперирует нематериальными сущностями)» — Вы издеваетесь? Читайте что такое программирование в книге Китова которую я привел и не занимайтесь выдумыванием бреда.
А как же другие определения?
А вот так. Я уже сказал вам: определения существуют только в рамках терминологической системы, и в разных терминологических системах они могут не совпадать. Нет никаких оснований считать, что выбранная вами терминологическая система правильнее, чем любая другая.
Даю ссылку — читайте все определения чуть ниже и не обманывайте ни меня ни других.
Так там как раз прекрасно видно, что далеко не все определения сводятся к физической сущности, так что вы только подтверждаете мой тезис.
Читайте что такое программирование в книге Китова которую я привел
А почему я должен считать эту книгу авторитетным источником?
(заметим в скобках, что определения программирования я там не нашел. Но вот вам случайная цитата: "Программирование состоит из двух основных этапов: составления логической схемы программы [...] и составления
программы". И программа, и логическая ее схема — нематериальные сущности. Если вы, конечно, не считаете программой ее запись...)
2. «А почему я должен считать эту книгу авторитетным источником?» — Не считайте. Вам это не нужно. Вы же понятия не имеете кто это такой и чем авторитетен по сравнению с другими.
3. «так что вы только подтверждаете мой тезис» — Не манипулируйте! Я не подтверждал ваш тезис. Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.
4. «И программа, и логическая ее схема — нематериальные сущности» — Да прекратите бред нести?! А хранятся они где? А что из себя представляют?
Вы же даже не понимаете какой бред сами же несёте!
Так по-вашему программирование сводится только к написанию алгоритма? А дальше-то что происходит? Подскажу — 0 и 1. А это что такое знаете? Как они становятся материальными и главное где?
У меня научное и материальное определение объекта
"Научное"? Согласно какому критерию научности?
Если Вы выбрали философский (как современно!) термин, то я выбрал материалистический.
Это не делает ваш термин более правильным, чем мой.
Да прекратите бред нести?! А хранятся они где? А что из себя представляют?
А какое это имеет значение? Когда я строю алгоритм, я оперирую именно нематериальными объектами, и их последующее физическое представление в виде электронов и/или электромагнитных полей меня волнует мало.
Так по-вашему программирование сводится только к написанию алгоритма?
Нет, программирование сводится к созданию компьютерной программы (я не хочу сейчас вдаваться в развернутый спор "программирование 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").
Больше того скажу, в Полинезии существуют народы, которые не знают данной абстракции. У них натурально для каждого существительного есть отдельные слова для разного количества. То есть отдельное слово для одной овцы, отдельное слово для двух овец. Аналогично с деревьями. И они не находят общих признаков у двух овец и двух деревьев.
Следуя вашей логике слово — это тоже реальный объект, потому что в той или иной форме он существует у всех народов?
Эм, прямо в процитированном вами определении сказано "число — [...] понятие". Понятие — не "реальный объект" никаким образом, это понятие.
Понятие "два" — существует, с этим никто не спорит. А реального объекта "два" — не существует.
То, что абстракция "берется из" реальных объектов, не означает, что каждой абстракции можно сопоставить реальный (физический, материальный) объект.
Я боюсь, у вас свое понимание слова "сопоставить".
Рассмотрим, значит, такую милую абстракцию как период (такая наименьшая музыкальная форма). Какой физический объект вы ей сопоставите? Или, что веселее, возьмем саму абстракцию музыкальной формы — какой физический объект ей соответствует?
Во вторых,
Музыкальная форма… многозначный музыкальный термин...
Хорошо, а что такое предложение в русском языке — вы знаете?
(кстати, а чему мешает многозначность термина?)
кстати, а чему мешает многозначность термина?
А вы сами попробуйте сопоставить 3 значения (описанные в первом абзаце этой статьи на википедии) между собой. Несмотря на то, что все они относятся к музыке, сходств у них гораздо меньше чем различий, особенно если первое или второе сопоставлять с третьим.
Если вы мне пытаетесь доказать или объяснить, что мое мнение ошибочно, то вы это делаете не тем способом. Я — это частный случай.
Я боюсь, у вас свое понимание слова «сопоставить».
Провести параллели, найти сходства и различия.
А вы сами попробуйте сопоставить 3 значения (описанные в первом абзаце этой статьи на википедии) между собой. Несмотря на то, что все они относятся к музыке, сходств у них гораздо меньше чем различий, особенно если первое или второе сопоставлять с третьим.
Тем не менее первые два из них (третье нас не очень интересует, потому что это дисциплина, и полное ее название выглядит не так. Впрочем, дисциплина, не являясь абстракцией, тоже не является физическим объектом.) оба являются абстракцией (разной абстракцией, но не суть). Поэтому они с равным успехом могут служить иллюстрацией моего тезиса.
Провести параллели, найти сходства и различия.
Так вот, во фразе EvilBlueBeaver "Математика вообще по своей сути набор различных абстракций, причем далеко не всем из них удается сопоставить реальные объекты" и в моей фразе "[не] каждой абстракции можно сопоставить реальный (физический, материальный) объект" используется другое понимание этого слова, а именно "провести однозначное двунаправленное соответствие".
А вы тут когда обсуждаете сопоставление абстракциям реального объекта, то что под этим подразумеваете вообще? Что можно, формально, построить какую-то функцию из множества абстракций в множество конкретных объектов? Ну, кажется, можно, буду сопоставлять интегралам яблоки, а топологическим пространствам — велосипеды, например. Или это должна быть не любая функция, а какая-то особенная?
Или это должна быть не любая функция, а какая-то особенная?
"Какая-то особенная". Я не знаю формального названия таких функций, но, если вкратце, это должна быть пара функций f1: A -> C и f2: C -> A (где C — это конкретные объекты, A — это абстракции), такая, что f2(f1(x)) = x и f1(f2(y)) = y.
Ну вот я там просопоставлял интегралам груши и все такое. Устроит вас такое отображение? Если нет, то чем?
Если я правильно понимаю термин, то не полностью: для биекции необходимо, чтобы множества были равномощными, нам же достаточно, чтобы взаимно однозначное отображение было для каждого элемента из множества абстракций (точнее говоря, я утверждаю, что такого отображения нет)
Это называется "иньективное отображение", ака "вложение".
Ну вот я там просопоставлял интегралам груши и все такое. Устроит вас такое отображение? Если нет, то чем?
Тем, что эта функция не будет выполняться для всего множества интегралов (множество интегралов — оно вообще счетное?); таким образом, будут абстракции (интегралы), не сопоставленные с реальными объектами (грушами), а это именно то, что мы пытались доказать.
Тем, что эта функция не будет выполняться для всего множества интегралов (множество интегралов — оно вообще счетное?); таким образом, будут абстракции (интегралы), не сопоставленные с реальными объектами (грушами), а это именно то, что мы пытались доказать.
Ну давайте возьмем не только реальные груши, но еще и те, которые я в принципе могу вырастить. В рамках обсуждения это вполне достаточная "реальность", мне кажется.
Ну давайте возьмем не только реальные груши, но еще и те, которые я в принципе могу вырастить.
Я подозреваю, что мощность этого множества все равно будет меньше мощности множества интегралов. Но не суть, впрочем.
Давайте лучше учтем тот факт, что в множестве абстракций еще есть абстракция "фрукт", которую мы (точнее, я) тоже сопоставили с грушей. Теперь функция из пространства реальных объектов в пространство абстракций имеет два значения.
С другой стороны, про груши — интересный философский вопрос. Множество генотипов максимум счётно, но на фенотип, наверное, влияет окружение, осадки там всякие, количество солнца, и считать это счётным или континуальным множеством параметров — хрен его знает.
Вы сейчас считаете варианты груш (не важно, генотипы или фенотипы), а считать надо экземпляры (т.е., конкретные груши, которые можно подержать в руках).
Ну а я ее с грушей не сопоставлял. Я ее сопоставил с вон тем воздушным шариком, так что все в порядке.
> (т.е., конкретные груши, которые можно подержать в руках)
Ну допустим размер груш непрерывно меняется от Х (самая маленькая груша), до Y (самая большая). Значит, по вариации этого параметра, множество груш, которые в принципе можно вырастить и подержать в руках — вполне континуально.
Но вас тут смущает именно проблема мощностей, а не то, что интегралам сопоставляются велосипеды, грушам — воздушные шарики и т.д.?
Я ее сопоставил с вон тем воздушным шариком, так что все в порядке.
Не, не в порядке: с воздушными шариками уже сопоставлено нормальное распределение.
(вообще, мощность множества абстракций выглядит больше множества реальных вещей)
Но вас тут смущает именно проблема мощностей, а не то, что интегралам сопоставляются велосипеды, грушам — воздушные шарики и т.д.?
Нет, смущает меня некорректность самой идеи такого сопоставления, но поскольку выражать семантику через функции я не умею, приходится пока обходиться количествами.
Нормальное распределение сопоставлено с арбузами, так что в порядке.
> (вообще, мощность множества абстракций выглядит больше множества реальных вещей)
А на мой взгляд, не выглядит.
Ну и вообще — давайте каждой абстракции поставим в соответствие мозг, находящийся в состоянии помысливания данной абстракции.
> Нет, смущает меня некорректность самой идеи такого сопоставления
Ну дайте другую идею. Вы же выше бодро сопоставление обсуждали. Вот я и пытаюсь выяснить, что вы за сопоставление обсуждали.
Ну и вообще — давайте каждой абстракции поставим в соответствие мозг, находящийся в состоянии помысливания данной абстракции.
Получится, что абстракции, о которых никто в этот момент не мыслит, не существуют, а это уже солипсизм какой-то.
Ну дайте другую идею. Вы же выше бодро сопоставление обсуждали. Вот я и пытаюсь выяснить, что вы за сопоставление обсуждали.
Ну, "по-хорошему", для сопоставления необходим еще критерий семантического соответствия, отношение "одно есть другое", но я не знаю способов это формально выразить.
Получится, что абстракции, о которых никто в этот момент не мыслит, не существуют, а это уже солипсизм какой-то.
Почему? Нет. Так же как с грушами, которые можно потенциально вырастить, мы рассмотрим потенциальную конфигурацию мозга, которая к выдумыванию данной абстракции приведет. А если такой конфигурации мозга не существует — то и абстракция это никогда не появится, то есть нету ее, да.
Ну, "по-хорошему", для сопоставления необходим еще критерий семантического соответствия, отношение "одно есть другое", но я не знаю способов это формально выразить.
Ага, ну вот как раз этого я и хотел.
Кстати, насчет числа математических объектов. Для любой теории с не более чем счетным алфавитом множество формул, очевидно, не более чем счетно. А значит, можно сформулировать не более чем счетное число утверждений, эффективно доказывающих существование каких-либо объектов. То есть, вот у вас есть континуум чисел, вроде вы можете доказать его существование и доказать существование континуальных подмножеств. Но вот если вы начнете доказывать существование конкретных чисел, то более чем счетного множества не получите. То есть все остальные числа принципиально "не потрогать" :)
Если я правильно понимаю термин, то не полностью: для биекции необходимо, чтобы множества были равномощными, нам же достаточно, чтобы взаимно однозначное отображение было для каждого элемента из множества абстракций (точнее говоря, я утверждаю, что такого отображения нет), но не обязательно, чтобы оно было для каждого элемента из множества материальных объектов.
Нет.
Значит ли это, что множество А не является множеством абстракций?
Нет.
Я не уверен, что я точно понимаю, что вы имеете в виду под своим вопросом (в частности, абстракцией чего является предложение?), но в общем случае ответ очевиден: абстракцией других объектов (или явлений).
но в общем случае ответ очевиден: абстракцией других объектов (или явлений).
И вы до сих не замечаете, как можно сопоставить абстракцию физическому объекту?
Если объект x принадлежит к не расширяемому классу С, а класс С расширяет абстрактный класс B, расширяющий абстрактный класс А, то можно сказать, что объект x соответствует типу A.
И наоборот, при тех же условиях.
Объект x типа А будет также принадлежать к типу С.
Опять не по вашему сопоставляю?
И вы до сих не замечаете, как можно сопоставить абстракцию физическому объекту?
Нет, не замечаю.
Если объект x принадлежит к не расширяемому классу С, а класс С расширяет абстрактный класс B, расширяющий абстрактный класс А, то можно сказать, что объект x соответствует типу A.
… и какое отношение это имеет к сопоставлению абстракций и физических объектов?
и какое отношение это имеет к сопоставлению абстракций и физических объектов?
Прямое! Вам осталось только
провести однозначное двунаправленное соответствиемежду двумя объектами: абстрактным x и конкретным y.
Дайте мне толковый словарь, который описывает ваше понимание слова сопоставить.
Прямое! Вам осталось только "провести однозначное двунаправленное соответствие" между двумя объектами: абстрактным x и конкретным y.
На основании чего, простите? (вы, собственно, вообще не ввели y)
Такого словаря нет. Я в этой дискуссии привел определение (их набор, точнее) в меру своей способности.
Завтра вы добавите в свой набор определений еще одно толкование и тележку условий, а мне что делать? Подстраиваться каждый раз под ваши определения?
Такова печальная реальность дискуссии в неопределенном терминологическом поле.
Вы говорите реальный объект — я понимаю это, как объект невымышленный и исключаю глубоко идеализированные абстракции.
Потом вы говорите физический материальный объект — я исключаю абстракции, но оставляю обобщения.
Затем я вижу в вашем сообщении
других объектов (или явлений)
Теперь я понимаю, что все это время вы имели ввиду физическое тело.
… вернемся к простым примерам. Какой конкретный физический объект соответствует абстракции «предложение» (в лингвистическом значении)?
Потому что если такой объект найти невозможно, будет продемонстрировано, что не каждой абстракции соответствует физический объект.
(я, впрочем, помню, что принято доказывать наличие, а не отсутствие, но в данном случае на негативных примерах как-то проще)
Потому что если такой объект найти невозможно, будет продемонстрировано, что не каждой абстракции соответствует физический объект.
А если такой объект будет найден, то это ничего не докажет. Если такой объект не найду я, то это тоже ничего не докажет. Если такой объект не сможет найти никто, то это все равно ничего не докажет.
"Реальный" в значении "материальный". Извините, если ввел вас в заблуждение неточной формулировкой.
Именно поэтому я поправился.
как это не казалось бы странным, но абстрактный объект — это тоже реальный объект.Вы можете доказать данное утверждение?
Может утверждение не так должно звучать или я чего-то не понимаю? Вроде бы слово "абстракция" введено не просто так. На примере желательно. Из реального мира. Раскройте полнее Ваше утверждение. И чем Ваши слова отличаются от слов о Макаронном монстре?
Прежде, чем доказывать данное утверждение, надо бы определиться с определениями (sic) понятий "абстрактный объект" и (особенно) "реальный объект".
Абстракция — это форма, в которую оборачивается материя. [...] Т.е. материальное — само по себе бесформенно, безобразно (не имеет образа).
Я боюсь, вы существуете в другой терминологической системе.
Исчисление — это что-то абстрактное
Да, но «2» уже не абстрактное, но обобщенное.
Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.
Если взять пример с двумя руками — тут все очевидно, как были руки, так и остались, отдельного физического объекта 2 не появилось.
Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.
Потому что все, что вы описывали, не является именно числом 2.
Но «два» и «2» можно рассматривать как равнозначные?
Нет физического объекта — который является числом 2.Значит теперь уже физического… а раньше было реального.
Если рассматривать пиксели на экране или звуковые волны или что угодно вы там используете для описания числа 2, то это тоже не работает вот почему: Если сложить число 2 с числом 3 — должно получиться число 5, а у вас получится какая-то мешанина пикселей или звуковых колебаний.К двум яблокам на столе можно прибавить 3 груши, чтобы получилось 5 фруктов.
Но «два» и «2» можно рассматривать как равнозначные?
Только в рамках русского языка. Тому, кто не знает русский язык, понятие 2 может быть знакомо, а вот слово «два» нет. Более того, ему и цифра 2 может быть незнакома, а до двух сосчитать он сможет. Но я уже выше писал, что существуют народы, которые и этого не смогут.
Значит теперь уже физического… а раньше было реального.
Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?
И даже если вам не нравится термин «физический», то и реального объекта «2» не появилось, появилась другая рука.
К двум яблокам на столе можно прибавить 3 груши, чтобы получилось 5 фруктов.
Как из 5 фруктов выделить непосредственно
Давайте определимся с терминологией, что вы подразумеваете под первым и под вторым?
А вы считали, что это синонимы?
Как из 5 фруктов выделить непосредственно физическийреальный объект «5»?
Зачем его выделять?
Если прибавить 2 грузовика к 3 стаканам сока, то 5 чего получится?
5 абсурдов! :)
Есть такой фильм «Роковое число 23», главный герой повсюду наблюдал число 23. Он считал предметы и получалось 23, складывал числа — получалось 23, число 23 было везде.
23 было объектом его воображения. Он абстрагировался от всего конкретного и ему не важно было чего там 23, его волновало только 23.
Получится 6 фруктов?
Не фрукт — конкретный объект, а конкретный объект — фрукт.
Называя конкретный объект фруктом мы просто его относим тем самым к классу фруктов.
Так что фрукт в мире яблок и прочих апельсинов — это все-таки абстракция, слово.
С другой стороны, фрукт — это конкретный нематериальный объект (да-да, абстракции могут быть объектами, если они рассматриваются в пространстве абстракций, и для них вводятся новые абстракции, чтобы классифицировать эти абстракции-объекты) — слово русского языка (заимствованное, но все же).
Автора статьи я не защищаю, просто по данному вопросу наше мнение совпало.
То есть вы тоже считаете, что объект может быть только физической сущностью (и, следовательно, число 2 — не объект)?
Я не придерживаюсь ни этого мнения ни противоположного.
Тогда, извините, но вы не можете говорить, что ваше мнение с автором совпало, потому что вы не придерживаетесь мнения, которого придерживается автор.
По моему слишком обобщенный вопрос, чтобы дать на него правильный ответ
Да нет, это очень простой вопрос, ответ на который уже неоднократно озвучен в разных терминологических системах.
Определим класс: КоммерческаяФирма.
Создадим экземпляр класса: Фирма (ООО, LTD)
У объекта Фирма свойства: счет, обороты по счету, учередители, директор, место регистрации, фактический адрес и т. д. И методы: получить деньги, перечислить деньги, отгрузить товар, принять заказы и т. п.
Объект Фирма может взаимодействовать с другими объектами фирмами, банками, людьми.
Является ли при этом Фирма физическим объектом?
С точки зрения науки и реальности Фирма не является физическим объектом.
С точки зрения программирования Фирма является объектом.
С точки зрения программирования Фирма является объектом.
Получается, объект в программировании может состоять из других объектов и не являться физической сущностью в реальном мире.
Но ведь ранее вы утверждали
В статье:
Обьект — наименьшая неделимая сущность,
В комментарии выше:
А объект — это всегда физ. сущность.
Кажется, мы пришли к противоречию…
Сам же Ваш вопрос был поставлен некорректно. Сначала Вы использовали терминологию программирования, но задали вопрос про физический объект. Видите разницу? Я увидел и в такой манере и ответил. Затем Вы делаете умозаключение «Получается, объект в программировании может состоять из других объектов и не являться физической сущностью в реальном мире.». Да это так и есть. И это называется абстракцией. В программировании, и в науке, мы легко можем создавать абстракции наделяя их свойствами и поведением которые нужны для решения определенных задач.
Так "объекты" в программировании — они объекты или абстракции?
1
А объект — это всегда физ. сущность.
2
С точки зрения программирования Фирма является объектом.
Я оспариваю утверждение «объект — это всегда физическая сущность».
Если 1==Истина И 2==Истина
Тогда Фирма физическая сущность
Хотелось бы узнать, где Фирма является физической сущностью?
В реальном мире это не физический объект, а в программировании это всего-лишь слово (последовательность знаков), которым мы обозначили фирму из реального мира.
По моему, всё программирование — это абстракция. Ведь физически не существует объектов и переменных, даже 0 и 1 — условность. В реальности у нас есть только соединенные между собой определённым образом транзисторы, на которые подается напряжение, также определённого формата.
даже 0 и 1 — условность. В реальности у нас есть только соединенные между собой определённым образом транзисторы, на которые подается напряжение, также определённого формата.
Так 0 и 1 это и есть этот формат, а не условность! Вы не знали об этом?
Я оспариваю утверждение «объект — это всегда физическая сущность».
Вы смешиваете красное с мягким! И я написал Вам об этом. Не надо так делать. Пытаетесь меня подловить на выдергивании цитат? Как мило… Причем уже в который раз. Или Вы не поняли что я написал и где подвох или издеваетесь? Так я тоже так могу делать, но только смысла от этого не будет. Сделайте что-то полезное в этой жизни не только для себя — будет только лучше.
Немного истории. С чего всё началось? Сначала было ....
Это очень интересная тема. Существуют обьёмные и очень интересных книги по истории, например, паровозов. В них рассматривается эволюция отдельных блоков, их разновидности и т.д. А вот об отдельных аспектах программирования, например истории баз данных, я не встречал.
Я лично убеждён, что прогресс популярных языков программирования примерно до 90-х годов определялся в основном развитием теории и практики построения компилчторов. Я думаю также, что С# был первым языком, когда вначале была собрана командв признанных на тот момент специалистов, которые не бросились в спорах писать первый вариант компилятора, а довольно долго подготавливали спецификацию для первой версии языка.
До сих пор создание совсем новых языков дело ужасно трудоёмкое и определяется базой накопленных знаний и умений.
Другими словами, при создании языков сначала появлялись технические возможности, а потом для них придумывались красивые интерпретации. Например — фактическое прикрепление функций к стркутурам в С назвали Обьектом. А могли бы назвать Атомом. На эту тему, кстати, есть байка, что закрепившийся в UML термин Актер на самом деле следствие ошибки переводчика со шведского. Эта штука должна называться Роль.
Может вместо создания нового УЯП стоит подумать как применить UML, например xUML (Executable UML)?
Если абстрагироваться от [...] не очень научных формулировок
Это в посте, который призывает к научному подходу? Ну то есть абстрагироваться от самой сути поста?
автор пытается призвать подумать над Универсальным Языком Программирования (УЯП), который будет способен моделировать всё в мире.
Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
Тогда уж пойти ещё глубже и попытаться понять, чем различаются моделирование и программирование. А Вы как думаете?
Моделирование — это часть процесса программирования.
Написание программы на ЯП — описание модели для компьютера, чтобы тот ее просчитал.
При этом следует понимать, что модель, которую строит для себя программист, не обязана быть всеобъемлющей. Она должна содержать в себе ровно ту часть предметной области, которая необходима для решения конкретной задачи.
Моделирование — построение модели.
Программирование — построение программы (снова, я избегаю спора "программирование vs разработка").
Программа может включать в себя модель (и обычно включает), но (а) не вся программа есть модель и (б) модель не обязательно является целью программы.
Аналогично, модель может быть исполнимой, но не обязана быть таковой.
Таким образом, мы имеем две различных деятельности, которые в какой-то своей части пересекаются, но имеют и непересекающиеся области.
1) «Формальную» или «официальную» модель предметной области. Иногда эти модели описаны в книгах, статьях, документах.
2) «Приватную» модель предметной области в голове программиста. Она отличается от первой модели по многим параметрам. По полноте, структуре и «природе» (из чего состоит). На самом деле про эту модель можно мало что сказать конкретного, кроме того что они субьективно существуют и «кристаллизируются» в процессе написания программы.
3) Модель программы (или системы) которая может быть формально отражена в докуметации, получена из кода или просто возникает в голове всякого, кто должен программу писать, расширять, тестировать и т.д.
А зачем, бишь? Нет, понятно, что "порядок и учет", и некоторые доценты очень любят классификации, но какой в этом практический смысл?
И, главное, какое это имеет отношение к обсуждению?
А к обсуждению это имеет вот какое отношение. Ваша фраза:
Может, надо начать с того, что понять, что язык программирования и язык моделирования — это разные вещи?
А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации? Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?
Как мне представляется, выплеснутая автором боль и происходит из этой дилемы.
Я — не доцент.
А я и не про вас. Это один из моих научных руководителей, на тот момент времени как раз доцент, говорил такое про себя каждый раз, когда вводил нам очередную классификацию чего-нибудь по новому признаку.
А должен ли язык программирования хорошо отражать модели второго типа в вышеприведённой классификации?
Нет. Он должен по возможности хорошо выражать намерения программиста.
Или программист должен свои ментальные модели «подгонять» под возможности языка программирования?
Программисту так или иначе придется подгонять свои ментальные модели под тот инструментарий, которым он пользуется.
Как мне представляется, выплеснутая автором боль и происходит из этой дилемы.
Как мне представляется, "эта дилемма" не имеет никакого отношения к "научности" программирования.
Я правильно Вас понял, что Вы не считаете, что названная дилема существует, а также не считаете что в программировании возможна научность (научный подход?)
Нет, вы неправильно меня поняли.
Я считаю, что в программировании есть проблема несоответствия языка, используемого программистом, тому, что программист хочет выразить на этом языке — однако я не уверен, что эта проблема имеет отношение к ментальной модели программиста (в частном понимании ментальной модели как ментальной модели домена).
Я не имею мнения по поводу "научности" в программировании, потому что я пока не услышал разумного определения, что же такое "научный подход" применительно к программированию.
Но неудолетворённость нынешним состоянием остаётся. Проблему хочется решать. Делать это можно по-разному.
Можно как алхимики пробовать и за счёт эмпирических правил и озарений всё же двигаться вперёд.
А можно по-научному. Но и тут без озарений не обойтись, похоже.
Научный подход применительно к программированию не должен сильно отличаться от подходов в других областях.
А можно по-научному.
Это как? Конкретно?
Научный подход применительно к программированию не должен сильно отличаться от подходов в других областях.
В каких "других областях"? Что такое "научный подход" в пошиве одежды?
Что такое «научный подход» в пошиве одежды?
Ну например для начала могу подарить Вам и всем дочитавшим до этого места два способа стать миллиордером уже к осени, занимаясь пошивом… дамских джинс.
Способ первый. Я не специалист по дамским джинсам, но как я понимаю, сейчас модно показывть голые щиколотки. А до этого было модно показывать самый нижний позвонок. А ещё — коленки сквозь искусственные прорехи.
Так вот — научитесь предугадывать, что будет нравиться дамам ближайшей осенью, свяжитесь с производителями и станете миллиардером.
Способ второй: Представте себе. Приходит дама в магазин, видит модный фасон джинс. Меряет — меряет, а потом говорит разочарованно продавцу — эти жмут внизу, а эти вверху, потому никакие не куплю. А продавец ей говорит: а Вы зайдите в вон ту кабинку, там Вас сканер отсканирует, а завтра приходите за джинсами. Только это будет стоить дополнительно X процентов.
Придумайте технологию — и разбогатеете.
Но вряд ли кто-нибудь к осени эти задачи решит. Но решат, я думаю. И непременно с помощью научного подхода.
Какие основные шаги:
1) точно сформуриловать проблемы/цели
2) построить адекватную модель предметной области с релевантными обьектами, релевантными состояниями, взаимосвязями, параметрами воздействия и функциями действия.
3) поиск решения на уровне модели и проверка решений на практике.
Конкретно по первому сценарию. Что значит физиологически, что джинсы нравятся? Это зависит от времени суток, национальности, культурного уровня, возвраста?
Можно функцию «нравится» оцифровать? Можно её интерполировать/экстраполировать?
И т.д.
Убедил?
Убедил?
Нет. Я не вижу в вашем описании ничего научного. Вы можете построить объективный способ опровергнуть ту или иную гипотезу про "что такое джинсы нравятся"?
(при этом, что характерно, ненаучные способы "предугадывать, что будет нравиться" — а, точнее, формировать спрос — есть, и это ровно то, чем занимаются модельеры)
Я не вижу в вашем описании ничего научного.
Разумеется за несколько минут нельзя серьёзно сформулировать план действий в рамках научного подхода. В моём экспромте я попытался показать, что научный подход при пошиве одежды возможен. Так же как и при разработке программы управления складом.
Другое дело, есть ли у нас на это время и деньги в нашей суетной жизни.
Вы можете построить объективный способ опровергнуть ту или иную гипотезу про «что такое джинсы нравятся»?
Насчёт обьективного способа вопрос очень сложный. Не возмусь. Но примерно понятно, как такие гипотезы проверять статистически. Но одно дело примерно представлять, а другое — профессионально провести. Для этого нужна помощь профессионалов.
Попытки эмпирически, по-наитию формировать спрос действительно постоянно предпринимаются. Но успех, как я понимаю, как у алхимиков. То есть как в лотерее.
В моём экспромте я попытался показать, что научный подход при пошиве одежды возможен.
Но вам это не удалось. Вы привели совершенно обывательские подходы, которые к науке как таковой никакого отношения не имеют.
По большому счету, ровно то же самое, что произошло с автором поста, просто у него — в программировании, а у вас — в пошиве одежды.
Начинать-то надо с определения, что такое "научный подход".
Попытки эмпирически, по-наитию формировать спрос действительно постоянно предпринимаются. Но успех, как я понимаю, как у алхимиков. То есть как в лотерее.
Это какая-то очень выигрышная лотерея, вы не находите?
Но вам это не удалось.
Ну это Вы в полемическом запале. К сожалению, сам я в этой жизни уже этим вопросом вряд ли буду заниматься. Но я ожидаю, уже скоро мы услышим о прорывах в обоих описанных направлениях (прогнозирование моды и автоматизация индувидуального пошива одежды). И науки при этом потребуется много.
Начинать-то надо с определения, что такое «научный подход».
Меня устраивает определение из Википедии. Правда, если посмотреть ту же статью на других языках, детали сильно отличаются. Это определение я брал за основу.
Это какая-то очень выигрышная лотерея, вы не находите?
Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды. Наши программисткие боли — сладкий сон по сравнению с ними.
Но я ожидаю, уже скоро мы услышим о прорывах в обоих описанных направлениях (прогнозирование моды и автоматизация индувидуального пошива одежды).
Понимаете ли, автоматизация индпошива — это не научный подход, точно так же, как не является научным подходом станок, который режет доску на куски заданного размера. Это просто… автоматизация.
А прогнозирование моды — вы вообще понимаете, что мода создается, а не меняется сама по себе?
Меня устраивает определение из Википедии.
Ну так по этому определению научного подхода в пошиве одежды быть не может, потому что (а) нет научного сообщества и (б) невыполнимо требование объективности.
Собственно, в программировании тоже есть проблемы с объективностью.
Как говорит поговорка — Хорошо где нас нет. Мне попадалась статья про суровую реальность жизни дизайнеров одежды.
Вам "попадалась статья", а я с некоторыми знаком лично (причем как и дизайнерами, так и с теми, кто шьет).
Спасибо!
ЗЫ: автор, хотелось бы узнать, ты TaPL (http://newstar.rinet.ru/~goga/tapl/tapl-toc.html) осилил?
Они своим словоблудием продвигают в массы только нужные им идеи, не заботясь ни о теории, ни о доказательствах
Полностью согласен! Взять хотя бы
В идеале должно быть всего 2 низкоуровневых языка и 3-4 высокоуровневых, построенных на их основе.
После ознакомления со стандартами SQL, можно приступить к ознакомлению vendor-specific особенностей каждой конкретной СУБД. Например LIMIT в стандарте отсутствует, т.к. противоречит реляционной теории, но при этом реализован у большинства вендоров.
В итоге получается, что SQL вроде бы один и тот же, а на самом деле их несколько десятков.
Можете сами оценить в списке на википедии.
Если учесть, что СУБД постоянно дорабатываются, то в каждой новой версии появляются новые надстройки. Так можно насчитать уже и сотню-другую диалектов SQL.
Благодаря такому многообразию инструментов, становится возможно выбрать тот, который удовлетворяет конкретным ограничениям конкретного проекта.
Здесь я говорю что в итоге низкоуровневый язык должен быть один(имея ввиду его синтаксис)
Нет, вы там говорите, что вообще язык должен быть один.
Можно было бы взять в качестве исходных фактов другие высказывания, звучащие столь же научно, и плясать уже от них, с иными результатами. Все эти факты из химии и физики (сильно упрощенные, и к тому же верные лишь отчасти) — на каком основании именно их вы приняли за постулаты своей теории? Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?
Далее, от исходных данных вы сразу же перешли к положениям своей теории. Как вы пришли к этим выводам? Вот вы пишете:
Приняв за основу изложенные факты и данные, проанализировав свойства и поведение элементов, их взаимодействие и процессы между ними
— где этот анализ, где вот это всё? Я из тех же самых положений за день могу родить с десяток столь же блестящих подходов к программированию. И, к сожалению, столь же сомнительных.
Наука — это не то, что звучит научно. Это не аргументация фразами из учебника. Это не то, что у вас в статье написано — у вас пример псевдонаучной статьи. У меня, честно говоря, возникают ассоциации с творчеством разных фриков — от физики/химии/etc.
Я вижу, что вы нормально относитесь к критике. Или пытаетесь, по крайней мере. Я бы хотел дать вам конструктива. Но трудно в рамках комментариев всё расписать, поэтому я ограничусь одним советом: почитайте о настоящей науке. Почитайте Фейнмана. Прочтите Гарри Поттер и методы рационального мышления — вот эту книгу я настоятельно рекомендую. Прочтите, хотя бы последнюю, до того, как писать следующую публикацию. Это все, что я могу вам сказать, не ввязываясь в полемику.
1. «Они что, полностью описывают Вселенную, или как? Что это, как не субъективность?»
Разве физика и химия не описывают вселенную?
И дело-то вообще не в этом. Я пытался найти причинно следственную связь между вашими предпосылками и выводами. И не нашел.
Любопытно наблюдать, что статей "Умные мысли, часть 1" на хабре сильно больше, чем статей "Умные мысли, часть 2". Причем в комментариях к статье 1 автор довольно часто обещает развернуть свои мысли в статье №2 или даже написать целый цикл статей.
Довольно странное впечатление от статьи.
- Вы ссылаетесь на математику, физику и химию как на пример точных наук. Но при этом не учитываете, что даже там были ошибочные теории.
Например, теория о теплороде в физике.
Или механика Ньютона, которой до сих пор пользуются, хотя она немного "не точна". - Наука в большинстве своем занимается предсказаниями: при заданных начальных условиях будет определенный результат.
Ваши же предположения очень спорны.
- Исключение абстракций, наоборот, может увеличить размер кода. Потому что, если у вас 10 типов объектов, то вам понадобится 10 типов списков конкретных объектов. Для каждого типа списка объектов придется писать почти одинаковый код.
- Антипаттерны вредны вообще, но на размер кода они влияют слабо. Сервис-локатор убирает много кода для предоставления зависимости там, где она нужна.
- Язык APL, на нем программы могут быть ощутимо короче, но понятнее от этого они не становятся.
- В принципах собраны как требования к языку, так и к стилю написания программ.
Последний особенно противоречив. Если ваш воображаемый язык заставит следовать этому принципу, то как вы будете разрешать конфликт, в котором у меня все работает, а у коллеги не запускается/компилируется, только потому, что у меня монитор стоит вертикально?
1. «Вы ссылаетесь на математику, физику и химию как на пример точных наук.» — Действительно, были разные теории и некоторые из них были ошибочные, и будут ещё в будущем другие — и все они будут пытаться объяснить происходящие вокруг процессы и явления. А как это наука сейчас делает? С помощью научного метода(и это большое достижение!) чтобы избежать ложных подходов при доказательствах и появлению псевдонауки.
2. «Наука в большинстве своем занимается предсказаниями: при заданных начальных условиях будет определенный результат.» — Не совсем верно. Научная теория может или обязана делать предсказания. И об этом я буду писать во второй части. 1 и 2 пункты я буду доказывать на примерах кода. 3 пункт — Вы полностью правы. Ведь это просто вопрос синтаксиса и реализации именно языка.
3. «В принципах собраны как требования к языку, так и к стилю написания программ.» — Справедливо замечено.
Еще нет «моего» языка и я даже не упоминал о его реализации.
4. «Если ваш воображаемый язык заставит следовать этому принципу, то как вы будете разрешать конфликт, в котором у меня все работает, а у коллеги не запускается/компилируется, только потому, что у меня монитор стоит вертикально?» — я не понял вопроса. При чем здесь монитор? Можете раскрыть вопрос?
Очень важная концепция — то, что в лингвистике называется гипотезой Сепира-Уорфа, она примерно состоит в том, что язык, которым мы пользуемся, является инструментом для мышления, и сама его структура оказывает влияние на то, что мы в принципе можем подумать. Многие программисты знают это на опыте (попробуйте на Haskell написать что-нибудь, если до этого писали только на процедурных, если не верите).
Ну а на практике, мне кажется, постепенно будет все двигаться в сторону языково-ориентированного программирования, то есть конструирования DSL под конкретную область, и дальше оно там может прижиться, как SQL, или там постепенно приживаться (как XML, который потом довольно скоро переизобрели как JSON).
Что правильнее Лямбда исчисление Черча, машины Тьюринга, или вообще циклические теги? Очень мило, если бы не хамство, выглядели попытки натянуть математические концепты на «химические элементы»
горшочек не вари.
lurkmore.net/%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B0%D1%8F_%D0%9E%D0%A1
является совокупностью бредово-казённо-абсурдных высказываний наподобие:
Процессор Пентиум — это логическое устройство. Любое действие процессора определяется логикой этого процесса.
Горлов А. В.
vs.
Факты:
1. Всё в окружающем мире состоит из мельчайших неделимых химических элементов и поэтому за основу главного объекта необходимо брать именно химический элемент обладающий множеством моделей поведения.
Очень странное обсуждение! Целая статья о "научном программировании", 200 комментариев, жаркие споры и ни разу не прозвучали волшебные слова: "денотационная семантика", "аксиоматическая семантика", "изоморфизм Карри-Говарда", "формальная верификация". Зато есть "ООП", "ФП", "хочешь странного: Хаскель и всякие F#"… Неужели никому в этой дискуссии не интересно именно научное программирование, а не ваяние формочек?
> Сначала идет теория, а за ней практика.
Это только в варианте рассмотрения через школьные учебники о том, что было 2000 лет назад, кажется, что «сначала идёт теория». Сначала таки шла практика, потом на неё «натягивалась» (в почти прямом смысле) теория, и именно поиск подходящей теории занимал значительное время.
Чтобы это осознать во всей полноте, надо обратиться к первоисточникам. Например, как выглядели в оригинале работы тех же греков, или Ньютона с Лейбницем. Огромное количество совершенно посторонних, с современной точки зрения, действий, сотни необоснованных утверждений. Катастрофически несовершенный аппарат, вплоть до обозначений (почитайте аль-Хорезми, хотя бы в хорошем переводе, но с обозначениями того времени; почитайте Фибоначчи; сравните знаки Ньютона, Лейбница, Эйлера, их современников с современными). Реальная теоретическая база это уже XIX и XX век. Матанализ приведён в стройную концепцию из свалки разнородного мусора Коши со товарищи. Геометрия — примерно тогда же. Самые теоросновы математики — уже в XX веке, включая жуткие поражения от Гёделя и прочих.
Да, вслед за теорией идёт новая практика. На процентов 90, я бы сказал — когда за счёт теории получается выкинуть кучу мусора из практики и банально освободить место в мозгах. Но она всё равно проверяется той же практикой, и критерии практические. Если бы определение прямого угла треугольником 3-4-5 давало бы дикую погрешность из-за неидеальности используемых деревянных палок, никто бы его не применял. Тысячи таких потенциальных практик погибли в безвестности из-за проблем неустойчивости решения.
В CS мы находимся на достаточно раннем этапе этого процесса. Да, это не значит, что надо сидеть на берегу реки и ждать, пока теории сами проплывут мимо. Надо изобретать, даже если 99% этого рассыпется в пыль, перекрытое лучшим или просто не выживя. Но говорить, что нет прогресса и нет теории… как-то смешно.
> Введение объекта должно было быть теоретически обосновано.
Теоретическое обоснование любой практики — это удел студентов под руководством замшелых преподавателей, которые методом вбивания метрового клина в голову пытаются хоть как-то научить обосновывать, а иначе не умеют. Какое теоретическое обоснование включения бензонасоса в поставку автомобиля? Насос что-то обеспечивает, и его ставят. Или не ставят. Может показаться, что аналогия хромает. Но на самом деле вся инженерная практика основана на подобных решениях. 99% это копирование предыдущих решений и интуитивное определение сущностей и возможных решений. 1% — да, теория, но прилагаемая уже к практическим идеям (насос должен быть мембранный, клапанный, турбинный? какой должен быть запас мощности? и т.п.) ООП — то же самое. С момента возникновения общей концепции есть немного принципиальных различий по сути: это давать самостоятельную жизнь каждому объекту (стиль Simula/Smalltalk, стандартные симуляции такого подхода в Erlang с компанией, etc.) или нет (C++, Java, C#, Swift и ещё тысячи их); принципиальность неизменяемости, где она полезна и как; ценность наследуемости и полиморфизма.
Если тут и будет какая-то теория, позволяющая реализовать решение по задаче, то она будет похожа не на математику, а на ТРИЗ: простая общая база и толстая библиотека типовых решений.
> Почему любой объект должен или может использовать наследование от другого объекта кто-то потрудился объяснить и доказать?
Наследование имеет строго определённый смысл: это обеспечение недублирования реализации за счёт её размещения в одном общем для всех месте. Наследование в классическом для компилируемых языков подходе — метод сделать это недублирование методом, максимально эффективным для современных процессоров.
Да, здесь есть классические примеры наиболее удачных применений и явных провалов. Удача — это, например, в GUI фреймворках, где толстая общая база не вызывает сомнений. Провалы — ну вспомним стандартный вопрос на интервью про соотношение квадрата и прямоугольника.
Методы обеспечения ссылаемости на такую общую реализацию могут быть самыми разными. Где-то это таблица виртуальных методов, как в C++, и как следствие — проблема общей базы в DAG наследников (см. множественное наследование и виртуальный базовый класс). Где-то в прототипе можно перечислить все методы явно. Где-то нет «методов», а есть привязанные логически функции. И вот тут уже начинается область, в которой сотни работ по теоретической проработке схем этих привязок, их преимуществ и недостатков; обычно оно скрывается под вывеской теории типов данных. Вероятно, Вы просто не знаете о них… что ж, пора ознакомиться.
Но, тем не менее, наследование — такая штука, которая пролазит везде. Даже там, где от неё стараются отбиваться руками и ногами. Потому что таки удобно. А дальше начинается околотеоретический поиск, как же лучше его уложить в конкретное прокрустово ложе…
Про NULL пропущу, потому что связанные с ним проблемы хорошо обозначены и решаются. Что за «реакционные объекты», совсем не понял. Хотелось бы пояснений.
И, кстати: во всей статье только один пример положительно упомянутого имени — шумного агрессивного евангелиста с откровенно однобокими, зато громко рекламируемыми решениями. «Это ж-ж-ж неспроста».
Ждём следующих обещанных статей, но начало уже вызывает пессимизм.
Как будто меня какие-то 'евангелисты' заставляют использовать ооп? Ну бред же.Не самообманывайтесь: никто не может изучить все технологии, узнать все практики и составить сравнительный анализ, какие объективно удобнее.
Скорее всего, вам показали ооп, вам понравилось то, что вы увидели, это показалось более удобным по сравнению с тем, что вы знали и использовали до этого, поэтому и используете сейчас.
Если бы вы жили в обществе, где повсеместно используется что-угодно, кроме ооп, а литературы по ооп было бы крайне мало, узнали бы вы о нём? Познакомившись с ним, научились бы вы «его готовить»? Сумели бы вы разглядеть в нём то удобство, не зная ни паттернов, ни хороших практик, не имея опыта (ведь коллеги не используют ооп в нашем мысленном эксперименте)? Искренне сомневаюсь. Всё-таки, человек коллективное (стадное) существо. А потому нужны евангелисты, задача которых рассказывать всем, какая штука была изобретена и как полезно обществу начать её использовать на практике. Общество слушает, кто-то использует, потом только вырабатывается оценка, которая, к слову, играет решающую роль, а не мнения евангелистов, потому что
Хуже всего, когда теоретики рассказывают практикам, как им делать их работу.
Если бы вы жили в обществе, где повсеместно используется что-угодно, кроме ооп, а литературы по ооп было бы крайне мало, узнали бы вы о нём?
Представьте себе, до появления ООП так и было. Тем не менее ООП появилось и стало широко известно.
Необязательно о чем-то узнавать от кого-то, можно придумать это самому, исходя из практики. Особенно в программировании.
Порядочный евангелист не станет обливать грязью все, что было придумано до него, вместо этого спокойно укажет на преимущества и недостатки своего подхода.Верно, так и должно быть. Всё остальное — профанация или шарлатанство.
Введение объекта должно было быть теоретически обосновано.
Почему это? Почему программисты не могут пользоваться тем, что им удобно практически?
И что значит само определение слова «наследование» в реальном мире?
Когда потомок получает что-то от предка. Можно было в словаре посмотреть. В случае с программированием это интерфейс и реализация.
Обьект — наименьшая неделимая сущность, также известная нам как химический элемент
Электрон это теперь не объект?
Попробуем применить к программированию науку и опираться только на её достижения, результаты и методы.
Провести аналогии с одной из наук не означает "применить науку". Особенно если эта наука описывает не все, что можно смоделировать. Тот же электрон, например.
Введем базовые определения для терминов: Обьект, Модель поведения, Процесс
Введение должно быть теоретически обосновано.
Факты
выделим несколько принципов
Докажите, что они необходимы и достаточны.
Реакционные объекты знают интерфейсы объектов с которыми работают.
Ничего подобного. Молния не вызывает метод дерева "загорись". Ни молния, ни ее энергия, ни излучение этой энергии не знают ни про дерево, ни про то что оно может гореть.
У элементов нет такого понятия как NULL. Вместо этого должен быть или 0, пустая строка, массив с одним элементом или пустая коллекция элементов.
У ваших элементов нет, у других есть. Использовать одно из правильных значений типа в качестве обозначения ошибки в корне неверно. Собственно потому, что это значение правильное.
1. «Почему это? Почему программисты не могут пользоваться тем, что им удобно практически?»
Программисты и пользуются этим. И в итоге это привело к текущему состоянию, когда каждый лепит свою ничем не обоснованную реализацию в языке или парадигме. Почитайте ссылки которые я дал, чтобы понять масштаб проблем.
2. «Когда потомок получает что-то от предка. Можно было в словаре посмотреть. В случае с программированием это интерфейс и реализация.»
Что Вы подразумеваете под «что-то»? В каких именно случаях это происходит в РЕАЛЬНОМ мире? «интерфейс и реализация» — это НЕ наследование! Приведите, пожалуйста, источник (словарь как я понимаю) откуда Вы взяли такое определение.
3. «Электрон это теперь не объект?»
Электрон — это физический объект. Я же приводил понятие «химический элемент» из АМУ, где Атом — наименьшая частица химического элемента, сохраняющая все его химические свойства. Или так: Атом — мельчайшая, химически неделимая, электронейтральная частица вещества.
4. «Провести аналогии с одной из наук не означает „применить науку“. Особенно если эта наука описывает не все, что можно смоделировать. Тот же электрон, например.»
Здесь Вы полностью правы. Но в том что я провожу аналогии с химией и не является наукой. Ею является моя попытка с помощью теории(в которую входит аналогия с химией) и доказательств сделать посильный вклад или хотя бы задать направление по которому программирование должно идти и развиваться. Иначе оно окажется там же где Астрология и Алхимия.
5. «Введение должно быть теоретически обосновано.» и «Докажите, что они необходимы и достаточны.»
Может я что-то пропустил или не знаю, но откуда Вы взяли эти утверждения? Или раскройте их глубже и шире или приведите источник этих высказываний.
6. «Ничего подобного. Молния не вызывает метод дерева „загорись“. Ни молния, ни ее энергия, ни излучение этой энергии не знают ни про дерево, ни про то что оно может гореть.»
Если грубо сказать, то у молнии есть метод «передать какое-то количество энергии в метод приёма энергии предмета». В свою очередь сам предмет(дерево в нашем случае) обрабатывая такое кол-во энергии видоизменяет свою структуру в виде реакции типа огонь. Если же количество энергии мало, то просто повышает свою температуру(случай когда солнце просто нагревает дерево). Надеюсь понятно объяснил.
7. «У ваших элементов нет, у других есть. Использовать одно из правильных значений типа в качестве обозначения ошибки в корне неверно. Собственно потому, что это значение правильное.»
Дабы не ошибиться, раскройте вопрос больше и желательно с помощью наглядных физических или химических опытов, экспериментов или примеров над реальными физическими объектами или их свойствами. Про NULL и про ошибки скажу в других частях в виде кода. Если будет интересно — просто подождите немного.
Пока что практика показывает, что отсутствие ООП — это страх и ненависть. В виде Win API до Delphi подобных языков, либо JS до TypeScript.
В каких именно случаях это происходит в РЕАЛЬНОМ мире?
желательно с помощью наглядных физических или химических опытов, экспериментов или примеров над реальными физическими объектами или их свойствами
А почему, собственно, нас должны волновать только "реальные физические объекты"? У вас программирование никогда не занимается задачами, связанными с другими объектами?
когда каждый лепит свою ничем не обоснованную реализацию в языке или парадигме
Обоснованную. Практической необходимостью.
Почитайте ссылки которые я дал, чтобы понять масштаб проблем.
Это их авторы считают, что это проблема. Ничего не мешает не пользоваться ООП тем, кому оно неудобно.
Кстати, как ваши определения их решают? Например, проблему создания многих объектов и сборки мусора, описанную по первой ссылке?
Что Вы подразумеваете под «что-то»? В каких именно случаях это происходит в РЕАЛЬНОМ мире?
Что-то — это обозначение того, что передается. Имущество, признаки, и т.д.
И то и другое передается от родителя к потомку в реальном мире.
В программировании передачу назвали по аналогии.
«интерфейс и реализация» — это НЕ наследование! Приведите, пожалуйста, источник (словарь как я понимаю) откуда Вы взяли такое определение.
«интерфейс и реализация» — это не наследование. Наследование это механизм их передачи от одного типа другому.
Наследование (программирование)
"концепция объектно-ориентированного программирования, согласно которой абстрактный тип данных может наследовать данные и функциональность некоторого существующего типа".
Наследование (право)
"Наследование — переход имущества, прав и связанных с ними обязанностей умершего лица (наследодателя) к иным лицам (наследникам)."
Наследование (биология)
Наследование — передача генетической информации (генетических признаков) от одного поколения организмов к другому.
Электрон — это физический объект. Я же приводил понятие «химический элемент» из АМУ
И зачем нужно определение химического элемента при задании способа моделирования, если оно не позволяет моделировать другие объекты?
Ею является моя попытка с помощью теории(в которую входит аналогия с химией) и доказательств
Чтобы использовать аналогию в рассуждениях, ее применимость сначала надо доказать. У вас нет в статье доказательств, только утверждения.
И нет, попытка провести аналогию это тоже не наука.
Может я что-то пропустил или не знаю, но откуда Вы взяли эти утверждения? Или раскройте их глубже и шире или приведите источник этих высказываний.
Источник фразы "Введение должно быть теоретически обосновано" это ваша статья.
Если вы приводите это как недостаток текущего использования ООП и причину отсутствия "научности", но сами этого не делаете, значит ваши рассуждения тоже ненаучны.
Требование необходимости и достаточности это часть логики, которая является частью научного метода.
Если грубо сказать, то у молнии есть метод «передать какое-то количество энергии в метод приёма энергии предмета».
Это не грубо, это неверно. Молния не знает ни про какой метод приема энергии ни у железа, ни у дерева, соответственно не может передать что-то именно туда.
Даже если допустить, что это так, то у любого объекта всегда будет один интерфейс из одного метода "принять сообщение". Значит ваше утверждение не имеет смысла, особенно с множественным числом слова "интерфейс".
раскройте вопрос больше и желательно с помощью наглядных физических или химических опытов, экспериментов или примеров над реальными физическими объектами или их свойствами.
А зачем? Аналогия с химическими объектами не доказана. А физические в ее рамках мы смоделировать не можем.
Я вам больше скажу. Алгоритм действий это не конкретное действие, это обобщение для действий в похожих ситуациях. При выполнении переменные принимают значения, соответствующие текущей ситуации. Что поместить в переменную, если в конкретной ситуации массива нет? Что поместить в переменную, если в коллекции нет запрошенного элемента?
Ладно алгоритм, а данные как хранить? Структура одна, а данных много. NULL — это отсутствие ссылки на объект. Отсутствие объектов в части ситуаций и есть причина его появления.
Даже если допустить, что это так, то у любого объекта всегда будет один интерфейс из одного метода "принять сообщение".
Ой, Smalltalk.
Обоснованную. Практической необходимостью.
Около 200 языков программирования это по-вашему необходимость? Список СУБД — где есть стандарт SQL и у каждого вендора есть поддержка этого стандарта + своя надстройка или расширение — это тоже необходимость? Может Brainfuck или другая эзотерика необходима в практике?
Кстати, как ваши определения их решают?
Это будет показано в следующих частях.
Например, проблему создания многих объектов и сборки мусора, описанную по первой ссылке?
Это уже детали реализации конкретного языка и наличия сборки мусора. К этой теме я даже не притрагивался и не собираюсь.
Что-то — это обозначение того, что передается. Имущество, признаки, и т.д.
И то и другое передается от родителя к потомку в реальном мире.
В каких реальных случаях это «что-то» передаётся? В случаях 2 гор или 2 ям или двух клеток или 2 атомов водорода? И что именно в этих случаях передаётся? Атомы, Кровь, ДНК или азотистые основания? И где в этих или других случаях родители и потомки?
«интерфейс и реализация» — это не наследование. Наследование это механизм их передачи от одного типа другому.
Тут что-то непонятное творится. Я задал вопрос:
И что значит само определение слова «наследование» в реальном мире?
Вы ответили:
Когда потомок получает что-то от предка. Можно было в словаре посмотреть. В случае с программированием это интерфейс и реализация.
И потом говорите это:
интерфейс и реализация — это не наследование
Вас ничего не смущает в Ваших же определениях?
Наследование это механизм их передачи от одного типа другому.
То есть по-вашему наследование это не передача чего-либо, а непосредственно вид, способ или процесс этой самой передачи?
И зачем нужно определение химического элемента при задании способа моделирования, если оно не позволяет моделировать другие объекты?
Химический элемент(атом) как раз и моделирует ВСЕ другие объекты.
Чтобы использовать аналогию в рассуждениях, ее применимость сначала надо доказать. У вас нет в статье доказательств, только утверждения.
В комментариях я признал, что не привёл доказательства перехода от фактов к утверждениям.
Это не грубо, это неверно. Молния не знает ни про какой метод приема энергии ни у железа, ни у дерева, соответственно не может передать что-то именно туда.
Даже если допустить, что это так, то у любого объекта всегда будет один интерфейс из одного метода «принять сообщение». Значит ваше утверждение не имеет смысла, особенно с множественным числом слова «интерфейс».
Как это «не знает»? Как это «не может»? У объекта не может быть по-вашему интерфейса принимающего энергию? А интерфейса принимающего гравитацию? Ну это еще рано об этом говорить. Давайте возьмём два примера для сравнения и анализа: Солнце и Дерево и Молния и Дерево. Что на что воздействует? В каком виде? Раскройте тему больше, пожалуйста. (Алан Кей выглядывает у Вас из-за спины с подсказками про сообщения?)
А зачем? Аналогия с химическими объектами не доказана. А физические в ее рамках мы смоделировать не можем.Затем, что я отвечаю на Ваши вопросы в виде дискуссии, а Вы не желаете делать также. Или Вы не дискутировать сюда пришли, а чисто высказать своё мнение в комментах?
Химический элемент(атом) как раз и моделирует ВСЕ другие объекты.
Эм. Химический элемент — это немножко не модель, он не предназначен для целей моделирования. И я что-то не вижу, как с помощью химического элемента как основы моделирования вы сделаете модель k-мерного пространства признаков.
Около 200 языков программирования это по-вашему необходимость?
Да. Потому что другие реализации по разным причинам не подходили. А может подходило ООП, но не подходила работа с параллельным выполнением кода. Сделали язык для параллельности, добавили ООП, похожее на другие языки. Все просто.
Это уже детали реализации конкретного языка и наличия сборки мусора. К этой теме я даже не притрагивался и не собираюсь.
А зря. Потому что из утверждения "Чем меньше тело класса и метода — тем лучше" напрямую следует, что самих объектов будет больше. И значит эту проблему он не решает.
В каких реальных случаях это «что-то» передаётся? В случаях 2 гор или 2 ям или двух клеток или 2 атомов водорода?
И что именно в этих случаях передаётся? Атомы, Кровь, ДНК или азотистые основания?
И где в этих или других случаях родители и потомки?
В случае наследования имущества — в случае смерти предка. Передается имущество.
В случае наследования признаков — в случае рождения потомка. Передаются признаки.
В случае наследования интерфейса и реализации — в случае объявления производного класса. Передается интерфейс и реализация.
Родитель — тот, от кого передается, потомок — тот, кому передается.
Непонятно, почему это вызывает у вас вопросы.
В случае 2 гор я не знаю что передается. 2 горы обозначаются двумя переменными одного типа.
2 типа гор могут обозначаться классами с наследованием. В естественных языках это выражается конструкциями наподобие "этот тип гор такой же как тот, только ...".
Тут что-то непонятное творится. Я задал вопрос:
Вы ответили:
Вас ничего не смущает в Ваших же определениях?
Нет. "Наследование — это когда потомок получает что-то от предка. В случае с программированием это 'что-то' — интерфейс и реализация. Передача интерфейса и реализации одного типа другому в языках программирования называется наследованием.".
То есть по-вашему наследование это не передача чего-либо, а непосредственно вид, способ или процесс этой самой передачи?
Вы смешиваете тип и экземпляр. Наследование двух конкретных классов это зкземляр. Наследование как механизм или концепция — это тип. Механизм наследования для краткости тоже называют наследованием.
В данном контексте определение из Википедии достаточно точное, я придерживаюсь его.
Химический элемент(атом) как раз и моделирует ВСЕ другие объекты.
Как вы смоделируете электрон химическими элементами? Они же у вас как минимум электрически нейтральные.
У объекта не может быть по-вашему интерфейса принимающего энергию? А интерфейса принимающего гравитацию?
А где он у реального дерева? Покажите. А если я подам энергию в интерфейс гравитации, оно мне Exception выбросит?
Нет. Есть внешние воздействия и законы физики. В пределах объекта мы можем обобщить законы физики до некоторого поведения этого объекта.
Но реакционные объекты сами ничего ничего не знают. Энергия при ударе молнии это сообщение. Куда оно уйдет и кто как его примет, в него не заложено.
Затем, что я отвечаю на Ваши вопросы в виде дискуссии, а Вы не желаете делать также.
Вы требуете от меня сделать что-то в рамках ваших утверждений, с которыми я и спорю. У конкретных физических объектов NULL-ов нет, но алгоритм это обобщение для многих конкретных запусков. Поэтому обосновать нужность или ненужность NULL с помощью физических экспериментов нельзя.
Зато в естественном языке, который тоже является обобщением, есть слова типа "нет", "никто", "никакой". Нет пользователя с таким ником, никто с таким ником не зарегистрирован.
В комментариях я признал, что не привёл доказательства перехода от фактов к утверждениям.
Ок. В таком случае данная статья бесполезна, критика ООП необоснована. Как и в других похожих статьях.
Да. Потому что другие реализации по разным причинам не подходили. А может подходило ООП, но не подходила работа с параллельным выполнением кода. Сделали язык для параллельности, добавили ООП, похожее на другие языки. Все просто.Тогда как Вы объясните Groovy, Kotlin, Ceylon, Scala? Что общего между ними? Они же на одной базе сделаны! Где там необходимость? Из недавних — Dart, Go, Swift — тоже необходимость? Вот как просто у Вас вышло что за 40-50 лет наплодили столько языков и всё из-за необходимости. А сколько будет из-за нее добавлено языков через 30 лет? Как же просто необходимостью оправдать появление огромного количества языков! И для поддержки параллельности нужно создавать новый язык с другим синтаксисом? Это необходимость?
В случае наследования признаков — в случае рождения потомка. Передаются признаки.
Вы уходите от ответов. Я задаю вопросы и ожидаю получить ответы на ВСЕ вопросы. Понимаете? А Вы их игнорируете или сознательно или не знаете что ответить — и то и другое говорит о многом. Вот пример: я задал вопросы про горы, ямы и атомы водорода и спрашиваю Вас: что именно передаётся в этих ВСЕХ случаях? В этих случаях есть наследование или нет? Где здесь предок, а где потомок? Какие именно объекты или информация или молекулы или атомы передаются? Надеюсь я понятно задал вопросы?
Нет. «Наследование — это когда потомок получает что-то от предка. В случае с программированием это 'что-то' — интерфейс и реализация. Передача интерфейса и реализации одного типа другому в языках программирования называется наследованием.»
Это Ваши цитаты и, как Вы подтвердили, ничего здесь Вас не смущает:
В случае с программированием это интерфейс и реализация.
интерфейс и реализация — это не наследование
Из определения из Вики о наследовании слова «наследовать данные и функциональность» не равны интерфейсу и реализации. Это просто данные и методы родительского класса (с различным уровнем доступа) к которым не всегда есть доступ. Вы, конечно же, можете сказать что реализация это и есть методы, но это не всегда так. Есть реализация и данные доступа к которым потомок не имеет.
Как вы смоделируете электрон химическими элементами?
Я не смогу этого сделать потому как электрон часть атома. Но мне это и не надо моделировать. Мне нужно с помощью атома, как кирпичика, моделировать ВСЕ остальные объекты которые из атомов состоят.
А где он у реального дерева? Покажите. А если я подам энергию в интерфейс гравитации, оно мне Exception выбросит? Нет. Есть внешние воздействия и законы физики.
Я не пойму — это Вы задали вопрос и сами же на него ответили или это ответ на мой вопрос? Как бы там ни было. Реальность и окружающий мир состоит из атомов. Поэтому и у «внешних воздействий» ВСЕГДА есть объект их вызывающий. То есть источник этих воздействий. Так вот — реакционные и атомарные объекты могут являться этими источниками.
У реального дерева — ВСЯ его поверхность имеет способность (читай метод) принимать энергетическое воздействие, а также механическое(другой метод) и гравитационное(третий) и так далее. Если же перепутать методы, то это будет как ошибка компиляции, а не Exception.
Энергия при ударе молнии это сообщение. Куда оно уйдет и кто как его примет, в него не заложено.
То есть молния и её энергия сами не знают куда ударят? Даже в молниеотводы? А как же шаровые молнии? Или по-вашему это и есть «сообщение»? А как быть с другими явлениями типа гравитации, химическими реакциями, магнетизмом и т.д.? Это тоже можно объяснить одними сообщениями?
Поэтому обосновать нужность или ненужность NULL с помощью физических экспериментов нельзя.Я не обосновываю нужность. Я говорю что в природе не существует NULL как объекта, ссылки на объект или что-то подобное. И в программировании такого быть не должно.
Нет пользователя с таким ником, никто с таким ником не зарегистрирован.А у объекта (который Вам это возвращает) метод возвращает единственное значение в виде ссылки на объект или коллекцию найденных совпадений? Ведь если бы возвращал коллекцию, то Вы бы про NULL и не узнали бы никогда?!
Ок. В таком случае данная статья бесполезна, критика ООП необоснована. Как и в других похожих статьях.
Какой чудесный вывод Вы сделали! То есть когда придумывали ООП о доказательстве не задумывались, а когда критикуют ООП доказательства уже нужны? Разве это не говорит о лицемерии? То есть в одном случае Вы верите на слово, а в другом требуете доказательств? Подождите немного и я предоставлю доказательства. Я понимаю что Вы и многие сюда зашедшие ожидали увидеть в малюсенькой статье(а большие статьи это же долго читать! Да и по ссылкам походить — что за садизм, верно?) научное обоснование программированию со всеми определениями и доказательствами и написанное понятным для всех языком. А у меня этого не получилось сделать. Здесь я виноват.
Я задаю вопросы и ожидаю получить ответы на ВСЕ вопросы. Понимаете?
При этом на чужие вопросы вы не считаете нужным отвечать. "Понимаете?"
Мне нужно с помощью атома, как кирпичика, моделировать ВСЕ остальные объекты которые из атомов состоят.
Как вы предлагаете моделировать объекты, которые не состоят из атомов?
Тогда как Вы объясните Groovy, Kotlin, Ceylon, Scala? Что общего между ними? Они же на одной базе сделаны! Где там необходимость?
Каждое ответвление языка было сделано для того, чтобы улучшить некоторые стороны Java. Более того, сама java переняла некоторые из этих улучшений.
Как по вашему можно объяснить существование белого и бурого медведя?
И для поддержки параллельности нужно создавать новый язык с другим синтаксисом? Это необходимость?
Можно не создавать целый язык, а сделать библиотеку к нему. В результате получится прослойка с собственным DSL, который подходит для решения конкретной задачи. По сути получится эдакий язык в языке.
Кстати, в какой момент начинается "новый" язык?
Можно ведь считать JVM языком, а Java, Kotlin, Scala — библиотеками для удобной работы с JVM.
На остальное отвечать не считаю нужным.
Тогда как Вы объясните Groovy, Kotlin, Ceylon, Scala? Что общего между ними? Они же на одной базе сделаны! Где там необходимость?
https://ru.wikipedia.org/wiki/Kotlin
"Авторы ставили целью создать язык более лаконичный и типобезопасный, чем Java, и более простой, чем Scala. Следствием упрощения по сравнению со Scala стали также более быстрая компиляция и лучшая поддержка языка в IDE."
На остальные языки, извините, лень искать. Попробуйте сами.
И для поддержки параллельности нужно создавать новый язык с другим синтаксисом? Это необходимость?
Да. Для того, кому нужно, это необходимость. Вы добавите в свой язык параллельность, которая нужна мне, но которая противоречит архитектуре вашего языка? Ну чтобы я мог написать go foobar и оно как в go работало, на ядра там распределялось и прочее?
Вы уходите от ответов. Я задаю вопросы и ожидаю получить ответы на ВСЕ вопросы. Понимаете?
Я вам ответил на все вопросы. Вы спросили, "что передается?". Почему вы прямой ответ "передаются признаки" считаете уходом от ответа?
Вот пример: я задал вопросы про горы, ямы и атомы водорода и спрашиваю Вас: что именно передаётся в этих ВСЕХ случаях? В этих случаях есть наследование или нет? Где здесь предок, а где потомок? Какие именно объекты или информация или молекулы или атомы передаются? Надеюсь я понятно задал вопросы?
Про две горы я вам ответил — ничего не передается, в программе это две переменные одного типа, наследования тут нет. Вы хотите, чтобы я вам то же самое написал про атомы водорода? Я рассчитывал, что вы понимаете, что ответ для них тот же самый.
В случае с двумя типами гор при наследовании передаются признаки уже существующего типа. Предок — первый тип (существующий), потомок — второй тип (определяемый).
Надеюсь, я понятно ответил?
Есть реализация и данные доступа к которым потомок не имеет.
А причем здесь прямой доступ? Доступ имеют методы родителя, следовательно, чтобы они работали в потомке, он должен унаследовать и их в скрытом виде. То же относится и к полям класса.
Я не смогу этого сделать потому как электрон часть атома. Но мне это и не надо моделировать.
То есть либо в рамках вашей теории мы не можем моделировать процессы, связанные с электронами, либо определение химического элемента в вашей теории не нужно, так как объект в ней это просто мелкая единица, и она вполне может обозначать электрон или любой другой физический объект меньше атома.
Вам не надо, а другим надо. Вот и еще одна причина для другого языка нарисовалась.
То есть молния и её энергия сами не знают куда ударят?
Да. В реальности молния не знает интерфейсов, ничего ни у кого не вызывает, не передает значения аргументов, не контролирует их типы. Мы можем такое написать в программе, чтобы смоделировать поведение, но это не свойство реальных объектов, следовательно оно не может являться часть вашей теории.
Это тоже можно объяснить одними сообщениями?
Это можно объяснить законами физики. Ученые еще не всё объяснили, а вы от меня требуете. И да, квант энергии это вполне себе сообщение, которое меняет состояние атома.
Я говорю что в природе не существует NULL как объекта, ссылки на объект или что-то подобное. И в программировании такого быть не должно.
Вот если бы мы писали отдельную программу на каждую конкретную ситуацию с конкретным набором объектов, и она запускалась только один раз, как это и происходит в реальности, тогда да, можно было бы обойтись без NULL.
Но так как программа одна, но моделирует много ситуаций, то нужно как-то обозначать отсутствие объекта в некоторых из них.
Ведь если бы возвращал коллекцию, то Вы бы про NULL и не узнали бы никогда?!
А зачем мне там коллекция, если мне нужен конкретный объект из нее с конкретными свойствами? Ну ок, вот есть у меня коллекция, как из нее получить объект, у которого поле nick = 'My nick'?
Я вас уже об этом спрашивал. Почему вы высказываете мне претензии, что я якобы игнорирую ваши вопросы, при этом сами так поступаете?
То есть когда придумывали ООП о доказательстве не задумывались, а когда критикуют ООП доказательства уже нужны?
Когда придумывали ООП, никого не критиковали. Я вам уже сказал — его придумали, потому что была практическая необходимость. Придумали и пользуются. Не нравится, не пользуйтесь, никто вас не заставляет. А доказательства нужны при любой критике, не только при критике ООП.
Надеюсь, я понятно ответил?
Да, понятно. И новый вопрос по этой теме: Как часто у реальных объектов встречается наследование и механизм передачи признаков? Можно сказать что во всех живых существах? Если да, то КАКИЕ именно признаки передаются? Информация от предка потомку в виде азотистых оснований. И всё это только при создании зародыша нового живого объекта. Только в 1 случае из всего многообразия объектов, их поведения и данных. Другими словами в природе наследование — всего лишь набор информации переданный от предка потомку при его создании (или другим способом размножения).
А причем здесь прямой доступ?Здесь оспаривать не буду потому как я говорю за Java и PHP, а у Вас может быть другой язык и соответственно реализация наследования там может быть другой.
То есть либо в рамках вашей теории мы не можем моделировать процессы, связанные с электронами, либо определение химического элемента в вашей теории не нужно, так как объект в ней это просто мелкая единица, и она вполне может обозначать электрон или любой другой физический объект меньше атома.В рамках химии(классической, а не квантовой) атом — мельчайший химически неделимый элемент и, действительно, процессы связанные с электронами она не может моделировать. Если Вы или кто-то другой построит теорию на основе квантовой физики я буду только рад и приветствовать.
Вам не надо, а другим надо. Вот и еще одна причина для другого языка нарисовалась.Так я против этого и возражаю. Что ни чих, то причина и она же, о совпадение!, необходимость! И у нас появился новый язык! Видели картинку в комментах про новый стандарт?
Да. В реальности молния не знает интерфейсов, ничего ни у кого не вызывает, не передает значения аргументов, не контролирует их типы.Согласен.
Мы можем такое написать в программе, чтобы смоделировать поведение,
Тут согласен тоже, потому как в ЯП у нас есть только данные и методы.
но это не свойство реальных объектов, следовательно оно не может являться часть вашей теории.Что не свойство реальных объектов? Подробнее можете сказать или другими словами. Я же вроде написал про источник энергии и остальные процессы…
Это можно объяснить законами физики. Ученые еще не всё объяснили, а вы от меня требуете.Эти сообщения одного типа или разного? Может я что-то не понял…
Я вас уже об этом спрашивал. Почему вы высказываете мне претензии, что я якобы игнорирую ваши вопросы, при этом сами так поступаете?Не увидел. подскажите, может я пропустил… Но вроде бы не спрашивали.
Когда придумывали ООП, никого не критиковали.Даже не знаю что и сказать на это. ООП настолько свято было, что его создали без критики? Серьезно? А необходимость возникла потому что ...? Наверное потому что что-то не устраивало в прошлой парадигме? Или по другой необходимости?
Если Вы или кто-то другой построит теорию на основе квантовой физики я буду только рад и приветствовать.
Вы же только что говорили, что должна быть одна правильная теория?
Не увидел. подскажите, может я пропустил…
Вам серьезно список нужен?
На мой вопрос «Где там необходимость?» Вы так и не ответили, а просто привели цитату
ну просто золотая необходимость
Я не являюсь разработчиком языка Kotlin, поэтому не могу отвечать за них. То, что написано в цитате, для меня является достаточным обоснованием необходимости.
Почему вы считаете, что раз вам не надо, то и другим должно быть не надо?
Как часто у реальных объектов встречается наследование и механизм передачи признаков?
А какая разница? Передача признаков от предка к потомку люди называют наследованием. Тот же процесс для типов в программировании назвали по аналогии. Всё.
Здесь оспаривать не буду потому как я говорю за Java и PHP
В PHP private-свойства присутствуют в потомке.
php -r "class A { private $x = 1; } class B extends A { public $y = 2; } var_dump(new B());"
Command line code:1:
class B#1 (2) {
public $y =>
int(2)
private $x =>
int(1)
}В рамках химии(классической, а не квантовой) атом — мельчайший химически неделимый элемент
А зачем нам рамки химии? Особенно если они не позволят моделировать все что нам надо?
Так я против этого и возражаю. Что ни чих, то причина и она же, о совпадение!, необходимость!
И что, вам жалко что-ли? В чем причина вашего возражения? Да, это необходимость. Для других, не для вас. Я вас спросил про параллельность, нужную лично мне, вы почему-то тоже не ответили.
Что не свойство реальных объектов?
Интерфейсы и их "знание" у реакционных объектов.
Не увидел. подскажите, может я пропустил
Ctrl+F "в коллекции"
В данном случае мне нужен не столько ответ, сколько отсутствие высокомерных претензий "Я вас спросил, значит вы должны ответить". Я тоже могу что-то пропустить.
ООП настолько свято было, что его создали без критики?
Почему что-то обязательно должно быть свято? Других причин для отсутствия критики нет?
Наверное потому что что-то не устраивало в прошлой парадигме?
Да, именно поэтому. С процедурным программированием были проблемы, некоторые люди предложили способ их решения. Зачем тут что-то критиковать или доказывать?
Если вы описание проблем считаете критикой, значит признание их наличия без способа, который их решает, и отсутствия с применением этого способа, это доказательство нужности способа. Следовательно, ваше утверждение "То есть когда придумывали ООП о доказательстве не задумывались" неверно. В вашей статье нет доказательств отсутствия проблем с применением вашего способа, даже по поводу наличия проблем есть сомнения.
То, что написано в цитате, для меня является достаточным обоснованием необходимости.И в объяснении и доказательствах это не нуждается, верно? Значит Вам можно рассказывать любые сказки, да? Лишь бы Вы в них поверили…
А какая разница?Большая! Если 1% людей верит в Ктулху и совершает религиозные танцы, то и Вы поверите и будете танцевать. Ведь разницы нет по-вашему! Я думаю удачно подобрал аналогию и Вы её поняли.
В PHP private-свойства присутствуют в потомке.Это просто шедевр! Вы попробуйте это на собеседовании или экзаменах сказать! Не надо позориться… И функция var_dump о рекурсии и обо всех уровнях доступа расскажет.
А зачем нам рамки химии? Особенно если они не позволят моделировать все что нам надо?Вы не читали мой ответ?
«Если Вы или кто-то другой построит теорию на основе квантовой физики я буду только рад и приветствовать.»
И что, вам жалко что-ли? В чем причина вашего возражения? Да, это необходимость.В комментариях выше уже рассказывали про языки почему это плохо. Ознакомьтесь с теориями про плоскую Землю, русалок, кэндимена, слендермена и ангелов — думаю Вам зайдет! Там такой же подход…
Я вас спросил про параллельность, нужную лично мне, вы почему-то тоже не ответили.Это тема отдельной статьи. Кто, для кого и зачем — слишком долго писать.
Почему что-то обязательно должно быть свято? Других причин для отсутствия критики нет?Есть конечно. Просто посыл Ваших слов я так воспринял. Возможно ошибочно. Только вот если что-то доказано и работает хорошо, то это не меняют. Так как нет критики. Если же критика есть, то это меняют. Логично?
Что поместить в переменную, если в конкретной ситуации массива нет? Что поместить в переменную, если в коллекции нет запрошенного элемента?Я думал это были риторические вопросы. Отвечаю: оперируйте не переменными, а коллекциями. Попытайтесь возвращать не одну ссылку на объект, а коллекцию.
Ладно алгоритм, а данные как хранить? Структура одна, а данных много. NULL — это отсутствие ссылки на объект. Отсутствие объектов в части ситуаций и есть причина его появления.
Если вы описание проблем считаете критикой, значит признание их наличия без способа, который их решает, и отсутствия с применением этого способа, это доказательство нужности способа. Следовательно, ваше утверждение «То есть когда придумывали ООП о доказательстве не задумывались» неверно. В вашей статье нет доказательств отсутствия проблем с применением вашего способа, даже по поводу наличия проблем есть сомнения.Напишите статью на эти высказывания — я там в комментариях пройдусь по логическим умозаключениям и выводам.
Отвечаю: оперируйте не переменными, а коллекциями. Попытайтесь возвращать не одну ссылку на объект, а коллекцию.
И каждый раз проверять, что в этой коллекции не больше одного элемента?
И в объяснении и доказательствах это не нуждается, верно?
Это и есть объяснение.
Лично мне никакие доказательства не нужны, так как появление Kotlin меня ни к чему не обязывает.
Я думаю удачно подобрал аналогию и Вы её поняли.
Не понял. Я ничего не говорил ни про веру, ни про маленькие проценты. Не могли бы провести параллели между сущностями вашего высказывания и моего?
Это просто шедевр! Вы попробуйте это на собеседовании или экзаменах сказать!
Не могли бы вы формулировать ответ явно, если вам кажется, что что-то не так? Вы отрицаете правильность работы var_dump()?
Вы не читали мой ответ?
Я не вижу, каким образом он доказывает необходимость рамок химии. И вообще, рамок каких-либо других наук, кроме информатики и применяемых в ней математических методов.
В комментариях выше уже рассказывали про языки почему это плохо.
Я не вижу там ответа на вопрос, почему нельзя делать языки, которые делают что-то лучше существующих.
Отвечаю: оперируйте не переменными, а коллекциями.
И про это я тоже вас спросил, в следующем комментарии. Как мне из коллекции получить конкретный объект с заданным значением поля? Когда-то надо будет перейти от работы с коллекцией к работе с объектом.
Почему вообще проверка количества на 0 лучше проверки переменной на null?
Напишите статью на эти высказывания — я там в комментариях пройдусь
Что вам мешает отвечать на вопросы в комментариях здесь?
Я не собираюсь ничего писать, я просто обосновал свой "чудесный вывод", почему статья бесполезна.
думаю Вам зайдет
Ну вот, переход на личности. Вы, похоже, по-другому не умеете вести дискуссию. Поскольку я уже несколько раз повторился по некоторым вопросам, то не вижу смысла продолжать.
Это и есть объяснение.Как раз такое отношение и называется религией, лженаукой или догматикой.
Лично мне никакие доказательства не нужны, так как появление Kotlin меня ни к чему не обязывает.
Не могли бы вы формулировать ответ явно, если вам кажется, что что-то не так? Вы отрицаете правильность работы var_dump()?Это просто позор услышать такое (То что вы сейчас сказали: «В PHP private-свойства присутствуют в потомке.») от PHP-разработчика. Вы написали такой бред, что мне даже стыдно это обсуждать, а Я даже ссылку дал, но даже такой намек неподвластен Вам! Найдите адекватного PHP-разработчика и пускай он Вам ответит в чём Вы неправы. Но если не получится, зайдите на Stackoverflow — там обязательно помогут!
Лично мне никакие доказательства не нужны
Не понял.
Я не вижу
Как мне из коллекции получить конкретный объект с заданным значением поля?
Почему вообще проверка ...
Я не собираюсь ничего писать, я просто обосновал свой «чудесный вывод», почему статья бесполезна.
Может быть вы попали в калашный ряд с таким уровнем вопросов?
Ну вот, переход на личности.Здесь Вы вообще не правы. Я лишь предположил, что моё предложение Вам может понравится на основе анализа Ваших высказываний.
Аргумент ad hominem вас не красит. А на вопросы вы так и не отвечаете, что характерно.
Я даже ссылку дал
Вот вам ссылки на исходники:
ZEND_API void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce)
{
...
ZEND_HASH_FOREACH_STR_KEY_PTR(&parent_ce->properties_info, key, property_info) {
do_inherit_property(property_info, key, ce);
} ZEND_HASH_FOREACH_END();
...
}static void do_inherit_property(zend_property_info *parent_info, zend_string *key, zend_class_entry *ce)
{
...
{
...
child_info = parent_info;
}
_zend_hash_append_ptr(&ce->properties_info, key, child_info);
}Остальное комментировать не буду.
В PHP private-свойства присутствуют в потомке.
А как к ним получить доступ? Например,
class Hello
{
private $hello = 'Hello';
private function getHello():string
{
return $this->hello;
}
...
}А причем здесь прямой доступ? Разговор был о том, что наследование это передача потомку интерфейса и реализации.
Возможно не при чем и я просто запутался, в таком случае прошу прощения и вопрос снимаю, ввиду отсутствия желания еще раз перечитывать и вникать.
Я вообще не понимаю, зачем автору статьи понадобилось определение слова «наследование» тем более с аналогией реального мира. Наследование вытекает из отношения «is a», оно не нуждается в определении и неправильно проводить аналогию с нашим «реальным» миром.
Из определения из Вики о наследовании слова «наследовать данные и функциональность» не равны интерфейсу и реализации. Это просто данные и методы родительского класса (с различным уровнем доступа) к которым не всегда есть доступ. Вы, конечно же, можете сказать что реализация это и есть методы, но это не всегда так. Есть реализация и данные доступа к которым потомок не имеет.
Данные и функциональность как раз и определяют интерфейс и реализацию.
Реализация — это все переменные, константы и методы класса со всеми их признаками (типы, и инициализация для переменных, значения для констант, тип возвращаемого значения и типы параметров для методов).
Интерфейс — это описание доступа к переменным, методам и константам извне объекта, которое определяется особенностями определения переменных, констант и методов класса.
Наследование данных в данном контексте — это наследование набора переменных и констант, а не наследование конкретных значений, присваиваемых переменным в процессе существования класса.
И следует понимать разницу между классом и объектом.
Класс — это общее описание всех объектов, обладающих общими признаками.
Объект — это конкретный экземпляр класса.
Наследуют именно классы, а не объекты.
Справедливости ради можно упомянуть, что в некоторых языках благодаря неосторожному введению ключевых слов может возникнуть некоторая путаница.
Например, слово object в Object pascal (оно же Delphi с некоторым допущением) определяет не объект, а класс объектов. Но в последних версиях от этой проблемы отошли, предложив использовать для определения классов слово class.
В результате многие дельфоводы запустили в обиход использование слова объект в значении класс (а вместо нормального объекта у них экземпляр объекта).
Но при должном внимании эта терминологическая не должна вводить в заблуждение.
Я не смогу этого сделать потому как электрон часть атома. Но мне это и не надо моделировать. Мне нужно с помощью атома, как кирпичика, моделировать ВСЕ остальные объекты которые из атомов состоят.
Ваша модель годится только для моделирования химических и физических процессов на уровне атомов.
А реальное программирование завершает модель не на уровне "мельчайших частиц", а на уровне, ниже которого рассматривать процесс не интересно.
В результате даже многие химические процессы будут описываться моделью, мельчайшим элементом в которой будут молекулы, а не атомы.
В других случаях мельчайшим объектом будут целые звезды и планеты, поскольку для моделирования солнечной системы не нужен не только уровень атомов, но и уровень внутреннего строения планет и звезды.
В третьем случае объектами моделирования будут абстрактные понятия (если все пространство модели абстрактно, например, в случае математической модели, не связанной с физическим миром).
Я не обосновываю нужность. Я говорю что в природе не существует NULL как объекта, ссылки на объект или что-то подобное. И в программировании такого быть не должно.
В природе очень даже есть. Например, дырки в полупроводниках.
NULL среди прочего позволяет кодировать факт отсутствия чего либо в рамках модели, если это важно для поведения объекта (в том же SQL оно именно в этом смысле и употребляется). В других случаях это не более чем 0.
Ваша модель годится только для моделирования химических и физических процессов на уровне атомов.Подождите с такими выводами до следующих статей. Или почитайте этот комментарий
А реальное программирование завершает модель не на уровне «мельчайших частиц», а на уровне, ниже которого рассматривать процесс не интересно.Но молекула — это множество атомов(бывает что из одного атома). Таким образом Ваше высказывание может быть ошибочным, если сделать замену слов: «В результате даже многие химические процессы будут описываться моделью, мельчайшим элементом в которой будут множества атомов, а не атомы.» Просто если принять, что ВСЕ химические процессы проходят над множествами атомов, то всё станет на свои места и не будет путаницы с определением «молекулы» и «многие химические процессы».
В результате даже многие химические процессы будут описываться моделью, мельчайшим элементом в которой будут молекулы, а не атомы.
В природе очень даже есть. Например, дырки в полупроводниках.Если Вы посмотрите в вики на картинку справа и увидите там количество(то бишь множество) электронов(в количестве 2 штук), протонов(в количестве 2 штук) и нейтронов(в количестве 2 штук). Электронов в атоме гелия 2 штуки.
Когда электрон покидает атом гелия, на его месте остается дырка.Что это значит? Множество электронов из 2 штук стало множеством электронов из 1 штуки. То есть «дырка» — это состояние атома без одного электрона из множества электронов которые там были. И NULL тут не при чём.
Что же касается SQL, то это реализация языка с понятием NULL и это неправильно и так быть не должно.
Что же касается SQL, то это реализация языка с понятием NULL и это неправильно и так быть не должно.
… и чем вы обоснуете это громкое утверждение?
Подождите с такими выводами до следующих статей. Или почитайте этот комментарий
В идеальном мире можно построить модель Всего, позволяющую рассчитать Все.
На практике оно не влезет в память компьютера. А если и влезет, то обсчитываться будет годами.
Потому при реальном программировании (да и при любом моделировании) модели упрощают до разумных пределов.
Но молекула — это множество атомов(бывает что из одного атома). Таким образом Ваше высказывание может быть ошибочным, если сделать замену слов: «В результате даже многие химические процессы будут описываться моделью, мельчайшим элементом в которой будут множества атомов, а не атомы.» Просто если принять, что ВСЕ химические процессы проходят над множествами атомов, то всё станет на свои места и не будет путаницы с определением «молекулы» и «многие химические процессы».
В определенных ситуациях (например, моделирование процесса аминирования) может быть чхать на то, из каких именно атомов состоит молекула, если она достаточно сложна.
А потому базовым объектом модели может стать молекула, с которой происходит преобразование в виде замены гидроксильной группы на аминогруппу.
В результате имеем вполне себе химическую реакцию и ни одного атома в модели.
Конечно, понятно, что молекула состоит из атомов, и гидроксильная с аминной группы состоят из атомов. Но эти детали не имеют значения с точки зрения получения результата, для которого достаточно присутствия в модели молекулы и набора заменяемых групп в этой молекуле.
Дырка — это не состояние атома, а квазичастица. аналог квазизначения NULL. Если мы строим модель кристаллической решетки полупроводника в соответствии с типичным представлением процесса в физике, то можно вполне использовать для дырки значение NULL, а для электрона или ядра атома экземпляры соответствующих классов (ядро атома, электрон).
Дырка — это не состояние атома, а квазичастица. аналог квазизначения NULL. Если мы строим модель кристаллической решетки полупроводника в соответствии с типичным представлением процесса в физике, то можно вполне использовать для дырки значение NULL, а для электрона или ядра атома экземпляры соответствующих классов (ядро атома, электрон).Вас хлебом не корми — дай набить всё NULL-ами!
Приведу цитаты из вики: «В физике твёрдого тела ды́рка — это отсутствие электрона в почти полностью заполненной валентной зоне.»
Тут аналогия как я и сказал(сидит множество людей и один из этого множества уходит): «имеется ряд людей, сидящих в аудитории, где нет запасных стульев. Если кто-нибудь из середины ряда хочет уйти, он перелезает через спинку стула в пустой ряд и уходит. Здесь пустой ряд — аналог зоны проводимости, а ушедшего человека можно сравнить со свободным электроном. Представим, что ещё кто-то пришёл и хочет сесть. Из пустого ряда плохо видно, поэтому там он не садится. Вместо этого человек, сидящий возле свободного стула, пересаживается на него, вслед за ним это повторяют и все его соседи. Таким образом, пустое место как бы двигается к краю ряда. Когда это место окажется рядом с новым зрителем, он сможет сесть. „
“Термин ды́рка также используется в вычислительной химии, где основное состояние молекулы интерпретируется как вакуумное состояние — в этом состоянии нет электронов. В такой схеме отсутствие электрона в обычно-заполненном состоянии называется ды́ркой и рассматривается как частица. А присутствие электрона в обычно-пустом пространстве просто называют электроном. „
Я говорю что в природе не существует NULL как объекта, ссылки на объект или что-то подобное.
Вы никогда не видели прочерк, или "нет данных", или n/a в заполняемых анкетах?
Если исключить из ЯП (Язык Программирования) возможность наследования, статические методы и атрибуты, абстрактные классы, то в проекте код станет минимум на 10-20 процентов меньше.Вы хотели сказать «больше»? Так как все перечисленное избавляет от повторения кода.
Если исключить из кода в проекте все антишаблоны проектирования, то код станет минимум на 10-15 процентов меньше.Мне нравится когда «научная» статья оперерует цифрами взятыми с потолка. 10-15 как было получено? И да, «антишаблоны» наверно лучше не использовать (судя по названию, это плохо), но вот что именно антишаблоны — непонятно. Надеюсь вы не называете ООП антишаблоном?
Чем меньше и проще объекты, тем проще их понимать, тестировать и изменять.Кэп не смог бы выразить мысль лаконичнее. Чтобы добавить выразительности, вы добавили еще 3 пункта повторяющие идею и ссылающиеся на нее. Статья заслуживает своих оценок.
Тем не менее, я считаю такие вот статьи очень полезными. Во-первых, они «учат» других не делать так же. Во-вторых, оценка статьи должна донести автору мысль, что «что-то» не так и возможно мы никогда не увидим «часть вторую» (что есть хорошо).
Название элемента
Масса
Группа
Период
Металл/Не металл
Подгруппа (буквы А и В. Не помню, что они значат)
Порядковый номер
Расположение электронов на орбитах
Это уже 8. Уверен, что настоящим химикам потребуется больше полей для создания объекта. И в чём тогда новизна?
Научное программирование: часть 1