Очередной хлоливар С/С++ vs Java/C# возник в месте обсуждения РТОС для мк. Я его переместил сюда.

Вброс


я когда вижу код на Perl - волосы дыбом, это не значит что Perl гавно.
а почему в языке должна быть многопоточность? Язык - это всего лишь язык. А всё остальное - это библиотеки, фрэймворки. Нужна многопоточность - подключай boost, Qt, *RTOS.... или сам суперлупом обеспечивай. Такто можно заявит: Почему сигналы-слоты не обеспечивает язык? Почему extFat не обеспечивает язык? Почему KDE не обеспечивает язык?
нету. не нормальных, не ненормальных.
какая к чёрту жава на мк? Даже эти ваши линуксы пишут на си по сей день. не на жаве, и тем более не на с#. и жава.... для неё нужна жавамашина. какую жава машину вы запехнёте в мк с 1кБ ОЗУ? Всё это удел высокоуровнего программирования, окошки, форточки... даже для ПК драйвера пишут на Си/С++. Не разу не слышал чтобы кто-то написал низкоуровневый драйвер для ПК на жаве.
А по поводу с# на мк- вообще смешно.... ибо c# не не язык программирования, а "язык программирования виндоус". Вы бы ещё спросили "А есть нормальные реализации языка 1С для мк?". ))
см вики
Это нужно в мк с 256 байтами ОЗУ (да хоть и с 64 кБ ОЗУ) запихать .NET? А также для неё поставить Windows8.... c мэтро

Дак на ура и жавой рушатся приложения только так.


А как в яве запись в регистр микросхемы? например в общем адресном пространстве 0x40001234 - адрес регситра RxDATA, а 0x40001236 - адрес регистра TxDATA. Как на Jave происходит обращение к этим регистрам?

старый не знаяит плохой. Русский ещё старее, а на дворе 2014...
ДВС - ему больше 100 лет. а на дворе 2014. Но пока человечество не придумало лучше двигатель.

juvf,
ППКС..

Много поточность и многоядерность нужна когда она нужна. Следить раз в минуту за температурой не нужен 8ядерный процессор с 256 мег памяти на джаве

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

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

как говорится без коментариев...
Всё от задачи треба...

А кто вообще сказал, что в Java многопоточность в языке? Это библиотека, если что.

А еще есть отдельный ужастик в среде исполнения Java-кода под названием "нативные методы". Это к вопросу "обращения к регистрам", например.

А вообще тема флудерастична по самое не хочу. Я бы, как модератор раздела, порекомендовал воздержаться.

Не, я не промолчу.
В связи с ростом популярности Free Pascal + Lazarus + CodeTyphoon

И мои впечатления можно в двух словах: "посидеть попрограммировать, отдохнуть от Си"

Forth (Форт)? (есть для любого МК) и GA144 (асинхронный (вкл/выкл 700МГц), 144 мультиядерный MISC контроллер с возможностью решать DSP задачи)
Вот где С,С++,Java,... (и.т.д. и.т.п.) отдыхают, как и всякие РТОС

P.S. Языковый подход в программирование основанный на составлении смысловых фраз!
(без дополнительных телодвижений по связыванию формальных и фактических параметров процедур/функций и локальным временем "хизни" "переменных",
получил из "потока" данные -> обработал -> выдал обратно в поток на обработку следующей "процедуре" и даже можно локально перехватить управление процессом трансляции/интерпритации/компиляции исходных слов самой программы подстроив синтаксис и семантику языка под текущее понимание задачи).
Вот где язык с "истинным" программерским адренолином
Аспекты эргономики языка программирования ещё не обсуждали?

Я бы прoшел мимо темы, если бы бодались пингвины с демонами, или видузятники. Можно поспорить за язык для пк. Но одсуждали работу фриртос на процессоре стм32. Какая там может быть жава или шарп? Или может есть для мк язык помимо си и сипипи?

Ух ты как идеологично.

Еще лет 10 назад когда Nokia была на пике, у нас вырос стартап сделавший бизнес именно на Java под MK. Это были ARM7 в составе Nokia12.
Приезжали ходоки из дальних деревень (нефтеперегонных терминалов, и наших и из Сургута ) и нахваливали как это мы здорово влепили Яву в свои контроллеры.
Теперь уже не то, да и Nokia сдулась. Нынче яву для МК толкает сам Oracle.

Правда выросло новое поколение которое думает, что кроме Arduino на свете ничего нет. А тот ардуиновский псевдо-си и есть самый настоящий C-и.
Народ таки оторвали от железа. Редкие энтузиасты теперь докапываются до реальных аппаратных регистров. Даже производители МК стали меньше заморачиваться с описанием железа.
Библиотеку в зубы и вперед без лишних вопросов.

Да что там, сам грешу. Ставлю всякие LUA, .NET micro frаmework, портирую исполнительные среды для визуальных редакторов типа Simulink, LabView. Тоже хочется оторваться от железа.

Скорость C# вполне приличная, не надо с Perl и Питон всякими сравнивать.
Например из задач: обработка журнала прокси-сервера (2ГБ текста, по несколько миллионов строчек). В памяти сохраняется каждая пара username + site. Т.е. на каждую считанную строчку (миллионы) идёт поиск в базе из ОЗУ (тысячи). Всё это отрабатывает за 2-5 минут и с потреблением около 20 мегабайт. Разве много?

Лично я бы не отказался от возможности программить на STM32f20x и выше на c# или perl
Я думаю, такое хорошо бы стрельнуло среди слоев населения, не имеющих программистской базы. А ля ардуинщики, Распберристы и т.д.

а есть компиляторы явы для мк? пруф?

а вы не путаете? это была именно Java под МК, или это была Java под МК+ОС+JVM?

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

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

ps диме, автору, респект!

http://www.st.com/web/en/catalog/tools/FM1...6?sc=stm32-java

Языки высокого уровня на контроллерах - вполне адекватная идея. Ява машина сидит даже в сим-картах, чего бы в STM32 не запихнуть? Я некоторое время возился с идеей запихнуть окамл на baremetal beaglebone. Очень увлекательное занятие, всем кто желает поближе познакомиться с устройством современных ОС, bios, EFI рекомендую. Ну и для прикола, есть порт окамла на PIC18: http://www.algo-prog.info/ocaml_for_pic/we...d=OCAPIC:OCAPIC
Ну и да, существуют порты java, .net для Cortex M3, правда сильно порезанные.

Ваймэ! Что случилось в этом мире, разве ассемблер для микроконтроллеров запретили уже??
Нет, ну правда, по серъезному - глупо же микроконтроллер заставлять считать double float например?
Его задача за датчиками следить (каламбур получился ) и команды на выход давать. Должность прапорщика, если не сержанта вообще. Мозгов много не надо, и язык соответствующий, зато однозначный и конкретный
Или "высоких программеров" к железу потянуло, а язык трудноват оказался?

однако http://www.rlocman.ru/news/new.html?di=146847

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

Ява на МК - глупость и не более.
Идея Явы - абстрагироватся от железа, в то время как программирование контроллеров сильно от него зависит.
С учетом многообразия и смены микроконтроллеров, основное время будет уходить в нахождении багов в
сандвиче Ява/хардвар, "почему на С работает, а на Яве нет".

ага-ага http://artemonische.narod.ru/nesbyvshiyesy...i_prognozy.html

1. Tessel is a microcontroller that runs JavaScript
   
2. Espruino is a small computer that anyone can use to control things around them. Its JavaScript interpreter gives you instant feedback so that you can experiment and develop whatever your level of experience

Ага скажите это производителям - продвигающим Java для МК и в частности Android OS запускающей Java софт (после конвертации) на Androidе

P.S. Java байт код - код стековой машины, но в сравнении с Форт концепцией обладает достаточно большой избыточностью.
Вместе с тем Imsys своей родословной обязаны стековым процессорам,
как и picoJava . И где сейчас PatriotScintific (вроде), если кто помнит. Запуск Java байт кода мохно осуществить и в рамках AVR архитектуры (примерно 12K кода и была тема лет 8 назад по запуску Java на МК на electronix)

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

2. "Можно" не значит нужно. В основном делают для "а вот я могу" или подобного.
Чем поможет Java в 12к на АВР? По моему, ничем, был бы смысл, она бы прижилась.

На мой взгляд, языком следующего поколения встраиваемых устройств вполне может стать Эрланг (Erlang - ERicsson LANGuage). Основные свойства языка: встроенная многопоточность с автоматической балансировкой нагрузки по узлам, "горячее" обновление кода без перезагрузки узла. Работу Эрланга на "Малинке" можно увидеть здесь:
Erlang embedded - episode 1
Erlang embedded - episode 2
Erlang embedded - episode 3
Erlang embedded - episode 4

Какие именно характеристики ухудшает количество ядер от Квалкомма? Одноядерный APQ8064 у меня кушает более всех. Потом обзавелся LG G2 и Galaxy 10 2014 - на 800 снэпдрагоне о 4 ядра - теперь о батарее не сильно волнуюсь.

Размер, стоимость, расход батареи.
"У меня был Х с один ядром, а стал У с 4мя и ест меньше не стреляет", так как У с одним кушал бы еще меньше, стоил дешевле и так далее со всеми остановками..
А что 8 ядер улучшают, не ясно..

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

а как в жаве уборка мусора происходит? абстрактно, допустим есть 100 байт свободной памяти. Объявляем переменную. в жаве, на сколько я понял динамически выделяется 100 байт и связывается ссылка на этот блок. потом удалили ссылку, по описанию языка, когда-нибудь уборщик мусора освободит эти 100 байт. Но когда? Вот создали переменную в 100 байт, удалили, и тутже создали новую переменную. Но уборщик мусора ещё не освободил память. Что произойдёт? Ошибка выделения памяти? Или принудительный вызов уборщика?

Жава и реалтайм - совместимые вещи? Жава гарантирует, что выполнит функцию за n тактов, и ни какой уборщик мусора не добавит m тактов?

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

Чего тут сложного? Наверняка используют reference counting. Блок остался бесхозным - и подлежит удалению при следующем обращении к манагеру памяти.

Почему как только речь заходит о Java сразу просыпается трогательное внимание к риалтайму?

А что, C-и жестко риалтаймный? Особенно его функции printf, scanf и т.д.?
Как C-и так и Java нужно приучать к риалтайму. Делать профайлинги, проектировать HAL и проч.

Жестко. printf(buff, "Hello world!"); как ни крути, в какое время не вызови - выполнется за определённое время тактов. ни тактом больше ни тактом меньше.

ps. сорри, printf не пользую, мож там из-за потока может быть задержка. Но sprintf(buff, "Hello world!") - тут уж точно, такт в такт.

Видимо, подразумевалась работа с кучей при вызове printf, sprintf.

sprintf вовсе не обязательно использует кучу.

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

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

А мне все равно неясна желательность С++ в приложениях малого среднего размера. Нужна инкапсуляция ? static в С никто не отменял (не тот, что модификатор хранения, а тот, что спецификатор области видимости). Виртуальные ф-ции и наследование - нет проблем http://habrahabr.ru/post/138684/
Ну да, операторы не перегрузишь, - но имхо польза этого сомнительна, в Яве это вообще убрали. Ну, а главное, красивые программы для эмбеддед - лично мне доводилось видеть только на С. На С++ 90 % используют 10 % особенностей языка, а так - в основном фишки вроде "объявляю переменную где хочу, более продвинутые promotion rules, ну и подобные , малозначимые вещи. Что-то серьезное, с полиморфной обработкой данных, общепринятыми паттернами, использованием STL итп в МИКРОконтроллерах - ну не видел. Ну не спорю, может мало видел. Зато качественного С кода - много. Статистика однако, пусть и личная. А обработку исключений в MCU много кто использует ? Не все даже знакомы с try - catch , а вы ++ говорите.


Вообще не вижу связи.


А гда вы вообще реализации с кучей видели (в смысле с дин. выделением памяти в ней) ? Вот рекурсивные они обычно, это да..

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

О чем и речь.

Вот прямо сейчас у меня в проекте на Kinetis MK70 используется Flash File System на NAND с выравниванием износа и прочими фичами.
Вся написана на C++. Там по полной используются классы, всякие виртуальные методы, итераторы, переопределения операторов, STL и проч.
До этого как то портировал Windows CE на iMX, там тоже файловые системы только на C++ были.
А все это довольно слабые uКонтроллеры.

Эт так для сведения.

Терпеть не могу когда в одном проекте мешаются несколько языков.

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

Тут меня прошу простить - ибо я не компитент.
Есть мнение

Сейчас на форуме ведется много споров, о том как делать исходники лучше в плане совместимости и соответствию стандарту.
Мне казалось, что newlib для МК будет самым совместимым и стандартным решением.
Конечно же реализации printf для вывода строк и целых чисел не обязана быть сложной и требовать много ресурсов - этим и объясняется большое количество безкучевых решений.

Но на самом деле я ничего не утверждал, а лишь предположил ответ на #27

Опустим малый размер из рассуждения.
В прочих случаях красота=надёжность кода экономят время. Не железякино время, а время от нашей жизни.
Да, C++ избыточен и у него с безопасностью не всё ладно(суть потомки C появляются немерено). Гугль их всех помИрит, год не час.

printf обладает некой детерминированностью только на простейших реализациях от Microchip-а.
А, например, в RealView от ARM совсем другая песня.

А вообще имелся в виду и heap который printf использует, и то что он выходит на потоки STD IN/OUT/ERR которые платформенно зависимые, и то что время выполнения может быть детерминировано но все равно не известно и нужен по любому профайлинг. А также то, что время выполнения зависит от аргументов.
Ну короче, printf никак не риалтайм функция.




Время экономят хорошая память и наработанные рефлексы.
Красота тратит наше время, ибо оно тратится на созерцание.

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


Где утверждается желательность? На чём нравится, на том и пишите. Язык во много определяет процесс мышления и комфортно думать на том языке, который ближе/нравится. Если вам удобнее думать в пространстве средств языка С, ради бога; мне удобнее думать в пространстве средств языка С++ (в одном и том же контексте, естественно).


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


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


Статистику нужно наводить относительную - какой процент программ, а по абсолютным значениям судить бессмысленно, ясно, что на С программ на порядок-два больше, как и программистов. И уж красота программы на С - это само по себе достаточно странное - какая там может быть глубокая красота программы, написанной на портабельном макроассемблере, которым по сути является С, поддерживающим одну-единственную парадигму программирования - процедурную. Вот вся эта красота процедурная и есть. Уровень описания очень низкий, никуда особо не разбежишься. Да, код получается эффективный (компактный, быстрый), но это благодаря близости к железу. Вот и вся красота. К слову, на С++ при должном умении код получается не уступающим по эффективности С (а кое-где и превосходящим), только вот умение оное приобрести не так просто. Что касается красоты, так и тут пространства больше. На этом форуме neiver приводил собственную либу управления пинами AVR, основанную на списках типов (добро пожаловать к тов. Александреску ). Вот это действительно красота (для тех, кто понимает), хотя практическое применение именно в этом контексте лично для меня сомнительно.


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

А мне не ясно нежелание писать на с++ в приложениях малого среднего размера...... Хотя наверно ясна... это консервативность... т.е. если прогер в си как рыба в воде, а в с++ его в ступор вводит символы ::, то конечно ТОЛЬКО СИ. Но если ты знаешь с++ или ты не знаешь ни си, ни с++, то однозначно учи и пользуй с++. Пример: маленькая программа, холоворд на с++

Чем не нравится эта с++ программа? Чем она хужа аналога на си? Ничем! Если кто-то нелюбит ООП в с++ для эмбэддэд, считает что не нужны try - catch в эмбэддэд, а STL на аттини - это оверинженеринг - не пользуйте эти плюшки. Пишите весь код в си стиле но на с++. Зачем нужен си? Несегодя-завтра у вас в эмбеддэд будет linux или windowsXP, и этот эмбэддед будет мало чем отличатся от настольного ПК, и вам потребуется try/catch - пожалуста, пользуйте. Будет эмбэддед на ATtiny с компилятом с++, в котором даже не реализованы new и delete - пишите всё на томже с++. Зачем учить новый язык? везде нужно использовать с++.

Конечно при написании рпограммы на с++ нужно адекватно оценивать возможности эмбэдэда и потребность в тех или иных плюшка. Там где достаточно массива интов, не нужно использовать std::list<MyClass>, где MyClass содержит в привате инт, и в паблике кучу методов для чтения/модификации этого инта.

Почитаете первые же ссылки по психологии программистов и поймете свои заблуждения.
Например "Психбольница в руках пациентов" Алана Купера. (глава 7)

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

Вот тогда поймете чего действительно стоят 'плюшки' на C++.

juvf
IMHO, ответ на вопрос "Почему до сих пор "сидят" на С/С++? " очень прост.
Потому, что в embedded большинство задач (и следовательно программистов) решают достаточно тривиальные задачи.
Для таких задач язык С прост и понятен. А также удобен и достаточен.
При переходе к более сложным задача используют С++. Это даже не язык - это целая вселенная! Средств языка хватает чтобы работать и на низком уровне аппаратных регистров и на уровне очень мощных абстракций ООП.
Мощь С++ заключается именно в его демократичности: изучить и практически использовать его можно буквально за 1 день. Другое дело, что года за три можно освоить его в той мере, что начинаешь понимать его красоту и изящество. Его реальную мощь. (Это пример из жизни когда в одном проекте работали и простые кодеры и ПРОГРАММИСТЫ. И все на С++).
Только в embedded-задачах мощи то и особенно развернутся и негде.
К моему глубокому сожалению, большинство тех, кто использует С++ (по моему опыту) слабо понимают силу инструмента, который они используют.
Поэтому и плодятся всякие Java, C# и прочие "серебряные пули". Эдакие "эрзац С++" для ленивых.
Только в реальной жизни чудес не бывает - за всё надо платить: памятью, быстродействием, энергопотреблением.
Пока цена ресурсов ниже цены труда программиста - это приемлемо. И оправдано.

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

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

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

Так вот C/С++ это язык для тех, кто точно знает, как то или иное должно быть устроено (для "архитекторов"), и нуждаются в таком языке, который был бы способен выразить все нюансы идеи. В тех же случаях, когда язык этого в полной мере не позволяет, такой программист вынужден непроизводительно тратить свое время и силы на борьбу с языком, изобретая способы, как бы ему заставить язык сделать код именно таким, каким он его задумал, а не таким, каким он получается по умолчанию. Языки слишком высокого уровня такого программиста зачастую раздражают, т.к. он не хочет пользоваться кодом, который "написали индусы или финские студенты" .

Напротив, программисты-потребители обычно избегают вникать в то, как работают те или иные функции, а уж тем более заниматься по этой части оптимизацией. Мол, занимает данная функция столько-то килобайт в памяти и требует столько-то времени на свое выполнение – то так тому и быть. В крайнем случае, они станут искать аналогичную функцию в библиотеках других производителей, но никогда даже не подумают о том, чтобы написать такую функцию самим. Свою работу такие программисты рассматривают в плоскости того, как "подружить" одни части чужого кода с другими, настолько же чужими. И даже по вопросам на форуме, таких за версту видно.

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

Вот для последних и создают языки типа Python , которые предоставляют широкий спектр готовых функций в обмен на сокрытие всего того, что связано с их работой.

Чем си удобней с++? Чем си проще и понятней с++? Я не говорю об ооп. ООП и на си можно реализовать и на асме. Я говорю о с++. Я написал пример тривиального кода на с++. Перепишите этот же код на си, что в си-коде будет проще и понятнее?

О каких плюшках вы говорите? Я привел пример кода на с++ - где там плюшки, которые действительно стоят?
в с++ есть плюшка bool - чего она стоит?
в с++ есть плюшка for(int i = 0; i<10; i++) - чего стоит плюшка внутри for объявлять i?
в с++ есть плюшка передачи аргументов в функцию по умолчанию - чего стоит эта плюшка?

Меня услышали так "А мне не ясно нежелание писать на с++ с использованием ООП и STL, с использованием паттернов и т.п. в приложениях малого среднего размера".
А говорил я так "А мне не ясно нежелание писать на с++ в приложениях малого среднего размера". Зачем вообще изучать си и писать на нем ПО (за исключением поддержки старого), если есть с++? С++ почти полностью включает си. Т.е. можно изучить в с++ только ту часть, которая стоит столько же, сколько и в си, которая проста и понятна и с помощью которой можно решать тривиальные задачи. Если не нравиться ооп и плюшки - не используй их в коде, но пиши на с++. Пиши в стиле си, но на с++. Зато потом, если понадобится какойнить перегруз функции, или класс, или другая плюшка.... то без проблем добавил в код и поехал дальше. Не нужно изучать новый язык, не нужно переписывать си код на с++ и не нужно скрещивать в проекти си код с с++.

Кто-то считает что с++ это обязательно плюшки и дает уроки по чистому с++ как здесь. Но это не так. Не нужно перегружать код всякими ненужными плюшкам. Вот пример холоворда на с++
Убиться об стену! Тривиальная задача решена.... из пушки по воробъям! Зачем? Вы думаете что си не позволит начудить оверинженеринга? Ошибаетесь.

juvf
Дык, в моём сообщение и не было утверждения, что си удобней с++.
Просто исторически сложилось, что для ОМЭВМ сначала появились эффективные компиляторы С, а уже потом С++.
Поэтому и "переползали" на С, а не на С++. А в силу тривиальности задач на С и остались.
Если "с нуля", то конечно С++.
У нас теперь ВСЁ программное обеспечение разрабатывается на С++: специалист растёт в рамках одного языка. Это экономически выгодно.

Ничего не стоит. В C это тоже есть. C-99.

Надо понимать это поверх линукса вы пишите ВСЁ на C++ ?

С++ нишевой язык не из-за своей недосягаемой могучести. А потому что его уже проехали.

Теперь гики косеют от Python, Swift, Go и проч. В психбольнице ничего не меняется.
Цель новых языков не что там ускорить, а сделать процесс увлекательным, о чем и пишет Apple в аннотации к Swift.

Хотел бы я посмотреть наколько быстрее напишет программист на C++ приложение для Kinetis по cравнению с программистом на C-и базируясь на инструментах и библиотеках предоставляемых Freescale.
Вот на 100% уверен, что C-и победит.

И мне не ясно нежелание писать на Форт (Forth) приложения малого и среднего размера (хотя как это оценить)

Возможно это

или "нежелание" "неумение" расставаться со "своими" "скелетами в шкафу" или "ограничнность" восприятия иных реалий программирования.


Банально холоворд на Форт

и так во многих моментах Форт реалий


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


Всё программирование в конечном счёте сводится к пересылкам одних ячеек памяти в другие (или одного потока данных процедуры к другой процедуре) с какими то преобразованиями при этом. А для этого многие искусственные абстракции типа опять ООПа не так важны. Достаточно иметь возможность делать векторным (переназначаемыми на разный код) некоторые процедуры в программе и по возможности избавляться от бездумного использования глобальных переменных.

P.S. Это мне "видится" так Патерны проектирования для меня увы почти незнакомы т.к. мне не приходится вести "позиционные войны" с используемым языковым инструментарием (что подумаю то и запрограммирую).
Пример вызова цикла for из другого слова с передачей диапазона цикла (тоже банально просто) печати 10-ть раз Hello World

Вопросы?
и интересный аспект Форт творчества CC14 LIfe: Wild Demo - #1 'Forth DemoTool'
похожая направленность детского творчества в проекте reda4 программирование как игра.