О значении командной строки «чушь»

Сначала прочтите это для понимания контекста. Выполнено? Хороший.

Остановите меня, если вы слышали это. Инженер-механик, инженер-химик и ученый-компьютерщик проезжают по улице. Машина ломается, и все трое выходят посмотреть, в чем дело. Инженер-механик говорит: «Я знаю, что не так, похоже, что штоки поршней смещены, если мы просто исправим это, все снова заработает». Она достает инструменты, начинает возиться с двигателем, и через 30 минут машина все еще не работает. Инженер-химик говорит: «Нет-нет, похоже, у нас проблема с кислородной смесью, она слишком богатая, и нам просто нужно ее настроить». Она вытаскивает кислородный датчик и начинает его настраивать, но через 30 минут машина все еще не едет. Ученый-компьютерщик говорит: «Я не понимаю, о чем вы двое говорите. Просто выключите машину, трижды хлопните левой пассажирской дверью, дважды обойдите машину, включите ее снова, и она снова заработает ». Они это делают, и вот, машина заводится.

Добро пожаловать в мир CS.

Есть аргумент, что работа с такого рода «ерундой» (бессмысленными, недружелюбными артефактами и интерфейсами) - это налог, который вы должны платить за выполнение работы. Этот аргумент говорит, что хорошая цель обучения (и точка остановки) - это процедурное мышление, которое позволяет вам заплатить налог, а затем продолжить свою жизнь. Я не думаю, что это правильно.

Я думаю, что не заставлять студентов бороться с чушью командной строки - это упущенная возможность обучения, которая имеет долгосрочные последствия как для их карьеры, так и - это звучит сенсационно, но терпите - для академической поле. А теперь вот поворот: меня на самом деле не волнует командная строка. Во-первых, меня волнует «чушь собачьей» и связанные с ней механизмы совладания (процессы мета-познания). Просто я думаю, что бит командной строки на самом деле является относительно безопасным местом для борьбы. Во-вторых, я не думаю, что это чушь собачья. Это результат философии, с которой мы можем не соглашаться, но все же развивались (и широко используются) по определенной причине.

Почему

Если вы посмотрите на большинство рамок задач обучения, вы обнаружите, что существует спектр от фактических (тип git clone) до процедурных (если вы видите это сообщение об ошибке, внесите следующие исправления; если вы видите это другое сообщение об ошибке, внесите эти другие исправления), в метакогнитивный (отразите свой прогресс в исправлении ошибки и настройте процедуры, которые вам нужны выполнять). Различия тонкие, но важные. Всем этим навыкам необходимо научить, но в зависимости от ваших целей вы можете остановиться на низком уровне (например, фактическом или процедурном). Я считаю, что образование исследователей (обучение людей тому, как быть исследователями) не может на этом останавливаться. В частности, потому, что мы, исследовательское сообщество, работаем на грани недружественного программного обеспечения, поэтому метакогнитивные навыки имеют решающее значение.

По мере того, как программное обеспечение становится «дружелюбным», студенты-исследователи фактически страдают из-за того, что у них нет высокоуровневых навыков преодоления трудностей (часто они возникают в результате мета-познания). Это студенты бакалавриата и магистратуры, которые переходят на работу с «своего рода» функциональным программным обеспечением с открытым исходным кодом. Но что более важно (по крайней мере, для этого поста), это мои аспиранты, которым нужно использовать новейшие исследовательские прототипы. Они приходят откуда-то еще и почти не компилируются, и то только если вы выключите компьютер, дважды пройдетесь вокруг него, произнесете пару молитв, подождете еще 10 секунд, а затем снова включите его (вы ждали, что я привяжу это шутить?).

Проблема не в том, что есть какой-то магический вызов, который заставляет эту работу, проблема в том, что следующее, что вы загрузите, потребует (что выглядит так) совершенно новый магический вызов. Это неизбежно. Это неизбежно, потому что мы работаем с другими людьми, которые не являются разработчиками программного обеспечения, которые прошли обучение наилучшим возможным процедурам. Это другие профессора и аспиранты, которым есть о чем беспокоиться. Это касается даже разработчиков с открытым исходным кодом. Да благословит их Бог, они делают потрясающие вещи (спасибо, люди с открытым исходным кодом, я люблю вас!). Но они также не особо заинтересованы в обновлении документации или программного обеспечения, работающего на конкретной машине, со случайным драйвером устройства, который был автоматически загружен на днях.

Что подводит нас к этой реальности. Однажды, и я почти уверен, что это произойдет, ваш ученик загрузит что-нибудь из Интернета, и он застрянет. Они застрянут так, что рецепт, которому вы их научили в первый день, не сработает. Они так сильно застрянут, что (1) им нужно будет обратиться к вам за помощью и / или (2) они бросят то, что скачали.

Обращение за помощью - не обязательно проблема, но действительно может быть. Когда ученик покажет вам, на чем он застрял, вы начнете применять свой многолетний опыт и изученные мета-навыки, гугл-фу и любые другие уловки, чтобы избавиться от проблемы. Это не 3 минуты работы и заставляет нескольких экспертов (читай: вас) ограничивать скорость. Понятно, что не идеальное и не масштабируемое решение.

Я поклонник этой философии менеджмента, когда вы добиваетесь успеха, если каким-то образом сумели избавиться от работы. Предоставление другим людям навыков для того, чтобы делать то, что вы делаете, имеет решающее значение как для их развития, так и для вашей компании. Этого нельзя добиться, просто обучая их запускать git, но давая им навыки, поэтому, когда они загружают какое-то программное обеспечение, которое использует дарки, потому что разработчик программного обеспечения это любит, ученик может понять это. Да, в краткосрочной перспективе неприятно. Простым решением было бы просто научить git и покончить с этим. Но я думаю, что исследование - это долгая игра (также: в какой-то момент им нужно закончить школу и обучить следующую группу студентов).

Это подводит нас ко второй возможной реакции: ученик отказывается от того, что скачал, и уходит делать что-то еще. Я считаю это трагичным. Часть академической деятельности (по крайней мере, в академических инженерных дисциплинах) заключается в том, что вы можете (а) строить работу других, чтобы создавать новые знания, и (б) сравнивать свою систему / решение с другими (да, создавать новые знания). Если вы не можете скачать, скомпилировать и использовать эту сумасшедшую программу, использующую какую-то библиотеку LISP, которая популярна только среди немцев, родившихся между 1980 и 1990 годами, но оказывается лучшей «частью» вашей исследовательской головоломки , это провал. Конечно, это их неудача из-за того, что они не упростили задачу, но это не то, что находится под вашим контролем или вашим докторантом. Если ученик откажется от этой наиболее подходящей части, работа окажется не такой хорошей, как могла бы или должна быть. Научный прогресс достигается благодаря упорному труду других, а это, к сожалению, требует определенной настойчивости.

Даже если я не могу убедить вас, что ваш ученик когда-нибудь обнаружит, что загружает какой-то сумасшедший фрагмент кода, надеюсь, вы узнаете другие виды «чуши», с которыми столкнется исследователь: странный псевдокод в статье с параметрами, которые кажутся определяемыми магия, которую вам нужно реализовать, или фрагменты кода, которые нужно извлечь из чего-то еще, или чей-то плохо документированный исходный код, который работал вчера, но не работает сегодня. Если вы живете на грани, вам нужно научиться бороться с ерундой. Трудно найти общие навыки совладания, которые позволят вам справиться с ерундой, а также специальные навыки совладания с информатикой. Если этому не научить рано, в относительно невысокой и легко исправляемой среде, позже будет только хуже.

Безопасность в командной строке

Даже если вы считаете, что «работа» с командной строкой - чушь собачья, позвольте мне сказать, что чушь с командной строкой - это безопасная чушь. Это безопасно, потому что это первый шаг, который должен сделать каждый разработчик, и безопасность в цифрах. Люди документируют свои усилия и создают для других следы из хлебных крошек. Такую информацию (относительно) легко найти. Да, это расстраивает, но в отличие от нашей сумасшедшей библиотеки LISP (которая, честно говоря, может оказаться невыполнимой задачей), заставить git запускаться или вызывать команды, чтобы они не останавливались, когда вы выходите из системы, действительно намного более выполнимо. На каких метакогнитивных навыках вы бы предпочли научиться?

Как

Итак, вот в чем проблема. Как нам сбалансировать метакогнитивное обучение с нашим желанием не отталкивать новых людей? Здесь я полностью согласен с аргументом Филиппа. Если вы предполагаете, что каждый может быть, есть или хочет быть хакером Unix, вы теряете много талантов. Я думаю, что для достижения и того, и другого (обучения и неотчуждения) требуется своего рода скриптовый хаос. Хаос, на поиски которого вам не придется тратить слишком много времени (просто вспомните последний раз, когда вы проклинали компьютер себе под нос). Сценарий там, где он находится. Это позволяет вам провести учащегося через «фигню» и продемонстрировать не только фактические или процедурные знания, которые могут это исправить, но и привитие метакогнитивных навыков, которые будут работать, когда факты и эвристика не помогут.

Если вы посмотрите видео Филиппа, которое, как я полагаю, является моделью для процедурного обучения, есть момент около 17 минут, в котором система выдает сообщение об ошибке (файл Python был написан для машины Windows, поэтому Mac не понимает путь). Демонстрируется исправление (откройте текстовый редактор, замените путь и т. Д.). Проблема в том, что мы нигде не узнаем, как он знал, как это сделать. Материал в видео потрясающий (я собираюсь посылать студентов посмотреть его), но в некоторых его частях есть ощущение, что это-то-то-то. По сути, цель обучения носит процедурный характер: просто введите X, когда увидите Y. Чтобы быть ясным, я думаю, что это нужно заменить на: вы видели Y, вот несколько стратегий для выяснения того, что означает Y, которые в конечном итоге приведут нас к X.

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

  1. Заставьте их поверить в то, что чушь (читай: диагностика и отладка странных вещей) - это часть жизни в мире компьютеров. Всегда есть соблазн использовать родительский «потому что я так сказал» или «учитель математики выучите эту математику, чтобы вы могли выучить математику сложнее». Я думаю, что очень важно сообщить правду о том, что эта работа - часть нашего мира, но вы можете найти способы справиться с ней. Это сложно. Мне бы хотелось, чтобы примеры, которые «показывают», а не «рассказывают» об этой реальности, легче анализировать.
  2. Стимулируйте поиск ответа. Этот я использую в своем классе, но думаю, что он также работает в исследовательских ситуациях. Я стараюсь отдать должное людям за попытки найти ответ. Например, если они могут указать мне на страницу переполнения стека, где есть что-то, что можно превратить в ответ: (немного) Кредит. Укажите мне на нужную страницу документации API: (немного) Кредит. Научиться «переводить» проблему в запрос Google и уметь находить ответ в куче мусора - это жизненный навык. Отдавая дань уважения людям за то, что они научились этому, мы мотивируем их усвоить сложный навык. Тот, который не является чисто процедурным.
  3. Покажите им, как вы (о великий и могущественный) справляетесь с неудачами. Раньше у меня были готовые слайды PowerPoint, которые я мог бы просмотреть, и которые просто работали. Это было здорово для обучения процедурным навыкам, но студенты полностью упустили бы тот факт, что я не запомнил и половины этого, когда писал слайды и мне приходилось тестировать и проверять 5 вещей, использовать Google и искать документацию. Это также заставило их казаться легким и, следовательно, личной неудачей, когда они не могли сделать это сами. С тех пор я перешел на «живое программирование». Это означает, что я терплю поражение перед ними, а затем показываю, как восстанавливаться. Это даже не так сложно. Моя дрянная память и плохое правописание делают большую часть работы за меня. Я должен отключить автозаполнение, чтобы было еще интереснее. Я пытаюсь сказать, на что я смотрю, когда читаю страницу, как я интерпретирую документацию API с 500 аргументами (трюк: игнорируйте те, которые имеют значения по умолчанию, чтобы начать) и как я разлагаю проблему на тестирование и проверку.
  4. Управляйте сценарием. Одна из вещей, которые мы часто делаем, чтобы сделать проблемы «реальными», - это внедрять в код неверные данные или ошибки. Думаю, здесь можно применить ту же идею. Вы можете контролировать количество «борьбы», с которой приходится иметь дело, создавая сценарии в основном для всего, за исключением пары важных частей, которые заставляют ученика учиться. Я думаю, вы можете найти подходящий уровень «сложного» для студента. Достаточно, чтобы они чему-то научились и ушли, чувствуя себя хорошо, что они справились с препятствием. У преподавателя, которого я очень уважаю, есть «упакованная» проблема для новых исследователей. Документ, некоторые данные, немного кода и тестовый сценарий - все настроено, и он передает их новым студентам. Отчасти это «тест». Вы действительно можете работать? Но я думаю, что это также можно превратить в возможность обучения по сценарию для мета-когнитивных задач.

Это то, что у меня есть на данный момент. Это не волшебное решение, и оно явно не сработает в каждой ситуации, но я надеюсь со временем выработать набор стратегий. Есть идеи? Пожалуйста, поделитесь ими.

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

Сноска: Почему я могу ошибаться, но думаю, что прав

Позвольте мне сказать, что этот пост не о:

  1. Дело в том, что мне приходилось подниматься на 4 мили (по снегу) в каждую сторону по дороге в школу, так что вы тоже должны это сделать. Я осознаю, что я стар (ну), что программное обеспечение изменилось, и что моя память искажена.
  2. Я считаю, что командная строка - лучшее, что есть после нарезанного хлеба. С одной стороны, у меня в офисе висит Unix barf bag. С другой стороны, мне нравится командная строка и я вижу в ней ценность. Но опять же, я тоже один из безумцев, которым нравится Perl. Я осознаю возможность того, что сошла с ума.
  3. Я считаю, что над учениками следует издеваться как часть их идеологической обработки (в основном я считаю, что культурное «инициирование» таким образом - глупо). Я понимаю, что «сложные вещи» могут иметь непредвиденные (читай: очень плохие) последствия.
  4. Думаю, это относится ко всем. Речь идет о том, чтобы научить будущих исследователей быть исследователями. Я предполагаю, что некоторые исследователи ОС будут ухмыльнуться при мысли, что этот разговор вообще необходим (да, да, мы поняли… вы твердолобый). Некоторые уроки действительно применимы к другим типам студентов, но я признаю, что существуют фундаментальные различия в опыте ученика и учебных целях инструктора.