Arduino.ru

Вот если бы бут сам лез по грпсу и менял в проце прошивку....

Медианые зарплаты, что для питона, что для С, что для C++ равны. Самые дешевые джуниоры этих трех направлений -- это Сишники. Джуны питонистов стоят на 10к дороже. Джуны С++ дороже еще на 5к. Сеньоры питона и плюсов стоят в среднем одинаково, сишники-просто дешевле на 20к. Максимальный ценник на питонистов выше, спрос больше в разы. Ну а рассказы в пейсбуке -- это просто рассказы.

Может быть сервису вакансий видно и так .. они больше мониторят вакансии - то бишь ПОЖЕЛАНИЯ работодателей. Цитату РАБОТОДАТЕЛЯ из мессенджера - привел выше. К непосредственным результатам работодателей у меня доверия несколько выше чем к их "ожидалкам".

по-просту: ваш график - это хотелка работодателя, запущенная через КА. Практика - это цитата из мессенджера. В общем-то коррелирует, ибо "берут питонщиков".. :)

Ну и ещё к статье в целом: слишком широкий охват (моя цитата за embed исключительно), охват "анкет" (кто там и что и во сколько раз приукрасил .. аналитики в статье нет на эту тему). В ряде "крупных" фирм работают близко знакомые коллеги .. у них несколько иные отзывы о "зарплатах", но не буду писать какие - не пиарю хоть набело хоть начерно.

Высокая популярность питона связана с тем, что пишущий на нем программист решает задачи проще и быстрее, причем в разы и без ущерба качеству, чем если он использует традиционные ЯП. Другими словами, производительность труда на питоне выше. Вы можете расскзывать здесь любые басни, но я категорически не могу представить работодателя, который при прочих равных отдаст предпочтение работнику с меньшей производетельностью труда, а его, выполняющего три нормы коллегу, выставит за дверь.

Сорри, я не вступаю в диспут... здоровье дороже ;).

Я понимаю, что "кто старое помянет.." и все эти вещи, НО!

Ванс апон а тайм... во времена "Великого Срача 4096 vs 4095", когда я написал тест на Питоне, ты как-то не столь позитивно реагировал... прям "двойные стандарты" приходится подозревать! ;) ;) ;) Ужас!

То, как я отреагировал, как-то влияет на свойства языка? На рыночную стоимость прогаммистов? О чем эта песня?

...и штоп никто не догада-а-ался, ...ну и так далее.

Просто стеб. Не принимай к сердцу.

О производительности труда программиста. Есть такие задачки под наванием квайны. Это программы, которые при выполнении печатают собственный исходный текст. Для перла квайн может быть таким:

open 0; print <0>;

для питона таким:

print(open(__file__).read())

для си таким:

char*s="char*s=%c%s%c;main(){printf(s,34,s,34);}";main(){printf(s,34,s,34);}

Это довольно грубое сравнение, но затраты усилий на решение одной и той же задачи с использованием разных ЯП примерно соответствуют объему текста решений, приведенных выше. :)

А теперь, нарисуйте точно также решение задачи считывания показаний Узв. датчика HCSR-04 по прерыванию "захват таймера", а не с использованием pulseIn() .. для сравнения т.с. :)

open 0; print <0>;

print(open(__file__).read())

char*s="char*s=%c%s%c;main(){printf(s,34,s,34);}";main(){printf(s,34,s,34);}

Зачем портить красивейшую из теорем теории алгоритмов нечестными примерами?

Квайн по-определению не может пользоваться никаким вводом, даже скрытым, и два твоих первых примера - это классика "читинг квайн".

Вот истиный квайн на питоне:

s = 's = %r\nprint(s%%s)'
print(s%s)

И нихера не понял, к чему это? Про квайны целая тема была тут, Ее ЕвгенийП начинал, если я не путаю. И на ардуинке можно, я сам как-то делал ...О! Нашел!

#include <stdio.h>
char program[250] = "#include <stdio.h>%cchar program[250] = %c%s%c;%cvoid setup()%c{%cchar ss[256];%cSerial.begin(9600);%csprintf(ss,program, 10, 34, program, 34, 10, 10, 10, 10, 10, 10, 10, 10, 10);%cSerial.prinln(ss);%c}%cvoid loop() {}%c";
void setup()
{
char ss[256];  
Serial.begin(9600);
sprintf(ss,program, 10, 34, program, 34, 10, 10, 10, 10, 10, 10, 10, 10, 10);
Serial.println(ss);
}
void loop() {}

С хорошим знанием питона, шансы обеспечить себе неплохой достаток немного выше, чем с набором умений вида "считывания показаний Узв. датчика HCSR-04 по прерыванию "захват таймера" на атмеге. Речь здесь в последнее время шла об этом, если вы забыли.

Портить? С ваших слов тогда выходит, что это какая-то некудышная "теорема", раз ее можно испортить столь бесхитростным способом.

Это радикально меняет суть моих слов? Даже на пол-бита не меняет.

В этом и проблема.

1. Я уже давно не понимаю, кому и что ты тут доказываешь...

2. У тебя проблема? Давай помогу решить! ;) ;) ;) Я добрый, пока трезвый. (шутка, все равно не добрый, ...да и не трезвый)

Опять же - не бери к сердцу! Я просто увидел слово "квайн" и "нечестный" пример, у меня рефлекс сработал. ;)

Понял, отстал. Слив защитан, Ваше мнение совершенно ясно, так его и запишем: ни питон ни перл не предназначены для программирования микроконтроллеров. Тот кто их пользует в МК - тупой болван. :)

Заскриню, пожалуй. Чтобы через пару лет, когда архаровец таки слезет с пальмы и начнёт изучать что-то новое, напомнить ему, кто из них двоих (он и его отражение в зеркале) - тупой болван :)

Тогда, наверное, стоит уже прекратить попытки.

Да, запишите там чего нибудь. Займите себя хотябы ненадолго.

Я ведь к чему? К тому, что с тобой никто не спорит, кроме Архата. Все, вроде как, согласны, ...возможно с оговорками.

А с Архатом спор заведомо нерезультативен, как и с тобой. В общем "Вот и встретились два одиночества, разожгли у дороги костер..." ;)

Можно запасаться попкорном.

Никто не спорит со мной. Один пингвин только мается. Все суетиться, с какого бы боку удобнее было дерьмецом мазнуть. То, неизвестно зачем, про питон двухлетней давности вспомнит, то посягательство на теорему приплетет.

Как тебя расколбасило то! Может сто грамм? А лучше сто пятьдесят! И орешки, воо-он те. ОК?

Закусывай, пингвин, а то совсем развезет.

Давай и твой высер заскриню, дабы когда ты поймешь, что изучение нового никак не связано с применением изученного там, где оно не требуется - ты мог ощутить наяву кто и где и какой болван, не способный отличать одну истину от другой, а также нормально воспринимать прочитанное .. чем там вас все-таки кормят?!?

Тут нет "спора". Есть мое утверждение, подтвержденное демонстрацией гумна автором А5021 и им же подтвержденная невозможность программирования систем управления на непригодных, но толкаемых в МК языках..

Кстати, о невозможности решать задачи управления (на прерываниях) на Питон хорошо изложено тут: https://docs.python.org/3.6/library/signal.html#execution-of-python-signal-handlers

Это документация, тем болванам, кто не читал, но думает что он "спорит". :)

Эка козлёнка зацепило-то :) Так и дрищет :)

Изложено хорошо. Только к "задачам управления (на прерываниях)" это никаким боком не относится и не может относиться в принципе. То, что вас гугл завел в эту сторону показывает, что в обсуждаемом вопросе вы не разбираетесь. Ловите уже лучше прерывания по событию захвата таймера на атмеге. Там вы хоть что-то осмысленное будете делать. Может быть.

Не смеши! Архат и осмысленное - это такой же оксюморон, как Logic и логичное.

Ещё один не читатель. Там наглядно показано ПОЧЕМУ питон не будет работать с прерыванием от захвата таймера В ЧАСТНОСТИ. Потому что в общем - прерывание может прийти в середине блока интерпретации команды и .. прервать его низзя.

Это и есть ГЛАВНАЯ причина, почему Вы - НИКОГДА не напишете предложенную задачу на питоне БЕЗ Си-шного обработчика прерывания ("библиотечной функции"), ЧТД: навязываем гумно, дабы поменьше лезло в С/С++...

Забавно как у дебилов внезапно кончились аргументы, а остались только оскорбления, на которые мне глубоко пофиг. Приятно.

Я тебе больше скажу! Любая многозадачная ОС общего назначения не позволит написать, как ты там выразился? - "обработчик прерываний захвата таймера", даже на С, не говоря уже о С++! ;););). Для этого существуют специализированные ОС, т.н. "Реального времени".  В "жестком" варианте планировщик в них имеет наименьший приоритет, и обращения ядра к контроллеру прерываний идут через специальный фильтр, чтобы ядро, даже в теории, не могло запретить прерывания. Атомарность оераций обеспечивает микроядро, уровнем ниже основного ядра ОС. И конфликт атомарности и "жеского реал-тайма" - один из острых моментов теории ОС реального времени... тут разные разработчики придумывают разные подходы, а железячники просто ледают процессоры все быстрее и быстрее, чтобы постановка задачи стала неактуальной.

Заметь, что за  "коучинг" по теории ОС я даже не прошу денег! А ведь мог бы! ;)

Если сказанное выше отложилось в подкорке, то вот тебе тема для анализа:

Когда-то, в далекой юности я делал 3Д визуализацию для томографа, которая внятно и информативно работала на 386DX40 с сопроцессором. И пересчет картинки в новом ракурсе с новым сечением и подстветкой плотностей происходил на глазаах - секунд 30-40 у меня по экрану полосочка пробегала и сразу показывала изображение. Конечно, у меня при пересчете все блокировалось, половина кода - на асм вставках, режим работы. Куча эвристик, сглаживающие сплайны я считал решая линейные уравнения даже не Гауссом. И уж точно не  матрицами.

А теперь - все это нахуй никому не уперлось, потому, что системы стали НАСТОЛЬКО быстрыми, что на уровне примитивов графических библиотек делают такие расчеты по отжатию кнопки.

Наводит ли эта история тебя на мысль, что реал-тайм реализации интерпретируемых языков - это вопрос нескольких лет?

-----

Еще аналогия: коробка автомат - самы сложный механический агрегат в автомобиле. Еще немного развития гибридов и мы увидим чисто электрическую трансмиссию, конструктивно сильно проще. Куда пойдут гениальные механики? Ясно, что в хобби, куда и ушли мастера разработки часовых механизмов, после появления копеечной электроники. Конечно, для ебанутых миллиардеров есть наручные часы с механокой, автозаводом и черте-чем, но массовости давно нет, а именно массовость отличает хобби и профессию.

как-то так, имхо.

Мне, конечно, сложно судить, что вы видите по ссылке и что из того понимаете, но говорится там главным образом об обработчиках сигналов. Сигналами в данном контексте называются асинхронные уведомления, которые процессы могут получать и посылать. Чисто софтовая юниксячья мулька, к железу напрямую не относящаяся.

Оч. хорошо. Значит, постоит-подождет этот сигнал. Нам-то какая с того печаль?

У вас план по бреду ? Выполнять нужно любой ценой?

Прочтите внимательно и устыдитесь своего безграмотного красноречия.

Как раз не так давно на котах была дискуссия, что микропитон не годится для реалтайма. Как пример, один из тамошних архатов предлагал рассмотреть расчет быстрых преобразований Фурье, на которые мега тратит 7.5мс для 128 бинов и каковая скорость ни для каких интерпретаторов не доступна, якобы, в принципе. Несчастного быстро натыкали носом в микропитоновскую библиотеку для STM32, которая считает 256 бинов за 2.5мс, плюс еще и точность значительно выше. Так что эти самыме "несколько лет" уже потихоньку напирают.

Блин. Поначалу решил что ты это местным чудикам пишешь, но потом решил что мне .. н-да.

Извини, кэп "очевидность", но в своем студенчестве писал эту самую "микроОС", как раз после своего же и на нем жеж, Асма на Д3-28 .. 1985-1986гг., последний курс. Ассемблер - это была так, поделка инструмента для написания диплома ("разработка программы расчета оптических систем с использованием терминала на Д3-28"), на преддипломе. А вот за микроОС взялся уже после диплома.. когда собрал 8шт этих чудо-машинок в вычислительный кластер на базе одних только проводов (как нам рассказывали преподы, это "бортовой вычислитель какого-то МИГ в их юности, 63-67гг и они умели уже тогда связываться в кластер на лету по радиоканалу" - стало интересно, вот и сваял). Вот тогда и возникла идейка накатать "ос". :)

Ну да ладно, давно это было .. ни к чему уже.

В таком разе, может ты сам и разъяснишь в чем ошибка предоставленной ссылки от А5021? Или сложно? :)

Ну и на твой вопрос: мой ответ - НЕТ, категорически. Сам понимаешь "почему" или как? Подсказка: "реал-тайм" с дискретностью 3мсек - вполне обеспечивает и малинка под Линукс на .. 160-мгц камне. Какой потребуется камень для обеспечения наносекундного реал-тайм в интерпретаторе? :)

То бишь .. что такое этот "реал-тайм"? Реакция в РЕАЛЬНОМ времени. Не, не твоем "реальном" или "реальном времени датчика", а камня.

Может он реагировать за 5 тактов на прерывание - вот это и есть реал-тайм.

Заставить его реагировать в секундных или минутных диавпазонах - не проблема даже сейчас. Только почему-то "реал-таймом" такое не называют. Любой интерпретатор - это 10% от "реал-тайма" в самом лучшем случае .. прекомпиляция, байт-код, ограничение функциональности и т.д. .. типовой интерпретатор "верхнего уровня" - это 0.007% от реал-тайм камня. Ну, может дойдет до 1% .. когда-нибудь.

Как? Неужели даже на чистом-чистом, промытым Фери и необычными стиральными порошками Си тоже нельзя? Ужость! Куда катится мир? А Черноморск всё-таки должен быть вольным городом!

Он пгосто не пгобовал отмывать Си с помощью Фери.. :)

А что, в середине исполнения двухтактной железной команды не может? А если может,
так значит я никогда не напишу предложенную задачу даже на Си ассемблере! Блин, вот облом, а я только собрался её написать :((( Как жить-то????

Как DetSemen.

Вот тут какие-то перцы замеряли время реакции на прерывание для PDP-11. Последняя, будучи весьма продвинутым аппаратом для своего времени, комплектовалась в том числе и операционной системой реального времени под названием RSX-11. Какое-то у них медленное течение реального времени наблюдается. Гораздо медленнее, чем тут архат рассказывает. Сотни микросекунд:

Да, дед - мудрый человек. У него нам учиться и учиться.

Вот код с обработчиком прерывания таймера, пусть и не захвата, а переполнения, но это уже не имеет никакого значения:

import machine
 
interruptCounter = 0
totalInterruptsCounter = 0
 
timer = machine.Timer(0)  
 
def handleInterrupt(timer):
  global interruptCounter
  interruptCounter = interruptCounter+1
 
timer.init(period=1000, mode=machine.Timer.PERIODIC, callback=handleInterrupt)
 
while True:
  if interruptCounter>0:
    state = machine.disable_irq()
    interruptCounter = interruptCounter-1
    machine.enable_irq(state)
 
    totalInterruptsCounter = totalInterruptsCounter+1
    print("Interrupt has occurred: " + str(totalInterruptsCounter))

И насрать на "середину блока интерпретации команды" и "сишного обработчика прерывания". Микропитон для ESP32.

Ну и на закуску:

Shall we use MicroPython in our real-time projects?

MicroPython is mature, elegant, and offers great productivity advantages over other embedded software environments. MicroPython is quite capable of running real-time code as long as we put some care around its limitations; after all we have to remember that real-time is not about being fast but about being deterministic. Providing the memory/speed resources are sufficient and we can meet our real-time deadlines, it is a great platform which we intend to use more and more in the future.

Архат, что будем делать с твоими экскрементами, которыми ты уже пол-форума здесь унавозил?

А5021, Где код того самого "mashine"? Что, опять Си? Сказано же було "на питоне", а не "с использованием С-вставок".. что будем делать с твоими и прочими экскрементами?

P.S. Лови и наслаждайся Си-шной реализацией модуля mashine https://github.com/micropython/micropython/tree/master/extmod, неуч.

Сам перевести не в состоянии что ли? "..after all we have to remember that real-time is not about being fast.." - такой он вот "не реалтаймовый этот "реал-тайм", аж перевести проблема..

Ну и с PDP-11 ты явно не якшался, ибо не знаешь, что:

"Процедура прерывания семейства моделей PDP-11, заключается в том, что вектор прерывания, кроме адреса программы обработки прерывания, содержит и начальное состояние программы обработки прерывания, и программа обработки прерывания начинает работу в своем контексте, а не в контексте прерываемой программы." На это - тоже время потребно. Так шта, вполне реал-тайм. Как умел так и делал..

Так что .. ну вот такой реал-тайм камня у неё и был. Но, ты же продолжаешь плодить экскременты..

ЕвгенийП, писал: "А что, в середине исполнения двухтактной железной команды не может? А если может,
так значит я никогда не напишу предложенную задачу даже на Си ассемблере!"

Реал-тайм двухтактного камня будет иметь 2 такта (гораздо больше на самом деле) реакции на прерывание. Это и есть его "реал-тайм". В этом ограничении и напишите на Си .. а вот на интерпретаторе напишите на 100х 1000х раз медленней, что уже сложно назвать "реал-тайм".. там было про это, но прикольно же экскременты на форум кидать, правда жеж?

P.S. Всё, что Вы тут так тщательно пропагандуете, написано раньше чем Вы на свет появились .. Вы просто ПЫТАЕТЕСЬ воспроизвести на очередном слое гумна то, что когда-то нормально работало напрямую с железом, восторгаясь очередным высером, пардон "шедевром"... агрессивное копрокодерство и ничего больше. За что Вам только зряплаты платят, неучи?!?

P.P.S. А впрочем .. когда-то, по студенчеству, сам такой был .. пройдет может быть. А впрочем2, пользуйте "модное гумно", осваивайте программирование микроконтроллеров на JS, Python и прочих интерпретаторах .. это хороший водораздел для отсеивания вменяемых от идиотов. Профессия в этом уже сильно нуждается. :)

Ты, как всегда, накидываешь навоз на вентилятор абсолютно не думая (видимо, нечем), что бессмысленно говорить о применимости тех или иных технологий не определяя конкретный круг задач. Ты же не потрудился этого сделать, а срёшся из-за коня в вакууме!

А если, не дай Бог, не 2-х, а 4-х тактная команда? Где грань применимости? Интерпретаторы - низзя. Хорошо. А 2-тактные можно. Ладно. А 4-тактные? Можно - не? Где грань-то?

Вот ты сказал про задачу с прерываниями. Так определи требования к скорости реакции, блин! Если 1 нс, то выбрось атмел вообще вместе со всеми ассемблерами! Е если 1 мс, то хоть Питон, хоть Бэйсик - всё будет работать.

Неужели мозгов даже на это не хватает? Ты всегда был безграмотным, но не настолько же - всему же должен быть предел.

Как раз всё наоборот. Я Вам определил круги применимости "реал-таймов", но Вы же не читатели, а срули (главное высрать, а что - не важно, хоть оскорбления)..

Выше, там есть все про ваш пост .. перечитывайте.

Хрена ты чё определил. Ты всё блеешь про какой-то "реал-тайм камня", а кому это не пох (ну, кроме тебя)? Нормальные люди определяют задачу. Для какой-то задачи этот "камень" вообще можно выбросить, а для какой-то хоть на бейсике писать. Тебе - дураку про это уже третий день талдычат. Но ты уже упёрся, теперь будешь сраться до последнего - пока штаны не переполнятся. Удачи! Только вот, зря ты так. Здесь ведь ещё не все знали, что ты безграмотный, упёртый болван, а ты это всем напоказ выставляешь. Твой союзник вон быстро всё понял и слинял втихаря, чтобы не позориться, а у тебя и на это ума не хватает.

Не только. Реал тайм камня - это тот реал, который камень (проц, SOC и т.д.) способен обеспечить т.с. "максимально". И есть его "круг задач", в которых фигуряет "реал тайм датчика" - то время реакции которое обеспевивает работоспособность в конце всей разработки.

Так вот подбор камня под задачу и есть совмещение второго с первым. Конечно можно (и про это писал выше) взять микроскоп с наносекундым "реал тайм" и запилить на нем решение "секундной" задачи, использовав "интерпретатор" как прокладку, сжирающую излишек. Но, это как раз не есть решение задачи выбора инструмента (камня), а просто безграмотное применение микроскопа для забивания гвоздей.

И эта безграмотность ни разу не оправдывается "низкой стоимостью микроскопа" и тем более "низким порогом вхождения в интерпретатор", ибо последний зачастую ВЫШЕ чем порог вхождения в тот же "С" и даже С++, хотя бы в силу большей мощности интерпретатора: он позволяет делать то, что компилируемый язык сделать не в состоянии.

То, что теперь понимается под "низким порогом вхождения" на самом деле тупо - профанация для ленивых обезьянок и способ отделить зерна от плевел.

Вообще-то, этот базар не так уж и интересен. Задача оптимизации кода уже решена и практически "давно". Задача автоматической генерации кода по тем же UML диаграммам ТЗ тоже продвинута и не "вчера" до нормального уровня. Машинное обучение уже взялось за решение задачи построения ТЗ по описанию задачи .. так что, профессия "программист" (недокодер) лет через 5-10 станет атавизмом на все 146%.

Так вот разговор надо начинать именно с задачи, а не с инструментов и говорить, что данный инструмент адекватен/неадекватен задаче. Ты же развёл срач о коне в вакууме, и доказываешь неадекватность инструмента как такового (неадекватность коню в вакууме). Как всегда, впрочем. Дошло?

Да нет конечно же! Я вообще-то начал с простого замечания, что в Samsung ни разу не знают, что питон мало применим для embeded решений .. ещё на 1 стр. А срач тут как раз развели такие как ты. :)

И понеслась дешевая демагогия. Куда-то исчезло безаппеляционное

как только выяснилось, что на голом питоне можно без всяких проблем написать обработчик. Теперь с больной головы перекладывается, что, оказывается это mashine написан на Си. И какое, собственно, это имеет отношение к предыдущему бреду в квоте выше? Правильно, никакого. Смысл только один -- соскочить с этого залета, соскочить любой ценой. Любой бред пойдет.

Кто-нибудь может перевести сей незамутненный поток на человеческий язык?

Думаю, что тут что-то связанное с теорией относительности - для каждого камня время идет по-своему ))

Камни же - они подчиняются законам физики. В некоторых даже черные дыры обнаруживались посетителями форума - данные тудыть попадают, а взад уже никак.