Без интернета, очевидно, это так не заработает. Но я не агитирую за питон на все случаи жизни, я просто поделился своим конкретным опытом, что даже на embedded linux платформах (я не говорю про остальной парк пк и серверов на разных ОС) для меня именно такая конфигурация стала самой простой и универсальной.
Если вам необходимо работать в подобных задачах оффлайн, понимаю, что скомпилированная программа с зависимостями может быть проще. Думаю, есть способ сделать такой трюк и с питоном, но это не лежит на поверхности, я так не делал. Однако, по-прежнему не понимаю, чем пачка dll (если мы говорим про Windows) мешает по сравнению со статически слинкованным exe. У меня был ряд внутренних рабочих программ, которые нужно было так использовать, никаких сложностей не возникало.
А в чём проблема использовать C/C++, а стандартную библиотеку слинковать статически? Да и Go изначально таким же был, не знаю, как сейчас. Хотя лично я никогда не понимал, в чём прелесть ограничения себя одним exe-файлом. Ну пусть рядом пара dll лежит, это же не проблема. Вообще, в плане простоты и переносимости, я в последнее время пришёл к python для этих задач. Пара простых действий (venv, pip, python), и всё работает на любой платформе, от сервера до embedded linux.
В первую очередь я ссылаюсь на личный опыт, как руководитель, неоднократно работавший в разное время во всех перечисленных форматах. Почему обсуждать не имеет смысла? С точки зрения научного метода, личный опыт и наблюдения лежат в начале познания. Особенно в век приближения эпохи мёртвого интернета, если она действительно наступит) Говоря об опыте других компаний, в СМИ я много и часто встречал паттерн новости "Компания Х возвращает сотрудников в офис", но тут, признаю, я не занимался исследованиями, какие там истинные причины, сопутствующие цели и статистические результаты.
Под результатом я понимаю продуктивное выполнение разработчиками своей работы, т.е. говоря о программистах - написание кода, погружённость в архитектуру и задачи, коммуникации с руководителями и в команде, скорость перехода от процесса написания кода к завершённому результату и т.д.
Охх, честно говоря, я вообще не представляю, какого сотрудника можно заменить на ИИ. Даже до замены офис-менеджера как до луны. По-моему, единственный случай "замены" - это операторы колл-центра, и слово "замена" я пишу в кавычках, т.к. ни одну задачу, которую решил бы оператор, пришедший ему на "замену" ИИ решить не может, и является это завуалированным отказом от колл-центров как таковых. Причина проста - нужно иметь доступ к нестандартно запрошенным данным, и уметь принимать решения. Ни один руководитель в здравом уме этих полномочий ИИ не даст. Остаются только заскриптованные чат-боты, популярные 20 лет назад, история сделала круг)
Речь идёт о том, что есть эмпирические зависимости:
Аутсорс по сравнению со штатными разработчиками - хуже результат
Удалённый сотрудник по сравнению с сотрудником в офисе - хуже результат
Безусловно, это не догма, и огромное количество частных случаев могут работать и в обратную сторону, но именно на общей картине, на мой взгляд, получается именно так. Сужу по своему опыту, и, насколько я понял из СМИ, после разгула удалёнки и аутсорса 2020-2021 года очень многие компании сделали такие же выводы.
Интересный подход! По названию, я подумал, что вы будете говорить о реализации асинхронный логики путем использования аппаратных контроллеров периферии и памяти. Но тут настоящий python/js async :) Выглядит впечатляюще!
Хотя я бы так не писал. Во многих задачах, где мне доводилось применять микроконтроллеры, нужно так или иначе реальное время - а том смысле, что время реакции системы на входные сигналы должно быть однозначно предсказуемо. Применение async этому препятствует - очень трудно однозначно сказать, будет в конкретном месте когда yield или не будет, и не получится ли, что при каком-то редком сочетании факторов время реакции будет неожиданно сильно большим, чем в остальных случаях.
Ну и к preprocessor hell это уже очень близко. :) Напоминает труды Александреску по C++, очень красиво, но лучше не применять в реальной жизни)
Я пробовал какое-то время пользоваться vim, научился худо-бедно навигации и редактированию, но мне всё время казалось, что я себя насилую на простейших задачах:) Видимо, не хватило до порога комфорта. В emacs, кстати, тоже какое-то время сидел, но после современных редакторов это всё кажется очень неудобным.
Увы, Sublime мне кажется не самой подходящей программой для "простого редактора". Без изучения возможностей (и как ими пользоваться) дальше стартового окна не уйти. Наполовину как [g]vim, про который ниже также писали.
На мой взгляд, это всё-таки недостаток программы, т.к. к 2025 году сложились удачные практики UI/UX, которые позволяют изучать программу по мере её использования, а не до первого запуска. Пример - тот же VS Code. А отдельно изучать текстовый редактор мне кажется немного притянутой задачей, если его роль - именно простой базовый редактор, не IDE и подобное. Для профессиональных задач я использую другие IDE, CAD, EDA программы, всеми из которых нужно уметь хорошо пользоваться, и с этой точки зрения изучать ещё и "простой текстовый редактор конфигов" кажется немного лишним.
Если кто-то использует sublime или gvim как основной рабочий инструмент, и хорошо его изучил, тогда нет вопросов. Они должны быть довольно круты в этом случае.
Это правда, просто часть редакторов, типа самого Notepad старых версий (не знаю, как сейчас), грузят весь файл в буфер, в результате чего даже на файле в несколько десятков мегабайт редактор ложится намертво. Речь только об этом. Конечно, вы правы, есть сценарии, в которых никакой редактор не может преодолеть физических ограничений, но это другая история.
Эх, xpaint :) Задумка, очевидно, именно такая, но им невозможно пользоваться, он ужасен во всём. Как и его брат gpaint (GNU paint). При необходимости использовать "paint" на Linux я в итоге пришёл к Krita, хотя она, конечно, жирновата по сравнению с истинным Paint.
К базовому текстовому редактору, на мой взгляд, основные требования такие: мгновенное открытие для редактирования конфигов и текстовых файлов, мгновенный отклик при работе с файлами произвольной длины, подсветка синтаксиса, навигация по файлам в дереве каталогов, поддержка разных кодировок. Требования не изменились со времён FAR :)
С этой точки зрения, notepad++ пробовал много раз (как и notepad2 и всё подобное). Конкретно у него недостатки: отсутствие внятного простого способа навигации по дереву файлов, очень перегруженный интерфейс кучей сомнительных функций, неприятное и хаотичное оформление UI, плохой UX/DX (user/developer experience).
Онлайн-редакторы эту задачу тоже, очевидно, не решают. Может быть, для других задач они неплохие (не знаю, я не нашёл им применения), но для быстрого distraction-free редактирования конфигов - явно нет.
Paint .NET, конечно, неплох. Но про Paint я говорил об отсутствии аналога в Linux. В Windows есть сам оригинальный Paint, который, на мой взгляд, идеален и совершенен, это как уаз буханка, или json - такие вещи, скорее, можно открыть (как научное открытие), а не разработать:)
А может, те же 30 минут, в этих документах обычно необходимая для реализации подобной задачи часть значительно меньше, чем весь документ. По своему опыту, я соглашусь с утверждением статьи. С одной стороны, мне кажется, что моя эффективность выросла в разы, особенно при работе с неизвестными ранее технологиями. С другой стороны, как-то до LLM я писал ещё более сложные проекты, чем сейчас, да и применять новые технологии любил тоже больше, и как-то не мешало)
Увы, меня годами мучает эта проблема, что нет нормальной альтернативы notepad и calc под Windows. Под Linux чуть лучше, но зато там нет аналога paint. Честно, за годы я перепробовал все, что мог найти, но увы. И платные приложения покупал, тщетно. Так и пользуюсь под windows geany и физическим научным калькулятором. Остается только сделать вывод, что простота данных программ немного обманчива, чтобы был поток любительских хобби-программ, плюс они плохо монетизируются, чтобы были профессионально сделанные альтернативы.
Утверждение очень радикальное, и совсем неверное :)
Сравните начальный МК и начальный процессора ARM, на котором может работать Linux: Цена от 3-5 центов против $3-5 (плюс память DDR) Время загрузки: микросекунды против секунд Количество компонентов обвязки в BOM: от 1 против 100+ Корпус: от WLCSP 1x1мм против BGA200+ размер не менее 7х7 Плата: 2-слойная против 4+ слойной Энергопотребление в режиме работы от единиц ма до сотни ма
И так далее. Тут даже сравнивать нечего. Всё, что можно сделать на МК, будет сделано на МК, я говорю как инженер. Automotive, military, industrial, home automation, wearable и т.д.:)
Я бы Вышу мысль по-другому повернул. Дискретные микросхемы уходят в прошлое, когда нафаршированный 32-битный RISC со встроенной флеш-памятью стоит пару центов. А микроконтроллеры теперь ставят везде.
Без интернета, очевидно, это так не заработает. Но я не агитирую за питон на все случаи жизни, я просто поделился своим конкретным опытом, что даже на embedded linux платформах (я не говорю про остальной парк пк и серверов на разных ОС) для меня именно такая конфигурация стала самой простой и универсальной.
Если вам необходимо работать в подобных задачах оффлайн, понимаю, что скомпилированная программа с зависимостями может быть проще. Думаю, есть способ сделать такой трюк и с питоном, но это не лежит на поверхности, я так не делал. Однако, по-прежнему не понимаю, чем пачка dll (если мы говорим про Windows) мешает по сравнению со статически слинкованным exe. У меня был ряд внутренних рабочих программ, которые нужно было так использовать, никаких сложностей не возникало.
А в чём проблема использовать C/C++, а стандартную библиотеку слинковать статически? Да и Go изначально таким же был, не знаю, как сейчас.
Хотя лично я никогда не понимал, в чём прелесть ограничения себя одним exe-файлом. Ну пусть рядом пара dll лежит, это же не проблема. Вообще, в плане простоты и переносимости, я в последнее время пришёл к python для этих задач. Пара простых действий (venv, pip, python), и всё работает на любой платформе, от сервера до embedded linux.
В первую очередь я ссылаюсь на личный опыт, как руководитель, неоднократно работавший в разное время во всех перечисленных форматах. Почему обсуждать не имеет смысла? С точки зрения научного метода, личный опыт и наблюдения лежат в начале познания. Особенно в век приближения эпохи мёртвого интернета, если она действительно наступит) Говоря об опыте других компаний, в СМИ я много и часто встречал паттерн новости "Компания Х возвращает сотрудников в офис", но тут, признаю, я не занимался исследованиями, какие там истинные причины, сопутствующие цели и статистические результаты.
Под результатом я понимаю продуктивное выполнение разработчиками своей работы, т.е. говоря о программистах - написание кода, погружённость в архитектуру и задачи, коммуникации с руководителями и в команде, скорость перехода от процесса написания кода к завершённому результату и т.д.
Охх, честно говоря, я вообще не представляю, какого сотрудника можно заменить на ИИ. Даже до замены офис-менеджера как до луны. По-моему, единственный случай "замены" - это операторы колл-центра, и слово "замена" я пишу в кавычках, т.к. ни одну задачу, которую решил бы оператор, пришедший ему на "замену" ИИ решить не может, и является это завуалированным отказом от колл-центров как таковых. Причина проста - нужно иметь доступ к нестандартно запрошенным данным, и уметь принимать решения. Ни один руководитель в здравом уме этих полномочий ИИ не даст. Остаются только заскриптованные чат-боты, популярные 20 лет назад, история сделала круг)
Речь идёт о том, что есть эмпирические зависимости:
Аутсорс по сравнению со штатными разработчиками - хуже результат
Удалённый сотрудник по сравнению с сотрудником в офисе - хуже результат
Безусловно, это не догма, и огромное количество частных случаев могут работать и в обратную сторону, но именно на общей картине, на мой взгляд, получается именно так. Сужу по своему опыту, и, насколько я понял из СМИ, после разгула удалёнки и аутсорса 2020-2021 года очень многие компании сделали такие же выводы.
Интересный подход! По названию, я подумал, что вы будете говорить о реализации асинхронный логики путем использования аппаратных контроллеров периферии и памяти. Но тут настоящий python/js async :) Выглядит впечатляюще!
Хотя я бы так не писал. Во многих задачах, где мне доводилось применять микроконтроллеры, нужно так или иначе реальное время - а том смысле, что время реакции системы на входные сигналы должно быть однозначно предсказуемо. Применение async этому препятствует - очень трудно однозначно сказать, будет в конкретном месте когда yield или не будет, и не получится ли, что при каком-то редком сочетании факторов время реакции будет неожиданно сильно большим, чем в остальных случаях.
Ну и к preprocessor hell это уже очень близко. :) Напоминает труды Александреску по C++, очень красиво, но лучше не применять в реальной жизни)
Я пробовал какое-то время пользоваться vim, научился худо-бедно навигации и редактированию, но мне всё время казалось, что я себя насилую на простейших задачах:) Видимо, не хватило до порога комфорта. В emacs, кстати, тоже какое-то время сидел, но после современных редакторов это всё кажется очень неудобным.
Увы, Sublime мне кажется не самой подходящей программой для "простого редактора". Без изучения возможностей (и как ими пользоваться) дальше стартового окна не уйти. Наполовину как [g]vim, про который ниже также писали.
На мой взгляд, это всё-таки недостаток программы, т.к. к 2025 году сложились удачные практики UI/UX, которые позволяют изучать программу по мере её использования, а не до первого запуска. Пример - тот же VS Code. А отдельно изучать текстовый редактор мне кажется немного притянутой задачей, если его роль - именно простой базовый редактор, не IDE и подобное. Для профессиональных задач я использую другие IDE, CAD, EDA программы, всеми из которых нужно уметь хорошо пользоваться, и с этой точки зрения изучать ещё и "простой текстовый редактор конфигов" кажется немного лишним.
Если кто-то использует sublime или gvim как основной рабочий инструмент, и хорошо его изучил, тогда нет вопросов. Они должны быть довольно круты в этом случае.
Это правда, просто часть редакторов, типа самого Notepad старых версий (не знаю, как сейчас), грузят весь файл в буфер, в результате чего даже на файле в несколько десятков мегабайт редактор ложится намертво. Речь только об этом. Конечно, вы правы, есть сценарии, в которых никакой редактор не может преодолеть физических ограничений, но это другая история.
Эх, xpaint :) Задумка, очевидно, именно такая, но им невозможно пользоваться, он ужасен во всём. Как и его брат gpaint (GNU paint). При необходимости использовать "paint" на Linux я в итоге пришёл к Krita, хотя она, конечно, жирновата по сравнению с истинным Paint.
К базовому текстовому редактору, на мой взгляд, основные требования такие: мгновенное открытие для редактирования конфигов и текстовых файлов, мгновенный отклик при работе с файлами произвольной длины, подсветка синтаксиса, навигация по файлам в дереве каталогов, поддержка разных кодировок. Требования не изменились со времён FAR :)
С этой точки зрения, notepad++ пробовал много раз (как и notepad2 и всё подобное). Конкретно у него недостатки: отсутствие внятного простого способа навигации по дереву файлов, очень перегруженный интерфейс кучей сомнительных функций, неприятное и хаотичное оформление UI, плохой UX/DX (user/developer experience).
Онлайн-редакторы эту задачу тоже, очевидно, не решают. Может быть, для других задач они неплохие (не знаю, я не нашёл им применения), но для быстрого distraction-free редактирования конфигов - явно нет.
Paint .NET, конечно, неплох. Но про Paint я говорил об отсутствии аналога в Linux. В Windows есть сам оригинальный Paint, который, на мой взгляд, идеален и совершенен, это как уаз буханка, или json - такие вещи, скорее, можно открыть (как научное открытие), а не разработать:)
А может, те же 30 минут, в этих документах обычно необходимая для реализации подобной задачи часть значительно меньше, чем весь документ. По своему опыту, я соглашусь с утверждением статьи. С одной стороны, мне кажется, что моя эффективность выросла в разы, особенно при работе с неизвестными ранее технологиями. С другой стороны, как-то до LLM я писал ещё более сложные проекты, чем сейчас, да и применять новые технологии любил тоже больше, и как-то не мешало)
Увы, меня годами мучает эта проблема, что нет нормальной альтернативы notepad и calc под Windows. Под Linux чуть лучше, но зато там нет аналога paint. Честно, за годы я перепробовал все, что мог найти, но увы. И платные приложения покупал, тщетно. Так и пользуюсь под windows geany и физическим научным калькулятором. Остается только сделать вывод, что простота данных программ немного обманчива, чтобы был поток любительских хобби-программ, плюс они плохо монетизируются, чтобы были профессионально сделанные альтернативы.
Утверждение очень радикальное, и совсем неверное :)
Сравните начальный МК и начальный процессора ARM, на котором может работать Linux:
Цена от 3-5 центов против $3-5 (плюс память DDR)
Время загрузки: микросекунды против секунд
Количество компонентов обвязки в BOM: от 1 против 100+
Корпус: от WLCSP 1x1мм против BGA200+ размер не менее 7х7
Плата: 2-слойная против 4+ слойной
Энергопотребление в режиме работы от единиц ма до сотни ма
И так далее. Тут даже сравнивать нечего. Всё, что можно сделать на МК, будет сделано на МК, я говорю как инженер. Automotive, military, industrial, home automation, wearable и т.д.:)
Я бы Вышу мысль по-другому повернул. Дискретные микросхемы уходят в прошлое, когда нафаршированный 32-битный RISC со встроенной флеш-памятью стоит пару центов. А микроконтроллеры теперь ставят везде.