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

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


FORTH definitions

vocabulary GRAPH
also GRAPH definitions

vocabulary POINTS
also POINTS definitions
: new
	create ( x y -- "name" )
		, , \ запомним x и y
	does>  ( -- addr )
		FORTH GRAPH POINTS \ установим контекст
;
: .x dup cell+ @ ."  x= " . ;
: .y dup @ ."  y= " . ;
: draw ." point: " .x .y drop ;
GRAPH definitions

vocabulary CIRCLES
also CIRCLES definitions
: new
	create ( x y r -- "name" )
		, , ,
	does> ( -- addr )
		FORTH GRAPH CIRCLES
;
: .x dup cell+ cell+ @ ."  x= " . ;
: .y dup cell+ @ ."  y= " . ;
: .r dup @ ."  r= " . ;
: draw ." circle: " .x .y .r drop ;
GRAPH definitions

POINTS 10 20 new p
CIRCLES 10 20 30 new c

p draw
c draw

GRAPH definitions

: array  \ нам понадобится массив
	create ( size -- "name" )
		cells allot
	does> ( i -- addr ) 
		swap cells +
;

5 constant NNN

NNN array FIGURE

POINTS  11 21    new tmp1 	' tmp1 0 FIGURE !
CIRCLES 12 22 32 new tmp2 	' tmp2 1 FIGURE !
POINTS  13 23    new tmp3 	' tmp3 2 FIGURE !
CIRCLES 14 24 34 new tmp4 	' tmp4 3 FIGURE !
POINTS  15 25    new tmp5 	' tmp5 4 FIGURE !

tmp1 draw
tmp2 draw
tmp3 draw
tmp4 draw
tmp5 draw

0 FIGURE @ execute draw
1 FIGURE @ execute draw
2 FIGURE @ execute draw
3 FIGURE @ execute draw
4 FIGURE @ execute draw

\ с массивом всё в порядке

GRAPH definitions

: testFIGURE CR
	NNN 0 ?do 
			i FIGURE @ execute s" draw" evaluate CR 
			\ чтоб не прибить гвоздями первую попавшуюся draw
		loop 
;

testFIGURE

\ с процедуркой всё в порядке

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

[code=forth]

$ gforth <./test.fs Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc. Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license' Type `bye' to exit ok FORTH definitions ok ok vocabulary GRAPH ok also GRAPH definitions ok ok vocabulary POINTS ok also POINTS definitions ok : new compiled    create ( x y — «name» ) compiled       , , \ запомним x и y compiled    does> ( — addr ) compiled       FORTH GRAPH POINTS \ установим контекст compiled ; ok : .x dup cell+ @ ." x= " . ; ok : .y dup @ ." y= " . ; ok : draw ." point: " .x .y drop ; ok GRAPH definitions ok ok vocabulary CIRCLES ok also CIRCLES definitions ok : new compiled    create ( x y r — «name» ) compiled       , , , compiled    does> ( — addr ) compiled       FORTH GRAPH CIRCLES compiled ; ok : .x dup cell+ cell+ @ ." x= " . ; ok : .y dup cell+ @ ." y= " . ; ok : .r dup @ ." r= " . ; ok : draw ." circle: " .x .y .r drop ; ok GRAPH definitions ok ok POINTS 10 20 new p ok CIRCLES 10 20 30 new c ok ok p draw point: x= 10 y= 20 ok c draw circle: x= 10 y= 20 r= 30 ok ok GRAPH definitions ok ok : array \ нам понадобится массив compiled    create ( size — «name» ) compiled       cells allot compiled    does> ( i — addr ) compiled       swap cells + compiled ; ok ok 5 constant NNN ok ok NNN array FIGURE ok ok POINTS 11 21 new tmp1    ' tmp1 0 FIGURE ! ok CIRCLES 12 22 32 new tmp2    ' tmp2 1 FIGURE ! ok POINTS 13 23 new tmp3    ' tmp3 2 FIGURE ! ok CIRCLES 14 24 34 new tmp4    ' tmp4 3 FIGURE ! ok POINTS 15 25 new tmp5    ' tmp5 4 FIGURE ! ok ok tmp1 draw point: x= 11 y= 21 ok tmp2 draw circle: x= 12 y= 22 r= 32 ok tmp3 draw point: x= 13 y= 23 ok tmp4 draw circle: x= 14 y= 24 r= 34 ok tmp5 draw point: x= 15 y= 25 ok ok 0 FIGURE @ execute draw point: x= 11 y= 21 ok 1 FIGURE @ execute draw circle: x= 12 y= 22 r= 32 ok 2 FIGURE @ execute draw point: x= 13 y= 23 ok 3 FIGURE @ execute draw circle: x= 14 y= 24 r= 34 ok 4 FIGURE @ execute draw point: x= 15 y= 25 ok ok \ с массивом всё в порядке ok ok GRAPH definitions ok ok : testFIGURE CR compiled    NNN 0 ?do compiled          i FIGURE @ execute s" draw" evaluate CR compiled          \ чтоб не прибить гвоздями первую попавшуюся draw compiled       loop compiled ; ok ok testFIGURE point: x= 11 y= 21 circle: x= 12 y= 22 r= 32 point: x= 13 y= 23 circle: x= 14 y= 24 r= 34 point: x= 15 y= 25 ok ok \ с процедуркой всё в порядке ok

[/code]

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

$ gforth <./test.fs 
Gforth 0.6.2, Copyright (C) 1995-2003 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `bye' to exit
  ok
FORTH definitions  ok
  ok
vocabulary GRAPH  ok
also GRAPH definitions  ok
  ok
vocabulary POINTS  ok
also POINTS definitions  ok
: new  compiled
	create ( x y -- "name" )  compiled
		, , \ запомним x и y  compiled
	does>  ( -- addr )  compiled
		FORTH GRAPH POINTS \ установим контекст  compiled
;  ok
: .x dup cell+ @ ."  x= " . ;  ok
: .y dup @ ."  y= " . ;  ok
: draw ." point: " .x .y drop ;  ok
GRAPH definitions  ok
  ok
vocabulary CIRCLES  ok
also CIRCLES definitions  ok
: new  compiled
	create ( x y r -- "name" )  compiled
		, , ,  compiled
	does> ( -- addr )  compiled
		FORTH GRAPH CIRCLES  compiled
;  ok
: .x dup cell+ cell+ @ ."  x= " . ;  ok
: .y dup cell+ @ ."  y= " . ;  ok
: .r dup @ ."  r= " . ;  ok
: draw ." circle: " .x .y .r drop ;  ok
GRAPH definitions  ok
  ok
POINTS 10 20 new p  ok
CIRCLES 10 20 30 new c  ok
  ok
p draw point:  x= 10  y= 20  ok
c draw circle:  x= 10  y= 20  r= 30  ok
  ok
GRAPH definitions  ok
  ok
: array  \ нам понадобится массив  compiled
	create ( size -- "name" )  compiled
		cells allot  compiled
	does> ( i -- addr )   compiled
		swap cells +  compiled
;  ok
  ok
5 constant NNN  ok
  ok
NNN array FIGURE  ok
  ok
POINTS  11 21    new tmp1 	' tmp1 0 FIGURE !  ok
CIRCLES 12 22 32 new tmp2 	' tmp2 1 FIGURE !  ok
POINTS  13 23    new tmp3 	' tmp3 2 FIGURE !  ok
CIRCLES 14 24 34 new tmp4 	' tmp4 3 FIGURE !  ok
POINTS  15 25    new tmp5 	' tmp5 4 FIGURE !  ok
  ok
tmp1 draw point:  x= 11  y= 21  ok
tmp2 draw circle:  x= 12  y= 22  r= 32  ok
tmp3 draw point:  x= 13  y= 23  ok
tmp4 draw circle:  x= 14  y= 24  r= 34  ok
tmp5 draw point:  x= 15  y= 25  ok
  ok
0 FIGURE @ execute draw point:  x= 11  y= 21  ok
1 FIGURE @ execute draw circle:  x= 12  y= 22  r= 32  ok
2 FIGURE @ execute draw point:  x= 13  y= 23  ok
3 FIGURE @ execute draw circle:  x= 14  y= 24  r= 34  ok
4 FIGURE @ execute draw point:  x= 15  y= 25  ok
  ok
\ с массивом всё в порядке  ok
  ok
GRAPH definitions  ok
  ok
: testFIGURE CR  compiled
	NNN 0 ?do   compiled
			i FIGURE @ execute s" draw" evaluate CR   compiled
			\ чтоб не прибить гвоздями первую попавшуюся draw  compiled
		loop   compiled
;  ok
  ok
testFIGURE 
point:  x= 11  y= 21 
circle:  x= 12  y= 22  r= 32 
point:  x= 13  y= 23 
circle:  x= 14  y= 24  r= 34 
point:  x= 15  y= 25 
 ok
  ok
\ с процедуркой всё в порядке  ok

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

> Может для чего-то Форт и хорош, но не для объектов..

Ха! Как там про утку?

«Если кто-то ходит как утка, плавает как утка и крякает как утка — то, скорее всего, это утка и есть» ?

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

-1 < 65535 = true, хотя бинарно они идентичны : 0xFFFF

в общем, со сравнением все по правилам математики,

а вот с переполнением при сложении — надо выкидывать исключение делать что удобнее при реализации, но типы должны быть правильные: u+u=u, s+s=s, u+s=s+u=s

(а удобнее, видимо, считать что -1s+65535u=-2s)

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

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

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

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

В режиме интерпретации, видимо, тоже.

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

> Может быть я не очень четко выразился, но целые должны

Может тебе не очень ясно намекнули, что ты о какой-то нерегламентированной .уйне спросил, которая кроме как забавной под*бки про бинарные операции над знаковыми и беззнаковыми, никому на .уй не впилась?

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

ну и какой смысл в форте, если из-за типизации стэк раздуется в 1.5 раза?

Вот я и говорю - а где он (стек, память) не раздувается из-за типизации. По моему во всех динамических языках. Можно пытаться разбоксировать всё и вся и строить безтэговую модель памяти. Но бестеговая модель стека - это как?

Например:

typedef enum {
  BOOLEAN,
  INT16,
  ...
} TypeTag;

typedef struct {
  TypeTag type;
} Object;

typedef struct {
  union {
    TypeTag type;
    ...
  }
} Boolean;

typedef struct {
  union {
    TypeTag type;
    ...
  }
} Int16;

...

Операции

Object* push(Object *object);
Object* pop();

Будут определены, а вот если убрать тэги со стека - push ещё ладно, но как будет работать pop?

(Можно хранить структуры в памяти, а на стек класть/снимать указатели , но это незначительно - чтобы сделать pop, нужно перейти по указателю и прочесть... сколько? нужен тэг?)

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

> ну и какой смысл в форте, если из-за типизации стэк раздуется в 1.5 раза?

Да ладно! Тебя же, вон, чего-то раздуло раза в полтора-два, так... Сижу, вот, теперь, думаю: подколоть или ну его, а то монитор заляпаешь?

P.S. Кстати, а при чём здесь стек?

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

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

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

> Но бестеговая модель стека - это как?

Бог мой! А это что ещё за хрень?! Что значит теговая-бестеговая? Это, вообще, о чём? Сколько нужно заплатить, чтобы от этого избавиться?!

а вот если убрать тэги со стека - push ещё ладно, но как будет работать pop?

Эта... старый-добрый способ ( id0 id1 id2 id3 id4 .. id[n-1] n — ) не то?

И что такое теги на стеке, зачем их убирать со стека и что они там, вообще, делают?

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

Бог мой! А это что ещё за хрень?! Что значит теговая-бестеговая? Это, вообще, о чём? Сколько нужно заплатить, чтобы от этого избавиться?!

И что такое теги на стеке, зачем их убирать со стека и что они там, вообще, делают?

Эта, я не понимаю вашего не понимания. Что такое тайптег не знаете? Чтобы отделять объекты разных типов в рантайме динамических языков - то что называется латентной (скрытой) типизацией у typeless языков.

Таки как будет работать pop без тайптегов?

Кстати, вот что интересно:

( id0 id1 id2 id3 id4 .. id[n-1] n — )

Это что? Это на форте что-то? Если да - при чём тут закорючки target языка?

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

s/не понимания/непонимания/

s/typeless/dynamic typed/ скорее всего.

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

Таки как будет работать pop без тайптегов?

А проблемы связи pop с тайптегами очень важны? Неужели так сложно определить размер структуры и сколько данных нужно выкинуть со стека без тайптегов?

( id0 id1 id2 id3 id4 .. id[n-1] n — )

Эта запись отображает состояние стека, когда на его вершине лежит число n, а под ним n ячеек (размера CELL, например 4 байта) данных.

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

Неужели так сложно определить размер структуры и сколько данных нужно выкинуть со стека без тайптегов?

Размер структуры и определятеся в зависимости от тайптега:

size_t size_of(Object *object) {
  switch object->type {
    case BOOLEAN: return sizeof(Boolean);
    case INT16:   return sizeof(Int16);
    ...
  }
}

Например - на вершине стека лежит объект (число, символ (указатель на него), структура (указатель на неё)) нужно его удалить. Вопрос - сколько байт удалять? И как вообще узнать - число там или символ или что? Вот тайптег и указывает - что именно лежит и сколько удалять.

Нужно поправится - Forth допустим typeless, т.е. вопрос о тэгировании значений на стеке может выглядеть странным (точно не знаю), но ведь еть другие языки (Factor, напрмер) где этот вопрос естесвеннен. Это www_linux_org_ru захотел и типизировать значения на стеке и чтобы без тайптегов - вот я и удивился, как это можно сделать (?)

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

Вопрос - сколько байт удалять? И как вообще узнать - число там или символ или что?

Да, причём не в семантике форта, а в семантике реализации его VM.

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

>с процедуркой всё в порядке ok

Даа.. И кто-то еще удивляется, почему Qt не портировали на форт.. :)

s" draw" evaluate

Вместо двух разыменований, при каждом вызове лопатить словарь в рантайме - это сурово. Это просто феерично. Это не жесть, это танковая броня на велосипеде. Вы правда думаете, что это можно хоть где-то всерьез использовать?

Плюс, для создания массива вам потребовалось создать 5 слов. Руками. Ну, это, разумеется, пустяк.. создать заранее побольше переменных и потом сгребать их в массивы.

Что ж, дерзайте.. Маленькая тележка костылей уже есть, еще вагон и все получится..

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

И кто-то еще удивляется, почему Qt не портировали на форт.. :)

Фортеры ворвались в тред и принялись показывать, куда именно провалился ООП ;)

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

> типизировать значения на стеке и чтобы без тайптегов - вот я и удивился, как это можно сделать (?)

А отказ от пользовательских значений на стеке и использование всеми операциями адресов структур операндов может быть решением проблемы?

Вообще-то говоря, распознать на бестиповом стеке типы структур - занятие, мягко говоря, даже выглядит сомнительным. И совершенно непонятно: зачем?

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

А отказ от пользовательских значений на стеке и использование всеми операциями адресов структур операндов может быть решением проблемы?

В принципе да. По крайней мере после того как адрес будет взят со стека и мы возьмём по нему структуру - тут ситуация сведётся к подобным в других языках программирования.

Например пусть на стеке (даже уже не важно что на стеке) могут лежать целые числа (integer) и рациональные числа rational как пара (integer, u_integer). И нужно построить, для начала, полиморфную операцию (+), это по крайней мере:

(+) :: integer,  integer  -> integer
(+) :: integer,  rational -> integer or rational
(+) :: rational, integer  -> integer or rational
(+) :: rational, rational -> integer or rational

И тут два варианта:

1) Поле типа при структурах, четыре спецификации для (+) и один generic.

2) Немного другая терминология - компиляция абстракции паттерн-матчинга такая, что специфичные (+) функции будут ссылать на те области памяти которые по типам гарантировано совпадают с соответсвующим типом спецификации, в этом случае таптег можно убрать (tagless).

Вообще-то говоря, распознать на бестиповом стеке типы структур - занятие, мягко говоря, даже выглядит сомнительным. И совершенно непонятно: зачем?

Ну можно взять гетерогенные списки типизированных значений и построить на них базовые операции форта - будет типизированный динамический стек.

А сами типы, видимо, нужны ради типов - например вот есть статья про вывод типов на типизированном стековом языке: Simple Type Inference for Higher-Order Stack-Oriented Languages.

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

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

Естественно. Но в указателе и не хранят его тип. А вот размер указателя в Форте обычно равен размеру целого.

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

>> с процедуркой всё в порядке ok

Даа.. И кто-то еще удивляется, почему Qt не портировали на форт.. :)


Кхм... Процедурку с draw заказывали? Заказывали. Получите и распишитесь.

s" draw" evaluate


Вместо двух разыменований, при каждом вызове лопатить словарь в рантайме - это сурово. Это просто феерично. Это не жесть, это танковая броня на велосипеде.


Так... к пуговицам^Wвызовам draw претензии есть? Убедились, что у нас танковая броня легким движением руки работает в runtime?

Работает? Работает. И это вы её ещё в бикини не видели! :)

Вы правда думаете, что это можно хоть где-то всерьез использовать?


Да. :) Это же настоящий runtime context за смешные деньги!

Плюс, для создания массива вам потребовалось создать 5 слов. Руками. Ну, это, разумеется, пустяк.. создать заранее побольше переменных и потом сгребать их в массивы.


Вообще-то, мог это сделать и в одну строчку. Но.

Надеюсь, ты понял каждую строку, как оно работает? Надеюсь, тебе не требуются дополнительные тестовые данные для исследования феномена и ты не только веришь всему представленному на экране, но и понимаешь о чём там?

Так, что не устраивает?

Что ж, дерзайте.. Маленькая тележка костылей уже есть, еще вагон и все получится..


Вообще-то, где-то в 1992 года, Черезов А.Ю. из Калиниграда, в предисловии к своему SP_FORTH 20.07.1992-31.07.1992 v1.01, завил открытым текстом:

«Наследование, третий кит ООП, прекрасно реализуется в Форте в виде так
называемых „контексных словарей“ (это единственный случай, когда одно и то
же понятие называется в Форте более „заковыристо“, чем принято в ООП). Може-
те считать словарь обьектом, каждый новый словарь, определенный внутри него
словом VOCABULARY, будет его потомком и будет наследовать его методы (в Фор-
те, как вы помните, нет обычных данных). Это сильно напоминает вам Турбо Пас-
каль, но в отличие от него, обьект может иметь несколько предков (множествен-
ное наследование, как в C++). Более того, для каждого метода, используемого
внутри нового обьекта, вы можете указать обьекта-хозяина, указав его имя (имя
контексного словаря). Обьект-потомок „видит“ все методы и данные в ветви каж-
дого из своих предков, вплоть до „корневого“ обьекта с именем FORTH (это имя
базового словаря Форта), и может их использовать. В этом случае имя предка
можно не указывать, оно нужно только для избежания двусмысленности - когда,
например, в двух родительских словарях (обьектах) есть методы с одним и тем
же именем. Причем в одном и том же словаре (обьекте) могут быть слова (мето-
ды), перекрывающие сами себя (описание полиморфизма Форта уже было дано).
Все это дает возможность вам избавиться от примитивных шаблонов использова-
ния средств ООП, навязываемых вам Турбо Паскалем и С++ (хотя ради справедли-
вости надо отметить, что и они являются прекрасными инструментами, просто
Форт - это шаг далеко вперед, (кстати, FORTH так и переводится - „вперед“)).
Контексные словари - это один из способов реализации наследования в Форте,
но в Форте есть и второй, совершенно другой (принципиально другой !), хотя
и он вызывает ассоциации с уже знакомыми способами: это реализация наследо-
вания с помощью тех же чудодейственных слов CREATE...DOES>.»

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

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

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

Нет, ребята.

Вам предложено сделать наиначальнейшую и примитивнейшую (имеющуюся нахаляву даже на си без плюсов) реализацию полиморфизма на вашем СуперПуперФорте, а от вас уже слышен мат.

Что будет, когда речь зайдет о чем-то посложнее?

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

>Вам предложено сделать наиначальнейшую и примитивнейшую (имеющуюся нахаляву даже на си без плюсов) реализацию полиморфизма на вашем СуперПуперФорте

Выше уже было. Читай внимательнее.

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

>Так... к пуговицам^Wвызовам draw претензии есть? Убедились, что у нас танковая броня легким движением руки работает в runtime?

Угу, на велосипеде, задом наперед, стоя на лыжах, с аквалангом, в балетной пачке.. Собственно никто и не утверждал, что сделать невозможно - возможно, но через анальное отверстие. Что вы с успехом продемострировали, спасибо.

Работает? Работает. И это вы её ещё в бикини не видели! :)

Скорее к этому подходит определение «страдает хернёй». В бикини..

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

Вижу только Integer, где signed и unsigned варианты?

где operator<(signed, signed) ?
где operator<(signed, unsigned) ?
где operator<(unsigned, signed) ?
где operator<(unsigned, unsigned) ?

где способ переключения 4 контекстов?

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

> Скорее к этому подходит определение «страдает хернёй». В бикини..

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

так что ООП легко моделируется; а вот современные языки, типа хаскеля и с++, уже требуют некоторых усилий

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

и вот одна цитата на тему о форте:

http://www.linux.org.ru/jump-message.jsp?msgid=3076729&cid=3079379

Я ж писал, что у меня программа на Си++ поместилась в 8-битный ATtiny13 с 64 байт ОЗУ и 1 Кб ПЗУ, заняв места не больше чем на Си... За ссылку на форт спасибо, однако о его эмбеддерском применении никогда не слышал ни от одного производителя и ни одного эмбеддерщика... чесслово... Си, да и Си++ - приятный на вид удобный привычный достаточно мощный язык + поддерживается десятками производителей, да и Си и Си++ из GCC (сори если не так выразился, ну в общем меня поняли :) ) много для чего есть...

www_linux_org_ru ★★★★★ ()

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

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

>(Можно хранить структуры в памяти, а на стек класть/снимать указатели , но это незначительно - чтобы сделать pop, нужно перейти по указателю и прочесть... сколько? нужен тэг?)

форт еще как-то можно спасти, если тэги хранить где-то параллельно... типа как на стэке возвратов; но со мной предпочитают ругаться, а не слушать :-)

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

>где operator<(signed, signed) ?

Очень не многие языки так умеют. Так что тут претензия явно не к Форту :D Тем более, что на Форте так можно, только уже в десяток строк не уложиться, тут думать нужно.

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

>форт еще как-то можно спасти, если тэги хранить где-то параллельно...

Да вагон там вариантов. Это-то и погубило в своё время Форт. Слишком легко реализуются слишком разные варианты. Каждый затачивает под себя и плевать ему на других.

Если уже тэги приспичит хранить именно на стеке, то лучше это делать не в параллельном стеке, а в основном же. Как под DOS указатели хранили в виде двух 16-битных целых. Или как всю жизнь в классическом Форте на стеке хранят строки.

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

> Угу, на велосипеде, задом наперед, стоя на лыжах, с аквалангом, в балетной пачке..

С хера ли такие сложности? Смотри внимательно на код. Смотри на код. Где там лыжи, акваланг или упоминание классического русского балета? Все средства стандартные. Средства языка не используются вне своей компетенции.

Далее, размеры словарей минимальны, накладные расходы на runtime минимальны. Можно посмотреть на содержание словарей (words) и цепочки их контекстов (order), чтоб понять - решение элегантно и заложено в реализации языка.

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

Да у тебя, я смотрю, любое отверстие - анальное.

Все средства применялись в соответствии с ANSI-стандартом, а конечный эффект можно реализовать на основе любого из принятых ANSI-стандартов.

Что вы с успехом продемострировали, спасибо.

Пжалста. У меня ещё много бисера в карманах.

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

> на любом, сколь угодно тупом языке можно сделать поле типа в структуре и по нему выбирать контекст, откуда вызывается операция, и это вполне можно назвать ООП

Любой, сколь угодно тупой эксперт может требовать и выставлять условия, и его вполне можно назвать экспертом. :D

так что ООП легко моделируется;

Оп-па! Дамы и господа! Случилось чудо! Теперь можно считать, что ООП легко моделируется!

И вы ещё до сих пор спрашиваете: Почему объектно-ориентированное программирование провалилось?

а вот современные языки, типа хаскеля и с++, уже требуют некоторых усилий

Гы. Ты ещё заяви, что ассемблер не требует усилий, эксперт, бл*. :)

P.S. Ты совсем дурак или у меня просто угол обзора неудачный?

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

>Все средства стандартные.

Даа.. задание имен методов через строковую константу - это стандартно?

накладные расходы на runtime минимальны

поиск по связанным спискам при каждом вызове - это эффективно?

Да у тебя, я смотрю, любое отверстие - анальное.

И после этого вы удивляетесь, почему вас не приглашают в приличное общество??

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

> Да вагон там вариантов. Это-то и погубило в своё время Форт. Слишком легко реализуются слишком разные варианты. Каждый затачивает под себя и плевать ему на других.

Кстати, да. Слишком много возможностей. Слишком легко, ещё на начальном этапе, реализуются разные варианты. А первоначальное решение использовать те или иные инструменты или эффекты, заложенное в фундамент, как правило диктует дальнейшую методику работы. Цена ошибки проектирования заложенной в фундамент становится слишком высокой. К примеру, можно наблюдать огромное количество реализаций ООП в Forth (в виде классов, микроклассов и пр. характерных для изначально не предназначенных для этого языков), а родные механизмы остаются, как правило, недостаточно изучены и поняты.

И в то время, когда многие могут говорить о том, что ООП начинает разваливаться под тяжестью собственного наследия и упираться всеми боками в ограничения реализаций, в случае Forth мы можем наблюдать совершенно противоположные проблемы — свобода оказывается слишком свободной, инструменты слишком индивидуальны, а понимание и создание алгоритмов решения поставленной задачи - слишком специфическим. Подобный эффект характерен и для Lisp - чудесный язык, но использовать могут и должны профессионалы.

К примеру, решение пометить все генераторы и экземпляры метками типов, с последующей реализацией механизма наследования (например, по типу связного однонаправленного списка как слов в словаре), предопределит дальнейшую работу с типами по принципу специального полиморфизма, пусть и на самом деле мы, в конечном итоге, хотели реализовать в DSL нечто вроде параметрического полиморфизма. Но это скорее проблемы проектирования (классификации) и понимания разницы между инструментом и решением поставленной задачи. Момент, когда инструмент становится решением поставленной задачи, определять должен программист, а не инструмент. Вот, собственно, где-то здесь проблема и проявляется.

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

Все средства стандартные.

Даа.. задание имен методов через строковую константу - это стандартно?

Так наглядно и понятно. Всё по аналогии. Даже люди не знающие Forth могут заметить аналогию и понять пример.

А специально для тебя создать эффективные реализации одинаково работающие в разных режимах? Зачем, если задачей было продемонстрировать эффект?

накладные расходы на runtime минимальны

поиск по связанным спискам при каждом вызове - это эффективно?

Да. Это самый простой в понимании и самый общий случай. Тема нашего разговора — контексты, не так ли? К тому же, в принципе, можно подсунуть любой другой контекст с другой своей реализацией POINTS или CIRCLES, оставив код их использования без изменений. Мне что, рассказать тебе про динамические контексты и зачем они нужны?

Создай словарь, определи в нём несколько слов и спроси WORDS — ты увидишь там только те несколько слов. Да, это эффективно.

Можешь попробовать доказать обратное.

Да у тебя, я смотрю, любое отверстие - анальное.

И после этого вы удивляетесь, почему вас не приглашают в приличное общество??

А это где? Ещё одно общество лицемеров? :)

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

>Так наглядно и понятно.

Потому, что по нормальному не получается.

Да, это эффективно.

Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме. И тем более при КАЖДОМ вызове. Эффективно - это два разыменования. Но у вас, видимо, свои понятия об эффективности - АНАЛогичные.

Всё по аналогии.

И чуть-чуть по гинекологии.. :)

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

>> Так наглядно и понятно.

Потому, что по нормальному не получается.

Что означает «по нормальному»? Что ты ожидаешь?

Да, это эффективно.

Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме. И тем более при КАЖДОМ вызове.

Категоричное безосновательное заявление. Сделай, померяй и тогда принимай решение. Если динамический контекст в рантайме становится объективно слишком дорог - переделай.

Эффективно - это два разыменования.

Прибить гвоздями это эффективно?

Это ты разыменования считаешь самыми эффективными и «нормальными»? Для таких как ты придумали ВЕКТОРНЫЕ ВЫЧИСЛЕНИЯ ( http://www.nncron.ru/book/sf/chapter9.htm ). Играйся - сколько влезет, только причём тут контексты - непонятно. Зачем эмулировать то, что уже есть в чистом виде?

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

>Да нифига это не эффективно. Это нормально во время компиляции, но никак не в рантайме

Так мой древний вариант посмотри. Там в райнтайме потери по сравнению с чистым Фортом минимальны. И не зависят от глубины наследования. Вызов виртуального метода - одно чтение адреса из памяти и вызов по нему. По-моему, в Си++ также.

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

Вот о чём и речь. У каждого фортера есть свой ООП :)

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

> Оп-па! Дамы и господа! Случилось чудо! Теперь можно считать, что ООП легко моделируется!

Чудо не случилось. Я молчал, т.к. мне было прикольно наблюдать, как фортеры пыхтят и реализуют тривиальный (общеизвестный) механизм :-)

Впрочем, от этого была польза — выяснилось, что они понимают его детали существенно по-разному.

www_linux_org_ru ★★★★★ ()

Образцовый вброс. Что тут скажешь. Семнадцатая страница идет.

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

> И что? К чему это?

Интересно, можно ли (маленькую) прогу на форте затолкать в 64 байта оперативки и 1024 байт ПЗУ?

То, что форт занимается упрощенной компиляцией, ставит его позади с++; жцц может занять 2ГБ оперативы, инлайня и оптимизуя, зато в рантайм прога будет маленькой, белой и пушистой.

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