Мне аж страшно подумать о том, что такое вы пишете, что вам прям в процессе работы над проектом приходится добавлять новый функционал в сам редактор.
Иногда замечаешь или что раздражает какая-нибудь мелочь, или что часто повторяешь какие-то довольно однообразные действия. Тогда я просто открываю условный init.el и пишу небольшую функцию, которая это (как мне кажется) исправляет. Потом, возможно, возвращаюсь к ней, исправляю, уточняю и т.д.
Думаю, в каком-то виде это возможно в любом текстовом редакторе. Но обычно всё же от появления мысли "это неудобно" до исправления неудобства надо пройти длинный путь, написать условное "расширение" и т.д. Мне просто было бы лень это делать. В Emacs же это быстро и просто: набросал в *scratch*, выполнил, запустил.
Ну, я, например, пользуюсь. И, полагаю, каждый, кто осознанно пользуется Emacs тоже, так как, в общем-то, кроме программируемости и упомянутой другими комментаторами стабильности, других плюсов у Emacs нет. Но для некоторых, включая меня, эти плюсы - это killer features Emacs'а.
К тому же сам LISP язык в целом мёртвый, прямо как латынь. Т.е. если захочется ковыряться в Emacs - придётся выучить LISP только для этого, и ни для чего больше
Это же не C++, что там учить-то? Синтаксис и семантику самого Emacs Lisp'а можно усвоить за полчаса. Внутренности самого Emacs'а, конечно, устроены сложнее, и часто можно наткнуться на довольно странное legacy. Но иногда наоборот удивляешься элегантности решений.
Программируемостью. Emacs - это не текстовый редактор, а интерпретатор Emacs Lisp'а; соотвественно, все внутренности Emacs'а (кроме самого интерпретатора) доступны для просмотра и изменения в процессе его работы.
Ну так ведь это плохо. По сути, чем популярнее продукт X, тем сложнее его конкуренту Y выжить, даже если он в чём-то лучше X или просто другой. В результате мы практически во всех сферах наблюдаем либо монополию, либо в лучшем случае олигополию с 2-3 игроками.
Поэтому, как мне кажется, сам факт того, что есть какие-то, хоть кривые и косые, но альтернативы Андроиду и iOS - это уже хорошо. И желать им успеха можно только из соображения того, что монополистов надо хотя бы иногда кусать за пятки (если уж ничего другого с ними сделать нельзя).
Я всё же так и не понял какие обязательства берёт на себя ментейнер, после того как какие-то (в целом, случайные) люди называют его ПО "критическим"? По-моему, почти в любой лицении на СПО содержится параграф про "отказ от обязательств".
Пользуясь случаем, спрошу у более знающих коллег: а как вообще определить что такое ФП-стиль? Не через признаки, а через суть?
Я для себя некоторое время назад некое подобие определения сформулировал, но я всё же совсем не специалист в этом всём, поэтому буду рад, если кто-нибудь скажет, прав ли я.
По мне так императивное программирование основано на машине Тьюринга: мы всё равно мыслим некоего исполнителя и некую ленту-память, и исполнитель исполняет некоторый набор команд, меняя состояние памяти.
Функциональное же программирование основывается на лямбда-исчислении. У нас уже нет ни исполнителя, ни памяти, ни состояний, ни команд, а есть некоторый текст (программа) и правила его редукции. И "выполнение" есть просто редуцирование текста в нормальную форму. В идеале (если я правильно помню, если наше исчисление (язык) сильно нормализуемо) порядок редукций не влияет на результат, так что слово "выполнение" лучше писать в кавычках.
Меня смущает то, что, как мне кажется, моё понимание этой всей терминологии противоречит тому, как она обычно применяется, поэтому мне кажется, что я ошибаюсь.
На мой вкус, одна из лучших книг про контакт это "Глас Господа" Лема. Она, конечно, довольно специфическая; но ведь статья про "книги с оригинальным подходом"?
Для меня капитализм — это как в США, РФ, Аргентине, Мексике. Социализм — это как в Дании, Швеции, Германии.
Мне кажется, проблема большинства споров и в интернете, и вне него в том, что у каждой из сторон этическое наполнение терминов становится определяющим для них: термин X определяется через то, что X — это хорошо, а термин Y определяется через то, что Y — это плохо. И спор часто сводится к спору об определениях: X — это плохо или хорошо?
Возможно, ваше определение через примеры является как раз таким скрытым сведением к «определению через этические категории»?
P.S. Вообще чаще всего то, о чём я написал, можно заметить в спорах о проблеме демаркации науки: наука в них определяется как то, что хорошо, а ненаука как то, что плохо.
Мне кажется, одна из главных ошибок некоторых мыслителей левого толка в том, что они считают, что технический прогресс занимается удовлетворением потребностей, которые при этом не меняются. Но 100 лет назад у людей не было потребности в мобильном телефоне новой марки, в компьютере и игрушках на нём и т.д. и т.п. Прогресс создаёт новые потребности, удовлетворяя старые.
К тому же в том мире, в котором мы живём, и потребности, и само потребление стало большей частью символическим (на эту тему, например, можно почитать когда-то очень популярного Бодрийяра), а никакой технический прогресс не сможет удовлетворить символическую потребность. Более того, сам этот прогресс является такой потребностью, вполне неплохо, как мы видим, продаваемой.
Когда-то я пытался настроить Vim для нормальной работы с Python. Оказалось, что:
— Нормального автодополнения (а не того, которое грузит процессор на 100% и виснет на несколько минут) нет.
— Нормального дебаггера (без необходимости делать print на каждую переменную) тоже нет.
Т.о. для меня vim так и не стал заменой ide, к сожалению.
Но надо ли ему таковой быть?
ИМХО, машинное обучение никак не может помочь в создании сильного ИИ, т.к. человек, в отличие от любой искуственной нейронной сети, действует в отсутствии какой-либо постановки задачи. Человеческий интеллект выражается в приписывании смыслов априори бессмысленным сырым данным, а задача ML — эктраполировать на больший набор данных те смыслы, которые им уже приписал человек («победа»/«поражение» в случае го и шахмат, «котики»/«не котики» в случае классификации картинок, слова из словаря в случае распознавания речи).
Иногда замечаешь или что раздражает какая-нибудь мелочь, или что часто повторяешь какие-то довольно однообразные действия. Тогда я просто открываю условный init.el и пишу небольшую функцию, которая это (как мне кажется) исправляет. Потом, возможно, возвращаюсь к ней, исправляю, уточняю и т.д.
Думаю, в каком-то виде это возможно в любом текстовом редакторе. Но обычно всё же от появления мысли "это неудобно" до исправления неудобства надо пройти длинный путь, написать условное "расширение" и т.д. Мне просто было бы лень это делать. В Emacs же это быстро и просто: набросал в *scratch*, выполнил, запустил.
Ну, я, например, пользуюсь. И, полагаю, каждый, кто осознанно пользуется Emacs тоже, так как, в общем-то, кроме программируемости и упомянутой другими комментаторами стабильности, других плюсов у Emacs нет. Но для некоторых, включая меня, эти плюсы - это killer features Emacs'а.
Это же не C++, что там учить-то? Синтаксис и семантику самого Emacs Lisp'а можно усвоить за полчаса. Внутренности самого Emacs'а, конечно, устроены сложнее, и часто можно наткнуться на довольно странное legacy. Но иногда наоборот удивляешься элегантности решений.
Программируемостью. Emacs - это не текстовый редактор, а интерпретатор Emacs Lisp'а; соотвественно, все внутренности Emacs'а (кроме самого интерпретатора) доступны для просмотра и изменения в процессе его работы.
Ну так ведь это плохо. По сути, чем популярнее продукт X, тем сложнее его конкуренту Y выжить, даже если он в чём-то лучше X или просто другой. В результате мы практически во всех сферах наблюдаем либо монополию, либо в лучшем случае олигополию с 2-3 игроками.
Поэтому, как мне кажется, сам факт того, что есть какие-то, хоть кривые и косые, но альтернативы Андроиду и iOS - это уже хорошо. И желать им успеха можно только из соображения того, что монополистов надо хотя бы иногда кусать за пятки (если уж ничего другого с ними сделать нельзя).
Чтобы был выбор.
Я всё же так и не понял какие обязательства берёт на себя ментейнер, после того как какие-то (в целом, случайные) люди называют его ПО "критическим"? По-моему, почти в любой лицении на СПО содержится параграф про "отказ от обязательств".
Спасибо за статью!
Пользуясь случаем, спрошу у более знающих коллег: а как вообще определить что такое ФП-стиль? Не через признаки, а через суть?
Я для себя некоторое время назад некое подобие определения сформулировал, но я всё же совсем не специалист в этом всём, поэтому буду рад, если кто-нибудь скажет, прав ли я.
По мне так императивное программирование основано на машине Тьюринга: мы всё равно мыслим некоего исполнителя и некую ленту-память, и исполнитель исполняет некоторый набор команд, меняя состояние памяти.
Функциональное же программирование основывается на лямбда-исчислении. У нас уже нет ни исполнителя, ни памяти, ни состояний, ни команд, а есть некоторый текст (программа) и правила его редукции. И "выполнение" есть просто редуцирование текста в нормальную форму. В идеале (если я правильно помню, если наше исчисление (язык) сильно нормализуемо) порядок редукций не влияет на результат, так что слово "выполнение" лучше писать в кавычках.
Меня смущает то, что, как мне кажется, моё понимание этой всей терминологии противоречит тому, как она обычно применяется, поэтому мне кажется, что я ошибаюсь.
На мой вкус, одна из лучших книг про контакт это "Глас Господа" Лема. Она, конечно, довольно специфическая; но ведь статья про "книги с оригинальным подходом"?
Мне кажется, проблема большинства споров и в интернете, и вне него в том, что у каждой из сторон этическое наполнение терминов становится определяющим для них: термин X определяется через то, что X — это хорошо, а термин Y определяется через то, что Y — это плохо. И спор часто сводится к спору об определениях: X — это плохо или хорошо?
Возможно, ваше определение через примеры является как раз таким скрытым сведением к «определению через этические категории»?
P.S. Вообще чаще всего то, о чём я написал, можно заметить в спорах о проблеме демаркации науки: наука в них определяется как то, что хорошо, а ненаука как то, что плохо.
К тому же в том мире, в котором мы живём, и потребности, и само потребление стало большей частью символическим (на эту тему, например, можно почитать когда-то очень популярного Бодрийяра), а никакой технический прогресс не сможет удовлетворить символическую потребность. Более того, сам этот прогресс является такой потребностью, вполне неплохо, как мы видим, продаваемой.
— Нормального автодополнения (а не того, которое грузит процессор на 100% и виснет на несколько минут) нет.
— Нормального дебаггера (без необходимости делать print на каждую переменную) тоже нет.
Т.о. для меня vim так и не стал заменой ide, к сожалению.
Но надо ли ему таковой быть?