LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от anonymous

>Нет, не получается.. Смотрите: на стеке лежит указатель на объект

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

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

Только вагон костылей спасет отца русской демократии..


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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

Потом если вдруг кто-то сделает swap весь текущий контекст пойдет по женской линии..

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

при аккуратной работе (а другая для Форта неприменима и при обычном программировании) простреливается именно та нога, какая нужна.

А при аккуратной работе и словари не нужны, хватает и глобального контекста. WinAPI тому пример.

anonymous ()
Ответ на: комментарий от anonymous

>Потом если вдруг кто-то сделает swap весь текущий контекст пойдет по женской линии..

Если кто-то сделает неожиданный SWAP, то вся программа пойдёт по женской линии независимо от контекста :D

А при аккуратной работе и словари не нужны, хватает и глобального контекста


«Аккуратная работа» и «удобная работа» - две не совпадающие области.

Использование словарей в «ООП-стиле» (когда слова переключают контекстный словарь так, чтобы подменялись используемые слова) - это достаточно распространённая практика на Форте.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>Если кто-то сделает неожиданный SWAP, то вся программа пойдёт по женской линии независимо от контекста :D

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

«Аккуратная работа» и «удобная работа» - две не совпадающие области.

ООП и Форт - тоже.

Использование словарей в «ООП-стиле» (когда слова переключают контекстный словарь так, чтобы подменялись используемые слова) - это достаточно распространённая практика на Форте.

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

Даже для MASMа реализация подобного «ООП» потребует меньше усилий. Ассемблер - ООП язык?

anonymous ()
Ответ на: комментарий от anonymous

>Налицо непонимание того, что работа с объектами в стеке требует поддержки переключения контекста

Налицо также непонимание того, что на Форте всегда полезно следить за переключением контекстов.

ООП и Форт - тоже.


ООП - это не только стиль Си++

Даже такая калечная имитация ООП нифига не распространена на форте


У Вас большая практика программирования на Форте? Сколько лет и в какой области? Вы общались с большим количеством Форт-программистов старой школы или делаете выводы по своей практике?

Даже для MASMа реализация подобного «ООП» потребует меньше усилий


Это даже не сравнение тёплого с мягким, а зелёного с падающим.

Ассемблер - ООП язык?


Безусловно, нет.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>У Вас большая практика программирования на Форте?

Хватает, еще с конца 80х. Насмотрелся всякого..

ООП - это не только стиль Си++

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

Ассемблер - ООП язык?

Безусловно, нет.

Нате, просвещайтесь http://objasm32.tripod.com/ Можете сравнить с жалкими попытками 25 лет вкорячить ООП в форт.

anonymous ()
Ответ на: комментарий от KRoN73

>Налицо также непонимание того, что на Форте всегда полезно следить за переключением контекстов.

Типа так?(на стеке 2 объекта - точка и круг):

set_point_ctx get_x swap set_circle_ctx set_x set_default_ctx

Чем это лучше глобального контекста?

point_get_x swap circle_set_x

Если контекст в голове, зачем ненужные дерги неймспейсом? Весь смысл ООП в автоматизации контекста. Когда мы пишем shape1.get_x, мы не задумываемся, какой именно кусок кода достанет координату Х фигуры. Что освобождает моск для более нужных вещей.

Но это не для форта.

anonymous ()
Ответ на: комментарий от anonymous

> Смотрите: на стеке лежит указатель на объект, нам нужно получить доступ его атрибуту(методу). Каким волшебным образом должен переключиться словарный контекст?

Здесь объекты не куски чего-то с автоматически срабатывающей кнопкой «Пуск» при рождении. Здесь объекты - как комнаты, с вещами, мебелью, и заклинанием портала (CONTEXT) в другую комнату по её имени. Через портал (CONTEXT) можно использовать любые вещи и мебель в той комнате не выходя их этой, а можно и перелезть (CURRENT) туда. В любой момент можно открыть портал (CONTEXT) в любую другую существующую комнату или создать новую с перемещением в неё, при этом в новой комнате создаётся портал в предыдущую. В последних стандартах языка Forth имеются средства манипулирования последовательностями цепочек комнат (наследование контекстов).

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

Есть Базовый Словарь (FORTH). Текущая область размещения новых слов (FORTH). В контексте (FORTH) определяем словарь (A). Устанавливаем текущей областью размещения новых слов (A). В контексте (A) определяем словарь (B). Устанавливаем текущей областью размещения новых слов (B). В контексте (B) определяем (C). Устанавливаем текущей областью размещения новых слов (C). /Мы получили цепочку наследования: FORTH - A - B - C/

Переключаем контекст на (FORTH). Устанавливаем текущей областью размещения новых слов (FORTH). В контексте (FORTH) определяем словарь (D). Устанавливаем текущей областью размещения новых слов (D). В контексте (D) определяем словарь (E). Устанавливаем текущей областью размещения новых слов (E). В контексте (E) определяем словарь (F). Устанавливаем текущей областью размещения новых слов (F). /Мы получили цепочку наследования: FORTH - D - E - F/

Переключаем контекст на (E). Устанавливаем текущей областью размещения новых слов (E). В контексте (E) определяем словарь (G). Устанавливаем текущей областью размещения новых слов (G). /Мы получили цепочку наследования: FORTH - D - E - G/

В контексте (G) определяем словарь (H). Устанавливаем текущей областью размещения новых слов (H). /Мы получили цепочку наследования: FORTH - D - E - G - H/ Добавляем слова - процедуры, данные.

Переключаем контекст на (B). /Мы получили цепочку наследования: FORTH - A - B - H/ Добавляем слова - процедуры, данные.

Переключаем контекст на (D). /Мы получили цепочку наследования: FORTH - D - H/ Добавляем слова - процедуры, данные.

/Поиск осуществляется от конца цепочки словаря (G) по направлению к базовому словарю (FORTH)/

Таким образом, для словаря/класса (G) мы получаем три разных цепочки контекстов в разные моменты времени формирования (G).

Только вагон костылей спасет отца русской демократии..

Можно грубо считать, что CLASS == VOCABULARY с красивым механизмом реализации множественного наследования, и никаких костылей.

anonymous ()
Ответ на: комментарий от anonymous

> Налицо непонимание того, что работа с объектами в стеке требует поддержки переключения контекста, вне зависимости от того, каким костылем (словарем, либо поддержкой в compile time) этот контекст реализован.

Все словари Forth - однонаправленные списки от последнего определённого слова к первому в пределах одного словаря. Эти словари связаны в систему ссылками первых элементов последующих списков на последние элементы предыдущих. Как ленточки, привязанные к другим ленточкам и, в конечном итоге, к одной - (FORTH).

Сама возможность создания объекта-словаря зависит от контекста и как тот реализован.

«Аккуратная работа» и «удобная работа» - две не совпадающие области.

ООП и Форт - тоже.

Или слишком опрометчиво или вы так ничего и не поняли :)

Использование словарей в «ООП-стиле» (когда слова переключают контекстный словарь так, чтобы подменялись используемые слова) - это достаточно распространённая практика на Форте.

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

Во-первых, не калечная. Во-вторых, размеры этого геморроя не больше геморроя с классами. А в третьих - вы разве никогда не слышали про словари Forth`а FORTH, EDITOR, ASSEMBLER?

anonymous ()
Ответ на: комментарий от anonymous

>>У Вас большая практика программирования на Форте?

Хватает, еще с конца 80х. Насмотрелся всякого..

Мать честная! И до сих пор ни...? Можно я вас сфотографирую? :)

ООП - это не только стиль Си++

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

Тут есть такое мнение, что Forth многолик.

Нате, просвещайтесь http://objasm32.tripod.com/ Можете сравнить с жалкими попытками 25 лет вкорячить ООП в форт.

А вот это уже изврат. И не оправдывайтесь! :)

anonymous ()
Ответ на: комментарий от anonymous

Налицо также непонимание того, что на Форте всегда полезно следить за переключением контекстов.

Типа так?(на стеке 2 объекта - точка и круг):

set_point_ctx get_x swap set_circle_ctx set_x set_default_ctx

Чем это лучше глобального контекста?

point_get_x swap circle_set_x

Где тут контексты или какой-нибудь намёк на ООП?

А вы, случаем, не путаете элементы DSL и концепцию ООП? O_o

Это, скорее, неправильно понятый пример из Лео Броуди «Способ мышления - Форт»:


	VARIABLE ЯБЛОКИ
	20 ЯБЛОКИ !
	ЯБЛОКИ ? 20 ok
	1 ЯБЛОКИ +!

Предположим, мы написали множество кода, использующего переменную ЯБЛОКИ. 
И теперь, в одиннадцатом часу, обнаруживаем, что необходимо отслеживать два 
различных типа яблок - красных и зеленых!
    Не стоит опускать руки, лучше вспомнить функцию слова ЯБЛОКИ: давать адрес. 
Если нам нужно два различных количества, ЯБЛОКИ могут давать два различных адреса, 
в зависимости от того, о каком типе яблок мы говорим. Так мы можем определить
более сложную версию слова ЯБЛОКИ, как показано ниже:

    VARIABLE ЦВЕТ  ( указатель на текущую переменную)
    VARIABLE КРАСНЫЕ  ( количество красных яблок)
    VARIABLE ЗЕЛЕНЫЕ  ( количество зеленых яблок)
    : КРАСНЫЙ ( тип яблок - красные)  КРАСНЫЕ ЦВЕТ ! ;
    : ЗЕЛЕНЫЙ ( тип яблок - зеленые)  ЗЕЛЕНЫЕ ЦВЕТ ! ;
    : ЯБЛОКИ  ( -- адр текущей яблочной переменной)  ЦВЕТ @ ;


    Рис.1-10. Смена косвенного указателя.

                          +------+
                          | ЦВЕТ |
                          +------+
   КРАСНЫЙ                    |
   ~~~~~~~    +---------+     |      +---------+
              | КРАСНЫЕ	|<-----      | ЗЕЛЕНЫЕ |
              +---------+            +---------+

     ---------------------------------------

                          +------+
                          | ЦВЕТ |
                          +------+
   ЗЕЛЕНЫЙ                    |
   ~~~~~~~    +---------+     |      +---------+
              | КРАСНЫЕ	|     ------>| ЗЕЛЕНЫЕ |
              +---------+            +---------+

anonymous ()
Ответ на: комментарий от anonymous

>Хватает, еще с конца 80х. Насмотрелся всякого..

Так «насмотрелся» или «напрограммировался»?

ООП - это не стиль, это парадигма, набор базовых понятий для построения программы.


Угу. Только трактовок этой парадигмы явно больше одной.

Безусловно, нет.

Нате, просвещайтесь http://objasm32.tripod.com/


И что?

KRoN73 ★★★★★ ()
Ответ на: комментарий от anonymous

set_point_ctx

И _с этим_ Вы начинаете говорить о Форте?? :D

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

Для удобства.

Весь смысл ООП в автоматизации контекста.

VOCABULARY POINTS DEFINITIONS
: x ( p -- x ) @ ;
: y ( p -- y ) CELL+ @ ;
: draw ( p -- ) DUP x SWAP y SOME-CODE-TO-DRAW-POINT ;

VOCABULARY CIRCLES DEFINITIONS
: x ( p -- x ) @ ;
: y ( p -- y ) CELL+ @ ;
: radius ( p -- radius ) CELL+ CELL+ @ ;
: draw ( p -- ) DUP x OVER y ROT radius SOME-CODE-TO-DRAW-CIRCLE ;

: POINT  ( x y -- p ) CREATE , , DOES> POINTS ;
: CIRCLE  ( x y radius -- p ) CREATE , , , DOES> CIRCLES ;

10 20 POINT p
30 50 30 CIRCLE c
p draw \ тут рисуется точка
c draw \ тут рисуется окружность

Где-то так, хотя за прошедшие лет 15 без практики многое из памяти вылетело. Работает, понятно, только в режиме интерпретации, в режиме компиляции нужно уже м IMMEDIATE работать.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>

p draw \ тут рисуется точка
c draw \ тут рисуется окружность

Замечательно, а теперь рассмотрим процидурку, которая получает point и устанавливает его как центр circle

 p c set_centre 
начнем так
: set_centre ( circle point -- ) swap \ на вершине point, надо получить его координаты 
и тут оппа, а контекст-то установлен для circle. Мы кажется приплыли - нам надо ручками менять контекст..

>Где тут контексты или какой-нибудь намёк на ООП?

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

>Можно грубо считать, что CLASS == VOCABULARY с красивым механизмом реализации множественного наследования, и никаких костылей.

Нет, можно грубо считать, что VOCABULARY == NameSpace, со своими прибамбасами. Для реализации объектной модели этого недостаточно.

>А вот это уже изврат. И не оправдывайтесь! :)

В чем проблема? В том, что язык низкоуровневый? Или что система объектов реализована в виде (фактически) препроцессора? Дык и с++ поначалу тоже был в виде препроцессора над не шибко высокоуровневым си.

anonymous ()

Ну чо? Переписать сложно что ли? «Не ссы, я сто раз так делал!» (с)

Andaril ()
Ответ на: комментарий от anonymous

>Замечательно, а теперь рассмотрим процидурку, которая получает point >и устанавливает его как центр circle

p c set_centre


Ну что за set_centre?? Вы Форт хоть раз в глаза видели? Первое, чему там учат - это соглашениям по нотации имён.

p c circle!

начнем так

: set_centre ( circle point — ) swap \ на вершине point, надо получить его координаты


и тут оппа, а контекст-то установлен для circle



Не оппа, а Форт. Мы знаем, что у нас SWAP не приводит к переключению контекстов.

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


Угу. То есть CONTEXT :)

Нет, можно грубо считать, что VOCABULARY == NameSpace, со своими прибамбасами.


Угу. ООП - это тоже NameSpace со своими прибамбасами.

В чем проблема? В том, что язык низкоуровневый?


Нет. В том, что в ассемблере нет ни типов, ни метапрограммирования для их имитации. А «в ООП-стиле» я на tasm ещё лет 17 назад писал. Только человек не знакомый с Фортом (или ассемблером) может сравнивать их с этой точки зрения.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

>Ну что за set_centre??

set_centre - это не только circle! (про такую мелочь, как радиус, так и быть, умолчим) это еще и возможность массы доп.действий, типа перерисовки, переупорядочивания etc..

Мы знаем, что у нас SWAP не приводит к переключению контекстов.

Вот тут та и опа. Нужно установить правильный context ручками.

Угу. То есть CONTEXT :)

Нет.. Вы разницу между возможным и допустимым понимаете? То что сделать возможно - это CONTEXT, а вот допустимо ли оно - зависит от контекста..

Угу. ООП - это тоже NameSpace со своими прибамбасами.

Мда.. И эти люди рассуждают об ООП..

В том, что в ассемблере нет ни типов,

Дык и в форте с ними не очень..

ни метапрограммирования для их имитации

а вот тут не надо ля-ля.. В MASMе как раз все нормально с метапрограммированием. Для него там просто отдельный макроязык. Согласен, с непривычки это выглядит дико, но, тем не менее, работает..

anonymous ()
Ответ на: комментарий от anonymous

>set_centre - это не только circle!

center! («centre» - это на каком?)

возможность массы доп.действий


Я тебе про Форт-нотацию, а ты даже не понимаешь о чём речь идёт.

Мда.. И эти люди рассуждают об ООП..


По сравнению с другими людьми, «рассуждающими» о Форте...

Дык и в форте с ними не очень..


Ага. Опять-снова.

а вот тут не надо ля-ля.. В MASMе как раз все нормально с метапрограммированием


Ладно, семеро мудрецов не переспорят одного... имеющего своё мнение...

KRoN73 ★★★★★ ()

Форт не нужен (кто-то ведь должен был это сказать).

P.S. в ассемблере есть типы - машинные слова и байты.

tailgunner ★★★★★ ()
Ответ на: комментарий от addewyd

> centre — английский, юноша. В отличие от «center» из американского недоязыка.

красиво умыл.

Rastafarra ★★★★ ()
Ответ на: комментарий от anonymous

> и тут оппа, а контекст-то установлен для circle. Мы кажется приплыли - нам надо ручками менять контекст..

Гы, какая забавная игра!

А что мешает в CIRCLE в разделе DOES> прописать не только возврат адреса структуры, но и переключение контекста на CIRCLES в вызове порождённого c? А в злободневном POINT прописать в DOES> не только возврат адреса структуры, но и предписание установить порождённому p контекст на словарь POINTS?

[code]
p x
p y
c set_centre ...
[/code]

Это же очевидно! :)

Нет, можно грубо считать, что VOCABULARY == NameSpace, со своими прибамбасами. Для реализации объектной модели этого недостаточно.


Вы недооцениваете силу VOCABULARY... А их систему наследования походу, вообще, не понимаете.

P.S. С 80-х пользовались Forth? Что-то мне как-то слабо верится... Как можно не видеть очевидное?

anonymous ()
Ответ на: комментарий от KRoN73

Вообще, чтоб не было соблазнов, я бы предложил:

[code] VOCABULARY GRAPH DEFINITIONS

VOCABULARY POINTS DEFINITIONS

...

GRAPH DEFINITIONS

VOCABULARY CIRCLES DEFINITIONS

...

GRAPH DEFINITIONS

... [/code]

anonymous ()
Ответ на: комментарий от anonymous
 VOCABULARY GRAPH DEFINITIONS

VOCABULARY POINTS DEFINITIONS

...

GRAPH DEFINITIONS

VOCABULARY CIRCLES DEFINITIONS

...

GRAPH DEFINITIONS

... 
anonymous ()
Ответ на: комментарий от tailgunner

> Форт не нужен (кто-то ведь должен был это сказать).

Неужели ты? Что ты знаешь о Forth?

P.S. в ассемблере есть типы - машинные слова и байты.

«машинные слова» в ассемблере? Что ты понимаешь под «машинными словами»?

anonymous ()
Ответ на: комментарий от anonymous

>> Форт не нужен (кто-то ведь должен был это сказать).

Неужели ты?

Видимо, да.

Что ты знаешь о Forth?

Что это низкоуровневая никому не нужная хрень (конечно, как и у всякой ненужной хрени, у нее есть фанаты).

«машинные слова» в ассемблере?

Да.

Что ты понимаешь под «машинными словами»?

Участок памяти размером с регистр.

tailgunner ★★★★★ ()
Ответ на: комментарий от addewyd

> А зачем форт?

Для души. Это самый красивый язык программирования, хоть и самый требовательный к программисту, наверное. :)

anonymous ()
Ответ на: комментарий от tailgunner

> Что это низкоуровневая никому не нужная хрень (конечно, как и у всякой ненужной хрени, у нее есть фанаты).

:)

anonymous ()
Ответ на: комментарий от anonymous

> и тут оппа, а контекст-то установлен для circle. Мы кажется приплыли - нам надо ручками менять контекст..

К тому же, если мы не хотим напрямую оперировать x и y, и если мы полагаем, что set_centre будет поставляться адрес структуры POINT, то не вижу ничего плохого, чтоб set_center умел переключаться на POINTS для доступа к нужным ему данным и обратно на CIRCLES, потому, как могут существовать ещё и LINE, и POLYLINE, которые можно заставить возвращать какой-нибудь POINT. В чём проблема сказать POINTS?

anonymous ()
Ответ на: комментарий от anonymous

> Для души. Это самый красивый язык программирования, хоть и самый требовательный к программисту, наверное. :)

Да ладно... Скучный он.

addewyd ()
Ответ на: комментарий от addewyd

> Да ладно... Скучный он.

Ни чуть.

Изначально Forth задумывался, как бестиповый язык. А есть подозрение, что товарищ ананим намекает на автоматическое распознавание типов подсовываемых данных своей set_center. Попробуй реализовать систему типов в Forth (это не так уж сложно: не сложнее извлечь два числа из структуры и сравнить, больше возни с декларацией всех операций над типами) и ты постигнешь дзен... :)

anonymous ()
Ответ на: комментарий от anonymous

Собственно, почему мне интересно спорить с анонимом? В своём споре он неуклонно движется к единственному правильному выводу:

ООП, в своих современных реализациях, давно уже не три кита: инкапсуляция, полиморфизм и наследование. Все о них почти забыли. ООП превратился в манипулирование типами. Это его и убивает.

P.S. А как раз Forth и позволяет вспомнить, что такое «настоящий ООП», хоть Forth и ровесник C и Pascal, и появился задолго до появления на свет модного бренда ООП, и не самый беспечный язык программирования. :)

anonymous ()
Ответ на: комментарий от anonymous

>давно уже не три кита

Ага. Сколько же Бучем ушибленных... ООП никогда и не являлся этими тремя китами. Он вообще возник из системы модулей... А во всяких С++, еше и с жуткими ограничениями типа отсутствия вложенности.

И чего менстрим реализации не пошли по пути абстрактных типов? ML, конечно, пошел, СLOS в какой-то мере. Да где они? Ведь сколько нервов было бы сэкономлено... Эх...

Macil ★★★★★ ()
Ответ на: комментарий от Macil

> Сколько же Бучем ушибленных...

И один Macil знает правду.

ООП никогда и не являлся этими тремя китами. Он вообще возник из системы модулей...

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

tailgunner ★★★★★ ()
Ответ на: комментарий от anonymous

>Попробуй реализовать систему типов в Forth

Я там выше кидал свой древний вариант ООП-расширения к SP-Forth. Динамическая типизация туда прикручивается в десяток-другой строк.

KRoN73 ★★★★★ ()
Ответ на: комментарий от Macil

<предыдущее комментировать не буду, по причине... кхм... не буду :)>

И чего менстрим реализации не пошли по пути абстрактных типов? ML, конечно, пошел, СLOS в какой-то мере. Да где они?

Проблема, как мне кажется, в том, что реализация, например множественной диспетчеризации, напрямую вторгается в область реализации контекстно-зависимых языков. Собственно, насколько помню, проблемы начались ещё во времена начала реализации перегрузки процедур и функций (кто-нибудь ещё помнит, как резко оборвался бум использования перегрузок в чистом виде и как его направили в мирное русло маниакальной типизации? :). Хоть тогда проблема контекстов и маячила в полный рост только на горизонте и в техническом плане всё выглядело вполне пристойно и реализуемо (получить сигнатуру вызова и по ней подставить подходящий вектор - несложно), что получится в итоге предсказать оказалось сложно, особенно в runtime. Современные проблемы реализации виртуальных методов (проблемы таблиц виртуальных методов при множественном наследовании) - лишь слабый отголосок проблем реализации полиморфизма, по сравнению с тем, чем грозила перегрузка процедур и функций без драконовской типизации всего и вся. Проблемы множественной диспетчеризации - это уже соизмеримые проблемы (runtime, как-никак, а в runtime, как известно, может случиться всякое :), хоть на этот раз и в рамках, вроде бы как, строгой типизации. :) А реализация контекстно-зависимых языков ( http://ru.wikipedia.org/wiki/Иерархия_Хомского ), если обратиться к учебной литературе, не так уж и проста. Строгая система типов появилась не просто так. И любые попытки перешагнуть её границы чреваты непредсказуемостью результата.

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

Ведь сколько нервов было бы сэкономлено... Эх...

Это смотря чьи нервы иметь ввиду... :)

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

anonymous ()
Ответ на: комментарий от KRoN73

> Я там выше кидал свой древний вариант ООП-расширения к SP-Forth. Динамическая типизация туда прикручивается в десяток-другой строк.

С наследованием? :)

Боюсь для {String[MaxStringSize], String[1000], String[100], String[10], String[1]} (т.е. различной длины, например), проблема присваивания и сравнения в десяток-другой строк не решится. :)

А ещё у нас могут быть, к примеру, LIST of STRING[различной длины] и GRAPH of AnyTypeAddr, со своими структурами и своими типами, соответственно. Обычно ими нужно как-то манипулировать и сравнивать с родственными или, в идеале, похожими структурами. (Предположим, у имеется пара списков и мы желаем сравнить их как множества или получили пару семантических сетей текстов и желаем сравнить их на предмет похожести /сравнить сюжеты текстов/, без учёта синонимов хотя бы. А что, вполне себе нормальная проблема для типизации :)

P.S. Кстати, я не вижу реализации сравнения для строк и списков. Это же не случайно? Возможно, на подсознательном уровне проблема типов таки маячила? :)

anonymous ()
Ответ на: комментарий от KRoN73

> Ладно, семеро мудрецов не переспорят одного... имеющего своё мнение...

вот как на форте решить такую простую задачку:

у нас на стэке могут лежать числа со знаком и без знака (все величиной в слово), при этом все операции < > + - должны работать с парой любых чисел, в том числе с парой беззнаковое-и-знаковое, и при этом записываться *одинаково* (не добавляя суффиксов типа >su для сравнения знакового и беззнакового)

мне кажется, тут придется переопределить ВСЕ операции форта, чтобы параллельно обычному стэку работал стэк с типами данных

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от anonymous

>проблем реализации полиморфизма

Угу. Башкой в столб. Бум-бум. Столб уже погнулся малость... Хочецца полиморфизма, так объяви тип полиморфным. И будет полноценный полиморфизм с блекдж^W^W в рантайме и с множественной диспетчеризацией в нагрузку. А не хочешь рантайма, то пользуйся специализацией, но с разумными ограничениями.

Одерский достаточно неплохо смог увязать алгебраические типы с иерархией типов (с помощью case-классов).

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

Macil ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> все операции < > + - должны работать с парой ... беззнаковое-и-знаковое

Кстати, а что должно получаться в результате этих операций, как это должно работать?

anonymous ()
Ответ на: комментарий от anonymous

>не вижу ничего плохого, чтоб set_center умел переключаться на POINTS

В чём проблема сказать POINTS?

этому мешает полиморфизм, указатель может указывать на предка/потомка POINT и перекрытые/виртуальные методы точно попадают в не то пальто.

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

p x
p y
c set_centre ...

Это же очевидно! :)

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

Как можно не видеть очевидное?

Очевидное оно на программках типа 2 2 + . Когда пытаешь написать что-то посерьезней - очевидное быстро отваливается. Может для чего-то Форт и хорош, но не для объектов..

что товарищ ананим намекает на автоматическое распознавание типов

Нет, тут скорее не в типах дело, а именно в контексте. В Питоне контроль типов (в общепринятом понимании) отсутствует, достаточно, чтобы в контексте данного объекта существовал нужный атрибут (поле/метод). Это порождает свои специфические проблемы, но объектная система работает на ура.

anonymous ()
Ответ на: комментарий от anonymous

> Кстати, а что должно получаться в результате этих операций, как это должно работать?

< > очевидно должны давать фортовский bool в виде -1 или 0, а + - знакового с беззнаковым должны давать знаковое

www_linux_org_ru ★★★★★ ()
Ответ на: комментарий от www_linux_org_ru

> < > очевидно должны давать фортовский bool в виде -1 или 0, а + - знакового с беззнаковым должны давать знаковое

- WORD - 16-бит, безнаковое целое от 0 до 65535

- INTEGER - 16-бит, знаковое целое от -32768 до +32767

Поясни, что должно получиться в результате операций (sign <oper> unsign):

-1 > 65535 = ?

-1 < 65535 = ?

-1 + 65535 = ?

-1 - 65535 = ?

-32767 > 65000 = ?

-32767 < 65000 = ?

32767 + 25000 = ?

32767 - 65000 = ?

anonymous ()
Ответ на: комментарий от www_linux_org_ru

>мне кажется, тут придется переопределить ВСЕ операции форта

Все десять? ;)

чтобы параллельно обычному стэку работал стэк с типами данных


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

KRoN73 ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.