Совершенно верно, программист транслирует естественное (для человека) описание ситуаций в неестественное — многоуровневое вложение условий. Это и отличает программиста от человека. Хотя отличие не только в этом. Отличие еще в том, что программист способен удерживать внимание на большем количестве объектов, чем непрограммист. Я решил задачу Эйнштейна за 40 минут, без ручки и бумаги, только в уме, не читая алгоритм нахождения ответа, и про сам ответ. Считаю, что на это способен любой программист с опытом. Чего не скажешь про непрограммистов.
Понятие «событийный адрес» не нужно.
Человек описывает системе ситуацию через набор триггеров:
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Система сама ищет обработчик этой ситуации. Если его нет — создает.
Событие это один триггер, как и состояние это один триггер.
Ситуация (условие) это совокупность триггеров (и вложенных ситуаций). Т.е. ситуации (условия) иерархичны. Вложение одних условий в другие пока не реализовано, но оно необходимо.
Ситуация в понимании человека = условие в интерпретаторе.
Тогда весь поток управления — не более чем рекоммендуемая последовательность проверок, которую можно заменить на систему приоритетов.
Можно и так сказать.
Если из двух обработчиков первый изменяет значение переменной, а второй только читает ее значение, то второй обработчик должен выполняться первым, а первый вторым. Главное, что условия и циклы берет на себя интерпретатор, и человеку не нужно задумываться о связях между разными обработчиками. Но для этого интерпретатор должен просмотреть все строки кода и построить зависимости.
предлагаю термин широкое программирование(wide programming)
я бы сказал (и в шутку и в серьез) что это естественное программирование, поскольку естественный язык (ну хорошо, близкий к нему, пока что) это естественно для человека. А объяснение поведения через описание ситуции, в которой это поведение применимо, естественно для человека не менее, чем естественный язык, на котором оно объясняется.
При программировании человек описывает реакции на входные данные, а не на ситуацию
Это при классическом программировании, не при ситуационном (естественном для человека).
поскольку все ситуации уникальные и все их просто невозможно перечислить
В программе программист пытается описать все ситуации, иначе кому нужна программа, которая не обрабатывает часть из возможных ситуаций. Обычно в таких неописанных ситуациях программа ведет себя непредсказуемо или вообще падает в дапм (корку). Разве это хорошо?
Число ситуаций всегда конечно. Особенно, если вести модульность ситуаций. Разбивать их на уровни абстракции.
Когда правила формулирует система в результате диалога с человеком, это какая-то далёкая фантастика, в стиле «ты тут сам подумай, разберись и сделай, чтобы все мои пожелания были учтены».
Ничто не заставляет задуматься об этом уже сейчас, хотя описанные подходы строго говоря совсем о другом.
Для этого и нужен естественный язык. Набор входных условий описывает на нем человек:
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
После чего он указывает набор инструкций для выполнения в этой ситуации.
Вот как раз как разработчик я очень хорошо знаю, что в любой сколь-либо сложной системе изменение может проявиться не сразу, и неочевидным образом. Иными словами, чем сложнее система, тем, при прочих равных, вероятнее в ней эффект бабочки.
Потому то и надо к программированию сложных систем подходить с точки зрения ситуаций.
Вы сейчас говорите о программировании в классическом понимании, когда тестировщик понятия не имеет, что вы исправили в коде, а если и имеет, то поверхностное.
А давайте отойдем от модели обучения с учителем и предположим, что все программы будут создаваться на основе ситуационного подхода. Вы, как программист, изменивший набор ситуаций (условий) можете предоставить список этих условий тестировщику. Если он все их протестирует, то откуда возникнет эффект бабочки?
Хотя, в некоторой степени вы конечно правы, и ошибка может возникнуть всегда, но ситуационный подход сильно уменьшает ее возникновение, это же очевидно.
Процитирую то, что уже писал выше, может быть на этот раз вы прочтете все.
«Это тема для отдельной статьи, пожалуй. Но если кратко, то у триггеров, из которых состоят условия будут символические имена, даже не имена, а конструкции, выражаемые предложением. Поиск процедуры, код которой нужно править будет выполнятся ассоциативно, на основе набора символических имен.
Например, мы хотим запросить (и изменить ее код) у системы процедуру, которая вызывается в ситуции (из примера на видео), когда (в этой ситуации нужно будет изменить направление движения змейки):
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Можно описать эти символические имена на языке с валентностями и передать системе, на что она должна ассоциативно найти процедуру и вернуть ее текст для правки. Если процедура для такой ситуации не предусмотрена, она будет создана, попутно будут созданы необходимые условия. Это может позволить автоматически давать имена (технические) переменным в коде, триггерам, условиям, процедурам. Т.е. человек возможно не будет оперировать объектами кода в привычном понимании. Отвечать на вопросы я пока не готов. Реализация этого всего дело не близкого будущего, да и к текущей теме не относится.»
Что важнее — как определить, что изменится, когда он внесет свои изменения?
Всякое изменение само стремится себя проявить, вам ли, как разработчику, этого и не знать.
Могли бы выключить функцию тролля на время и объяснить человеку. Вы уже знаете больше, чем кто либо другой по теме.
«Двигатель запущен» — это одновременно событие и состояние
если правильно понял, то именно это и понимает автор под событиями
Это событие. А «двигатель работает» это состояние. Все зависит от того, что важно для системы, то что двигатель был запущен, или то, что он работает именно сейчас.
Во время обсуждения прошлой статьи с ув. lair стало понятно, что кроме событий есть еще и состояния. Оба эти термина объедены в понятие триггер. Он имеет 2 устойчивых состояния: активирован и деактивирован. Триггер состояния может быть активным долгое время, триггер события деактивируется после вызова его обработчика. Несколько триггеров могут быть объединены в условие, которое активируется тогда, когда все его триггеры активированы.
Это известно. Функции общения с ядром для мультипоточных приложений в Windows. Но кто будет арбитром при одновременном возникновении нескольких ситуаций, обработчик одной из которых должен выполняться строго после обработчика другой? Для этого нужно анализировать код и выдавать всем обработчикам приоритеты. Ядро этим заниматься не будет, это дело интерпретатора/компилятора.
Я не против "=", как и не против PHP. Но он не обладает свойством коммуникативности. Задача была не избавиться от императивности, а скорее наоборот, сохранить ее и добавить к ней коммуникативности. Чтобы язык и выполняться мог и информацию переносить.
После добавления флага для запрещения срабатывания триггеров внутри триггеров
Должно быть так:
INIT[10:10] — определяем игровое поле для змейки 10х10 клеток
SET[A1] SET[A2] SET[A3] — Устанавливаем «звездочку» в ячейки A1, A2, A3
REFR[] — обновление содержимого экрана
CLR[A1] — удаляем «звездочку» из ячейки A1
SET[A4] — устанавливаем звездочку в ячейку А4
REFR[] — обновление содержимого экрана
CLR[A2] — удаляем «звездочку» из ячейки A2
SET[A5] — устанавливаем звездочку в ячейку А5
REFR[] — обновление содержимого экрана
CLR[A3] — удаляем «звездочку» из ячейки A3
SET[A6] — устанавливаем звездочку в ячейку А6
REFR[] — обновление содержимого экрана
и т.д. пока змейка не дойдет до грани поля
Эти комманды записываются в пайп, из которого читает другая программа-терминал, отображающая эти команды как бегающую змейку.
У вас порядок инструкций попутался т.к. некоторые триггеры и условия могут активироваться одновременно, но их обработчики не всегда могут вызываться в произвольном порядке, тут есть правила, которые я уже выявил. Таким образом, обработчикам, присваиваются приоритеты, чтобы в спорном случае интерпретатор знал, какой обработчик нужно вызывать первым. В коде из примера приоритеты заданы явно инструкцией «устанавливать? что приоритет (? чего X,? какой Y).» Хотя в реальной работе они будут рассчитываться интерпертатором (сейчас я по установленному алгоритму определяю приоритеты расчетами в экселе)
Внос изменений будет таким же сложным, как обычное программирование. Сначала человек месяцы это читает и отмечает, где что расписано.
Как раз делается попытка ухода от этого. В коде не нужно будет разбираться. Человек работает с одной, конкретной ситуацией, поведение, при возникновении которой, он хотел бы изменить.
В ваших словах есть доля правды, если вы читали прошлую статью и осознали плюсы ее подхода. Для этого и разрабатывается интерпретатор, чтобы подтвердить, или опровергнуть.
В принципе, ситуационное программирование интересно само по себе, чего не скажешь про программирование на естественном языке. Но в паре они могут позволить выполнять программирование (изменение поведения) объяснением, без оперирования объектами кода. Подчеркиваю, не позволят, а могут позволить. Это предмет исследования.
Ну тут тоже можно ничего не объясняя показать много сыгранных партий(в удобной компьютеру форме). Причем можно даже не объяснять кто выиграл, тогда просто будет обучение одновременно паре игр(шашки/поддавки).
Это проблема обучения без учителя, обучения наблюдением. И эта задача из области СИИ (сильного ИИ), а не ИИ, она затрагивает умение естественного интеллекта к ассоциативной классиикации. Причем к классификации всего и вся. Для этого нужно выявить принципы работы такого умения, а они насколько я знаю пока неизвестны (именно универсальный классификатор всего и вся).
Например, во всех играх есть игроки, их может быть определенное количество. Они могут играть разные роли. В игре могут быть вспомогательные объекты (доска, фишки, фигуры, карты, кубики). Игроки в определенной последовательности что-то делают. Делают с объектами (кидают кубик) или без объектов (загадывают число, говорят что-то другим игрокам).
В каждой игре должна быть какая-то целевая функция, возможные окончания (выигрыш, проигрыш, ничья) или промежуточные этапы.
Человек описывает системе ситуацию через набор триггеров:
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Система сама ищет обработчик этой ситуации. Если его нет — создает.
Событие это один триггер, как и состояние это один триггер.
Ситуация (условие) это совокупность триггеров (и вложенных ситуаций). Т.е. ситуации (условия) иерархичны. Вложение одних условий в другие пока не реализовано, но оно необходимо.
Ситуация в понимании человека = условие в интерпретаторе.
Если из двух обработчиков первый изменяет значение переменной, а второй только читает ее значение, то второй обработчик должен выполняться первым, а первый вторым. Главное, что условия и циклы берет на себя интерпретатор, и человеку не нужно задумываться о связях между разными обработчиками. Но для этого интерпретатор должен просмотреть все строки кода и построить зависимости.
В программе программист пытается описать все ситуации, иначе кому нужна программа, которая не обрабатывает часть из возможных ситуаций. Обычно в таких неописанных ситуациях программа ведет себя непредсказуемо или вообще падает в дапм (корку). Разве это хорошо?
Число ситуаций всегда конечно. Особенно, если вести модульность ситуаций. Разбивать их на уровни абстракции.
Ничто не заставляет задуматься об этом уже сейчас, хотя описанные подходы строго говоря совсем о другом.
Списком из чего?
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
После чего он указывает набор инструкций для выполнения в этой ситуации.
Потому то и надо к программированию сложных систем подходить с точки зрения ситуаций.
Вы сейчас говорите о программировании в классическом понимании, когда тестировщик понятия не имеет, что вы исправили в коде, а если и имеет, то поверхностное.
А давайте отойдем от модели обучения с учителем и предположим, что все программы будут создаваться на основе ситуационного подхода. Вы, как программист, изменивший набор ситуаций (условий) можете предоставить список этих условий тестировщику. Если он все их протестирует, то откуда возникнет эффект бабочки?
Хотя, в некоторой степени вы конечно правы, и ошибка может возникнуть всегда, но ситуационный подход сильно уменьшает ее возникновение, это же очевидно.
«Это тема для отдельной статьи, пожалуй. Но если кратко, то у триггеров, из которых состоят условия будут символические имена, даже не имена, а конструкции, выражаемые предложением. Поиск процедуры, код которой нужно править будет выполнятся ассоциативно, на основе набора символических имен.
Например, мы хотим запросить (и изменить ее код) у системы процедуру, которая вызывается в ситуции (из примера на видео), когда (в этой ситуации нужно будет изменить направление движения змейки):
1. Текущая секция змейки является головой
2. Направление движения змейки — вниз
3. Голова змейки находится в самой нижней клетке поля
Можно описать эти символические имена на языке с валентностями и передать системе, на что она должна ассоциативно найти процедуру и вернуть ее текст для правки. Если процедура для такой ситуации не предусмотрена, она будет создана, попутно будут созданы необходимые условия. Это может позволить автоматически давать имена (технические) переменным в коде, триггерам, условиям, процедурам. Т.е. человек возможно не будет оперировать объектами кода в привычном понимании. Отвечать на вопросы я пока не готов. Реализация этого всего дело не близкого будущего, да и к текущей теме не относится.»
Всякое изменение само стремится себя проявить, вам ли, как разработчику, этого и не знать.
Что по вашему мнению я должен использовать вместо всего этого?
Это событие. А «двигатель работает» это состояние. Все зависит от того, что важно для системы, то что двигатель был запущен, или то, что он работает именно сейчас.
Во время обсуждения прошлой статьи с ув. lair стало понятно, что кроме событий есть еще и состояния. Оба эти термина объедены в понятие триггер. Он имеет 2 устойчивых состояния: активирован и деактивирован. Триггер состояния может быть активным долгое время, триггер события деактивируется после вызова его обработчика. Несколько триггеров могут быть объединены в условие, которое активируется тогда, когда все его триггеры активированы.
Это вы правильно сделали.
Должно быть так:
INIT[10:10] — определяем игровое поле для змейки 10х10 клеток
SET[A1] SET[A2] SET[A3] — Устанавливаем «звездочку» в ячейки A1, A2, A3
REFR[] — обновление содержимого экрана
CLR[A1] — удаляем «звездочку» из ячейки A1
SET[A4] — устанавливаем звездочку в ячейку А4
REFR[] — обновление содержимого экрана
CLR[A2] — удаляем «звездочку» из ячейки A2
SET[A5] — устанавливаем звездочку в ячейку А5
REFR[] — обновление содержимого экрана
CLR[A3] — удаляем «звездочку» из ячейки A3
SET[A6] — устанавливаем звездочку в ячейку А6
REFR[] — обновление содержимого экрана
и т.д. пока змейка не дойдет до грани поля
Эти комманды записываются в пайп, из которого читает другая программа-терминал, отображающая эти команды как бегающую змейку.
У вас порядок инструкций попутался т.к. некоторые триггеры и условия могут активироваться одновременно, но их обработчики не всегда могут вызываться в произвольном порядке, тут есть правила, которые я уже выявил. Таким образом, обработчикам, присваиваются приоритеты, чтобы в спорном случае интерпретатор знал, какой обработчик нужно вызывать первым. В коде из примера приоритеты заданы явно инструкцией «устанавливать? что приоритет (? чего X,? какой Y).» Хотя в реальной работе они будут рассчитываться интерпертатором (сейчас я по установленному алгоритму определяю приоритеты расчетами в экселе)
В принципе, ситуационное программирование интересно само по себе, чего не скажешь про программирование на естественном языке. Но в паре они могут позволить выполнять программирование (изменение поведения) объяснением, без оперирования объектами кода. Подчеркиваю, не позволят, а могут позволить. Это предмет исследования.