• Инженерное нелюбопытство
    0
    Разве? Я конечно что вижу ближе всего то и описываю, но кажется будто такая обстановка везде.
    Сейчас со стороны кажется что абсолютно везде движение вширь идет огромными темпами. В плюсах — стандарт каждый год, люди с ума начинают сходить. Системщикам приезжают Rust, Zig, у которых много концептуально других подходов: я подписан на несколько блогов и видно что Rust сообщество кипит просто и генерирует нереально много новых вещей. Бэкенд трансформируется от монолитных монстров до распределённых систем по умолчанию, алгоритмы консенсуса из академических кругов выходят в стандарт индустрии. Пользовательские приложения обрасли целевыми платформами и огромным количеством вендор-зависимостей, десктоп пора под ARM будут собирать, придется разбираться с оптимизацией под платформу, плюс и окружения на месте не стоят. Даже в каких-то базовых вещах казалось бы ничего не должно происходить, мол с вводом-выводом все уже придумали, но вон читаю что в Linux io_uring-который-изменит-всё (ну не всё, но под руку попалось). Да даже банальщина какая-нибудь — сейчас же пакет-менеджер нужен всем: я не припомню чтобы программисты на делфи условные лет 5 (ладно, наверное уже 10) назад нуждались в пакет-менеджерах, NuGet всего 10 лет — объём готовых документированных решений в любой сфере стал выше, всё — конструктор, и нужно прежде всего знать, какие детали есть, а не как они работают.

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

    Я не говорю, что мозг среднего разработчика стал больше или люди стали, внезапно, понимать больше в среднем. Хороший инженер как знал «очень много», так и будет вынужден знать «очень много». Просто подход к получению и изначальная структура этох знаний изменилась. Был больше дедуктивный, стал больше индуктивный.
  • Инженерное нелюбопытство
    +1
    Я как недавний студент решил всё-таки вспомнить аккаунт на хабре и высказать несколько мыслей по этому поводу:

    Дело, как по мне, в том, что область знаний (не концептуальная, а, скажем, IT эрудиции) за последние даже не 20, а 5 лет выросла до невозможных объёмов. Сейчас условному изучающему веб студенту нужны: webpack, понимание (примерное) как работают хранилища состояний, как работает shadow dom, как работают варианты подключения модулей в js, как работает ваша библиотека/фреймворк, как работают дочерние библиотеки для разных типовых задач, как копаться в апи, как поставить правильный npm, как работать с git, как оформить это так чтобы в галеру приняли, и прочая. Когда я начинал еще в подростковом возрасте я брал js и просто дёргал элемент. И решал свою задачу на юкозе. Сейчас такие решения просто невалидны. Они не нужны никому. Я плавно прогрессировал от небольших либ, условные деды от ассемблера, а студенты сейчас среди десятка гигантских фреймворков выбирают. Несколько лет назад условный Zend казался мне каким-то гипер-усложнённым гигантом, и если бы я начал свой путь с того, чтобы разобраться в нём перед решением задач, я бы закончил на петле, простите за чёрный юмор. А сегодня он даже и не нужен никому. Сейчас всё условно «большое».

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

    Человек видит «проект» — ему не очень интересно, какой он там внутри, он его редактирует — наверное умные дяди до него сделали так что всё внутри, какая разница. Для меня заголовочные файлы в си — странное явление. Почему такие вещи вообще нужны, и что за проект такой который файлы собирает? Почему на других языках у меня есть autoloader который сам всё ищет а тут как-то через чёрный ящик все классы друг о друге знают. Это ведь всё на самом деле вопросы с кроличьей норой если в них разбираться. А фреймворк-который-изменит-всё ждёт сейчас.

    Второе — это интересное следствие (позитивное или негативное — очень сильно зависит от взглядов) того, что мне лично сейчас неинтересны маленькие задачи, и, подозреваю, студентам тоже — я от них пока еще недалеко. Первое время было прикольно сдать лабу на хаскеле с выводом дерева, какой-то датасет из лабы обработать в R, попробовать написать что-то простое на ассемблере, et cetera. Сейчас, при поверхностном знании инструментов, которых хоть и стало очень много, можно реально делать в одном лице большие штуки. Если студент хочет в геймдев, ему наверняка не хочется заниматься тем, чтобы писать рендерер, когда у него в руках вот 2 топовых игровых движка с кучей решенных проблем — это хочется студенту, который пишет на расте.

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

    TL;DR: студентам не любопытно углубляться раньше времени в технологию, которая сейчас — просто одна из сотни даже для написания приложений для Windows — ведь сегодня они могут делать это хоть на Swift. Им сейчас куда любопытней смотреть в ширь: какие из тысяч технологий, применяемых сегодня, они могут использовать завтра.
  • 3D-движок, написанный на формулах MS Excel
    +1
    Это конечно здорово, но:
    1) Разве хэш медленный, если на каждый вариант клетки лабиринта нужно всего три (всегда по 2 стены) бита? То есть даже если брать медленный sha256, у нас целых 256 бит информации, из которых можно вытащить 64 клетки лабиринта с полными данными о 4 стенах. Не считая что есть более быстрые uniform хэши.
    2) Почему такой странный алгоритм лабиринта? Неужели ни Прима, ни Уилсона, не реализовать?