Комментарии 380
Вам не лень было создавать для этой мысли отдельную запись?
Нет.
А вам не лень было писать для этой мысли отдельный коммент?
А вам не лень было писать для этой мысли отдельный коммент?
Какой пост, такой и комментарий. Все вроде как справедливо
1. Я могу заменить любую вашу сущность файлом с набором функций и переменных.
2. Я могу использовать MVC без единого класса, лишь набором функций.
3. Я могу сделать все что вы делаете с помощю ООП без оного, и вы так же прекрасно будете понимать в чем суть.
По серьезней аргументы не могли придумать? Да, ООП не отстой, но не по этим заметкам.
Если бы вы «не ограничивли себя каким-то одним подходом и выбирли в каждый конкретный момент тот из них», то не писали бы этой заметки. Я на 90% уверен что вы, в 99% случаев используете именно ООП, потому как «оно есть».
2. Я могу использовать MVC без единого класса, лишь набором функций.
3. Я могу сделать все что вы делаете с помощю ООП без оного, и вы так же прекрасно будете понимать в чем суть.
По серьезней аргументы не могли придумать? Да, ООП не отстой, но не по этим заметкам.
Если бы вы «не ограничивли себя каким-то одним подходом и выбирли в каждый конкретный момент тот из них», то не писали бы этой заметки. Я на 90% уверен что вы, в 99% случаев используете именно ООП, потому как «оно есть».
user = User.where(:name => «taliban»)
user.destroy
user.followers.remove
user.comments.last.destroy
Пожалуйста, опишите это без ооп, и чтобы всем было понятно
user.destroy
user.followers.remove
user.comments.last.destroy
Пожалуйста, опишите это без ооп, и чтобы всем было понятно
Есть хоть один непонятный момент?
$user = getUser(array('name'=>'taliban'));
removeUser($user);
removeUserFollowers($user);
removeUserComments($user, array('position'=>'last'))
$user = getUser(array('name'=>'taliban'));
removeUser($user);
removeUserFollowers($user);
removeUserComments($user, array('position'=>'last'))
Скажите пожалуйста, а $user — это не объект? Вы не находите, что запись removeUser($user) не настолько лаконична, как $user->remove?
Нет, $user не обьект, это структура (массив если так хотите) и я нахожу эти обе записи одинаково лаконичными.
Плюс ко всему я нахожу такую запись бессмысленной:
user.destroy
user.followers.remove // user удален, как я могу им пользоваться?
В моем же случае я просто управляю (грубо говоря) айдишником пользователя а не сущностью и порядок не играет роли.
Оба подхода вполне равнозначны, и я не говорил что-то против ооп, я лишь сказал что в статье аргументы приведены плохие в защиту ооп, не в этом соль ооп. Да и 90% людей которые кричат что ооп — не отстой, пользуются им потому что это «круто», а не потому что он подходит для данных нужд, хотя с гордостью заявляют что нужно выбирать инструменты под нужды.
Зы: да, и я использую ооп повсеместно, но я никогда не скажу плохого слова в сторону процедур, потому как иногда они лучше, и в некоторых случаях могут полностью заменить ооп без потери понятности кода.
Плюс ко всему я нахожу такую запись бессмысленной:
user.destroy
user.followers.remove // user удален, как я могу им пользоваться?
В моем же случае я просто управляю (грубо говоря) айдишником пользователя а не сущностью и порядок не играет роли.
Оба подхода вполне равнозначны, и я не говорил что-то против ооп, я лишь сказал что в статье аргументы приведены плохие в защиту ооп, не в этом соль ооп. Да и 90% людей которые кричат что ооп — не отстой, пользуются им потому что это «круто», а не потому что он подходит для данных нужд, хотя с гордостью заявляют что нужно выбирать инструменты под нужды.
Зы: да, и я использую ооп повсеместно, но я никогда не скажу плохого слова в сторону процедур, потому как иногда они лучше, и в некоторых случаях могут полностью заменить ооп без потери понятности кода.
>Нет, $user не обьект, это структура (массив если так хотите)
По-моему вопрос был о том, является ли $uesr объектом в семантическом смысле, а не с точки зрения его воплощения в сущностях конкретного языка. Так что правильный ответ — «да, семантически это объект».
Кстати, это точно не массив, т.к. массив — это индексированный набор однотипных данных, что в общем случае неверно для структур.
По-моему вопрос был о том, является ли $uesr объектом в семантическом смысле, а не с точки зрения его воплощения в сущностях конкретного языка. Так что правильный ответ — «да, семантически это объект».
Кстати, это точно не массив, т.к. массив — это индексированный набор однотипных данных, что в общем случае неверно для структур.
По вашему массив = обьект? Мне кажется вам стоит пересмотреть ваши взгляды на обьекты, а особенно понять разницу между структурой и обьектом. Это отнюдь не одно и то же.
Мне кажется, вам стоит пересмотреть свои взгляды на объекты, выйдя за [довольно узкие] рамки С++.
Да, массив (как сущность, а не как синтаксическая конструкция того или иного языка) — это объект. У него есть все признаки объекта: данные, состояние и методы оперирования данными/изменения состояния. Опровергайте :)
Да, массив (как сущность, а не как синтаксическая конструкция того или иного языка) — это объект. У него есть все признаки объекта: данные, состояние и методы оперирования данными/изменения состояния. Опровергайте :)
состояние и методы? у массива? мы точно об одном и том же говорим? массив — набор данных, в отличии от обьекта, в котором еще и дейсвия находятся, причем не просто действия, а еще и:
1. инкапсуляция
2. наследование
3. полиморфизм
и это лишь азы ооп, в отличии от массивов и процедур.
1. инкапсуляция
2. наследование
3. полиморфизм
и это лишь азы ооп, в отличии от массивов и процедур.
>мы точно об одном и том же говорим?
Почти наверняка не об одном и том же. Я — об абстрактной сущности «массив», который есть «индексированный набор однотипных данных», без привязки к реализации. Вы же, подозреваю, о конкретной реализации вроде «int array[10]». Что является лишь одной из возможных реализаций, но далеко не единственно возможной.
Под определение, данное выше, подходит и std::vector, и QVector, и хренова туча других реализаций, у которых (сюрприз!) есть и методы, и инкапсуляция, и прочие 33 удовольствия.
Ещё раз вам говорю: перестаньте мыслить в рамках конкретной реализации.
Почти наверняка не об одном и том же. Я — об абстрактной сущности «массив», который есть «индексированный набор однотипных данных», без привязки к реализации. Вы же, подозреваю, о конкретной реализации вроде «int array[10]». Что является лишь одной из возможных реализаций, но далеко не единственно возможной.
Под определение, данное выше, подходит и std::vector, и QVector, и хренова туча других реализаций, у которых (сюрприз!) есть и методы, и инкапсуляция, и прочие 33 удовольствия.
Ещё раз вам говорю: перестаньте мыслить в рамках конкретной реализации.
> user.destroy
> user.followers.remove // user удален, как я могу им пользоваться?
removeUser($user);
removeUserFollowers($user); // user удален, как я могу им пользоваться? ;)
Не придираясь к терминологии, в чем в данной ситуации вы видите разницу между структурой и прилагающимся к ней и только к ней функционалом для работы (removeUser, removeUserFollowers и т.д.) и объектом и его методами? Если честно, я разницы тут не вижу. Разве что запись длиннее.
> user.followers.remove // user удален, как я могу им пользоваться?
removeUser($user);
removeUserFollowers($user); // user удален, как я могу им пользоваться? ;)
Не придираясь к терминологии, в чем в данной ситуации вы видите разницу между структурой и прилагающимся к ней и только к ней функционалом для работы (removeUser, removeUserFollowers и т.д.) и объектом и его методами? Если честно, я разницы тут не вижу. Разве что запись длиннее.
Да эта ваша скучная мысль уже жевана-пережевана в тысячу раз, каждый уже по своему уровню ответ заготовил. Можно только одну цитату?
«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
(с) Александр Степанов, со-автор C++, автор STL
Ах да, взято отсюда: Почему объектно-ориентированное программирование провалилось?
«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
(с) Александр Степанов, со-автор C++, автор STL
Ах да, взято отсюда: Почему объектно-ориентированное программирование провалилось?
О кстати вспоминал чья это цитата :)
С Александром я полностью согласен — совершенно неудобно разрабатывать сначала каркас, а после думать как по нему лазать. Но с другой стороны — это ли не повод чтобы сначала спокойно спроектировать приложение, а уж после приступить к его реализации? Минус для кодера — плюс для инженера?
С Александром я полностью согласен — совершенно неудобно разрабатывать сначала каркас, а после думать как по нему лазать. Но с другой стороны — это ли не повод чтобы сначала спокойно спроектировать приложение, а уж после приступить к его реализации? Минус для кодера — плюс для инженера?
Оба правы.
Математики начинают с доказательств — допустим. Потом выделяют подходящий набор аксиом. Но потом им потребуется рефакторинг доказательств уже исходя из этого набора — чтобы было проще, логичнее, красивее; часто потребуется развернуть доказательство в обратную сторону (доказать то, что раньше казалось более первичным)…
Вы обречены на переписывание программы. Точка.
Математики начинают с доказательств — допустим. Потом выделяют подходящий набор аксиом. Но потом им потребуется рефакторинг доказательств уже исходя из этого набора — чтобы было проще, логичнее, красивее; часто потребуется развернуть доказательство в обратную сторону (доказать то, что раньше казалось более первичным)…
Вы обречены на переписывание программы. Точка.
Хорошо хоть строители так не считают и начинают дом с фундамента )
Лучше бы они начинали с чертежей. И с модели.
дом в любом случае имеет план и чертеж, разрешения, расчеты. да и хозяин зачастую имеет видение, где будет диван, а где аквариум. но строят все-равно с фундамента, а остальное держат в уме и на бумаге.
Иначе будет как в анекдоте — «Молдаване строя дом сначала прибивают все имеющиеся доски, а потом отпиливают все лишнее»
Иначе будет как в анекдоте — «Молдаване строя дом сначала прибивают все имеющиеся доски, а потом отпиливают все лишнее»
Дураков не сеют, не пашут — сами рождаются.
>выводится аксиома
Ну как можно воспринимать на веру это откровенно ложное утверждение, пускай даже высказанное авторитетным человеком.
Аксиома на то и аксиома, что ее не выводят, а принимают как данное. В науке вообще, а не только в математике, начинают именно с аксиом. Попробуйте откуда-нибудь вывести «количество» или «точку». Или определите понятие «жизнь» в биологии. А ведь это то самое, что изучает эта наука. Абсолютно неопределимое аксиоматическое понятие.
Ну как можно воспринимать на веру это откровенно ложное утверждение, пускай даже высказанное авторитетным человеком.
Аксиома на то и аксиома, что ее не выводят, а принимают как данное. В науке вообще, а не только в математике, начинают именно с аксиом. Попробуйте откуда-нибудь вывести «количество» или «точку». Или определите понятие «жизнь» в биологии. А ведь это то самое, что изучает эта наука. Абсолютно неопределимое аксиоматическое понятие.
В целом Вы правы, но с точкой погорячились см. Определение точки (хотя это скорее оффтоп)
Это болтология, а не определение.
Почему же?
Потому что точка определяется через плотность, а плотность — через точку. Фраза «содержать в одной точке более одной точки» вообще шикарна. «Интересующий нас» — тоже замечательное выражение для определения:)
Ну и даже если на это забить, то точка получается вполне себе делимой.
«расстояние — количество точек между двумя нас интересующими, включая их» [жирный шрифт мой — mihaild]
facepalm
«Окрестностью точки назовем совокупность точек, которые окружают интересующую нас точку;»
double facepalm
«Предельной точкой объекта назовем точку, которая хотя бы в одной точке не имеет окрестности;»
triple facepalm
<...>
ну, Вы поняли
Ну и даже если на это забить, то точка получается вполне себе делимой.
«расстояние — количество точек между двумя нас интересующими, включая их» [жирный шрифт мой — mihaild]
facepalm
«Окрестностью точки назовем совокупность точек, которые окружают интересующую нас точку;»
double facepalm
«Предельной точкой объекта назовем точку, которая хотя бы в одной точке не имеет окрестности;»
triple facepalm
<...>
ну, Вы поняли
Я понял, что вы ничего не поняли. Вам кажется, что нельзя определить понятия одно через другое замкнутое в круг? Так это и есть ошибка формальной логики.
Вас смущает фраза «Интересующий нас» — а вас не смущает «допустимая погрешность в эксперименте»? Нет? Двойные стандарты.
Вырывать из контекста тоже вас не красит.
> Плотностью назовем свойство материи содержать в одной точке более одной точки, т.е. их объемы пересекаются;
и что тут проблемного? объемы интересующих нас областей не могут пересекаться.
Ну, и так далее… не место для полноценного объяснения, того что вы не понимаете или не хотите понять.
Вас смущает фраза «Интересующий нас» — а вас не смущает «допустимая погрешность в эксперименте»? Нет? Двойные стандарты.
Вырывать из контекста тоже вас не красит.
> Плотностью назовем свойство материи содержать в одной точке более одной точки, т.е. их объемы пересекаются;
и что тут проблемного? объемы интересующих нас областей не могут пересекаться.
Ну, и так далее… не место для полноценного объяснения, того что вы не понимаете или не хотите понять.
Вообще, такие текстовы определения — это артефакт естественного языка. В случае формальной логики есть сигнатура (набор значков), и множество аксиом, в некотором смысле объясняющих, что эти значки обозначают.
Нет, не смущает. Потому что «допустимая погрешность» легко формализуется (более того, в серьезной физике всегда говорят о доверительном интервале, который является совершенно точным понятием).
Что именно я вырвал из контекста?
Нет, не смущает. Потому что «допустимая погрешность» легко формализуется (более того, в серьезной физике всегда говорят о доверительном интервале, который является совершенно точным понятием).
Что именно я вырвал из контекста?
«Интересующий нас» — легко формализуется «доверительным интервалом» :)
> Что именно я вырвал из контекста?
Да, все. Но я говорил о «содержать в одной точке более одной точки»
> Что именно я вырвал из контекста?
Да, все. Но я говорил о «содержать в одной точке более одной точки»
Правда? Ну формализуйте.
Там это сделано более чем.
> «допустимая погрешность» формализуется «доверительным интервалом»
вот опишите мне чем эта процедура отличается от того, что элементарно стоит за словами «выбрать интересующий нас объем»?
вот опишите мне чем эта процедура отличается от того, что элементарно стоит за словами «выбрать интересующий нас объем»?
Погрешность допустима, если она попадает в доверительный интервал с некоторым фиксированным уровнем доверия (конкретное его значение зависит от контекста, в научных работах его указывают явно).
Так, вот, дорогой мой, «интересующий нас» означает ровно тоже самое. В конкретной научной работе (по физике, скажем) надо указывать в зависимости от контекста, что мы выбрали за точку.
Если в математике говорят «пусть А — будет точкой», то в физике этого мало — нужно говорить пусть если считать планету Земля точкой А, а точкой Б — Луну, то можем… (это и есть точки «интересующей нас объем»)
Если в математике говорят «пусть А — будет точкой», то в физике этого мало — нужно говорить пусть если считать планету Земля точкой А, а точкой Б — Луну, то можем… (это и есть точки «интересующей нас объем»)
Т.е. Вы не претендуете на то, что Ваша «наука» имеет какое-то отношение к математике?
О чем Вы? Речь идет только об одном определении, данном более точно, тем ныне существующие.
Считаете ли Вы тот текст определением, пригодным для использования в математике?
Да, и не только. Это определение дает больше понимания того, что мы называем точкой как в математике, так и в других науках.
«Понимание» — это нечто странное и совершенно неформальное.
Работать с Вашими определениями, в отличии от нормальной теории меры, нельзя.
Как Вы объясните существование биекций, не сохраняющих меру?
Работать с Вашими определениями, в отличии от нормальной теории меры, нельзя.
Как Вы объясните существование биекций, не сохраняющих меру?
Дорогой мой, «понимание» — это та тема над которой я работаю :) и если обладая им мы считаем это нечто странным — это диагноз. На говорить, что мы просто не понимаем, что есть понимание. :)
Работать в каком смысле, что вы хотите сделать. Чтобы говорить, что с ним нельзя работать — нужно понимать как работать и для чего.
(Если вы математик — это вы должны мне объяснить «существование биекций, не сохраняющих меру» — а мне пожалуйста, на примерах из реального физического мира — иначе это не существование, а математическая фантазия. )
Работать в каком смысле, что вы хотите сделать. Чтобы говорить, что с ним нельзя работать — нужно понимать как работать и для чего.
(Если вы математик — это вы должны мне объяснить «существование биекций, не сохраняющих меру» — а мне пожалуйста, на примерах из реального физического мира — иначе это не существование, а математическая фантазия. )
Опечатка:
На говорить -> Надо говорить
На говорить -> Надо говорить
Я хочу получать теоремы в геометрии, теории меры, топологии и т.д. Ваши «определения» сделать этого не позволят.
Хорошо, вот классический пример. Два колеса разного размера насажены на одну ось, катятся каждое по своей колее. Они сделали полный оборот. Каждой точке большего колеса оказалась сопоставленной точка меньшего (например, точке X сопоставляем точку Y, такую, что X и Y оказываются внизу одновременно). Каждой точке большего колеса оказалась сопоставленной точка меньшего колесе. Значит, если мы понимаем длину как «сумму длин точек, состовляющих кривую», то окружности большего и меньшего колеса имеют одинаковую длину, что неверно.
Если работать с мерой строго, то парадокса не возникает: мера не есть «сумма длин точек».
Хорошо, вот классический пример. Два колеса разного размера насажены на одну ось, катятся каждое по своей колее. Они сделали полный оборот. Каждой точке большего колеса оказалась сопоставленной точка меньшего (например, точке X сопоставляем точку Y, такую, что X и Y оказываются внизу одновременно). Каждой точке большего колеса оказалась сопоставленной точка меньшего колесе. Значит, если мы понимаем длину как «сумму длин точек, состовляющих кривую», то окружности большего и меньшего колеса имеют одинаковую длину, что неверно.
Если работать с мерой строго, то парадокса не возникает: мера не есть «сумма длин точек».
Не ясно причем тут мое определение, но ладно.
Вы создали свой парадокс сами, когда сопоставили точки разных колес. И проблема не в определении.
Вы создали свой парадокс сами, когда сопоставили точки разных колес. И проблема не в определении.
А в чем же, если не в определении? У Вас длина кривой — это сумма длин точек. Значит, если у нас есть биекция f между точками, то длины равны:
длина(меньшее колесо) = \sum_{x \in меньшее колесо} длина(x) = \sum_{x \in меньшее колесо} длина(f(x)) = \sum_{y \in большее колесо} длина(y) = длина(большее колесо).
длина(меньшее колесо) = \sum_{x \in меньшее колесо} длина(x) = \sum_{x \in меньшее колесо} длина(f(x)) = \sum_{y \in большее колесо} длина(y) = длина(большее колесо).
У меня нет длины кривой — у меня есть только расстояние.
И тем более у меня нет определения биекции. Поэтому Вы нашли проблему не у меня, а выдумали её у себя.
И тем более у меня нет определения биекции. Поэтому Вы нашли проблему не у меня, а выдумали её у себя.
Вы не можете сделать биекцию для разных колес. Отсюда у вас и вывод не правильный.
еще раз, с большого колеса на меньшие вы можете сделать только сюръекцию
Как не могу? А что приведено выше, если не биекция?)
Там ничего не приведено, там болтовня что давайте мол это сделаем…
Зададим отображение из одного колеса на другое: точке X одного колеса сопоставим точку Y другого колеса, такую, что X и Y оказываются внизу одновременно.
Если это не биекция, то прошу указать точку на одном колесе, которой соответствует не ровно одна точка на другом.
Если это не биекция, то прошу указать точку на одном колесе, которой соответствует не ровно одна точка на другом.
У вас на одном колесе только 10 точек, на другом только 5 точек, т.к. оно меньшего объема. Задать такое отображение как вы пишите вы не можете.
Т.е. в некоторые моменты у меньшего колеса не будет нижней точки?)
Самая нижняя будет всегда. Иногда их будет даже две.
Т.е. в некоторые моменты у меньшего колеса будет одна и тоже точка, в то время как у большего сменятся несколько.
Такие хорошие длинные точки у Вас получаются.
Можно ли разрезать точку на две?
И мне пришел в голову еще один хороший пример, более сложный с точки зрения математики, но, быть может, более понятный интуитивно, когда объединение континуального числа множеств нулевой меры дает ненулевую.
У Вас есть честная монетка (вероятность орла — 1/2, решки — 1/2). Будем ее бросать и при выпадении орла писать 0, при выпадении решки — 1. Какова вероятность того, что мы никогда не напишем ни одной единицы (будем всегда писать только нули)?
Можно ли разрезать точку на две?
И мне пришел в голову еще один хороший пример, более сложный с точки зрения математики, но, быть может, более понятный интуитивно, когда объединение континуального числа множеств нулевой меры дает ненулевую.
У Вас есть честная монетка (вероятность орла — 1/2, решки — 1/2). Будем ее бросать и при выпадении орла писать 0, при выпадении решки — 1. Какова вероятность того, что мы никогда не напишем ни одной единицы (будем всегда писать только нули)?
Можно и нужно использовать одинаковый масштаб точек, и все тогда будет логичным.
Вероятность — 0. Но что это доказывает?
Вероятность — 0. Но что это доказывает?
Ну вот, теперь какой-то «масштаб» появился. Кстати, как в Вашей мегатеории с длинными точками объясняется существование несоизмеримых отрезков?)
Отлично, вероятность — ноль. А теперь давайте зафиксируем какую-нибудь другую бесконечную последовательность нулей и единиц (например, двоичная запись числа пи, или еще что угодно). Какова вероятность того, что мы получим в точности эту последовательность?
Отлично, вероятность — ноль. А теперь давайте зафиксируем какую-нибудь другую бесконечную последовательность нулей и единиц (например, двоичная запись числа пи, или еще что угодно). Какова вероятность того, что мы получим в точности эту последовательность?
Да, ничего нового не появилось, масштаб — это синоним того что было «интересующий нас объем материи единичной плотности».
Ну, что еще за несоизмеримые отрезки. Дорогой, я совершенно не математик — и не стремлюсь им быть. Я просто замечаю ряд нелепец о которых и говорю, как их исправить.
> Какова вероятность того, что мы получим в точности эту последовательность?
Явно отличимая от нуля. И зависит от того закона получения первичной последовательности.
Ну, что еще за несоизмеримые отрезки. Дорогой, я совершенно не математик — и не стремлюсь им быть. Я просто замечаю ряд нелепец о которых и говорю, как их исправить.
> Какова вероятность того, что мы получим в точности эту последовательность?
Явно отличимая от нуля. И зависит от того закона получения первичной последовательности.
Ну да, ничего нового — как была болтология, так и осталась.
То, что Вам что-то непонятно не означает, что это нелепость. Попробуйте почитать нормальные книжки по математике (более новые, чем труды Декарта), если останутся вопросы — обращайтесь. А пытаться придумать что-то своё, не разобравшись в имеющемся — довольно странный подход.
Я выписываю из головы последовательность из N нулей и единиц и потом N раз бросаю монетку. Какова вероятность того, что результаты бросков будут соответствовать этой последовательности?
PS. Не надо фамильярности.
То, что Вам что-то непонятно не означает, что это нелепость. Попробуйте почитать нормальные книжки по математике (более новые, чем труды Декарта), если останутся вопросы — обращайтесь. А пытаться придумать что-то своё, не разобравшись в имеющемся — довольно странный подход.
Я выписываю из головы последовательность из N нулей и единиц и потом N раз бросаю монетку. Какова вероятность того, что результаты бросков будут соответствовать этой последовательности?
PS. Не надо фамильярности.
Странный подход — это начинать с нелепых аксиом. А потом подогнать их под опыт. Не нужно думать, что оппоненту чего-то не понятно, если он не ХОЧЕТ разбираться в запутанной и не логичной «вашей» терминологии. Чтобы мне разбираться в этом мире мне достаточно думать своей головой.
P.S. Фамильярности будут, тогда когда вы будите говорить ad hominem
P.S. Фамильярности будут, тогда когда вы будите говорить ad hominem
Противоречие обыденной интуиции — не признак нелепости.
А вот невозможность формальной работы с формулировками как раз таки признак их неправильности.
Вы не хотите разбираться в математике, но тем не менее объявляете её нелепой?
Фамильярности уже есть. Я Вам не «дорогой».
А то, что я называю Вашу «теорию» болтологией — я бы ее так назвал независимо от авторства.
А вот невозможность формальной работы с формулировками как раз таки признак их неправильности.
Вы не хотите разбираться в математике, но тем не менее объявляете её нелепой?
Фамильярности уже есть. Я Вам не «дорогой».
А то, что я называю Вашу «теорию» болтологией — я бы ее так назвал независимо от авторства.
Так, вот. Если математики в своих аксиомах заложили противоречия обыденной интуиции — значит — ОНИ ГЛУБОКО ОШИБАЮТСЯ. И это не аксиомы — а бред. Противоречить обыденной интуиции — может только эмпирический опыт, а строить теории противоретящие здравому рассудку — это нечто. Не удивительно как много смешных вещей я тогда читаю. Никто мне еще не объяснил, не смог — необходимость бреда в начала точных наук. Это просто заметание под ковер, о чем не очень логично получается судить.
Проблема в том, что «здравому смыслу» могут противоречить уже самые простые вещи.
Более того, здравый смысл субъективен. Мне кажется вполне нормальным, что ненулевая длина получается объединением точек нулевой длины, Вам — не кажется. Формализм нужен как раз для того, чтобы разные люди могли получать одни и те же выводы.
Более того, здравый смысл субъективен. Мне кажется вполне нормальным, что ненулевая длина получается объединением точек нулевой длины, Вам — не кажется. Формализм нужен как раз для того, чтобы разные люди могли получать одни и те же выводы.
Да, с формализмом или без — «Мне кажется вполне нормальным, что ненулевая длина получается объединением точек нулевой длины» — это классическое противоречие. Брать за основу противоречие и строить на этом теорию? Ну, и что получится… — нелепая теория. Это даже не теория — это традиция, глубоко уходящая в теорию о Боге.
Вы не видите противоречия? Нет. Вы видите. Вы просто не хотите признать это, потому что это противоречит определенного рода традиции в определенных кругах.
Но ничего не изменяется во всей математике если принят эту аксиому так как предложенный мной. просто изменяется и появляется естественный смысл описываемого.
Вы не видите противоречия? Нет. Вы видите. Вы просто не хотите признать это, потому что это противоречит определенного рода традиции в определенных кругах.
Но ничего не изменяется во всей математике если принят эту аксиому так как предложенный мной. просто изменяется и появляется естественный смысл описываемого.
«классическое противоречие» чему? Вашему «здравому смыслу»?
Моему «здравому смыслу» это не противоречит.
Пока что аксиомы я не вижу. Выше я указал, как через значки принадлежности, равенства и скобки построить теорию вещественных чисел. Запишите Вашу «теорию» хоть в какой-нибудь сигнатуре формулами — тогда можно будет рассуждать о ее преимуществах. Я пока что не вижу способа это сделать.
Моему «здравому смыслу» это не противоречит.
Пока что аксиомы я не вижу. Выше я указал, как через значки принадлежности, равенства и скобки построить теорию вещественных чисел. Запишите Вашу «теорию» хоть в какой-нибудь сигнатуре формулами — тогда можно будет рассуждать о ее преимуществах. Я пока что не вижу способа это сделать.
Да, не буду я записывать значками то что не должно быть записано значками. Значки ничего не дают. Ну можете каждое мое слово обозначить любым вам интересным значком и переписать. Что? Получили качественно что-то новое? Нет. Так и в математике это не дает ничего качественно нового — это лишь сокращение записи.
> Моему «здравому смыслу» это не противоречит.
Бред мы обсуждать не будем. И так уже зафлудили. Если не видите элементарного противоречия — ничем вам помочь не могу.
Бред мы обсуждать не будем. И так уже зафлудили. Если не видите элементарного противоречия — ничем вам помочь не могу.
Если вместо того чтобы попытаться что-то понять, Вы объявляете это противоречием — ничем помочь не могу.
Вы не на раз не показали отсутствия противоречия, а все только вокруг да около…
А отсутствие противоречия, согласно второй теореме Геделя, показать не получится (если только его на самом деле нет). Вы утверждаете противоречивость — пожалуйста, выведите противоречие.
Да, чего его выводить — ниже мы уже договорились, что ваша аксиома несовместима с реальным миром, и для него не нужна, пока вы не проведете квантование. Ну, нравится вам измышлять о божественном — прошу… но зачем потом выдавать это за нужное для науки?
0 * N !== 0 для N > 0, если вы всё ещё об определении длины отрезка через безразмерную точку.
Увы, так устроен мой мозг — и может быть это и моя проблема или преимущество, что нормальных книжек по математике я не встречал ВООБЩЕ. Там или одни закорючки, или с первых страниц смешные вещи. И только не нужно считать кого-то глупее, если у вас не возникают элементарных вопросов. Попробуйте адресно посоветовать, что читать — тогда уж.
Я чуть выше уже писал: Рудин, «Основы математического анализа». Могу скинуть электронную версию.
Вообще я встречал не так много совсем уж бредовых книжек по математике, так что, видимо, это Вам не везло (или мне не везло).
Ну да, в математике часто пишут формулы — это лаконичнее и удобнее, чем слова, и четче чем картинки.
Я не делаю никаких выводов о Вашем интеллекте. Я всего лишь указываю на то, что некоторые из возникающих у Вас вопросов есть лишь следствие пробелов в Ваших знаниях в том смысле, что эти вопросы уже решены.
Вообще я встречал не так много совсем уж бредовых книжек по математике, так что, видимо, это Вам не везло (или мне не везло).
Ну да, в математике часто пишут формулы — это лаконичнее и удобнее, чем слова, и четче чем картинки.
Я не делаю никаких выводов о Вашем интеллекте. Я всего лишь указываю на то, что некоторые из возникающих у Вас вопросов есть лишь следствие пробелов в Ваших знаниях в том смысле, что эти вопросы уже решены.
Таких «математических анализов» на полке у меня полно, они не дают мне ничего нового. И пока я как-то не увидел из нашей дискуссии как решена проблема «определения точки». Кроме как отстранения от явной проблемы, за наукообразными словами.
Я тут где-то уже писал, как определить вещественные числа, начав с понятия множества.
Точка на прямой — это вещественное число, точка на плоскости — это пара вещественных чисел. И т.д.
Точка на прямой — это вещественное число, точка на плоскости — это пара вещественных чисел. И т.д.
Вам не кажется, что выводить понятия надо из уже определенных понятий. И чем меньше будет аксиом тем больше теория будет соответствовать Оккаму? Нет?
Так вначале определите число — какое отношение имеет число к точке?
У вас получается что точку нельзя определить без понятия числа, а число без понятия множества… Ну, тогда хотя бы начните с определения множества, без применения терминов число или точка. Не можете? У вас получается ровно такой же круг в определениях, как и у меня. Это естественно. Но Вы начинаете просто с другой стороны…
Так вначале определите число — какое отношение имеет число к точке?
У вас получается что точку нельзя определить без понятия числа, а число без понятия множества… Ну, тогда хотя бы начните с определения множества, без применения терминов число или точка. Не можете? У вас получается ровно такой же круг в определениях, как и у меня. Это естественно. Но Вы начинаете просто с другой стороны…
Ну, и послушайте — вы же потом вводите понятие умножения, так какого… вы применяя это же умножение получает Отрезок 10 см = 0*10 точек — и потом говорите что это нормально… Вы ДОРОГИЕ, математики запутались в самых своих началах.
Или как там у вас софистика работает — отрезок 10 см состоит из точек или нет?
А кто Вам сказал, что на отрезке 10 точек?) На отрезке континуум точек.
Мы не дорогие. Например, мое время стоит довольно дешево. Я даже готов его тратить на незнакомого человека, который, возможно, хочет разобраться в том, чего он не понимает.
Мы не дорогие. Например, мое время стоит довольно дешево. Я даже готов его тратить на незнакомого человека, который, возможно, хочет разобраться в том, чего он не понимает.
1. отрезок 10 см состоит из точек или нет?
2. Сколько точек на этом отрезке?
3. Да сколько бы их не было умножайте на ноль и получайте 10 см. вот уж логика так логика.
2. Сколько точек на этом отрезке?
3. Да сколько бы их не было умножайте на ноль и получайте 10 см. вот уж логика так логика.
1. Состоит.
2. Континуум.
3. Умножение определено для вещественных чисел (ну и для комплексных, кватернионов… не суть). Операция умножения на континуум не определена.
2. Континуум.
3. Умножение определено для вещественных чисел (ну и для комплексных, кватернионов… не суть). Операция умножения на континуум не определена.
Ни фига се — т.е. зная, что отрезок состоит из точек вы в математике не можете посчитать его длину… замечательно. ч.т.д. — пользы ноль.
Если единственное, что я знаю об отрезке — это то, что он состоит из точек — то да, я не могу посчитать его длину. Потому что и отрезок [0;1], и отрезок [0;2] состоят из точек. Более того, из «одинакового числа» точек (между ними есть биекция).
> отрезок [0;1], и отрезок [0;2] состоят из точек. Более того, из одинакового числа» точек
Зашибись откровения пошли. Ну теперь мне ясна логика вашей мысли. Только смысла в таким математических определениях нет ни каких!
Зашибись откровения пошли. Ну теперь мне ясна логика вашей мысли. Только смысла в таким математических определениях нет ни каких!
Хорошо. Вот я нарисовал на лежащей рядом со мной бумажке отрезок. Он состоит из точек. Определите с помощью своей мегатеории его длину.
Вы что то путаете. Это не теория, а определение точки было. Забыли?
Нарисовав отрезок — вы его должны определить. И согласно моему определению, для этого вы должны выбрать
1. «минимально интересующий нас объем» — объем точки
2. и для объекта отрезок дать расстояние как «величину, которая равна количеству точек между двумя нас интересующими, включая их»
И только тогда это быдет означать, что вы строго определили то, что вы совершили акт «рисования отрезка».
Ну, уже разжевал как мог, теперь понятно?
Нарисовав отрезок — вы его должны определить. И согласно моему определению, для этого вы должны выбрать
1. «минимально интересующий нас объем» — объем точки
2. и для объекта отрезок дать расстояние как «величину, которая равна количеству точек между двумя нас интересующими, включая их»
И только тогда это быдет означать, что вы строго определили то, что вы совершили акт «рисования отрезка».
Ну, уже разжевал как мог, теперь понятно?
Длина отрезка — это его объем деленный на площадь его сечения. Есть и такой подход. А сохраняется ли объем или масса при биекции, зависит от множества допустимых преобразований.
Если мы растянем резиновый отрезок, его длина изменится. А изменится ли количество точек?
Если мы растянем резиновый отрезок, его длина изменится. А изменится ли количество точек?
Вот, уже намечается что-то нормальное. Хотите строить свою теорию, в которой не будет выполнена аксиома бесконечной делимости — стройте. Никаких априорных соображений, что это сделать не получится, я не вижу. Может быть, будет что-то аналогичное нестандартному анализу (в котором есть бесконечно малые числа), с помощью которого некоторые классические результаты доказываются куда проще.
Правда, нестандартный анализ всё же использует классические вещественные числа. В Вашей теории они тоже понадобятся, чтобы задать величину «минимального объема».
Вообще, скорее всего, кто-то уже пробовал такую теорию построить. Хотите — поищите, если найдете — напишите, буду благодарен.
Правда, нестандартный анализ всё же использует классические вещественные числа. В Вашей теории они тоже понадобятся, чтобы задать величину «минимального объема».
Вообще, скорее всего, кто-то уже пробовал такую теорию построить. Хотите — поищите, если найдете — напишите, буду благодарен.
Это у вас получается как у древних философов (в принципе от них вы и позаимствовали, но не на раз не разобрались) — отрезок состоит из континуума точек (читай Вселенная бесконечна и Бог всюду) — ну и зачем мне такие метафизические определения, не соответствующие эмпирическому опыту — мы наукой занимаемся или выводим сферически-религиозного коня?
А, то есть Вы предлагаете заняться квантованием пространства? В этой области, конечно, были какие-то попытки, но вроде бы особым успехом они не увенчались.
Древние философы как раз не умели аккуратно работать с бесконечностью.
А «эмпирическому опыту» как раз прекрасно соответствует принцип бесконечной делимости.
Причем тут религия, я совсем не понимаю.
Древние философы как раз не умели аккуратно работать с бесконечностью.
А «эмпирическому опыту» как раз прекрасно соответствует принцип бесконечной делимости.
Причем тут религия, я совсем не понимаю.
Да, при том, тут религия, что там появилось понятие о бесконечном — и только там не нужно заниматься квантованием. Все же смертные на конечных пространствах им занимаются. И как вы сами выше написали — если не заняться квантованием в каждом конкретном случае в зависимости от задачи (вспоминаем мои слова «минимально интересующий нас объем») — то смысла во всех этих определения не будет ни какого — рассчетов сделать нельзя. А то над чем нельзя сделать расчетов — не существует, значит есть измышление о Боге (в смысле философии). Т.е. понимание точки в математике — есть религиозное представление о мире, а данное мной определение — в котором уже встроено квантование на уровне замкнутого определения — есть предмет науки. Вот так вот :)
Декартово произведение определено. Если мы одноэлементное множество умножим на континуум, то континуум и получим. Целых 10 см (и при этом 0 см^2).
Кстати, с точками нас обманули. С самого начала дискуссии никто не вспомнил, что точка и фигура, состоящая из одной точки — это разные объекты. Отрезок и колесо являются множеством точек. Их можно было бы рассмотреть, как континуальные объединения одноточечных множеств. Но можно пойти по другому пути — взять алгебру, в которой есть только измеримые множества, сказать, что множества определяются с точностью до «множества меры ноль» и запретить более чем счетные объединения/пересечения. Тогда отрезок уже не будет объединением «точек», да и сама «точка» окажется неотличимой от пустого множества. Теория станет чуть сложнее, но более соответствующей здравому смыслу и материальному миру (наивному представлению о нем).
А математика вообще (в ее современном виде) с одной стороны является результатом борьбы с парадоксами естественного языка (лжеца и цирюльника), а с другой — описание реального мира это всего лишь одно из ее возможных приложений. Сама математика пригодна для работы с гораздо более разнообразными мирами.
Кстати, с точками нас обманули. С самого начала дискуссии никто не вспомнил, что точка и фигура, состоящая из одной точки — это разные объекты. Отрезок и колесо являются множеством точек. Их можно было бы рассмотреть, как континуальные объединения одноточечных множеств. Но можно пойти по другому пути — взять алгебру, в которой есть только измеримые множества, сказать, что множества определяются с точностью до «множества меры ноль» и запретить более чем счетные объединения/пересечения. Тогда отрезок уже не будет объединением «точек», да и сама «точка» окажется неотличимой от пустого множества. Теория станет чуть сложнее, но более соответствующей здравому смыслу и материальному миру (наивному представлению о нем).
А математика вообще (в ее современном виде) с одной стороны является результатом борьбы с парадоксами естественного языка (лжеца и цирюльника), а с другой — описание реального мира это всего лишь одно из ее возможных приложений. Сама математика пригодна для работы с гораздо более разнообразными мирами.
Ну да, получится некая теория, похожая на интегральное исчисление Лебега (там в общем-то тоже никого не волнует поведение точки на множестве меры ноль). Насколько это соответствует «реальному миру» — сказать сложно. Физикам же зачем-то нужна, например, дельта-функция — которая представляет из себя нечто странное, если мы игнорируем отличие регулярных функций на множестве меры ноль.
Скорее, получится алгебра борелевских множеств (если я не перепутал). Про дельта-функцию физики знают, что она может входить только в свертку, и за ее пределами с ней надо обращаться осторожно (хотя взять производную — запросто). Например, считать ее значения в точках смысла нет вообще. Такой объект функционального пространства, который отображением из R в R не является. Но является производной одного из таких отображений.
> Сама математика пригодна для работы с гораздо более разнообразными мирами.
Самим не смешно? Нет у нас ничего кроме реального мира и божественного мира. Так каким миром занимается математика?
Самим не смешно? Нет у нас ничего кроме реального мира и божественного мира. Так каким миром занимается математика?
Или я понял — математика занимается мирами которых еще не определены :) Не смешно?
Мне не смешно. Я привык работать и с многомерными пространствами и с неевклидовыми. И то, что у них нет физического представления, меня не останавливает совсем. Математика миром не занимается. Ее используют те, кому нужно заниматься каким-нибудь миром, и адаптируют под известные им особенности этого мира.
Например, наш мир, описываемый волновой функцией, с точки зрения математики совсем не тот, который описывали Ньютон и Эйнштейн. Но математика с этим новым представлением справляется без особого напряжения.
Например, наш мир, описываемый волновой функцией, с точки зрения математики совсем не тот, который описывали Ньютон и Эйнштейн. Но математика с этим новым представлением справляется без особого напряжения.
Мы несколько по разному понимаем с вами реальность мира. Реальный мир — это мир данный в ощущениях. Вы говорите о физическом мире как материалист — т.е. мире данном только во внешних ощущениях. Я отношу себя к кантистам — и это позволяет мне говорить о ощущения происходящих у моем мозгу, но вызванных внешними ощущениями. Например, если я визу распределение по 5 критериям, в моем мозгу реально (в прямом смысле) формируется 5-мерное пространство и я пытаюсь вычислить поверхность на это 5-мерном пространстве.
Но это должно отличаться от того, когда мне совершенно не зачем оперировать с понятиями, которые никак не помогают решить реальные проблемы. А выше обсуждаемое понятие точки — это замкнуто пустое понятие, не применимое ни как для материалистов, ни для кантистов.
Но это должно отличаться от того, когда мне совершенно не зачем оперировать с понятиями, которые никак не помогают решить реальные проблемы. А выше обсуждаемое понятие точки — это замкнуто пустое понятие, не применимое ни как для материалистов, ни для кантистов.
А кто сказал, что наш мир — единственно возможный?
Вообще же эти вопросы довольно неплохо изложены в статье Вигнера «Непостижимая эффективность математики в естественных науках».
Вообще же эти вопросы довольно неплохо изложены в статье Вигнера «Непостижимая эффективность математики в естественных науках».
> Я выписываю из головы последовательность из N нулей и единиц и потом N раз бросаю монетку. Какова вероятность того, что результаты бросков будут соответствовать этой последовательности?
ну прочитайте про генераторы псевдослучайности… причем тут это?
ну прочитайте про генераторы псевдослучайности… причем тут это?
Или Вам кажется, что я не повторю псевдослучайность? Так это была одна из моих работ на втором курсе :) Повторяются еще как.
Псевдослучайность тут не при чем. Я беру обычную честную монетку.
Вероятность будет 1/2^N, так?
Вероятность будет 1/2^N, так?
Ну и?
Прошу в вопросах, предполагающих ответ «да/нет», помимо комментария к ответу, писать этот ответ в явном виде.
Буду считать, что Вы согласились.
Выше Вы утверждали, что бывают бесконечные последовательности, вероятность получить которые больше нуля. Возьмем такую последовательность X, пусть вероятность ее получить больше эпсилон. Зафиксируем какое-нибудь N такое, что эпсилон > 1 / 2^N. Тогда вероятность получить всю последовательность больше эпсилон, а вероятность получить ее начало длины N равно 1/2^N, что меньше эпсилон. Т.е. вероятность получить всю последовательность меньше, чем вероятность получить ее начало.
Буду считать, что Вы согласились.
Выше Вы утверждали, что бывают бесконечные последовательности, вероятность получить которые больше нуля. Возьмем такую последовательность X, пусть вероятность ее получить больше эпсилон. Зафиксируем какое-нибудь N такое, что эпсилон > 1 / 2^N. Тогда вероятность получить всю последовательность больше эпсилон, а вероятность получить ее начало длины N равно 1/2^N, что меньше эпсилон. Т.е. вероятность получить всю последовательность меньше, чем вероятность получить ее начало.
> Т.е. вероятность получить всю последовательность меньше, чем вероятность получить ее начало
И что. Вполне логично. Получить более длинную последовательность сложнее, чем более короткую… В чем примус?
И что. Вполне логично. Получить более длинную последовательность сложнее, чем более короткую… В чем примус?
Примус в опечатке. Последнее предложение предыдущего коммента противоречит предпоследнему:) Имелось в виду, что
«вероятность получить всю последовательность» > эпсилон > 1/2^N > «вероятность получить начало последовательности».
«вероятность получить всю последовательность» > эпсилон > 1/2^N > «вероятность получить начало последовательности».
> Значит, если мы понимаем длину как «сумму длин точек, состовляющих кривую», то окружности большего и меньшего колеса имеют одинаковую длину
Ничего это не значит — не делаете неверный вывод.
Ничего это не значит — не делаете неверный вывод.
И более того, считаю что подобного рода определения ТОЛЬКО и должны быть в математике, что было ясно их содержание, а не только на интуитивном уровне.
К примеру, я спрашивал у математиков, что такой дифференциалы или там тензор — ни кто не дал нам нормального четкого ответа. А потом слушу различные признания из уст серьезных математиков «мы не знаем что такое дифференциалы», мы только можем с ними оперировать как с с символами. Но это не является знанием.
К примеру, я спрашивал у математиков, что такой дифференциалы или там тензор — ни кто не дал нам нормального четкого ответа. А потом слушу различные признания из уст серьезных математиков «мы не знаем что такое дифференциалы», мы только можем с ними оперировать как с с символами. Но это не является знанием.
Какие-то неправильные математики Вам попадались:)
Дифференциал функции в точке — есть линейное отображение, приближающее функцию в данной точке.
Тензор ранга (m, n) над пространством V — это полилинейный функционал на V^m x (V^*)^n (x — прямое произведение).
Дифференциал функции в точке — есть линейное отображение, приближающее функцию в данной точке.
Тензор ранга (m, n) над пространством V — это полилинейный функционал на V^m x (V^*)^n (x — прямое произведение).
Вы начните с того, что объясните парадокс вашего определения точки:
«фигура имеющая объем состоит из частей не имеющих объем?»
А потом будем говорить о определениях построенных на парадоксе.
«фигура имеющая объем состоит из частей не имеющих объем?»
А потом будем говорить о определениях построенных на парадоксе.
Парадокса в этом нету. У меры есть свойство счетной аддитивности: мера объединения не более чем счетного семейства попарно непересекающихся измеримых множеств есть сумма их мер. А фигура состоит из континуального (более чем счетного) семейства точек.
Кстати, точка имеет объем, равный нулю. Это важное отличие, потому что бывают множества, действительно неимеющие объема (неизмеримые).
> Какие-то неправильные математики Вам попадались
Сказал студент доктору математики Александр Виноградову :) см. с 35 минуты
Сказал студент доктору математики Александр Виноградову :) см. с 35 минуты
> В случае формальной логики есть сигнатура
Вы путаете формальную логику и математическую. И увы эти значки смысла не добавляют, а лишь их растворяют. Тем более каждый значок должен быть объяснен — как вы там сказали — артефактами естественного языка.
Вы путаете формальную логику и математическую. И увы эти значки смысла не добавляют, а лишь их растворяют. Тем более каждый значок должен быть объяснен — как вы там сказали — артефактами естественного языка.
Не должен. См., например, Бурбаки.
Ну да, есть такой момент. Я говорил о математической логике (так как не очень понимаю, о каком формализме можно говорить вне математики:D).
Ну да, есть такой момент. Я говорил о математической логике (так как не очень понимаю, о каком формализме можно говорить вне математики:D).
:)… о да, вам еще надо понять откуда слово формальная взялось…
ну, а сказки, где «не должен» мы оставим в стороне, и так за оффтопили
ну, а сказки, где «не должен» мы оставим в стороне, и так за оффтопили
Просто Вы строите какую-то свою, отличную от классической теорию. Мне интересно, есть ли за ней хоть что-то, или это очередная болтология по типу «начал православной арифметики». Пока что аргументов в пользу первого варианта я не вижу.
Я ничего не строю! Я лишь указал как дать определение точки, и все. И могу указать на не корректность текущей аксиомы под название точка.
На самом деле, то определение, которое сейчас принято — никто его в этом смысле не использует. Я лишь вербализовал то, что сейчас понимают под точкой.
То, что Вы указали, является чем угодно, но не определением.
Укажите.
Укажите.
Вам снова процитировать, что такое определение, хорошо:
логическая процедура придания строго фиксированного смысла терминам языка
Я придал/вербализовал термину языка «точка» строгий смысл, связанный с его реальным использованием.
логическая процедура придания строго фиксированного смысла терминам языка
Я придал/вербализовал термину языка «точка» строгий смысл, связанный с его реальным использованием.
То, что Вы сделали, никак нельзя назвать сколь-нибудь строгим.
Строгое или нет определяется тем соответствует ли моей определение реальному миру. Пока противоречий я не вижу.
Вау! Шикарное определение строгости)
Тогда верхом строгости будет определение «бозон Хиггса — это непонятная хрень».
Тогда верхом строгости будет определение «бозон Хиггса — это непонятная хрень».
«бозон Хиггса — это непонятная хрень» — сейчас это так и есть :) в отношении реального физического мира
Другое дело, что люди под этим понимают… и тут я сомневаюсь что они это определяют как нибудь строго.
Другое дело, что люди под этим понимают… и тут я сомневаюсь что они это определяют как нибудь строго.
Определяют. Стандартная модель — хорошая красивая математическая теория.
>«бозон Хиггса — это непонятная хрень» — сейчас это так и есть :) в отношении реального физического мира
Что есть «реальный физический мир»? Тот узкий срез окружающей нас Вселенной, который мы можем наблюдать при помощи ограниченного набора примитивных устройств?
Что есть «реальный физический мир»? Тот узкий срез окружающей нас Вселенной, который мы можем наблюдать при помощи ограниченного набора примитивных устройств?
Да, представьте себе именно это и объем этого реального физического мира растет вместе с нашими знаниями и приборами — вот уж поистине Большой взрыв Это оставлю тут как ответ на вопрос — что такое реальный мир :) — но вот это философская аксиоматика, в отличии от определения точки
>Да, представьте себе именно это и объем этого реального физического мира растет вместе с нашими знаниями и приборами
В таком случае «в отношении реального физического мира» бозон Хиггса — это вовсе не «непонятная хрень», а вполне определённый объект.
В таком случае «в отношении реального физического мира» бозон Хиггса — это вовсе не «непонятная хрень», а вполне определённый объект.
Как раз нет — он за пределами нашего реального мира, сейчас он находится только в мире Идей.
В таком случае подавляющее большинство того, что вы называете «реальным миром», таковым не является, ибо существующие «законы природы» (начиная с Ньютоновых) на самом деле лишь грубые приближения для определённых частных случаев, т.е. они ничем не лучше как той же теории струн, так и предположения Хиггса о существовании бозона.
Бозон Хиггса — не вытекает из впечатлений о физическом мире с необходимостью (как бы с другой стороны не подтверждено в эксперименте ничем, что может давать о нем хоть какое либо впечатление). Поэтому бозон Хиггса — это абстракция математическая или философская, что в данном случае одно и тоже.
Ньютоновские приближения — есть существующие законы природы, с той лишь погрешностью, что они идеализированы для какого-то случая. Но наш мозг увы только так и устроен, что не может воспринимать информацию по другому — а лишь с каким то приближением, или обобщением вида «на сколько я знаю по другому не было». Это реальная особенность мыслительной деятельности и с этим надо считаться. Т.е. даже желая воспринимать лучше и зная как это сделать — мы не знаем четкого рецепта, поэтому одни понимают на уровне одних образов/понятий, другие на уровни других… и лишь немногие на опыте исследования. Но это искажение, отличается от фантастики.
Ньютоновские приближения — есть существующие законы природы, с той лишь погрешностью, что они идеализированы для какого-то случая. Но наш мозг увы только так и устроен, что не может воспринимать информацию по другому — а лишь с каким то приближением, или обобщением вида «на сколько я знаю по другому не было». Это реальная особенность мыслительной деятельности и с этим надо считаться. Т.е. даже желая воспринимать лучше и зная как это сделать — мы не знаем четкого рецепта, поэтому одни понимают на уровне одних образов/понятий, другие на уровни других… и лишь немногие на опыте исследования. Но это искажение, отличается от фантастики.
Да, это некоторая проблема — физика уже добралась до областей, где привычные аналогии не работают. В макромире нет ничего, похожего на элементарные частицы. Но с ними всё равно можно работать, с помощью математики.
«Мы можем понять то, что не можем представить»
«Мы можем понять то, что не можем представить»
В том то и дело, что математика не разрешило эту проблему, вопрос упирается в неполноту квантовой механики. И проблема тут как раз в том, что математики не могут создать адекватный инструмент для ей описания.
Вроде бы там всё хорошо — тензорный анализ на гильбертовых пространствах и прочие милые вещи.
Приведите, пожалуйста, свидетельства обратного, если они у Вас есть. Аргументы вида «квантовая механика противоречит моему здравому смыслу» не принимаются.
Приведите, пожалуйста, свидетельства обратного, если они у Вас есть. Аргументы вида «квантовая механика противоречит моему здравому смыслу» не принимаются.
Имелся введу «Парадокс Эйнштейна — Подольского — Розена» и прочие сопряженное вещи.
Этот (и многие другие) «парадоксы» квантовой физики связаны с попытками проведения интуитивных аналогий между законами макро и микро миров. Вполне возможно, что таких аналогий просто нет (и современная квантовая физика исходит именно из этого). В этом случае нет ничего странного, что попытки применения неприменимого в данном случае аппарата приводят к противоречию.
Вообще, говорить о квантовой физике есть смысл только в терминах математики — интуиция в ней не работает. По сути, есть некоторый набор параметров, которые можно измерить, и законы изменения которых можно красиво описать с помощью соответствующего формализма. А что понимать под их «физическим смыслом» — не очень понятно.
Вообще, говорить о квантовой физике есть смысл только в терминах математики — интуиция в ней не работает. По сути, есть некоторый набор параметров, которые можно измерить, и законы изменения которых можно красиво описать с помощью соответствующего формализма. А что понимать под их «физическим смыслом» — не очень понятно.
Ну, вы вкратце повторили ответ Боа :) — он не удовлетворителен. Пока нет понимания — нет и сущности о которой можно говорить с 100% уверенностью.
Он не удовлетворителен == он не удовлетворяет Вас ?)
Проблема в том, что наше «понимание» основано на проведении аналогий с привычными вещами. А ничего аналогичного элементарным частицам среди привычных вещей нет.
Проблема в том, что наше «понимание» основано на проведении аналогий с привычными вещами. А ничего аналогичного элементарным частицам среди привычных вещей нет.
Не только меня :) Он не удовлетворителен для науки. Он не дает понимания происходящих процессов.
«Понимание» — штука субъективная. Ученые, активно работающие в этой области, вырабатывают некое подобие интуиции. Есть даже такой термин — «математическая интуиция»:)
А науке нужно процессы описывать так, чтобы по этим описаниям можно было делать предсказания и рассчеты «что нужно сделать, чтобы получить такой эффект».
А науке нужно процессы описывать так, чтобы по этим описаниям можно было делать предсказания и рассчеты «что нужно сделать, чтобы получить такой эффект».
> А ничего аналогичного элементарным частицам среди привычных вещей нет.
Нет — это просто роспись в невежестве, не умении объяснить, а все остальное сказочки.
В такой манере можно создать некую искусственную систему, которая будет работать как мозг человека. Но НИКТО не будет понимать КАК она работает. После чего мы будем утверждать — а просто нет ничего аналогичного в том как работает мозг, и нам не суждено это понять. Это сродни объяснению того, что замыслы Бога не возможно понять, а надо принимать их как есть без способности понимать.
Нет — это просто роспись в невежестве, не умении объяснить, а все остальное сказочки.
В такой манере можно создать некую искусственную систему, которая будет работать как мозг человека. Но НИКТО не будет понимать КАК она работает. После чего мы будем утверждать — а просто нет ничего аналогичного в том как работает мозг, и нам не суждено это понять. Это сродни объяснению того, что замыслы Бога не возможно понять, а надо принимать их как есть без способности понимать.
И да, т.н. «Ответ Бора» — не удовлетворителен, он сродни ответу «не понимаю, но это работает»
«бозон Хиггса — это непонятная хрень» — а вы разве не согласны? :)
в смысле однозначно определяется. Если используя мое определение, вы покажите, что под точкой можно понимать, что то такое, что не является точкой при рассмотрении — то тогда это будет не строгим определением. Иначе увы, это только ваше поверхностное мнение.
Вам нужно понять, хотя бы одно. Точка — это термин — означающий желание исследователя, что-то представить себе из реальности.
напомню:
Так вот в этом смысле у меня строго определено, что есть точка, увы, в отличии от классической геометрии.
Определение, дефиниция (лат. definitio — предел, граница) — логическая процедура придания строго фиксированного смысла терминам языка
Так вот в этом смысле у меня строго определено, что есть точка, увы, в отличии от классической геометрии.
А вот какой бред написан в Википедии:
Ну как может состоять фигура из нульмерных объектом — бред да и только. А на этом построена вся математика…
В геометрии, топологии и близких разделах математики то́чкой называют абстрактный объект в пространстве, не имеющий ни объёма, ни площади, ни длины, ни каких-либо других измеримых характеристик. Таким образом, точкой называют нульмерный объект. Точка является одним из фундаментальных понятий в математике; любая геометрическая фигура считается состоящей из точек.
Ну как может состоять фигура из нульмерных объектом — бред да и только. А на этом построена вся математика…
А потом удивляемся как в физике появляется теории из полной хрени…
facepalm
Да, фигура есть континуальное множество нульмерных точек. В чем проблема?
Да, фигура есть континуальное множество нульмерных точек. В чем проблема?
Чего? фигура имеющая объем состоит из частей не имеющих объем? Бред!
Рассмотрим прямую.
Какую длину имеет точка 0?
Точка 1?
Точка 1/2?
Точка 0.1347814237723456713...?
Какую длину имеет точка 0?
Точка 1?
Точка 1/2?
Точка 0.1347814237723456713...?
Чтобы рассматривать прямую — её нужно определить. Не определяемыми могут быть только вещи из реального мира. Предложите то, что вы хотите считать точкой в реальном физическом мире, тогда будет о чем говорить.
Дайте определение «реального мира» для начала.
Я говорю о математической прямой.
Я говорю о математической прямой.
Так мы далеко пойдем и все это в рамках ООП-парадигмы ;)
Что такое математическая прямая? Как она соответствует понятиям из реального мира?
Или Вы мне предлагаете пользоваться текущим совершенно смешным определением
Прямая — одно из основных понятий геометрии.
Увы, я тогда не понимаю что это за хрень такая.
Что такое математическая прямая? Как она соответствует понятиям из реального мира?
Или Вы мне предлагаете пользоваться текущим совершенно смешным определением
Прямая — одно из основных понятий геометрии.
При систематическом изложении геометрии прямая линия обычно принимается за одно из исходных понятий, которое лишь косвенным образом определяется аксиомами геометрии.
Увы, я тогда не понимаю что это за хрень такая.
А что такое «реальный мир»?)
Есть неопределяемое понятие — множество, и один неопределяемый предикат — принадлежность — «A есть элемент B».
Из этого можно определить натуральные числа. Далее, целые числа — это натуральные плюс «минус натуральные» (например, -n можно определить как {{n}}). Рациональные числа — это множества пар целых чисел, задающих равные дроби. Вещественные числа — это множества рациональных чисел, удовлетворяющих двум свойствам: 1) если x принадлежит вещественному числу и y<x, то y принадлежит вещественному числу; 2) в вещественном числе нет наибольшего (неформально, вещественное число есть множество рациональных чисел, его меньших). На вещественных числах можно ввести арифметические операции.
Ура, мы построили теорию вещественных чисел из теории множеств. Далее можно ввести плоскость (как множество пар вещественных чисел). Тогда множество точек плоскости X есть прямая, если существуют a, b и c такие, что X состоит в точности из пар <x, y>, удовлетворяющих условию a*x+b*y+c=0.
Тут же можно идти дальше и строить нормальную теорию меры, в которой вполне нормально, что объединение множеств с нулевой мерой может иметь ненулевую меру. И т.д.
Есть неопределяемое понятие — множество, и один неопределяемый предикат — принадлежность — «A есть элемент B».
Из этого можно определить натуральные числа. Далее, целые числа — это натуральные плюс «минус натуральные» (например, -n можно определить как {{n}}). Рациональные числа — это множества пар целых чисел, задающих равные дроби. Вещественные числа — это множества рациональных чисел, удовлетворяющих двум свойствам: 1) если x принадлежит вещественному числу и y<x, то y принадлежит вещественному числу; 2) в вещественном числе нет наибольшего (неформально, вещественное число есть множество рациональных чисел, его меньших). На вещественных числах можно ввести арифметические операции.
Ура, мы построили теорию вещественных чисел из теории множеств. Далее можно ввести плоскость (как множество пар вещественных чисел). Тогда множество точек плоскости X есть прямая, если существуют a, b и c такие, что X состоит в точности из пар <x, y>, удовлетворяющих условию a*x+b*y+c=0.
Тут же можно идти дальше и строить нормальную теорию меры, в которой вполне нормально, что объединение множеств с нулевой мерой может иметь ненулевую меру. И т.д.
Про реальный мир, выше ссылка дана. А просто понятия построенные на не определяемых понятиях — это выше моего понимания — это метафизика.
Чтобы строить не противоречивые определения, вам почаще надо читать классиков. Например, в данном случае Декарта. Нельзя определить какие либо числа без понятия о количестве — это будет фикция. Если же определять нормально, то окажется, что все становится на свои места.
Количество есть реальная пространственная и временная определённость тел/предметов/объектов, которая выражается через число.
Таким образом, пока число не сопоставлено с количеством из реального мира — оно есть нечто.
Точно так же как точка не имеющая объема — есть нечто. Чтобы говорить о точке мы должны сопоставить/выбрать интересующий нас объем и если речь о физике, то еще и плотность.
А у вас наслоения понятий, смысла которых ЧЕТКО не определен, а соответственно не дано их определения.
Количество есть реальная пространственная и временная определённость тел/предметов/объектов, которая выражается через число.
Таким образом, пока число не сопоставлено с количеством из реального мира — оно есть нечто.
Точно так же как точка не имеющая объема — есть нечто. Чтобы говорить о точке мы должны сопоставить/выбрать интересующий нас объем и если речь о физике, то еще и плотность.
А у вас наслоения понятий, смысла которых ЧЕТКО не определен, а соответственно не дано их определения.
На понятиях из реального мира далеко не уедешь. Там даже иррациональные числа увидеть трудно, их получили уже исходя из теоретических рассуждений (вроде теоремы Пифагора). Комплексные числа (без которых нет ни квантовой механики, ни электродинамики) — вообще не просматриваются. А уж бесконечно малые, на которых вообще вся Ньютоновская физика постоена — фикция в чистом виде, игра слов и воображения. Но она работает и активно используется.
Пока проекция теории на реальный мир не обнаруживает противоречий, почему бы ей не воспользоваться. А когда противоречия возникнут, например, парадокс Банаха-Тарского, противоречащий закону сохранения массы, придется выбирать — либо оставляем аксиому выбора, с которой математика получается гораздо удобнее, либо отказываемся от нее — и получаем странную конструкцию, в которой не можем почти ничего доказать.
Пока проекция теории на реальный мир не обнаруживает противоречий, почему бы ей не воспользоваться. А когда противоречия возникнут, например, парадокс Банаха-Тарского, противоречащий закону сохранения массы, придется выбирать — либо оставляем аксиому выбора, с которой математика получается гораздо удобнее, либо отказываемся от нее — и получаем странную конструкцию, в которой не можем почти ничего доказать.
Это уже нормальный и верный подход. Но это совсем не отменяет того, что нужно СТАРАТЬСЯ давать точный определения, а не противоречивые аксиомы, хотя бы там где это возможно. А с точкой — это как видим возможно.
О, круто, аксиомы противоречивы. Выведите, пожалуйста, в любой из основных теорий (геометрия, теория меры, арифметика Пеано, дифгем — где хотите) утверждение «0 = 1».
Круто. Может быть, докажете непротиворечивость ZFC в рамках ее самой?
А я где-то утверждал, что ZFC непротиворечива?)
tac же утверждал о противоречивости.
tac же утверждал о противоречивости.
Круто, то что вы берете за аксиомы аналогичны 1=0 вещи. Надо напоминать, что аксиомы — это не то что вы придумали? Или сами поймете, что такое аксиомы?
Аксиомы — это список формул. Об аксиомах какого именно раздела математики Вы говорите?
Вы утверждаете, что они противоречивы. По определению, теория противоречива, если в ней выводится «A и не A». Это равносильно тому, что в ней выводится «1=0» (при условии, что мы работаем в сигнатуре, в которой есть 1, 0 и =).
Вы утверждаете, что они противоречивы. По определению, теория противоречива, если в ней выводится «A и не A». Это равносильно тому, что в ней выводится «1=0» (при условии, что мы работаем в сигнатуре, в которой есть 1, 0 и =).
«аксиома» — «истина, очевидная сама по себе»
я говорю только о точке :) для начала… хотя уверен если покопаться можно найти много…
Аксиома о точке — не очевидна. И вот я не понимаю ваших возражений. Вам чем-то не нравится мое описание… но оно более очевидная истина, и не имеет явных противоречий.
я говорю только о точке :) для начала… хотя уверен если покопаться можно найти много…
Аксиома о точке — не очевидна. И вот я не понимаю ваших возражений. Вам чем-то не нравится мое описание… но оно более очевидная истина, и не имеет явных противоречий.
Видите ли, со времен Декарта математика довольно далеко ушла вперед. Чтобы понимать, что такое строгие определения, почитайте что-нибудь более современное.
Аксиомы можно выбрать. И неопределяемые понятия тоже.
В аналитической проективной геометрии, например, точка определяется как тройка чисел с точностью до пропорциональности. Прямая — другая тройка чисел. А «точка принадлежит прямой» определяется как a*p+b*q+c*r=0.
В теории множество «количество» — не более, чем инвариант отношения эквивалентности, которое определяется как существование биекции, которая определяется, как множество с определенными свойствами… Само множество в этой теории — неопределяемое понятие, но в других построениях, вероятно, можно определить и его.
А вещественное число в матане (в некоторых конструкциях) определяется как точная верхняя грань множества рациональных чисел. Которые, в свою очередь, определяются как… Ну, и так далее.
В аналитической проективной геометрии, например, точка определяется как тройка чисел с точностью до пропорциональности. Прямая — другая тройка чисел. А «точка принадлежит прямой» определяется как a*p+b*q+c*r=0.
В теории множество «количество» — не более, чем инвариант отношения эквивалентности, которое определяется как существование биекции, которая определяется, как множество с определенными свойствами… Само множество в этой теории — неопределяемое понятие, но в других построениях, вероятно, можно определить и его.
А вещественное число в матане (в некоторых конструкциях) определяется как точная верхняя грань множества рациональных чисел. Которые, в свою очередь, определяются как… Ну, и так далее.
В итоге вы получаете множество аксиом, каждая из которых «определяется» через какой-то набор соседок. Это конечно забавная игра терминов, только вот к реальной выводимости имеет мало отношения. В конце концов, само по себе это множество не выводится ниоткуда :)
Аксиомы ни через что не определяются, это просто замкнутые формулы в той или иной сигнатуре.
Ну простейшие понятия со школьной скамьи стыдно уж забывать:
ru.wikipedia.org/wiki/Аксиома
ru.wikipedia.org/wiki/Аксиома
Это вы мне? Я как раз о них не забыл. Слово определяются у меня не зря в кавычки заключено.
Пардон, я видимо как-то по-другому читаю ваши кавычки:
Либо «определяется» у вас не равносильно «выводится» или «доказывается», либо я что-то запутался…
получаете множество аксиом, каждая из которых «определяется» через какой-то набор соседок
Аксио́ма (др.-греч. ἀξίωμα — утверждение, положение), постула́т — утверждение, принимаемое истинным без доказательств, и которое в последующем служит «фундаментом» для построения доказательств в рамках какой-либо теории, дисциплины и т. д.
Либо «определяется» у вас не равносильно «выводится» или «доказывается», либо я что-то запутался…
Да, я могу выбрать много эквивалентных наборов аксиом+«неопределяемых понятий». С точки зрения каждого такого набора остальные будут состоять из теорем. Ну и что?
Точно так же базовые классы и интерфейсы в программе я могу выбирать по-разному. И строить другие классы через них. Получится много более или менее удобных/эффективных реализаций одного и того же. Опять же, ну и что?
Точно так же базовые классы и интерфейсы в программе я могу выбирать по-разному. И строить другие классы через них. Получится много более или менее удобных/эффективных реализаций одного и того же. Опять же, ну и что?
А то, что значальное утверждение неверное. Вы вернитесь и посмотрите, о чем шла речь.
Вы про слово «выводится»? Даже не знаю. Можно было бы сказать «выбирается», но учитывая проделанный объем работы, после которого можно сделать этот выбор…
«Проанализировав полученный набор утверждений, приходим к выводу, что в качестве набора независимых аксиом для нашей теории удобно выбрать следующие...» Разве не так? И как после этого говорить, что они не выводятся?
«Проанализировав полученный набор утверждений, приходим к выводу, что в качестве набора независимых аксиом для нашей теории удобно выбрать следующие...» Разве не так? И как после этого говорить, что они не выводятся?
Ну да, в теории категорий (так же известной, как «абстрактная чепуха» и «наука о рисовании стрелочек») множества вполне определяются.
Геометрия началась с вавилонских табличек-рецептов. Евклид был намного позже. И так в любой науке. Но привыкший ко всему готовому на уроках о таком не думает
Это не совсем так, например, к аксиоматике Гильберта пришли в процессе весьма продолжительного развития геометрии и плясок с бубном вокруг пятого постулата. На ранних этапах математики вообще упирались не на аксиомы, а на «очевидность», продемонстрированную чертежами. В этом смысле очень хорошо прослеживается параллель с разработкой ПО — изначально условно-рабочий прототип, потом его «отливка» в ООП.
Ну как-как? Я вот тоже запнулся, потом смотрю: «соавтор С++»… Ну, думаю: okay, может я — лох… И так оно обычно и бывает, не возможно все перепроверять.
Как немного знакомый с математикой человек, могу сказать: чушь. В основных разделах математики аксиомы уже давно зафиксированы.
Так уж и давно. Аксиоматике ZFC меньше ста лет. Кроме того, она только в наше время считается основой математики, до нее аксиомы были другими. И не факт, что она продержится в качестве основы вечно.
Ну, и в каждой новой теории принимаются свои, частные, наборы аксиом и понятий. Правда, чаще эти аксиомы называются свойствами — но теоремы выводятся из них как из аксиом.
Ну, и в каждой новой теории принимаются свои, частные, наборы аксиом и понятий. Правда, чаще эти аксиомы называются свойствами — но теоремы выводятся из них как из аксиом.
Существует несколько способов решения задач: синтез и анализ, дедукция и индукция… и т.п… Так что я бы за математиков так уверенно не говорил.
По вашему проще доказать сначала что 2+2 = 4 и только потом начать этим пользоваться.
Открою вам тайну, круг круглый — аксиома
Квадрат — фигура с четырьмя гранями — аксиома.
Сначала сущности, потом — все остальное, так устроен весь мир.
Открою вам тайну, круг круглый — аксиома
Квадрат — фигура с четырьмя гранями — аксиома.
Сначала сущности, потом — все остальное, так устроен весь мир.
«Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.»
LOL WHAT??? Я не сомневаюсь в авторитете автора, но, как студент факультета прикладной математики, кроме как посочувствовать человеку, сказавшему такое, ничего не могу. Математика начинается с аксиом, правил которые задаются в пространстве, которое мы определяем.И только на аксиомах строятся доказательства.
LOL WHAT??? Я не сомневаюсь в авторитете автора, но, как студент факультета прикладной математики, кроме как посочувствовать человеку, сказавшему такое, ничего не могу. Математика начинается с аксиом, правил которые задаются в пространстве, которое мы определяем.И только на аксиомах строятся доказательства.
Вы знаете, это чем-то напоминает диалог с креационистами — они придумывают тезисы эволюционистов, а потом успешно их опровергают. Александр написал все верно, но он подменил методологию, как она описывается у Буча, своим измышлением. Уже во многих источниках описано, что работа начинается с прототипа, на базе которого в процессе рефакторинга создаются работоспособные классы, удовлетворяющие потребностям проекта. Никто не предлагает запрягать телегу в лошадь. Методология ООП как раз является тем, что описано во втором абзаце, но никак не в первом. И то, что ООП используется неправильно — это не проблема ООП.
НЛО прилетело и опубликовало эту надпись здесь
Нет, ООП — отстой. Раздутая, тяжёлая и неповоротливая хрень.
Вот зачем вы это пишите? Это не подход.
К счастью ООП решает свои задачи и решает их, по всей видимости, хорошо, так как иначе им не пользовалось такое Огромное количество разработчиков. Думайте глубже — решайте на нем задачи, требующие ООП для элегантного исполнения.
К счастью ООП решает свои задачи и решает их, по всей видимости, хорошо, так как иначе им не пользовалось такое Огромное количество разработчиков. Думайте глубже — решайте на нем задачи, требующие ООП для элегантного исполнения.
Существует мнение, что основная задача, которую решает ООП — это создание дополнительного объёма кода на пустом месте. Просто в США была норма программирования: 300 строк в день. Сложно написать 300 вменяемых строк в день. А если это всё заворачивается в интерфейсы и классы, да ещё есть автогенераторы из UML и т.д. В общем, индустриальное счастье. И ещё с умным видом можно рассуждать о паттернах. Поэтому тема и была раскручена. И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее (не путать с системами типов).
И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее (не путать с системами типов).
Вы это готовы доказать для любого класса задач?
Сложно написать 300 строк кода в день? Вы должно быть шутите. И ООП тут совсем не обязателен.
Можно взять ассемблер x86 и спокойно начать на нем писать. Поверьте, простейшая программа выльется в весьма солидный объем кода.
Можно взять ассемблер x86 и спокойно начать на нем писать. Поверьте, простейшая программа выльется в весьма солидный объем кода.
Это зависит от того, разрешен ли у вас Copy/Paste, или блок скопированных строк считается за одну :)
Но да, 300 строк на x86 — не проблема (после небольшой тренировки).
Но да, 300 строк на x86 — не проблема (после небольшой тренировки).
Вы шутите? Это-же ассемблер, одна инструкция — одна строка, и каждая инструкция — низкоуровневая, для копирования области памяти через индексные регистры их уже нужно 4, да и для вызова процедуры копирования памяти столько-же, так как 3 инструкции — для задания откуда, куда и сколько, которые нужны так или иначе, 300 строк тут — вообще пшик, было-бы желание.
Желание и время. Чтобы каждое копирование памяти написать с нуля и эффективно, нужно хоть чуть-чуть потренироваться (хотя бы, чтобы понять, уместно в конкретном случае rep movsw, или лучше как-нибудь по-другому).
Мы-то разговор ведем в ключе того что ленивые программисты придумали мерзкий ооп чтобы кода больше вышло — так что с этой точки зрения самый эффективный код вот:
строчек — аж целых 10!
mov eax, источник
mov ebx, назначение
mov ecx, 10
loop:
dec ecx
mov byte [ebx], [eax]
inc eax
inc ebx
cmp ecx, 0
jnz loop
строчек — аж целых 10!
Точно ассемблер оптимален по скорости порождения правильно работающего кода?
Не понял о чем вы — но наверное да :)
Это значит, что задача «написать N работающих строк кода на ассемблере» решается быстрее задачи «написать N работающих строк кода на С++».
Вообще же, думаю, задачу следует ставить так: «решить задачу в течении данного времени, потратив на это максимальное количество строк кода».
Вообще же, думаю, задачу следует ставить так: «решить задачу в течении данного времени, потратив на это максимальное количество строк кода».
А, ну это безусловно, каждая команда си — это десяток, если не сотня драгоценных ассемблерных инструкций! К тому-же инлайновое переписывание команды printf заново — на си могут счесть говнокодом, а на ассемблере это уникальная, эффективная реализация и устранение внешних зависимостей :)
Да, ассемблер эффективнее. Вариантов там меньше, и фрагмент, подобный вышеприведенному, пишется на автомате, быстрее, чем за минуту. И почти не отнимает ресурсов мозга.
Кстати,
mov byte [ebx], [eax]
— разве такое бывает? Даже если не byte, а byte ptr?
Пересылки «память — память» я после PDP не встречал (не считая команд LDI / movsw и ассемблера DCPU-16)
И еще, если уж нужны строчки:
— честнее будет. А то вдруг окажется 10==0?
mov byte [ebx], [eax]
— разве такое бывает? Даже если не byte, а byte ptr?
Пересылки «память — память» я после PDP не встречал (не считая команд LDI / movsw и ассемблера DCPU-16)
И еще, если уж нужны строчки:
push esi
push ebx
push ecx
mov esi, источник
mov ebx, назначение
mov ecx, 10
jmp short start_loop
loop:
mov al,[esi]
inc esi
mov [ebx],al
inc ebx
dec ecx
start_loop:
cmp ecx, 0
jnz loop
pop ecx
pop ebx
pop esi
— честнее будет. А то вдруг окажется 10==0?
Почитайте хотя-бы тезисы Алана Кея, которые он сделал при создании Smalltalk.
Что на счет избыточности ООП кода, то это скорее касается языков со статической типизацией. Однако такая избыточность оправдана, если нужна высокая производительность, т.к. в том же питоне во время вызова метода работает MRO, который не очень быстрый.
Что на счет избыточности ООП кода, то это скорее касается языков со статической типизацией. Однако такая избыточность оправдана, если нужна высокая производительность, т.к. в том же питоне во время вызова метода работает MRO, который не очень быстрый.
Как связана избыточность кода и статическая типизация?
> Как связана избыточность кода и статическая типизация?
Прямо и косвенно :)
Прямо — это более избыточный синтаксис для того, чтобы компилятору дать информацию о классе, всех его атрибутов и сигнатурах (тип, модификторы доступа). В динамических языках этого обычно нет, за что приходится расплачиваться в рантайме.
Косвенно — при статической типизации и отсутствии множественного наследования необходимо применять различные паттерны ООП, которые для динамических языков просто не нужны (пример — абстрактная фабрика, на питоне вы его врядли встретите).
Прямо и косвенно :)
Прямо — это более избыточный синтаксис для того, чтобы компилятору дать информацию о классе, всех его атрибутов и сигнатурах (тип, модификторы доступа). В динамических языках этого обычно нет, за что приходится расплачиваться в рантайме.
Косвенно — при статической типизации и отсутствии множественного наследования необходимо применять различные паттерны ООП, которые для динамических языков просто не нужны (пример — абстрактная фабрика, на питоне вы его врядли встретите).
Вот статическая типизация:
foo x = x + 1
Избыточный синтаксис нужен не при статической типизации, а при обязательной декларации типов, но это не обязательно присутствует в статически-типизируемом языке.
foo x = x + 1
Избыточный синтаксис нужен не при статической типизации, а при обязательной декларации типов, но это не обязательно присутствует в статически-типизируемом языке.
В реальной программе выводилка очень быстро загрустит без подсказок, чем больше полиморфизма, тем быстрее. Плюс много места занимает непосредственно описание структур данных.
Ну допустим у вас есть рекламная кампания, в ней объявления, у них ключевые фразы и настройки разные. Без объектов у вас скорее всего будет каша, плюс нельзя будет спросить у конкретного объявления его заголовок, url, его фразы и т.п., а надо будет это реализовывать как-то через переменные и функции, что лично мне не близко ввиду излишней замороченности кода.
>И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее
Вот уж дудки. Если у меня предметная область моделируется объектами, то я буду использовать ООП как естественный подход к программированию данной предметной области.
Ну и т.д. Все сильно зависит от специфики каждого приложения.
Вот уж дудки. Если у меня предметная область моделируется объектами, то я буду использовать ООП как естественный подход к программированию данной предметной области.
Ну и т.д. Все сильно зависит от специфики каждого приложения.
это где такая предметная область?
Да где угодно. Проще сказать, где ее нет.
Вот вам интернет-магазин. Там есть товары, хранилища товаров, пользователи, платежи — все это естественно представляется объектами, не нужно ничего придумывать.
Другое дело, что любят нагородить 100500 хелперных классов по всем правилам (каких-нибудь ОбертокШаблоновФабрикиПрототипов), а потом путаются во всей этой куче. Ну так никто не заставляет писать настолько абстрактно.
Вот вам интернет-магазин. Там есть товары, хранилища товаров, пользователи, платежи — все это естественно представляется объектами, не нужно ничего придумывать.
Другое дело, что любят нагородить 100500 хелперных классов по всем правилам (каких-нибудь ОбертокШаблоновФабрикиПрототипов), а потом путаются во всей этой куче. Ну так никто не заставляет писать настолько абстрактно.
это данные предметной области. Структуры данных действительно есть везде. Структуры данных, а не оопшные объекты. В книгах по ооп делают подмену понятий, как будто это единственный вариант.
В любом магазине будет табличка со списком платежей (очевидная структура данных, которая была и при бумажном обороте), а мапить ли ее на объектную модель языка далеко не очевидный и естественный вопрос с кучей вариантов, ни один из которых не будет естественнее строчки в амбарной книге.
Если мапить, допустим, товар, из-за принципов ООП автоматом возникнет не один класс — товар, а зоопарк, например различные рендедеры товара в разные представления. А там и до фабрики представлений недалеко. И в любом проекте таких классов будет большинство — не объектов предметной области, а конвертеров и прочих конвертеров конвертеров. Спасает от этого отделение алгоритмов от структур данных, а ооп говорит о противоположном.
Иначе это не ооп, а синтаксисческий сахар с неявным this вместо явного. Который имеет смысл в языках без модулей как замена им (а также функциям высшего порядка — паттерны типа action) и является сейчас мейнстримом.
В любом магазине будет табличка со списком платежей (очевидная структура данных, которая была и при бумажном обороте), а мапить ли ее на объектную модель языка далеко не очевидный и естественный вопрос с кучей вариантов, ни один из которых не будет естественнее строчки в амбарной книге.
Если мапить, допустим, товар, из-за принципов ООП автоматом возникнет не один класс — товар, а зоопарк, например различные рендедеры товара в разные представления. А там и до фабрики представлений недалеко. И в любом проекте таких классов будет большинство — не объектов предметной области, а конвертеров и прочих конвертеров конвертеров. Спасает от этого отделение алгоритмов от структур данных, а ооп говорит о противоположном.
Иначе это не ооп, а синтаксисческий сахар с неявным this вместо явного. Который имеет смысл в языках без модулей как замена им (а также функциям высшего порядка — паттерны типа action) и является сейчас мейнстримом.
> И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее
Надеюсь, я вас правильно понял, и под ООП вы понимаете классы и наследование. В таком случае:
Объясните мне, как элегантно решить данную задачу без ООП.
Надеюсь, я вас правильно понял, и под ООП вы понимаете классы и наследование. В таком случае:
var Shape = new Class({
getAttribute:function(name){ return this.props[name] },
setAttribute:function(name,val){ this.props[name] = val }
});
var Rect = new Class(Shape, {
attrHooks:{} // ...
});
Объясните мне, как элегантно решить данную задачу без ООП.
А какую вы задачу решаете?
Я создаю несколько классов. Rect, Circle, Triangle… У каждого есть абсолютно одинаковые методы — getAttribute и setAttribute.
Я объявляю класс Shape и реализую их в рамках него. А затем просто наследую от него остальные.
Вы мне предлагаете (без наследования) реализовывать их каждый раз заново?
Я объявляю класс Shape и реализую их в рамках него. А затем просто наследую от него остальные.
Вы мне предлагаете (без наследования) реализовывать их каждый раз заново?
Пока вы формулируете задачу в терминах ООП через «я создаю классы» и «у них есть методы», я не смогу вам ответить, так как в ФП нет методов, а есть функции, поэтому сама задача «три класса с одинаковыми методами» там звучит крайне странно.
Вот, например, хотим мы уметь сравнивать числа, строки, whatever you want, в Haskell для этого существует класс типов Eq, это похоже на интерфейсы, но несколько мощнее
Причём реализовано это через обычную структуру, вот такую:
Разница только в том, что во втором случае мне придётся её передавать в функции явно, а класс типов передаётся неявно.
Вот, например, хотим мы уметь сравнивать числа, строки, whatever you want, в Haskell для этого существует класс типов Eq, это похоже на интерфейсы, но несколько мощнее
class Eq a where
(==) :: a -> a -> Bool
-- обратите внимание на то, что с обоих сторон от == значения одного типа
-- т.е. написать 1 == "asd" нельзя, а вот 1 == 2 и "sdd123" == "34sdf" - можно
Причём реализовано это через обычную структуру, вот такую:
data Eq a = Eq { (==) :: a -> a -> Bool }
Разница только в том, что во втором случае мне придётся её передавать в функции явно, а класс типов передаётся неявно.
Мне Haskell сложно читать, давайте всё же что-то поближе к C.
И я не совсем понимаю. Вы предлагаете мне писать так?:
И я не совсем понимаю. Вы предлагаете мне писать так?:
var r = rect_create();
shape_get_attribute(r, 'attrname');
Нет, мы хотим выполнять некоторую операцию над всем объектами, входящими в некую группу, причем для каждого типа объекта эта операция реализуется по-своему.
В терминах ФП это функция по discriminated union, вот только мы хотим добавлять новые типы элементов (=расширять union) и добавлять новое свойственное им поведение уже после выпуска кода и без перекомпиляции (модель плагинов).
В терминах ФП это функция по discriminated union, вот только мы хотим добавлять новые типы элементов (=расширять union) и добавлять новое свойственное им поведение уже после выпуска кода и без перекомпиляции (модель плагинов).
Existentials решают эту проблему
Правда на деле это крайне редко нужно, потому что на ФП разрабатывают иначе.
Правда на деле это крайне редко нужно, потому что на ФП разрабатывают иначе.
А как вы решите задачу с расширяемым ПО на ФП?
Я даже не знаю, как ответить на этот столь общий вопрос. Наверное «так же, как и везде». Расширяемое ПО пишут и на Си, и на Erlang, и на OCaml.
Вот понимаете, в ООП есть типовое решение: выделите интерфейс, затем реализуйте его, все.
А какое типовое решение в ФП?
А какое типовое решение в ФП?
Я же написал выше про классы типов, они шире интерфейсов.
Что такое реализовать интерфейс? Предоставить набор функций над конкретным типом данных. В ФП это делается тривиально.
Что такое реализовать интерфейс? Предоставить набор функций над конкретным типом данных. В ФП это делается тривиально.
Эмм.
Я, наверное, чего-то не понимаю, потому что нам надо не просто «предоставить набор функций», а в одном месте (ядро) сформулировать набор функций, а в другом его реализовать, причем несколько раз для одного и того же набора данных.
Я, наверное, чего-то не понимаю, потому что нам надо не просто «предоставить набор функций», а в одном месте (ядро) сформулировать набор функций, а в другом его реализовать, причем несколько раз для одного и того же набора данных.
Пока что все, что я там прочитал, как раз показывает на то, что люди реализуют вещи, которые уже реализованы в ООП. Про что изначально речь и шла — ООП лучше справляется с контрактами компонентов.
Ну и как реализовать на ООП вот такое:
Через isEqual что ли с принятием 2-х object?
class Eq a where
(==) :: a -> a -> Bool
Через isEqual что ли с принятием 2-х object?
Я, к сожалению, не знаком с Хаскелем, поэтому не могу сразу определить, что этот код делает. Судя по примерам, это аналог интерфейсов/дженериков (ближе к дженерикам в c#), соответственно, для них и реализовывать. Если вы приведете более полный пример, а еще лучше — задачу, то я смогу ответить более точно.
К сожалению, у меня нет времени тут расписывать всё это.
Это «интерфейс», реализуя который мы получаем функцию сравнения двух объектов.
Отличие от x.isEqual(y) в том, что isEqual реализован для object и принимает object, поэтому равенство типов приходится проверять внутри самому. Тут же == гарантированно принимает значения одного типа. А вот какого именно — уже неважно.
Это «интерфейс», реализуя который мы получаем функцию сравнения двух объектов.
Отличие от x.isEqual(y) в том, что isEqual реализован для object и принимает object, поэтому равенство типов приходится проверять внутри самому. Тут же == гарантированно принимает значения одного типа. А вот какого именно — уже неважно.
В ООП это прекрасно делается generic-интерфейсами.
Которые слизаны с ФП как раз. Но я отвечал на «Объясните мне, как элегантно решить данную задачу без ООП». Однако я не согласен с утверждением «И в ООП нет ничего, что позволяет решать ту или иную задачу элегантнее», тем не менее всё вполне решается и без наличия в самом языке классов или методов. Особенно если учесть, что ООП — это подход. Тот же Erlang вообще вполне себе ООП (процессы обмениваются сообщения), и на том же Haskell можно сделать ООП через зелёные потоки. Так что сам подход иногда очень хорошо ложится на задачу, но это не значит, что ООП нужен везде, и уж тем более не значит, что без поддержки в языке классов в нём будет что-либо неудобно.
через обыкновенную перегрузку функций. Реализация ad-hoc полиморфизма ортогональна ооп
Вот зачем вы это пишите? Это не подход.Чтобы стать признанным троллем
<?xml version="1.0"?><?xml version="1.0"?> <habrauser>
<login>ShadowHacker</login>
<karma>-65</karma>
<rating>-31.36</rating>
<ratingPosition>-7</ratingPosition> </habrauser>
Миллионы хомячков не могут ошибаться? :)
Вы знаете это очень хороший аргумент. Он универсален. Толпа бывает ошибается, потому в этом конкретном случае, толпа ошибается.
И не нужно называть хомячками Страуструпа, Джеймса Гослинга, Мацумото и других.
И не нужно называть хомячками Страуструпа, Джеймса Гослинга, Мацумото и других.
Толпа бывает ошибается
толпа в принципе глупее отдельно взятых индивидумов
Это скорее применимо к людям которые непосредственно находятся в одном месте. Там разум затуманивается и инстинкты берут свое. В нашем же случае я бы сказал что интеллект толпы что-то среднее со всех ее участников.
Извините за оффтоп.
«Интеллект толпы равен интеллекту ее самого глупого члена, поделенного на размер толпы» (Пратчетт)
«Интеллект толпы равен интеллекту ее самого глупого члена, поделенного на размер толпы» (Пратчетт)
«миллионы не могут ошибаться» нельзя использовать в качестве аргумента против популярной точки зрения, но можно использовать в качестве аргумента против использования популярности точки зрения в качестве аргумента за нее.
«Надеюсь, Вы поняли, что я хотел сказать, потому что я этого не понял» (на самом деле, понял, и фраза несложная, просто без использования вспомогательных переменных выглядит забавно).
«Надеюсь, Вы поняли, что я хотел сказать, потому что я этого не понял» (на самом деле, понял, и фраза несложная, просто без использования вспомогательных переменных выглядит забавно).
mihaild все правильно расписал.
От себя добавлю, что да, скорее всего такие нехомячки, как Страуструп, Джеймс Гослинг, Мацумото и другие — они не ошибаются. Они пришли к выводу, что ООП не отстой, исходя из каких-то своих соображений, касаемо использования ООП. Но это не значит, что не ошибаются остальные. Для них ООП вполне может быть отстоем, порождающим оверинженеринг. Или даже фабрику фабрик прототипов, реализующих интерфейс оверинженеринга.
А разница между ними в том, что одни подумали и решили, а вторые решили не думая. Возможно даже благодаря такому тезису, как Огромное количество разработчиков.
От себя добавлю, что да, скорее всего такие нехомячки, как Страуструп, Джеймс Гослинг, Мацумото и другие — они не ошибаются. Они пришли к выводу, что ООП не отстой, исходя из каких-то своих соображений, касаемо использования ООП. Но это не значит, что не ошибаются остальные. Для них ООП вполне может быть отстоем, порождающим оверинженеринг. Или даже фабрику фабрик прототипов, реализующих интерфейс оверинженеринга.
А разница между ними в том, что одни подумали и решили, а вторые решили не думая. Возможно даже благодаря такому тезису, как Огромное количество разработчиков.
Мы приходим к тому что прежде чем использовать инструмент нужно попробовать работать без него. Только тогда ты поймешь почему с ним лучше. И только зная как это делается на низком уровне ты сможешь делать это хорошо на высоком.
Не совсем так. Попробовать работать без него вполне можно. Но лучше задать себе вопрос «почему именно этот инструмент?» и получить ответ на него.
Забить гвоздь можно камнем, молотком или пневматическим гвоздезабивателем. В зависимости от начальных условий, каждый из этих инструментов может оказаться лучшим в текущей ситуации.
Забить гвоздь можно камнем, молотком или пневматическим гвоздезабивателем. В зависимости от начальных условий, каждый из этих инструментов может оказаться лучшим в текущей ситуации.
>gleb_kudr 16 июля 2012 в 22:52
>Другое дело, что любят нагородить 100500 хелперных классов по всем правилам (каких-нибудь ОбертокШаблоновФабрикиПрототипов), а потом путаются во всей этой куче
Вы прям мои мысли читаете :)
>Другое дело, что любят нагородить 100500 хелперных классов по всем правилам (каких-нибудь ОбертокШаблоновФабрикиПрототипов), а потом путаются во всей этой куче
Вы прям мои мысли читаете :)
На вкус и цвет фломастеры разные. Пишите так, как вам удобнее. И не указывайте другим, как писать им.
Вы наверное не любите такие инструменты как парное программирование или коллективное владение кодом?
Почему же? Когда люди пишут проект совместно, они как-то договариваются, как писать и что использовать…
Когда я пишу проект, и предполагаю, что код будут смотреть другие люди — я стараюсь писать красиво (вообще всегда стараюсь, но так стараюсь больше).
Но при этом использую то, что (на мой взгляд) подходит больше всего. ООП — использую ООП, императивный стиль — использую его. Задачи разные, решения тоже.
Когда я пишу проект, и предполагаю, что код будут смотреть другие люди — я стараюсь писать красиво (вообще всегда стараюсь, но так стараюсь больше).
Но при этом использую то, что (на мой взгляд) подходит больше всего. ООП — использую ООП, императивный стиль — использую его. Задачи разные, решения тоже.
ТОЛЬКО ПРОЦЕДУРЫ — ТОЛЬКО ЧИСТЫЙ КОД!111расрас
Вот почему когда говорят о ООП, всегда упоминают в первую очередь MVC???
Да эти аббревиатуры из трёх букв уже съели всем мозг. Следующая ассоциация — PHP.
это единственный паттерн, который хоть как-то известен широким слоям.
Те кто плохо отзывается об ООП, вероятно, пишут очень очень маленькие проекты, либо имеют дело с проектами для которых скорость приложения является более значимым явлением чем сопровождение проекта.
Я бы сказал: «Если ты не читал книгу „Совершенный код“ от МакКоннела, ты не имеешь права говорить плохо о какой-либо технологии. », дядюшка Мак сформулировал все за нас и сформулировал очень точно! По крайней мере сейчас мысли в его книге чуть ли не на 90% отражают всю текущую деятельность человека в отрасли по разработке ПО
Я бы сказал: «Если ты не читал книгу „Совершенный код“ от МакКоннела, ты не имеешь права говорить плохо о какой-либо технологии. », дядюшка Мак сформулировал все за нас и сформулировал очень точно! По крайней мере сейчас мысли в его книге чуть ли не на 90% отражают всю текущую деятельность человека в отрасли по разработке ПО
ООП, ФП, MVC — это всё инструменты, каждый для своей подзадачи. Если вы строите дом, вам и молоток нужен, и пила, и рубанок. Никто не говорит, что рубанки отстой и давайте строить все дома только молотком.
Извините, что ради этой банальной мысли я написал комментарий.
Извините, что ради этой банальной мысли я написал комментарий.
Вот еле удержался от подобной реакции, хотя очень хотелось. Всё верно написано.
Проблема исходного посыла («ООП — отстой») в том, что автор не конкретизирует предметную область, он просто говорит, за какую бы задачу вы не взялись, выбор ООП будет ошибочным, и приводит спорные доводы.
ООП — это просто парадигма мышления, которая отражает стремление человеческого мозга к классификации, упорядочиванию информации и поиску закономерностей.
Я к подобным нападкам, которые периодически всплывают в сети и вызывают в частности такие реакционные статьи отношусь прохладно. У любой теории, у любого инструмента есть минусы. И любой теории и любому инструменту можно приписать свойства из серии «это микроскоп плох, потому что им неудобно забивать гвозди».
В общем, однобокость мышления проявляется даже среди выдающихся умов. К сожалению.
Проблема исходного посыла («ООП — отстой») в том, что автор не конкретизирует предметную область, он просто говорит, за какую бы задачу вы не взялись, выбор ООП будет ошибочным, и приводит спорные доводы.
ООП — это просто парадигма мышления, которая отражает стремление человеческого мозга к классификации, упорядочиванию информации и поиску закономерностей.
Я к подобным нападкам, которые периодически всплывают в сети и вызывают в частности такие реакционные статьи отношусь прохладно. У любой теории, у любого инструмента есть минусы. И любой теории и любому инструменту можно приписать свойства из серии «это микроскоп плох, потому что им неудобно забивать гвозди».
В общем, однобокость мышления проявляется даже среди выдающихся умов. К сожалению.
Пишу проект, ООП и МВЦ само по себе вытекает по нужде. Даже как то не задумываюсь об этом.
НЛО прилетело и опубликовало эту надпись здесь
Странно, что еще не все в курсе провала ООП парадигмы.
Сейчас использовать ООП, это тоже самое, что писать на Delphi. Зачем мучить труп?
Что хорошего принесло ООП? Увеличение сложности, грузовик костылей, грузовик книг по обходу этих костылей и конечно тотальную несовместимость.
Начнем с конца. Было время, когда ООП еще не существовало, трава была зеленая и одуванчики в Москве цвели. Тогда бородатые программисты писали на Си, фортране и паскале. Возможно для вас это будет шоком, но программа могла быть написана на всех трех языках сразу. А если все это сверху посыпать ассемблером то получится замечательная программа.
Теперь посмотрим на ООП языки. Ни один из них не совместим с другим. Нельзя написать программу на Java C# и C++. Разумеется грузовик костылей подвезли незамедлительно.
Проблема эффективности. ООП языки игнорируют ее. Ну и что? Ведь производительность компьютеров стремительно растет.
Тем не менее эффективность — центральная проблема программирования.
Ее нельзя просто так игнорировать. Нужно использовать возможности оборудования, а не абстрагироваться от него.
ООП не выдерживает проверку временем.
Сколько живет АПИ написанное в процедурном стиле? Да сколько угодно. Примеры повсюду. Возрасты многих Си АПИ измеряются десятками лет. И они все так-же хороши.
А что у нас с ООП АПИ? Посмотрите на Java. Совсем молодой язык. Но какой бардак в его стандартной библиотеке! Сотни классов для одной простейшей задачи. Один повторяет функционал другого.
Куча устаревших классов. Чтобы прочесть файл нужно еще 10 раз подумать как это сделать.
В сравнении с библитекой Си (пяток функций, написанных 40 лет назад.) это просто ад и позор.
И так с любым ООП АПИ. Устаревают, приходят в негодность, обрастают не пойми чем и очень слабо поддерживаются.
Современные языки уже не поддерживают эту парадигму.
Например язык Go. Нет ООП, нет мерзкого наследования.
Зато есть возможность использования оборудования(многопоточность). Нет страшного оверхеда, присущего ООП парадигме. За такими языками будущее.
Сейчас использовать ООП, это тоже самое, что писать на Delphi. Зачем мучить труп?
Что хорошего принесло ООП? Увеличение сложности, грузовик костылей, грузовик книг по обходу этих костылей и конечно тотальную несовместимость.
Начнем с конца. Было время, когда ООП еще не существовало, трава была зеленая и одуванчики в Москве цвели. Тогда бородатые программисты писали на Си, фортране и паскале. Возможно для вас это будет шоком, но программа могла быть написана на всех трех языках сразу. А если все это сверху посыпать ассемблером то получится замечательная программа.
Теперь посмотрим на ООП языки. Ни один из них не совместим с другим. Нельзя написать программу на Java C# и C++. Разумеется грузовик костылей подвезли незамедлительно.
Проблема эффективности. ООП языки игнорируют ее. Ну и что? Ведь производительность компьютеров стремительно растет.
Тем не менее эффективность — центральная проблема программирования.
Ее нельзя просто так игнорировать. Нужно использовать возможности оборудования, а не абстрагироваться от него.
ООП не выдерживает проверку временем.
Сколько живет АПИ написанное в процедурном стиле? Да сколько угодно. Примеры повсюду. Возрасты многих Си АПИ измеряются десятками лет. И они все так-же хороши.
А что у нас с ООП АПИ? Посмотрите на Java. Совсем молодой язык. Но какой бардак в его стандартной библиотеке! Сотни классов для одной простейшей задачи. Один повторяет функционал другого.
Куча устаревших классов. Чтобы прочесть файл нужно еще 10 раз подумать как это сделать.
В сравнении с библитекой Си (пяток функций, написанных 40 лет назад.) это просто ад и позор.
И так с любым ООП АПИ. Устаревают, приходят в негодность, обрастают не пойми чем и очень слабо поддерживаются.
Современные языки уже не поддерживают эту парадигму.
Например язык Go. Нет ООП, нет мерзкого наследования.
Зато есть возможность использования оборудования(многопоточность). Нет страшного оверхеда, присущего ООП парадигме. За такими языками будущее.
> Например язык Go. Нет ООП, нет мерзкого наследования.
Серьезно?
golangtutorials.blogspot.com/2011/06/summary-of-object-oriented-programming.html
golangtutorials.blogspot.com/2011/06/structs-in-go-instead-of-classes-in.html
golangtutorials.blogspot.com/2011/06/polymorphism-in-go.html
golangtutorials.blogspot.com/2011/06/interfaces-in-go.html
golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html
Серьезно?
golangtutorials.blogspot.com/2011/06/summary-of-object-oriented-programming.html
golangtutorials.blogspot.com/2011/06/structs-in-go-instead-of-classes-in.html
golangtutorials.blogspot.com/2011/06/polymorphism-in-go.html
golangtutorials.blogspot.com/2011/06/interfaces-in-go.html
golangtutorials.blogspot.com/2011/06/inheritance-and-subclassing-in-go-or.html
А что у нас с ООП АПИ? Посмотрите на Java. Совсем молодой язык. Но какой бардак в его стандартной библиотеке! Сотни классов для одной простейшей задачи. Один повторяет функционал другого.
Куча устаревших классов. Чтобы прочесть файл нужно еще 10 раз подумать как это сделать.
В сравнении с библитекой Си (пяток функций, написанных 40 лет назад.) это просто ад и позор.
Вы серьёзно? Приведите пример. Или скажите честно — не смогли понять java.io.
Сколько живет АПИ написанное в процедурном стиле? Да сколько угодно. Примеры повсюду. Возрасты многих Си АПИ измеряются десятками лет. И они все так-же хороши.
Ага, функции с 20 параметрами решают xD. Вам наверное очень нравится всякие интовые хендлы хранить, а потом думать, что за этим хендлом скрывается. У вас мозг ещё не опух?
Нет ООП, нет мерзкого наследования.
Мне вас жалко, как вы без него живёте? А если нужно в некотором месте изменить поведение?
P.S. Вы случайно не потролить зашли)?
> Вам наверное очень нравится всякие интовые хендлы хранить, а потом думать, что за этим хендлом скрывается. У вас мозг ещё не опух?
Вот вам пример как делается инкапсуляция на C с нормальными типами. git.gnome.org/browse/glib/tree/glib/gdatetime.h#n99
Никаких интовых хендлов нет вовсе. Детали реализации скрыты. В случае C++ тут бы светилась секция private со всеми потрохами, или Pimpl с его оверхедом.
Вот вам пример как делается инкапсуляция на C с нормальными типами. git.gnome.org/browse/glib/tree/glib/gdatetime.h#n99
Никаких интовых хендлов нет вовсе. Детали реализации скрыты. В случае C++ тут бы светилась секция private со всеми потрохами, или Pimpl с его оверхедом.
А можно не хедер, а имплементацию?
Ещё скажу что очень весело функции по префиксу искать — когда нужно — не найдёшь никогда.
Ещё скажу что очень весело функции по префиксу искать — когда нужно — не найдёшь никогда.
Пожалуйста git.gnome.org/browse/glib/tree/glib/gdatetime.c#n116
Искать не надо. Есть же документация :) developer.gnome.org/glib/stable/glib-GDateTime.html
Искать не надо. Есть же документация :) developer.gnome.org/glib/stable/glib-GDateTime.html
Даже смущаюсь спросить, это
и это
не кажется вам слегка похожим? Только не приходится каждый раз писать g_datetime_, оно в принципе во всех биндингах gtk+ на объектно-ориентированные языки примерно так и выглядит.
GDateTime* time = g_datetime_new();
g_datetime_add_years(time, 1);
g_datetime_add_months(time, 2);
g_datetime_add_weeks(time, 3);
g_datetime_add_days(time, 4);
и это
DateTime time = new DateTime();
time.addYears(1);
time.addMonths(2);
time.addWeeks(3);
time.addDays(4);
не кажется вам слегка похожим? Только не приходится каждый раз писать g_datetime_, оно в принципе во всех биндингах gtk+ на объектно-ориентированные языки примерно так и выглядит.
Ну так ничего удивительного. Вся реализация Glib — классическое ООП (да, на С).
Слово new и точка не делают из структуры объекта. Это всего лишь синтаксис. Я специально дал ссылку на GDateTime, а не на GObject. GDateTime классом не является.
И в чем-же тогда его отличия от класса? Даже так, в чем кардинальные отличия двух приведённых мной вариантов?
Вы спрашиваете чем структура отличается от класса? Хотя бы невозможностью наследования. А конкретная (GDateTime), например, тем, что не может участвовать в обобщённых алгоритмах с объектами. Ещё её нельзя поместить в одну коллекцию с другими объектами.
Хочу напомнить что си вообще не относится к языкам с нативной поддержкой ооп, и обобщённых алгоритмов работы с объектами в нём вообще нет, GObject — частная реализация библиотеки glib, тоже что реализация GDateTime не связан с GObject ровным счётом никакого отношения к нашему разговору не имеет.
Но таки различие в чём? g_date_time_new — аллокатор, инициализирует данные, размещает их в памяти и возвращает на них ссылку, new DateTime тоже, g_datetime_add_* — работают, принимая первым аргументом контекст выполнения, в time.add* контекст указывается до точки, принципиальная разница где?
И я таки на всякий случай отнаследую вам вашу структуру
Но таки различие в чём? g_date_time_new — аллокатор, инициализирует данные, размещает их в памяти и возвращает на них ссылку, new DateTime тоже, g_datetime_add_* — работают, принимая первым аргументом контекст выполнения, в time.add* контекст указывается до точки, принципиальная разница где?
И я таки на всякий случай отнаследую вам вашу структуру
struct GDateTimeExt {
struct GDateTime dateTime;
gboolean extended;
}
gboolean g_date_time_ext_get_extended(GDateTimeExt* datetime) {
return datetime.extended;
}
void g_date_time_ext_set_extended(GDateTimeExt* datetime, gboolean extended) {
datetime.extended = extended;
}
int main(int argc, char** argv) {
GDateTimeExt* datetime = g_date_time_ext_new();
g_date_time_add_month((GDateTime*)datetime, 1);
g_date_time_ext_set_extended(datetime, TRUE);
return 0;
}
Вот бы ещё метод переопределить какой-нибудь…
И в чем проблема?
Это уже детали реализации.
void g_date_time_ext_add_month(GDateTimeExt* datetime, int month) {
g_date_time_add_month((GDateTime*)datetime, month + 1);
}
Это уже детали реализации.
Это не override, а просто ещё одна функция. И в этом разница. Не получается наследования и полиморфизма. Это всё ещё функция, а не посылка сообщения объекту. Поэтому это структура, а не объект.
И это не детали реализации. Ваша реализация протекла в интерфейс. Да, до объекта осталось немного, добавить виртуальную таблицу (или аналог, как делает Objective C). Только тогда можно будет говорить об объектах.
И это не детали реализации. Ваша реализация протекла в интерфейс. Да, до объекта осталось немного, добавить виртуальную таблицу (или аналог, как делает Objective C). Только тогда можно будет говорить об объектах.
Там где нет нативной поддержки чего-либо — приходится довольствоваться соглашениями. В GTK например вызов gtk_window_new возвращает структуру, из которой, вычислив смещение, можно выцыганить, например, имя окна, что в принципе нарушает инкапсуляцию, однако-же есть соглашение так не делать, а пользоваться для этого функцией (методом) gtk_window_get_title. Или как в старом php или текущем яваскрипте — приватных методов и свойств нет, потому есть соглашение писать имена приватных методов с _, ничто не мешает вызывать их извне, но с точки зрения соглашения их можно вызывать только внутри объекта.
Ну и в конце концов в тот-же GTK+ работает по тому-же принципу, и если цепочка наследования выглядит как GObject > GtkWidget > GtkBin > GtkWindow — то методы виджета нужно вызывать через gtk_widget_*, а методы окна через gtk_window_* — однако-же никто не спорит что GTK+ — объектно-ориентированная библиотека.
Так что я повторюсь — это детали реализации ооп для конкретного языка/библиотеки и т.д. и т.п., где-то реализовано больше, где-то меньше, где-то так, где-то иначе.
Ну и в конце концов в тот-же GTK+ работает по тому-же принципу, и если цепочка наследования выглядит как GObject > GtkWidget > GtkBin > GtkWindow — то методы виджета нужно вызывать через gtk_widget_*, а методы окна через gtk_window_* — однако-же никто не спорит что GTK+ — объектно-ориентированная библиотека.
Так что я повторюсь — это детали реализации ооп для конкретного языка/библиотеки и т.д. и т.п., где-то реализовано больше, где-то меньше, где-то так, где-то иначе.
Одних соглашений мало. GObject для того чтобы быть объектом приходится заводить виртуальную таблицу. git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.h#n193
Для любого виджета можно вызвать метод gtk_widget_* не зная конкретного типа. Тем не менее будет вызван метод потомка. Работает полиморфизм.
В вашем же примере нельзя передать GDateTimeExt вместо GDateTime.
Для любого виджета можно вызвать метод gtk_widget_* не зная конкретного типа. Тем не менее будет вызван метод потомка. Работает полиморфизм.
В вашем же примере нельзя передать GDateTimeExt вместо GDateTime.
Для языков без поддержки ООП и интерпретируемых языков — это так, с другой стороны компилируемый строго типизованный язык с поддержкой ООП таблицу вызовов может иметь только на этапе компиляции, и в результате переопределённые методы будут вызывать методы потомка, не переопределённые — родителя, так как тип (класс) на этапе компиляции будет известен.
Так что с одной стороны вы конечно правы, а с другой, если возвращаться к теме нашей дискуссии — если сравнивать например си и ди, как два компилируемых языка, то обе записи, вокруг которых и развернулся спор, будут равнозначны, обе выделяют память, инициализируют данные и предоставляют методы для работы с оными, которые в свою очередь сводятся к передаче контекста (данных объекта/структуры) в функцию обработки оных, GDateTime реализованный в виде объекта тут ничем не проигрывает, даже наоборот — приобретает, тот-же самый полиморфизм.
Так что с одной стороны вы конечно правы, а с другой, если возвращаться к теме нашей дискуссии — если сравнивать например си и ди, как два компилируемых языка, то обе записи, вокруг которых и развернулся спор, будут равнозначны, обе выделяют память, инициализируют данные и предоставляют методы для работы с оными, которые в свою очередь сводятся к передаче контекста (данных объекта/структуры) в функцию обработки оных, GDateTime реализованный в виде объекта тут ничем не проигрывает, даже наоборот — приобретает, тот-же самый полиморфизм.
>Не получается наследования и полиморфизма.
Добавляем в структуру указатели на функции (собственно, делаем виртуальную таблицу вручную). Инициализируем их в «конструкторе», направляя на нужные функции. Итог — для «объектов», созданных разными «конструкторами», будут вызываться разные функции, причём клиентский код об этом знать не будет.
Добавляем в структуру указатели на функции (собственно, делаем виртуальную таблицу вручную). Инициализируем их в «конструкторе», направляя на нужные функции. Итог — для «объектов», созданных разными «конструкторами», будут вызываться разные функции, причём клиентский код об этом знать не будет.
Надо как-то не зная типа структуры добраться до этой таблицы. Например, условиться, что в любой структуре она идет первым полем. Но гарантируют ли компиляторы, что адрес первого поля структуры совпадает с адресом самой структуры?
А что если вообще сделать так: данные инкапсулируем через тот же pimpl (т.е. в структуре из данных один только указатель на структуру-контейнер с реальными данными), а дальше просто перечисляем «виртуальные функции» в виде полей структуры. Интерфейс «класса» же известен заранее.
В итоге наследование реализуется в структурах с данными, а виртуальные функции — в структуре-контейнере.
Правда, во всей этой затее засада в том, что в функции-«методы» нужно будет явным образом передавать указатель на сам объект, т.к. указатель «this» отсутствует. Получится что-то вроде такого:
Наследник будет выглядеть следующим образом:
И тогда в клиентском коде можно писать
И в этом случае вызовется функция print_circle.
В итоге наследование реализуется в структурах с данными, а виртуальные функции — в структуре-контейнере.
Правда, во всей этой затее засада в том, что в функции-«методы» нужно будет явным образом передавать указатель на сам объект, т.к. указатель «this» отсутствует. Получится что-то вроде такого:
// shape.h :
typedef struct _shape {
void* data;
// "methods"
void (*print)(struct _shape*);
...
} shape_t;
shape_t* new_shape();
// shape.c :
static void print_shape(shape_t* shape) {
// print shape data
};
shape_t* new_shape() {
shape_t* shape = malloc(sizeof(shape_t));
shape->data = // ... create data here ....
shape->print = &print_shape;
return shape;
}
// in the client code
shape_t* shape = new_shape();
shape->print(shape); // кривовато, да :-/
Наследник будет выглядеть следующим образом:
void print_circle() {
// print circle data
}
shape_t* new_circle() {
shape_t* circle = malloc(sizeof(shape_t*));
circle->data = // .... create data here ....
circle->print = &print_circle;
return circle;
}
И тогда в клиентском коде можно писать
shape_t* circle = new_circle();
circle->print(circle);
И в этом случае вызовется функция print_circle.
1. Ссылки должны быть в data.
2. Объект data может и должен шариться между всеми экземплярами одного типа.
3. Для методов делаются обёртки:
void shape_print(shape) { shape->data->print(shape); }
В первом приближении GObject так и построен. :)
2. Объект data может и должен шариться между всеми экземплярами одного типа.
3. Для методов делаются обёртки:
void shape_print(shape) { shape->data->print(shape); }
В первом приближении GObject так и построен. :)
Объект data шариться не может — в нем находятся индивидуальные данные экземпляров. Проблема, с моей точки зрения, в том, что таблички виртуальных функций для разных объектов совпадают гораздо чаще, чем данные — и в итоге на инициализацию тратится лишнее время.
Кстати, как быть с множественным наследованием? Или, хотя бы с реализацией многих интерфейсов и возможностью кастинга между ними? Что-то вроде
Или можно лучше?
Кстати, как быть с множественным наследованием? Или, хотя бы с реализацией многих интерфейсов и возможностью кастинга между ними? Что-то вроде
typedef _CastedObject struct{
void *casted_data; // ссылка на данные базового класса (внутрь структуры data)
void *casted_functions; // ссылка на реализацию текущего интерфейса (внутрь virt_functions)
void *data; // данные всего объекта
void *virt_functions; // сводная таблица виртуальных функций
} CastedObject;
Или можно лучше?
>1. Ссылки должны быть в data.
Нет, их лучше всё же разнести, хотя бы из соображений того, что виртуальная таблица и набор данных могут расти независимо друг от друга, а наращивать структуру "наследованием" можно только добавляя поля в конец. И плюс таким образом мы сможем шарить структуру со ссылками между всеми экземплярами, оставляя данные уникальными для каждого. В общем, нужно делать не так, как я предложил выше, а ровно наоборот: методы в отдельной структуре, а данные — прямо тут :)
Что-то вроде такого:
В итоге получаем и наследование, и полиморфизм.
Сейчас набросал примерчик, в котором следующий код
Выводит
Нет, их лучше всё же разнести, хотя бы из соображений того, что виртуальная таблица и набор данных могут расти независимо друг от друга, а наращивать структуру "наследованием" можно только добавляя поля в конец. И плюс таким образом мы сможем шарить структуру со ссылками между всеми экземплярами, оставляя данные уникальными для каждого. В общем, нужно делать не так, как я предложил выше, а ровно наоборот: методы в отдельной структуре, а данные — прямо тут :)
Что-то вроде такого:
typedef struct _shape_methods {
void (*print)(struct _shape_t* shape);
} shape_methods_t;
typedef struct _shape_t {
shape_methods_t* methods;
int x;
int y;
} shape_t;
В итоге получаем и наследование, и полиморфизм.
Сейчас набросал примерчик, в котором следующий код
shape_t* shape = new_shape( 5, 5 );
shape_t* circle = new_circle( 10, 10, 20 );
print_shape(shape);
print_shape(circle);
Выводит
Shape { x: 5, y: 5 }
Circle { x: 10, y: 10, r: 20 }
Сейчас я выкручусь. :) Я говорил только о ссылках (на методы). Про данные речь не шла.
Всё правильно, их надо разносить. А вот данные тоже можно по-разному представлять: хоть в саму структуру засунуть, хоть pimpl.
Осталось только переименовать shape_methods_t в shape_class, и сделать
typedef struct {
shape_class parent;
} circle_class;
Всё правильно, их надо разносить. А вот данные тоже можно по-разному представлять: хоть в саму структуру засунуть, хоть pimpl.
Осталось только переименовать shape_methods_t в shape_class, и сделать
typedef struct {
shape_class parent;
} circle_class;
С другой стороны, если «виртуальных функций» немного, и особенно, если они могут меняться во время жизни структуры, то положить их в отдельные поля и потом вызывать оттуда — самое милое дело. Вот только какое отношение это имеет к ООП?
>Вот только какое отношение это имеет к ООП?
Ну, формально у нас есть «объекты» (структуры данных с определёнными операции над ними), налицо абстракция, наследование и полиморфизм. С инкапсуляцией сложнее — максимум, что мы тут можем сделать, это спрятать данные в pimpl, структура которого наружу не светится. Понятно, что технически это не преграда, но чисто технически в C++ тоже можно до приватных данных достучаться.
В итоге — практически классическое ООП, вид сбоку.
Ну, формально у нас есть «объекты» (структуры данных с определёнными операции над ними), налицо абстракция, наследование и полиморфизм. С инкапсуляцией сложнее — максимум, что мы тут можем сделать, это спрятать данные в pimpl, структура которого наружу не светится. Понятно, что технически это не преграда, но чисто технически в C++ тоже можно до приватных данных достучаться.
В итоге — практически классическое ООП, вид сбоку.
Это наверно потому что GTK+ с Glib'ом вместе — объектно-ориентированные? :)
ООП — парадигма, а не набор операторов языка, и там где есть данные, сгруппированные в единую сущность (в GTK они представлены в виде структур), и методы работы с ними — там присутствует и оно, и все его особенности, и все его плюсы и минусы.
Но если по порядку — для описания сколько-либо комплексного объекта одной скалярной переменной недостаточно — нужно несколько, хранить их в массиве — неудобно, да и типы у них могут быть разные, соот-но нужна структура, чтобы не было overhead'а при передаче этой структуры внутри кода — её необходимо передавать по ссылке, обрабатывать данные структуры на месте — несерьёзно, нужны функции обработки, передавать каждую порцию данных отдельно — глупо, функции может понадобится ещё одна и придётся менять сигнатуру, поэтому передается ссылка на всю структуру целиком — и вот у нас уже и поля данные, сгруппированные в объект, передающийся по ссылке, с собственными методами.
А ещё бывает что структура нужна точно такая-же как старая — только с ещё парой полей — и вот у нас уже наследование, а то что новую структуру с доп. полем можно кастануть в старую и обрабатывать функциями старой, а новых может быть несколько — это полиморфизм. Вот как-то вот так появилось объектно-ориентированное программирование.
А на случай если и против процедурного программирования есть претензии — то там тоже все просто, каждый раз один и тот-же кусок кода писать долго и не прикольно, а ещё программы от этого сильно разрастаются — потому вумные дядьки из outer world придумали выносить их в процедуры, в старых бейсиках например использовали goto туда — goto обратно за неимением других вариантов, а уж в си, паскале и их наследниках они из коробки есть.
Вот так вот по аналогии с процедурным программированием на головы ничего не подозревающих программистов настал ООП, и если в каком-то языке, как в старых бейсках без процедур, его поддержки нет — это ещё не значит что его там нет.
ООП — парадигма, а не набор операторов языка, и там где есть данные, сгруппированные в единую сущность (в GTK они представлены в виде структур), и методы работы с ними — там присутствует и оно, и все его особенности, и все его плюсы и минусы.
Но если по порядку — для описания сколько-либо комплексного объекта одной скалярной переменной недостаточно — нужно несколько, хранить их в массиве — неудобно, да и типы у них могут быть разные, соот-но нужна структура, чтобы не было overhead'а при передаче этой структуры внутри кода — её необходимо передавать по ссылке, обрабатывать данные структуры на месте — несерьёзно, нужны функции обработки, передавать каждую порцию данных отдельно — глупо, функции может понадобится ещё одна и придётся менять сигнатуру, поэтому передается ссылка на всю структуру целиком — и вот у нас уже и поля данные, сгруппированные в объект, передающийся по ссылке, с собственными методами.
А ещё бывает что структура нужна точно такая-же как старая — только с ещё парой полей — и вот у нас уже наследование, а то что новую структуру с доп. полем можно кастануть в старую и обрабатывать функциями старой, а новых может быть несколько — это полиморфизм. Вот как-то вот так появилось объектно-ориентированное программирование.
А на случай если и против процедурного программирования есть претензии — то там тоже все просто, каждый раз один и тот-же кусок кода писать долго и не прикольно, а ещё программы от этого сильно разрастаются — потому вумные дядьки из outer world придумали выносить их в процедуры, в старых бейсиках например использовали goto туда — goto обратно за неимением других вариантов, а уж в си, паскале и их наследниках они из коробки есть.
Вот так вот по аналогии с процедурным программированием на головы ничего не подозревающих программистов настал ООП, и если в каком-то языке, как в старых бейсках без процедур, его поддержки нет — это ещё не значит что его там нет.
>В случае C++ тут бы светилась секция private со всеми потрохами, или Pimpl с его оверхедом.
А не интерфейс (a.k.a. «абстрактный класс»), не?
А не интерфейс (a.k.a. «абстрактный класс»), не?
>Теперь посмотрим на ООП языки. Ни один из них не совместим с другим. Нельзя написать программу на Java C# и C++
Т.е. вы не отличаете парадигму от конкретной реализации конкретного языка? Шикарно!
Кстати, рекомендую ознакомиться с платформой .NET
>Сколько живет АПИ написанное в процедурном стиле? Да сколько угодно. Примеры повсюду. Возрасты многих Си АПИ измеряются десятками лет. И они все так-же хороши.
А тут вы не различаете парадигму и конкретную реализацию конкретного АПИ.
Кстати, рекомендую ознакомиться с Linux kernel API.
>Например язык Go. Нет ООП, нет мерзкого наследования.
Ну а тут просто рекомендую ознакомиться с сабжем, о котором вы имеете неосторожность говорить, не имея о нём ни малейшего представления (ссылки даны выше).
Т.е. вы не отличаете парадигму от конкретной реализации конкретного языка? Шикарно!
Кстати, рекомендую ознакомиться с платформой .NET
>Сколько живет АПИ написанное в процедурном стиле? Да сколько угодно. Примеры повсюду. Возрасты многих Си АПИ измеряются десятками лет. И они все так-же хороши.
А тут вы не различаете парадигму и конкретную реализацию конкретного АПИ.
Кстати, рекомендую ознакомиться с Linux kernel API.
>Например язык Go. Нет ООП, нет мерзкого наследования.
Ну а тут просто рекомендую ознакомиться с сабжем, о котором вы имеете неосторожность говорить, не имея о нём ни малейшего представления (ссылки даны выше).
Эта статься наверное ответ на эту habrahabr.ru/post/147890/?
… поскольку человеческий мозг вообще не приспособлен для оперирования абстракциями
Есть мнение, что именно эта способность человеческого мозга позволила нам перестать жрать бананы на деревьях, а развиться до компьютеров и айфонов.
Есть мнение, что теори Дарвина неверна.
Я думаю стоит определить что для каждого из вас является абстракцией.
Мнений есть куча, но давайте не будем уподобляться РПЦ, а думать своей головой и рассматривать факты?
Мнений есть куча, но давайте не будем уподобляться РПЦ, а думать своей головой и рассматривать факты?
ага, — Использование UML для эксперимента по эволюционной систематике прокариот, и косвенно о психологии ученых, скоро будут новые результаты…
Мысль, повторённая трижды становится мудростью.
Мысль, повторённая трижды становится мудростью.
Мысль, повторённая трижды становится мудростью.
/Годзилла Занудный/
Мысль, повторённая трижды становится мудростью.
Мысль, повторённая трижды становится мудростью.
/Годзилла Занудный/
Даешь неделю ООП-холиваров на Хабре! Налетаем, переводим!
Видите ли, когда я написал на хабре статью «Существуют только структурная и объектная парадигмы программирования», с полноценными пояснениями — люди быстро минусовали, думаю даже не сильно вчитываясь. Вы же лишь сделали реверансы во все стороны и сорвали плюсы, но не одного аргумента. Вот как это понимать? Текущий тренд? Ну тогда я предлагаю просто иногда думать, что есть что… а не следовать поп-культуре. Не могут другие якобы парадигмы (та же функциональная) называться парадигмами — т.к. ну нет там ни каких идей столь значимых для кодирования. Отдельные способы/методы — да. Но парадигмой в полном смысле можно называть только ООП.
А на уровне отстой/не отстой — даже обсуждать не интересно.
А на уровне отстой/не отстой — даже обсуждать не интересно.
Фраза автора о том, что мозг не может оперировать абстракциями, повергла меня в ..., в общем повергла. Неужели, когда он подходит к двери, он оперирует не абстракцией, а молекулами дерева и прочего. А переходя дорогу, видит в автомобилях, прежде всего, не предмет, который может сбить его, а сложный механизм состоящий из n деталей. Все мы в основе своей оперируем абстракциями, просто потому, что это на много проще в восприятии. Я бы рекомендовал начать читать Code Complete.
А мне казалось что ООП предполагает более высокий уровень абстракции чем прочие типы ЯП. Чем сложнее структура проекта, чем больше различных зависимостей у внутренних элементов, и чем больше необходимости отойти в некую «виртуальную модель» — тем больше ООП подходит для данной задачи
Главный минус ООП — то что многие считают подход единственно правильным, и другие варианты просто не воспринимают.
А в остальном, обычный tradeoff как и в любой ИТ технологии.
btw реализация ООП в мейнстрим языках вообще отдельная песня.
А в остальном, обычный tradeoff как и в любой ИТ технологии.
btw реализация ООП в мейнстрим языках вообще отдельная песня.
Почему ООП не отстой