Пользователь
0,0
рейтинг
13 декабря 2015 в 23:38

Разработка → Полный перевод Unix-коанов на русский язык



Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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


Master Foo & MCSE
Однажды к Мастеру Фу явился знаменитый Windows-администратор и спросил его совета:
— Я слышал, ты могущественный волшебник в мире Unix. Не согласишься ли на обмен секретами, от которого мы оба только выиграем?

— Хорошо, что ты ищешь мудрость, — ответил Мастер Фу, — Но в Великом Пути нет секретов.

Администратор выглядел обескураженным:
— Но ведь говорят, что ты — Великий мастер Unix-систем, кто знает глубочайшие их секреты! Как и я в Windows: я сертифицированный инженер Microsoft. У меня имеются и другие знаки отличия, которые в мире встретишь нечасто. Я помню наизусть даже самые мрачные закоулки реестра. Я могу рассказать всё о Windows API, даже те легенды, которые в самом Редмонде уже полузабыты. Что за тайное знание даёт тогда тебе твою силу?

Мастер Фу ответил:
— У меня нет ничего. Ничто не скрыто, нечего и раскрывать.

Возмущённый администратор воскликнул:
— Отлично! Скажи мне тогда, если нет у тебя секретов: что же мне нужно знать, чтобы стать таким же могущественным в Великом Пути как ты?

Мастер Фу промолвил:
— Человек, что принимает секреты за знание, похож на того, кто в поисках света так крепко хватается за свечу, что тушит её пламя и обжигает свою руку.

Услышав это, администратор обрёл просветление.

Master Foo Discourses on Returning to Windows
— Мы узнали, что Unix — это не только операционная система, но также и стиль решения проблем, — начал студент

Мастер Фу кивнул, соглашаясь.

Студент продолжил:
— Значит, Великий Путь подходит и другим операционным системам?

Мастер Фу замер на мгновение, затем сказал:
— В любой операционной системе есть тропинка к Великому Пути, если только мы способны найти её.

Студент продолжил:
— Как тогда насчёт Windows? Она предустановлена на большинстве компьютеров, и, хотя инструменты её в основном много примитивнее, их легко освоить новичкам. Windows непременно может извлечь пользу из Unix-философии!

Мастер Фу снова кивнул.

Студент сказал:
— Что ж, тогда возвращаются ли те, кто достиг просветления в Великом Пути, в мир Windows?

Мастер Фу ответил:
— Чтобы вернуться в Windows нужно просто загрузить её.

Студент воскликнул, распаляясь:
— Мастер Фу, если это так легко, почему тогда так много раздутых и сломанных приложений под Windows? Ведь и с графическим интерфейсом и модными цветами должна быть возможность писать элегантные приложения, но такое почти не случается. Что же тогда происходит с теми просветлёнными, кто возвращается в Windows?..

Мастер промолвил:
— Разбитое зеркало уже не отразит;
Опавшие цветы не вернутся на старые ветви.

Услышав это, все присутствующие обрели просветление.

Комментарий
Над этим коаном мне пришлось в своё время крепко подумать.

Возвращаясь в этот раз, я считаю, что под разбитым зеркалом Мастер понимал людей из мира Unix, кто, прельстившись сладостью и простотой, покинули сообщество ради собственного удобства и обогащения.
Опавшие цветы же — это те, кто вырос в мире, заполненном Windows во множестве, но, тем не менее, нашёл просветление и ушёл.

Опять же, вопрос «а каким образом они нашли просветление» будет раскрыт в следующих коанах.
Забегая вперёд, философия Unix расцветает в умах программистов практически спонтанно и на полу-интуитивном уровне. В каком-то смысле поначалу такие окружённые Windows являются пратьека-буддами.



Master Foo and the Script Kiddie
Однажды во время утренней трапезы к Мастеру Фу и его ученикам подошёл путешественник из страны Woot.

— R слышал, чт0 тbl э1337ен, — начал он, — Пожалуйс7а, обуч1 меня вс3му, что зн@ешь.

Ученики мастера переглянулись, смущённые варварским языком странника. Но Мастер только улыбнулся и ответил:
— Ты желаешь обучиться Пути Unix?

— Я х0чу бытb магом-хакер0м! — отвечал странник, — и овлад3ть всеми ящиками мира!

— Я не учу этому пути, — ответил Мастер.

Странник выглядел взволнованным:
— Чув@к, да тbl пр0ст0 позеR! — воскликнул он, — Знай ты х0тb что-н1будь, ты бы ра55казал мне!

— Есть путь, — сказал Мастер, — что может привести тебя к мудрости.
Он нацарапал IP-адрес на клочке бумаги и протянул страннику:
— Взлом этой машины не представит для тебя особой трудности, стражи её некомпетентны. Возвращайся и расскажи мне, что нашёл.

Странник поклонился и вышел. Мастер закончил свою трапезу.

Шли дни, за ними месяцы. Странник был позабыт.

Годы спустя путешественник из Woot вернулся.
— Будь ты проклят! — вскричал он с порога, — я взломал ту систему, и это было просто, как ты и сказал. Но ФБР схватили меня и бросили в тюрьму!

— Хорошо. — ответил Мастер, — теперь ты готов к следующему уроку.
Он нацарапал другой IP-адрес на бумаге и протянул страннику.

— Ты свихнулся?? — отпрянул тот. — После всего того, что со мной было, я и на милю не подойду к чужим ящикам!

Мастер Фу улыбнулся.
— Здесь, — промолвил он, — и начинается мудрость.

Услышав это, странник обрёл просветление.

Комментарий
Этот коан, наверное, самый известный из всех.
Жаль, но в переводах я нигде не видел литспика скрипт-кидди.

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



Master Foo and the End User
На очередном публичном выступлении Мастера Фу конечный пользователь, ведомый слухами о мудрости Мастера, пришёл к нему за советом.

Он поклонился Мастеру трижды.
— Я хочу научиться Великому Пути Unix, — начал он, — но командная строка приводит меня в замешательство.

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

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

Ученик начал, заикаясь, отвечать, но ничего не смог сказать.

Мастер Фу обернулся к пользователю.
— Расскажи мне, — спросил он, — почему ты ищешь Великий Путь?

— Я недоволен программным обеспечением, которое окружает меня, — сказал пользователь, — Оно не работает надёжно и не радует глаз и душу. Услышав, что Путь Unix, хоть и сложнее, но cовершеннее, я пытаюсь отбросить все барьеры и предрассудки.

— И чем занят ты в миру, — спросил Мастер, — что заставляет тебя бороться с программным обеспечением?

— Я архитектор, — ответил пользователь, — на многих домах в этом городе моя печать.

Мастер Фу повернулся обратно к ученику:
— Кошка может насмехаться над тигром, — сказал Мастер, — но это не превратит её мяуканье в рёв.

Услышав это, ученик обрёл просветление.

Комментарий
Этот коан я точно видел переведённым в «записках дебианщика».
И перевод там был отличный. Разве что Эрик прямо указывает в заметках, что хорошо бы использовать эквивалент «печать».



Master Foo and the Hardware Designer
Однажды, когда Мастер Фу направлялся на одну из конференций с несколькими старшими учениками, к нему обратился архитектор микросхем.

Он сказал:
— Ходят слухи, что вы великий программист. Как много строк кода вы пишете в год?

Мастер Фу ответил вопросом:
— Как много квадратных дюймов кремния вы изготавливаете в год?

— Чт… нет, мы, архитекторы железа, никогда не измеряем нашу работу таким способом, — ответил тот.

— А почему нет? — поинтересовался Мастер Фу.

— Если бы мы так поступали, — ответил архитектор, — Нас бы искушала возможность изобретать микросхемы столь большие, что они не могли бы быть изготовлены, а если даже и могли бы, их крайняя сложность создавала бы непреодолимые препятствия для корректного их тестирования!

Мастер Фу улыбнулся, затем поклонился ему.

В этот момент архитектор достиг просветления.


Master Foo and the Ten Thousand Lines
Мастер Фу как-то сказал посещавшему его программисту:
— В одной строчке баш-скрипта больше духа Unix, чем в десяти тысячах строк кода Си.

Программист, который весьма гордился своим мастерством в Си, возразил:
— Как такое возможно? Си это язык, на котором было написано самое ядро Unix!

Мастер ответил:
— Это так. И всё же, в одной строчке баш-скрипта больше духа Unix, чем в десяти тысячах строк кода Си.

На лице программиста отразилось огорчение:
— Но ведь через Си мы познаём благодать патриарха Ритчи! Мы становимся одним целым с операционной системой и машиной, достигая несравнимой производительности!

Мастер ответил:
— Всё это истинно. Тем не менее, в одной строчке баш-скрипта всё равно больше духа Unix, чем в десяти тысячах строк кода Си.

Программист усмехнулся и встал, желая уйти. Но Мастер Фу кивнул на своего ученика Ньюби, который прикидывал баш-однострочник на доске неподалёку, и спросил:
— Мастер программист, взгляните на этот конвейер. Написанный на чистом Си, не занял бы он десяти тысяч строк?

Программист бормотал сквозь бороду, созерцая начертанное Ньюби. Наконец он согласился, что это так.

— А сколько часов бы потребовалось, чтобы написать и отладить такую программу? — поинтересовался Ньюби.

— Много, — признал программист, — но только глупец стал бы тратить время на подобное, когда его ожидает столько куда более важных задач.

— И кто же лучше постигает дух Unix? — спросил Мастер Фу, — Тот ли, кто пишет десятки тысяч строк, или же тот, кто, понимая пустоту задачи, выигрывает, не написав ни единой?

Услышав это, программист обрёл просветление.

Комментарий
Гм, на самом деле этот коан немного отличается от остальных. Рассуждения о «Природе Будды», на которую здесь имеются отсылки, больше свойственны японским школам, поэтому некоторые слова должны переводиться иначе. Вместо «пустоты», например, в коане должна быть «шуньята» (отсутствие собственной природы или причинности у чего-либо), а вместо «просветления» — «сатори». Я перевёл таким образом чтобы сохранить единообразие с остальными коанами, но комментарий, тем не менее, необходим.



Master Foo and the Unix Zealot
Фанатик Unix, прослышав о мудрости Мастера Фу в Великом Пути, пришёл к нему за советом.

Мастер Фу сказал ему так:
— Когда Патриарх Томпсон изобрёл Unix, он не осознал этого. Позже он пришёл к пониманию, и не изобрёл более ничего.
— Когда Патриарх Макилрой изобрёл конвейер, он знал, что это преобразит программы, но он не знал, что это преобразит сознание.
— Когда Патриарх Ритчи изобрёл Си, он обрёк программистов на тысячу адов переполнения буфера, повреждения памяти и разыменования нулевого указателя!
— Воистину, патриархи были слепы и глупы!

Фанатика немало разозлили такие сентенции Мастера:
— Эти просветлённые, — возразил он, — завещали нам Великий Путь Unix. И если мы будем насмехаться над ними, мы потеряем всякое достоинство и переродимся как звери или инженеры Microsoft!

— Бывает ли код твой истинно чист от ошибок и упущений? — вопросил Мастер Фу.

— Нет, — признал фанатик, — такое не под силу человеку.

— Мудрость Патриархов, — промолвил Мастер, — в том, что они знали, что были глупцами.

После этих слов на фанатика снизошло озарение.

Комментарий
Почему-то последнюю строчку переводили частенько как «они были безумцами». Прискорбно, но от этого коан немного теряет смысл.

Патриархи знали, что они были глупцами — это так. Юникс был придуман и реализован совершенно стихийно, главенствовал принцип «механизм, не дизайн». Многое в поздние годы было подвергнуто критике — слишком примитивная модель безопасности, слишком много названий для одного и того же, контроль задач похож на заплатку…

Но при всей кажущейся хрупкости такой системы в работе с Unix-подобными ОС прослеживается та самая идея, за которую мы так и любим их, и которая, возможно, и легла в основу коана: «Пользователю виднее». Зная о своей недалёкости, патриархи сделали свои механизмы такими, чтобы не ограничивать тех, кто будет пользоваться плодами их трудов.

И сообщество воздало им сторицей.



Master Foo and the Programming Prodigy
Уже некоторое время до Мастера Фу и его учеников доходили слухи о необычайно одарённом молодом программисте, исходившем земли вдоль и поперёк, создавая шедевры программирования и помножая на ноль всех посмевших состязаться с ним.

В конце-концов молодой гений пришёл посетить Мастера, который встретил его с почтением и предложил ему чай. Гений принял его с ответной почтительностью и объяснил цель своего визита:
— Я пришёл к Вам, — сказал он, — в поисках оценки архитектуры и кода моего последнего проекта. Ибо проект этот исключительной сложности, и я не знаю никого, кто мог бы на равных объять его. Только признанный мастер, такой как Вы (и здесь гений низко поклонился), может обладать должной проницательностью.

Мастер Фу вежливо поклонился и приступил к изучению кода. Спустя некоторое время он поднял глаза от экрана:
— Код этот на первый взгляд выглядит очень впечатляюще, — сказал он, — его архитектура элегантна, в алгоритмах чувствуется оригинальность и искусность, и написан он с чрезвычайным тщанием, что минимизирует возможность ошибки.

Гений выглядел очень польщённым такой оценкой Мастера, но тот продолжил:
— Однако, я вижу один существенный недостаток.

— Недостаток? — встрепенулся гений, — Какой недостаток?

— Код этот сложно читать, — ответил Мастер, — он только слегка откомментирован, переменные его размыты, и я нигде не вижу описания логики и внутренних структур. Эти проблемы будут сильно препятствовать совместной работе с другими программистами.

— Я не ищу сотрудничества с иными программистами, — свысока ответил гений, — Меня постигало разочарование каждый раз когда я считал, что нашёл того, кто может сравниться со мной мастерстве. Поэтому я работаю один.

— Но даже работая один, хакер сотрудничает с другими и всегда должен изъясняться понятно, иначе работа его станет запутанной и забытой.

— Кто эти «другие», о которых вы говорите? — потребовал ответа гений.

Мастер Фу ответил:
— Все будущие ты.

Услышав это, гений обрёл просветление.

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

Что в них было общего, так это любовь к совершенству и программированию. Они пытались сделать свои подручные программы настолько хорошими, насколько это вообще возможно. И ещё хотели, чтобы те работали изящно. Они хотели бы сделать что-то в настолько ошеломляющем ключе, что никто не поверил бы даже в реальность подобного, и сказать: «Смотри, насколько это прекрасно. Спорим, ты не верил, что так можно!»

— Ричард Столлман



Master Foo and the Nervous Novice
Один послушник, научившийся уже довольно многому от Мастера, всё равно чувствовал, что чего-то недостаёт. Помедитировав на свои сомнения некоторое время, он осмелился приблизиться к Мастеру со своей проблемой:
— Мастер Фу, — спросил он, — почему адепты Unix не пользуются антивирусными программами? И дефрагментаторами? И очисткой от троянов?

Мастер Фу улыбнулся и сказал:
— Когда дом твой построен хорошо, нет нужды в колоннах, чтоб держать крышу.

Послушник ответил:
— Не лучше ли всё равно использовать их — просто чтобы быть уверенным?

Мастер Фу подобрал клубок бечёвки, лежавший неподалёку, и стал оборачивать ею ноги послушника.

— Что вы делаете? — спросил тот в изумлении.

Мастер Фу ответил просто:
— Завязываю тебе шнурки.

Услышав это, послушник обрёл просветление.


Master Foo and the Editor Wars
Однажды безмятежное утро Мастера Фу было омрачено воплями страданий.

Обнаружив, что они исходят от одного из новичков, он осведомился:
— В чём твоя трудность?

— Я в отчаянии от своих инструментов, — ответил новичок, — Каждый раз мне приходится использовать целый сонм редакторов, потому что ни Emacs, ни Vi, ни любой другой текстовый процессор не обладает всеми возможностями, что мне нужны.

Мастер Фу кивнул:
— Как, — спросил он, — решил бы эту трудность Мастер Великого Пути?

Ученик подумал пару минут, потом ответил:
— Ну, это очевидно. Я напишу лучший редактор на свете. Он будет делать всё, чего я захочу. Он будет делать всё, чего захочет кто угодно. И мир станет лучше, потому что…

… Тут речь ученика прервалась резким ударом посоха Мастера по затылку.

— М… Мастер? — спросил ученик, осторожно потирая ушиб, — В чём я был неправ?

— Глупец! — сказал Мастер Фу, — неужели ты думаешь, что я хочу учиться ещё одному редактору?

Услышав это, ученик обрёл просветление.

Комментарий
Этот коан ещё не был переведён никем и нигде. Он появился буквально на днях.
Представьте мою радость, когда я вижу первое за полтора года обновление на сайте Реймонда.



Master Foo and the Old Hand
Опытный Unix-программист, прослышав о мудрости Мастера Фу, пришёл к нему за наставлением. Подходя к Мастеру, он поклонился трижды и сказал:
— Мастер Фу, я серьёзно обеспокоен. В молодости моей в ходу у тех, кто следовал Великому Пути, были простые и незатейливые программы — ed, mailx. Сегодня они используют vim и mutt. Завтра, я опасаюсь, они освоют KMail и Evolution, и Unix станет таким же как Windows — раздутым и испещрённым всевозможными графическими интерфейсами.

Мастер Фу сказал:
— Но какую программу использовать, если нужно нарисовать плакат?

— Я..., — осёкся программист, — никогда не делал подобного. Но я уверен, что мог бы найти истинный путь Unix и использовать LaTeX или pic чтоб справиться с этим без графического интерфейса.

Тогда Мастер Фу спросил:
— Кто быстрее переберётся через реку: тот ли, кто мечтает о плоте, или же тот, кто голосует автостопом до ближайшего моста?

Услышав это, программист достиг просветления.

Комментарий
ed — потоковый текстовый редактор, один из первых и простейших. Сейчас практически полностью забыт и погребён sed'ом.
mailx — потоковый и очень простой почтовый клиент, до сих пор используется кое-где на HP-UX или Solaris и для простых посылок писем по конвейеру.

vim — консольный текстовый редактор, один из лучших на данный момент. Есть плагины практически на все случаи жизни.
mutt — консольный почтовый клиент с удобным интерфейсом на ncurses.

KMail — графический почтовый клиент от KDE e. V. Долгое время был огромным монолитным слепком полуработающего кода.
Evolution — графический почтовый клиент от Gnome Foundation. Долгое время не предоставлял практически никаких возможностей подгонки интерфейса и поведения под нужды пользователя.



Master Foo Discourses on the Two Paths
Мастер Фу наставлял учеников:
— В пути дхармы есть учение, примером которому служит изречение Патриарха Макилроя: «Делай одну вещь, и делай её хорошо», которое демонстрирует, что программа тогда следует пути Unix, когда имеет простое и соответствующее поведение, с понятными пользователю и иным программам параметрами.
— Но есть и иное учение дхармы, примером чему служит великая мантра Патриарха Томпсона «Будучи в сомнении используй грубую силу», наравне с различными сутрами о получении 90% прямо сейчас, нежели 100% поздно, что демонстрирует ясность и простоту реализации.
— Скажите мне теперь, каким программам более присущ дух Unix?

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

Мастер Фу одобрительно кивнул.

— Но с другой стороны, хорошо известно, что идеальные алгоритмы на деле хрупки. И очередная попытка покрыть узкое место ведёт к взаимодействию и с кодом центральной логики программы, и с кодом из других узких мест.
— Таким образом, желание покрыть все узкие места сразу в стремлении достичь «простоты описания» может на деле привести к переусложнённому и хрупкому коду или к такому, который из-за обилия ошибок никогда не заработает. Ведь и это не дух Unix?

И снова Мастер одобрительно кивнул.

— Какое же учение дхармы верно, в таком случае?

И Мастер ответил:
— Когда орёл летит, забывает ли он, что ноги его касались земли? Когда тигр хватает свою добычу, забывает ли он о моменте, проведённом в прыжке? Три фунта VAX!

Услышав это, Ньюби обрёл просветление.

Комментарий
В этом коане, так же как в одном из предыдущих, есть отсылки к «Природе Будды», а также непереводимая игра слов — реплика Мастера «Three pounds of VAX!» должна напоминать о классическом коане «Three pounds of flax!», в котором подчеркивается схожая идея. А именно: нет никакой серебряной пули. Нет ни единой программы, отвечающей всем идеалам. И при разработке не следует во всем идти на поводу лучших практик, потому что контекст может кардинально различаться.

VAX — архитектура построения компьютеров, весьма популярная в 1980-е, на которой долгое время велась разработка Unix. Интересно отметить, что именно из-за своей приверженности к VAX адепты Unix не обратили в своё время внимание на появление неприметного в те времена Intel x86, а позже и Windows на них.



Master Foo Discourses on the Unix-Nature
Ученик сказал Мастеру Фу:
— Нам говорили, что компания Novell удерживает истинную власть над Unix.

Мастер Фу кивнул.

Ученик продолжил:
— Но также нам говорили и то, что компания OpenGroup также удерживает истинную власть над Unix.

Мастер Фу кивнул.

— Как такое возможно? — поинтересовался ученик.

Мастер Фу ответил:
— Novell действительно удерживает власть над кодом Unix, но код Unix — это не Unix. OpenGroup действительно удерживает власть над именем Unix, но имя Unix — это не Unix.

— Что же тогда такое дух Unix? — спросил ученик.

Мастер Фу сказал:
— Не код. Не имя. Не мысль. Не вещь. Вечно меняясь, остаётся тем же.
— Дух Unix прост и пуст. Из-за этой простоты и пустоты он мощнее тайфуна.
— Двигаясь согласно законам природы, он неумолимо расцветает в умах программистов, ассимилируя проекты в своё естество. Все программы, которые хотят состязаться с ним, должны стать таким как он — пустыми, пустыми, глубоко пустыми, совершенным ничто, да будет так!

Услышав это, ученик обрёл просветление.

Комментарий
Снова отсылки к «Природе Будды», которую каждый находит сам. Этот коан просто пестрит всевозможными отсылками и переделками фраз с настоящих коанов. Самим ESR был оставлен комментарий, что «Двигаясь согласно законам природы» — это очень частая присказка для обоснования чего-либо в «Tao Te Ching», также, «Не код. Не имя. Не мысль. Не вещь.» — практически полная копия с коана №27, а последние слова Мастера в настоящих коанах встречаются как строчка из песен сутры.



Master Foo and the Shell Tools
Новичок пришёл к Мастеру Фу и сказал:
— Я в смятении. Разве не в том путь Unix, что каждая программа должна делать одну вещь и делать её хорошо?

Мастер Фу кивнул.

Новичок продолжил:
— Разве также не в том Путь Unix, что колесо не до́лжно переизобретать?

Мастер Фу снова кивнул.

— Почему тогда есть похожие по возможностям инструменты в обработке текста?

Мастер Фу спросил ученика:
— Какой из них использовал бы ты, будь у тебя текстовый файл и необходимость заменить несколько слов в нём другими?

Новичок нахмурился, потом сказал:
— Регулярные выражения Perl слишком избыточны для такой задачи. Я не знаю awk, но в последние недели я писал sed-скрипты. Поскольку у меня уже есть некоторый опыт, на данный момент я предпочёл бы sed. Но если нужно отредактировать лишь один файл один раз, хватит и текстового редактора.

Мастер Фу кивнул и ответил:
— Когда голоден, ешь; когда у тебя жажда, пей; когда устал, спи.

Услышав это, ученик обрёл просветление.


Master Foo and the Methodologist
Во времена когда Мастер Фу со своим студентом Ньюби путешествовал по святым местам, обычаем Мастера было давать наставления неофитам Unix, коротая время до ночлега в попутных городках и деревнях.

В один из таких дней среди внимающих был и методолог.

— Если вы не будете регулярно профилировать свой код в поисках узких мест при отладке, вы станете подобны рыбаку, который забрасывает сеть в пустое озеро, — говорил Мастер Фу.

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

— Я однажды наткнулся на рыбака, который как раз уронил свою сеть в озеро, где плавала его лодка, — сказал Мастер Фу, — Он довольно долго рылся на дне лодки, пытаясь найти её.

— Но.., — сказал методолог, — Если он уронил сеть в озеро, почему же он искал её в лодке?

— Потому что он не умел плавать, — ответил Мастер Фу.

После этих слов на методолога снизошло озарение.

Комментарий
Эрик Реймонд прямо указывает в инструкциях по переводу считать принадлежность методолога не к конкретной практической ветви какой-либо методологии, а к касте менеджмента вообще — и речь его просит не переводить дословно, а использовать подходящий по значению заменитель в целевом языке в сфере бизнес-сленга



Master Foo Discourses on the Graphical User Interface
Как-то раз Мастер Фу и Ньюби посетили встречу программистов, собравшихся для обмена знаниями. Один из программистов поинтересовался у Ньюби, к какой школе принадлежат он и его учитель. Услышав, что они последователи Великого Пути Unix, тот презрительно усмехнулся.

— Инструменты командной строки Unix грубые и отсталые, — бросил он, — современные правильно спроектированные операционные системы делают всё через графический интерфейс!

Мастер Фу промолчал, но ткнул пальцем на луну. Собака неподалёку залаяла на руку Мастера.

— Я не понимаю вас! — сказал программист.

Мастер Фу, по-прежнему храня молчание, ткнул на изображение Будды. Затем на окно.

— Что вы пытаетесь сказать? — вопрошал программист.

Мастер Фу ткнул на голову программиста. Затем на камень.

— Почему вы не можете сказать ясно? — потребовал ответа программист.

Мастер Фу задумчиво нахмурился, затем дважды щёлкнул программиста по носу и бросил его в ближайшую мусорную корзину.

Пока программист пытался выбраться оттуда, пробегавшая мимо собака помочилась на него.

В этот момент программист достиг просветления.

Комментарий
Когда я в первый раз читал этот коан в переводе, он окунул меня в пучину СПГС, поскольку переводчик выбрал «указал» в качестве описания действий Мастера. Хоть это и более верно стилистически в русском языке, но я считаю, здесь стоит сделать ударение на схожести действий Мастера с указателем мышки пользователя, пробующего на вкус все множество хитросплетений кнопок в графических приложениях.
Мораль же проста — графический интерфейс не делает твою программу современной и удобной за тебя.



Спасибо за внимание. Хотелось бы, чтобы такие жемчужины не пропадали в огромном море контента в нынешней сети. Комментарии, поправки к переводу приветствуются.

EDIT:
Прошу прощения, сейчас вдруг подумал, что лучше было бы оформить пост как перевод, поскольку всё кроме заголовка и комментариев к коанам — достояние сообщества. Извините.
@Kanedias
карма
31,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (65)

  • +16
    Это прекрасно.
    • 0
      Согласен!
  • 0
    Прекрасные притчи) Единственное, не пойму, зачем называть их какими-то «коанами». Судя по информации в википедии, с данными притчами это слово имеет не так много общего.
    • 0
      Коаны давали мастера Дзен своим ученикам для решения. Считается, что решая коаны, можно постичь истиннуб природу Дзен. Это действительно притчи, но каждая содержит в себе коаны мастера.
      • +2
        Обычно в коанах главную роль выполняет противоречие, из-за которого ученик и «достигает просветление». А здесь скорее небольшие вполне логичные рассказы.
        • +8
          Вероятно, вы уже обрели просветление, раз вы видите в них логику :) Я встречал много «продвинутых пользователей», которые читали эти притчи с насмешкой и непониманием.
          Ну и как бы сам автор зовет их коанами, значит и переводчику негоже отсутпать от авторского стиля
          • +4
            Не могу назвать себя продвинутым пользователем UNIX, sed и awk вызывают у меня трепет отнюдь не предвкушения, а необходимость написать скриптик на баше — вздох, обильный гуглеж и курение манов, но ничего парадоксального в этих коанах не вижу. UNIX тем и хорош, что не требует входа в особое состояние разума.
  • +2
    Отлично! Большое спасибо за изящество.
  • +10
    Я понял, что я ничего не понял. Сократ ли я?
    • +5
      Спешу вас обрадовать, после неоднократных попыток изучения темы вы начнёте не понимать намного больше!
  • +1
    Большое спасибо!
  • 0
    Шикарно!
  • +10
    «И помни, Нео! Знать путь и пройти его это не одно и тоже!»
    • +1
      Ещё один пример затерянных в сети жемчужин. Как вышло, что я ничего не знаю о притчах по ссылке? Как узнали о них вы?
      • +5
        Так им уж сто лет в обед. Был уверен, что все про них знают, но не мог не вспомнить в контексте сабжа.
        Я вот наоборот — про юниксовые коаны не знал до вашего топика :)
      • 0
        ЕМНИП, оно ещё чуть ли не в глубокое фидошное время по эхами ходило :)
  • –3
    > vim — мощнейший на данный момент консольный текстовый редактор.
    Воу-воу, полегче! Попахивает холиваром)

    Спасибо, коаны шикарны, многих нигде ещё не читал.
    • +6
      Коан и должен вызвать холивар. В первую очередь в голове читающего.
      • –1
        Мой комментарий относился не к коану, а к комментарию переводчика к нему.
        Спор vim/emacs/else чрезвычайно стар, давать определение vim-у как «мощнейший консольный текстовый редактор» очень уж необъективно, на мой взгляд. Ну и это вправду ведёт к холивару в большинстве случаев на определённых ресурсах.
    • +4
      Рад, что вам понравилось!

      Насчёт vim-а, признаю, это был комментарий с подвохом (сейчас поправлю). Я его оставил просто чтобы посмотреть, спросит ли кто-нибудь об этом. На деле я ко всем редакторам питаю искреннее уважение, даже к такой экзотике как acme и wily. Очень жаль, что вас заминусовали из-за меня.
      • +3
        > На деле я ко всем редакторам питаю искреннее уважение, даже к такой экзотике как acme и wily.
        Признаться, пришлось погуглить про них, ранее даже не слышал. Спасибо вам ещё раз, теперь уже за эту отсылку — acme чертовски впечатлил.

        > Очень жаль, что вас заминусовали из-за меня.
        Не думаю, что из-за вас. Это хабр, мне стоило быть осмотрительнее.
  • –4
    Master Foo and the Editor Wars

    Нежелание развиваться за мудрость выдаётся, однако…

    Зачем изобретать новые языки программирования? Их же придётся изучать! Лучше всё писать на ассемблере. Другие языки не нужны.

    Аналогичную фразу можно сказать про вообще что угодно. Всегда можно что-то илучшить, и действительно, потом это улучшение нужно будет кому то изучать. Но порой лучше «день потерять, потом за час долететь».
    • +12
      ни Emacs, ни Vi, ни любой другой текстовый процессор не обладает всеми возможностями, что мне нужны.

      Я напишу лучший редактор на свете. Он будет делать всё, чего я захочу. Он будет делать всё, чего захочет кто угодно. И мир станет лучше, потому что…
      Вы не обрели просветления. Потому что не было даже попытки улучшить имеющиеся инструменты (vim и emacs дополняемые), а уже потом хвататься за напильник и молоток, чтоб сотворить новый инструмент.
      • +3
        Вы попали в точку. Я даже приведу точную цитату от ESR (The Art of Unix Programming: The Right Size of Software):

        The corrective to this tendency comes straight from the old-school Unix hymnbook. It is the Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do—that is, when attempts to partition the problem have been made and failed. This maxim implies an astringent skepticism about large programs, and a strategy for avoiding them: look for the small-program solution first. If a single small program won't do the job, try building a toolkit of cooperating small programs within an existing framework to attack it. Only if both approaches fail are you free (in the Unix tradition) to build a large program (or a new framework) without feeling you have failed the design challenge.
    • +5
      А здесь будет уместна притча «Master Foo and the Ten Thousand Lines».
  • –1
    Ожидала увидеть другие коаны, но это тоже хорошо.
    • +2
      При всем уважении к языку, руби пришел и рано или поздно уйдет в сторону, а Unix-way останется.
      * ну и в заголовке явно присутствует слово Unix *
      • +2
        Мне почему-то показалось, что автор комментария совсем не имела ввиду именно приведенные по ссылке коаны на руби, а подразумевала аналогичные приведенным по ссылке обучающие, скажем так, инструкции-уроки в соответствующей форме для постижения unix-way.
        • +3
          ППКС, вы мою мысль выразили более точно.
    • +2
      На codewars это назвали ката.
  • 0
    Я наверняка чего-то не понимаю, но что vi[m], что emacs у меня вызывают одну ассоциацию…
    А именно:
    В каком-то фантастическом романе правящий компьютер создал синтетический язык для общения с кастой своих жрецов-слуг. Этот язык использовал пропускную способность речевого аппарата человека практически полностью, но требовал пары лет брутальных уроков а-ля собака Павлова, и все равно перед каждым использованием требовалась предварительная «настройка» с помощью этакого «камертона».

    Вот и с ними также — да, потенциально можно работать очень эффективно, но порог вхождения настолько крут, что невольно задаешься вопросом: а оно точно того стоит?
    • +2
      Сейчас появилось много хороших редакторов (atom, sublime), так что в некоторых областях емакс с вимом уже проигрывают.
      С другой стороны, у них есть свои ниши, в которых они будут ещё долго хороши.
    • +4
      Ну, сложность vi[m] слегка преувеличена, там реально нужно запомнить десяток команд. Как, собственно, и в любом современном редакторе для эффективной работы. Другое дело, что в vi[m] разделен режим ввода команд и режим редактирования и потому у новичков он работает всего лишь в двух режимах: «бибикает» и «все портит».

      В общем, тем, кто не хочет заморачиваться, стоит запомнить простое сочетание: (esc), ":", «q!» — выход без сохранения изменений.
      • 0
        Только вот оно работает не во всех режимах.
        • 0
          Сорри, проглядел "(esc)". Тогда все ок.
      • 0
        Лучше: (esc), (esc), ":", «q!»
        Так сработает 100% )))
    • –1
      Порог вхождения в эмакс настолько крут не потому что эмакс принципиально сложен, а потому что это отражение трагедии современного высшего образования в области информатики и компьютерных наук. После паскаля, бейсика и PHP лисп действительно кажется синтетическим средством изобретенным инопланетянами, при том что его полное описание заняло у автора аж целый непомерный лист формата A4.
      • 0
        Порог вхождения в emacs настолько крут ни в коем случае не из-за языка. Lisp — вполне простой для освоения язык. Для сравнения тот же Vimscript — кошмар и ужас. А попытки как-то автоматизировать работу в vim вызывают желание побиться головой о клавиатуру.

        Проблема с emacs во взрывающих мозг комбинациях клавиш. Чтобы модифицировать инструмент под себя мне надо научиться хоть как-то работать с базовой версией. Но как я могу научиться работать с ней, если я не могу запомнить ни одну комбинацию клавиш?! В emacs есть курс для новичков: он выглядит как издевательство, у меня пальцев не хватает на базовые действия в нем, не говоря уже о том, чтоб повторить это без подсказки.
        • +1
          Единственная программа, в которой вменяемо подошли к хоткеям — Idea. Там есть Ctrl+Shift+A, помогающий выучить остальные комбинации. Будь нечто подобное в emacs — освоить его стало бы несравнимо проще.
          • 0
            Я с вами согласен в этом ключе — хотелось бы, чтобы хоткеи подсказывались в процессе работы ненавязчиво, но неоднократно, как при полном поиске нужной функции в Ctrl+Shift+A. У vim, конечно, есть vimtutor и интерактивный учебник, но нет-нет, да и обнаруживаешь себя на tips wiki в поисках очередной фичи.
            • +1
              В emacs есть программа Guide Key которая делает именно это.
              • 0
                Вот это? kai2nenobu/guide-key
                Это совершенно не то же самое, что Ctrl+Shift+A в Idea. Ctrl+Shift+A проводит полнотекстовый поиск по описанию действия. guide-key — поиск по части комбинации.
                • 0
                  Ближайший аналог в Emacs — встроенная команда apropos, C-h a, но она не ищет по описанию действия. Среди всего разнообразия дополнений есть что-то похожее, но как по мне учебник и гугл таки уместнее.
        • +1
          Комбинации клавиш принципиально вызывают проблемы независимо от программы и самих сочетаний. Они ужасны везде, не только в Emacs. Например сочетания Ctrl-Z, Ctrl-X, Ctrl-C и Ctrl-V абсолютно невменяемы и нелогичны, насколько я могу о них судить. Они привычны, потому что фактически стали частью современной культуры, но это не меняет их сути. В Emacs большинство сочетаний клавиш имеют осмысленное значение, как в vi: forward, backward, next, previous, word, line, kill, yank, transpose, uppercase, capitalize, save, find, search, reverse, end, zap, qoute, indent, open, delete, и т.д — это из тех что лично я использую все время.
          • +3
            Они логичны в том плане, что на раскладке QWERTY эти четыре очень часто выполняемых действия посажены на клавиши рядом с левым Ctrl, поэтому нет нужды ставить пальцы на шпагат. =)
            Ctrl-A, Ctrl-C и Ctrl-S в этом плане повезло — не только легко нажать, но и буква совпадает по смыслу. Хотя смысловое совпадение — штука обоюдоострая из-за синонимов. Ведь пользователю придется вспоминать, какой глагол использовался для, скажем, поиска: search, find или look.
        • 0
          Поставьте пакет ergoemacs — он во многом дублирует хоткеи «нормальных» редакторов, Ctrl+C, Ctrl+V и прочие плюшки там что называется из коробки.
    • 0
      Я когда-то давно начал использовать вим из-за того, что ни один редактор не мог оставить меня довольным собой, я всех и не вспомню, в каждом мне в итоге хотелось изменить ряд вещей. Одни лагали, другие были неудобны, третьи поддерживали очень ограниченный список языков, в других нельзя было кастомизировать тривиальные вещи и т.д. и т.п. А о вим я был наслышан как о редакторе, который можно вертеть и крутить, что ж, это оказалось чистой правдой.

      С тех пор я серьёзно прокачал конфиг, и то, как я работаю в виме с целой сворой плагинов сейчас, напоминает работу в «голом» vim очень отдалённо, автоматизировал кучу вещей и привык к куче комманд, которые позволяют мне вместо нудного для меня тыкания по всяким «стрелочкам» и елозинья мышкой производить целевые действия, часто используемые комбинации доведенны до рефлексов. Что меня по прежнему не перестаёт радовать, — я могу заставить редактор подстроиться под меня, он не навязывает мне свою рутину.

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

      По вопросу могу сказать, что если вы нюфаг, или вас итак всё устраивает, вы эффективно решаете свои задачи, то оно того наверняка не стоит, т.к. рвать шаблон будет сильно, особенно первый месяц непрерывной работы, если только для фана, авось зацепит. Первое время вы будете думать по большей части о редакторе, а не о коде. Если же вас смущают ограничения вашего редактора, которые вы не можете преодолеть, то однозначно стоит попробовать vim, т.к. он не возбраняет изменять себя до неузноваемости.

      Большая однако паста получилась.

      P.S. Нюфагам — первым делом ремапьте capslock чтобы использовать его вместо ctrl (даже если не пользуетесь vim-ом).
      • 0
        О каких недостатках речь и в рамках каких задач? А то не очень понятно, как в разработке текстовый редактор может тягаться, например, с полноценной IDE, заточенной под работу с проектами.
        • 0
          О недостатках:
          1. Часто отсутствие полного контроля с клавиатуры, часто приходится прибегать к использованию мыши, особенно неприятно, когда эти действия становятся более менее частыми;
          2. Я не знаю другого редактора, который бы так же хорошо был заточен под 10-и пальцевую посадку, чтобы не было необходимости постоянно передёргиваться на «стрелочки» и обратно, а то и на мышь, руки всегда посажены в одном месте;
          3. Отсутствие комманд для быстрой контексто-зависимой навигации по коду, например, я смотрю на экран, хочу попасть в такое-то место, в вим я смотрю на relative-номер строки, делаю 10j (опускаюсь на 10 строк вниз), а потом допустим иду до первого символа “:” (f:) и удаляю всё что между “{” и “}” ( di} ), в прочих редакторах наикратчайший путь, как правило — взять в руки мышь и началь ей что-то выделать, для меня это довольно нудно;
          4. В vim я например набросал свой костыль для очистки пробелов и табов на концах строк, который делает именно то, что мне нужно, и повесил хук на запись в файл, он учитывает текущие настройки отступов, чтобы в случае чего не резать табы на пустых строка (т.к. в проекте так принято, для того чтобы легче было визуально воспринимать), чтобы не резать такие отступы также и в комментариях, т.к. это не пустые строки, которые могут иметь пробелы/табы на окончаниях и т.д., то есть применил вообще свой, достаточно замороченный алгоритм, каждый день мои коллеги испытвают проблемы, их редакторы либо режут лишнее, либо не режут вообще, а я решил проблему единоразово, написав свой кастомный хук;
          5. Отсутствие гибкости в биндах на сочетания клавиш, часто нельзя переопределить поведение стандартных сочетаний, необходимость в «аккордах», это основная фича вима, последовательные комбо, ;
          6. Отсутствие возможности повторить последнее действие, аля сделать это ещё N раз;
          7. Отсутствие возможности заменять одну часть системы на другую, либо сильная ограниченность в этом, в виме большинство задач, вроде каких-нибудь сниппетов или навигации по файлам выполняется с помощью различных плагинов, и если мне не нравится один путь, я всегда могу выбрать другой, настроить его под себя, например файл я могу открыть целой своро способов (fuzzy search из ctrlp, релятивное открытие в ctrlspace, дерево файлов nerdtree, дефолтные способы вроде :e :o, которые могут быть также весьма наглядны с помощью wildmenu), работа с табами/буфферами/окнами (стандартные способы, ctrlspace, всякие бары, которые кастомизируются и отображают необходимую тебе информацию);

          Я могу продолжать далее, если угодно.

          А если Вы хотите услышать ответ по поводу «тягаться с IDE», то перечислите мне то, что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины и я дам вам ответ каким образом я решаю ту или иную задачу в Vim.
          • 0
            что вы имеете в IDE, чего по вашему не может Vim и прилегающие к нему плагины

            Самое банальное — рефакторинг в большом проекте.
            • 0
              Это возможно для определённых языков, в которых структура проекта достаточно прозрачна (где такая автоматизация по сути возможна), у меня не возникало задач, где это можно было бы автоматизировать и я об этом не задумывался, то есть инцидента не возникало, не могу дать ответ, т.к. работаю в основном с ЯП, к которым это в большинстве случаев не применимо.
            • 0
              Прошло время и у меня появился ответ на ваш вопрос про рефакторинг (сам пользуюсь): CtrlSF
              • +1
                Очень даже неплохо! Пользовался раньше vim-easygrep, но этот выглядит получше, спасибо.
          • 0
            Насчет зависимости от мыши — мне не попадалось ничего подобного ни в одном приличном редакторе. Все пункты меню вызываются стандартными шоткатами или стрелками. А в мощных редакторах можно настроить комбинации клавиш для любых действий. Мышь является лишь альтернативой.

            Что я имею в других редакторах?

            — организацию проекта в виде дерева файлов с легкой навигацией по нему. Замечу, что файлы проекта != всем файлам в директории и субдиректориях.
            — список функций в конкретном файле и быстрый переход по методам других классов в рамках проекта
            — автокомплит, использующий названия переменных, методов и объектов всего проекта
            — маркировка строк не влияющая на содержимое файлов
            — привязка раскладки панелей к конкретному проекту.
            — возможность «сворачивать» блоки
            — собственно, функционал для отладки — панель с содержимым стека/переменных, брекпоинты и т.д.

            Из дополнительных фич: поиск/замена в файлах проекта. Неограниченное undo/redo. Переключение на hex-view с некириллическим шрифтом (это спасало от целой бездны боли, связанной с русско-латинскими «c» и «o»). Визуальное превью текста для навигации. История клипборда.

            Я тоже могу продолжать далее, если угодно. :-)
            • 0
              1. В NERDTree можно фильтровать содержимое, не знаю на счёт конкретно вашей ситуации, и что конкретно из себя представлют файлы проекта в директории отдельно от каких файлов? Какие файлы в той же директории не являются файлами проекта?
              2. TagBar, gf (и ещё некоторые), возможно конечно в Вашей IDE это работает более навороченно;
              3. В Vim прекрасный автокомплит, по всем словам из всех октрытых файлов, так же есть куча вариаций с помощью плагинов, опять же по всем файла проекта и прочее, автокомплит у меня в виме работает ощутимо лучше, чем у моих коллег, предпочитающих IDE, при чём они сами это признают;
              4. Это всё тоже есть в Vim, если я правильно Вас понял, поясните что Вы понимаете под «маркировкой строк»?
              5. Тут нужно представить вашу ситуацию в ваккуме, что у вас за «панели»? Кастомный набор фреймов в Vim также реализуем, при чём независимый в каждом табе, и в каждом воркспейсе (например воркспейсы из ctrlspace);
              6. В vim-е есть фолды, как и везде, которые могу работать в пачке разных режимов, по вложенности, по синтаксису, по маркерам в комментариях и т.д.
              7. В виме вполне себе возможна конпеляция из него с получением отчётов, более гибко с брейкпоинтами я сам не видел, но не исключено что можно присобачить, возможно это будет хуже, чем в Вашей IDE.

              Приведите пожалуйста в пример редакторы, которые, как Вы сказали, хороши для работы с клавиатуры?
              • 0
                1. Да все, что угодно: документация в doc/pdf, временные файлы, дампы базы, логи, служебные файлы SVN/CVS/GIT и так далее. Практически любая система контроля версий разделяет содержимое проекта и содержимое директорий. Соотв. редакторы должны уметь работать только с проектом, чтобы тот же поиск по всем файлам не застрял на каком-нибудь тридцатигигабайтном дампе базы.

                2-3. Приведу пример. Я написал класс Fuzz с методом buzz и комментариями к нему. Потом я где-то завел переменную f класса Fuzz. Автокомплит должен мне автоматом показать метод buzz( ) и комментарий к нему, как только я наберу «f.» в области видимости объявленной переменной. А если я наведу курсор на f.buzz(), то в IDE есть возможность по хоткею сразу перейти к функции buzz конкретного класса Fuzz.

                4. В UE можно расставлять метки на строках сочетанием клавиш Ctrl+F2, а затем по нажатию F2 перемещаться по ним. Удобно для отладки. При этом информация об этих метках хранится где-то самим редактором никак не затрагивая содержимое файла.

                В качестве универсального редактора я использую UltraEdit, а в качестве IDE в последнее время в основном Eclipse.
                • 0
                    1. Не понял, важно чтобы ваш редактор открывал pdf/doc? оО Мне кажется для этого должен нужен не редактор кода, а соответсвующий целевой софт;
                    2. Временные файлы есть в вим из коробки, более того, можно написать например `:earlier 15m` и получить состояние файла 15 минут назад, есть плагин gundo, который по факту представляет из себя версионирование файла с ветвлениями по временным точкам аля git, когда вдруг это нужно, очень удобная плюха;
                    3. Что вы понимаете под фичей редактора/IDE «дампы базы, логи»?
                    4. Для гита и прочиз CV целая свора плагинов, которые помимо прочего связываются ещё и с другими плагинами;
                  1. Для этого есть набор плагинов, видел демо, но сам не пользовал, ничего подсказать не могу, т.к., повторюсь, работаю в основном с ЯП, где это малоприменимо;
                  2. Метки в Vim есть, как я уже говорил раньше, и они тоже не затрагивают содержимое файла.
                  • 0
                    1. К сожалению, вы потеряли контекст обсуждения.

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

                    2. Т.е. работаете с ЯП, в котором нет ни ООП, ни структур, ни библиотек? Я заинтригован. Ассемблер?
                    • 0
                      1. Тогда я не понимаю почему вы решили, что это не реализуемо в Vim;
                      2. javascript, в виду отсутствия единого пути ООП, модулей и прочего, — статический анализ очень затруднителен, я видел у коллег, как их IDE безуспешно обваливались при попытке найти корни например объявленных конструкторов исключений, которые генерируются динамически в виде простого хеш-мапа.
                      • 0
                        1. Так я и не решил, я просто не видел такого решения, вот и спросил. По-умолчанию vim не умеет почти ничего, но плагины могут это исправить. Вот мне и интересно, есть ли готовые решения для работы с проектами в своем формате или же cvs/svn/git. И если есть, то насколько они адекватны.

                        2. Некоторые проекты на некоторых других языках занимают мегабайты (а порой и десятки мегабайт) кода и содержат сотни классов и полусотни библиотек. Там для меня поддержка IDE крайне важна, поскольку довольно сложно помнить все параметры всех методов всех классов, зачастую имеющих одинаковые или схожие названия
                        • 0
                          Вот лично моё мнение, что всё-таки скорее всего по части навигации по структурам данных внутри проекта лучше справится ваша IDE.
  • –5
    Вот красивый компьютер — первые 1000 слов памяти — прерывания, последние 1000 слов памяти — регистры внешних устройств. Но! Работать будет медленно, поэтому мы сделаем для внешних устройств прямой доступ в память — пусть пишут в параллель с центральным процессором. Давайте еще сделаем порты ввода-вывода для ускорения. Давайте память видеокарты добавим к памяти компьютера для ускорения записи.

    Windows — давайте выжмем из электроники по максимуму и поиграем. Linux — давайте сделаем все канонично-логично и не спеша поработаем.

    Путь Unix — отсутствие вирусов, только отсутствие вирусов и ничего кроме отсутствия вирусов. Все эти рассказки есть лишь рекомендации по реализации пути Unix.
  • 0
    что хорошо бы использовать эквивалент «печать»


    Как насчет чего-нибудь вроде «я приложил руку к...» (проектированию, строительству,… этих домов)?
  • +1
    Гм. ed — не потоковый редактор. Он линейно-ориентированный, да, но при этом вполне интерактивный. Потоковый редактор — это sed. Stream Ed.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.