Ну я пока тоже не уверен где то место где разумно остановиться с минимизацией. Проводить эксперименты с 9ю клавишами я точно не готов :) Я, скорее, подхожу к процессу с позиций плавного улучшения. Сначала поменял местами Ctrl и Alt, сразу стало на порядок легче в основных приложениях - у меня там основной модификатор Ctrl. Потом повесил раскладку на Caps. Сейчас ищу подходящую альтернативу для Esc где-нить поближе. Остаются бесячие "[" (после 20 лет тачтайпа я до сих пор по ним не попадаю). Отсюда и выросла идея что-то более кардинальное попробовать. В целом эксперимент получился интересным - 3 ряда мне вполне хватало, цифры на отдельном слое вполне себе норм. Проблемы подкрались с другой стороны. От механики мне оказалось ни тепло, ни холодно, а вот длинноходные модификаторы - отстой, неудобно. Орто в плане эргономики ничего не добавляет, нужно лишь инвестировать в привыкание и не ясно стоит ли оно того. По итогам вернулся на MS Sculpt. Сейчас опять зачесалось - заказал себе High Plains Drifter на Outemu с тачпадом.
Не знаю как автор на это смотрит, отвечу за себя. Где-то есть золотая середина между отдельной клавишей на каждое действие и клавишей для каждого пальца "чтобы руками лишний раз не двигать". Для сценария набора текста, имхо, определенный консенсус сложился - для каждого знака своя клавиша, но вот свой набор клавиш для каждого знака unicode - явный перебор. А вот для сценария работы с кодом однозначно людям чего-то не хватает. И, если приличное сообщество любителей намутить свою клавиатуру вас не убеждает, можно посмотреть сколько у нас любителей Vima и прочих модальных редакторов. Редактирование кода требует много разной, причем, иногда, довольно хитрой навигации (желающие поспорить что ci" стрелками удобнее - велкам). И вот тут четко ощущается, что стрелки "в стороне" это реально неудобно. И это не решить тренируясь попадать по ним "вслепую" - стрелки во всех клавах делаются или по принципу "красиво" - в полноразмерных, или по принципу хоть как-то их упихнуть - в ноутбуках. И вот тогда хочется примерно как в Vimе не только в Vime и все заверте...
P.S. ИМХО, более удобный вариант вашего ребуса: kkk$vbbbdG$p
Идеальный программист, имхо, как-то эффективнее должен использовать рабочее пространство на его мониторах, да и такие длиннючие строчки в коде - некомильфо. P.S. Текст так и не собрался прочитать, сорри.
А где обещанный способ избавиться от WIP коммитов? На фоне заглавной картинки stash выглядит как-то бледно (я ведь верно помню, что при пожаре незаконченная работа сгорит вместе с рабочей станцией?).
Ортолинейность больше геморрой - реально много времени уходит на привыкание а толку немного. Ничего особенно эргономичного в ортолинейности нет - колонки клавиш под указательным пальцами всё равно две и пальцам приходится двигаться вправо и влево.
Вообще, не только Emacs, в Linux почти везде шорткаты с Ctrl и оно очень неудобно пока не поменяешь Ctrl и Alt местами. Тогда все становится на свои места (да, да space kadett и все такое)
Опять все не там ищут. Конечно, в изначальном ТЗ была подсистема которая визуализирует сигнал датчика. Просто ее не успели сделать и сдали проект как было, убедив заказчика, что для MVP это вполне норм. функциональность. И не докопаешься - подрядчик не виноват, в его документации было всё подробно описано.
Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится. В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.
Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
Я таки подозреваю, что ограничения которые предлагались были связаны именно со сложностью восприятия их кода чем с локальной проблемой типа гигиены. Мало того что там код создает другой код, дык еще и все эти квотинги\анквотинги жизнь проще не делают. Как мне кажется, именно поэтому в scheme попытались как-то исправить эту ситуацию - define-syntax легче воспринимать.
Не, было круче - чуваку нужно было поправить по виду простейший баг который в конце "путешествия" оказался злонамеренной диверсией предшественника в коде компилятора.
Еще в Common Lisp'овых гайдах пытались предупреждать о том, что макросами не стоит злоупотреблять - там где можно функцией обойтись НУЖНО ею обходиться. И вообще, - макрос только если всем участникам очевидно что получилось удачно. При этом, к сожалению, какого-то более простого критерия уместности макроса никто так и не придумал :(
По-моему, в F# была подходящая фича которую не спешат тянуть в другие языки - единицы измерения в качестве модификатора типа. Фича позволяла без особой когнитивной нагрузки избежать ошибок когда метры могут быть в качестве килограммов использованы.
Ну дык на дейликах происходит ровно то же самое. Все прекрасно успевается до тех пор пока в планируемую дату завершения не становится понятно что не успевается.
И от "напишет херню" дейлики никак не спасают - код на слух очень плохо воспринимается. Для этого, сколько помню, код ревью придумали.
Вот всему руками поддержу. Давно пора уже перестать разрабатывать все эти скучные и унылые продукты. Если кому такое надо, пусть они, как-нибудь, сами, там, что-нибудь, в экселе копошатся!
А вы не пробовали работу как-то по-другому организовать? Ну, знаете, там, аналитики бывают всякие, продакт овнеры и т.д. Ну, чтобы, когда разработчик что-то начинает разрабатывать уже было понятно что и зачем он делает.
Мне интересно было что-то делать на ассемблере КМ1801 (PDP-11 который) и КР580 (Интел 8080, вроде). Тогда вообще все происходящее на тех компьютерах укладывалось в одной голове и ассемблер был вполне органичен. В MSDOS, пожалуй тоже. А вот что-то делать в системах типа винда на ассемблере, имхо, странно.
Я, когда проделал аналогичное упражнение на винде, - приложение на ассемблере создавало окно используя win api, испытал странное чувство что я сделал какую-то фигню, но не мог понять почему. А потом меня озарило. Я вспомнил споры со своим другом - аудиофилом. Аргумент про дорогучий силовой кабель из бескислородной меди (тут про технологию точно соврал, но деталей не помню) который ну никак, ни за какие деньги не сможет исправить кривое электричество которое было погнуто в процессе передачи по километрам зоопарка проводки от электростанции до розетки.
Ну я пока тоже не уверен где то место где разумно остановиться с минимизацией. Проводить эксперименты с 9ю клавишами я точно не готов :)
Я, скорее, подхожу к процессу с позиций плавного улучшения. Сначала поменял местами Ctrl и Alt, сразу стало на порядок легче в основных приложениях - у меня там основной модификатор Ctrl. Потом повесил раскладку на Caps. Сейчас ищу подходящую альтернативу для Esc где-нить поближе. Остаются бесячие "[" (после 20 лет тачтайпа я до сих пор по ним не попадаю). Отсюда и выросла идея что-то более кардинальное попробовать. В целом эксперимент получился интересным - 3 ряда мне вполне хватало, цифры на отдельном слое вполне себе норм. Проблемы подкрались с другой стороны. От механики мне оказалось ни тепло, ни холодно, а вот длинноходные модификаторы - отстой, неудобно. Орто в плане эргономики ничего не добавляет, нужно лишь инвестировать в привыкание и не ясно стоит ли оно того. По итогам вернулся на MS Sculpt. Сейчас опять зачесалось - заказал себе High Plains Drifter на Outemu с тачпадом.
Не знаю как автор на это смотрит, отвечу за себя. Где-то есть золотая середина между отдельной клавишей на каждое действие и клавишей для каждого пальца "чтобы руками лишний раз не двигать".
Для сценария набора текста, имхо, определенный консенсус сложился - для каждого знака своя клавиша, но вот свой набор клавиш для каждого знака unicode - явный перебор.
А вот для сценария работы с кодом однозначно людям чего-то не хватает. И, если приличное сообщество любителей намутить свою клавиатуру вас не убеждает, можно посмотреть сколько у нас любителей Vima и прочих модальных редакторов.
Редактирование кода требует много разной, причем, иногда, довольно хитрой навигации (желающие поспорить что ci" стрелками удобнее - велкам). И вот тут четко ощущается, что стрелки "в стороне" это реально неудобно. И это не решить тренируясь попадать по ним "вслепую" - стрелки во всех клавах делаются или по принципу "красиво" - в полноразмерных, или по принципу хоть как-то их упихнуть - в ноутбуках.
И вот тогда хочется примерно как в Vimе не только в Vime и все заверте...
P.S. ИМХО, более удобный вариант вашего ребуса: kkk$vbbbdG$p
Идеальный программист, имхо, как-то эффективнее должен использовать рабочее пространство на его мониторах, да и такие длиннючие строчки в коде - некомильфо.
P.S. Текст так и не собрался прочитать, сорри.
А где обещанный способ избавиться от WIP коммитов? На фоне заглавной картинки stash выглядит как-то бледно (я ведь верно помню, что при пожаре незаконченная работа сгорит вместе с рабочей станцией?).
А с ортолинейностью это как связано?
Ортолинейность больше геморрой - реально много времени уходит на привыкание а толку немного. Ничего особенно эргономичного в ортолинейности нет - колонки клавиш под указательным пальцами всё равно две и пальцам приходится двигаться вправо и влево.
Вообще, не только Emacs, в Linux почти везде шорткаты с Ctrl и оно очень неудобно пока не поменяешь Ctrl и Alt местами. Тогда все становится на свои места (да, да space kadett и все такое)
А что с Орбакайте-то случилось??
Опять все не там ищут. Конечно, в изначальном ТЗ была подсистема которая визуализирует сигнал датчика. Просто ее не успели сделать и сдали проект как было, убедив заказчика, что для MVP это вполне норм. функциональность. И не докопаешься - подрядчик не виноват, в его документации было всё подробно описано.
Вот поддержу, да. Ощущение такое, что эта вся огромная система написанная на этом языке постоянно в движении и никак не устаканится.
В итоге, каждый раз когда нужно сделать что-то не сильно сложное, типа локального шелла с выбранными питоновскими пакетами приходится копировать и править существующий конфиг, запомнить и воспроизвести по памяти так и не выходит.
Особенно это хорошо видно когда пытаешься отладить какую-нибудь проблему - очень так непросто, много слоев всякого.
Знание греческого алфавита явно не помогает понять молодое поколение :)
Я таки подозреваю, что ограничения которые предлагались были связаны именно со сложностью восприятия их кода чем с локальной проблемой типа гигиены. Мало того что там код создает другой код, дык еще и все эти квотинги\анквотинги жизнь проще не делают. Как мне кажется, именно поэтому в scheme попытались как-то исправить эту ситуацию - define-syntax легче воспринимать.
Не, было круче - чуваку нужно было поправить по виду простейший баг который в конце "путешествия" оказался злонамеренной диверсией предшественника в коде компилятора.
Еще в Common Lisp'овых гайдах пытались предупреждать о том, что макросами не стоит злоупотреблять - там где можно функцией обойтись НУЖНО ею обходиться. И вообще, - макрос только если всем участникам очевидно что получилось удачно.
При этом, к сожалению, какого-то более простого критерия уместности макроса никто так и не придумал :(
По-моему, в F# была подходящая фича которую не спешат тянуть в другие языки - единицы измерения в качестве модификатора типа. Фича позволяла без особой когнитивной нагрузки избежать ошибок когда метры могут быть в качестве килограммов использованы.
Ну дык на дейликах происходит ровно то же самое. Все прекрасно успевается до тех пор пока в планируемую дату завершения не становится понятно что не успевается.
И от "напишет херню" дейлики никак не спасают - код на слух очень плохо воспринимается. Для этого, сколько помню, код ревью придумали.
Вот всему руками поддержу. Давно пора уже перестать разрабатывать все эти скучные и унылые продукты. Если кому такое надо, пусть они, как-нибудь, сами, там, что-нибудь, в экселе копошатся!
А вы не пробовали работу как-то по-другому организовать? Ну, знаете, там, аналитики бывают всякие, продакт овнеры и т.д. Ну, чтобы, когда разработчик что-то начинает разрабатывать уже было понятно что и зачем он делает.
Мне интересно было что-то делать на ассемблере КМ1801 (PDP-11 который) и КР580 (Интел 8080, вроде). Тогда вообще все происходящее на тех компьютерах укладывалось в одной голове и ассемблер был вполне органичен. В MSDOS, пожалуй тоже. А вот что-то делать в системах типа винда на ассемблере, имхо, странно.
Я, когда проделал аналогичное упражнение на винде, - приложение на ассемблере создавало окно используя win api, испытал странное чувство что я сделал какую-то фигню, но не мог понять почему.
А потом меня озарило. Я вспомнил споры со своим другом - аудиофилом. Аргумент про дорогучий силовой кабель из бескислородной меди (тут про технологию точно соврал, но деталей не помню) который ну никак, ни за какие деньги не сможет исправить кривое электричество которое было погнуто в процессе передачи по километрам зоопарка проводки от электростанции до розетки.