Здравствуйте, vdimas, Вы писали:
V>А как ты увидишь, если речь об усреднённых вещах?
V>Ты собирал статистику, проводил собеседования в разные годы?
Бремя доказательства лежит на утверждающем. Это оппонент делает утверждение о снижении среднего уровня программистов. Так что давайте адресуем вопрос про статистику и собеседования к нему.
А так — да, конечно же я проводил собеседования в разные годы.
Ну, и кроме собеседований я преподаю в ВУЗе, поэтому могу оценивать распределение уровней квалификации сегодняшних бакалавров и магистров. Никаких признаков проблемы, обозначенной ТС, не наблюдается ни там, ни там.
V>Например?
Из самого известного — "ошибка на миллиард долларов" Тони Хоара. (К квалификации Тони вопросы есть?)
Из чуть менее известного —
thread.stop()/suspend()/resume() в Java 1.0. Гослинг вроде тоже отнюдь не новичок, но тем не менее принял заведомо неудачное решение.
Ещё в ту же коробку — Java.util.Date.
Это практически хрестоматийный пример того, как можно сделать неправильно буквально всё. Начиная с того, что тип с value-семантикой реализован как mutable, и заканчивая тонкими проблемами взаимодействия с календарём.
https://programminghints.com/2017/05/still-using-java-util-date-dont/
V>Я вижу, что принятые ранее решения исходили (а) из ограничений аппаратуры и (б) были расчитаны в среднем на более способного программиста.
![](/Forum/Images/smile.gif)
Приведённые мной примеры — это грабли, которые никакого отношения к ограничениям аппаратуры не имеют, и от программиста ожидают не каких-то особенных способностей.
Ну, вот к примеру — с т.з. той же java.util.Date, "способный" программист отличается от "неспособного" тем, что в геттерах свойств выполняет defensive copy.
При этом никакого существенного улучшения качества программы не происходит — помимо замусоривания хипа и увеличения нагрузки на GC (что там у нас по ограничениям аппаратуры), клиентский код по-прежнему работает не так, как ожидают его авторы.
V>Концептуально нового? ))
V>Например?
Ну, например, я не ожидал, что в 21 веке смогут придумать какой-то новый вид скалярных индексов для СУБД. Казалось бы — после B-trees, hash, и bitmap индексов в этой области уже ничего нового не придумать.
Ан нет — апрель 2020,
PGM-index.
Прекрасная штука — все преимущества B-tree (range queries, nearest search), плюс значительная компактность (а, значит, меньше io-нагрузка, более высокий cache hit ratio, и все вытекающие).
Был ли возможен такой индекс в 1963? Да, конечно. Это не нейронки, обучение которых стало практически пригодным только после массового распространения многоядерных видеокарточек.
Математика в основе лежит общеизвестная, сложность алгоритмов — не выше, чем у B-tree. Просто — не додумались.
V>Я, наоборот, концептуально нового уже давно не вижу.