От мутного к четкому. История про лунный модуль

А мне и не надо разбираться в работе компьютера на аппаратном и программном уровне. Потребительство на стероидах; что тут сказать.

А у меня был подобный агрегат. Занимал 2/3 кузова “Урала” (остальное - дизель-агрегат). Считал топографию.

И да, позже подобный “объектный” интерфейс действительно использовался:

Picture’s worth a thousand words. Писал я подобные программы на заре своей трудовой деятельности. Компьютер был размером с книгу и точно такая же принципиальная компоновка пользовательского интерфейса.
Сейчас это уже делается голосом: Алиса, включи музыку.

Зы: статья хорошая, утащу потом.

2 лайка

Это называется “Мурзилка”.

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

В целом вы верно мыслите, вот две категории и характеристики каждой из них. Меня тут как-то спросили про Мысль и речь. Что влияет на что, эта статья логическое продолжение той. Классификация глаголов – родилась в лингвистическом исследовании. У меня есть гипотеза, что понимание что делать и как делать, наступает в момент когда в сформулированной задаче отсутствует необходимость дополнительно интерпретации.


Описательные глаголы действия (DAV)

  • Указание на объект и ситуацию, один конкретный вид деятельности и физический инвариантный признак действия.
  • Действие имеет четкое начало и конец. Нет положительной или отрицательной семантической валентности.
  • Контекст необходим.
  • Объективное описание события.

Позвонить, встретить, пнуть, поцеловать

Интерпретирующие глаголы действия (IAV)

  • Ссылка на объект и ситуацию, один конкретный вид деятельности и физический инвариантный признак действия.
  • Автономное понимание предложения. Контекст не имеет значения.
  • Интерпретирует действие за пределами описания. Имеет несколько объяснений.
  • Общий класс поведения.
  • Имеет определенное действие с началом и концом.
  • Имеет положительную и отрицательную семантическую валентность.

Обмануть, подражать, помочь, сдерживать

1 лайк

Спасибо! Хорошая теоретическая подводочка к правилам для применения на практике.

Например, “формулировать название задачи глаголом”, что автоматически помогает автору сформулировать задачу конкретно и понятно для исполнителя (в отличие от случая, когда название задачи написано существительным и вызывает вопрос “а делать-то что?”).

Я давно подозревал о важности этого, а после марафона Дорофеева по джедайским техникам стал делать только так.

Да много каких игр для программируемой Электроники там было) Даже ферма была)

В правилах программирования есть требование формулировать название функции или метода глаголом

1 лайк

С удовольствием почитал обсуждение. Мысли…
У меня буквально вчера был кейс когда супруга предложила посмотреть обсуждение 3х девочек, одна из них психолог, обсуждали девиации в сексе и “здоровые” отношения.

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

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

По поводу глаголов и не глаголов. Меня в школе учительница учила что при конспекте если не успеваешь нужно записывать глаголы. Потому что по ним можно основной смысл восстановить. Я пробовал и существительные и прилагательные и глаголы. Да действительно по глаголам можно понять что именно происходит.

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

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

Существительное показывает с какими сущностями мы работаем. Имея глагол но не имея существительное мы будем в состоянии менять пространство но не будем знать к чему прикладывать усилия. Отсутствует точка приложения изменения.
что меняем? местоположение шатла (посадить шатл)

Прилагательное показывает качество, характеристику. Без него можно обойтись иногда, но оно уточняет очень сильно.
какой? как? посадить шатл 15 со скоростью 17

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

2 лайка

Просто оставлю это здесь. “Коды операций”, которые тут обсуждают:

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#/media/File:Agc_verb-noun-list.jpg

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

Я думаю тут особенность в том что если у нас есть несколько простых тривиальных задач, то конечно их проще закодить конкретной кнопкой.

Проблема начинается тогда когда нужна вариативность.

Если есть 3 сущности которые могут быть или активны или неактивны ок работает. А если у нас 150 элементов и каждый может иметь 3-4 статуса. На такое кнопок не напасешься.

Это вопрос инженерии. Например, в старой игрушке BattleZone, команда вводилась тремя цифрами: номер группы (нападение, оборона, строительство), номер танка, действие (цель действия, все-таки, обычно указывалась мышкой, впрочем, мышкой можно было заменить и указание номера танка). Но когда, во второй версии игры, такой ввод стал мешать сюжету, ввели объединения танков не по группам, а по сценарию. Впрочем, “оцифровывать” логику поведения можно самыми разными способами Блог старого нелюбителя X-COM .

Спасибо за заметку, в очередной раз приходит понимание, что формулировки важны как никогда. (На эту тему даже анектдот был о важности правильного использования предлогов с глаголами).
Единственное, что хотелось бы уточнить, это влияние формулировки на последующие действия. У меня был небольшой опыт обучения молодежи на работе и в ходе этого опыта я столкнулся с проблемой формулировок у них. Часто молодежь впадала в ступор действия, т.к. могла сформулировать только предположение о том, что делать дальше. Хотя для дальнейших действий нужна гипотеза.
В итоге для себя пришел к разделению формулировок на:

  • предположения;
  • гипотезы;
  • решения.

Предположение определяет ожидание результата в конкретной области ( Если я заговорю с этой девушкой о литературе, то выйдет интересная беседа).

Гипотеза содержит критерии проверки предположения. В контексте примера это ответы на вопросы:

  1. А что для меня значит интересная беседа?
  2. Почему я решил, что беседа выйдет интересной?/Почему я решил что с этой девушкой беседа о литературе будет интересная?

Решение - выражение построеное по принципу “Я буду делать А, чтобы получить Б, потому что В” (Я пойду разговаривать с этой девушкой о литературе, т.к. мне нравится девушка и я что-то понимаю в литературе)

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

Так как раз в этом и смысл. Что мы зашиваем не конкретную комманду, а многомерную логику. Иначе бы пришлось на каждое действие каждого танка вешать кнопку.
То что есть особенности исходя из задач да, тут я согласен. Но принципы то остаются все равно примерно те же. Я думаю Рустам больше про принципы говорил, нежели про конкретную реализацию.

А можно подробнее чем гипотеза от предположения отличается в вашем случае? Для меня это одно и то же, поэтому и спросил. Вики тоже выдает гипотезу как предположение.

1 лайк

И условия вселенной этой игры это позволяли. И большинство частных инженерных/программных решений - тоже. В английском языке все еще проще - достаточно всего 18 глаголов.

Для меня разница вот в чем.
Предположение - это размышление про ожидаемый реузльтат (… выйдет интересная беседа), не содержащее критериев проверки и опредления результата. Предположение проверить не получится, требуется куча уточнений, на которых обычно буксуют размышления.
Гипотеза - это предположение + определение результата+ критерии проверки. Т.е. предположение это только часть гипотезы, помогающая определить, где мы будем гипотезу проверять.(Заговорю с этой девушкой о литературе).

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

Сегодня возникла гипотеза, что в понимании картины мира могут быть два состояния - полная ясность или полная муть. «Туман войны» - очень хороший стандартный термин для описания всего того, что человек, принимающий решения, не знает о противнике. Таким образом коммуникация может быть направлена на изменение позиции другого человека — прояснение его понимания или его затуманивание.

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

С ясностью понятно, но какая польза от тумана войны? Или я не вижу или не понимаю. :