> Столмэн по идейным соображениям ненавидел идею коммерческого ПО
Это неверно. Столлман против проприетарного ПО, а коммерциализацию свободного ПО он, наоборот, поддерживает. На gnu.org это уже разжёвывалось неоднократно, например здесь: www.gnu.org/philosophy/selling.html
> и воровал код из Symbolics, копируя его в бесплатный продукт
Первый раз слышу о том, что он у кого-то в Symbolics что-то воровал и кому-то угрожал. Пытался в одиночку разработать аналог ПО, производимого Symbolics, — это да. Перманентно ругался с Symbolics — тоже да, но на этом всё.
> статья… о Лиспе (точнее о современном диалекте этого языка — Common Lisp)
Статья может создать у начинающего ложное впечатление, что Emacs использует Common Lisp и тесно с ним связан. Это неверно: основной диалект лиспа, используемый в Emacs, — это Emacs Lisp, и он является довольно ограниченной реализацией лиспа. Есть пакет cl, но это фактически слой совместимости c Common Lisp, а не реализация.
В теории было бы хорошо такое иметь даже в vim, но реальное положение дел следующее:
— На стандартной клавиатуре до шифта большим пальцем не дотянуться. И вообще, зажатие клавиши-модификатора обездвиживает руку, особенно это видно на составных командах vim («2dW» или «d(» не набрать с какой бы то ни было зажатой modkey без страданий).
— Нет редакторов (известных мне), которые бы позволяли при зажатой modkey функциональность как в vim command mode. Одиночные команды ещё ладно, а вот аналогов для составных команд нет.
> Всегда думал, что режимы – это неизбежное (в Виме) зло.
Нет, это киллер-фича. Выход из insert mode в command mode в vim позволяет использовать всю клавиатуру и все возможные буквенные keychord-ы для операций над текстом. В обычных редакторах, если судить с позиции vim, огромная часть keychord-ов жёстко забита на вставку текста, оставляя для хоткеев лишь Ctrl, Alt, Shift комбинации (плюс часть небуквенных клавиш и мышь).
> Что значит «тянуть к стрелкам»? Они у меня всегда под рукой.
При слепой печати — нет.
> А второе вхождение? А десятое? Для каждого – свой хоткей, что ли, учить?
Нет, всего лишь ввести префиксом число перед нажатием клавиши поиска.
Т.е. например 3 / abc для поиска третьего вхождения abc.
Vim тем и хорош, что после того, как выучиваешь принципы композиции команд, можно их конструировать самому, заранее зная, каким будет результат (в тч я ни разу не пользовался поиском с цифровым префиксом, но знаю, что написанное мной сработает)
Плюс что, поиск n-ного вхождения — это такая частая операция, что мы её вдруг используем для проверки редактора на крутость? Я разработчик и не помню ни разу, чтобы такое мне понадобилось на практике хоть раз в жизни. Вот vim-овский инкрементальный поиск /, n, n, N, n, — сплошь и рядом. Такими вопросами можно доказать, что любой редактор плох, достаточно задавать всё более экзотические вопросы «а может ли так ваш редактор».
> в ST есть поиск всех вхождений выделения по одному хоткею. Или не просто поиск, а выбор всех этих вхождений и одновременное редактирование.
Ну во-первых давайте тогда ваш вопрос про N-ный результат поиска и к ST применим, чтобы честно было. На том уровне, на котором я знаю ST, ответ для ST — «возможно только через скриптование». Для vim, как видите, ответ «возможно из коробки». Мультикурсорность — да, это одна из самых крутых фич ST, не имеющих известных мне аналогов в vim/emacs.
При чём здесь доп. монитор? Он избавляет вас от необходимости таскать мышкой окна приложений?
Плюс, в многомониторной конфигурации tiling wm ещё больше уделывает стековый, тк там перебросы окон между мониторами делаются опять же 1 кнопкой, как и между рабочими столами.
Эм, если что, у меня отрицательная карма и я не могу вас минусовать. По той же причине, как оказывается, у меня режутся html теги и это было причиной исчезновения ссылок. Но я тихо ржу сейчас, это вы правы.))) Ещё раз всего хорошего
Я делал, не знаю почему хабр делает их простым текстом.
Зачем вам ссылки, вы же говорили, что vim использовали, вам все эти объекты должны быть известны. Прыжки — это vim jumplists.
Эта ваша современная IDE умеет такие фичи «архаичного» vim, как text marks? Text objects? Прыжки? Поиск и замену регулярок одной строкой? Я уже не говорю про киллер-фичи sublime.
Я ничего не путал. Я продолжил 2 разных ветки обсуждения по 2 разным темам. В первой я утверждал, что по функциональности программируемые текстовые редакторы могут поспорить с IDE. Во второй (про проблемы обучаемости), начатой кстати не мной, — утверждал, что IDE своим удобством может вредить студенту при обучении.
Что студенты в процессе обучения используют IDE — это абсолютно нормально, им в этой IDE работать. Основная мысль состояла в том, что IDE не стимулирует изучать низкоуровневые операции и желательно учить студентов этим операциям — на что в реальности часто забивают. Да, даже когда учат 4 года, примеров таких джуниоров у меня перед глазами довольно много. Как побочный эффект, появляются товарищи вроде комментатора выше, говорящего про «ужас блокнотов».
Возражение про магию в IDE абсолютно ясное, не знаю что в нём можно не понять. Студент набирает код, жмёт Compile и получает бинарный файл. Как у него в голове при этом может выстроиться хоть какая-то картина, кроме «я пишу код, жму на кнопку, происходит магия, и получается exe файл»? Он мб сможет быстро приступить к изучению языка, но не будет знать, что такое объектный файл, линковка, файл проекта, link.exe, cl.exe. Студент, набирающий код в «блокноте» (sic) в проекте из более чем 1 файла и не имеющий на руках системы сборки кода, практически сразу встретится с необходимостью всё это изучить хоть как-то.
Бред какой. Я все свои проекты реализую в emacs и он уделывает по функциональности все эти IDE (равно как на это способны и vim и sublime). В тч там есть эмуляция vim, автодополнение, сниппеты, jump to definition, code folding. Более того, этот подход (текстовый редактор) практикует огромное количество программистов. Из моих знакомых разработчиков около половины — вимеры.
Цель одна и та же — организация удобного управления несколькими окнами приложений и передачи данных между ними. Разница лишь в том, кто является «менеджером окон» (у ТС это tmux, у вас xmonad).
Кроме того, рабочая среда в статье завязана на tmux (тк vim-slime служит для передачи данных от vim к tmux или screen).
Вообще ИМХО тайловый менеджер удобнее, но tmux/screen зато незаменимы на удалённой машине для старта приложений.
По такой логике, этот принцип нарушает любое высокоуровневое ПО, которое юзер применяет для собирания конкретного набора атомарных инструментов ОС (листинг файлов, архиватор, ftp, ssh, медиаплеер, редактор — кстати ничего не мешает заменить mcedit на что угодно) в единое целое. В том числе Gnome, Emacs, mc, любая IDE.
Всю целиком ошибочной не считаю, только балльную систему.
Чем заменить — не знаю, это очень сложный вопрос, могу лишь предположить необходимые признаки такой системы — индивидуальный подход или мини-группы вместо классов в 20-30 человек, отсутствие жёсткой рейтинговой системы проверки знаний, вместо неё — система не привязанных ко времени тестов, которые ребёнок «закрывает» с течением времени, в своём ритме.
> А вы уверены, что в обычной школе дети стимулированы получить знания, а не гоняться за внешними признаками
Нет, не уверен и считаю, что традиционная балльная система оценок неэффективна.
И тем неприятнее мне видеть проект, который вместо того, чтобы попытаться починить проблему ложных стимулов, только её усугубляет ещё больше.
Они упоролись. Не говоря уже о всех этих магах с абилкой телепорта и онлайн-покупках бронелифчиков (первое — самая идиотская фича проекта, вторая — самая мерзкая) — у меня большие сомнения, что геймификация уместна в школе. Она и при более традиционном применении не всегда и не всюду эффективна, а здесь такой сложный и тонкий процесс, как школьное обучение. Автор уверен, что он просчитал всё правильно как педагог? Что дети будут стимулированы именно усваивать знания, а не гоняться за внешними признаками успеха в игре? Что соревновательный элемент не станет слишком сильным давлением на психику ребенка? Что настолько радикальный процесс логичнее было бы вводить небольшими порциями, например начав с легкой геймификации системы достижений ученика, а не шарашить сразу файрболлами?
> Столмэн по идейным соображениям ненавидел идею коммерческого ПО
Это неверно. Столлман против проприетарного ПО, а коммерциализацию свободного ПО он, наоборот, поддерживает. На gnu.org это уже разжёвывалось неоднократно, например здесь:
www.gnu.org/philosophy/selling.html
> и воровал код из Symbolics, копируя его в бесплатный продукт
Первый раз слышу о том, что он у кого-то в Symbolics что-то воровал и кому-то угрожал. Пытался в одиночку разработать аналог ПО, производимого Symbolics, — это да. Перманентно ругался с Symbolics — тоже да, но на этом всё.
> статья… о Лиспе (точнее о современном диалекте этого языка — Common Lisp)
Статья может создать у начинающего ложное впечатление, что Emacs использует Common Lisp и тесно с ним связан. Это неверно: основной диалект лиспа, используемый в Emacs, — это Emacs Lisp, и он является довольно ограниченной реализацией лиспа. Есть пакет cl, но это фактически слой совместимости c Common Lisp, а не реализация.
Я педалью пользуюсь для смены режима vim =)
www.kinesis-ergo.com/shop/savant-elite-2-pedal/
Но всё это привязывает к конкретной машине
— На стандартной клавиатуре до шифта большим пальцем не дотянуться. И вообще, зажатие клавиши-модификатора обездвиживает руку, особенно это видно на составных командах vim («2dW» или «d(» не набрать с какой бы то ни было зажатой modkey без страданий).
— Нет редакторов (известных мне), которые бы позволяли при зажатой modkey функциональность как в vim command mode. Одиночные команды ещё ладно, а вот аналогов для составных команд нет.
Нет, это киллер-фича. Выход из insert mode в command mode в vim позволяет использовать всю клавиатуру и все возможные буквенные keychord-ы для операций над текстом. В обычных редакторах, если судить с позиции vim, огромная часть keychord-ов жёстко забита на вставку текста, оставляя для хоткеев лишь Ctrl, Alt, Shift комбинации (плюс часть небуквенных клавиш и мышь).
> Что значит «тянуть к стрелкам»? Они у меня всегда под рукой.
При слепой печати — нет.
> А второе вхождение? А десятое? Для каждого – свой хоткей, что ли, учить?
Нет, всего лишь ввести префиксом число перед нажатием клавиши поиска.
Т.е. например 3 / abc для поиска третьего вхождения abc.
Vim тем и хорош, что после того, как выучиваешь принципы композиции команд, можно их конструировать самому, заранее зная, каким будет результат (в тч я ни разу не пользовался поиском с цифровым префиксом, но знаю, что написанное мной сработает)
Плюс что, поиск n-ного вхождения — это такая частая операция, что мы её вдруг используем для проверки редактора на крутость? Я разработчик и не помню ни разу, чтобы такое мне понадобилось на практике хоть раз в жизни. Вот vim-овский инкрементальный поиск /, n, n, N, n, — сплошь и рядом. Такими вопросами можно доказать, что любой редактор плох, достаточно задавать всё более экзотические вопросы «а может ли так ваш редактор».
> в ST есть поиск всех вхождений выделения по одному хоткею. Или не просто поиск, а выбор всех этих вхождений и одновременное редактирование.
Ну во-первых давайте тогда ваш вопрос про N-ный результат поиска и к ST применим, чтобы честно было. На том уровне, на котором я знаю ST, ответ для ST — «возможно только через скриптование». Для vim, как видите, ответ «возможно из коробки». Мультикурсорность — да, это одна из самых крутых фич ST, не имеющих известных мне аналогов в vim/emacs.
Плюс, в многомониторной конфигурации tiling wm ещё больше уделывает стековый, тк там перебросы окон между мониторами делаются опять же 1 кнопкой, как и между рабочими столами.
Зачем вам ссылки, вы же говорили, что vim использовали, вам все эти объекты должны быть известны. Прыжки — это vim jumplists.
Эта ваша современная IDE умеет такие фичи «архаичного» vim, как text marks? Text objects? Прыжки? Поиск и замену регулярок одной строкой? Я уже не говорю про киллер-фичи sublime.
И вы продолжаете хамить. Вам самому сколько лет?
Возражение про магию в IDE абсолютно ясное, не знаю что в нём можно не понять. Студент набирает код, жмёт Compile и получает бинарный файл. Как у него в голове при этом может выстроиться хоть какая-то картина, кроме «я пишу код, жму на кнопку, происходит магия, и получается exe файл»? Он мб сможет быстро приступить к изучению языка, но не будет знать, что такое объектный файл, линковка, файл проекта, link.exe, cl.exe. Студент, набирающий код в «блокноте» (sic) в проекте из более чем 1 файла и не имеющий на руках системы сборки кода, практически сразу встретится с необходимостью всё это изучить хоть как-то.
Цель одна и та же — организация удобного управления несколькими окнами приложений и передачи данных между ними. Разница лишь в том, кто является «менеджером окон» (у ТС это tmux, у вас xmonad).
Кроме того, рабочая среда в статье завязана на tmux (тк vim-slime служит для передачи данных от vim к tmux или screen).
Вообще ИМХО тайловый менеджер удобнее, но tmux/screen зато незаменимы на удалённой машине для старта приложений.
struct V {};
bool operator== (const V& a, const V&b) { return false; }
void main() {
V v;
if (v == v) {
std::cout << «YES»;
} else {
std::cout << «NO»;
}
}
Чем заменить — не знаю, это очень сложный вопрос, могу лишь предположить необходимые признаки такой системы — индивидуальный подход или мини-группы вместо классов в 20-30 человек, отсутствие жёсткой рейтинговой системы проверки знаний, вместо неё — система не привязанных ко времени тестов, которые ребёнок «закрывает» с течением времени, в своём ритме.
Нет, не уверен и считаю, что традиционная балльная система оценок неэффективна.
И тем неприятнее мне видеть проект, который вместо того, чтобы попытаться починить проблему ложных стимулов, только её усугубляет ещё больше.