Pull to refresh
4
0
Send message

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

неплохо так закопались, спасибо )

Имеется в виду, что персонажи в файтинге обладают различными уникальными способностями и фишками? Это другое измерение для вовлеченности, это разнообразие выбора с выбором для себя подходящих предпочтений и легенды, если персонажи как в Smash имеют свой story и все это в пределах общего баланса силы.

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

да, в комментарии этом неточность есть. Слово «обратную» лишнее здесь.
Добавить метод find нетрудно, тогда
// Keep a reference to the current node, 'fox',
// and to the previous node in the list. Indicate the 'dog' node.
mark1 = current;
LinkedListNode<string> mark2 = current.Previous;
current = sentence.Find("dog");
IndicateNode(current, "Test 9: Indicate the 'dog' node:");

будет в Hi выглядеть примерно так:
mark1 = sentence.current
LET mark2 = sentence.prev
sentence.find "dog"
PRINT "Test 9: Indicate the 'dog' node:", sentence.current
Linked list в этой статье делает то же, что пример для С# (кстати, согласен — хороший), только еще проще, например фрагмент:
// Move the last node to be the first node.
        mark1 = sentence.Last;
        sentence.RemoveLast();
        sentence.AddFirst(mark1);
        Display(sentence, "Test 4: Move last node to be first node:");

в синтаксисе Hi выглядит так:
sentence.last
LET last = sentence.remove
sentence.insertFirst last
PRINT "Test 4: Move last node to be first node:"

Можно саму трансформацию выразить и одной строкой:
sentence.insertFirst (sentence.last.remove)  


пример про мем — это не список, это очередь

Ладно, продолжим кружок занимательной информатики.
По очередью обычно понимают однонаправленный список (т.е. частный случай), но советская очередь это всё-таки связный список. Об этом говорят типичные фразы:
«Кто последний?» list.last
«А кто перед вами?» list.prev # очередь в информатике не имеет ссылок на пред. элементы
«Я пойду, перед мной вот эта женщина» list.remove
«Я занимала за этим мужчиной!» list.insert aWomen
«Вас здесь не видели!» IF list.current == NIL THEN…
Поясню: для всего списка существуют действия «создать», «очистить», «найти голову/хвост», «изменить указатель на текущий элемент», «изменить текущий элемент», «добавить/удалить элемент».
А элементом списка является структура из данных и двух указателей. Для элемента имеют смысл действия «получить следующий/предыдущий элемент», «изменить данные»

У вас «изменить указатель на текущий элемент» для списка пересекается по смыслу «получить следующий/предыдущий элемент» для элемента. Это же будет уже другой элемент. Аналогично для действия «изменить элемент». Получилась каша в смыслах. Попробуйте рядом с моим API выписать ваши многосложные варианты с разделением для «списков» и «элементов».
Правильные названия — одна из ключевых проблем в программировании.

Разумнее заменить слово «правильные» на «целесообразные», тогда будет корректно. Не бывает априорно «правильных» решений. Следуя вашей логике «правильного» смыслового именования следует каждый раз задумываться как именовать счетчик в циклах вида for i =…

Некоторые военные историки не без оснований считают, что в военных действиях имеет преимущество та сторона, чей язык короче. С другой стороны еще дедушка мог бы рассказать, что логику linked list хорошо знали и использовали в Советском союзе, где был даже соответствующий мем: «Следующий [list.next] — кричит заведующий [owner]».
В таком виде IMO cкорее усложняет прочтение, чем делает яснее.

Использование Goto сразу оживляет призрак Дейкстры (не путать с Дийкстра из Ведьмака) с топором в руках
А иначе, увы, не скажешь.

А вот сформулировали же по другому :-)

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

Поживем, увидим. В любом случае это интересно делать.

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

Впрочем, не всегда водопадный подход работает хорошо даже для крупных проектов. Например, разработка игр. Дело в том, что нельзя создать заведомо качественный BRD для инновационной игры, потому что слишком много неизвестного. Здесь целесообразна итерационная разработка и эксперименты с прототипами. Иногда в процессе создания игры полностью меняется исходный концепт и почти всегда он частично трансформируется. Иногда приходится досрочно завершать разработку, потому что исходные гипотезы не подтверждаются. В книгах по гейм-дизайну, это детальнее описано, например The Art of Game Design: A Book of Lenses (книга вроде есть в русском переводе).

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

несколько портит впечатление.
Это как раз не беспокоит. Говоря метафорами, наша будущая цель не дать вместо совка лопату [для промышленного использования], а предоставить робота с лопатой. И более интересует, чтобы робот не воткнул лопату в электрический кабель.
… не надо в язык пихать сущностей сверх необходимого («бритва Оккама»). Посмотрите на тот же С++ — есть сам язык, содержащий минимальный набор типов и инструкций и есть библиотеки.

Диалектика для «бритвы Оккама» здесь в том, что сам C++ в том числе с помощью механизма множественного наследования является почти идеальным генератором сущностей и без особой необходимости продуманности в том числе.
почему бы для обозначения действий не использовать глаголы?

Ак как вы предлагаете именовать, допустим, list.next?
Язык, который мы используем определяет характер нашего мышления. Эффективный язык должен доносить сообщение адресату с минимумом затрат на формирование самого сообщения.

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

Как пример полезной эволюции языка. В ранних версиях Swift не было встроенной поддержки генерации рандомных чисел. Приходилось или подключать свою оболочку, или GameplayKit или использовать в коде довольно тяжеловесные конструкции c конверсией типов из UInt32 вида:
let n = Int(arc4random_uniform(11)) // не все в начале знают, что здесь диапазон генерации от 0 до 10

В версии 4.2 появилась встроенная поддержка:
let n = Int.random(in: 0…10)

Стало логично и гораздо удобнее. Язык вроде как усложнился, а программисту стало проще.

Причина экспериментов с linked list здесь на самом деле другая. Язык Hi конструируется с прицелом на гораздо более широкое применение в будущем, чем просто быстро программировать несложные задачи для начинающих в алгоритмическом стиле с дружелюбным environment.

Чтобы нам спроектировать будущий язык целесообразно [и попутно выполнить декларацию полной выполнимости исходного текстового кода в будущем], нужно пытаться на существующем языке реализовать сложные концепции, для которых он пока еще не предназначен. На примере linked list и еще некоторых примерах стало понятно, что c optionals лучше работать, чем их не иметь в языке даже в базовой версии. Соответственно теперь задача так их интегрировать в выразительные средства, чтобы было логично, просто, надежно. Работа с optionals требует продумывания обработки ситуаций с nil и т.д.

Концептуально создавать простой и понятный, функционально удобный язык очень непросто. Это означает, что в значительной мере сложность задач уходит от программиста к дизайнеру языка.
По просьбе читателей в дополнение к основной статье уточним некоторые детали исходно шуточной идеи концепта реализации linked list.

Связный список может содержать элементы одного типа или разных типов.
Объявление списка с инициацией можно делать через присвоение начальных значений с заданным сетом элементов.
VAR stringList = <”α”, “β”, “γ”>
VAR aList = <“β”, 1, 3.14>

# Вывод типа здесь осуществляется автоматически.

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

Рассмотрим их на примере. Допустим мы хотим создать свой список чтения интересных постов и статей по программированию. Так как мы имеем только одну голову, то есть можем читать в один конкретный момент времени только один элемент, определим некоторый порядок чтения, одно за другим. Обычно новые статьи мы помещаем в конец списка, впрочем, при появлении интересной работы по нашим тегам мы можем поместить её, допустим, ближе к началу списка. Прочитанные статьи, в том числе и из середины списка удаляем. Так как в мире сейчас писателей больше, чем читателей, то наш список может быть о-очень большим.
Создаем начальный список с самой интересной работы:
VAR list = <"Hi Programming Language”>

В первую очередь нам нужны методы по добавлению (insert) и удалению (remove) узлов.
list.insert "Hi Programming Language: начинаем конструировать"
list.insert "Computing Machinery and Intelligence"

# Можем добавить в список сразу несколько элементов:
list.insert «SICP для занятых», «Как я научился программировать в 90 лет»

Стоп. Последний пост нас не интересует, удалим его.
list.remove # удаляет последний добавленный элемент

То есть наша реализация списка всегда имеет встроенный указатель на текущий, активный узел. Похожим образом в итерационных циклах мы имеем активный элемент node в конструкциях с итератором вида:
for node in array {

}

Логика работы insert и remove описана в основной статье.

В любой момент времени для не пустого списка мы может получить как сам объект, так и ссылку на него для быстрого доступа.
LET sicp = list.current
LET sicpMark = list.link

Ссылку мы можем использовать позднее, когда после добавления, удаления, перемещения элементов списка, решим вернуться к узлу. Разумеется, ссылка на ранее удаленный элемент списка не приводит к run time error, а переводит list.current в NIL.

Количество таких ссылок неограниченно, мы можем сделать что-то вроде мета-списка избранного чтения, допустим 100 лучших статей из нашего списка, включив линки, например, в линейный массив.
Если нам нужно заменить один элемент на другой, то мы делаем это как с property экземпляра класса в некоторых языках:
list.current = “Новый комментарий в habr”

Встроенные методы для linked list включают следующие команды (прям как в музыкальном плейере):
list.first # мгновенно перемещаемся на первый элемент списка
list.next # идем к следующему элементу цепочки
list.prev # возращаемся обратно к предыдущему элементу цепочки
list.last # мгновенно перемещаемся на последний элемент списка
list.go sicpMark # а это переходим к нашей ранее сохраненной закладке

Важное уточнение. Все команды выше могут использоваться как процедуры и как функции, возвращая релевантный элемент списка, например так:
LET firstArticle = list.first
LET removed = list.remove

Это как на книжной полке, мы не просто перебираем корешки книг, но сразу получаем в руки каждую из них. Если не нужна – ищем дальше, нужна – убираем с полки и кладем в карман.

В принципе, ничего не мешает нам также сделать что-то вроде словаря из отдельных tuple:
LET (value, key) = (list.insert, list.link)

Information

Rating
Does not participate
Registered
Activity