Re[11]: Прочёл... Ик.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 15:35
Оценка:
Здравствуйте, batu, Вы писали:

ГВ>>

Обычно (и привычно) объединение концептов осуществляется скобками. Собственно для этого скобки и придумали.

ГВ>>Was ist концепт? Что это такое?
B>Что такое концепт изложено в старттопике.

Эммм... А я-то думал, что старттопик — это только аннотация к тексту, а не составляющая.

ГВ>>Потом, ты сходу вводишь кучу разновидностей скобок (сиречь — группировок), постоянно ссылаясь на некое "выполнение" концептов, но при этом пропущено объяснение того, что же такое это самое выполнение. В смысле, сама модель вычислительной среды у тебя отсутствует. Что, за чем, кем и когда выполняется? Ну не с неба же оно всё берётся!

B>Не с неба. Алгоритм виртуальной машины я еще не выложил потому что не все основы изложил. Но в старт топике указал что концепт-субъект имеет программу которая и запускается при выполнении концепта-объекта. Т.е. концептов порожденных непосредственно классом Concept.
B>Ну, и раздел 3. Там более подробно.

Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.

ГВ>>Вот это вообще десять:

Любой концепт может представлять собой как императивную сущность, так и логическую

ГВ>>Что это такое: императивная сущность? А логическая?
B>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)

В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники.

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

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

Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак.

ГВ>>Добавим сюда путаницу. Раздел 1 вводит термины: круглые, фигурные, квадратные, именные, перечислимые, лексические, метареализации (это всё были скобки). Хорошо, пусть так. Раздел 2:

1. В скобках объединено один, и более концептов. Это непосредственно группирование концептов. Исключение составляют круглые, текстовые или квадратные скобки с единственным концептом


ГВ>>Что такое текстовые скобки?

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

Обязательно. Иначе ты сбиваешь читателя с толку.

ГВ>>Дальше:

1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл

.


ГВ>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь.

B>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.

Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".

B>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.


А можно сказать — глокая куздра. Тоже ведь так можно сказать?

B>Но это сейчас не важно.


Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему.

B>Важно то, что "Перевод строки" тоже знак (ну и концепт само собой).


Это концепт типа "знак" или "знак" типа "имя концепта"? Кто на ком стоял?

B>Так этот знак в текстовых скобках не приводит к переводу строки. Здесь опять мы пропустим две важные вещи как выполняется функциональная часть концепта "Перевод строки" и как определяется. Это важно, но пока достаточно того что уже сказано. Отключается функциональный смысл.


Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.

B>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.


Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори.

B>Дело в том что к ЛЮБОМУ концепту при создании мы можем добавить новые свойства (плюс к тем что в классе), новые методы и новые события (это реализация называется).


О, как. "Дело в том"! Ты ещё не поставил неявного но единственного вопроса, чтобы огорошивать читателя нежданным открытием. Пока что у читателя возникает туева хуча вопросов совершенно отвлечённых вопросов.

B>Эти события могут обрабатываться процедурами. В общем, если концепт взят в текстовые скобки, то все что мы ему доопределили не выполняется.


А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем?

Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое.

ГВ>>Ещё бриллиант из следующего абзаца:

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


ГВ>>А чем отличается индекс от имени и от ключа?

B>Можно сказать ничем не отличается. То дураки дали разные названия.

Нашему бы теляти...

ГВ>> И снова водопад новых слов: массив, коллекция. А почему нет, скажем, "набора" и "множества"?

B>Добавь. И любое пользовательское объединение...

Ещё лучше...

ГВ>>И в том же духе по остальному тексту. В третьем разделе есть какое-то упоминание про теговую машину, но что это за зверь такой — не понятно. Тебе трудно скопировать все свои описания в один документ?


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


B>Просто поверь, я старался. А как получится насчет это ж и от читателя зависит. И вообще делайте больше замечаний. Буду исправлять. Заранее извиняюсь если так что... Но я ж здесь


Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[12]: Прочёл... Ик.
От: batu Украина  
Дата: 13.11.11 16:41
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:



B>>Ну, и раздел 3. Там более подробно.


ГВ>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.

Давай скушаем то, что подано. Я понимаю что не просто.


B>>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)


ГВ>В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники.

Вот часть моих первоисточников.
Альфред Тарский «Введение в логику и методологию дедуктивных наук.»
Стр. 167. Раздел 37. Модель и интерпретация дедуктивной теории.
К. Хоггер «Введение в логическое программирование.»
Стр. 57. Раздел 2. Процедурная интерпретация.
С. Клини 1957. «Введение в математику.»
Стр 125. Раздел 30. Разрешающая процедура. Интерпретация.

Я же написал что этот термин "Интерпретация" не в привычном для программистов смысле, а в том что в логическом программировании.

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

ГВ>Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак.
Не факт. Просто читая литературу по привычному программированию не обращаешь внимание на вроде знакомые термины. А здесь все по другому и буквы и строки.. Так я еще больше запутаю. Просто поверь.


B>>Во введении при определении перечислимых скобок предпоследняя фраза следующая:

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

ГВ>Обязательно. Иначе ты сбиваешь читателя с толку.

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

ГВ>>>Дальше:

1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл

.


ГВ>>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь.

B>>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.

ГВ>Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".


B>>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.


ГВ>А можно сказать — глокая куздра. Тоже ведь так можно сказать?


B>>Но это сейчас не важно.


ГВ>Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему.


Ты ж спросил. Вот и пришлось говорить. Я просил пропустить пока.

ГВ>Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.


B>>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.


ГВ>Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори.


К сожалению, и "выполнение" тоже не катит потому как будет видно дальше выполнение происходит в несколько этапов.

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

ГВ>А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем?

Отключаем обработку событий для единственного концепта в текстовых скобках. А может и для всех концептов в текстовых скобках. Или только для алфавита так сделать. Есть мысли. Это надо обдумать. Но для единственного точно.

ГВ>Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое.

Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных.
Так концепт Form А { Size:=20;120) Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120) )создает эту же форму динамически.


ГВ>>>А чем отличается индекс от имени и от ключа?

B>>Можно сказать ничем не отличается. То дураки дали разные названия.

ГВ>Нашему бы теляти...

А чего б и нет?

ГВ>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.

Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.
Re[13]: Прочёл... Ик.
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 13.11.11 17:35
Оценка:
Здравствуйте, batu, Вы писали:

B>>>Ну, и раздел 3. Там более подробно.

ГВ>>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.
B>Давай скушаем то, что подано. Я понимаю что не просто.

Давай выплюнем недоброкачественное.

B>>>До этого еще рано. Но счел нужным указать на будущее. Концепты имеют не только императивное представление но и логическое. Как в Прологе. И при запуска целевого выражения (это термин из пролога) запускается так же как и в Прологе интерпретация (термин тоже из логического программирования. В императивной парадигме этот термин имеет другое значение)


ГВ>>В Прологе не интерпретация, а машина перебора. Кстати, как раз поэтому Пролог может быть и компилируемым. Короче, посмотри первоисточники.

B>Вот часть моих первоисточников.
B>Альфред Тарский «Введение в логику и методологию дедуктивных наук.»
B>Стр. 167. Раздел 37. Модель и интерпретация дедуктивной теории.
B>К. Хоггер «Введение в логическое программирование.»
B>Стр. 57. Раздел 2. Процедурная интерпретация.
B>С. Клини 1957. «Введение в математику.»
B>Стр 125. Раздел 30. Разрешающая процедура. Интерпретация.

B>Я же написал что этот термин "Интерпретация" не в привычном для программистов смысле, а в том что в логическом программировании.


Давай так. Я из тебя не буду вытягивать слово за словом, а ты всё это внесёшь в одну бумагу. Пусть она окажется на 100 страниц — не страшно. Главное, чтобы изложение было последовательным, полным и непротиворечивым.

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

ГВ>>Значит, изъян где-то в самом излагаемом предмете. Это очень надёжный диагностический признак.
B>Не факт. Просто читая литературу по привычному программированию не обращаешь внимание на вроде знакомые термины. А здесь все по другому и буквы и строки.. Так я еще больше запутаю. Просто поверь.

Да я уж не то, что поверил, а прямо убедился в этой самой путанице.

B>>>Во введении при определении перечислимых скобок предпоследняя фраза следующая:

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

ГВ>>Обязательно. Иначе ты сбиваешь читателя с толку.

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

Угу, хорошо. Только теперь, давай, остальные нестыковки ты найдёшь в своём тексте сам. Ручаюсь, это очень полезная практика.

ГВ>>>>Дальше:

1.1. Единственный концепт в текстовых скобках представляет собой именно сам концепт, игнорируя его синтаксический, семантический и функциональный смысл

.

ГВ>>>>Значит так, если ты говоришь о каких-то "смыслах" изволь дать точное определение этих самых смыслов. Что такое семантический смысл? А синтаксический? "Подлежащее" — это синтаксический или семантический смысл? А "сказуемое" — функциональный? И потом, уточнение "именно сам" означает, что автор сам не определился, о чём он тут говорит. Здесь могут быть варианты: имя концепта, ссылка на концепт по его имени и т.п. Или он у тебя разворачивается в исходный текст, или ещё что-то. Я могу додумать, но за тебя делать этого не собираюсь.
B>>>Точное не приведу. Но суть попробую. Хотя это тоже впереди паровоза. Но что делать. Что б не объяснять сейчас все приведу несколько примеров.

ГВ>>Отказать. Если не можешь объяснить точно — не объясняй вообще. Скажи: "пока не знаю".


B>>>Текст и буквы это тоже концепты. И "Перевод строки" это не буква, а можно сказать событие.


ГВ>>А можно сказать — глокая куздра. Тоже ведь так можно сказать?

B>>>Но это сейчас не важно.
ГВ>>Если не важно, зачем об этом говорить? Многословие — зло. Тем более в тексте, подобном твоему.
B>Ты ж спросил. Вот и пришлось говорить. Я просил пропустить пока.

А, ясно. То есть замечание в скобках с ремаркой "это не важно" — это ответ на мою просьбу. Мда...

ГВ>>Есть корректный термин вместо твоего "функционального смысла": выполнение программы, ассоциированной с концептом. Для примера описания схожей функциональности см. функции QUOTE, EVAL, APPLY в Lisp.


B>>>Вот у нас знак (не важно какой) обозначает комментарий. Как отключить его синтаксический смысл (обозначать комментарий)? Да очень просто. Взять его (единственного) в текстовые скобки.


ГВ>>Забудь про слово "смысл". Вообще. Это всё для вольного пересказа. Смысл в твоём случае должен иметь конкретное наполнение — выполнение, распознавание, ещё что-то. Вот только об этом наполнении и говори.

B>К сожалению, и "выполнение" тоже не катит потому как будет видно дальше выполнение происходит в несколько этапов.

Я не знаю, что катит, а что — нет. Это твоя обязанность — изложить всё внятно и без двусмысленностей. Мне остаётся только гадать.

B>За выполнение программы, ассоциированной с концептом понравилось. Только надо что-то покороче придумать.


Дарю.

ГВ>>А то, что было определено заранее (кстати, где?) — выполняется? А что мы тогда отключаем?

B>Отключаем обработку событий для единственного концепта в текстовых скобках. А может и для всех концептов в текстовых скобках. Или только для алфавита так сделать. Есть мысли. Это надо обдумать. Но для единственного точно.

Какие ещё, к дьяволу, "может быть"? Либо да, либо — нет, либо одно — либо другое. Может быть, не может быть... Ты предлагаешь читателю заниматься гаданием на кофейной гуще?

ГВ>>Бр-р-р... Так, давай по-порядку. В качестве опорной точки выберем нечто привычное и неизменное. Как концепт представляется в памяти машины? Структура, что куда указывает, где какие ссылки, где словари и как реализованы, и всё такое.

B>Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных.
B>Так концепт Form А { Size:=20;120) Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120) )создает эту же форму динамически.

Разные открывающая и закрывающая скобка — это так задумано или опечатка?

ГВ>>>>А чем отличается индекс от имени и от ключа?

B>>>Можно сказать ничем не отличается. То дураки дали разные названия.
ГВ>>Нашему бы теляти...
B>А чего б и нет?

Да не, ничего. Только не надорвись.

ГВ>>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.

B>Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.

Да, всего лишь второй. Не, всё, больше не читаю. Разве что ты переоформишь свои измышления во что-то более удобоваримое. Свистни, когда управишься — постараюсь выступить пруфридером.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[14]: Прочёл... Ик.
От: batu Украина  
Дата: 13.11.11 17:45
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:

B>>Хороший вопрос. Концепт располагается непосредственно непрерывно в памяти (для того он и размер имеет). А выполнять может и создание динамических данных.

B>>Так концепт Form А { Size:=20;120} Представляет собой форму и может применяться для создания формы типа в браузере (у нас нет браузеров, программ и т.п. все загрузочные единицы имеют один формат документа ( Концепт Document). А применение концепта New к этой форме (New Form А { Size:=20;120} )создает эту же форму динамически.

ГВ>Разные открывающая и закрывающая скобка — это так задумано или опечатка?

Опечатка.

ГВ>>>Да я верю, что старался. Только тут не ПКМ, старание в зачёт не идёт, тем более, что ты уже не первый год народ тут долбишь.

B>>Лукавишь. С месяц поболтали и я ушел на год трудится. Доставать это не мое. Не интересно не читай.

ГВ>Да, всего лишь второй. Не, всё, больше не читаю. Разве что ты переоформишь свои измышления во что-то более удобоваримое. Свистни, когда управишься — постараюсь выступить пруфридером.

Ок.
Re[12]: Прочёл... Ик.
От: batu Украина  
Дата: 14.11.11 08:15
Оценка:
Здравствуйте, Геннадий Васильев, Вы писали:


ГВ>Не пойдёт, давай цельное изложение. Ты вообще для чего всё это пишешь? Для того, чтобы читали? Или просто ради mind dump? Если второе, то извини, продолжать дискуссию не вижу смысла.


Я переспал с этим вопросом.
А, действительно, зачем я все это пишу?
Что б поделится своими мыслями. Я не студент-фантаст. Начинал еще в начале 80-х работая на голом железе и дырочки в перфокартах и перфолентах ручками вырезал. Технологии программирования развивались очень быстро. Это, конечно, хорошо. Но в этой гонке многие старые решения не пересматривались, а наследовались как данное и почти святое. В первую очередь это касается кодировки алфавита и методов редактирования. Ведь он тупо скопирован с печатных машинок. С появлением графических мониторов и объектной парадигмы это ж полный бред. Пробел не символ, перевод строки и вообще коды редактирования (форматирования) не символы вообще, а события. Т.е. другой класс объектов. И вообще что такое символ? Значение или объект? И если объект то каким боком там операция сравнения и сортировок? И откуда код символа? Это глупые вопросы для того кто привык к тому как есть. А логично это или нет уже никого не волнует. Получи строковый тип данных и все тут. А почему он отдельный и такой специфический? Может это не правильно?
Потом как появились расширения файлов. Когда были одни программы и комп не применялся для редактирования (текстовых редакторов вообще не было) так и проблем таких не было. И вдруг проявились ассемблеры и текстовые файлы (само значение слова файлы не так давно появилось). Их надо было как то отличать и тут Эврика! Та в имени файла через точку три буквы поставим и все решение. Так и тянем до сих пор это "мудрое" решение. А что можно формат файла (и все свойства файла) содержать в самом файле тогда эта мысль не могла появится.
Прерывания — суть события. Правда и события можно и нужно усовершенствовать. Что и предлагаю.
Загрузку, хранение, распределение памяти, сборка мусора, протокол передачи можно значительно упростить если все имеет единую структуру.
Трансляция, глобализация ставит новые задачи и подходы.
В общем, я предлагаю решение древних проблем и новые подходы к программированию надо только поменять подход.
И, конечно, понимаю что сам я всего задуманного не сделаю. И не только потому что большой объем работы, а потому что все это необходимо прокрутить в мозгах, обсудить, попробовать реализовать. Исправить недостатки и снова обсудить и снова реализовать. Короче у меня уже версий 5 было. А обсуждать не с кем. Да и бабки нужны.
Вот потому и пишу здесь. Матюкайте
Re: Концептная парадигма
От: Буравчик Россия  
Дата: 14.11.11 10:10
Оценка:
Здравствуйте, batu, Вы писали:

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

B>Всем спасибо!

Если я правильно понял, то все это похоже на принципы DSL.

1. Есть у нас некий алфавит (множество концептов). Используя (объединяя) их мы можем написать что-то полезное. Например, все слова некоторого языка программирования (if, for, return) мы можем рассматривать как концепты. Тогда объединяя эти концепты мы получим программу на данном языке программирования.

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

3. Концепты из п.1 (if, for, return) могли быть реализованы на основе каких-то других, более примитивных концептах, например, на концептах виртуальной машины. Те, на еще более примитивных концептах. Значит должны быть какие-то базовые концепты из которых строится все-все, а также правила их объединения.

4. Идея, как я понимаю, и состоит в том, чтобы придумать:
— минимальный набор базовых концептов
— правила объединения концептов синтаксис
— правила задания значения концептов (семантика)
— возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла)

В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.).

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

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

Повторюсь, это то, как я понял. Прошу меня поправить.
Best regards, Буравчик
Re[2]: Концептная парадигма
От: batu Украина  
Дата: 14.11.11 10:38
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Здравствуйте, batu, Вы писали:


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

B>>Всем спасибо!

Б>Если я правильно понял, то все это похоже на принципы DSL.


Б>1. Есть у нас некий алфавит (множество концептов). Используя (объединяя) их мы можем написать что-то полезное. Например, все слова некоторого языка программирования (if, for, return) мы можем рассматривать как концепты. Тогда объединяя эти концепты мы получим программу на данном языке программирования.

Где-то так. Не только программу. Любой документ. Программа это частный случай документа.

Б>2. Но можно также добавлять новые концепты, выражая их через другие концепты. Т.е. придумать некий DSL для описания некой предметной области. Например придумать язык описание юнит тестов. Но система должна знать как трактовать данный концепт, поэтому его семантика должна быть каким-то образом описана (правила для системы).

Можем. есть и синтаксис и наследование концептов. И потом концепт класса Concept создает другие концепты, в частности концепт Class, который в свою очередь создает объекты. Есть и язык (даже два. один теговый, второй высокого уровня). И этот язык типа метаязык который может создавать и грамматики. Причем синтаксис остается общим.

Б>3. Концепты из п.1 (if, for, return) могли быть реализованы на основе каких-то других, более примитивных концептах, например, на концептах виртуальной машины. Те, на еще более примитивных концептах. Значит должны быть какие-то базовые концепты из которых строится все-все, а также правила их объединения.

Так куда уже примитивнее чем If Думаю их можно запрограммировать и в ассемблере или C++. Хотя у меня концепт If без секции Else. Секция Else самостоятельный концепт и включается в концепты If, Select и другие срабатывая при значении свойства Result=False
Базовых концептов 5, я их перечислил. Кроме того правила группирования здесь (т.е. объединения).


Б>4. Идея, как я понимаю, и состоит в том, чтобы придумать:

Б>- минимальный набор базовых концептов
Б>- правила объединения концептов синтаксис
Б>- правила задания значения концептов (семантика)
Б>- возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла)
Совершенно верно.

Б>В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.).

Не как угодно, но в принципе правильно.

Б>В этом случае это действительно может стать базой для любых языков программирования, для любых форматов данных. Например, мы можем реализовать концепты, соответствующие XML. Потом использовать эти концепты для построения некоторого документа XML. Выглядеть это будет именно как XML, но по сути будет объединение концептов.

Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..

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


Б>Повторюсь, это то, как я понял. Прошу меня поправить.

Очень близко все понял. На нюансах я бы не стал сейчас акцентировать.
Re[3]: Концептная парадигма
От: Буравчик Россия  
Дата: 14.11.11 12:47
Оценка:
Здравствуйте, batu, Вы писали:

Непонятно почему концепт = (размер, программа).

Что происходит с программой? Как она выполняется, т.е. каковы правила исполнения концептов? Это какая-то императивная программа (как С) или некоторое описание, по которому будет построена программа на основе других концептов (концептов стоящих внутри данного концепта, стоящих рядом, стоящих где-то в другом месте документа/программы)?

Зачем введено понятие размер?

Б>>2. Но можно также добавлять новые концепты, выражая их через другие концепты. Т.е. придумать некий DSL для описания некой предметной области. Например придумать язык описание юнит тестов. Но система должна знать как трактовать данный концепт, поэтому его семантика должна быть каким-то образом описана (правила для системы).

B>Можем. есть и синтаксис и наследование концептов. И потом концепт класса Concept создает другие концепты, в частности концепт Class, который в свою очередь создает объекты. Есть и язык (даже два. один теговый, второй высокого уровня). И этот язык типа метаязык который может создавать и грамматики. Причем синтаксис остается общим.

Про наследование концептов хотелось бы подробнее узнать.

B>Базовых концептов 5, я их перечислил. Кроме того правила группирования здесь (т.е. объединения).


Этот документ я видел. Но хочется примеров, как из базовых концептов сформировать другой концепт (что-нибудь полезное). Среди базовых концептов нет (if,for,return) — как их реализовать? кто это будет делать? каких использовать (подключать) готовые концепты? Также среди базовых нет концептов для логического программирования, функционального программирования, описания таблиц Excel и т.д. и т.п. Вопросы те же.

Б>>4. Идея, как я понимаю, и состоит в том, чтобы придумать:

Б>>- минимальный набор базовых концептов
Б>>- правила объединения концептов синтаксис
Б>>- правила задания значения концептов (семантика)
Б>>- возможно, правила взаимодействия концептов (это от себя, про это речь еще не шла)
B>Совершенно верно.

Ну вот и план описания концепции концептного программирование. Добавь введение, цели, систему вычисления и много примеров. Получится более-менее внятное описание.

Б>>В этом плате система похожа на LISP. В лиспе есть всего-лишь одна основная операция — группирование в скобки. Объединяя значения в скобки мы можем моделировать сущность любой сложности. При этом последовательные значения в скобках мы можем трактовать как угодно (как значения, как программу на языке C, как ключевые слова DSL и т.д.).

B>Не как угодно, но в принципе правильно.

Почему не как угодно?

B>Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..


Не понял про теги и теговый язык. Как это все соотносится с концептами?

B>Очень близко все понял. На нюансах я бы не стал сейчас акцентировать.


Если все правильно понял, то можно (нужно) и про нюансы.
Два самых важных вопроса:
1. Описание (идеи) системы исполнения/вычисления/интерпретации концептов
2. Для чего все это нужно? Какие проблемы удастся решить, если ВСЕ что можно будет построено с использованием концептного программирования и концептов? Здесь можно помечтать...
Best regards, Буравчик
Re[4]: Концептная парадигма
От: batu Украина  
Дата: 14.11.11 17:10
Оценка:
Здравствуйте, Буравчик, Вы писали:

Б>Непонятно почему концепт = (размер, программа).

Концепт имеет следующие обязательные свойства
Таблица 1.1. Обязательные свойства концепта.

Название Доступ Тип Назначение
Name Полный Text Имя концепта.
Class Чтение Word Класс концепта.
Parent Чтение Selector Родительский объект (объект в который вложен текущий).
Child Чтение Concept() Вложенные концепты.
Help Полный Text Справочная информация.
Result Полный Boolean Результат работы. Имеет события Error и Good

Свойство Class, Name и Parameters формируется общим синтаксисом, и доступно только для чтения. Свойство Child и Parent недоступно для изменения и формируется расположением концептов (в тексте). Свойство Child содержит вложенные концепты. Т.е. все объекты, находящиеся в реализации данного объекта за исключением присвоений свойств. Свойство Result является признаком результата выполнения объекта. Этим свойством контролируется выполнение реализаций. Кроме того реализация имеет доступ к этому свойству, и может его изменить своим функционалом. Свойство Help содержит информацию об объекте.
В случае если класс концепта порожден Concept, то вложенные концепты являются программой его реализующей. Т.е создаем концепт For. Повторяю
Концепт For будет выглядеть где-то так.

Concept For
{Property Integer Per=0 ' Переменная цикла со значением по умолчанию=0
Property Integer End ' Значение конца цикла
Per+:=1
IfElse Per<=End { Execute Else Exit Concept For }
}

При трансляции выражения
For I=1 To N {... }
Создается концепт класса For и именем I соответствующими значениями свойств концепта. В таком формате и хранится. Результат трансляции — тоже концепты.
А сам тип Integer возникает из Byte (приблизительно) так
Type Integer
{Dim Byte First
Dim Byte Second
}

Размер, а точнее количество свойств плюс правило по которому вычисляется количество байт содержащихся в концепте и позволяет выполнять манипуляции с концептом. Свопинг, загрузка, передача и т.п..
Для концептов созданых непосредственно
Плюс работа с устройствами тоже унифицируется.

Б>Что происходит с программой? Как она выполняется, т.е. каковы правила исполнения концептов? Это какая-то императивная программа (как С) или некоторое описание, по которому будет построена программа на основе других концептов (концептов стоящих внутри данного концепта, стоящих рядом, стоящих где-то в другом месте документа/программы)?

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


Б>Этот документ я видел. Но хочется примеров, как из базовых концептов сформировать другой концепт (что-нибудь полезное). Среди базовых концептов нет (if,for,return) — как их реализовать? кто это будет делать? каких использовать (подключать) готовые концепты? Также среди базовых нет концептов для логического программирования, функционального программирования, описания таблиц Excel и т.д.


Б>Ну вот и план описания концепции концептного программирование. Добавь введение, цели, систему вычисления и много примеров. Получится более-менее внятное описание.

Если б было так просто. Так и делаю, но сначала основные понятия.


B>>Не для любых форматов. Формат необходимо блюсти. Вместо XML я предложил свой теговый язык. У XML есть большой недостаток. Он меняет среду в которой работает. Так, например, первый тег должен обязательно указать шрифты и т.д.. И действие этого тега изменяет среду, до тех пор пока следующий ее не изменит еще раз. Правильнее область действия тега распространить только на самого себя. Т.е. то на что он действует должно находиться внутри тега. Но тут возникает проблема, что мы не можем оттранслировать и выполнить тег пока он полностью не закончился. В этом и хитрость и в загрузке и при выполнении, что в виртуальной машине сначала выполняются свойства, а потом вложенные теги (концепты)..


Б>Не понял про теги и теговый язык. Как это все соотносится с концептами?


Б>Если все правильно понял, то можно (нужно) и про нюансы.

Б>Два самых важных вопроса:
Б>1. Описание (идеи) системы исполнения/вычисления/интерпретации концептов
Б>2. Для чего все это нужно? Какие проблемы удастся решить, если ВСЕ что можно будет построено с использованием концептного программирования и концептов? Здесь можно помечтать...
Ну, например, реальная мультиплатформенность. Все без исключения определяется через концепты нижнего уровня.
Re[5]: Концептная парадигма
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 16.11.11 14:47
Оценка:
Здравствуйте, batu, Вы писали:

Когда я опять вижу все эти Фор, Иф, Цикл, проверки и тп
то понимаю что этот язык полностью опять улетит в говнокод.
Опять для описания чегото нужно будет 100500 циклов, 1005000100 переменных и тд
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[6]: Концептная парадигма
От: batu Украина  
Дата: 16.11.11 15:57
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


PC_>Когда я опять вижу все эти Фор, Иф, Цикл, проверки и тп

PC_>то понимаю что этот язык полностью опять улетит в говнокод.
PC_>Опять для описания чегото нужно будет 100500 циклов, 1005000100 переменных и тд
Привет! Рад видеть.
Циклы это конечно. Но вот с ифами есть и свежее.
Во первых чисто синтаксический сахар. Оператор If отдельно, а секция Else отдельно и выполняется в любом концепте если Result=False.
Во вторых оператор If (как и любой концепт) можно объединить в группу.
If
{ Х=0 {...}
X<0 {...}
X>= {...}
}
И в эту группу добавить секцию Else.
Во третьих совершенно свежий оператор Swith создающий перечислимое значение из группы операторов If.

Swith I
If
{ Х=0 {...}
X<0 {...}
X>= {...}
}

И затем (не обязательно сразу, а в другом месте текста программы) организовать переход по этой переменной на выполнение в соответствующую группу операторов
ExecuteOnSwitch S
{
{A+:=I}
{A-:=I}
{A*:=I}
Else {A:=A^3}
}
Любопытной фишкой является возможность именовать операторы. Тоже согласно общему синтаксису после имени класса концепта может стоять имя концепта. И тогда if -ы в операторе Swith можно именовать и использовать эти имена для именования группы для выполнения. Что очень удобно. Получается типа флага который может принимать несколько значений, а не только False, True. И по которому можно переходить в зависимости от его значения.

Пример именования оператора If
If "проверка на принадлежность комплекту" X=0 {...}
"проверка на принадлежность комплекту" — это имя такое.
И, самое главное. If-ы создают определенные сложности особенно если их много. Так часть If-ов можно убрать из текста используя события.
Так, например, если необходимо проверять на конец текста, можно определить событие "End Text" и избавится от этих проверок в тексте программы переложив этот контроль на процедуру обработки события.
О событиях я писал год назад.
Re[7]: Концептная парадигма
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 16.11.11 18:18
Оценка:
Здравствуйте, batu, Вы писали:

Циклы зло.
Ифы зло.
Переменные зло.

Ориентируйся на язык SQL.
Он конечно нишевый, но показывает как лаконично без багово можно описать "программку" в один запрос,
без всяких переменных циклов ифов и тд.

Вот о таком языке нужно думать.
Чтобы был на три головы выше чем все остальное.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[8]: Концептная парадигма
От: batu Украина  
Дата: 16.11.11 18:47
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


PC_>Циклы зло.

PC_>Ифы зло.
PC_>Переменные зло.

PC_>Ориентируйся на язык SQL.

PC_>Он конечно нишевый, но показывает как лаконично без багово можно описать "программку" в один запрос,
PC_>без всяких переменных циклов ифов и тд.

PC_>Вот о таком языке нужно думать.

PC_>Чтобы был на три головы выше чем все остальное.
Будешь смеяться. База данных управление и запросы получаются как часть системы. Ведь хранение концептов одна из основных задач. Там тоже есть любопытные результаты. Одним из главных результатов это то, что "иерархические базы данных" это плод нашего воображения. В природе они не существуют. иерархия возникает как результат нашего отношения к данным. Физическое расположение данных все равно линейное и не зависит от нашего отношения к ним как сейчас, и, тем более, в будущем (это я намекаю что они не нуждаются в нормализации). А так как отношений может быть много именно их и необходимо реализовывать. На практике это означает возможность строить несколько каталогов на одни и те же данные. Ярким примером является проводник. Там папки находятся одна в другой и это не имеет никакой связи с их расположением. Вполне логично иметь несколько каталогов по нашему отношению к документам. Фактически имя такого каталога это имя свойства которым документ обладает, либо это свойство появляется как наше отношение к некоторому множеству документов. А имена папок обычно значения этих свойств. Так первый вариант демонстрирует построение каталога файлов по авторству. Автор присутствует как свойство документа. А второе если будем строить каталог "любимых", "Очень любимых", "Не любимых" фильмов. Ведь в самом файле фильма нет свойства "Любимый". Это свойство появляется как наше отношение к некоторому множеству фильмов.
Re[8]: Концептная парадигма
От: batu Украина  
Дата: 16.11.11 18:49
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


PC_>Циклы зло.

PC_>Ифы зло.
PC_>Переменные зло.
Насчет переменных согласен. Это опять же в глобальном смысле. Но императивное программирование уже из истории не вычеркнешь. Да и из будущего тоже..
Re[7]: Концептная парадигма
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 16.11.11 19:35
Оценка:
Здравствуйте, batu, Вы писали:

B>Будешь смеяться. База данных управление и запросы получаются как часть системы. Ведь хранение концептов одна из основных задач. Там тоже есть любопытные результаты. Одним из главных результатов это то, что "иерархические базы данных" это плод нашего воображения. В природе они не существуют. иерархия возникает как результат нашего отношения к данным. Физическое расположение данных все равно линейное и не зависит от нашего отношения к ним как сейчас, и, тем более, в будущем (это я намекаю что они не нуждаются в нормализации). А так как отношений может быть много именно их и необходимо реализовывать. На практике это означает возможность строить несколько каталогов на одни и те же данные. Ярким примером является проводник. Там папки находятся одна в другой и это не имеет никакой связи с их расположением. Вполне логично иметь несколько каталогов по нашему отношению к документам. Фактически имя такого каталога это имя свойства которым документ обладает, либо это свойство появляется как наше отношение к некоторому множеству документов. А имена папок обычно значения этих свойств. Так первый вариант демонстрирует построение каталога файлов по авторству. Автор присутствует как свойство документа. А второе если будем строить каталог "любимых", "Очень любимых", "Не любимых" фильмов. Ведь в самом файле фильма нет свойства "Любимый". Это свойство появляется как наше отношение к некоторому множеству фильмов.


Все правильно мыслишь, я о этом тоже много думал и понял что ООП в новом языке места нет.
Также как и ты выделил для данных некоторый слой. Они лежат в твоем понимании "линейно" в моем понимании еще более абстрактно "хаотично".
И вот те кто "смотрят" на эти данные интерпретируют их по своему. Не знаю что в данном случаем ты подразумеваешь под концептом,
но в моей теории это теория послойного построения структур на основе распознавания. Тоесть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне.
Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла.
В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.

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

Так работает мышление человека, на уровне распознавания.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[9]: Концептная парадигма
От: PC_2 http://code.google.com/p/rsinterpretator/
Дата: 16.11.11 19:38
Оценка:
Здравствуйте, batu, Вы писали:

PC_>>Циклы зло.

PC_>>Ифы зло.
PC_>>Переменные зло.
B>Насчет переменных согласен. Это опять же в глобальном смысле. Но императивное программирование уже из истории не вычеркнешь. Да и из будущего тоже..

Семантика переменной это изменяемая ячейка памяти компьютера. И операции оперирования с этой ячейкой.
Тоесть это самый самый низкий уровень программирования который плотненько лежит на архитектуре.

Вместе с тем SQL или функциональное программирования уводит нас от такого понятия как "ячейка памяти"\переменная и являются намного более эффективными абстрактными моделями программирования достаточно хорошо оторванными от функционирования железа.
"Вся страна играть в футбол умеет, лишь мы 11 человек играть не умеем"(с)КВН
Re[8]: Концептная парадигма
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.11.11 19:57
Оценка:
Здравствуйте, PC_2, Вы писали:

PC_>Здравствуйте, batu, Вы писали:


PC_>но в моей теории это теория послойного построения структур на основе распознавания. Тоесть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне.

PC_>Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла.
PC_>В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.
Автор теории за год так и не прикинул, сколько углов даст 1000 точек?

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


PC_>Так работает мышление человека, на уровне распознавания.

Не обобщай. Не все мыслят брутфорсом.
Re: Концептная парадигма
От: 0x7be СССР  
Дата: 16.11.11 20:10
Оценка:
Здравствуйте, batu, Вы писали:

B>Всем спасибо!

Несколько отвлеченный вопрос, но, я думаю, это будет полезно для понимания. Решение какой практической задачи привело к созданию это парадигмы? То есть от какой реальной проблемы мысль полетела
Re[8]: Концептная парадигма
От: batu Украина  
Дата: 16.11.11 20:13
Оценка:
Здравствуйте, PC_2, Вы писали:


PC_>Все правильно мыслишь, я о этом тоже много думал и понял что ООП в новом языке места нет.

Ну, почему нет? Ноги по любому растут оттуда. А недостатков меньше. Хотя не без них.
PC_>Также как и ты выделил для данных некоторый слой. Они лежат в твоем понимании "линейно" в моем понимании еще более абстрактно "хаотично".
PC_>И вот те кто "смотрят" на эти данные интерпретируют их по своему. Не знаю что в данном случаем ты подразумеваешь под концептом,
Размер, свойства и программу его реализующую. Кроме того, логическое определение. Высказывание. Как в Прологе.
PC_>но в моей теории это теория послойного построения структур на основе распознавания. То есть слой за слоем структурируется информация, в зависимости от наложеных "понятий" на этом уровне.
PC_>Самый простой пример это пример с фигурами. Определяется понятие точки, которая любые два числа распознает как координаты. Отрезки распознают себя там где есть две точки. Углы там где есть три точки. Прямые углы там где есть три точки и определенное соотношение. Прямоугольники там где есть четыре угла.
1. Не любые две точки есть координаты. Нужно еще что-то однозначно определяющее с чем имеем дело. У меня это программа и высказывание.
2. "Уровни" это настолько мутное понятие если в реальности говорить об уровнях можно только в случае наследования или наличия в составе. А в реальности уровней нет. Все в перемешку.
PC_>В отличии от зашореной ООП вылитой в граните, здесь структура намного более гибкая. Она может расходится и сходится на уровнях, анализируя что на каждом этапе появляется.
Ну, да..Я ж и говорю что "уровни" понятие весьма абстрактное. А вот "гранитность" ООП легко разбавить динамическим доопределением свойств и методов но только при непосредственном создании из класса. Более глубокое наследование (не от классов а от данных как в прототипных языках) делает систему не надежной и тормознутой.

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

Почему как координаты? А почему не другой тип? И что такое числа? Целое и вещественное это разные типы хотя и числа.
PC_>Так работает мышление человека, на уровне распознавания.
Мышление у человеков по разному работает. Даже в одной индоевропейской группе англичанин, немец и русский думают по разному. Не говоря уже про китайцев. Есть еще языки объектной группы. Основные на планете. Но, представь, есть племена индейцы разговаривают не на объектном языке. Потому так нет привычных отношений типа вчера-завтра и т.п. они мыслят совсем по другому
Re[10]: Концептная парадигма
От: batu Украина  
Дата: 16.11.11 20:22
Оценка:
Здравствуйте, PC_2, Вы писали:


PC_>Семантика переменной это изменяемая ячейка памяти компьютера. И операции оперирования с этой ячейкой.

PC_>Тоесть это самый самый низкий уровень программирования который плотненько лежит на архитектуре.

PC_>Вместе с тем SQL или функциональное программирования уводит нас от такого понятия как "ячейка памяти"\переменная и являются намного более эффективными абстрактными моделями программирования достаточно хорошо оторванными от функционирования железа.

Я знаком с функциональным программированием еще по Lisp. В парадигме все красиво. И вопрос даже не в эффективности как с Прологом Хотя тоже прекрасная парадигма. А как раз в том что трудно мыслить такими категориями и переложить чисто в функциональную парадигму. Как раз в тему предыдущего поста. Людям так трудно думать.
Есть еще одна красивая парадигма-"машины управляемые потоками данных". Т.е. там для выполнения поступают не команды, а данные. Очень мощная парадигма для параллельной обработки, и весьма близко к тому как происходит в реальности. Однако запрограммировать такую машину человеку не человечески трудно. Кстати, мое предложение механизма событий решает эту проблему. Т.е. события происходят как угодно, а процедуры обработки пишутся линейно.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.