Погодите, автор это тот самый человек, который рассказывал про интеграцию 1С с друпалом? Я там был! Это было волшебно! Это было прекрасно! Весь зал лежал! Никакой Камеди Клаб с этим не сравнится!
Может у вас найдётся время дать ссылку на что-нибудь демонстрирующее преимущества описанного в статье подхода по сравнению с исключениями? Если нет — в любом случае, хорошо побеседовали :).
Тут есть 2 пункта.
В джаве есть исключения, добавляемые в сигнатуру метода. К счастью их можно не использовать и видеть только в кошмарных снах :). Практика показывает, что это плохая идея.
И второй пункт. Вы хотите сказать, что в примере из статьи сигнатура функции отражает что-то кроме того, что в ней может возникнуть исключительная ситуация?
Ну метод явно нечистый, поскольку сайд-эффект налицо.
А то, что метод map позволяет не вводить дополнительный механизм обработки исключений это безусловно хороший лайфхак для языков, в которых обработки исключений нет.
И может быть в функциональных языках действительно можно писать простой и понятный код безо всяких исключений. Но в приведённых примерах код точно такой же, каким был бы с исключениями. Только вот для этого пришлось добавить специальный тип для возврата значения и обязать всех им пользоваться.
О проверке типов компилятором и четком понимании на каком участке кода какие ситуации могут возникнуть тут речи нет, вернее компилятору понять такой код не проще, чем код с исключениями.
Про типобезопасность и обработку краевых случаев тоже непонятно. Возьмём например то самое деление, которое в статье. И в том и в другом случае надо проверить нету ли там нуля. И это должен сделать программист. И он одинаково эффективно забудет об этом и в том и в другом случае и компилятор ему не поможет.
В функциональных языках многое прекрасно. И применению ФП в императивных языках тоже есть место, но оно не в обработке исключительных ситуаций.
И если бы в обмен на отсутствие исключений мы получили возможность объявить чистую функцию, результаты выполнения которой можно кешировать и параллелить, то это можно было бы декларировать фичей языка. Но я так понял об этом нет и речи. Может есть хотя бы модификатор const для методов, как в С++?
Всегда был уверен, что сайд эффект — это когда функция делает что-то помимо возврата результата. Тут не так. Тут как раз что справа, что слева происходит одно и то же. Только в случае с исключениями процесс автоматизирован, а в случае с вводом перечисления как результата все контролируется вручную. Наверное есть какие-то ситуации, когда это к лучшему, но в стандартных случаях это как правило минус.
Механизм исключений позволяет не вводить дополнительного возвращаемого типа, позволяет не вводить метод map и при этом писать понятный и простой код. Также позволяет не писать в функциональном стиле, если тебе это не нравится и писать когда это приятно.
Преимущества функционального подхода (помимо эстетических) тут вообще не совсем понятны. Или в Swift есть возможность объявить чистую функцию? Или компилятор умеет доказывать её чистоту?
Ну Страуструп как-то добавил исключения в С++ не убив из-за этого совместимость С++. А про сайд-эффект, так передача индикатора неудачного результата по цепочке это точно то же самое, что исключения, только с бойлерплейтом и без оптимизаций компилятором. Сайд-эффект же не в самом выбросе исключения, а потенциально в его обработке.
Коротко скажу, что fuzzy-поиск это интересно, правда относится это не к редактированию текста, а к облегчению порога вхождения. То есть фича не текстового редактора, а любой программы. Но всё равно прикольно. И одновременное редактирование найденных значений тоже хорошо, хоть по сути неотличимо от find and replace. В остальных мелочах вы просто плохо информированы по поводу Вима и хорошо по поводу Саблайма.
Я бы с удовольствием похоливарил по поводу этих мелочей, но мне кажется, что вам будет интереснее узнать мое мнение по поводу вещей, которые я мелочами не считаю. Не мелочи — это заблуждение о том, что стрелки всегда под рукой, что режимы — зло, пусть и неизбежное и что вам нужен инструмент, который будет помогать работать.
На моей клавиатуре от home row до стрелок — сантиметров 10. Переносить руку на эти 10 сантиметров при малейшей необходимости подвинуть курсор, а потом, когда надо что-то напечатать — переносить руку обратно — верный путь к нервному расстройству. Конечно, если печатать вслепую не умеешь и вообще набираешь текст медленно и двумя пальцами, а правая рука и так ходит между клавиатурой и мышью — действительно создаётся иллюзия, что стрелки под рукой, но платой за эту иилюзию является низкая эффективность работы с редактором.
И режимы в Виме выполняют функцию ограждения пользователя от ужасов постоянного перемещения правой руки между мышью, стрелками и буквами. Без них Вим не нужен, в них его смысл и высокая миссия :). Именно с их помощью Вим помогает работать и несёт добро в мир!
А вот по поводу того, что вам не нужен инструмент, который будет помогать работать — это я покривил душой. Просто это не единственное ваше требование к инструменту. Вам, судя по вашим словам, также важно, чтобы кривая обучения была как можно более пологой, а лучше вообще отсутствовала. То есть есть какое-то соотношение степени в которой инструмент помогает жить и того, насколько трудно им овладеть.
И это безусловно правильный подход, если только большая часть вашей жизни не проходит в работе с текстом. Если вы занимаетесь текстом постоянно, то на овладение инструментом не жалко потратить время, потому что это экономия времени в итоге будет колоссальна. По крайней мере так считают те, кто пользуется вимом или емаксом.
P. S. Вы никого не обидели, не переживайте. Холивары — в свободное от работы время — крайне полезная и интересная штука ибо при участии в них велик шанс узнать что-то радикально новое.
В разрезе выяснения значимых отличий Vim от Sublime Text обсуждение кастомизируемости что того, что другого эффективно не более, чем удобство работы с кодом. Правда по другой причине — они одинаково сильно поддаются кастомизации. В разумных пределах конечно. Из Sublime Text сделать Vim проще, чем в Vim реализовать Sublime, но мы вроде не об этом.
А вот дальше интересно. Комбинацию, которая используется для выделения слова в ОС можно без проблем использовать в любом из исчадий блокнота — никаких проблем. И это действительно плюс ST, но он идёт в графу «Просто для использования неопытным пользователем». Потому что, как вы совершенно верно отметили, так слово можно выделить только если курсор стоит в начале или в конце слова. Что конечно ужасно неудобно. А если он в где-нибудь в середине, то неизбежно придётся читать про Ctrl+d.
Короче, если не учить хоткеи, то отличия Саблайма от блокнота вообще сводятся к минимуму. А если пользоваться мышью, то наверное единственная его фича — это миникарта файла. И собственно всё. Ну то есть тоже интересно конечно, но для того, чтобы пользоваться им по несколько часов в день — как-то маловато.
Что для абсолютно любого действия в Виме надо помнить хоткей или команду — большое преувеличение. Что такое режимы придётся выяснить — это да. А дальше можно обходиться минимумом. Можно даже пользоваться стрелками. Только работать не используя всё богатство возможностей редактора неудобно независимо от названия этого редактора. Изучать придётся и ST и Vim.
Приводить примеры чудес всегда нелегко. Особенно в случае с вимом. Если для того, чтобы крутить сальто нужно год тренироваться — кому нужно это сальто и, что самое главное, какое же это чудо :). Но я попробую.
Чудо — это вообще весь Вим и его режимы.
Чудо — что не нужно тянуть руку к стрелкам каждый раз, когда хочешь чуть-чуть передвинуть курсор. И что для выделения кусков текста не надо зажимать одновременно несколько клавиш.
Чудо — что если ты подредактировал строку, а потом после беглого просмотра файла понял, что надо вписать в ту же строку ещё что-нибудь — достаточно набрать gi и курсор окажется в конце последнего редактированного куска.
Чудо — что для первого поиска сделующего вхождения слова под курсором нужно набрать *, а для того, чтобы найти где оно встречается в третий раз достаточно нажать n. А чтобы найти где оно встречается выше по тексту — N.
Чудеса не в том, что можно сделать в Виме, а в том как это делается.
Быстрая работа с кодом это конечно интересно, но в этом отношении IDE кроют ненастроенный и неоплагиненный вим как бык овцу. И Sublime Text тоже кроют. И разницы между vim и Sublime Text по сравнению с IDE в этом отношении почитай, что и нету.
ssh тоже не сильно важно.
А вот насчёт интуитивности к Sublime Text большие вопросы. То есть Ctrl+v, Ctrl+c и Ctrl+x это в общем интуитивно, как и стрелки, как и сочетание Ctrl+стрелки.
А вот чтобы выделить слово, кажется надо нажать Ctrl+d. Это ни разу не интуитивно и это придётся запоминать, как и огромную кучу других хоткеев. Но так как Sublime это такой расширенный и улучшенный блокнот — работать можно и без них. Правда удобство работы с текстом — тоже как у блокнота, хоть и на стероидах.
Вим подходит к проблеме более радикально. Он вообще в руках неопытного пользователя умеет только пищать и всё портить. Но применение принципиально другой схемы работы с текстом позволяет обученному пользователю творить чудеса, на которые блокнот не способен в силу отсутствия модальности.
Большинство современных редакторов плоть от плоти блокнота и кровь от крови его и главная их фича точно такая же как у блокнота — с ними может работать неопытный пользователь.
Главная фича Vim — комфорт, которого блокнот дать не может by design. Ради этого комфорта и стоит учиться пользоваться Vim. Пусть это и требует определённых усилий.
Большое спасибо за статью! Документации по rtorrent мало и она неполна, поэтому появление такого обзора — безусловно большая радость.
Я тоже настраивал себе автоматическую закачку после копирования *.torrent файла в директорию и копирование загруженных файлов в целевую директорию в зависимости от местонахождения *.torrent файла.
Но вот копирование файлов с магнет-линков у меня настроить так и не получилось. Когда магнет-линк скачан rtorrent теряет файлы с раздачи и считает их нескачанными. Происходит это, как я понимаю, из-за отсутствия соответствующего раздаче *.torrent файла. Может кто знает, как это побороть?
Таки дают. Ну то есть можно попросить вернуть определённый кусок диска в 512 байт. И диск представлен в линуксе блочным устройством с линейной адресацией.
www.youtube.com/watch?v=SN7CtUdSMFc
Минут 7 идёт сам доклад, а дальше ответы на вопросы, в которых в общем-то вся суть. Но сам доклад тоже лучше посмотреть.
Может у вас найдётся время дать ссылку на что-нибудь демонстрирующее преимущества описанного в статье подхода по сравнению с исключениями? Если нет — в любом случае, хорошо побеседовали :).
В джаве есть исключения, добавляемые в сигнатуру метода. К счастью их можно не использовать и видеть только в кошмарных снах :). Практика показывает, что это плохая идея.
И второй пункт. Вы хотите сказать, что в примере из статьи сигнатура функции отражает что-то кроме того, что в ней может возникнуть исключительная ситуация?
А то, что метод map позволяет не вводить дополнительный механизм обработки исключений это безусловно хороший лайфхак для языков, в которых обработки исключений нет.
И может быть в функциональных языках действительно можно писать простой и понятный код безо всяких исключений. Но в приведённых примерах код точно такой же, каким был бы с исключениями. Только вот для этого пришлось добавить специальный тип для возврата значения и обязать всех им пользоваться.
О проверке типов компилятором и четком понимании на каком участке кода какие ситуации могут возникнуть тут речи нет, вернее компилятору понять такой код не проще, чем код с исключениями.
Про типобезопасность и обработку краевых случаев тоже непонятно. Возьмём например то самое деление, которое в статье. И в том и в другом случае надо проверить нету ли там нуля. И это должен сделать программист. И он одинаково эффективно забудет об этом и в том и в другом случае и компилятор ему не поможет.
В функциональных языках многое прекрасно. И применению ФП в императивных языках тоже есть место, но оно не в обработке исключительных ситуаций.
И если бы в обмен на отсутствие исключений мы получили возможность объявить чистую функцию, результаты выполнения которой можно кешировать и параллелить, то это можно было бы декларировать фичей языка. Но я так понял об этом нет и речи. Может есть хотя бы модификатор const для методов, как в С++?
Механизм исключений позволяет не вводить дополнительного возвращаемого типа, позволяет не вводить метод map и при этом писать понятный и простой код. Также позволяет не писать в функциональном стиле, если тебе это не нравится и писать когда это приятно.
Преимущества функционального подхода (помимо эстетических) тут вообще не совсем понятны. Или в Swift есть возможность объявить чистую функцию? Или компилятор умеет доказывать её чистоту?
В С++, Java и других языка, поддерживающих исключения код будет выглядеть гораздо проще. Вот примерно так.
А тут тот же Objective C вид сбоку.
Я бы с удовольствием похоливарил по поводу этих мелочей, но мне кажется, что вам будет интереснее узнать мое мнение по поводу вещей, которые я мелочами не считаю. Не мелочи — это заблуждение о том, что стрелки всегда под рукой, что режимы — зло, пусть и неизбежное и что вам нужен инструмент, который будет помогать работать.
На моей клавиатуре от home row до стрелок — сантиметров 10. Переносить руку на эти 10 сантиметров при малейшей необходимости подвинуть курсор, а потом, когда надо что-то напечатать — переносить руку обратно — верный путь к нервному расстройству. Конечно, если печатать вслепую не умеешь и вообще набираешь текст медленно и двумя пальцами, а правая рука и так ходит между клавиатурой и мышью — действительно создаётся иллюзия, что стрелки под рукой, но платой за эту иилюзию является низкая эффективность работы с редактором.
И режимы в Виме выполняют функцию ограждения пользователя от ужасов постоянного перемещения правой руки между мышью, стрелками и буквами. Без них Вим не нужен, в них его смысл и высокая миссия :). Именно с их помощью Вим помогает работать и несёт добро в мир!
А вот по поводу того, что вам не нужен инструмент, который будет помогать работать — это я покривил душой. Просто это не единственное ваше требование к инструменту. Вам, судя по вашим словам, также важно, чтобы кривая обучения была как можно более пологой, а лучше вообще отсутствовала. То есть есть какое-то соотношение степени в которой инструмент помогает жить и того, насколько трудно им овладеть.
И это безусловно правильный подход, если только большая часть вашей жизни не проходит в работе с текстом. Если вы занимаетесь текстом постоянно, то на овладение инструментом не жалко потратить время, потому что это экономия времени в итоге будет колоссальна. По крайней мере так считают те, кто пользуется вимом или емаксом.
P. S. Вы никого не обидели, не переживайте. Холивары — в свободное от работы время — крайне полезная и интересная штука ибо при участии в них велик шанс узнать что-то радикально новое.
А вот дальше интересно. Комбинацию, которая используется для выделения слова в ОС можно без проблем использовать в любом из исчадий блокнота — никаких проблем. И это действительно плюс ST, но он идёт в графу «Просто для использования неопытным пользователем». Потому что, как вы совершенно верно отметили, так слово можно выделить только если курсор стоит в начале или в конце слова. Что конечно ужасно неудобно. А если он в где-нибудь в середине, то неизбежно придётся читать про Ctrl+d.
Короче, если не учить хоткеи, то отличия Саблайма от блокнота вообще сводятся к минимуму. А если пользоваться мышью, то наверное единственная его фича — это миникарта файла. И собственно всё. Ну то есть тоже интересно конечно, но для того, чтобы пользоваться им по несколько часов в день — как-то маловато.
Что для абсолютно любого действия в Виме надо помнить хоткей или команду — большое преувеличение. Что такое режимы придётся выяснить — это да. А дальше можно обходиться минимумом. Можно даже пользоваться стрелками. Только работать не используя всё богатство возможностей редактора неудобно независимо от названия этого редактора. Изучать придётся и ST и Vim.
Приводить примеры чудес всегда нелегко. Особенно в случае с вимом. Если для того, чтобы крутить сальто нужно год тренироваться — кому нужно это сальто и, что самое главное, какое же это чудо :). Но я попробую.
Чудо — это вообще весь Вим и его режимы.
Чудо — что не нужно тянуть руку к стрелкам каждый раз, когда хочешь чуть-чуть передвинуть курсор. И что для выделения кусков текста не надо зажимать одновременно несколько клавиш.
Чудо — что если ты подредактировал строку, а потом после беглого просмотра файла понял, что надо вписать в ту же строку ещё что-нибудь — достаточно набрать gi и курсор окажется в конце последнего редактированного куска.
Чудо — что для первого поиска сделующего вхождения слова под курсором нужно набрать *, а для того, чтобы найти где оно встречается в третий раз достаточно нажать n. А чтобы найти где оно встречается выше по тексту — N.
Чудеса не в том, что можно сделать в Виме, а в том как это делается.
ssh тоже не сильно важно.
А вот насчёт интуитивности к Sublime Text большие вопросы. То есть Ctrl+v, Ctrl+c и Ctrl+x это в общем интуитивно, как и стрелки, как и сочетание Ctrl+стрелки.
А вот чтобы выделить слово, кажется надо нажать Ctrl+d. Это ни разу не интуитивно и это придётся запоминать, как и огромную кучу других хоткеев. Но так как Sublime это такой расширенный и улучшенный блокнот — работать можно и без них. Правда удобство работы с текстом — тоже как у блокнота, хоть и на стероидах.
Вим подходит к проблеме более радикально. Он вообще в руках неопытного пользователя умеет только пищать и всё портить. Но применение принципиально другой схемы работы с текстом позволяет обученному пользователю творить чудеса, на которые блокнот не способен в силу отсутствия модальности.
Главная фича Vim — комфорт, которого блокнот дать не может by design. Ради этого комфорта и стоит учиться пользоваться Vim. Пусть это и требует определённых усилий.
Я тоже настраивал себе автоматическую закачку после копирования *.torrent файла в директорию и копирование загруженных файлов в целевую директорию в зависимости от местонахождения *.torrent файла.
Но вот копирование файлов с магнет-линков у меня настроить так и не получилось. Когда магнет-линк скачан rtorrent теряет файлы с раздачи и считает их нескачанными. Происходит это, как я понимаю, из-за отсутствия соответствующего раздаче *.torrent файла. Может кто знает, как это побороть?