LINUX.ORG.RU
Ответ на: комментарий от Stanson

А найди мне пистон для PIC18F1320 например. :) Ну нормальный питон, со всеми этими numpy и всё такое

После того, как ты найдешь мне для него нормальный C99 с gsl и всем таким.

tailgunner ★★★★★
()
Ответ на: комментарий от Stanson

Потому что они могут делать то, что делают веб-макаки, а веб-макаки не могут делать то, что делают эмбедщики.

Ммм... Хорошо, что в твоем понимании делают веб-макаки, и что делают embedded программисты? Ты можешь привести примеры задач?

В общем, да, ничего особенного. Только всякое веб-макакчество и жабодрочерство на несколько поряков тривиальнее.

Ты можешь привести примеры?

Это только в рашке может быть. А так, хороший эмбедщик получает в разы, если не на порядок больше какого-нибудь жабодрочера. Особенно в automotive и airspace.

Что такое «хороший эмбэдщик» и уверен ли ты, что хороший «жабодрочер» получает меньше?

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

простенький сайт отъедает около 8 мегабайт памяти и 0.01% проца

под напором миллионов юзеров, я так понимаю?

vostrik ★★★☆
()
Ответ на: комментарий от Iron_Bug

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

Во многом переход от ASM к C произошел по причине того, что код на C более безопасен и меньше подвержен ошибкам. Правда, не все с этим тогда соглашались и приводили похожие аргументы. Есть мнение, что банально не осилили.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от true_admin

Но туда ползет самый ублюдочный язык со времен VB.

js шоле

Да.

Я бы променял питон на современный js (с ламбдами, генераторами, статической типизацией через typescript, JIT, etc)

фейспалм

Генераторы есть в Python, его лямбды покрывают 80% юзкейсов. Про статическую типизацию через Typescript смешно получилось, а на JIT я просто валялся. Почему бы тебе было просто не сказать «да там же будет WebAssembly, используй что хочешь»?

tailgunner ★★★★★
()
Ответ на: комментарий от kirk_johnson

Во многом переход от ASM к C произошел по причине того, что код на C более безопасен и меньше подвержен ошибкам

А я думал что дело в скорости разработки, большей переносимости и относительной простоты модификации.

ramon13666 ★★★
()
Ответ на: комментарий от Iron_Bug

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

Расскажи это перцам из CCP.

kirk_johnson ★☆
()
Ответ на: комментарий от ramon13666

А я думал что дело в скорости разработки, большей переносимости и относительной простоты модификации.

скорости разработки и простоты модификации

Ну а я о чем?

kirk_johnson ★☆
()
Ответ на: комментарий от Stanson

Чей опыт?

Мой опыт собеседования чуваков, имеющих обширный опыт в embedded, на должность программиста. Зачастую всё очень печально, и чуваки не осиливают банальные вещи вроде простейшей рекурсии.

А эмбеддед относится к тем самым прочим областям программирования очень просто - всё то же самое, только надо запихнуть это в кристалл размером 5х5мм и чтоб не отсвечивало.

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

Китайцы практически ничего не сочиняют в эмбеддед. Они насилуют всяческие SDK которые им написали разработчики железа.

Эти разработчики железа, в основном, тоже китайцы.

Вот и получается на выходе кромешный ад.

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

Расскажи это перцам из CCP.

Перцы из CCP по сути изобрили свой питон. У них Stackless и практически своя стандартная библиотека.

hateyoufeel ★★★★★
()
Ответ на: комментарий от holuiitipun

Не лопни от смеха - https://micropython.org

STM32F405RG microcontroller 168 MHz Cortex M4 CPU with hardware floating point 1024KiB flash ROM and 192KiB RAM

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

Просто кто-то не умеет в программирование и питон.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Расскажи это перцам из CCP.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от ns_ramesses

башу - может быть. но не перловке. перловка файло молотит - только в путь. жрёт много ресурсов - да. но довольно шустро перемалывает всякие там регекспы и своё дело делает. было дело, я перловкой обрабатывала логи базовых станций для выборки ошибок для отдела поддержки. при том, что я не профи на перловке и делала это по-быстрому, самыми простыми средствами, но это работало относительно шустро. попробуйте на пистоне регекспами пройтись по файлику хотя бы метров на сто. и почувствуйте разницу, так сказать.
быстрый поиск в гугле выдал вот это:
http://benchmarksgame.alioth.debian.org/u64q/perl.html
собсна, если добавить в эти тесты работу с I/O и многопоточность, то перл станет абсолютным чемпионом.

Iron_Bug ★★★★★
()
Ответ на: комментарий от true_admin

Ты хоть понимаешь что такое numpy? Если да то зачем просишь? Ты не запихнёшь функционал numpy в свой pic какой бы ЯП это ни был.

Щито? Зачем мне весь функционал numpy? Только то, что нужно из numpy для конкретной задачи.

Запихивал, запихиваю и буду запихивать легко. На сях, разумеется.

Stanson ★★★★★
()
Ответ на: комментарий от tailgunner

После того, как ты найдешь мне для него нормальный C99 с gsl и всем таким.

sdcc например. Нужные куски gsl собирал мне без малейших проблем.

Stanson ★★★★★
()
Ответ на: комментарий от kirk_johnson

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

эмм...я в игрушки не играю вообще. не могу сказать, крупный или нет. просто не воспринимаю это серьёзно.

есть задачи по обработке данных, сложной математике. вот там можно сравнивать.

Можно примеры «сложной математики» на C?

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

А вот мои перцы с МатМеха используют numpy и прочие клевые штуки и очень довольны.

kirk_johnson ★☆
()

Си пока никуда не денется. Еще долго останутся задачи, которые эффективнее решать на «высокоуровневом ассемблере». Например, недавно мне пришлось писать прошивку для микроконтроллера, который работает от coin cell батарейки. Максимальное среднее потребление 5мкА. При этом он должен десять раз в секунд опрашивать свой АЦП, внешние датчики по I2C и производить вычисления. Управляющий алгоритм достаточно сложный, вычислительный тоже - я очень постарался, чтобы прошивка влезла в 32к флэши.

На счет сложности, о которой тут спорят Pentium02 и vostrik: кроме микроволновок есть намного более сложные примеры ембедеда. Хороший пример реалтаймового ембедеда - управление мощными асинхронными двигателями. Да и вообще, бОльшая часть ЦОС пишется на С (или ассемблере).

С другой стороны сложность энтерпрайза. Когда-то я писал на жаве для J2EE, и представляю сложность энтерпрайза. Он конечно сложен, но сложность эта во-первых сильно зависит от предметной области, а во-вторых искуственно привнесена разработчиками фреймворков и библиотек. Чего только стоит стандартная библиотека жава. Попробуйте, например, быстро разобраться в javax.mail. Я, в свое время (году в 2003, наверное), мозг сломал, пока писал почтовый сервер. А потом посмотрите mail api какого нибудь Go или Ruby - всё просто и понятно, разобраться можно за пару дней.

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

Другое дело, как показывает практика, разработчики не спешат использовать питоны и ЖС, а продолжают писать на родном ламповом Си.

Puzan ★★★★★
()
Ответ на: комментарий от Puzan

в 32к флэши

Вот это я понимаю контроллер! А в современных STM32 память скоро мегабайтами начнут мерить. Как RAM, так и EEPROM/flash.

А уже давно выпускаются контроллеры, где код пишется на Scala и Java, а на флэшу кладется Java-байткод... Дожили.

ns_ramesses
()
Ответ на: комментарий от Stanson

А найди мне пистон для PIC18F1320 например. :) Ну нормальный питон, со всеми этими numpy и всё такое

После того, как ты найдешь мне для него нормальный C99 с gsl и всем таким.

sdcc например.

Не виляй. Речь шла о PIC18F1320, C99 и всем gsl, а не о SDCC на непонятно какой платформе и нужных тебе кусках.

tailgunner ★★★★★
()
Ответ на: комментарий от hateyoufeel

Мой опыт собеседования чуваков, имеющих обширный опыт в embedded, на должность программиста. Зачастую всё очень печально, и чуваки не осиливают банальные вещи вроде простейшей рекурсии.

Видимо это были какие-то ардуинщики нубские.

И да, рекурсия в однокристалках - это в 99% полная жопа. Ибо размер стека для сохранения обратного адреса (я уж не говорю о локальных переменных, если они тоже на стек сохраняются) очень сильно ограничен.

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

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

Эти разработчики железа, в основном, тоже китайцы.

У китайцев мозг не предназначен для разработки чего-то нового. Они под копирование заточены. Поэтому у китайцев крайне мало действительно собственных разработок.

но всем зачастую насрать, так как экономически это более чем оправданно.

Даже для бытовухи не насрать. Хотя бы потому что для бытовухи код будет намертво зашит в масочную ROM и потом уже не перешьёшь. Уже хочешь-не-хочешь, даже китайцам приходится напрягаться и рожать что-то удобоваримое. А про девайсы управляющие многотонными станками или там каким-нибудь МРТ я вообще молчу. Там стоимость ошибки может быть очень велика. Потому - никакого хипстерского жабодрочерства и питономастурбации, а только си и даже ассемблер. Очень иногда бывает lisp но это скорее исключение.

Stanson ★★★★★
()
Ответ на: комментарий от tailgunner

Не виляй. Речь шла о PIC18F1320, C99 и всем gsl, а не о SDCC на непонятно какой платформе и нужных тебе кусках.

Виляешь здесь ты. SDCC, PIC18F1320 - прекрасно всё собирается и работает. Можно и целиком gsl собрать, только нахера, если оттуда только какой-нибудь forward_deriv в железке нужен, а целиком оно тупо не влезет?

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Видимо это были какие-то ардуинщики нубские.

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

рекурсия в однокристалках - это в 99% полная жопа. Ибо размер стека для сохранения обратного адреса (я уж не говорю о локальных переменных, если они тоже на стек сохраняются) очень сильно ограничен.

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

Как и для всякого ынтерпрайзного говнища.

Ты кроме embedded, web и энтерпрайзного говнища какие-нибудь другие области вообще знаешь?

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

http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-de...

У меня, кстати, микроволновка от LG как-то раз повисла :D

У китайцев мозг не предназначен для разработки чего-то нового. Они под копирование заточены.

Ну вот, ты уже в расизм скатываешься. Нельзя так.

Даже для бытовухи не насрать. Хотя бы потому что для бытовухи код будет намертво зашит в масочную ROM и потом уже не перешьёшь. Уже хочешь-не-хочешь, даже китайцам приходится напрягаться и рожать что-то удобоваримое. А про девайсы управляющие многотонными станками или там каким-нибудь МРТ я вообще молчу. Там стоимость ошибки может быть очень велика. Потому - никакого хипстерского жабодрочерства и питономастурбации, а только си и даже ассемблер.

Ты понимаешь, что сам себе противоречишь?

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

ну, первое, что приходит на ум из часто используемого - gmp, mpfr, mpc. это без особой специфики, просто используются в компиляторе, например. я сама пару раз mpfr юзала, когда нужно было с float работать. но я системщик, я не работаю по профилю матвычислений. чистые теоретики, думаю, приведут гораздо больше примеров. кстати, до сих пор много математики написано на фортране. у студентов могу уточнить потом, что конкретно их не устраивает в пистоне. хотя для меня пистон и так уже решённый вопрос: однозначное ненужно.

Iron_Bug ★★★★★
()
Ответ на: комментарий от hateyoufeel

У меня, кстати, микроволновка от LG как-то раз повисла

Да небось там SoC был с Windows CE.

ns_ramesses
()
Ответ на: комментарий от Stanson

А найди мне пистон для PIC18F1320 например. :) Ну нормальный питон, со всеми этими numpy и всё такое, а не бесполезный обрубок в виде pyastra.

А зачем оно там?

Ты всякие большие матстаты на контроллере делаешь, что тебе нампи нужен?

holuiitipun
()
Ответ на: комментарий от Iron_Bug

ну, первое, что приходит на ум из часто используемого - gmp, mpfr, mpc. это без особой специфики, просто используются в компиляторе, например. я сама пару раз mpfr юзала, когда нужно было с float работать. но я системщик, я не работаю по профилю матвычислений. чистые теоретики, думаю, приведут гораздо больше примеров. кстати, до сих пор много математики написано на фортране. у студентов могу уточнить потом, что конкретно их не устраивает в пистоне. хотя для меня пистон и так уже решённый вопрос: однозначное ненужно.

Не читал, но осуждаю? :)

kirk_johnson ★☆
()
Ответ на: комментарий от Stanson

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

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

holuiitipun
()
Ответ на: комментарий от Stanson

Не виляй. Речь шла о PIC18F1320, C99 и всем gsl, а не о SDCC на непонятно какой платформе и нужных тебе кусках.

Виляешь здесь ты.

Ясно. Отличная тактика - ляпнуть фигню и шланговать.

SDCC, PIC18F1320 - прекрасно всё собирается и работает

Правда? http://sdcc.sourceforge.net/index.php#Support

«Work is in progress on supporting the Microchip PIC16 and PIC18 targets»

И C99 в sdcc нет.

Можно и целиком gsl собрать, только нахера,

А, так всё же не будет gsl на PIC18F1320.

если оттуда только какой-нибудь forward_deriv в железке нужен, а целиком оно тупо не влезет?

Это не помешало тебе требовать numpy.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Stanson

Если человеку нужна технология не дающая выстрелить себе в ногу - то этот человек априори дебил.

C -w конпеляешь небось?

arturpub ★★
()
Ответ на: комментарий от hateyoufeel

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

Ну и ты тоже пиши в резюме, что 10 раз на МКС летал, фигли.

Просто почему-то так получается, что люди с обширным опытом в embedded ущербны мозгом.

А не пробовали нормальную зарплату предлагать, а не нищенскую, которая только студентов заинтересует? Ну хотя бы от 200к$ в год.

Ты кроме embedded, web и энтерпрайзного говнища какие-нибудь другие области вообще знаешь?

Ты так и не понял. Embedded - это не область. Embedded включает в себя всё возможное программирование, но не как обычно, а вот в эту конкретную железку, где RAM 512 байт, а ROM 1k.

http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-de...

У меня, кстати, микроволновка от LG как-то раз повисла :D

Единичные случаи на миллиарды девайсов. Показательно, да.

Ну вот, ты уже в расизм скатываешься. Нельзя так.

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

Ты понимаешь, что сам себе противоречишь?

В чём же?

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

А не пробовали нормальную зарплату предлагать, а не нищенскую, которая только студентов заинтересует? Ну хотя бы от 200к$ в год.

Это примерно 1 миллион рублей в месяц.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Я, конечно, не писал на асме ничего сложнее «hello_led», но читал некоторые программы. И не представляю, как система типов С лучше таковой в асме (если вообще можно говорить о типах в ассемблере). Подходы к разработке различны: там где сишник сделает одну функцию с приведением типов, ассемблерщик напишет несколько подпрограмм для каждого используемого типа данных. Или я не прав?

ramon13666 ★★★
()
Ответ на: комментарий от Iron_Bug

линейный

Корутины, не? Да и треды есть, хоть и с gil.

«многопоточность» - фикция, пародия на нормальную многопоточность

А зачем пихать питон туда, где нужна параллельность?

holuiitipun
()
Ответ на: комментарий от tailgunner

Правда? http://sdcc.sourceforge.net/index.php#Support

«Work is in progress on supporting the Microchip PIC16 and PIC18 targets»

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

И C99 в sdcc нет.

И насколько то чего в SDCC нет из C99 действительно нужно?

Это не помешало тебе требовать numpy.

А что, в пистоне теперь можно как-то выдрать кусочек из numpy и не тащить его целиком на девайс, если хочется что-то оттуда использовать?

Stanson ★★★★★
()
Ответ на: комментарий от ramon13666

Я, конечно, не писал на асме ничего сложнее «hello_led», но читал некоторые программы. И не представляю, как система типов С лучше таковой в асме (если вообще можно говорить о типах в ассемблере). Подходы к разработке различны: там где сишник сделает одну функцию с приведением типов, ассемблерщик напишет несколько подпрограмм для каждого используемого типа данных. Или я не прав?

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

kirk_johnson ★☆
()
Ответ на: комментарий от Puzan

Да и вообще, бОльшая часть ЦОС пишется на С (или ассемблере).

таки есть статистика? сколько видел - там vhdl и верилог, сишники за сигаретами бегают

vostrik ★★★☆
()
Ответ на: комментарий от holuiitipun

А зачем пихать питон туда, где нужна параллельность?

Даже в этом случае в python можно просто сделать пул рабочих процессов.

kirk_johnson ★☆
()
Ответ на: комментарий от Iron_Bug

собсна, если добавить в эти тесты работу с I/O и многопоточность, то перл станет абсолютным чемпионом.

У вас там точно не умеют в питон)

holuiitipun
()
Ответ на: комментарий от Stanson

Ну и ты тоже пиши в резюме, что 10 раз на МКС летал, фигли.

Очень тупая отговорка, серьёзно. Взрослые люди обычно не врут в резюме, как бы долго они не писали под embedded.

А не пробовали нормальную зарплату предлагать, а не нищенскую, которая только студентов заинтересует? Ну хотя бы от 200к$ в год.

Ты уже получаешь $200k в год за свой embedded?

Embedded включает в себя всё возможное программирование, но не как обычно, а вот в эту конкретную железку, где RAM 512 байт, а ROM 1k.

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

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

Единичные случаи на миллиарды девайсов. Показательно, да.

Это ты про Тойоту? Не единичные, читай внимательно. И, что удивительно, выбор более высокоуровневых языков вместо C вполне может предотвратить ситуации с переполнением стэка или выходом за границы массива, от которых код на C так страдает.

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

Я не понимаю как из первого ты выводишь второе.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

Это примерно 1 миллион рублей в месяц.

Это очень средненькая такая зарплатка Embedded Software Engineer. Год назад это было всего 400 тыс. деревянных в месяц, кстати.

Stanson ★★★★★
()
Ответ на: комментарий от Stanson

Это очень средненькая такая зарплатка Embedded Software Engineer. Год назад это было всего 400 тыс. деревянных в месяц, кстати.

Да, я в курсе. Опубликуешь ссылки на вакансии?

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

А ничего, что ИТ-рынок не локален, а глобален? Это не рынок токарной и фрезерной работы. Раз глобален, то сравнивать зарплаты разработчиков соответствующей квалификации в разных странах логично в какой-то одной приведенной валюте. В USD или хоть в рупиях, но одной мерой мерить.

ns_ramesses
()
Ответ на: комментарий от Puzan

в целом, соглашусь. только вот

На всяких пистонах и жабаскриптах можно писать верхнюю часть управляющей логики, это быстрее и короче, чем на Си. А на Си писать критичные части.

это эмбеддед уже более высокого уровня.
в микроконтроллерах «верхняя часть» мало отлична от «нижней». там прерывания и вычисления. плюс математика зачастую рукотворная и время обработки важно. а с этим, опять же, к С.
а вот в более крупном эмбеддеде, на микро-компьютерах, где уже линюкс крутится, лучше юзать не пистон, а lua. для таких целей он вполне пригоден и он на порядок диетичнее в потреблении ресурсов. пример - тот же OpenWRT, в котором на luа написана морда и некоторые скрипты бэкендов. конечно, ресурсов там значительно больше, чем на мелкоконтроллерах. но всё же luа там применять гораздо удобнее.

Iron_Bug ★★★★★
()
Ответ на: комментарий от ns_ramesses

А ничего, что ИТ-рынок не локален, а глобален? Это не рынок токарной и фрезерной работы. Раз глобален, то сравнивать зарплаты разработчиков соответствующей квалификации в разных странах логично в какой-то одной приведенной валюте. В USD или хоть в рупиях, но одной мерой мерить.

Ты можешь мне ссылки на вакансии от $200k в год привести?

kirk_johnson ★☆
()
Ответ на: комментарий от ns_ramesses

А ничего, что ИТ-рынок не локален, а глобален?

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

hateyoufeel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.