Pull to refresh

Comments 104

Что имеется в виду под "Нарушение привычного синтаксического порядка"?
Если порядок как он должен быть в англ. языке, то я часто отхожу от этого порядка ради более быстрого поиска функций в autocomplete.
Например пишите вы:


let job = new Cr...

… и начинаете искать среди кучи сущностей Order, Post, User свой CreateOrderJob
А можно просто написать:


let job = new Or...

… и сразу будет доступен список действий для сущности Order и в частности OrderCreateJob, что гораздо удобнее и быстрее, хотя да, по правилам английского языка — неверно.
Ну и в файловой системе всё будет сгруппировано по сущностям.

Это Вы.
А я потом читаю Ваш код, натыкаюсь на это — и зависаю.
Думая — «Счет создает работу… угу… Ну вот как это???»
Вы сами объяснили, что вам это удобно именно с точки зрения автодополнения. Такая точка зрения тоже уместна, но рассматривается именно удобство чтения.
Кроме того, у меня автодополнение по слову Order выдаст в том числе и CreateOrderJob. Я бы в вашей ситуации выбрал правильный с точки зрения языка вариант.

Для группировки в файловой системе есть каталоги. В разных языках тоже часто есть модули, неймспейсы и т. п. чтобы писать, например. Order.CreateJob — тут мозг не ломается, к знакам препинания он привыкший.

Ну, всегда можно написать «new COJ», по крайней мере в Idea так найдёт нужный класс
Согласен, как наиболее распространённый пример стоило упомянуть венгерскую нотацию. Для меня наиболее трудночитаемые идентификаторы — это написанные в венгерской нотации. Ни один из них не распознаётся сразу как целое слово, всё приходится читать по буквам, проговаривая про себя. А чтение их по буквам — просто издевательство над произношением — многие префиксы — это совершенно непроговаривариваемые сочетания согласных. Хорошо, что сейчас венгерская нотация встречается нечасто, однако даже некоторые относительно молодые программисты до сих пор используют её в коде на C. Транслит читается намного легче, и его происхождение понятно — незнание английского в сочетании с нежеланием его изучать.

Причём незнание необязательно у разработчиков. Бывает бизнес требует имен транслитом в базах и, например, http API ендпоинтах. Ну и по всему приложению они расползаются.

Смотря какой язык
Мне например, венгерская нотация удобна для наименования глобальных переменных, чтобы сразу знать какой тип у неё. Имена локальных пишу прописью без указания типа.
Да и пишу я не на С, но на подобном ему языке (правда, сейчас синтаксис больше похож на Java или С#, во всяком случае года 4 назад синтаксис поменяли, хотя можно писать и на старом).

Префиксы у переменных имеют смысл, если без них возможны конфликты имён.
Например считал я из текстового поля введённое пользователем значение напряжения в переменную txtU в киловольтах. Распарсил её в переменную kvU, а для расчётов сделал ещё одну
vU = kvU*1000;

А потом пришел я и застрелился, потому что в коде тысячи переменных u, U, Us, Uu, uuu, _u etc etc etc.

Так предметную область надо знать. Все однобуквенные обозначения — из предметной области взяты.
Считаем мы, к примеру трансформатор. Что обозначает локальная переменная с именем U?


И, да, я не уточнил — это всё про локальные переменные.

Мне кажется в предметной области все-таки напряжение, ток и сопротивление (voltage, current, resistance), ну и так далее, а никак не U, I, R. Более того, часто это будет не просто voltage, а более конкретный InputVoltage, SupplyVoltage или какой-нибудь BiasVoltage…

Это в быту "вольтаж" и иже с ним. В предметной области общепринятые буквы.

Остается только надеяться, что пишите вы сугубо для себя и никому не придется вдаваться в подробности вашей предметной области ))

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

Вполне может быть допущен, если что-то с кодом сделать надо, а программиста со знанием предметной области под рукой нет.

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

Конкретно пример с kvU мне кажется странным, но вот стандартные формулы в таком стиле воспринимаю нормально. Пример:

let R = U / I;


И даже не смотря на то что это будет нарушение общего стиля то я бы заапрувил PR из-за того что сразу же понятно что тут происходит.
Считаем мы, к примеру трансформатор. Что обозначает локальная переменная с именем U?

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


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

Если напряжения в трансформаторе два, то U_h и U_l. В противном случае в коде появляются конструкции вида:

output_current := input_current * (input_voltage / output_voltage);
I_l = l_h * (U_h / U_1);

идеально :)))
именно вторая конструкция написана на языке предметной области и читается легко
Вы так говорите «трансформатор постоянного тока» как будто такие вообще бывают. Трансформатор (в электронике или электротехнике) это несколько обмоток на общем сердечнике, он по определению работает только с переменным током. Если же говорить о преобразователях постоянного тока, так это довольно сложная конструкция, которая вполне может содержать трансформатор.
Ну и хранить амплитудное значение отдельно от действующего… а зачем? Они же пропорциональны.

Отдельно хранить их и правда мало смысла, но вот понимать какое из двух хранится — нужно.

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

Сопряжение модулей — это отдельная тема. У меня в Public не торчат ни однобуквенные имена, ни венгерская нотация. Все эти вещи — для использования внутри модуля.

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

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


Ну и хранить амплитудное значение отдельно от действующего… а зачем? Они же пропорциональны.

Как верно заметили выше, в некоторых случаях важно знать, какое из них мы храним (например, для вывода пользователю или для расчетов).

Если под kvU имеется в виду напряжение в киловольтах, то так делать без особой нужды (экономии скорости или памяти там) не стоит. Лучше использовать все единицы в системе Си, без дробных и кратных. И с формулами не напортачишь, и разбираться в каких же единицах оно хранится в файле не придется. Ну и что если одно число будет, скажем, 6.8e-11 Ф, а второе 1.2e+7 Гц. Потери точности при перемножении чисел с плавающей точкой не выше, чем с фиксированной, а складывать их все равно не имеет физического смысла.
Но когда использование float обходится слишком дорого, можно и указывать размерность в имени макроконстанты, которую потом переводить во внутреннее представление с самыми странными коэффициентами:
#define TIMEOUT_s 100
---
#define TIMEOUT_ticks F_CPU / 65536 / TIMEOUT_s

Если в ТЗ указано, что ввод должен быть в киловольтах — то он будет в киловольтах.
Для расчёта я его, естественно, в систему СИ переведу.
А в процедуре, которая преобразует текстовый ввод в вольты — будут все три названные переменные.

Но они будут внутри процедуры, то есть наружу будут торчать только «единицы по умолчанию». А внутри процедуры на десяток строк можно и попроще переменные назвать.

Естественно. В том, что торчит наружу, я и венгерскую нотацию не использую.

Может проще сразу при парсинге txtU преобразовать в vU минуя использование промежуточной переменной kvU, которая, насколько я понял, больше нигде не задействована?

В используемом мной языке это выглядело бы примерно так:
void SomeFunction(%параметры_функции%)
{
...
	char sU[32];
	GetCmdArg(1, sU, sizeof(sU));	// так, например, получаем строковое значение
	int iU = StringToInt(sU) * 1000;
...
}
Ни один из них не распознаётся сразу как целое слово

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


Ну, положим, btn — кнопки, txt — текст-боксы, cmb — комбо-боксы, lst — списки, и т.п. Нужно это для того, чтобы в IDE, которая сортирует всю эту нечисть по алфавиту, однотипные компоненты собрались вместе.


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

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

Односложные префиксы для элементов интерфейса — это ещё ничего, в этом случае упоминание типа в имени уместно, напрягает только сокращение, я предпочитаю писать в таких случаях без сокращений. Гораздо хуже всякие lpsz, и другие составные префиксы. А физические единицы я если указываю — то суффиксами: time_ms, i_mA. Так лучше, потому что сначала суть, потом детали, и ближе к естественному языку.
напрягает только сокращение

Они стандартны. Содраны у мелкомягких в чистом виде.
На счёт единиц суффиксами — вы правы. Так действительно лучше.


составные префиксы

А вот это я считаю — против самой идеи. Префиксы не должны быть составными и их должно быть в общей сложности немного.

у как ты опишешь unsigned long variable кроме как составным ulVariable?

НЕ НАДО описывать unsigned long с помощью префиксов. Они не для того.

Википедия и ребята программирующие на плюсах с тобой не согласятся

Зато со мной согласен товарищ Спольски. Вернее, это я с ним согласен.

У M$ в плюсовом коде очень часто Венгерская нотация присутствует. 100% что и в Эксель оно есть.
M$

И именно их товарищ Спольски в первую очередь обвинял в извращении его идей.

Работать с ними ему это впрочем не мешало
lpsz — а что тут непонятного и неестественного: long pointer to string zero terminated?
В коде ты ведь тоже пишешь char* mystring, а не mystring c* — тип всегда предваряет имя.
Непонятного тут нет ничего. А неестественно проговаривать про себя при чтении кода 4 согласных подряд. Одинаково неестественно каждый раз расшифровывать их в полное наименование типа. Не делать ни того ни другого у меня не получается, не смотря на то, что кода в венгерской нотации я читал много.
неестественно проговаривать про себя при чтении

Проговаривать про себя при чтении — в принципе неестественно.

Да, если читаешь текст из знакомых слов, а не из транслита и сокращений. Статья именно об этом.

Эм… У меня — наоборот. Когда читаешь текст из слов — можно их проговаривать для собственного удовольствия. Транслит, впрочем, тоже легко читается, если вы в начале 2000-х писали смс-ки.
А специальный текст, не говоря уж о сокращениях в нём — проговаривать не нужно, а зачастую — невозможно.

слушай, ну тебя же не напрягает тип char — ты же его в character каждый раз не расшифровываешь? А int в Integer.

Имхо венгерская плоха в первую очередь тем, что мешает автокомплиту в IDE — никогда не помнишь, с какой буквы надо начинать набор.


Скажем, во freeRTOS все API — с венгеркой. И это просто адище:


xTaskCreate
xTaskCreateStatic
vTaskDelete
vTaskDelay
vTaskDelayUntil
uxTaskPriorityGet
vTaskPrioritySet

Пояснение: u — unsinged, v — void, x — хз что. Да, ux — это unsigned хз что.


И вот какая мне, блин, разница, что возвращают эти функции? Почему они все не начинаются со слова task, они ведь все относятся к блоку манипуляции тасками?! А вот. И, разумеется, большинство IDE начинают поиск только если первую букву угадаешь.

Вы привели типичный пример неправильного использования венгерской нотации.

Вы привели типичный пример неправильного использования венгерской нотации.

Именно! Вроде бы, товарищ Спольски это называет "Наивная венгерская нотация" — когда к переменной приписывается формальный тип, который никого не интересует.


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

Всё это, конечно, правильно, да…
Но как быть с ВыгрузкаПоДебиторскойЗадолженностиИПоЗадолженностиОтПосредниковРаботающихСУдержаниемКомиссииГрафикБудущихПлатежей?

ЗЫ. У кого экран шире 1280 — конец слова виден?
В такой ситуации правильным решением будет отказ от 1С)

Вообще такое должно решаться на уровне номенклатуры. Например, присвоение номеров отчётам. В итоге получим код вида

ReportService.getReport(128256);
Не бывает ситуаций, когда вам надо разобраться во всём сразу. Обычно ломается какой-то один отчёт и вы уже знаете что именно этот отчёт должен выдать.
Угу, а еще бывает, что какая-то общая функциональность используется в N отчетах, соответственно когда ищешь в каких именно, то результат показывает что в отчетах 128256, 008 и 123 — в этот момент рука тянется к кнопке запуска крылатой ракеты настроенной на поиск писавшего это.
ReportService.getReport(128256);
Одна из первых рекомендаций обычно: не используй магические числа, используй именованные константы.
Так что ReportService.getReport(REPORT_EXPORT_DEBTS_AND_BLAHBLAH_BLAH_WITH_FUTURE_TRANSACTION_PLAN_BLA);
ВыгрузкаПоДебиторскойЗадолженностиИПоЗадолженностиОтПосредниковРаботающихСУдержаниемКомиссииГрафикБудущихПлатежей?
Если вы сформулируете внутреннюю логику бизнес-процессов или нормативов, для чего именно понадобились именно эти данные, то, скорее всего, вам удастся придумать более лаконичную формулировку. Главное — последовательно использовать одну и ту же терминологию во всём проекте.
А у пользователя этот отчет как называется? Не поверю, что так же.

ЗЫ. У кого экран шире 1280 — конец слова виден?

Если не забуду — дома проверю.
На 1920 последняя буква в слове Комиссии обрезана ровно пополам.
Просто у хабра интерфейс растягивается не на весь экран.
Слева и справа пустые поля примерно по 20% от ширины экрана выходят на FullHD.
Хабр не резиновый.

min-width: 1024px;
max-width: 1164px;
Возможно, чтение мемасиков, в которых используется т.н. «олбанскей езыг», за счет повышенной нагрузки на мозг, создает некое ощущение полезной деятельности? Интересно.
Программар наци
ИМХО универсальных принципов именования не найти, ассоциативные цепочки у людей существенно разные, так что как вы функцию не назовёте, кому-то всё равно будет глаз колоть, на экран не влезать и под курсором мешаться. Комментируйте код, господа.
cntr_nm_code = 38;
Пример специально подогнан под желаемые выводы.
«cntry» вместо «country», «ctr» вместо «counter» — уже всем понятно с первого взгляда (аналогично с id, idx, num, val, cur, buf, ptr, tmp и пр.).
Разбирать выражение, растянувшаяся на несколько строк только из-за пустопорожних километровых имён — вот это действительно, мягко говоря, утомляет…
Очень толковая книжка — «практика программирования» Кернигана и Пайка как раз про это говорила.
website.userAdd();
Классический способ построения номенклатур «сверху вниз» наподобие «карандаши цветные». Это правильно и удобно.
Мимикрия слов (Name, name, _name и _Name в одной функции)
Вот настоящее зло, начиная с самой идеи назвать переменную «имя» без уточнения чьё именно имя… Бросаются из крайности в крайность, то сочиняя имена, занимающие всю строчку, то экономят несколько знаков любой ценой, разрешая конфликты извращениями с регистрами и подчерками. Нет ничего лучше классической сишной нотации. book_name_set(book, book_name) { book->name = book_name; }
Не знаю заметили ли вы, но в «подогнанном» примере вы сами и опечатались)
уже всем понятно с первого взгляда

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

Это не "карандаши цветные", это "карандаш добавить".

«ctr» вместо «counter» — уже всем понятно с первого взгляда

с первого взгляда ctr я распарсил, как control. А для counter/count много лет уже живет сокращение cnt.
«cntry» вместо «country», «ctr» вместо «counter» — уже всем понятно с первого взгляда (аналогично с id, idx, num, val, cur, buf, ptr, tmp и пр.).

cur это валюта, курсор или что-то текущее?
ctr кстати не очень понятен — лучше cnt
Тогда еще:
sck(dic) = set_current_key(dictionary)
fck(slt) = file_check(system_library_template)
set current key это несколько слов, сокращение не общеупотребительное и будет не понятно и даже если и будет понятно что мы делаем — присваиваем текущий ключ или текущему ключу.

pow, exp, len, str, eval, enum, var, val — никого ведь не смущают?

если про ключи то: pk, capk, exp тоже вполне употребимо.

file check можно сократить до fcheck (printf/fprintf) или fchk если букву жалко.
Похоже троллинга на тему cnt вы не уловили ;)
Не все часто употребляют англоязычные ругательства.
Не заостри Вы на этом внимания и я тоже не обратил бы. =)
Тем не менее, если я напишу в коде ПЗДЦ, все прочитают именно то, что прочитают, несмотря на то, что я имел ввиду, например, «первоначально заданные данные цели»

Авторы аббревиатур вроде НПЦ ПЗДМ (реальная организация, расшифровку точно не помню, что-то на тему "психического здоровья детей и молодёжи") могут не согласиться.

Иногда мне кажется, что авторы подобных аббревиатур прекрасно понимают как эти аббревиатуры читаются, просто они тролли.

Из контекста остальных сокращений id, idx, num, val, cur, buf, ptr, tmp — однозначно что-то текущее, но только если рядом никто currency не сокращает. Мне кажется в любом проекте есть некий словарь принятых сокращений, но эти реально общепринятые. Хотя в коде про бизнес-процессы я не ленюсь писать index вместо idx, buffer вместо buf и т.д. А вот в системном наверняка ленился бы, потому что там такие сокращения очень часто используются.

P.S. Зачем сокращать country — мне решительно непонятно.

О!


cntr_nm_code

преобразуем в lowerCamelCase и получается


cntrNmCode


Венгерская нотация!

Может быть всё же iCntrNmCode?
Без префикса, указывающего тип переменной, это будет не венгерская нотация.

Наоборот. Спольски говорил, что префикс должен указывать что угодно, но не тип переменной.

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

Применяемая система префиксов зависит от многих факторов:
Ссылка
запись типа переменной в её идентификаторе (венгерская нотация)
Ссылка

Спольски упомянут только как автор идеи использовать префиксы для обозначения подтипов (да и то, если указания типа не хватает).

Вот только я самого Спольского читал, когда ещё Википедии не было.
Если автор статьи на Вики не сумел найти первоисточник — это сугубо его проблемы.
Кстати, об этом написано, и даже со ссылкой, в обсуждении статьи.
Сылка

Я сразу так и сказал
Тогда нужно править статью на википедии.
Прочитал статью по ссылке.
В общем изначально под типом подразумевалась область использования, что ли, а не тип переменной. Вроде «безопасной» и «небезопасных» строк или координат относительно строки и разметки (здесь вообще имя переменной состоит только из префикса).
Да и то это больше зависит от языка, где эта нотация используется. В некоторых изначальная её версия особого смысла иметь не будет.

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

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

Рискну предположить, что это потому, что люди пишут код значительно медленнее, чем все остальное (особенно начинающие разработчики, либо опытные разработчики в новом языке/фреймворке, с непривычки). В мозгу начинающего разработчика код именно что составляется из отдельных букв и символов, вручную. Оптимизированные образы «слов» и «выражений» еще не выработаны, поэтому мозг даже и не пытается проверять написанное на соответствие этим самым образам. В этом отношении код начинающего разработчика напоминает корявые прописи четырехлетнего ребенка

За собой, кстати, наблюдаю проблему уже другого уровня. Как известно, чеволек без прлобем может читать ткест при извстеном конткесте, даже если в нем перестлавены отльденые буквы, при условии, что предолжение и текст в целом соствалены грамотно. Я считаю себя довольно опытным разработчиком, и очень серьезно запариваюсь на соблюдение и поддержание архитектуры в своих приложениях. При этом на уровне отдельных функций/операторов (которые я пишу довольно быстро, почти на автомате) вполне позволяю себе писать код с мелкими нарушениями, смешивая buttonOk и okButton. А что, я же знаю, что архитектура в целом соблюдается, и эти мелкие ошибки никак не повлияют на поведение приложения в целом — вот мозг и привыкает не обращать внимания на эти мелочи.
У мозга есть физиологическое ограничение: время распознавания образа практически константа, от появления перед глазами объекта до осознания мозгом что этот объект из себя представляет проходит около 500 мс.


Откуда цифра 500, если не секрет? Из того, что я видел, везде 150, например www.nature.com/articles/srep01928
Когда испытуемый сидит в пустой комнате то у него в мозгу происходит какая-то электрическая активность, если показать ему какой-то объект, то произойдёт всплеск активности с пиком в районе 500мс, затем снова вернётся к нормальному режиму.

Источники точно не укажу, но, например, в ссылках из статьи картина именно такая и во всех остальных исследованиях которые я изучал данные точно такие же.
Ну я тоже читал про эти эксперименты начиная от статей на пабмеде и заканчивая публицистикой вроде «Consciousness and the brain». Только везде 150 (10-50 для амигдалы, но это отдельный набор экспериментов и он не интересен). Цифру в 500 вижу первый раз в жизни вот в этой статье на Хабре. Она где-то еще встречается в литературе, научных статьях, пабмеде?
Вообще я взял эту цифру как среднее на основе стандартных составляющих ERP. Их картина достаточно стабильна, пики на ЭЭГ именуются как N/P(отрицательный или положительный) с добавлением обычного времени появления, например N100.
Для стандартных стимулов последний пик — N400 с максимальным временем появления 500мс. На него я и опираюсь в своём суждении.
Есть также пик P600, но он проявляется только как реакция на синтаксические или им подобные аномалии.
Есть с этими цифрами что-нибудь с пабмеда? Именно про «появления перед глазами объекта до осознания мозгом что этот объект из себя представляет»? Осознание определяется отдельным набором экспериментов, например человек кнопку нажимает, чтобы выбрать что он увидел итд.
В рамках изучаемой темы точное число было не особо важно, поэтому не интересовался. Если вы вдруг сможете предоставить какие-то другие аргументированные цифры — буду благодарен.
Привведённая вами статья о том, что чтение некоторых слов вызывает более быструю реакцию в некоторых регионах мозга и происходит это в предела 200 мс, что существенно меньше общепринятого порога в 400 мс.

Это лишь предположение, что 200 мс являются реальным временем распознования а остальная активность с распознаванием образов уже не связана. Боюсь что правду до составления карты человеческого мозга мы так и не узнаем.
Без паники, у меня все под контролем!

1) www.frontiersin.org/articles/10.3389/fnhum.2019.00013/full => Yeo, L. G., Sun, H., Liu, Y., Trapsilawati, F., Sourina, O., Chen, C.-H., et al. (2017). “Mobile EEG-based situation awareness recognition for air traffic controllers,” in 2017 IEEE International Conference on Systems, Man, and Cybernetics (SMC) (Banff, AB), 3030–3035.

2) www.ncbi.nlm.nih.gov/pmc/articles/PMC3081809

3) en.wikipedia.org/wiki/Face_perception => «For temporal profile of shape and surface processing, around 150ms seemed to be critical moment, perhaps where integration of shape and surface features happen, leading to successful face recognition, as face reconstruction accuracy also reached significance around that time frame».

Если с этими статьями что-то не так — я могу без проблем еще найти, пол гугла откликается на «150 ms brain cognition» и за последние десять лет я эту цифру встречал бесконечное количество раз.

И вот такие картинки в лекциях: image
Первая статья — единственное, что связано — предположение, что можно создать интерфейс мозг-компьютер с интервалом между стимулам 100-200мс.

Вторая ссылка — выдвигается теория, что мышление идёт циклами по 260–390 мс. На основе экспериментальных и симулированных данных. Ну допустим, я готов поверить в усреднённые 325 мс, хотя и с большой натяжкой.

Третья ссылка — тоже ничего. Упоминается, что 150мс, вероятно, один самых важных моментов в распознавании лиц, интеграция формы и поверхности. Не полное время, а самый важный момент.

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

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

Основная причина, по которой я сомневаюсь в ваших цифрах указана мной выше, это N400. Если распознавание образа происходит 3а 150 мс, то какова роль этого пика? Я могу согласиться, что за 150 мс происходит какой-то важный этап, например нахождение соответствия между образом перед глазами и образом в памяти, но никак не в то, что это полное время осознания того, что перед глазами находится определённый объект.
Ооок, попробую с цитатами:

1) «The RPT finds that the brain activity correlated with CONSCIOUS perception of a stimulus occurs on the earlier side, approximately 150 ms after stimulus presentation, as opposed to the late wave of activity posited by GNWT at >300-400 ms» (https://www.reed.edu/psychology/scalp/thesis/files/Goldblatt_Thesis_2016.pdf)

2) «Unfortunately, the literature is still inconsistent with regard to
even basic aspects of the time course of visual word recognition.
In particular, the latency ranges for lexico-semantic information retrieval are still intensely debated, with estimates ranging from before 150 to about 350 ms» (https://www.scienceopen.com/document_file/5b111e86-f4e3-4182-b5cf-4e70967026a3/PubMedCentral/5b111e86-f4e3-4182-b5cf-4e70967026a3.pdf)

3) Вот тут пара интерресных коррелянтов, которые я обычно использую чисто в инженерных целях при работе со звуком и видео: www.pubnub.com/blog/how-fast-is-realtime-human-perception-and-technology

Вопрос про «какая роль N400» я не совсем понимаю. Как он коррелирует с задержкой осознания? Чтобы посчитать задержку осознания ставят эксперименты, где человек реагирует на входящие стимулы (изображение, звук, тактильные) нажимая кнопки, говоря что-то итд. После чего вычитают активность «после осознания». Для этого ставят коварные эксперименты, меняя экспериментальный параметр так, чтобы менялся только факт работы именно сознания. Бифокальное противостояние, например. ЭЭГ в этих экспериментах, насколько я знаю, вообще не используют, потому как оно показыват «погоду на марсе» — корреляция между активностью мозга и снимаемой с черепа электрической активностью есть, но она слишком грубая, чтобы хоть как-то помогать с происходящими внутри активностями.

А вот вопрос про более-менее точную задержку интересен. Похоже, несмотря на обилие цифры в 150мс я не могу сходу нагуглить действительно хороших исследований, которые бы намертво закрывали вопрос. Я уточню у знакомых нейрофизиологов и буду более внимательно смотреть на эти цифры именно в экспериментах, связанных с сознанием. Если через год в этой ветке появится коммент — значит я нашел обновленную информацию))
Про N400 я упомянул с позиции того, что это постоянно присутствующий пик в реакции на раздражитель, мне кажется странным его не учитывать его продолжительность в измерении времени реакции на стимул.

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

Посмотрим, что будет через год)
Only those users with full accounts are able to leave comments. Log in, please.