"Не пущать!" vs "Хай будэ.."

profiT

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

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

Закрытость компилятора -- тоже запретительная концепция, которая ведёт к таким "форточкам" как препроцессор C, макросы ассемблера, шаблоны в C++.

"Может уже что-то в консерватории подправить?" (с)

Зачем нужны эти запреты, если они только нагромождают условностей, увеличивают сложности и снежным комом порождают новые запреты? Зачем они нужны если всё равно их надо обходить?

Единственный ничего (ну, или почти ничего) не запрещающий язык (насколько я знаю) -- Форт. Хочешь себе -- императивщина, хочешь -- ассемблер, хочешь -- прототипирование, хочешь -- ООП, хочешь -- ЛИСП и ПРОЛОГ, хочешь -- бэкФорт, а хочешь -- всё вместе и в комбинациях. Нет искусственных ограничений на программы.

А вот недавно прочитал критику Javascript'а за то что он в нескольких местах тоже придерживается идеи "Хай будэ". Дескать, там ООП "ненастоящее". Почему?.. Потому что оно там мало запрещает:

Цитата:

Не лучше обстоит дело и с наследованием. Для его реализации применяется механизм прототипов. Он определяет набор свойств и функций, которые автоматически получает вновь создаваемый объект. И тут нас ждет новый сюрприз. Оказывается, два объекта, созданные с помощью одного и того же конструктора, могут иметь различную структуру! Дело в том, что никто не мешает в любой момент изменить прототип. Может ли наследование оказаться полезным в подобной ситуации?

В кои-то веки в mainstream'е развития ЯП сделано упрощение концепций, которое закономерно ведёт к большей гибкости в программировании, а его за эту гибкость ругают...

Запреты физически непреодолимые против запретов принятых, то есть бетризация (см. "Возвращение со звёзд" С. Лема) против 10 заповедей.

Но если подработать адвокатом дьявола, то и у этих запретов должны быть серьёзные и объективные преимущества... Перечислите их пожалуйста, а то вот то что придумываю я сам пока звучат слишком общо.

chess

profiT писал(а):

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

Это логично - типы и введены так, чтобы они были невзаимозаменяемы.
Все mainstream-языки ориентированы на снижение трудоемкости разработки ПО за счет использования готовых шаблонов того или иного вида. Если задача не может быть решена в рамках набора шаблонов, то возникают "обходы запретов".
В Форте почти нет шаблонов, поэтому почти нет и запретов.

Mihail

chess писал(а):

Все mainstream-языки ориентированы на снижение трудоемкости разработки ПО за счет использования готовых шаблонов того или иного вида. Если задача не может быть решена в рамках набора шаблонов, то возникают "обходы запретов".
В Форте почти нет шаблонов,

Если в Форте чего нет, то всегда можно ввести.

Цитата:

поэтому почти нет и запретов.

Почему почти?
Однако, и любые запреты можно ввести, но лучше это делать с возможностью откатки.

chess

Mihail писал(а):

Почему почти?

Ну, например, запрет на использование пробела в имени слова.

Mihail

chess писал(а):

Ну, например, запрет на использование пробела в имени слова.

Лично мне, никто не запрещал.
Для СПФ4:

Код:

: S:  SHEADER  ]  HIDE ;

S" HI FORTH" S: ." Hello USER!" ;

S" HI FORTH" SFIND 0= THROW EXECUTE

Систему, в которой что-то нельзя, я за Форт не считаю.
Ограничение дает только среда базирования.

chess

Mihail писал(а):

Лично мне, никто не запрещал.

Ну в словарь HI FORTH через строку загнали и исполняем его тоже через строку, это все не то, должно
быть как-то так:

Код:

{ 1 BL }  : HI FORTH S" Hello USER!" ;
HI FORTH

ygrek

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

chess

yGREK писал(а):

Определите поведение в случае если в словаре даны слова HI, FORTH, HI FORTH.

Поведение чего?

ygrek

Интерпретатора. Определены эти три слова и на входе (строка для EVALUATE) как в примере выше - HI FORTH.
Опишите строго алгоритм работы интерпретатора в таких случаях и потом сформулируйте - какой запрет мешает это реализовать.

chess

yGREK писал(а):

Опишите строго алгоритм работы интерпретатора в таких случаях и потом сформулируйте - какой запрет мешает это реализовать.

Замаемся описывать, так как таких случаев может быть очень много.

ygrek

"Поди туда не знаю куда, принеси то, не знаю что"? О каком запрете тогда идёт речь?! То что Форт не может выполнить незаданный алгоритм?

А кто может?

Mihail

Код:

0 VALUE }CHAR
0 VALUE }COUNT

: { ; 

: } TO }CHAR TO }COUNT ;

: }PARSE-WORD ( -- c-addr u )
  SkipDelimiters
  CharAddr >IN @
  SkipWord
 }COUNT 0 ?DO  GetChar  IF }CHAR = IF >IN 1+! THEN ELSE DROP THEN  SkipWord
  LOOP
  >IN @ - NEGATE

  >IN @ 1+ #TIB @ MIN >IN !
;

: :  }PARSE-WORD  SHEADER  ]  HIDE ;

: }INTERPRET ( -> )
  BEGIN
    }PARSE-WORD DUP
  WHILE
    SFIND ?DUP
    IF
         STATE @ =
         IF COMPILE, ELSE EXECUTE THEN
    ELSE
         S" NOTFOUND" SFIND 
         IF EXECUTE
         ELSE 2DROP ?SLITERAL THEN
    THEN
    ?STACK
  REPEAT 2DROP
;

{ 1 BL }  : HI FORTH ." Hello USER!" ;

' }INTERPRET &INTERPRET !

HI FORTH

Гость

profiT писал(а):

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

Обходить пол-дела, а компилятору, еще к тому же, необходим титанический труд по их контролю:)
Да и то бывает даже он не справляется и не выдает даже Warning в безобидной
ситуации.

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

chess

chess писал(а):

Замаемся описывать, так как таких случаев может быть очень много.

yGREK писал(а):

"Поди туда не знаю куда, принеси то, не знаю что"? О каком запрете тогда идёт речь?! То что Форт не может выполнить незаданный алгоритм? А кто может?

Здесь речь идет не о не заданном алгоритме, а о трудоемкости описания алгоритма работы интерпретатора.
Да - решение через интерпретатор принципиально есть, но практически его нет из-за превышения разумного порога по трудоемкости(вот он практический запрет - теория никого не интересует!).

chess

Mihail писал(а):

{ 1 BL } : HI FORTH ." Hello USER!" ;
' }INTERPRET &INTERPRET !
HI FORTH

у меня было по другому, и информации в этой записи достаточно(даже при условии, что слова HI в словарях нет).

Код:

{ 1 BL }  : HI FORTH S" Hello USER!" ; 
HI FORTH

"Не пущать!" vs "Хай будэ.."

Кто сейчас на конференции