Примерно пять лет тому назад, по просьбе моего дяди, я разместил его статью тут, в Хабре, которая содержала аргументы, вызывающие вопросы к теории относительности. Его целью было стимулировать критическое мышление в научном сообществе и получить от него конструктивный отклик или поддержку. К сожалению, комментарии заполнились большим количеством негатива, выраженного в детских высказываниях. Однако, стремясь дать второй шанс, по его же просьбе я снова опубликовал переработанную версию статьи.
Вот скажите... Ваш дядя знает про научные журналы, про arxive.org, вообще как нужно набрасывать на вентилятор в науке? Почему за пять лет он не вступил в переписку с известными учёными, не получил от них рецензии? Если бы у него был науч-поп -- это можно было бы понять, но у него как бы "original research". Что именно вы хотите от местных читателей, 99% которых не то что физику, математику на уровне технического вуза не знают?
PS: статья состоит из высказываний школьника, теперь понятно, почему её не шлют в журналы.
Когда мы говорим о парадигме ООП, то мы имеем ввиду вполне конкретные вещи.
Именно. И эти вещи: (1) всё есть объект и (2) объекты взаимодействуют путем посылки сообщений. Вот и все принципы. Всё прочее -- это частности реализации.
А именно, возможность инкапсуляции методов и свойств в классы с применением наследования и полиморфизма.
Классы и наследование -- это частный случай реализации. Есть языки, в которых вместо них используются прототипы и композиция. Слово "полиморфизм" вообще не люблю. Что оно значит вне конкретных языков? В терминологии C++ полиморфная функция может принимать аргументы разных типов. Причём тут ООП? Это ближе к метапрограммированию. То, что разные объекты по разному отвечают на одни и те же сообщения -- является их базовым свойством.
Ещё у вас противоречащие пункты. Вот вы пишите, что:
Этот подход к организации и проектированию кода стал возможным потому, что однажды удалось добиться сохранения кадра стека вызова функции в динамической памяти. То есть, появилась возможность сохранить состояние вызываемого кода на разных этапах выполнения.
Угу, то есть частности низкоуровневой реализации сделали возможным ООП. Ну, хорошо. Но ниже, вы уже ставите телегу впереди лошади:
И существует оно для решения нескольких задач. Первая задача связана с сохранением состояния вызова функции на разных этапах её выполнения. Вторая задача - избегание повторения кода за счёт наследования или полиморфизма функций, посредством использования ссылок на них.
То есть ООП нужно, чтобы сохранить состояние вызова функции? Причём тут вообще вызовы и состояния функций? Почему вы их пихаете во все комменты?
ООП -- это концепция высокого уровня. На этом уровне нет ни функций, ни вызовов, ни указателей, -- это всё частности реализации не только языков, но и машин. На уровне ООП есть лишь объекты и сообщения.
Ещё в статье восхищает использование доисторической терминологии "посылка сообщения" вместо современной "вызов метода".
Ну что за чушь! Посылка сообщений и вызов методов – принципиально разные вещи!
Сообщение – это объект, состоящий из текстовой строки (имени сообщения) и возможного списка аргументов.
Метод – это объект, реализующий некоторую функциональность, проще говоря функция, привязанная к объекту.
Посылка сообщения – это способ коммуникации объектов. Объект, получивший сообщение, сам решает, как ему поступить с ним. Он может (1) ничего не ответить, (2) вызвать метод, соответствующий имени сообщения, (3) выбросить исключение или (4) переслать сообщение иному объекту.
Вызов метода – это вызов некоторой функции, привязанной к объекту, и передача ей возможных аргументов, вот и всё. Так что вызов метода – это лишь один из многих возможных способов реакции объекта на полученное сообщение.
Механизм сообщений является неотъемлемой частью ООП, но используется и вне его. Например, все распределённые системы параллельных вычислений (MPI) используют посылку сообщений. Поскольку сообщение – это текстовая строка и список аргументов, его можно послать по сети. Вызвать функцию или метод по сети нельзя (если вы не знали). Межпроцессные коммуникации (IPC) также используют механизм сообщений. Ибо вызвать функцию или метод из иного процесса тоже нельзя.
Так что в жизни вы постоянно используете сообщения, просто не знаете это, как и многие иные вещи.
И ни в каком языке программирования для вызова методов сообщения не посылаются.
Вы так пишите, словно Smalltalk исчез. Он живёт и используется в промышленном программировании. Не в РФ, конечно. Из более новых языков сообщения используются в Ruby.
Ну, с определëнными допущениями, условиями и расширениями, тьюринг-машину можно собрать теоретически на чëм угодно.
Щито? Это математика, в ней теорема или верна, или не верна. Она не может быть верна наполовину. Язык или тьюринг-полный, или не трьюринг-полный. Если его семантика эквивалентна машине Тьюрига, он тьюринг-полный.
И очередное неправомерное приписывание изобретения современного ООП Алану Кею.
Более чем правомерное. Именно Алан Кэй впервые сформулировал концепцию современного ООП и употребил это выражение.
То ООП которое мы знаем было реализовано в С++ Страуструпом, далее распространилась по остальным языкам: Java, C# и т.п..
Вот это вообще хтоническая чушь! Вы учили программирование на говнокурсах? То ООП, которое вы знаете -- это не ООП, а абстрактные типы данных. Многие их путают -- и это неправильно. ООП -- это объекты и обмен сообщениями.
Впервые же объектные принципы (объекты, классы, наследование и иные вещи) были реализованы в 1961 - 1967 в языке Simula. Это самая ранняя реализация некоторых концепций ООП.
Страуструп не изобрел ООП, он взял его из Simula. И ООП в C++ является набором костылей, прикрученных поверх C, и нужных, чтобы улучшить скорость выполнения. Нормальная реализация ООП поверх C есть в Objective-C.
Но вернёмся к истинному ООП. Гений Алан Кэй, посмотрев на Simula, понял, что можно сделать ещё лучше. И в 1967 впервые сформулировал концепцию современного ООП и, что принципиально, употребил это выражение в разговоре. Так что именно он является отцом современного ООП.
Первый язык, реализующий современное ООП вышел в 1972, и это был Smalltalk. Он вполне жив и применяется в промышленном программировании.
Имею некоторое мнение. Курсы, которые учат с нуля -- не нужны. Программирование -- это сложная инженерия, и ей нельзя научиться на курсах. Ну то есть нельзя быть барменом, и внезапно через несколько месяцев стать инженером.
Чтобы стать хорошим программистом нужно иметь бакалавриат по математике или информатике и магистратуру по инженерии. Поэтому курсы нужны иные -- по конкретным технологиям, чтобы инженеры, выпускники вузов, имеющие теоретические знания, изучили конкретные технологии, применяемые в промышленном программировании.
Программист -- это инженер, пилот -- это пользователь. После курсов нельзя стать инженером, нужно естественнонаучное или инженерное образование, а не курсы в несколько месяцев.
Ну, вообще ничего такого. Если учёный не живёт в РФ и не работает в РФ, то он уже и не российский. Было бы весьма странно отказывать учёному лишь по цвету его паспорта. Этим грешат лишь несколько истеричных европейских стран. Причём именно тех, через которые российские чиновники ввозят и вывозят санкционные товары.
Вот человек, казалось бы, умными вещами занимается, а такую чушь пишет.
Какой язык программирования учить, чтобы работать с нейросетями? И, как не крути, ответ один - это Python. Хотите ли вы или нет, любите ли вы его или ненавидите, но это ничего не изменит, так как в нейросетях Python - царь горы, на нем здесь работает все!
Нет, не все! Мы будем писать на том, что нам нравится. Python поощряет писать ужасные программы. Виной этому низкий порог. На C или C++ вы не напишете программу, если вы не знаете язык хорошо и не разбираетесь в программировании. Ибо она у вас просто не запустится. Чтобы писать программы на C / C++ вам нужно много знать.
К счастью, физики в основном всё ещё пишут на Fortran. Но многие биологи и и биоинформатики, увы, пишут на Python. Поэтому мы имеем кучи ужасно написанных бибилиотек, написанных учёными, не умеющими программировать, не понимающими ничего в программировании.
Итак, для разработки ПО смело учите JavaScript, он и популярен и эффективен, и отрицать это было бы очень глупо.
Oh, boy, here we go! Как вообще можно написать серьёзную программу типа научных программ, фото-, видео-, аудиоредакторов и компьютерных игр на JavaScript? Ещё есть и системное программирование! Похоже, что он считает, что разработка ПО ограничивается вебом и ботами.
Вы в курсе, что наркоз -- это серьёзная травма мозга и вообще организма?
Интервью со Стефани Планк из Covalent Bioscience
Вы иной иммунотерапии не знаете? Ну там CAT-T, TIL? Ещё есть генные терапии и THIO, о которых много написано в моём блоге.
Вот прямо пригорело. Ваш дядя вообще wikipedia.org читал?
Вот скажите... Ваш дядя знает про научные журналы, про arxive.org, вообще как нужно набрасывать на вентилятор в науке? Почему за пять лет он не вступил в переписку с известными учёными, не получил от них рецензии? Если бы у него был науч-поп -- это можно было бы понять, но у него как бы "original research". Что именно вы хотите от местных читателей, 99% которых не то что физику, математику на уровне технического вуза не знают?
PS: статья состоит из высказываний школьника, теперь понятно, почему её не шлют в журналы.
Именно. И эти вещи: (1) всё есть объект и (2) объекты взаимодействуют путем посылки сообщений. Вот и все принципы. Всё прочее -- это частности реализации.
Классы и наследование -- это частный случай реализации. Есть языки, в которых вместо них используются прототипы и композиция. Слово "полиморфизм" вообще не люблю. Что оно значит вне конкретных языков? В терминологии C++ полиморфная функция может принимать аргументы разных типов. Причём тут ООП? Это ближе к метапрограммированию. То, что разные объекты по разному отвечают на одни и те же сообщения -- является их базовым свойством.
Ещё у вас противоречащие пункты. Вот вы пишите, что:
Угу, то есть частности низкоуровневой реализации сделали возможным ООП. Ну, хорошо. Но ниже, вы уже ставите телегу впереди лошади:
То есть ООП нужно, чтобы сохранить состояние вызова функции? Причём тут вообще вызовы и состояния функций? Почему вы их пихаете во все комменты?
ООП -- это концепция высокого уровня. На этом уровне нет ни функций, ни вызовов, ни указателей, -- это всё частности реализации не только языков, но и машин. На уровне ООП есть лишь объекты и сообщения.
Речь про конкретную цитату. Вот про эту:
Причём вообще SQL или иной язык?
Можете пойти. Или вам нужно разрешение?
Можно. Программная инженерия (Software Engineering).
Считается, но они больше заточены на науку.
В паспорте какой страны? Если человек живёт в Израиле, его имя на иврите писать?
Ну что за чушь! Посылка сообщений и вызов методов – принципиально разные вещи!
Сообщение – это объект, состоящий из текстовой строки (имени сообщения) и возможного списка аргументов.
Метод – это объект, реализующий некоторую функциональность, проще говоря функция, привязанная к объекту.
Посылка сообщения – это способ коммуникации объектов. Объект, получивший сообщение, сам решает, как ему поступить с ним. Он может (1) ничего не ответить, (2) вызвать метод, соответствующий имени сообщения, (3) выбросить исключение или (4) переслать сообщение иному объекту.
Вызов метода – это вызов некоторой функции, привязанной к объекту, и передача ей возможных аргументов, вот и всё. Так что вызов метода – это лишь один из многих возможных способов реакции объекта на полученное сообщение.
Механизм сообщений является неотъемлемой частью ООП, но используется и вне его. Например, все распределённые системы параллельных вычислений (MPI) используют посылку сообщений. Поскольку сообщение – это текстовая строка и список аргументов, его можно послать по сети. Вызвать функцию или метод по сети нельзя (если вы не знали). Межпроцессные коммуникации (IPC) также используют механизм сообщений. Ибо вызвать функцию или метод из иного процесса тоже нельзя.
Так что в жизни вы постоянно используете сообщения, просто не знаете это, как и многие иные вещи.
Вы так пишите, словно Smalltalk исчез. Он живёт и используется в промышленном программировании. Не в РФ, конечно. Из более новых языков сообщения используются в Ruby.
Щито? Это математика, в ней теорема или верна, или не верна. Она не может быть верна наполовину. Язык или тьюринг-полный, или не трьюринг-полный. Если его семантика эквивалентна машине Тьюрига, он тьюринг-полный.
Ну это же синтаксический сахар. Они реализованы поверх прототипов.
Почему не упомянуты прототипные языки Self и JavaScript, в которых нет классов? И вообще, классы не являются непременным атрибутом ООП.
І тут у мене підгоріло!
Более чем правомерное. Именно Алан Кэй впервые сформулировал концепцию современного ООП и употребил это выражение.
Вот это вообще хтоническая чушь! Вы учили программирование на говнокурсах? То ООП, которое вы знаете -- это не ООП, а абстрактные типы данных. Многие их путают -- и это неправильно. ООП -- это объекты и обмен сообщениями.
Впервые же объектные принципы (объекты, классы, наследование и иные вещи) были реализованы в 1961 - 1967 в языке Simula. Это самая ранняя реализация некоторых концепций ООП.
Страуструп не изобрел ООП, он взял его из Simula. И ООП в C++ является набором костылей, прикрученных поверх C, и нужных, чтобы улучшить скорость выполнения. Нормальная реализация ООП поверх C есть в Objective-C.
Но вернёмся к истинному ООП. Гений Алан Кэй, посмотрев на Simula, понял, что можно сделать ещё лучше. И в 1967 впервые сформулировал концепцию современного ООП и, что принципиально, употребил это выражение в разговоре. Так что именно он является отцом современного ООП.
Первый язык, реализующий современное ООП вышел в 1972, и это был Smalltalk. Он вполне жив и применяется в промышленном программировании.
Имею некоторое мнение. Курсы, которые учат с нуля -- не нужны. Программирование -- это сложная инженерия, и ей нельзя научиться на курсах. Ну то есть нельзя быть барменом, и внезапно через несколько месяцев стать инженером.
Чтобы стать хорошим программистом нужно иметь бакалавриат по математике или информатике и магистратуру по инженерии. Поэтому курсы нужны иные -- по конкретным технологиям, чтобы инженеры, выпускники вузов, имеющие теоретические знания, изучили конкретные технологии, применяемые в промышленном программировании.
Программист -- это инженер, пилот -- это пользователь. После курсов нельзя стать инженером, нужно естественнонаучное или инженерное образование, а не курсы в несколько месяцев.
Ну, вообще ничего такого. Если учёный не живёт в РФ и не работает в РФ, то он уже и не российский. Было бы весьма странно отказывать учёному лишь по цвету его паспорта. Этим грешат лишь несколько истеричных европейских стран. Причём именно тех, через которые российские чиновники ввозят и вывозят санкционные товары.
Как сказал умный человек: "Санкции нам только на пользу. Но раз они не работают, то и пользы нет."
Вот человек, казалось бы, умными вещами занимается, а такую чушь пишет.
Нет, не все! Мы будем писать на том, что нам нравится. Python поощряет писать ужасные программы. Виной этому низкий порог. На C или C++ вы не напишете программу, если вы не знаете язык хорошо и не разбираетесь в программировании. Ибо она у вас просто не запустится. Чтобы писать программы на C / C++ вам нужно много знать.
К счастью, физики в основном всё ещё пишут на Fortran. Но многие биологи и и биоинформатики, увы, пишут на Python. Поэтому мы имеем кучи ужасно написанных бибилиотек, написанных учёными, не умеющими программировать, не понимающими ничего в программировании.
Oh, boy, here we go! Как вообще можно написать серьёзную программу типа научных программ, фото-, видео-, аудиоредакторов и компьютерных игр на JavaScript? Ещё есть и системное программирование! Похоже, что он считает, что разработка ПО ограничивается вебом и ботами.