Pzz>Я бы поспорил. Я думаю, нам для того и нужны хитроумные инструменты, потому что наши мозги по-другому думают, чем компьютеру было бы удобно.

Разница между мозгом и компьютером в том, что мозг — гибкий.
Не у всех, конечно, а у тех, кто мозг тренировал быть гибким (см. flexible vs rigid thinking). Это хорошая тема для обсуждения Но опять ведь обвинят в уходе в философию. Конечно, все философия — до тех пор, пока не начинаешь решать реальную задачу, и работать над одной проблемой в составе команды.

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

Прекрасно сказано! Эрланг, кстати, один из примеров такого инструмента.
Но сложность в том, что к этому инструменту приходят люди, долгое время (как бы даже не всю жизнь) работавшие только с императивным подходом. И зачастую еще и с полным непониманием асинхронности мира и задач, которые требуется решить. И виноват тут не инструмент. могу рекомендовать выступление Simon Peyton Jones — про новую программу CS в британских школах. Вот это, "The revolution of computing in schools" — нашел запись здесь. То, что он делает, — если взлетит — может ощутимо изменить ландшафт софтостроения.

Pzz> Мне, как человеку, прошедшему путь от самодельного компьютера на 8080 (и это был не Радио-86РК с интерпретатором бейсика, шестнадцетиричные коды которого публиковались в журнале)

Калькулятор МК-61. Ага, от розетки который работал (но мог и пару часов протянуть на трех батарейках, только батарейки было не достать в ту пору).
На другом конце кластеры из десятков тысяч машин, работу которых может разладить единственная неудачная команда.

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

Pzz>Go, кстати, чертовски сложный под капотом, видно, что настоящий хакер старой школы писал. Но наружу эта сложность практически не вылазит.

Да-да, это уже пол-эрланга, надо еще подождать, и будет полный.

Pzz>Ну ОК, разговор все равно состоялся приятный.



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

Вы только не говорите этого в какой-нибудь большой компании с глубокой иерархией. Да-да, Google, Apple, Facebook и т.п.. Нельзя вот так брать и резать правду-матку, или придется участвовать в обсуждениях про "токсичных девелоперов".

Pzz>Этого я просто не понял, объясни, что ты имел ввиду. Про instant signal, а не про КОБОЛ.

Попытаюсь в двух словах.
Суть в том, чтобы разработчик не раздражался по таким пустякам как бессмысленное ожидание.
1. Build (compile/assemble/link/...) должен быть мгновенным (200 мс и меньше). Иными словами, как только я закончил редактировать код/тест/конфиг, я не должен жать никаких кнопок, ждать 5 секунд пока взлетит компилятор, еще 10 секунд на разворачивание разных там докеров, инстанцирование чего-то еще, или запросов "а не компилировал ли кто-то где-то в интернете точно такой же код" (привет bazel).
2. Signal — подразумевается весь полезный сигнал от инструментария разработчика. То есть, lint, format, smoke tests (естественно, с test selection в соответствии с code coverage).
3. Интеграция инструментария (т.е. lint не отдельно где-то там, а прямо в IDE/vim/emacs).
4. Отсутствие любой необходимости (или полная прозрачность) "рестарта системы". Скажем, в том же эрланге, поддержка hot code load сделана по уму (а не как в java, где значительная часть попросту не работает).

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