Забавные новости 0й-Ti :)

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

 

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

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

 

Еще раз напишу - я не против ЯВУ и новых ЯП, я и сам на том же вб6 часто что-то пишу. Я просто высказал свое мнение насчет использования таких вот штук в серийном производстве.

 

Да не, это не к тебе была претензия, про производство ты всё правильно сказал

 

Да, я видел, но мне не очень нравится, что там слишком много чего наворотили. Мне куда больше импонируют проекты типа BerryScript, Umka, Janet накрайняк, где все просто и понятно. Вообще, ко всей экосистеме ДжаваСкриптовой очень негативно отношусь. Я уже говорил, что современной веб-макаке было слишком просто кодить без утечек памяти и юз афтер фри, что ей пришлось себе других проблем придумать, чтобы страдать, как старые спецы завещали))

 

Мне лично трудно понять зачем на микроконтроллерах скрипты. Это же не zx spectrum где бейсик был локомотивом поставки в школы.
Неудобро строки на Си складывать - юзай плюсплюсы.

 

Это просто удобно, когда поменять программку можешь в любом блокноте без пересборки и перезаливки на контроллер.
Плюс, многие движки предоставляют REPL - такая консолька, в которую можешь построчно вводить и сразу исполнять скриптовые команды (как баш, только питон).
Юзают во всяких бордах для прототипирования.

 

Плюс - это hot-reload, когда ты можешь менять код вообще всего (кроме вм) без перезагрузки приложения или системы. Какие-нибудь Ерлангисты заявят, что этот плюс жирнее любой производительности. Это можно и с нативным кодом делать, но со скриптами это куда проще, в частности из-за наличия ненавистного для всех реалтаймовых спецов сборщика мусора.

 

Ты прям ОмЭрЫку открыл у того же ди самый кич - это совместимость с сишкой ЧУТЬ ЛИ не стопудовая..

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

--- Сообщение объединено, 5 дек 2023 ---

для всех страждущих пихать скрипты в лоулевел - определение реалтайма..

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

--- Сообщение объединено, 5 дек 2023 ---

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

 

Да что такое этот ваш реалтайм…

Есличо, линукс пишут на си не потому что «реалтайм», а потому что он уже написан на си.
Как бы ты ни хотел, чрезвычайно сложно внедрить в устоявшуюся экосистему совершенно иной язык с другой сборкой, с другими правилами, с другим всем.
Поэтому и раст никак не взлетает: биндинги устаревают быстрее, чем их успевают писать (а я напоминаю, что в линуксе нет стабильного API и ABI: в любом обновлении могут выбросить или поменять функцию, которой ты пользовался десять лет, просто потому что).

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

 

ну-так сишка изначально и писалась под задачу написания ядра юниха..

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

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

 

Я думал нормальная борда для разработки это когда нажал кнопку "отладить" в IDE и тебе тут же само всё залилось, запустилось и по протоколу отладки в отладчике шаг за шагов фигачишь как белый человек.

 

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

 

Даже если бы это было экономически оправдано, сделать это... просто невозможно.
Начинать писать с нуля - тем более: пока ты дойдёшь хотя бы до уровня Win 95, существующие операционки убегут ещё на двадцать лет вперёд.
Весь айтишный мир стал заложником технологий, созданных в семидесятых. Это и вся экосистема си с десятком одинаково ужасных систем сборок, и x86, где легаси больше, чем не-легаси, и весь Linux с glibc-адом и крайне неудачными архитектурными решениями как в ядре, так и в юзермоде, которые тоже создавались ещё тогда, когда ни у кого ещё не было чёткого понимания, что работает хорошо, а что через полвека будет доставлять страдания. Сделали хоть как-то, и оно хоть как-то работает до сих пор.
И ты с этим уже ничего не сделаешь ни за какие деньги.

 

в линуксе eBPF есть, так что управление ядром это уже не только Си и Асм

 

https://blog.brixit.nl/comparing-hare/ - вот оно, наконец-то хоть кто-то сподобился сделать честное сравнение языков программирования, несите добрую весть в массы!

--- Сообщение объединено, 5 дек 2023 ---

 

Неоспоримый факт.
Взять только даже strcpy - сделана из рук вон плохо: https://gamedev.ru/flame/forum/?id=234823
Одна маленькая деталь и могла бы быть нормальная функция с нормальным поведением, но Керниган и Ричи в своё время прошляпили очевидное.
И это будущие поколения теперь разберутся какой углеродный след породила неверно спроектированная strcpy и нанесла ущерб всей планете...

 

aa_dav, доставил коммент, экономия 1 байта:

 

Ну она сделана по стандартам 70ых, времена были такие, никто не знал, как делать правильно, до того, как сделали Аду, но это уже был конец 70ых - начало 80ых. Идея о том, что строки нужно заканчивать нулем, вместо того, чтобы иметь 4 байта длины - это полный бред, и много алгоритмов (те же слайсы) можно было бы делать куда быстрее. Но "история сослагательных наклонений не терпит", из-за чего многие, как в статье, приходят к очевидному выводу:

Очевидному практически всем, кроме нескольких элитных спецов с васма.

 

ASCIZ в принципе был неплохой штукой на 8-битках и тех ранних около-16-битках где си возник потому что типичные структуры данных там выглядели типа вот так:

Код (Text):

1.  
2. struct student
3. {
4.   int age;
5.   char name[30];
6. }
7.  

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