Здравствуйте, Cyberax, Вы писали:

>> Почему-то никто не удивляется, что нельзя просто так взять карандаш и
>> нарисовать портрет или пейзаж -- этому нужно долго учиться. Хотя чего
>> тут сложного: бумага, карандаш, ластик. Все просто и интуитивно понятно.

C>Предположим, что человек уже умеет рисовать, а ему дают карандаши,
C>которые надо 2 года осваивать.

...И поэтому ну на фиг эти карандаши, я и дальше фломастерами плакаты лепить буду!

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

C>А вот в Emacs'е мне пришлось прежде чем начать работу:
C>1. Прочитать достаточно большой мануал
C>2. Поэкспериментировать с софтом
C>3. Поотлаживать код в elisp'е

C>При этом меню в Emacs такое, что ничем особо не помогает. Сейчас вот 40
C>минут искал опцию, чтобы заставить speedbar открывать файлы при нажатии
C>enter, но не переключаться на них сразу.

А вот мне интересно, тебе это реально надо было? Нет, ну серьезно, подумай. Вот не включил бы ты эту опцию и тратил бы на открытие файла на 5 секунд больше. 40 минут -- это время открытия 480 файлов. Если ты работаешь с 40-ка файлами каждый день, то этого времени тебе хватит на 12 рабочих дней -- две недели. Теперь представь, что вместо поиска опции самому, ты бы запостил вопрос о существовании этой опции сюда. И продолжил бы отрывать файлы по старинке. Мне кажется, что за две недели кто-нибудь из emacs-оводов бы тебе чего-нить подсказал. И может даже чего-нибудь более полезного.

Я вот, например, чуть больше года назад волевым усилием заставил себя пересесть из SciTe в vim (как раз тогда много приходилось по telnet-у и ssh на удаленных машинах работать). И что ты думаешь, после прочтения vim tutor я стал продвинутым пользователем vim-а? Да ни в жисть! Первые месяцы я вообще кроме h, j, k, l, dd, x, X, y, p, P, o, O, u, ^R и перехода в Visual-mode ничего не мог запомнить -- за всем приходилось в help заглядывать. И уж совсем смешно -- первый месяц я думал, что в Vim можно только один файл редактировать (ну не дочитал я сразу в tutor-е про буфера и окна). А как между буферами переключался: сначала :ls, затем находил имя и номер буфера, затем :b<номер>. Потом узнал, что можно :b<фрагмент имени>. А как я был счаслив, когда вычитал про :b# Самому смешно вспоминать. И такие маленькие (а иногда и не очень) приятные открытия сопровождают меня до сих пор. Вот недавно, например, в форуме "Средства разработки" подсказали принцип комбинаций ciw, diw -- ну очень помогает. А сейчас многие команды vim мне кажутся намного удобнее аналогичных из Visual-сред. И даже новые файлы в Vim через :e + автодополнение по tab мне открывать гораздо удобнее, чем через Open File Dialog в Word-е.

Так к чему это я. Да к тому, что лично у меня процент времени, который занимает набор кода в vim, намного меньше 50% от времени, которое я трачу на разработку (может быть даже меньше 30%). Гораздо больше времени уходит на проектирование, тестирование и документирование. Поэтому затраты на изучение и овладение новой средой (emacs или vim) оказывают незначительное влияние на время всей разработки.

Ну а Unix, в моем представлении, это вообще среда не для спешки. Ну куда можно спешить в системе, которой уже под 30 лет и которая еще столько же счастливо прожить собирается? Днем/неделей раньше, днем/неделей позже -- какая разница. Ну не пишут под Unix софт, который пользователь пару раз запустит, полюбуется на диалоговые окошки с картинками и снесет нафиг. Наоборот, делают системы, которые месяцами, годами работают без перезагрузки и участия пользователя/администратора. А если программа будет работать 5-10 лет без серьезных upgrade, с минимумом необходимых patch-ей, то так ли будет важно, что при ее написании один из разработчиков тратил на открытие одного файла в emacs на пять секунд больше, чем в Visual Studio (да и то в первые три-четыре недели разработки)?