Экспресс-додзё имени Хомского

Недавние мысли Дяденьки Бобби вслух про Истинный Путь Самурая в применении к софтверной индустрии растревожили одну, уж было заснувшую в темных пучинах моего сознания, смутную идею. Надо законспектировать, пока не заснула опять.

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


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

Однако языками (особенно императивными) дело не ограничивается, и даже не всегда начинается. Действительно, плюс-минус синтаксис, ну какая фигня. Сегодня C++, завтра Java, вчера C#, hell of a difference. Главное, чтобы алгоритм был годный, дизайн внятный, и минимальное тестирование не подвело.

Хуже, синтаксису можно как-то научить, и можно научить алгоритмам; набор повседневно используемых синтаксических фокусов и алгоритмов крайне невелик. Тестированию тоже, это вообще вопрос сугубо дисциплины: если больно бить палкой каждый раз, как в репозиторий влит некомпилирующийся (или не работающий сразу же после запуска) код, оно обязано принести неплохие результаты.

Но как научить применять алгоритмы правильно? Дизайнить внятно как научить?

Иными словами – не срать под себя синтаксису языка программирования обучить несложно; но как обучить внятно говорить, а не лепетать по-детски “языку” дизайна и алгоритмистики?

Глубинная мудрость (не-)применения известных приемов приходит строго с опытом. Опыт приходит со временем. Времени практически всегда не хватает. Опытных тоже. (Изредка времени хватает. В таких случаях с технической точки зрения наступает счастье, зато счетчик “до дембеля осталось N дней” ускоряется – ну, скучно же очень все, ну!)

Однако ошибки, на которых падаван учится и обретает крупицы мудрости, – совершенно, совершенно типовые.

Отсюда немедленно возникает мега-идея обустройства проекта (с целью циничного превращения его в процесс). Что, если умудрится выделить типовой набор задач, типовой набор ошибок; прогонять несоответствующих стандартам падаванов через процесс решения этих самых задач; тыкать носом в классические ошибки; и кормить сахарком за их несовершение? Да, это N месяцев “работы” вчистую на выброс. Нет, это не трата денег в никуда. Недостаточно опытный боец в продакшн коде? Да он по штатному расписанию обязан немножечко вредить, если посчитать конечные время и деньги!

Мечта идиота – не просто додзё общего назначения, о котором говорит дядя Боб, и в котором послушники полируют дзен годами – а таки экспресс-додзё имени камрада Хомского, специализированное под практики каждого конкретного проекта – и в максимально сжатые сроки обучающее свеженанятых людей правильным практикам, на живых (хотя уже и не раз решенных) задачах.

Вот бы попробовать.

p.S.

…на самом деле додзё, конечно, категорически нельзя называть в честь товарища Хомского – долбаный мистик-левак хоть признает отличия в экспрессивной мощи, но при этом пропагандирует встроенную в человека универсальную грамматику – это ж подумать только, ребзя, вместо единственно верного учения материалистической партии в виде гипотезы Сепира-Уорфа!

Просто про Хомского авось хоть кто-то слышал.

  • Dmitry Tyurev

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

  • Sergei_am

    Я вообще не про проектирование.
    Про ‘как писать ежедневнъй код’ – чисто потренироватся и нутром почуствовать то другое.
    Ибо – вижу перед собой кодеров с многолетним стажем, которъе копипастят код, если не буквально, то с минимальнъми отличиями. Я не верю, что в такой ситуации такой кодер когда-то перестанет уже копипастить, ever.

  • Dmitry Tyurev

    >3) происходит не потому – что знают, но формулируют плохо, а потому – >что не представляют совсем.

    Вообще, действительно странно. На вопрос о виртуальной функции мне отвечают правильно 70-80% претендентов. Подробности про таблицу виртуальных функций могут выдать 10-15% претендентов. Правда, я не отношу этот вопрос к особенно важным. Гораздо показательнее как человек решает предложенные задача (несложные). Был прикольный случай – пришёл человек, рассказал, что несколько лет профессионально занимается программированием, даже писал игры и т.п. Я думаю: О! Надо срочно брать. Предложил ему кратенько описать на словах функцию,которая должна рекурсивно обойти дерево каталогов, начиная с указанного. Так он минут 10 пыхтел и так и эдак – не смог придумать, как написать такую функцию! Нормально? К счастью, это исключение. Любой студент отвечает на такие вопросы не задумываясь.

  • Dmitry Tyurev

    >Ибо – вижу перед собой кодеров с многолетним стажем, которъе копипастят >код, если не буквально, то с минимальнъми отличиями. Я не верю, что в >такой ситуации такой кодер когда-то перестанет уже копипастить, ever.

    Угу. Старые кодеры не всегда пишут идеальный код. И переучивать их гораздо сложнее, чем новичков. У нас есть один товарищ – вроде как, не совсем новичок, писал самостоятельно гонки в 3d с неплохой физикой, сделал небольшой 3d-редактор и т.п. Но при этом пишет омерзительный си-стайл код, функции огромного размера, всё очень неструктурированно и неаккуратно. Пытаемся переучивать, но без особого успеха. :( С другой стороны есть человек, который пишет аккуратный С++ код, но допускает грубые архитектурные ошибки. Нет в жизни счастья. :)

  • coolace

    Частично помогал такой подход: в относительно локальных, но боевых задачах заставлять писать юнит тесты и описывать места как тот код, что написан будет\может глючить, заставлять рассказывать об этом. Эта метода даже не новичкам помогает. Заставлять вылизывать локальные задачи до блеска. Заставлять думать. Потом как освоится предлагать ему помочь подумать над твоими собственными задачами и после обдумывания делиться мыслями. И опять заставлять думать.