В реальности всё не так как на самом деле - это очень заманчивая парадигма.
Только прежде чем по ней следовать всерьёз надо чётко определить 2 понятия: "реальность" "на самом деле".
Только после того, как вы их определите - можно будет спорить почему "эпициклы" по-вашему не наука (хотя определить год события по астрономическим записям было можно), а "ньютоновская механика" - это наука не смотря на дальнейшие уточнения, что это недостижимое частное упрощение.
Бенчмаркомерилки это делают так: 1. Ищем конкретный случай под SIMD (SSE или AVX), который современные компиляторы не распознают - а они довольно плохо SIMD делают, в том числе потому, что не знают вам Vec<Int> - он обычно на 2 инта или обычно на 2000 интов? 2. Конкретно для этого случая вставляем костыль "распараллель под SIMD" (с пре-лупом, внутренним распараллеленным под SIMD циклом и пост-лупом). 3. Добавляем этот бэнчмарк и хвастаемся какой крутой наш компилятор.
Ну честно говоря не понятно про язык вообще ничего.
Заявленные характеристики производительности возможны в случаях: - подделки (немасштабируемый костыль) под конкретный use-case - какое-то концептуальное (например data-flow / порт в OMP / ... ) распараллеливание в языке. - (все компиляторописатели последние 20 лет занимались фигнёй и .... - ну это так для проформы момент). Про концептуальное распараллеливание в статье ни слова. Результатов spec тестов нету - значит ли это, что реализовался первый вариант?
2. Какая система типов в языке? Хотя бы "объекты" или "структуры с интерфейсами (трейтами \ тайпклассаи \ ...)"?
3. Как в типизированный язык импортируются модули из нетипизированного (Python)?
4. Ну и да всякие вопросы типа: это будет native компиляция с честным ffi в С или какая-то платформа? Пакетный менеджер? Ну и куча других вопросов, с которых по-хорошему начинать надо, но они вообще за рамками статьи остались.
ПС Одно замечание: текущее ограничение по одновременности хода (пока игроки не увидели друг-друга впервые) - это не техническое ограничение, а ограничение ТЗ. Вы когда его отменяете - у вас получается пусть немного, но уже другая игра с другим балансом (кто быстрее нажал).
было: в случае обновления законодательной базы парсит нововведения и получает новый PHP файлик выдачи документов.
стало: ну мы умеем форматировать данные по xsd.
Понятно.
> P.S. и да, это уже не "у меня" больше трех лет.. работает штатно, насколько понимаю.. Было "в вашем примере", стало "у меня". Смысл кавычем - в точности цитаты.
Впрочем я уже по предыдущему ответу всё понял, удачи вам.
Я не очень понимаю как это может быть устроено у вас с "синглтоном".
Есть "статический полиморфизм" (это по сути шаблоны / трэйты + мономорфизация) Есть D2S фаза компиляции (у бинарных трансляторов и JIT-компиляторов), но она никак не привязана к "синглтону" - она просто собирает статистику по dynamic call destination и если это 1-2-3 варианта - просто вставляет статические джампы + ветка "не смогла".
А что у вас написано (в частности при чём тут синглтон) - я не понимаю.
ПС
При dynamic call сразу несколько сложностей: 1. Прочитать адрес вызова из VMT (в java к стати у объекта может быть целый вектор VMT а не одна) - из-за этого у java он скрыт за отдельной индирекцией. 2. предсказателю переходов намного сложнее работать с динамической информацией. Она же скрыта за машинерией получения VMT, а не лежит по конкретному смещению +field_offset у объекта.
придётся руками искать и дополнять все эти гениальные switch statements
Ну если мы сравниваем C++ -classes мы C++ -templates то наверное да. А вот если мы возьмём Rust - то там из коробки свичи (они там pattern-matching и называются match) exhaustive. Поэтому компилятор их за вас все сам найдёт и скажет: допиши ещё ону альтернативу пожалуйста.
Генератор выкачивает описания, сличает их с имеющимися, в случае обновления законодательной базы парсит нововведения и получает новый PHP файлик выдачи документов.
Э... подождите в вашем примере парсится текст закона (и подзаконных актов). И по тексту закона, даже без промежуточного ТЗ, генерируется нужный нам код. Это как?
Вы наверное хотели адресовать это к человеку выше? Потому, что там был хитрый вопрос "вот выпилите ООП в кодовой базе на 100KLoC тогда поговорим" - и ответ "вот выпилил на проде в базе 10KLoС, доволен".
И да я так не считаю (часто Хаскель за счёт отделения кода от данных чудо как хорош, часто Rust за счёт управления ошибками (близко к аппаратуре) великолепен).
Но часто ООП очень полезен (иначе dyn в Rust не завозили бы).
Upd.
В современных языках можно иметь статический диспатч для открытого множества типов который часто будет даже лучше свитча
Сдаётся мне мы как-то сильно по разному это понимаем, ну или вы забыли (*) и подпись мелким шрифтом.
Ну вот я не согласен с вами. Как писал выше - переписывал библиотеку DSL-языка с полиморфизма на струкруты + switch. Но это очень "алгоритмический" код. А вот бизнес-логику я бы так переписывать не стал - я не могу прямо определить что есть "бизнес-логика" что есть "алгоритмы". Но когда работаешь с кодом прям чувствуется.
Я рефакторил библиотеку DSL-языка на 10 КLoC (это включая заголовки) на С \ CPP. Заменил полиморфизм свичами (defaul проверял экзостив в рантайм), списки массивами (для этого надо иметь нерасширяемый тип в заголовке библиотеке).
Ускорение в типовом случае в 5-7 раз (после сборки с -lto). Значимых багов (после вылавливания изначальных с помощью тестового генератора) найдено не было. И уж точно не помню багов как-либо связанных с переписыванием.
Понятность кода после разворота динамических вызовов в свичи повысилась.
Когда программисты говорят про переполнение буфера? Когда имеется в виду работа с нуль-терминированной строкой, неправильное использование функций strcat, memcpy и т.д.
А я всегда думал, что это при выходе за границы буфера на запись (т.е. по сути риск испортить данные за пределами буфера).
У нас два разногласия: - что значит действовать в соответствии с "обычаями делового оборота" и "что есть обычаи делового оборота" в данном случае.
По первому пункту:
Смотрите - если в трудовом договоре написано: а ещё в нербочее время делать кофе начальнику, то именно этот пункт признают недействительным, а трудовой договор в целом сохранят. Такая же логика распространяется и на другие договоры. Для ЗоЗПП это хорошо прописано и есть практика.
Я как не-юрист считаю, и даже почти уверен, что такие же имплицитные нормы применяются ко всем другим договорам (по духу права, источником которого в т.ч. являются обычаи и традиции делового оборота). Просто они или до ВС не доходили или не на слуху (что в нашем праве, что в прецедентном). Ну то есть это с изучения "основ права" осталось. Если юрист поправит - буду не прав.
Также по смыслу есть положения, что мы можем исходить из добросовестности второй стороны договора. И вот так работать, как будто договор составлен "честно". А если они на самом деле мошенники оказались и договор скам - их накажут, а нам что-то возместят (скорее всего суд скажет "требуем читать договор честно").
По второму пункту. Есть некоторая "ситуация на рынке". Из которой люди исходят как из данности. Условно "день на тестовое" - это максимум (я делал такое на свою первую работу прогером). Больше - время должно быть оплачено.
Таковы сегодняшние реалии. Ну два дня можно. Но в ситуацию "делаю задание неделю а оно оплачено не будет" - никто не полезет из программистов. Просто так не делается сегодня (как суммы пишутся в десятичной и не пишутся в одиннадцатиричной системе счисления). И я бы такие формулировки считал "скамом" (не знаю мне иностранные слова кажутся менее жёсткими и "скам" не так эмоционально как "обман"), мелким мошенничеством, "ну прокатило".
Но если разбираться - нет ребята или вы на 2й 3й день говорите - ты прогер не нашего уровня. Или если уж неделю ждали - заплатите. Так в индустрии сегодня просто не делается (может мы все через год за еду с ChatGPT работать будем - но это будет через год). Никто такого не ожидает. И интервьюируемый в праве ожидать некоторого "разумного по-умолчанию" отношения.
При таких вводных обычно просто вывода нет - если у вас нет компетенции утверждать, что нужная статья действительно правильная, но я, как читатель, вашу компетенцию проверить не могу.
Мне кажется, что вы пропустили "если" в этой фразе и распарсили её как вывод о вашей компетенции. В то же время она читается так:
1. Рассмотренные статьи не позволяют вам делать выводов о том какая гипотеза правильная. 2. Из правила 1 есть единственное исключение - вы большой эксперт, тогда вы можете делать субьективные выводы. 3. Но к сожалению я как читатель не понимаю эксперт вы или нет => goto в пункт 1: могу пологаться только на объективные данные а их недостаточно.
Ок. Принимается. Если я высказался о вашей компетенции - приношу извенения (* но я старался не: ниже цитата не о вашей компетенции, а о том, что я не могу её проверить - это же принципиально разные вещи).
Для меня ваша статья читается так: исследовательские данные такого качества, что легко можно подобрать данные под любой удобный вывод ... При таких вводных обычно просто вывода нет - если у вас нет компетенции утверждать, что нужная статья действительно правильная, но я, как читатель, вашу компетенцию проверить не могу.
Давайте попробуем ещё раз.
Мы имеем в вашем обзоре: - с одной стороны мальчики для битья (важно уточнение вы над ними подтруниваете - т.е. обозначаете свою позицию). - с другой стороны одно китайское исследование, вроде бы в тему, но одно и китайское.
И вот я как слушатель (я не прочитал столько статей сколько вы) какие выводы должен делать: а) вы действительно перебрали всё подходящее и вытащили лучшее на наш суд - тогда это почти эквивалентно "исследований нет". б) вы не очень хорошо искали и специально вытащили "мальчиков для битья" - тогда я тоже не могу сделать выводов.
Заметьте в любом случае я значимых выводов сделать не могу. По одной статье, тем более такой, они реально не делаются. И второе замечание (ну как человека который читал и нормальные обзоры и ангажированные) - ирония в вашем обзоре заставляет подозревать вариант "б" с бОльшей вероятностью чем было бы без неё.
Вы пишете так, будто критерии оплаты в задании указаны объективно. Но они таковыми не являются. Например "плавность анимации" - оценочное суждение. И да этот оценочный критерий есть как недостаток в фитбэке.
Смотрите человек имеет право считать, что перед ним не мошенники и исходить из этого в своих действиях (в том числе при интерпретации условий договора). Если договор, как здесь, читается двумя способами "передо мной мошенники" или "они неудачно сформулировали договор" - я имею право действовать по второму сценарию и должен (во всяком случае в идеальном мире) выиграть такое дело в суде.
По факту мы имеем: 1. Договор должен соответствовать обычаям делового оборота 2. Мы читаем ТЗ на тестовое задание 3.а ТЗ, как его читал интервьюируемый - худо-бедно соответствует традициям делового оборота 3.б ТЗ, как его читал работодатель - резко не соответствует традициям делового оборота (по объёму это не ТЗ не тестовое) 4. В фидбеке правки никак не помогающие пройти тестовое, а валидные если объявление скам и вы пытаетесь сделать приложение.
Да и почему автор статьи простофиля, но не дурак не умеющий читать. ТЗ может быть не скамом, только если его читать примерно как (это допустимое прочтение): - сделать 1 страницу точно - показать, что я вообще умею писать приложения такого рода (с прототипами остальных страниц) - показать что я умею в плавную анимацию и тому подобные вещи (я не фронт) - показать, что я умею внешний JS-код заворачивать для контрактов в нормальное окружение для работы.
Смотрите вы можете встать в позицию "не пойман не вор" (докажите что фразы (*) высокомерны - по мне человек отзывающийся так о докладах коллег нарушает этические принципы) - не вижу рациональных причин дальше тратить на вас время. Я начал с максимально спокойного комментария, который мог бы сделать статью чуть лучше (в смысле она бы смотрелась чуть лучше) - если вам этого не надо, ну хорошо.
*)
я изложил вполне конкретные проблемы.
Исследователи пришли к ошеломляющему результату, что на красном фоне текст читать тяжелее всего!
Феноменальным образом оказалось, что тёмный экран в совершенно тёмной комнате во всех
Учёные пришли к прорывному выводу, что красный
В этот раз авторы догадались добавить в сравнение негативную схему «белое на чёрном», правда остальные схемы почему‑то всё такие же шизовые
Высокомерный тон (в тексте это высокомерные, поучительные обороты) которым вы комментируете статьи. Подчёркивание, что тема исследования неудачная (не плохо матчится на нас а именно неучачная).
Это типичные приёмы ангажированного обзора исследований (я этого не писал в исходном комментарии, чтобы выразиться помягче) - это одна из причин, по которой к вашей статье нет доверия. Вы не просто подобрали неудачные статьи на неустраивающую вас точку зрения, а ещё и попытались эмоционально их принизить.
В реальности всё не так как на самом деле - это очень заманчивая парадигма.
Только прежде чем по ней следовать всерьёз надо чётко определить 2 понятия:
"реальность" "на самом деле".
Только после того, как вы их определите - можно будет спорить почему "эпициклы" по-вашему не наука (хотя определить год события по астрономическим записям было можно), а "ньютоновская механика" - это наука не смотря на дальнейшие уточнения, что это недостижимое частное упрощение.
Интересно, при mmap же должна быть оптимизация, когда полностью перезаписывают страницы, интересно как она происходит.
Т.е. если мы открыли существующий файл и пишем в него, то как делается что вот это не требует чтения с диска:
char *fdata = mmap(... fd ...);for (int i = 0; i < PAGE_SIZE; i++)fdata[i] = data[i * 2];В то время как вот это требует:
char *fdata = mmap(... fd ...);for (int i = 0; i < 100; i++)fdata[i] = data[i * 2];Бенчмаркомерилки это делают так:
1. Ищем конкретный случай под SIMD (SSE или AVX), который современные компиляторы не распознают - а они довольно плохо SIMD делают, в том числе потому, что не знают вам Vec<Int> - он обычно на 2 инта или обычно на 2000 интов?
2. Конкретно для этого случая вставляем костыль "распараллель под SIMD" (с пре-лупом, внутренним распараллеленным под SIMD циклом и пост-лупом).
3. Добавляем этот бэнчмарк и хвастаемся какой крутой наш компилятор.
Ну честно говоря не понятно про язык вообще ничего.
Заявленные характеристики производительности возможны в случаях:
- подделки (немасштабируемый костыль) под конкретный use-case
- какое-то концептуальное (например data-flow / порт в OMP / ... ) распараллеливание в языке.
- (все компиляторописатели последние 20 лет занимались фигнёй и .... - ну это так для проформы момент).
Про концептуальное распараллеливание в статье ни слова. Результатов spec тестов нету - значит ли это, что реализовался первый вариант?
2. Какая система типов в языке? Хотя бы "объекты" или "структуры с интерфейсами (трейтами \ тайпклассаи \ ...)"?
3. Как в типизированный язык импортируются модули из нетипизированного (Python)?
4. Ну и да всякие вопросы типа: это будет native компиляция с честным ffi в С или какая-то платформа? Пакетный менеджер? Ну и куча других вопросов, с которых по-хорошему начинать надо, но они вообще за рамками статьи остались.
Извините не вам ((
Круто, серьёзно.
ПС
Одно замечание: текущее ограничение по одновременности хода (пока игроки не увидели друг-друга впервые) - это не техническое ограничение, а ограничение ТЗ.
Вы когда его отменяете - у вас получается пусть немного, но уже другая игра с другим балансом (кто быстрее нажал).
было: в случае обновления законодательной базы парсит нововведения и получает новый PHP файлик выдачи документов.
стало: ну мы умеем форматировать данные по xsd.
Понятно.
> P.S. и да, это уже не "у меня" больше трех лет.. работает штатно, насколько понимаю..
Было "в вашем примере", стало "у меня". Смысл кавычем - в точности цитаты.
Впрочем я уже по предыдущему ответу всё понял, удачи вам.
Я не очень понимаю как это может быть устроено у вас с "синглтоном".
Есть "статический полиморфизм" (это по сути шаблоны / трэйты + мономорфизация)
Есть D2S фаза компиляции (у бинарных трансляторов и JIT-компиляторов), но она никак не привязана к "синглтону" - она просто собирает статистику по dynamic call destination и если это 1-2-3 варианта - просто вставляет статические джампы + ветка "не смогла".
А что у вас написано (в частности при чём тут синглтон) - я не понимаю.
ПС
При dynamic call сразу несколько сложностей:
1. Прочитать адрес вызова из VMT (в java к стати у объекта может быть целый вектор VMT а не одна) - из-за этого у java он скрыт за отдельной индирекцией.
2. предсказателю переходов намного сложнее работать с динамической информацией.
Она же скрыта за машинерией получения VMT, а не лежит по конкретному смещению +field_offset у объекта.
Ну если мы сравниваем C++ -classes мы C++ -templates то наверное да.
А вот если мы возьмём Rust - то там из коробки свичи (они там pattern-matching и называются match) exhaustive. Поэтому компилятор их за вас все сам найдёт и скажет: допиши ещё ону альтернативу пожалуйста.
Э... подождите в вашем примере парсится текст закона (и подзаконных актов). И по тексту закона, даже без промежуточного ТЗ, генерируется нужный нам код.
Это как?
Вы наверное хотели адресовать это к человеку выше?
Потому, что там был хитрый вопрос "вот выпилите ООП в кодовой базе на 100KLoC тогда поговорим" - и ответ "вот выпилил на проде в базе 10KLoС, доволен".
И да я так не считаю (часто Хаскель за счёт отделения кода от данных чудо как хорош, часто Rust за счёт управления ошибками (близко к аппаратуре) великолепен).
Но часто ООП очень полезен (иначе dyn в Rust не завозили бы).
Upd.
Сдаётся мне мы как-то сильно по разному это понимаем, ну или вы забыли (*) и подпись мелким шрифтом.
Ну вот я не согласен с вами. Как писал выше - переписывал библиотеку DSL-языка с полиморфизма на струкруты + switch.
Но это очень "алгоритмический" код. А вот бизнес-логику я бы так переписывать не стал - я не могу прямо определить что есть "бизнес-логика" что есть "алгоритмы". Но когда работаешь с кодом прям чувствуется.
Я рефакторил библиотеку DSL-языка на 10 КLoC (это включая заголовки) на С \ CPP.
Заменил полиморфизм свичами (defaul проверял экзостив в рантайм), списки массивами (для этого надо иметь нерасширяемый тип в заголовке библиотеке).
Ускорение в типовом случае в 5-7 раз (после сборки с -lto).
Значимых багов (после вылавливания изначальных с помощью тестового генератора) найдено не было. И уж точно не помню багов как-либо связанных с переписыванием.
Понятность кода после разворота динамических вызовов в свичи повысилась.
А я всегда думал, что это при выходе за границы буфера на запись (т.е. по сути риск испортить данные за пределами буфера).
У нас два разногласия:
- что значит действовать в соответствии с "обычаями делового оборота" и "что есть обычаи делового оборота" в данном случае.
По первому пункту:
Смотрите - если в трудовом договоре написано: а ещё в нербочее время делать кофе начальнику, то именно этот пункт признают недействительным, а трудовой договор в целом сохранят. Такая же логика распространяется и на другие договоры. Для ЗоЗПП это хорошо прописано и есть практика.
Я как не-юрист считаю, и даже почти уверен, что такие же имплицитные нормы применяются ко всем другим договорам (по духу права, источником которого в т.ч. являются обычаи и традиции делового оборота). Просто они или до ВС не доходили или не на слуху (что в нашем праве, что в прецедентном). Ну то есть это с изучения "основ права" осталось. Если юрист поправит - буду не прав.
Также по смыслу есть положения, что мы можем исходить из добросовестности второй стороны договора. И вот так работать, как будто договор составлен "честно". А если они на самом деле мошенники оказались и договор скам - их накажут, а нам что-то возместят (скорее всего суд скажет "требуем читать договор честно").
По второму пункту.
Есть некоторая "ситуация на рынке". Из которой люди исходят как из данности. Условно "день на тестовое" - это максимум (я делал такое на свою первую работу прогером). Больше - время должно быть оплачено.
Таковы сегодняшние реалии. Ну два дня можно. Но в ситуацию "делаю задание неделю а оно оплачено не будет" - никто не полезет из программистов. Просто так не делается сегодня (как суммы пишутся в десятичной и не пишутся в одиннадцатиричной системе счисления). И я бы такие формулировки считал "скамом" (не знаю мне иностранные слова кажутся менее жёсткими и "скам" не так эмоционально как "обман"), мелким мошенничеством, "ну прокатило".
Но если разбираться - нет ребята или вы на 2й 3й день говорите - ты прогер не нашего уровня. Или если уж неделю ждали - заплатите. Так в индустрии сегодня просто не делается (может мы все через год за еду с ChatGPT работать будем - но это будет через год). Никто такого не ожидает. И интервьюируемый в праве ожидать некоторого "разумного по-умолчанию" отношения.
Мне кажется, что вы пропустили "если" в этой фразе и распарсили её как вывод о вашей компетенции.
В то же время она читается так:
1. Рассмотренные статьи не позволяют вам делать выводов о том какая гипотеза правильная.
2. Из правила 1 есть единственное исключение - вы большой эксперт, тогда вы можете делать субьективные выводы.
3. Но к сожалению я как читатель не понимаю эксперт вы или нет => goto в пункт 1: могу пологаться только на объективные данные а их недостаточно.
Ок. Принимается.
Если я высказался о вашей компетенции - приношу извенения (* но я старался не: ниже цитата не о вашей компетенции, а о том, что я не могу её проверить - это же принципиально разные вещи).
Давайте попробуем ещё раз.
Мы имеем в вашем обзоре:
- с одной стороны мальчики для битья (важно уточнение вы над ними подтруниваете - т.е. обозначаете свою позицию).
- с другой стороны одно китайское исследование, вроде бы в тему, но одно и китайское.
И вот я как слушатель (я не прочитал столько статей сколько вы) какие выводы должен делать:
а) вы действительно перебрали всё подходящее и вытащили лучшее на наш суд - тогда это почти эквивалентно "исследований нет".
б) вы не очень хорошо искали и специально вытащили "мальчиков для битья" - тогда я тоже не могу сделать выводов.
Заметьте в любом случае я значимых выводов сделать не могу. По одной статье, тем более такой, они реально не делаются.
И второе замечание (ну как человека который читал и нормальные обзоры и ангажированные) - ирония в вашем обзоре заставляет подозревать вариант "б" с бОльшей вероятностью чем было бы без неё.
Вы пишете так, будто критерии оплаты в задании указаны объективно. Но они таковыми не являются.
Например "плавность анимации" - оценочное суждение. И да этот оценочный критерий есть как недостаток в фитбэке.
Смотрите человек имеет право считать, что перед ним не мошенники и исходить из этого в своих действиях (в том числе при интерпретации условий договора).
Если договор, как здесь, читается двумя способами "передо мной мошенники" или "они неудачно сформулировали договор" - я имею право действовать по второму сценарию и должен (во всяком случае в идеальном мире) выиграть такое дело в суде.
По факту мы имеем:
1. Договор должен соответствовать обычаям делового оборота
2. Мы читаем ТЗ на тестовое задание
3.а ТЗ, как его читал интервьюируемый - худо-бедно соответствует традициям делового оборота
3.б ТЗ, как его читал работодатель - резко не соответствует традициям делового оборота (по объёму это не ТЗ не тестовое)
4. В фидбеке правки никак не помогающие пройти тестовое, а валидные если объявление скам и вы пытаетесь сделать приложение.
Да и почему автор статьи простофиля, но не дурак не умеющий читать.
ТЗ может быть не скамом, только если его читать примерно как (это допустимое прочтение):
- сделать 1 страницу точно
- показать, что я вообще умею писать приложения такого рода (с прототипами остальных страниц)
- показать что я умею в плавную анимацию и тому подобные вещи (я не фронт)
- показать, что я умею внешний JS-код заворачивать для контрактов в нормальное окружение для работы.
Смотрите вы можете встать в позицию "не пойман не вор" (докажите что фразы (*) высокомерны - по мне человек отзывающийся так о докладах коллег нарушает этические принципы) - не вижу рациональных причин дальше тратить на вас время.
Я начал с максимально спокойного комментария, который мог бы сделать статью чуть лучше (в смысле она бы смотрелась чуть лучше) - если вам этого не надо, ну хорошо.
*)
Исследователи пришли к ошеломляющему результату, что на красном фоне текст читать тяжелее всего!
Феноменальным образом оказалось, что тёмный экран в совершенно тёмной комнате во всех
Учёные пришли к прорывному выводу, что красный
В этот раз авторы догадались добавить в сравнение негативную схему
«белое на чёрном», правда остальные схемы почему‑то всё такие же шизовые
Высокомерный тон (в тексте это высокомерные, поучительные обороты) которым вы комментируете статьи. Подчёркивание, что тема исследования неудачная (не плохо матчится на нас а именно неучачная).
Это типичные приёмы ангажированного обзора исследований (я этого не писал в исходном комментарии, чтобы выразиться помягче) - это одна из причин, по которой к вашей статье нет доверия. Вы не просто подобрали неудачные статьи на неустраивающую вас точку зрения, а ещё и попытались эмоционально их принизить.