Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.
Чтобы эта функция принимала на вход аргупент option? Не, в целом подход с lift функцией прикольный, но обработка ошибок в lift отсутствует полностью, так что для промышленной рвзработки такой код неприемлем.
В дополнение хочется хочется посмотреть на то, как монада разрулит ситуацию с функциями, которые принимают больше, чем один аргумент на вход и/или возвращают кортеж значений
Я считаю, что проблема всех туториалов про монады в том, что все объяснение монад ВСЕГДА заканчивается на Option, ценность которой, по моему мнению, около нуля, т.к. с помощью этой невероятно тупой монады не написать НИЧЕГО полезного. В реальном мире мы всегда хотим знать не только, что "что-то" пошло не так, но ещё и "где".
Для этого есть другая монада (Result), но с ней начинается другая беда - ошибок в программе может быть больше тысячи. Бросая даже один тип исключения мы всегда получим stacktrace с точным местом ошибки, а для Result придется иметь кучу возможных возвращаемых значений + сложности с обработкой этих ошибок. Кстати, в целом всегда показывают монады в стиле: "смотрите какой у нас классный код линейный", но никогда не показывают код обработки ошибок этого линейного кода.
Также всегда остаются за рамками обсуждений все вопросы связанные с соединением двух разных монад. Нефига не очевидно, как из одной монады получаются другие, как они между собой взаимодействуют и главное - почему это всё лучше обычного императивного подхода.
У нас есть носитель сигнала (ток, напряжение), у которого есть характеристики (амплитуда, фаза, частота). Изменяя характеристики мы сигнал кодируем. Соответственно изменяя одну из характеристик, мы меняем и регистрируемый на другом конце сигнал.
Проблема в том, что изменение чего либо в цепи требует энергии. Но тут сразу прикол в том, что получается эту энергию надо откуда-то взять. Но чесслово из схемы транзистора не очень понятно откуда эта энергия берётся)
Я готов признать, что GUI очень удобен при настройки графики и всяких элементов системы, требующих визуального контроля (цвета, шрифты, размеры панелей и пр.).
С другой стороны, настройки сети, разделов, параметров мониторования ОС, конфигурация и запуск всяких демонов (SSH, docker, etc), обновление системы, установка/удаление приложений, создание/удаление пользователей, поиск по файлам и их содержимому, бекапы - в разы удобнее настраивать в консоли.
Из других очевидных плюсов - это всё можно автоматизировать. Совсем хорошая новость в том, что скрипты не зависят от DE, а значит не надо в каждой графической оболочке разбираться.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
Это да, но кто-то же должен ей заниматься? :) Удивительный прикол жизни в том, что процессы реально меняющие что-то в этом мире - это огромный механизм, требующий очень много рутины для поддержания его работоспособности :) И главный вопрос в том, как сделать счастливыми именно тех, кто крутит педали в спортзале, а не тех, кто катается на мотоцикле по автобану)
Чёт не осилил это прочитать, но судя по табличкам формула простая: "чтобы было хорошо, надо работать в хороших компаниях" и "чтобы ваша компания была хорошей, надо делать хорошие проекты")
Зависит от того, какие гарантии ты обещал пользователям. В ядре Linux действительно пофигу какие цифры, т.к. никто обратной совместимости там не обещал никогда. В других продуктах это может быть вовсе не так.
Но таки определенные договоренности о гарантиях совместимости между версиями удобная вещь, когда нужно без глубокого и долгого анализа на глаз прикинуть "а взлетит моё ПО в этом окружении или нет, и сколько займет времени допиливание".
Я аж поперхнулся :) Я вроде не слишком старый, только приближаюсь к 30, но в принципе поперхнулся бы и в свои 23. Для меня загадка кому нужен GUI для конфигурирования. Это постоянно ж надо помнить и совершать тонны бессмысленных телодвижений.
Если надо, перед передачей упаковать в Option
Не занимаемся. Чем этот действительно занимается - так это заметанием ошибок под ковёр.
Вот положим у меня цепочка вычислений из, ну скажем, 15 преобразований. Вернулся None. Надо понять почему. Как?
Чтобы эта функция принимала на вход аргупент option? Не, в целом подход с lift функцией прикольный, но обработка ошибок в lift отсутствует полностью, так что для промышленной рвзработки такой код неприемлем.
Что ж, в функции getSecondArg что-то пошло не так. Надо это залогировать и послать сообщение юзверю. Как?
Чем это лучше, чем просто текст в стиле: "на такой-то строке, в таком-то тэге, у вас неправильный атрибут"?
Зачем печатать что-то непонятное (дерево тэгов), если можно просто напечатать сам HTML. Он вполне себе читаемый.
Это я в курсе, но покажите мне код (с монадамм) после этого) Потому что это будет нечто невразумительное
А можно просто переписать первую и не городить бессмысленные конструкции
Прочитал, но пока не понял, чем это удобнее обычного
В дополнение хочется хочется посмотреть на то, как монада разрулит ситуацию с функциями, которые принимают больше, чем один аргумент на вход и/или возвращают кортеж значений
Я считаю, что проблема всех туториалов про монады в том, что все объяснение монад ВСЕГДА заканчивается на Option, ценность которой, по моему мнению, около нуля, т.к. с помощью этой невероятно тупой монады не написать НИЧЕГО полезного. В реальном мире мы всегда хотим знать не только, что "что-то" пошло не так, но ещё и "где".
Для этого есть другая монада (Result), но с ней начинается другая беда - ошибок в программе может быть больше тысячи. Бросая даже один тип исключения мы всегда получим stacktrace с точным местом ошибки, а для Result придется иметь кучу возможных возвращаемых значений + сложности с обработкой этих ошибок. Кстати, в целом всегда показывают монады в стиле: "смотрите какой у нас классный код линейный", но никогда не показывают код обработки ошибок этого линейного кода.
Также всегда остаются за рамками обсуждений все вопросы связанные с соединением двух разных монад. Нефига не очевидно, как из одной монады получаются другие, как они между собой взаимодействуют и главное - почему это всё лучше обычного императивного подхода.
Это не так чтобы корректное объяснение.
У нас есть носитель сигнала (ток, напряжение), у которого есть характеристики (амплитуда, фаза, частота). Изменяя характеристики мы сигнал кодируем. Соответственно изменяя одну из характеристик, мы меняем и регистрируемый на другом конце сигнал.
Проблема в том, что изменение чего либо в цепи требует энергии. Но тут сразу прикол в том, что получается эту энергию надо откуда-то взять. Но чесслово из схемы транзистора не очень понятно откуда эта энергия берётся)
В таком случае на источнике энергии должен формироваться такой же сигнал, но инвертированный по фазе, но этого не происходит
Выбор небогат:
Содержимое предыдущих сообщений - гавно
Обсуждаемая тема гавно, но все что мы можем - это смириться
Собеседник тупой, т.к. сам не знает чё имел ввиду
Я не вижу причинно-следственной связи между
и