В свежих питонах сделали достаточно идейно выдержанный pattern matching. Навряд ли это поможет занять рынок тулзей для написания компиляторов, но, скорее всего, такого и не было в планах
Правда, эти шаблоны сделаны на обвязке из match/case, то есть, выглядят не так изящно, как хотелось бы, но всё же теперь они есть
Когда-то видел график чёт там объём кода на разных языках, хотел дать ссылочку, но не смог снова найти. Ну так вот, питон где-то в лидерах по компактности. Из "обычных" (которые не лисп, не фортран и не хаскель) переплюнул его, кажется, только перл, который читабельным никак не назовёшь
Уверяю, манифест (дзен) реально рулит. Если применять его к совершенно любому языку, то будет намного лучше. А типы не только можно указывать (аннотации типов), но даже и ведущие собаководы рекомендуют это делать. Насчёт this - ну хз. Не понял, как это он при вызове не указывается. Про магию len тоже не понял
Заточенность под ИИ и науку присутствует, видимо, просто потому что так звёзды сложились. Ошибка выжившего, иначе говоря. Не по хорошу мил, а по милу хорош. Раньше для интерактивщины и прототипирования были R и матлаб, но как-то по-тихому пиплЫ переползли на питон. А GIL тут не мешает. Он, если честно, вообще мало где мешает, чаще помогает. По сути, он защищает от выстрела в ногу. Во внешних вызовах нити не особо-то и нужны, а внутри библиотек (внутри чёрного ящика) они есть и как-то там работают себе. Но там их писали специально обученные люди, которые о выстрелах в ноги знают абсолютно всё и потому умеют уворачиваться
И снова не понял суть претензий к this. Как вообще без ссылки (указателя) на объект иметь доступ к полям объекта?
Ну вот, опять это "медленнее ". Top1 претензия к питону. Или top1 - это "нет многопоточности"? Всё время путаю, которая из них топовее
Скока ж можно-то? Ну медленнее, да. Как будто бы с этим кто-то спорит. Оно ведь и телефон медленнее компьютера, и отвёртка медленнее шуруповёрта, и лопата медленнее экскаватора, и велосипед медленнее космического корабля. Все примеры перечислять, где что-то медленнее чего-то - тысячи жизней не хватит
О! Идея! А давайте все лопаты запретим? Ну медленно же ж. И отвёртки заодно. И велосипеды, само собой
А ведь это те же самые люди, которые уверяют, что выборочно цитировать нехорошо...
Лично мне кажется, что решить делать коммерческий компилер на SQL не смог бы человек, разделяющий доминирующую точку зрения на выбор языка для написания компилеров. То же, вероятно, касается жс и питона
Тем не менее, и для питона есть разные библиотеки на эту тему, например, Python Lex-Yacc. Почему бы им и не быть? Не всегда нужна производительность парсинга офиглиард знаков в наносекунду
О, вспомнил. Я ведь и сам когда-то начинал переписывать некую антикварную тулзу на питоне с использованием pyparsing. Прототип умел разбирать управляющие инструкции со скоростью во много раз выше приемлемой. То есть, даже и компилять было не надо, хватало интерпретации. Правда, дальше прототипа дело не пошло, но вовсе не из-за медлительности рантайма
The pyparsing module is an alternative approach to creating and executing simple grammars, vs. the traditional lex/yacc approach
Перехожу к ответу на первый
Сильно подозреваю, что для разных заказчиков оценка насущности одной и той же задачи будет разной. Например, можно предположить, что для некоторых заказчиков написание компилеров имеет насущность, стремящуюся к нулю.
Одно из доказательств см. выше. Я-то поначалу думал, что коэффициент насущности задачи написания компилера высокий, но потом он устремился к нулю и где-то там уже который год бултыхается
Прощаю с лёгким сердцем, потому что я как раз и цитировал выборочно. Про недостатки питона знают чуть более, чем все, но при этом, наверное, не меньше народу почему-то уверены, что в хаскеле (и прочих типизированных языках) мёдом намазано
А суровая правда состоит, что там, как и везде, местами намазано мёдом, а местами не совсем тем, чем хотелось бы, чтобы было намазано
Вообще, лёгкость применения инструмента бывает обратно пропорциональна степени защиты. Простой пример: межкомнатная дверь и дверь сейфового хранилища. Понятно, что сейфовая безопаснее, но и ходить сковозь неё геморройнее. И тысячу человек в час она сквозь себя не пропустит, если каждый раз открывать-закрывать. И из этого же сравнения становится примерно понятно, почему питона в природе намного больше, чем хаскеля
Ни сейфовые, ни межкомнатные двери не ставят везде, где нужна дверь, поскольку универсальных дверей не существует и не может существовать. Но межкомнатные двери не ругают за то, что они не сейфовые, а питон ругают за то, что он не хаскель. Не посчитать ли нам с вами это явление странным?
Любые программы глюкуют. Все к этому привыкли, смирились и научились с этим жить. Проблема не в самом факте наличия глюка, а в том, насколько сильно он мешает выполнению производственных задач. Выгодно ли его исправлять. Потому что исправление - оно ж не бесплатное ни разу
Вот сказ о том, как одни и те же люди пишут на питонах и на хаскелях. Выводы достаточно неочевидные
баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией
программа на Haskell равно так же не защищена от сегфолтов
поиск программистов является проблемой
проекты на Хаскеле пишутся медленнее, чем на Питоне
сложное прототипирование
Это я, конечно, не к тому, что надо бегом бежать всё переписывать на языки с динамической типизацией, а к тому, что ни фига нет ничего идеального в этом, блин, несовершенном мире
Неплохая иллюстрация того, почему статьи из этих ваших интеренетов следует воспринимать критически
Раньше - подтверждаю, через datatable было быстрее, но с тех пор, как прикрутили и допилили чтение через pyarrow, читать следует через него (по возможности)
Только что проверил на знаменитом датасете CSSEGISandData/COVID-19. Запускал несколько раз, так что данные закешировались, и скорость чтения с диска не участвует
Видно, что datatable с конверсией в pandas работает медленнее, чем родное чтение через pyarrow в 2 с лишним раза.
До кучи видно, что по дефолту оно (в этой версии pandas) читает как engine='c', а engine='python' работает чудовищно медленно. Раньше, помнится, по дефолту было именно python
1.4.1 1.0.0 4.0.1 92.2 ms ± 1.04 ms per loop (mean ± std. dev. of 7 runs, 10 loops each) 137 ms ± 1.68 ms per loop (mean ± std. dev. of 7 runs, 10 loops each) 294 ms ± 8.06 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) 2.43 s ± 19.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) 291 ms ± 1.95 ms per loop (mean ± std. dev. of 7 runs, 1 loop each) 56.3 ms ± 485 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
Можно рассуждать "как надо" или смотреть "как оно на самом деле". От первого подхода на душе приятнее, зато второй позволяет находиться немножко ближе к суровой реальности
Так вот, из статистики известно, что на хаскеле почти никто не пишет. Видимо, он всё же не настолько хорош, несмотря на мощную систему типов
Выходит, от языков мало, что требуется ещё что-то, кроме безопасности типов, так безопасность типов ещё и располагается где-то в хвосте списка требований, судя по тому, что на первых местах - JS, SQL и Python
Например, это можно объяснить тем, что эти языки ЛУЧШЕ хаскеля приспособлены решать НАСУЩНЫЕ задачи. А можно никак не объяснять и просто принять как факт, нравится он или нет. Ведь даже если не нравится, он не перестанет быть фактом
У меня на conda зависимости ломались. Еле починил. Причём requirements.txt не особо помогал. Вроде, и назад откатился, а всё равно не работало. Возможно, под старыми именами в репах валялись пересобранные пакеты, но не уверен
А по поводу "нетипизированные языки - зло, типизированные языки - добро" мне кажется, что это сравнимо с "город - зло, деревня - добро", "мясо - зло, овощи - добро" и так далее
По сути, какие объективные критерии существуют при выборе инструмента разработки?
стоимость разработки
сроки разработки
отсутствие критических задержек в исполнения кода
отсутствие критических ошибок в исполнении кода
стоимость сопровождения
При этом, очевидно, в разных бизнесах "критическими" будут считаться разные задержки и ошибки
Имеет ли смысл добавлять в список пункт "поддержка статической типизации"? Не думаю так, пока не увижу убедительной статистики, что типизация ускоряет и удешевляет разработку и сопровождение ПРИ ПРОЧИХ РАВНЫХ УСЛОВИЯХ. Тем более, что совершенно непонятно, как обеспечивать эти самые "прочие равные"
Так она во всех языках прикручена сбоку. В 100% случаев имеется возможность ругань компилятора обойти и прогу с ошибками запустить на исполнение. Например, typecast-ов понапихать везде, где оно ругается. Уверен, что есть over9000 программ, где именно так ошибки несовпадения типов и "исправлены"
Для примера, C++, Rust и Haskell - все статически типизированные, но во всех трёх это сделано по-разному. Какой подход правильнее? А какой удобнее в работе? Оба вопроса, разумеется, риторические
Статическая типизация - средство, а не цель. Где-то она помогает, а где-то, наоборот, мешает. Если б только помогала, то все языки были бы типизированными
Очевидно, что типизация помогает ловить ошибки, но так же очевидно, что помогает не бесплатно: и писанины вообще становится больше, и некоторые концепции становятся весьма трудноописуемыми
Да и потом, если б типизация была панацеей, так ведь нет, ошибки содержатся в программах, написанных на любых ЯП
Но ведь в современном питоне можно использовать типы, и можно настроить среду так, что соответствие будет проверяться сразу при написании. Это почти полноценный аналог ловли компилятором несовпадений типов. Другое дело, что типизация опциональна, но если СИЛЬНО бить по рукам, когда разраб использует нетипизированные переменные, то он быстренько привыкнет, что так делать низзя
Можно даже делать приведение типов (typecast)
Примерчик:
def myfunc(int_var: int, complex_var: MyComplexType) -> MyComplexType2: ... do something ... myint: int = 2 mystr: str = cast(str, myint) ... do something more ... return complex2_value
Там есть некоторые подводные камни, но в целом ситуация на тему проверки типов уже значительно улучшилась и продолжает улучшаться
Лично я мангами/комиксами не увлекаюсь, но оба города грехов пересматривал раз по ..надцать и раз по нескольку - оба канонических полнометражных гитса. Так что будущее почти что неизбежное "нейросетевое кинофицирование" комиксов категорически одобряю
Ну я вообще с джиттером боролся долго. Перешшупал, кажется, все варианты, до которых смог дотянуться. В конце концов, кажется, примерно понял, как это работает, поднастроил всякие там буферы-кодеки-оверлеи-тайминги (в MPC их хренова гора) и пришёл к выводу, что лично меня madVR без переключения частот устраивает чуть менее, чем полностью. Да и то, даже он часто избыточен. В принципе, чуть ли не единственный случай, когда вижу существенную пользу от его smooth motion - это 50-герцовые видосы из домашнего архива на 60-герцовом экране
В последнее время и вовсе обленился и гляжу, в основном, через встроенный плеер Kodi, где почти нет настроек видеовывода, и madVR не прикручивается. Переключение режимов и там есть, но, как говорил выше, не пользуюсь. Что мог, поставил на максимум и более-менее устраивает, как оно пашет без переключения
Но, разумеется, если захочется поглядеть какую-нибудь по-настоящему крутую киноху, то непременно переключу телек на киношную частоту, нахрен повыгоняю всех отвлекаторов, сяду поближе к экрану и буду смотреть, не отрываясь. Ибо замечено, что точные интервалы между кадрами и зыркание без отрывов таки значительно более способствуют вовлечению в зрелище, чем джиттер с паузами и перемотками. Только вот последний раз такое желание грабить корованы возникало года джва назад
Если оценивать научно-технический прогресс как положено, по достижениям в методах ведения войны, то становится очевидно, что никакого замедления нет и в помине
Потому что, собственно говоря, идея достижения превосходства над конкурентами как раз и является основным побудительным мотивом НТР
В свежих питонах сделали достаточно идейно выдержанный pattern matching. Навряд ли это поможет занять рынок тулзей для написания компиляторов, но, скорее всего, такого и не было в планах
Правда, эти шаблоны сделаны на обвязке из match/case, то есть, выглядят не так изящно, как хотелось бы, но всё же теперь они есть
Вот ведь как мозги-то по-разному у всех устроены. Для меня он читаемый как раз лучше паскаля, хотя до питона паскаль считал эталоном читабельности
Когда-то видел график чёт там объём кода на разных языках, хотел дать ссылочку, но не смог снова найти. Ну так вот, питон где-то в лидерах по компактности. Из "обычных" (которые не лисп, не фортран и не хаскель) переплюнул его, кажется, только перл, который читабельным никак не назовёшь
Уверяю, манифест (дзен) реально рулит. Если применять его к совершенно любому языку, то будет намного лучше. А типы не только можно указывать (аннотации типов), но даже и ведущие собаководы рекомендуют это делать. Насчёт this - ну хз. Не понял, как это он при вызове не указывается. Про магию len тоже не понял
Заточенность под ИИ и науку присутствует, видимо, просто потому что так звёзды сложились. Ошибка выжившего, иначе говоря. Не по хорошу мил, а по милу хорош. Раньше для интерактивщины и прототипирования были R и матлаб, но как-то по-тихому пиплЫ переползли на питон. А GIL тут не мешает. Он, если честно, вообще мало где мешает, чаще помогает. По сути, он защищает от выстрела в ногу. Во внешних вызовах нити не особо-то и нужны, а внутри библиотек (внутри чёрного ящика) они есть и как-то там работают себе. Но там их писали специально обученные люди, которые о выстрелах в ноги знают абсолютно всё и потому умеют уворачиваться
И снова не понял суть претензий к this. Как вообще без ссылки (указателя) на объект иметь доступ к полям объекта?
Спс, я старалсо
Лично я вообще не в восторге от его использования в качестве "баша на стероидах". Слишком много бойлерплейта на каждый чох
Ну вот, опять это "медленнее ". Top1 претензия к питону. Или top1 - это "нет многопоточности"? Всё время путаю, которая из них топовее
Скока ж можно-то? Ну медленнее, да. Как будто бы с этим кто-то спорит. Оно ведь и телефон медленнее компьютера, и отвёртка медленнее шуруповёрта, и лопата медленнее экскаватора, и велосипед медленнее космического корабля. Все примеры перечислять, где что-то медленнее чего-то - тысячи жизней не хватит
О! Идея! А давайте все лопаты запретим? Ну медленно же ж. И отвёртки заодно. И велосипеды, само собой
А ведь это те же самые люди, которые уверяют, что выборочно цитировать нехорошо...
Захотелось вначале ответить на второй вопрос
Ключевое слово - мне. Не?
Лично мне кажется, что решить делать коммерческий компилер на SQL не смог бы человек, разделяющий доминирующую точку зрения на выбор языка для написания компилеров. То же, вероятно, касается жс и питона
Тем не менее, и для питона есть разные библиотеки на эту тему, например,
Python Lex-Yacc. Почему бы им и не быть? Не всегда нужна производительность парсинга офиглиард знаков в наносекундуО, вспомнил. Я ведь и сам когда-то начинал переписывать некую антикварную тулзу на питоне с использованием pyparsing. Прототип умел разбирать управляющие инструкции со скоростью во много раз выше приемлемой. То есть, даже и компилять было не надо, хватало интерпретации. Правда, дальше прототипа дело не пошло, но вовсе не из-за медлительности рантайма
Перехожу к ответу на первый
Сильно подозреваю, что для разных заказчиков оценка насущности одной и той же задачи будет разной. Например, можно предположить, что для некоторых заказчиков написание компилеров имеет насущность, стремящуюся к нулю.
Одно из доказательств см. выше. Я-то поначалу думал, что коэффициент насущности задачи написания компилера высокий, но потом он устремился к нулю и где-то там уже который год бултыхается
Прощаю с лёгким сердцем, потому что я как раз и цитировал выборочно. Про недостатки питона знают чуть более, чем все, но при этом, наверное, не меньше народу почему-то уверены, что в хаскеле (и прочих типизированных языках) мёдом намазано
А суровая правда состоит, что там, как и везде, местами намазано мёдом, а местами не совсем тем, чем хотелось бы, чтобы было намазано
Вообще, лёгкость применения инструмента бывает обратно пропорциональна степени защиты. Простой пример: межкомнатная дверь и дверь сейфового хранилища. Понятно, что сейфовая безопаснее, но и ходить сковозь неё геморройнее. И тысячу человек в час она сквозь себя не пропустит, если каждый раз открывать-закрывать. И из этого же сравнения становится примерно понятно, почему питона в природе намного больше, чем хаскеля
Ни сейфовые, ни межкомнатные двери не ставят везде, где нужна дверь, поскольку универсальных дверей не существует и не может существовать. Но межкомнатные двери не ругают за то, что они не сейфовые, а питон ругают за то, что он не хаскель. Не посчитать ли нам с вами это явление странным?
Для простоты рассуждений соглашусь, что именно так дела и обстоят, но ведь безошибочность программ не является целью их написания. Программы нужны для выполнения задач. И вот тут (внезапно) выясняется, что абсолютно всё определяется сроками и стоимостью написания минимально рабочего кода, затем дополнения функционала и правки ошибок. При этом знаменитая Строгая Типизация ©, как ни странно, не особо-то и спасает отцов русских демократий
Любые программы глюкуют. Все к этому привыкли, смирились и научились с этим жить. Проблема не в самом факте наличия глюка, а в том, насколько сильно он мешает выполнению производственных задач. Выгодно ли его исправлять. Потому что исправление - оно ж не бесплатное ни разу
Вот сказ о том, как одни и те же люди пишут на питонах и на хаскелях. Выводы достаточно неочевидные
Haskell в продакте: Отчёт менеджера проекта
баги в программе на Хаскеле фиксить сложнее, чем в языках с динамической типизацией
программа на Haskell равно так же не защищена от сегфолтов
поиск программистов является проблемой
проекты на Хаскеле пишутся медленнее, чем на Питоне
сложное прототипирование
Это я, конечно, не к тому, что надо бегом бежать всё переписывать на языки с динамической типизацией, а к тому, что ни фига нет ничего идеального в этом, блин, несовершенном мире
Неплохая иллюстрация того, почему статьи из этих ваших интеренетов следует воспринимать критически
Раньше - подтверждаю, через datatable было быстрее, но с тех пор, как прикрутили и допилили чтение через pyarrow, читать следует через него (по возможности)
Только что проверил на знаменитом датасете CSSEGISandData/COVID-19. Запускал несколько раз, так что данные закешировались, и скорость чтения с диска не участвует
Исходный файл 14 мегабайт, 3342 rows × 974 columns
Видно, что datatable с конверсией в pandas работает медленнее, чем родное чтение через pyarrow в 2 с лишним раза.
До кучи видно, что по дефолту оно (в этой версии pandas) читает как
engine='c', аengine='python'работает чудовищно медленно. Раньше, помнится, по дефолту было именно pythoncsv_file = f"{path}/csse_covid_19_time_series/time_series_covid19_confirmed_US.csv"
import pandas as pd; print(pd.version)
import datatable as dt; print(dt.version)
import pyarrow; print(pyarrow.version)
%timeit dt.fread(csv_file, header=True)
%timeit dt.fread(csv_file, header=True).to_pandas()
%timeit pd.read_csv(csv_file, index_col=None, header=0)
%timeit pd.read_csv(csv_file, index_col=None, header=0, engine='python')
%timeit pd.read_csv(csv_file, index_col=None, header=0, engine='c')
%timeit pd.read_csv(csv_file, index_col=None, header=0, engine='pyarrow')
1.4.1
1.0.0
4.0.1
92.2 ms ± 1.04 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
137 ms ± 1.68 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
294 ms ± 8.06 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
2.43 s ± 19.4 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
291 ms ± 1.95 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)
56.3 ms ± 485 µs per loop (mean ± std. dev. of 7 runs, 10 loops each)
Можно рассуждать "как надо" или смотреть "как оно на самом деле". От первого подхода на душе приятнее, зато второй позволяет находиться немножко ближе к суровой реальности
Так вот, из статистики известно, что на хаскеле почти никто не пишет. Видимо, он всё же не настолько хорош, несмотря на мощную систему типов
Выходит, от языков мало, что требуется ещё что-то, кроме безопасности типов, так безопасность типов ещё и располагается где-то в хвосте списка требований, судя по тому, что на первых местах - JS, SQL и Python
Например, это можно объяснить тем, что эти языки ЛУЧШЕ хаскеля приспособлены решать НАСУЩНЫЕ задачи. А можно никак не объяснять и просто принять как факт, нравится он или нет. Ведь даже если не нравится, он не перестанет быть фактом
Любые ограничения безопасности можно как-то обойти. Это ж классическое противостояние брони и снаряда
Как говорил Квай-Гон Джинн, всегда найдётся рыба крупнее
У меня на conda зависимости ломались. Еле починил. Причём requirements.txt не особо помогал. Вроде, и назад откатился, а всё равно не работало. Возможно, под старыми именами в репах валялись пересобранные пакеты, но не уверен
А по поводу "нетипизированные языки - зло, типизированные языки - добро" мне кажется, что это сравнимо с "город - зло, деревня - добро", "мясо - зло, овощи - добро" и так далее
По сути, какие объективные критерии существуют при выборе инструмента разработки?
стоимость разработки
сроки разработки
отсутствие критических задержек в исполнения кода
отсутствие критических ошибок в исполнении кода
стоимость сопровождения
При этом, очевидно, в разных бизнесах "критическими" будут считаться разные задержки и ошибки
Имеет ли смысл добавлять в список пункт "поддержка статической типизации"? Не думаю так, пока не увижу убедительной статистики, что типизация ускоряет и удешевляет разработку и сопровождение ПРИ ПРОЧИХ РАВНЫХ УСЛОВИЯХ. Тем более, что совершенно непонятно, как обеспечивать эти самые "прочие равные"
Так она во всех языках прикручена сбоку. В 100% случаев имеется возможность ругань компилятора обойти и прогу с ошибками запустить на исполнение. Например, typecast-ов понапихать везде, где оно ругается. Уверен, что есть over9000 программ, где именно так ошибки несовпадения типов и "исправлены"
Почему-то никто не упомянул poetry, а ведь, по слухам, оно помогает решать проблемы с ломающимися зависимостями
Для примера, C++, Rust и Haskell - все статически типизированные, но во всех трёх это сделано по-разному. Какой подход правильнее? А какой удобнее в работе? Оба вопроса, разумеется, риторические
Статическая типизация - средство, а не цель. Где-то она помогает, а где-то, наоборот, мешает. Если б только помогала, то все языки были бы типизированными
Очевидно, что типизация помогает ловить ошибки, но так же очевидно, что помогает не бесплатно: и писанины вообще становится больше, и некоторые концепции становятся весьма трудноописуемыми
Да и потом, если б типизация была панацеей, так ведь нет, ошибки содержатся в программах, написанных на любых ЯП
Но ведь в современном питоне можно использовать типы, и можно настроить среду так, что соответствие будет проверяться сразу при написании. Это почти полноценный аналог ловли компилятором несовпадений типов. Другое дело, что типизация опциональна, но если СИЛЬНО бить по рукам, когда разраб использует нетипизированные переменные, то он быстренько привыкнет, что так делать низзя
Можно даже делать приведение типов (typecast)
Примерчик:
def myfunc(int_var: int, complex_var: MyComplexType) -> MyComplexType2:... do something ...
myint: int = 2
mystr: str = cast(str, myint)
... do something more ...
return complex2_value
Там есть некоторые подводные камни, но в целом ситуация на тему проверки типов уже значительно улучшилась и продолжает улучшаться
Несвязанного кислорода, я имел в виду
Лично я мангами/комиксами не увлекаюсь, но оба города грехов пересматривал раз по ..надцать и раз по нескольку - оба канонических полнометражных гитса. Так что будущее почти что неизбежное "нейросетевое кинофицирование" комиксов категорически одобряю
Ну я вообще с джиттером боролся долго. Перешшупал, кажется, все варианты, до которых смог дотянуться. В конце концов, кажется, примерно понял, как это работает, поднастроил всякие там буферы-кодеки-оверлеи-тайминги (в MPC их хренова гора) и пришёл к выводу, что лично меня madVR без переключения частот устраивает чуть менее, чем полностью. Да и то, даже он часто избыточен. В принципе, чуть ли не единственный случай, когда вижу существенную пользу от его smooth motion - это 50-герцовые видосы из домашнего архива на 60-герцовом экране
В последнее время и вовсе обленился и гляжу, в основном, через встроенный плеер Kodi, где почти нет настроек видеовывода, и madVR не прикручивается. Переключение режимов и там есть, но, как говорил выше, не пользуюсь. Что мог, поставил на максимум и более-менее устраивает, как оно пашет без переключения
Но, разумеется, если захочется поглядеть какую-нибудь по-настоящему крутую киноху, то непременно переключу телек на киношную частоту, нахрен повыгоняю всех отвлекаторов, сяду поближе к экрану и буду смотреть, не отрываясь. Ибо замечено, что точные интервалы между кадрами и зыркание без отрывов таки значительно более способствуют вовлечению в зрелище, чем джиттер с паузами и перемотками. Только вот последний раз такое желание грабить корованы возникало года джва назад
Если оценивать научно-технический прогресс как положено, по достижениям в методах ведения войны, то становится очевидно, что никакого замедления нет и в помине
Потому что, собственно говоря, идея достижения превосходства над конкурентами как раз и является основным побудительным мотивом НТР