Даже не рассматривая обоснованность выбора Python для микросервисов, игнорируя Go, Java, C# или даже Rust или C/C++, проблема GIL, в принципе, решаема. Нерешаема проблема динамической типизации. Но это отдельный разговор.
Бывает, несмотря на то, что есть субъективное восприятие. Недавно посчитал, что за этот год мне пришлось использовать больше десятка языков. И несмотря на то, что не все они мне по душе, ничего от меня не отвалилось. Не будете же Вы писать новый Sink для Confluent не на Java, расширение для PostgreSQL не на C, CLR функцию для MS SQL не на C# и т.п.?
Тема нежурналируемых таблиц почти не раскрыта. А ведь использование их вместо временных таблиц может давать заметные преимущества: параллельные планы запросов, включая конструируемые вручную через dblink, и снижение нагрузки на information schema
Техзадание не имеет никакого отношения к управлению разработкой. Это лишь документ. Вы хотя бы вспомните про кризис программного обеспечения, возникший в 60-х годах и про то, как он решался Дейкстрой и Бруксом. А то складывается ощущение, что Вы вообще не представляете, чем программа отличается от программного продукта, программного комплекса и, наконец, системного программного продукта. И почему разработка последнего десятикратно сложнее, чем первого.
из времён, когда люди правда понимали что они делают и зачем, и когда оно будет готово
Зачем ворошить 50-е годы прошлого века, если уже в начале 60-х началась "смоляная яма" в разработке, принявшая катастрофические масштабы в середине 60-х?
Какая связь между техзаданием и управлением задачами? Стикеры, как я указал, появились задолго до канбана. В канбане, появившемся в конце 50-х годов прошлого века, они стали цветными. А диаграммы Ганта рисовали на доске мелом ещё в самом начале XX века.
Я уже молчу о том, что даже в конце 80-х управлять разработкой без бумажного ежедневника было мало реально. И да, цветные фломастеры или маркеры при этом широко применялись
Стикеры были бумажными. Цветными они стали только в самом конце 50-х с внедрением канбан. Вы предлагаете вернуться к еще не цветным биркам, которые использовались до конца 50-х годов прошлого века?
Как раз "трекать таски, вести историю разработки, аналитику, документацию" можно без проблем и в Redmine. А вот для менеджеров его может потребоваться допиливать, ставить или покупать нужные этим менеджерам расширения.
Вам не кажется, что сравнивать ARM Cortex-A53 с Cortex-M0+ выглядит несколько странным? Это совершенно разные весовые и ценовые категории для решения совершенно разных задач.
Для RP2040 тоже не нужен программатор. Более того, прошивка туда копируется, как на флешку (UF2), что ещё больше снижает порог входа. А платы на RP2040 мало отличаются по цене от Arduino, предоставляя на порядок-другой больше возможностей.
Нет, всё-таки CH32V003 слабоват по оборудованию, если судить по докам
В сравнении с ATMega328? Можете аргументировать?
умеющее самостоятельно работать с USB
Ну так и CH32V003, и AVR умеют работать с USB, пусть и программно. Другое дело, что в CH32V003 BootLoader выделен внутри, а в Arduino проблема работы с USB решалась дополнительным корпусом: либо вторым AVR, либо FT232RL.
сравнил этот атмегу с STM32F030
Это уже другая ценовая категория, чем CH32V003, в которой RP2040 выглядит намного предпочтительней STM32F.
Во-первых, не утрируйте, так как абсолютный максимум VCC у ATMega328 6В, а Safe Operating Area для тактовой частоты 16МГц 3.8-5.5В, что заметно хуже, чем у CH32V003, позволяющего питание 2.8-5.5В на максимальной тактовой частоте.
Во-вторых, защита от дурака определяется экспериментально и может сильно различаться от партии к партии. Но зато мешает выявлению дурака, которому наличие этой защиты потребовалось. Это я к 100мА инжектирования в пин.
В-третьих, для поддержки USB AVR требовал или второго AVR, или FT232RL, тогда как CH32V003 сам с USB справляется.
Вообще-то, кроме выпуска одноплатника, так же была заявлена реализация её поддержки в Arduino IDE. В том числе и с поддержкой low-code. Но насколько это имеет практическую ценность под Linux? Что касается "развесистой архитектуры", то подход RP2040 с PIO, позволяющий реализовать почти любое периферийное устройство, которое есть или которого нет в STM32, мне кажется более логичным.
Ардуино - это всё же больше идеология и IDE. И это покрывает почти все массовые МК и их китайские платы. Если же говорить про AVR, то CH32V003 выглядит вполне достойной ему альтернативой. Ну или RP2040, если хочется намного большего, вплоть до HDMI(DVI), пусть и с VGA разрешением.
В статье же речь о конкуренции с одноплатниками и Linux, для которых идеология Ардуино подходит плохо.
Спасибо за уточнение, но это другая ценовая категория, чем CH32V003. Уже на уровне CH32V203 или RP2040.
Даже не рассматривая обоснованность выбора Python для микросервисов, игнорируя Go, Java, C# или даже Rust или C/C++, проблема GIL, в принципе, решаема. Нерешаема проблема динамической типизации. Но это отдельный разговор.
Бывает, несмотря на то, что есть субъективное восприятие. Недавно посчитал, что за этот год мне пришлось использовать больше десятка языков. И несмотря на то, что не все они мне по душе, ничего от меня не отвалилось. Не будете же Вы писать новый Sink для Confluent не на Java, расширение для PostgreSQL не на C, CLR функцию для MS SQL не на C# и т.п.?
Почитайте всё же хотя бы Брукса
Тема нежурналируемых таблиц почти не раскрыта. А ведь использование их вместо временных таблиц может давать заметные преимущества: параллельные планы запросов, включая конструируемые вручную через dblink, и снижение нагрузки на information schema
Техзадание не имеет никакого отношения к управлению разработкой. Это лишь документ. Вы хотя бы вспомните про кризис программного обеспечения, возникший в 60-х годах и про то, как он решался Дейкстрой и Бруксом. А то складывается ощущение, что Вы вообще не представляете, чем программа отличается от программного продукта, программного комплекса и, наконец, системного программного продукта. И почему разработка последнего десятикратно сложнее, чем первого.
Зачем ворошить 50-е годы прошлого века, если уже в начале 60-х началась "смоляная яма" в разработке, принявшая катастрофические масштабы в середине 60-х?
Какая связь между техзаданием и управлением задачами? Стикеры, как я указал, появились задолго до канбана. В канбане, появившемся в конце 50-х годов прошлого века, они стали цветными. А диаграммы Ганта рисовали на доске мелом ещё в самом начале XX века.
Я уже молчу о том, что даже в конце 80-х управлять разработкой без бумажного ежедневника было мало реально. И да, цветные фломастеры или маркеры при этом широко применялись
Стикеры были бумажными. Цветными они стали только в самом конце 50-х с внедрением канбан. Вы предлагаете вернуться к еще не цветным биркам, которые использовались до конца 50-х годов прошлого века?
Как раз "трекать таски, вести историю разработки, аналитику, документацию" можно без проблем и в Redmine. А вот для менеджеров его может потребоваться допиливать, ставить или покупать нужные этим менеджерам расширения.
Да, конечно. Мобила любит не то вставить. А когда заметил, редактировать уже дали.
Вам не кажется, что сравнивать ARM Cortex-A53 с Cortex-M0+ выглядит несколько странным? Это совершенно разные весовые и ценовые категории для решения совершенно разных задач.
Для RP2040 тоже не нужен программатор. Более того, прошивка туда копируется, как на флешку (UF2), что ещё больше снижает порог входа. А платы на RP2040 мало отличаются по цене от Arduino, предоставляя на порядок-другой больше возможностей.
В сравнении с ATMega328? Можете аргументировать?
Ну так и CH32V003, и AVR умеют работать с USB, пусть и программно. Другое дело, что в CH32V003 BootLoader выделен внутри, а в Arduino проблема работы с USB решалась дополнительным корпусом: либо вторым AVR, либо FT232RL.
Это уже другая ценовая категория, чем CH32V003, в которой RP2040 выглядит намного предпочтительней STM32F.
Во-первых, не утрируйте, так как абсолютный максимум VCC у ATMega328 6В, а Safe Operating Area для тактовой частоты 16МГц 3.8-5.5В, что заметно хуже, чем у CH32V003, позволяющего питание 2.8-5.5В на максимальной тактовой частоте.
Во-вторых, защита от дурака определяется экспериментально и может сильно различаться от партии к партии. Но зато мешает выявлению дурака, которому наличие этой защиты потребовалось. Это я к 100мА инжектирования в пин.
В-третьих, для поддержки USB AVR требовал или второго AVR, или FT232RL, тогда как CH32V003 сам с USB справляется.
А зачем тогда Вы это мне написали, если, по сути, именно это я и написал?
Да никуда она не денется эта архаика. MCS51 до сих пор встречаю в современных разработках. К слову, тот же CH32V003 замечательно на 5В работает.
STM заметно сдает в конкуренции с CH32V203-217 и RP2040/RP2050
Вообще-то, кроме выпуска одноплатника, так же была заявлена реализация её поддержки в Arduino IDE. В том числе и с поддержкой low-code. Но насколько это имеет практическую ценность под Linux? Что касается "развесистой архитектуры", то подход RP2040 с PIO, позволяющий реализовать почти любое периферийное устройство, которое есть или которого нет в STM32, мне кажется более логичным.
USB High Speed и FT2232H позволяют ногодрыг до 30МГц, так что, если 5МГц мало - есть решение, которое широко используется на ПК.
Ардуино - это всё же больше идеология и IDE. И это покрывает почти все массовые МК и их китайские платы. Если же говорить про AVR, то CH32V003 выглядит вполне достойной ему альтернативой. Ну или RP2040, если хочется намного большего, вплоть до HDMI(DVI), пусть и с VGA разрешением.
В статье же речь о конкуренции с одноплатниками и Linux, для которых идеология Ардуино подходит плохо.