Паттерны Command и Strategy с точки зрения функционального программирования

См. выше.

Паттерны Command и Strategy с точки зрения функционального программирования

Вы спорите о словах: называть паттерном реализацию без класса или не называть. По-моему тут важнее возможность построения изоморфизма: если возможно построить изоморфизм с описанием паттерна — то это тот же паттерн, иначе — нет.
В этом случае легко понять, что предложенные подходы на основе функций являются одними из возможных реализаций паттернов.

Несколько неожиданное поведение кеширования при boxing-е

Объект Null — вообще очень правильная тема. NPE — очень неприятная ошибка :-)
Я бы вообще запретил использовать ссылки на null, требуя для таких случаев создания специального Null-объекта.

Exception-ы и мифы о них

Например, в Java накладным расходом на throw является сохранение в объекте Exception всего stack trace, что являет довольно дорогой операцией. Поэтому такими средствами нужно пользоваться либо в случае некритичности по времени, либо при завершении вселго цикла обработки после обработки исключения. Если же ловить исключение на каждой итерации — просад может быть о-о-очень значительным.
Так что всему свое место, IMHO.

Exception-ы и мифы о них

В последнем примере должно быть отрицание:

static class SrcClassHelper
{
  public static void Exec(this SrcClass src)
  {
    if (!src.TryExec()) // Здесь было без !
      throw new MyException();
  }
}

Концепция баррикады

В случае Java многие уже используют аннотации типа @NotNull и @Nullable, а IDE проверяет, чтобы это было корректно. В итоге — делаем в одном месте проверку, возвращаем @NotNull — и в остальных местах уже можно не проверять.
Я думаю, через пару-тройку лет подобная фича будет реализована на уровне синтаксиса, причем не только для not-null, а также для range-check и тому подобных условий.

Ваша программа — дворецкий

Жаль только есть те, кто использует эти штуки без осознания плюсов, которые они принесут, а просто так, потому что «это клево».

Хорошо, что есть те, кто использует их, потому что «это клево».
Потому что именно они привносят творческие идеи в программирование.
Пусть не все из них удачны, но они есть, и лучших из них мы сейчас и используем.

Ваша программа — дворецкий

Обратное тоже верно, кстати :-) Если уж на то пошло.

Ваша программа — дворецкий

Мне тоже.
Но в общем случае без ошибок написать асинхронный софт — довольно сложная задача.
Причем часто проблема упирается в неявные косяки в различных библиотеках. Недавно только копался в Swing, пытаясь понять, почему при отложенном (invokeLater) изменении текста в редакторе все падает…

Ваша программа — дворецкий

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

Ваша программа — дворецкий

Программист интерфейсов обязан быть хорошим юзабилистом. IMHO.

Вы готовы поменять диплом на стартовый капитал?

(Разве что учился бы побольше и дурака валял поменьше :)

Далеко не все, кто так говорят, так бы и сделали )

Уверены, что хотите выполнить это действие?

К сожалению, временные затраты на восстановление при этом никто не отменяет.
Хотя их и стануовится существенно меньше.

Уверены, что хотите выполнить это действие?

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

Уверены, что хотите выполнить это действие?

Если это DDL, то транзакции не спасут, увы.

Алгоритм подготовки данных для сжатия

Лучше сказать об этом в конце семестра, недели за две до зачетов )
После чего студентов ждет творческая работа по переработке всех лекций.

Как Ларри Пейдж изучал Java

… писать код.

Как Ларри Пейдж изучал Java

Главное — делать )
А думать многие умеют.

Пробелы VS табы 4. Смерть всем

См. коммент из предыдущих серий.

Пора завязывать

То, что я предлагаю, находится где-то между байт-кодом и текущим состоянием дел, когда код = текст. Существующие варианты байт-кодов не поддерживают взаимно-однозначное соответствие между синтаксисом и байт-кодом. Я же предлагаю взаимную однозначность для целей разработки. И стандартизацию подобного решения. А тогда уже любая IDE может это реализовать, стандарт-то будет открыт.