All streams
Search
Write a publication
Pull to refresh
151
0
Send message
Вау, диванный психотерапевт! Добро пожаловать, заходите, располагайтесь, выкладывайте свои диагнозы. :)))
Поиск:
vim — нажать / ввести что ищете, нажать Enter
стандартный редактор — нажать Ctrl + F, ввести, что ищете, нажать Enter

Да что вы говорите?/слово

Редактирование:
vim — стрелками подвести курсор к месту, которое нужно редактировать, нажать i, начать набирать
стандартный редактор — стрелками подвести курсор к месту, которое нужно редактировать, начать набирать

Вы знаете, это iпрекрасно, пока iне надо наiбирать кириллицу.

Замена:
vim — нажать :%s/слово, которое искать/слово на которое заменить/g
стандартный редактори — не помню хоткея, наверное надо лезть в менюшку

Какая чудесная, интуитивно-понятная команда!:%s/чудесная/прекрасная/g
Не работает что-то.

Откат изменений:
vim — нажать u
стандартный редактор — нажать Ctrl+Z

Мне коuажется, вы чего-то не договвuариваете. :)

Я к тому, что без выработки дурацкой^W привычки тыкать Esc перед любым действием vim — это наказание, а не редактор.
В виме нет гуёвой менюшки.
Она есть в гвиме.
Вот только есть нюанс: с его же слов, на освоение вима в минимальной конфигурации у него ушел целый месяц.

Ну, то есть примерно столько же, сколько в случае с каким-нибудь другим редактором.

Хорошо пошутили, ценю.

«Какой-нибудь другой редактор» осваивается за вечер. Это если говорить о необходимом минимуме для комфортной работы: поиск, редактирование, замена, откат изменений, сохранение.

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

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

Со стороны может создаться такое впечатление, но это как слепая печать. Надо потратить время и силы. Но те, кто потратили как правило довольны. Стокгольмский синдром?

А знаете, не исключено, что и так. :)

Лично я видел не так много людей, которым слепая десятипальцевая печать была действительно нужна в работе. Возможно, у вас другой опыт, но программистам навык слепой печати никак не помогает в работе. Большую часть времени программист не клацает по клавиатуре, а все-таки думает. Вот для девочек, подрабатывающих набором текстов на компьютере, слепая печать действительно помогает жить.

О чём там говорить много часов? Если у редакторов есть паритет по фичам, то весь вопрос сходится к тому, любите вы режимы, или нет.

Вы первый раз холиварите что ли? Вопросы вкуса фломастеров — самые животрепещущие и долгообсуждаемые. :)

А паритета фич у vim и mcedit и близко нет. Вим — чугунный швейцарский нож с педальным управлением и встроенным подогревом сиденья (правда, искаропки подогрев на дровах, но это можно исправить парой навесных блоков). Мцедит — ностальгия по встроенному в нортон коммандер редактору со всеми вытекающими: одновременно умеет редактировать только один файл, поддерживает только необходимый минимум действий. А еще, поскольку половина действий повешена на функциональные кнопки, его иногда запаришься конфигурировать под конкретный терминал (особенно эротично это делать в сессиях screen на всяких интересных платформах типа соляриса). Тем не менее и в нем можно творить удивительные вещи, т.к. есть макросы и вызов внешних программ.

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

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

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

Я все это к тому, что иногда мне кажется, что ярые поклонники вима страдают наслаждаются стокгольмским синдромом. Да что там — не иногда, а почти всегда. Освоение вима — это череда сплошных издевательств над мозгом, и нельзя же открыто признать, что все эти страдания были впустую. :)

Помню, после одной многочасовой дискуссии «vim vs mcedit» сошлись на том, что вим круче, ибо верую. :)
Надо было брать правильный термин — пермутация. А еще желательно было бы добавить область применения вашего кода — психологическое тестирование.

Сейчас ваша статья вводит в заблуждение: читатель думает, что ваш код способен из одного слова или словосочетания сделать другое путем перестановки букв. Это, между прочим, весьма нетривиальная задача, и посмотреть ее решение было бы интересно многим. На деле же оказывается, что вы всего-навсего перемешиваете буквы с невразумительными переподвывертами.
Настоящие анаграммы потому и сложно разгадывать, что они являются существующими словами. Это сбивает с толку и делает задачу сложной для человека.
А вот составить слово из мешанины букв может даже первоклассник (касса букв — помните?).
Упорство хорошо, когда вы отстаиваете некую новую концепцию, непонятую аудиторией. А вот когда вы пытаетесь упорством прикрыть собственные неточности и промахи — это уже плохо, ибо затягивает дискуссию и превращает ее в бессмысленное толковище.

Я вам пару очевидных вещей скажу, только вы не обижайтесь.

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

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

Анагра́мма (от греч. ανα- — «пере» и γράμμα — «буква») — литературный прием, состоящий в перестановке букв или звуков определенного слова (или словосочетания), что в результате дает другое слово или словосочетание
Если пользователь проводит в этом режиме много времени — удобнее ввести полноценное переключение между режимами.

Вообще-то нет. Если пользователь проводит в неком «режиме» много времени, ему удобнее использовать отдельный набор управляющих элементов. Например, отдельный блок кнопок для ввода команд редактирования. Необходимость в отдельных режимах при этом отпадает.
Конечно, у Раскина свои тараканы. Следуя его логике, для ввода русских букв удобнее использовать отдельную клавиатуру, а не переключение режимов. Оно-то, возможно, и так, только где же столько места на столе найти? :)
И таки да, код несовершенен, т.к. в нём оценивается качество перемешивания букв анаграммы слов, читаемых традиционно слева-направо. Имеет смысл добавить такую же оценку, если читать справа-налево, чтобы исключить, к примеру анаграмму «бирг» для слова «гриб».

Что за бред я только что прочитал? Вы бы хоть поинтересовались, что и как именно оценивает алгоритм Левенштейна, чтобы в следующий раз не пороть чушь.
Анаграмма — да. Но у вас — не анаграмма, а перемешивание символов.
Ориентировался на более широкую трактовку семантики этого понятия.

Не надо жонглировать терминами. У слова «анаграмма» семантика вполне определенная, никаких «расширенных» семантик у него нет. В результате перестановки букв должно получиться слово или фраза, а не мешанина символов.

То, что делаете вы, называется пермутацией.

Вот теперь сижу и думаю: может я чего нарушил, применив её непрофильно. :)

Непрофильно вы применили термин «анаграмма».
Именно режимы это его настоящая киллер-фича.

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

Патамушта человек плохо адаптирован к режимам — ему удобнее кнопку или педаль держать нажатой, нежели запоминать, какой сейчас режим включен.

Да-да, вам удобно, вашим коллегам нравится, у всех работает…
Очень согласен.
Именно поэтому многие не рекомендуют использовать языки промышленной разработки (С, С++) в обучении программированию: привычки и шаблоны потом ничем не перебьешь.
Нет у нас готового однозначного слова для «бреда наполненного на 93%». И такими категориями вы уже не можете думать

1. Бредок.
2. Люди вообще вряд ли могут мыслить процентами. У нас количество значимых градаций всяко поменьше 100.

Или например «blue» в английском и «синий»/«голубой» в русском.

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

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

Это проблема халатности сотрудников. Вы же не думаете всерьез что в блокноте конкретно они будут писать лучше, корректнее и быстрее?

Это не халатность, а скорее протест. Люди искренне не понимали требований.

Что касается блокнота — вы не поверите, но были и такие эксперименты. До конца дошли очень немногие. Тем не менее — код получился лучше, корректнее и читабельнее. Естественно, что скорость была никакая — но не потому, что товарищи резко разучились находить кнопки на клавиатуре. Просто очень много времени ушло на объяснения очевидных вещей: «вот тут у тебя — видишь? — все в кучу слеплено. А если пробельчиков добавить — сразу становится понятнее».

А еще налицо проблема инфраструктуры. Ничто не мешает вам использовать IDE с clang'овскими диагностиками и компилить самим clang'ом.

Это уже не относящиеся к обсуждаемому вопросу мелочи. Лично я считаю, что исходники должны быть отвязаны от любого рода IDE. А это значит, что даже если косоглазый китаец откроет их допотопным vi'ем в текстовой консольке 80х25 — он должен увидеть вполне читаемый код, а не уходящую за край экрана мешанину без единого пробела.

Что касается особенностей моей тогдашней работы — как бы вам объяснить-то покорректнее… Проблема инфраструктуры шерифа (сиречь руководство) не колыхала совершенно. Руководство было в далекой и влажной стране, все офисы были типовыми, вся разработка велась на серверах, которые стояли за много тыщ километров от машины разработчика. На машинах разработчика — винда. Так положено.
Вариантов запустить IDE было ровно два:
1. Поднимаем на винде X Window Server. Пробрасываем на него коннект с серверной машины. Запускаем там Eclipse (или Emacs, или gvim). Уходим пить кофе. К нашему приходу, если повезет, окошки дорисуются.
2. Ставим на локальной машине студию (или Eclipse, или еще что). Ставим в нее плагин, чтобы можно было брать исходники по FTP (другого на серверах нет). Компилять, естественно, не получится. Мучаемся так.

А так, конечно, ни-че-го не мешало нам использовать IDE. :)

Другие IDE то в чем повинны?

Ни в чем. И вижулятина тоже ни в чем не виновата. Я вообще не об инструменте, а о влиянии молотка на неокрепшие умы.
IDE с подсветкой вовсе не обязательно будет у тех, кто потом будет поддерживать этот код. А без подсветки разобраться в вызовах такой функции малореально. Особенно если кто-то удалил, скажем, один аргумент из середины списка или перепутал порядок аргументов. Компилятор вовсе не обязательно в таких случаях выдаст ошибку (типы данных можно и подпривести к нужным, а некоторые аргументы могут иметь значения по умолчанию).
Ну и — очевидно — чем длиннее список аргументов, тем больше вероятность, что программист что-нибудь напутает при вызове.
IDE это в первую очередь инструмент, и чем он лучше, тем производительнее сотрудник.

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

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

Information

Rating
4,916-th
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity