Pull to refresh

Comments 153

Из статьи не понятно в чём «Трагедия Common Lisp».

P.S. Похоже автор статьи не знаком с «Трагедией Forth» и её историей. :)
А в чем трагедия Forth, вроде, он успешно используется для процессоров, устойчивых к радиации?

Гм, а пруфы есть? А то я в основном как-то про другое слышу.

А, ну если из серии «был использован», то да — был.
В чем там трагедия, если на его базе сейчас Telegram запилил новый Fift?
Вы считаете это успехом? (не зная всех реалий и возможностей)
Или это лишь повод обратить свой взор на этот странный язык программирования — Форт?
Хорошее вступление, с нетерпением буду ждать статьи.
> Когда язык небольшой, наша оценка часто определяется чувством: «Я могу всё выучить и овладеть им»
На мой взгляд это и есть основа основ. Освоив минимальный язык и столкнувшись с ограничениями, одни пишут полезные и не очень библиотеки (у того же С были ведь стандартные неслабого объёма), другие же, кто имеет возможность влиять на развитие языка, развивают бурную деятельность по его расширению. Вот тут-то и собака зарыта. Всё это делается на базе уже имеющихся знаниях, кажется, что вот это и вон то, да и нечто до кучи будет полезно и востребовано.
Это так, но для новичка подобное делает стройный язык менее удобоваримым, у него же нет таких базовых знаний языка и опыта, ему приходится изучать язык со всеми примочками.
А разработчикам не всегда удаётся соблюсти баланс.

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

Си любят в эмбеде, потому что там и без собственно технологии программирования хватает вопросов для изучения, так что если вы новичок в эмбеде — лучше начать с Си.
Вот эта фраза вызвала у меня когнитивный диссонанс. Си — это очень сложный и очень небезопасный язык. У него есть некоторые достоинства, но если у вас и так «хватает вопросов для изучения» — то выбор Си кажется безумием. Потому что такого количества граблей в столь малом объёма — вы вообще мало где найдёте.

По-моему в эмбеде его очень любят… потому что не знают. И используют как «высокоуровневый ассемблер». А когда получают «простреленную ногу» из-за незнания — начинаются какое-то дикое бурление говён…

Всё это очень странно, потому что тот же, упомянутый чуть выше, Forth — куда как более предсказуем… но в эмбеде, в последние годы — нелюбим.
По-моему в эмбеде его очень любят… потому что не знают. И используют как «высокоуровневый ассемблер».

Какое то у Вас противоречивое заявление. И что можно не знать то в "C"? Он в базе простой и примитивный. Если кто то знает ассемблер (используют как «высокоуровневый ассемблер»), то уж с "C" фраза "потому что не знают" звучит странно.


Это в "С++" можно наступить на грабли с tempalate, виртуальными таблицами функций и пр.


Лично я использую "C" в эмбеде потому что в случае проблем вида "Почему не так работает", "нужно четко оценить время выполнения блока кода внутри прерывания" и т.д. всегда можно посмотреть код ассемблера и понять проблему, а не использовать слова "магия".


Например, анализируя результат компиляции (листинг ассемблера), нашел ошибку в GCC кросс компиляторе (STM Cortex-M3). И теперь определенный вариант switch|case просто не использую.

Основные грабли у Си и С++ общие, и имя им — UB (undefined behavior), различается лишь число случаев объявленных как UB.


А основная проблема в понимании Си и С++ — в том, что от компилятора неявно ожидается генерирование конкретного машинного кода для каждого оператора. А ведь это с каждой новой версией компилятора все более не так...

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


И да… все сказанное именно к микропроцессорам относится.


Писать в 2019 году новые программы (web сервисы и т.п.) на C++. Я не мазохист.
Хватает того что приходится поддерживать старые наработки на C++.

Прошу простить, а что не так с виртуальными функциями?

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

Нормально все с виртуальными функциями. И с шаблонами то же.
Вопрос был по понимание основ языка. "С" очень простой язык.
"С++" в полном объеме существенно сложнее.

«С++» в полном объеме существенно сложнее


Это так, я этот тезис и отстаиваю. Просто пытался понять, почему вы именно виртуальные функции отметили — они-то как раз просты для понимания.
Просто пытался понять, почему вы именно виртуальные функции отметили — они-то как раз просты для понимания.

Для понимания в концепциях языка — просты.
А вот сгенеренный код (ассемблерный листинг GCC) не так тривиален и сопоставим как с кодом С.


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

Прошу простить, а что не так с виртуальными функциями?
Указатели на виртуальные функции вызывают, чувство легкого беспокойства.
Какое то у Вас противоречивое заявление. И что можно не знать то в «C»? Он в базе простой и примитивный.
Количество вещей, которые нужно держать в памяти при написании программы огромно. Нельзя выучив чисто си сесть и начать писать что-то полезное, нужно выучить ещё кучу всего. char это не символ, это просто байт, поэтому нужно либо отказаться от многобайтных символов, выбрав какую-то кодировку, либо вручную прописывать требуемый код. Нельзя просто выделить немного памяти и начать туда писать пользовательские данные, нужно сначала проверить размер. Нельзя просто взять символ по индексу, нужно правильно обрабатывать многобайтные символы. Авторы многих программ либо не знали подобных вещей, либо им было просто лень это делать. Нельзя задав пару вопросов программисту на си определить код какого качества он напишет завтра. Глядя на файл си кода, невозможно сказать как он будет работать в приложении.
Эбеддед редко работает с Unicode, извините. Там это просто не нужно. Но, как я уже сказал: C умудрился в крайне малом объёме сконцентрировать крайне большое число граблей. Уже тот факт, что можно взять int, начать прибавлять к нему единичку в цикле и никогда не получить ожидаемого нуля — выглядит очень странно с точки зрения «высокоуровневого ассембелера». Ибо в любом известном мне процессоре вы что-нибудь да получите: если не ноль, так хотя бы прерываение OVERFLOW… а в — запросто получаете бесконечный цикл.

А вызов никогда не вызываемой функции? С каких пор процессоры таким трюкам научились?
Я вас все-таки прошу — ну скажите же уже, на чем писать эмбеддерам? Правда, интересно ваше мнение (Раст не предлагать).

Вообще то речь шла про эмбедeд. И только о нем.
А это очень специфичная тема.


И как я писал, под другое окружение писать сейчас на C/C++ это мазохизм.
Код написанный под Solaris и Linux просто таки пестрит #ifdef платформо зависимыми. А уж про совместимость кода (особенно мультиязычного) для Windows и Unix… Это вообще жесть и угар (хотя и приходилось такое делать).

Си — это очень сложный и очень небезопасный язык


Ну, как бы это сказать… Все познается в сравнении. Да, он сложнее Бейсика или Алгола, например, но на них вы ничего не напишете. А если сравнить его с другими языками, столь же хорошо поддержанными в распространенных тулчейнах для эмбеда, то какой же интересно окажется проще, чем Си?

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

По-моему в эмбеде его очень любят… потому что не знают. И используют как «высокоуровневый ассемблер».


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

Насчет «высокоуровневого ассемблера» — был бы рад услышать внятные возражения этому, весьма популярному и отнюдь не дураками придуманному утверждению. Впрочем, вероятно, что в формате ответа на сообщение это просто невозможно. Пока скажу только одно — если, например, расположить Java и C# (на чем тоже писал, представление имею) на одном полюсе, а Си на другом, а потом попытаться где-то здесь расположить любой ассемблер, то он скорее к Си притянется, что как бы намекает.

А когда получают «простреленную ногу» из-за незнания — начинаются какое-то дикое бурление говён


Ну ладно вам, нытье не зависит от языка.

Всё это очень странно, потому что тот же, упомянутый чуть выше, Forth — куда как более предсказуем… но в эмбеде, в последние годы — нелюбим.


По очень простой причине — сложен для понимания необученными массами. И это приговор не массам, а языку.
Насчет «высокоуровневого ассемблера» — был бы рад услышать внятные возражения

Рассмотрим простой код (не очень корректный):


float *p;
float x = *p;

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


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

Во-первых хотелось бы больше конкретики, а то пример слишком изолированный. Прямо вот на голдболте бы.

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

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

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


Наверное вы считаете, что хороший язык позволяет писать любую муру

Нет, я просто продемонстрировал отличия языка Си от высокоуровнего ассемблера.


К слову — многие ли языки пройдут через этот ваш тест?

Вполне возможно, что ни одного. А почему ответ на этот вопрос важен?

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


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

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


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

Вполне возможно, что ни одного. А почему ответ на этот вопрос важен?


Ну, если спорить с утверждением о том, что Си можно назвать «высокоуровневым ассембером», то хорошо бы привести пример языка, более соответствующего этому утверждению. Ведь очевидно Си не является ассемблером в буквальном смысле, это не нужно доказывать, однако будучи «языком для кроссплатформенной разработки ОС» (так его тоже называют), он очевидно ближе к ассемблеру, чем другие языки. Если это утверждение неверно, то нужен пример другого языка.
Все еще хуже — проект собирается только одной конкретной версией тулчейна и не переносится в другую IDE без танцев с бубном.
И это, извините, называется «простой язык»?

И это никак не решается знанием стандарта Си.
Почему не решается? У других как-то решается. Более того: как-то программы на миллионы строк переносятся… а программы на тысячу — аж никак. Не находите это несколько… странным?

Почему разработчиков Chrome уведомляют о том, что у них компилятор сменится тогда-то и тогда-то (и связано это в основном с вопросами поддержки разных версий OS)… а для разработчиков поделки в 1000 раз меньшего размера — это катастрофа?

будучи «языком для кроссплатформенной разработки ОС» (так его тоже называют)
Его не «так называют». Он для этого сделан.

он очевидно ближе к ассемблеру, чем другие языки.
Совершенно не очевидно. C никогда не используется сам по себе для написания OS. Всё, что имеет отношения к конкретной архитектуре пишется на ассемблере. Всё, что не имеет — уже на C. В некотором роде C — это анти-ассемблер.
И это, извините, называется «простой язык»?


Именно так. Язык — простой. Система разработки в целом — сложная и, что собственно и играет здесь роль, многовариантная.

Почему не решается? У других как-то решается.


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

Почему разработчиков Chrome уведомляют о том, что у них компилятор сменится тогда-то и тогда-то (и связано это в основном с вопросами поддержки разных версий OS)… а для разработчиков поделки в 1000 раз меньшего размера — это катастрофа?


Насчет катастроф вы явно преувеличиваете, но вообще это обычное дело — чем крупнее и компетентнее команда, тем лучше она умеет «сопротивляться» любым внешним подачам. Чего тут обсуждать? Язык-то как влияет на эту картину?

В некотором роде C — это анти-ассемблер


Все, победили, с этим спорить невозможно.

Ну так что же, какому языку следует учиться эмбеддерам?

И просто для примера… (gcc version 4.5.0 ARM STM Cortex-M3)
Если просто
float p;
float x =
p;
то компилятор выдаст предупреждение, а код с оптимизирует (p и x не используются.)


Если x потом поиспользовать, то…
272:main.c * float p;
273:main.c **
float x = *p;

20968 0008 1868 ldr r0, [r3, #0] @ float
20969 000a FFF7FEFF bl __aeabi_f2iz


В принципе вполне так высокоуровневый ассемблер…
"int __aeabi_f2iz(float) — float (single precision) to integer C-style conversion"

Речь идёт вот подобных вещах. Когда вот такая функция:
int bar(float *p) {
   if (p==NULL) {
      return foo();
   } else {
       return *p;
   }
}
проверку на NULL содержит. А вот такая вот:
int baz(float *p) {
   float x = *p;
   if (p==NULL) {
      return foo();
   } else {
       return *p;
   }
}
уже нет. И вызова foo — там тоже нет.

Это что за ассемблер такой, который берёт и выкидывает куски кода?
Ну еще раз — во второй функции написан очевидный бред…
Тем не менее поведение этого бреда «с точки зрения реального» железа и с точки зрения C — отличается. И отличиается очень сильно. Особенно если вспотнить, что у большинства микроконтроллерово образение к адресу ноль — ошибок не вызывает.
Это-то да, но суть в том, что подобный код в принципе писать нельзя. Зачем же его обсуждать?

И, все-таки, напишите ваши соображения по поводу того, чем заменить тут Си. Правда интересно ваше мнение.
Это-то да, но суть в том, что подобный код в принципе писать нельзя. Зачем же его обсуждать?
Затем, что большинсво эмебеддеров считают, что его писать можно (как мы вот прямо здесь видим), а когда он не работает — это записывается в категорию «ошибка компилятора».

И именно потому что большинство эмбедеров не знают C и не умеют на нём писать — они и считают его «простым». Собственно с этого тезиса началась наша дискуссия.

И, все-таки, напишите ваши соображения по поводу того, чем заменить тут Си.
Всё зависит от того, кого вы хотите привлечь к проекту. В былые времена подходящими кандидатами были Forth и MP/M, сегодня, возможно — Rust… Ассемблер, опять-таки никто не отменял… да даже и C, в общем-то можно использовать, если понимать что делаеть.

Вот только не надо про его «простоту» рассказывать. Это — сложный язык. Удивительно сложный для своих небольших размеров, а общем-то.

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


Насчёт лучшего языка:
1) Специалистов со знанием Форта прямо пруд пруди (сарказм). И писать на нем прямо страсть как удобно (сарказм). И библиотек наверное много, особенно от вендоров (сарказм).
2) Писать сколько-нибудь сложные проекты на ассемблере — ну уж нет, я через это проходил (правда там было развитие, а не написание с нуля, но все же). Опять же гора библиотек под ассемблер (сарказм).
3) Раст имеет весьма странный синтаксис и вообще сам по себе странен. Нужно наверное очень много на нем писать, чтобы перестать потеть от одного внешнего вида. Ну и расчет специалистов/библиотек все уже конечно не так плохо, но просто капля в море по сравнению с сишным наследием.


Я чесгря ожидал, что вы плюсы предложите, но нет.


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


P.S.: Пожалуй не стал бы спорить с вами насчёт Раста в условной параллельной вселенной, где никто не видел Си и нет столько наследия. Но не в нашей.

Не думаю, что вы докажете полную иммунность того же Форта к ошибкам программиста.
Форт гораздо ближе к ассемблеру, чем даже к C. Как и в ассемблере — любая чушь, которую вы напишите как-то да сработает и что-то да сделает. Такое себе программирование «по бразильской системе».

Зато сам по себе язык действительно маленький и «от себя» «граблей» не доваляет. Что написали — то и получили…
Ну то есть ошибки были, есть и будут — просто вы не готовы мириться конкретно с UB, и его отсутствие в Форте вас удовлетворяет. Позиция ясна. А меня вот, как человека от сохи, не удовлетворяет Форт в общем и целом, ну вырвиглазный же язык.

Вот реально, будущее могло бы быть у Раста, не будь он тоже отчасти вырвиглазным. А сейчас нам остается надеяться на статические анализаторы для Си, если нам реально нужно фильтровать лажу ан масс.
Ну то есть ошибки были, есть и будут — просто вы не готовы мириться конкретно с UB, и его отсутствие в Форте вас удовлетворяет.
Конкретно UB плох тем, что если писать программы, которые его игнорируют, то переход на новую версию компилятора становится кошмаром — со всеми дальнейшими проблемами из этого вытекающими.

Форт таких проблем не содержит: если у вас в программе ошибка — то она в новой версии будет «срабатывать», если ошибок нет — то их таки нет.

А меня вот, как человека от сохи, не удовлетворяет Форт в общем и целом, ну вырвиглазный же язык.
Вопрос привычки. Люди, переходящие с Ada или Pascal имеют такое же мнение про C: всё эти ваши странные занчки и крючёчки… ужас же.

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

Пока ошибки, в общем и целом, производителю не встают «в копеечку» — язык C будет процветат.
Конкретно UB плох тем, что если писать программы, которые его игнорируют, то переход на новую версию компилятора становится кошмаром


Предлагаю таких программ не писать. На полном серьезе.

Вопрос привычки. Люди, переходящие с Ada или Pascal имеют такое же мнение про C: всё эти ваши странные занчки и крючёчки… ужас же.


Хз, адовские программы я только лишь видел, и они не выглядят вырвиглазными, а на Паскале довольно долго писал (в школе) — и как-то у меня моментально переход на Си произошел.

Не. Остаётся надеяться только на регуляторов, которые будут делать так, чтобы ошибки получали свою цену. Пока ошибки, в общем и целом, производителю не встают «в копеечку» — язык C будет процветат.


Опять какая-то параллельная Вселенная… Вы хотите сказать, что во всех конторах, где для разработки mission critical software используется Си (не в чистом виде, как правило), руководство типа спит спокойно и ни о чем не думает? И типа ответственности никакой не несет и потому ничего не боится?
Вы хотите сказать, что во всех конторах, где для разработки mission critical software используется Си (не в чистом виде, как правило), руководство типа спит спокойно и ни о чем не думает?
Почти во всех. Какая-то ответственность наблюдается у столь малого процента, что они — погоды не делают.

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

Предлагаю таких программ не писать. На полном серьезе.
Как вы собираетесь это обеспечить? Если люди элементарно не знают инструмента, которым они пользуются — и не хотят знать. Ибо это — не-вы-год-но.
Ну не могут несколько тысяч человек, работающих на обронку и атомщиков, «перебить» тренд всей индустрии, где выпустить дерьмо, которое глючит и разваливается, но вложиться в рекламу — гораздо выгоднее, чем выпустить что-то надёжное


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

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

В-третьих, современные тренды управления проектами сами по себе не располагают к тому, чтобы в отсутствие жестких регуляторных требований задрачивать что-то насмерть, достаточно «as low as reasonably possible», это позволяет снизить издержки и не перекладывать их на потребителя (а ведь именно это обычно толкает его покупать всякий «подвальный кал»). Так что задача переломить всю индустрию возможно и не стоит.

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


Ничего подобного. Есть стандарты MISRA, есть небесплатные анализаторы под них — уже какая-никакая инфраструктура, мешающая совершать ряд ошибок. У авиастроителей свои свадьбы, даже на Хабре можно про это почитать — UB просто в принципе не пролезает.

Как вы собираетесь это обеспечить? Если люди элементарно не знают инструмента, которым они пользуются — и не хотят знать. Ибо это — не-вы-год-но.


Очень просто же — требованиями регулятора. Если они есть, то люди начинают шевелиться — либо закрывают бизнес. Ничего иного не придумано.
Очень просто же — требованиями регулятора. Если они есть, то люди начинают шевелиться — либо закрывают бизнес. Ничего иного не придумано.
Ну вот пока что — регуляторы заняты «не тем», мягко говоря.

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

Есть стандарты MISRA, есть небесплатные анализаторы под них — уже какая-никакая инфраструктура, мешающая совершать ряд ошибок.
И, тем не менее, всё это «повешено» поверх всё того же ненадёжного и опасного языка C, что и всё остальное. Почем там не используется какая-нибудь Ada?
Ну вот пока что — регуляторы заняты «не тем», мягко говоря


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

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


Если программа приведет к тому, что упадет самолет, то вы легко сможете кинуть предъяву производителю самолета. Если же вы, условно, купили Windows (с явным отказом от ответственности) и, опять же условно, сделали базу данных миллиона учеников на MS Access (тоже с явным отказом от ответственности) и дальше у вас все упало от случайно вставленной флешки — ССЗБ же. Виноваты не только те, кто написали плохое ПО, но и те, кто его купили. Есть много ПО, ответственность за которую производители несут в полном объеме, просто его мало, оно не на слуху и стоит других денег (и зачастую также не блещет качеством самого кода, но интеграционное тестирование более чем на уровне).

И, тем не менее, всё это «повешено» поверх всё того же ненадёжного и опасного языка C, что и всё остальное. Почем там не используется какая-нибудь Ada?


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

Есть мнение, что у нее тяжелый синтаксис, и я с этим отчасти согласен. Хотя, как по мне, это почти что Паскаль, но ведь он ни разу не образчик хорошего синтаксиса (особенно в сравнении с Си). Утверждается, что Аде «не хватает выразительности» (понимай как знаешь). Известны также высказывания известных людей (возможно от обиды) относительно сложности языка и запутанности проекта стандарта.
Если же вы, условно, купили Windows (с явным отказом от ответственности) и, опять же условно, сделали базу данных миллиона учеников на MS Access (тоже с явным отказом от ответственности) и дальше у вас все упало от случайно вставленной флешки — ССЗБ же.
А почему, собственно? Почему, купив булку хлеба и обнаружив в ней крысиный хвост — вы можете подать в суд и получить неплохие такие деньги. А купив Windows за несколько тысяч баксов — вы не получаете никаких гарантий?

Виноваты не только те, кто написали плохое ПО, но и те, кто его купили.
Те, кто его покупают — зачастую не имеют особо выбора. Вообще если бизнесу дать волю — то он наплюёт на любые правила безопасности. Отсюда, собственности необходимость в регуляторах. Только ограничения касаются очень малого процента софта — в этом основная проблема.

Есть много ПО, ответственность за которую производители несут в полном объеме, просто его мало
Так много его или мало? Если много — почему его нигде не видно, если мало… ну так в этом и проблема.

Что-то это значит наверное?


Не стали бы люди просто так отказываться от хорошего языка в пользу плохого.
Легко. Популярность куда важнее, собственно, качества языка. Принцип «никто еще не был уволен за покупку оборудования IBM» распространяется и на языки программирования и на многое другое.

Хотя, как по мне, это почти что Паскаль, но ведь он ни разу не образчик хорошего синтаксиса (особенно в сравнении с Си).
Мне и до сих пор кажется, что у С — крайне некрасивый и неудобный синтаксис. Притом, что я пишу на C++ последние 10 лет.

Но он привычный — а дальше уже неважно.

Что касается «недостаточной выразительности» — то да, у Ады есть большая беда: она сидит «между двух стульев» (именно «не на двух стульях», а «между двух стульев»). Когда её проектировали, то рассчёт в области безопасности шёл на GC… а потом его решили не делать обязательной частую среды. В результате написать мало-мальски сложную переносимую программу на Ada нельзя.

Всё не так ужасно, как в случае с Pascal'ем (где ничего почти нельзя переносимым образом сделать… работа с строками — непереносима, куда уж дальше), но, в общем, там хватает проблем переносимости.

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


EULA — читаем и (не) покупаем. Свободный рынок.

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

Только ограничения касаются очень малого процента софта — в этом основная проблема


Если весь софт обложить определенными требованиями по надежности, то наблюдаемого с 80-х и поныне бума развития софта просто не будет.

Так много его или мало?


Ну, да, я некорректно выразился. Его достаточно много, чтобы не говорить, что его нет совсем. :)

Популярность куда важнее, собственно, качества языка


Ну а популярность-то откуда берется?

Это как с долларом. Плохой он, зеленый, золотом не обеспечен, однако в любой точке Земли к расчету принимается по высшему курсу.

Мне и до сих пор кажется, что у С — крайне некрасивый и неудобный синтаксис


Гм, что же вам не нравится? Ну, кроме трудности отличения того, к какому контексту относится закрывающая скобка (}).

В результате написать мало-мальски сложную переносимую программу на Ada нельзя


Вот тут не согласен. Если не использовать автосборку мусора, то почему вдруг программа станет непереносимой?

Собственно и реализаций языка немного, где там проблемы с переносимостью вообще…

Всё не так ужасно, как в случае с Pascal'ем (где ничего почти нельзя переносимым образом сделать… работа с строками — непереносима, куда уж дальше)


А расскажите для общего развития, что не так с со строками в Паскале? Давно уже забыл все. Вроде же просто массив, у которого есть максимальная длина, и текущая длина. Только ASCII, ну это не в новинку.

Но главное — её некому продвигать


И это при том, что у нее были такие локомотивы!
С булками иначе, там другое законодательство.
Ну так в этом и проблема. Пока за потерю данных никто не платит — их будут терять. Ибо это выгоднее.

Если весь софт обложить определенными требованиями по надежности, то наблюдаемого с 80-х и поныне бума развития софта просто не будет.
О каком «буме развития софта» вы говорите? Он кончился в конце прошлого века. Ну может ещё пару лет из этого. Всё принципиальные новинки, появившиеся с тех пор (всякие интересные вещи, связанные с машинным обучением и прочим) — результат развития железа.

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

Ограничить это порождение всё больших количеств дерьма, не ведущих к реальному прогрессу — сам бог велел.

Не одномоментно, конечно… если сразу ввести жёсткие нормы, то мы вообще без софта останемся. Но постепенно. Требования к выпечке хлеба не сразу стали такими, какие они сегодня.

Ну а популярность-то откуда берется?

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

После второй мировой доллар был логичным выбром, так как чуть не половина мирового промышленного производства была сосредоточена в США. Ну а сейчас «соскочить» весьма непросто — это процесс идёт.

Популярность C — прямая заслуга Cygnus'а, который смог сделать так, что на любой, самой кривой embedded архитектуре есть компилятор C — хоть и не самый лучший, но, как правило, не хуже, чем альтернатива: какой-нибудь убогий типа-язык от производителя.

Но Cygnus — уже давным-давно история и та же Ada, при желании, портируется хоть на восьмибитный AVR… Но разработка всё равно ведётся на C…

Гм, что же вам не нравится? Ну, кроме трудности отличения того, к какому контексту относится закрывающая скобка (}).
Ну опишите хотя бы массив функций, получающих массив callback'ов… С какого раза удастся не заблудиться в бесконечных скобочках? А потом попробуйте им воспользоваться.

Работа с типами в C == боль, работа с указателями == боль… и это мы ещё до C++ не добрались. Да и фигурные скобки для блоков — не лучший выбор.

Если не использовать автосборку мусора, то почему вдруг программа станет непереносимой?
Потому что без выделения памяти много чего не очень удобно писать… а освобождать как? Переносимого способа нету…

А расскажите для общего развития, что не так с со строками в Паскале? Давно уже забыл все. Вроде же просто массив, у которого есть максимальная длина, и текущая длина.
Вы о каких строках? Те, которые у Вирта — это просто массивы char'ов, с первым индексом 1. Никаких строк переменной длины у него не было. Они появились в «Расширенном Паскале» — но там они были генерик-типом! Однако в большинстве популярных диалектов всего этого великолепия не было, а вместо этого, обычно, был доморощенный тип string, несовместимый со стандартным ни в каком виде! Начиная с того, что стандарт предписывал писать string(30) (и завести переменную без указания размера было нельзя), а какой-нибудь Turbo Pascal — либо string, либо string[30].

И это при том, что у нее были такие локомотивы!
Это тормоза были, а не «локомотивы». Все участники «движухи» вокруг Ada хотели денег. Много денег. Первая бесплатная версия вышла в 1995м. К этому моменту «в лагере C/C++» уже были «студенческие пакеты» (Turbo C и Quick C), «визуальные среды» (Borland C++ 4.5, Visual C++ 1.5), Cygnus уже портировал GCC на десятки процессорных архитектур…

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

А ещё и «гениальная» идея владельцев Borland'а (в те же годы): турнуть Фила и «сконцентрироваться на ынтырпрайзе» (в результате чего компания потеряла поддержку университетов и перестала приносить прибыль)…

В общем Pascal и Ada оказалось тупо некому продвигать: «доить» корову хотели многие, «кормить» — не хотел никто…
Ну так в этом и проблема. Пока за потерю данных никто не платит — их будут терять. Ибо это выгоднее.


Да, так и есть. И хотя я горячий сторонник хорошего софта, я все-таки не думаю, что попытка заставить тот же мелкософт отвечать за все миллиарды инсталляций по миру будет хорошей идеей. Ведь она сулит непреодолимый поток жалоб и разбирательств, который не только по карману мелкософта ударит. Ну и, что важно, тогда у нас всех будет один Windows. Всегда. К слову — не так уж это и плохо было бы.

О каком «буме развития софта» вы говорите? Он кончился в конце прошлого века.


Ну, ээээ, я даже не знаю, что тут сказать.

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


Ну так естественно, потому и идет прогресс, что, реализовав все возможное на этом этапе, мы идем вперед. Но когда терафлопс уместился на ладони — что мы стали делать? Правильно, умные колонки, маневрирующие коптеры, кучу всего другого. что потребовало кучу софта. Который был написан во многом благодаря тому, что эти разработки не превращались каждый раз в лицензирование на право строительства АЭС.

Популярность C — прямая заслуга Cygnus'а, который смог сделать так, что на любой, самой кривой embedded архитектуре есть компилятор C


То бишь Гилмор сотоварищи решил добровольно и без поддержки DoD рассеять C/C++ по всему миру (причем, если точнее, целью быль не конкретный язык, а вообще вся ГНУсятина). Полагая, что он и его сторонники были явно не дураки, я предположу, что язык они тоже выбрали не от балды (теоретически у них было из чего выбрать, кроме Си, несмотря на то, что почти только на нем они тогда и писали). Других столь же самоотверженных друзей у других языков не нашлось. Что-то это да значит наверное? Почему сейчас нет энтузиастов, готовых пройти тот же, уже много более простой в нынешних условиях, путь?

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

Ну опишите хотя бы массив функций, получающих массив callback'ов… С какого раза удастся не заблудиться в бесконечных скобочках? А потом попробуйте им воспользоваться.


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

Работа с типами в C == боль, работа с указателями == боль… и это мы ещё до C++ не добрались.


Спрашивать вас, что там за боль с типами, я как-то боюсь (потому что у меня ее практически нет, и это наверное означает что-нибудь страшное), а вот с указателями какая такая боль? Напомню — мы говорим сейчас про синтаксис языка, а не про подводные камни.

Насчет плюсов — согласен, там полный барокко с синтаксисом. Хотя ИМХО все равно в близкой перспективе для всего эмбеда плюсы будут лучшим выбором, чем чистый Си.

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


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

Вы о каких строках?


Каюсь, я про Турбо Паскаль.

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

Это тормоза были, а не «локомотивы». Все участники «движухи» вокруг Ada хотели денег.


Э, подождите, я про DoD. Он хотел не денег, а язык ))

Собственно там весьма классическая история же, полностью противоположная истории Си. Движуха была очень сильная, конкурс, стандарты (изданные раньше, чем стандарты Си), вот это вот все. Компиляторов кучу наделали даже в СССР, под самые разные процессорные архитектуры притом. И где оно все теперь?

Первая бесплатная версия вышла в 1995м


Тоже на деньги DoD, к слову. А вот Cygnus…

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


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

Давайте для примера возьмем тот же (Турбо)Паскаль. Вы знаете, что в СССР и России огромное количество людей изучали его в институтах. И вы конечно знаете, что подавляющее большинство из них при первой возможности пересаживались на (Турбо)Си. И мы сейчас не про популярность на разных архитектурах говорим, ведь в основном все эти люди работали на ПК. То есть если был выбор между двумя даже визуально похожими пакетами от одного производителя на одном и том же ПК, то выбор был в пользу Си. Почему же при сравнении с Адой мы говорим напротив, что дело уже не в самом языке, а в «не зависящих от языка обстоятельствах»?

А ещё и «гениальная» идея владельцев Borland'а (в те же годы): турнуть Фила и «сконцентрироваться на ынтырпрайзе» (в результате чего компания потеряла поддержку университетов и перестала приносить прибыль)…


Не совсем понял, а это как-то относится к падению Ады?

Если речь об ударе по популярности Паскаля, так ведь его с уходом Кана не произошло. Ну то есть конечно ТурбоПаскаль начал умирать (но это с Каном вряд ил как-то связано, не мог же тот язык и IDE по сию пору использоваться в проде), но зато в дело пошел Дельфи. И очень долго и продуктивно использовался. Другое дело, что все те многие десятки знакомых мне людей, которые писали на Дельфи, почти в полном составе уехали жить в Borland Builder 6.0. И это тоже кое-что означает, ведь возможности среды формально были ну абсолютно одинаковые.
И хотя я горячий сторонник хорошего софта, я все-таки не думаю, что попытка заставить тот же мелкософт отвечать за все миллиарды инсталляций по миру будет хорошей идеей.
За существующие — конечно нет. Вообще идея заставлять законы действовать «задним числом» плоха.

За новые — почему бы и нет?

Ну так естественно, потому и идет прогресс, что, реализовав все возможное на этом этапе, мы идем вперед.
Мы не идём вперёд. Мы зацикливаемся. Как и любую банальность эту — осветил у себя Джоел: разработка хорошего софта занимает десять лет. Плюс-минус. Потом — порождаются «инновации ради инноваций». Вот ровно так:
Is there anything you need that Excel 2000 or Windows 2000 doesn’t already do? With all due respect to my friends on the Office team, I can’t help but feel that there hasn’t been a useful new feature in Office since about 1995. Many of the so-called “features” added since then, like the reviled ex-paperclip and auto-document-mangling, are just annoyances and O’Reilly is doing a nice business selling books telling you how to turn them off.


А насчёт…
Но когда терафлопс уместился на ладони — что мы стали делать? Правильно, умные колонки, маневрирующие коптеры, кучу всего другого. что потребовало кучу софта. Который был написан во многом благодаря тому, что эти разработки не превращались каждый раз в лицензирование на право строительства АЭС.
Вот прямо тут написано, что всё это потребовало несколько миллионов долларов и годы работы (те же самые пресловутые «десять лет» по сути) всё равно. И неизвестно — стоит ти возможность насладиться «умной лампой» всех тех проблем, которые неизбежно выльются в миллиарды уже в самом скором будущем.

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

Но ведь и теперь у американской экономики нет конкурентов.
По многим оценкам — Китай уже превосходит. Но даже не это главное: когда доллар стал мировой валютой США могли единолично накладывать санкции хоть на весь мир. Сейчас это невозможно.

Если бы сейчас выбирали мировую валюту — разве выбрали бы что-то иное?
А почему вообще должна быть какая-та «мировая валюта»? Тысячи лет крупные сделки отлично совершались с оплатой в килограммах (фунтах, тоннах — нужное подчеркнуть) золота. А мелкие — в решиональных валютах.

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

Но и сам синтаксис, безусловно, проще.
Вот Ada:
  type callbacks_array is
    array(1..10) of access procedure;
  x : array(1..10) of access
    procedure (callbacks : callbacks_array);

type
  array_callbacks = array[1..10] of procedure;
var
  x : array[1..10] of
    procedure(callbacks : array_callbacks);


а вот с указателями какая такая боль? Напомню — мы говорим сейчас про синтаксис языка, а не про подводные камни.
Я про него. Вот скажите *p[10] — это взять десятый указатель и разименовать или взять указатель, разименовать и потом получить десятый элемент массива? А *p++ — сдвигает указатель или то, на что он ссылается? И так далее.

Ну стоп, если мы говорим про весь из себя надежный эмбед, то работа с динамической памятью в процессе выполнения основных функций вообще является не лучшим решением. Если все-таки приходится при функциональной инициализации использовать вручную malloc/free, то почему это вдруг стало непереносимо?
Потому что Ada.Unchecked_Deallocation — это Ada 95. А в Ada 83 была типа как написана для GC… но при этом в реальных реализациях никакого GC не было, а были непереносимые хаки (кроме iAPX 432… но это — отдельная боль… скажем только, что свою цену — оно, мягко говоря, не оправдывало).

Первая бесплатная версия вышла в 1995м

Тоже на деньги DoD, к слову. А вот Cygnus…
А Cygnus торговал компилятором, который не он написал. Ну вот потому что только Столманн уволился из MIT и спал где-то в подсобке — а ни у кого больше на это духу не хватило. А написать именно C он решил, потому что, если ещё не забыли GNU = Gnu is Not Unix. А Gnu is Not Unix — это потому что AT&T широко раздаривала исходники Unix до 1982го года. А раздаривала она его до 1982го — потому что DoJ с ней судилась и потому продавать коммерческие лицензии на Unix AT&T не могла.

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

Разве можно считать непереносимым банальный массив постоянного размера с указателем на последний валидный элемент?
Несмотря на свою «банальность» программы, работавшие со строками, которые в изначальной версии от Вирта работать с такими строками не могли… Ровно как и наоборот, передать «стандартную» строку в процедуру, ожилавшую USCD-строку (изначально это они придумали) — тоже было было нельзя…

Если у вас вариант A работает только со стандартным Pascal'ем, а вариант B — только с нестандартным… то что это за переносимость такая? Перепиши всё программу и живи спокойно?

Э, подождите, я про DoD. Он хотел не денег, а язык ))

Собственно там весьма классическая история же, полностью противоположная истории Си. Движуха была очень сильная, конкурс, стандарты (изданные раньше, чем стандарты Си), вот это вот все. Компиляторов кучу наделали даже в СССР, под самые разные процессорные архитектуры притом. И где оно все теперь?
А бог его знает. До 1995го года все-привсе хотели денег (ну Ok, DoD не хотел… но он же сам ничего и не выпускал), компиляторы продавались за приличные деньги (типчиная цена была от пятисот долларов и до многих тысяч), в свободном доступе их не было.

А компиляторы C были либо дешёвые (Turbo C и Quick C), либо вообще бесплатные… GCC — начиная с 1987го на всяких Solaris'ах, через пару лет и под OS/2 и DOS: EMX и DJGPP.

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

Тем более, что при адиной распространенности речь все-таки шла не о «кучке».
Именно что о «кучке»! До 83го года включительно всех персоналок, вместе взятых, было выпущего порядка десяти миллионов. И ещё меньше — мини-компьютеров и «больших». А вот уже в 1995м — за год было продано 50 миллионов.

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

Но только Pascal, фактически, продвигал один Borland (другие реализации были несовместимы и, фактически, были другим языком, как выше обсуждалось), а вот C — были десятки реализаций (Borland C, High C, Lattice C, Lattice C, Power C, TopSpeed C, Watcom C, Zortech C) и, главное, была популярная бесплатная версия — и она же (но уже за деньги) версия, поддерживающая кучи микроконтроллеров.

А вот где-то после 1998го — бурный рост прекратился. То есть рост был, ещё много лет был, но такого, чтобы «все программисты вместе взятые, сущестсовавашие раньше — составляют лишь небольшую долю от тех, что начали программировать в последние 3-4 года»… такого уже не было.

Давайте для примера возьмем тот же (Турбо)Паскаль. Вы знаете, что в СССР и России огромное количество людей изучали его в институтах. И вы конечно знаете, что подавляющее большинство из них при первой возможности пересаживались на (Турбо)Си.
Вот прям «при первой возможности»? Не знаю таких. На Visual C++ — да, пересаживались. Потому что всё, кроме Visual C++ не поддерживало новейшие технологии Windows. А Borland C++… где вы такие сведения нашли? У меня ощущение, что Delphi был тогда гораздо, гораздо популярнее.

То есть если был выбор между двумя даже визуально похожими пакетами от одного производителя на одном и том же ПК, то выбор был в пользу Си.
Статистика есть? Потому что извините уж, но по сохранившимся старым программам я этого не вижу. На каждую программу, требующую cw32*.dll (Borland C++ runtime) я встречаю несколько, требующих vcl*.bpl (Delphi runtime)… ну и, конечно, десятки программ требующих msvcrt*.dll (Visual Studio) или msvbvm*.dll (но тут Windows-специфика: писать программы под микроконтроллеры или там Android на Visual Basic не получится).

Я сам тоже перешёл с Turbo Pascal на C/C++… но вот как раз никакого Borland C++ я никогда не использовал!

Да что там говорить — даже сейчас вы можете обнаружить инструкции по установке Borland C++ 3.1 в Windows 10 — но получаете вы, в результате, знаменитые синие окошки!

Не знаю где вы жили, что у вас Borland C++ for Windows был популярен… я был уверен, что таких мест в природе не существовало. Выход Windows 95 и бардак в Борланде в это же время его, фактически, убил…

Почему же при сравнении с Адой мы говорим напротив, что дело уже не в самом языке, а в «не зависящих от языка обстоятельствах»?
Потому что это правда? От качества собственно языка мало что зависит. Хороший пример — C#. До 2012го его популярность увернно росла — а потом начала точно так же уверенно падать. Что случилось? Язык, вдруг, поплохел? Нет, конечно. Просто C# намертво прибит гвоздями и прикручен шурупами к Windows. До 2012го казалось, что все эти «выскочки» скоро будут поставлены на место, Microsoft выдавит Android, придёт на IoT… и можно будет комфортно жить в этой экосистеме. А он… ну не шмогла я, не шмогла.

Соотвественно и C# пошёл на убыль. А вовсе не из-за того, что он был хорош, много лет был хорош… а потом бац — и стал плох. То же самое — Swift и Objective-C. Хорошо видно, что «Apple = усё». Вот на рынках — этого ещё не очень видно, а на TIOBE — легко.

Судьба языков, не привязанные к одной платформе — устроена ровно так же, с тем одним (но важным) отличием, что смерть одной платформы может с лёгкостью компенсироваться бурным ростом другой. Так, собственно, тройка C/C++/Java и держится в тройке многие годы: платформы возникают и исчезают, но в среднем — их достаточно, чтобы статус кво оставался неизменным…

P.S. Кстати неправильное прочтение этой статьи легко опровергается тем же TIOBE. Да, Microsoft терпит неудачу и C# «сдувается». Но он явно не умрёт и Windows скоро не «закончится» — это подтверждается вот этим графиком. Пока разработчики надеялись и ждали «пока Microsoft захватит мир» — все вкладывались в C#. А когда стало понятно, что «C# — это только и исключительно Windows»… не бросили Windows совсем, но переключились на другой, более простой и понятный Windows-only язык: Visual Basic.NET…
За новые — почему бы и нет?


Потому что тогда либо никто не будет покупать новую Windows 11 BugFree за $356720, либо если вдруг Microsoft пообещает багфри просто так (с надеждой), то будет ровно то, что я описал.

Мы не идём вперёд. Мы зацикливаемся.


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

Касательно Спольски — как и любой другой клевый чувак из отрасли, он любит делать клевые банальные цитаты. Примерно как тогда, лет десять назад, когда вместе с китайским другом они рассказывали о том, почему для бомжепрограммистов Си лучше, чем C++. Так и тут — мне по работе часто приходится иметь дело с Экселем, и он реально стал лучше с точки зрения интерфейса и возможностей по оформлению (что немало). Хотя конечно мало что принципиально поменялось, ага. Табличный процессор как табличный процессор.

И неизвестно — стоит ти возможность насладиться «умной лампой» всех тех проблем


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

Потому что AT&T больше не находится под следствием.


А при чем тут это в текущей ситуации? Вот кто мешает условному Цукербергу вложить условный миллиард в массовое насаждение Ады в IoT? При том, что это могло бы быть вполне даже окупаемое мероприятие.

Но даже не это главное: когда доллар стал мировой валютой США могли единолично накладывать санкции хоть на весь мир. Сейчас это невозможно.


Не хочу в политоту, но все же — США и сейчас единолично накладывают санкции на весь мир. Причем вообще как хотят. Даже если где-то и не слышали про доллар, то санкции на них все равно наложить могут.

А почему вообще должна быть какая-та «мировая валюта»? Тысячи лет крупные сделки отлично совершались с оплатой в килограммах (фунтах, тоннах — нужное подчеркнуть) золота


Скорее всего потому, что расплачиваться металлическими деньгами весьма неудобно. Решил я такой заказать гостиницу в Чили для командировки, и иду на почту — посылать им щепотку золота для предоплаты…

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


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

Вы конечно скажете «ага, ну вот в Си надо ограничивать, а Ада сама ограничивает», и будете конечно правы, но не ограничивает ли это адино ограничение заодно и ее саму?

Я про него. Вот скажите *p[10] — это взять десятый указатель и разименовать или взять указатель, разименовать и потом получить десятый элемент массива? А *p++ — сдвигает указатель или то, на что он ссылается? И так далее.


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

Ну вот потому что только Столманн уволился из MIT и спал где-то в подсобке — а ни у кого больше на это духу не хватило. А написать именно C он решил, потому что, если ещё не забыли GNU = Gnu is Not Unix.


Ну я же так и написал в предыдущем ответе, что, да, был Волосатый, была ГНУсятина, и Си шел на самом деле в комплекте. Ну так ведь… Есть же теперь уже готовый GNAT, все дела, где еще один Волосатый, где венчурные инвесторы, почему никто? Не может ли быть так, что проблемы Си волнуют лишь небольшую часть искренних энтузиастов, которые, впрочем, почему-то все равно никак не возьмутся нести всепобеждающие идеи Ады в массы?

Если у вас вариант A работает только со стандартным Pascal'ем, а вариант B — только с нестандартным… то что это за переносимость такая? Перепиши всё программу и живи спокойно?


Ну если так рассуждать, то да — любые нестандартные расширения не являются переносимыми. Жаль только, что почти все реализации почти всех языков наполнены нестандартными расширениями чуть более, чем наполовину.

Вот прям «при первой возможности»? Не знаю таких. На Visual C++ — да, пересаживались. Потому что всё, кроме Visual C++ не поддерживало новейшие технологии Windows. А Borland C++… где вы такие сведения нашли? У меня ощущение, что Delphi был тогда гораздо, гораздо популярнее.


Ну, во-первых в процитированной вами фразе речь шла про ТурбоПаскаль и ТурбоСи, еще до Дельфи и Билдера. Уже там была массовая пересадка. Во-вторых — ну хз, я знаю, о чем говорю, после всплеска популярности Дельфи (в наших краях это было в конце 90-х) довольно быстро все свернулось, один единственный из моих знакомых остался в Дельфи, все остальные переехали на Билдер (и ооочень долго на нем сидели потом). К слову сказать, Студия среди нашей тусовки тогда была мало популярна, кто-то почему-то ругал MFC, кому-то не нравилась тяжеловесность IDE, были даже такие, кто любил Борланд в пику «корпорации зла» (но это особенности возраста).

Не знаю где вы жили, что у вас Borland C++ for Windows был популярен… я был уверен, что таких мест в природе не существовало


Не в Москве )))

Просто C# намертво прибит гвоздями и прикручен шурупами к Windows


Во-первых это не совсем так, хотя конечно теоретическая возможность использовать все это под Линуксом мало что дает в не-ПК применениях. Во-вторых не думаете ли вы, что кровавый (который энтерпрайз) попросту сместил свой фокус на что-то такое, где C# вообще не нужен? Как, впрочем, и C/C++.

переключились на другой, более простой и понятный Windows-only язык: Visual Basic.NET


Этого я вообще не понимаю. Дело их конечно, но зачем? Чем он проще и понятнее? И вообще, любителям простоты и понятности нужно идти Си (это был сарказм).
И это опять вопрос к тому, что некоторые очень умные программисты любят играть с синтаксисом. А я вот не люблю, и в гробу видал запоминание порядка выполнения операций. Для большинства случаев я конечно его помню, но этим знанием я намеренно не пользуюсь, добавляя скобки для исключения непонимания кода кем бы то ни было.
Это просто уже мазохизм какой-то. Как можно «играться с синтаксисом», если он хорош? Ну возьмите тот же Pascal, который вы, вроде как, знаете. p^[10] против p[10]^ — тут нужно что-нибудь запоминать? И где тут «поиграться с синтаксисом»? А путанице LongInt(a*b) vs LongInt(a)*b где возникнуть?

И подняв бурю трёпа на тему того, что в Ada/Pascal нельзя передавать анонимные массивы в функции — вы даже не обратили внанимание на то, что если бы это было возможно и в моих примерах можно было вместо callbacks_array написать array(1..10) of access procedure — то это всё равно никаких проблем с разбором этого выражения не вызвало бы!

Это ж кем надо быть, чтобы буквально в двух соседних абзацах сначала утверждать что синтаксис в C — хорош, а потом обвинять программистов в том, что они «любят играть с синтаксисом». Если синтаксис языка хорош, то вы не сможете запутать человека в трёх-пяти строках! Если это сделать можно — то это и значит, что синтаксис ужасен! В Ada — синтаксис хорош и даже в Pascal он вполне неплох. А вот в C и Rust — он паршив и разные правила типа «не бойтесь использовать много скобочек» или «не забывайте про typedef» — это костыли, многочисленные подпорки, позволяющие сгладить его недостатки. Про C++ я вообще молчу — там есть много достоинств, но «понятный синтаксис» — это точно не про C++.

Есть же теперь уже готовый GNAT, все дела, где еще один Волосатый, где венчурные инвесторы, почему никто?
Почему никто? Есть Rust, есть D, есть, как вы уже упомянули Ada… но в этом-то и проблема, что есть много всего! А главное — уже есть C/C++ и миллиарды строк кода, на них написанные.

Ну я же так и написал в предыдущем ответе, что, да, был Волосатый, была ГНУсятина, и Си шел на самом деле в комплекте.
Вы упустили один важный, принципиальный, момент: важно было не то, что он нашёлся. А то, что он, такой, нашёлся один. Альтернативы не было. Примерно 4-5 лет (а это — большой срок) GCC был единственным приличным бесплатным компилятором. Потом — подтянулись и другие. Но долгие годы — он был единственный альтернативой. Под него даже компьютеры делали. И даже Стив Джобс при всей его спеси и нежелании использовать «чужое» — вокруг него свою операционку построил (хотя язык, как раз, NeXT сделал свой).

А сейчас — альтернатив, как грязи. Почему в 80е было много групп, продававших миллионы пластинок, а сейчас таких мегазвёзд нету? Да потому что такого фильтра, прессинга, позволявшего взлететь только единицам, больше нету! Сделал PSY прикольный ролик, выложил на YouTube — все протащились… и забыли. Никто не будет ждать его следующего сингла, не будет собирать деньги, чтобы полететь на его концерт в другую страну…

То же самое и с языками: новые языки и компиляторы появляются косяками. Пачками. Но «взлететь», набрать критическую массу — им всё сложнее и сложнее.

А при чем тут это в текущей ситуации? Вот кто мешает условному Цукербергу вложить условный миллиард в массовое насаждение Ады в IoT? При том, что это могло бы быть вполне даже окупаемое мероприятие.
С чего вы решили, что миллиарда хватит и что это будет окупаемым мероприятием? Последний язык (да, собственно, единственный язык) взлетевший таким образом — это Java была. Чтобы её «поднять» пришлось «спалить» целую компанию. Десятки тысяч человек на это работали — в результате Java взлетела, основной бизнес издох.

Неудивительно, что больше никто такой «успех» повторять не хочет.

Не может ли быть так, что проблемы Си волнуют лишь небольшую часть искренних энтузиастов, которые, впрочем, почему-то все равно никак не возьмутся нести всепобеждающие идеи Ады в массы?
Проблемы C волнуют, в общем-то, огромное количество людей. Как и проблемы Windows. Но ни то, ни другое, «в лоб» заменить не удастся. Просто потому что это, фактически, нужно будет целую новую, альтернативную индустрию, создать.

Ну если так рассуждать, то да — любые нестандартные расширения не являются переносимыми.
А как ещё, чёрт побери, рассуждать? Переносимость — это когда вы берёте программу и запускаете её где-то в другом месте. На другом процессоре, на другом компиляторе…

Жаль только, что почти все реализации почти всех языков наполнены нестандартными расширениями чуть более, чем наполовину.
Что вовсе не означает, что все программы и библиотеки намертво на эти расширения завязаны. В случае с C — можно сделать так, чтобы 99% кода была написана на простом ANSI C. И только в 1% было бы что-то специфическое для компилятора.

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

Ну, во-первых в процитированной вами фразе речь шла про ТурбоПаскаль и ТурбоСи, еще до Дельфи и Билдера. Уже там была массовая пересадка.
Ну и где она? Вот артефакты тех дней. Ну или тут. Где там залежи добра под Turbo C? Или даже на SimTel гляньте. Просто сравните хотя бы даже «на глаз» количество добра под Turbo Pascal и Turbo C.

Уже там была массовая пересадка.
Хде следы? Понимаете: я этой эпохи, массового пересаживания с Turbo Pascal на Turbo C (если таковая когда-то и была) — не застал. Для меня весь этот CP/M, DOS и прочее — это археология. Довольно увлекательная, но… археология. Я могу только лишь представить себе как вот всё это было.

И «культурные наслоения» несут в себе из 80х — массу артефактов Pascal'я. Вот массу. Начиная от MacOS (которая написана на Pascal — не путать с MacOS X), Excel (первая версия была точно на Pascal, хотя как Джоел пишет потом её переписали на C и оставили только P-code) и кончая массой других артефактов.

Там же — много добра на Basic'ах разнообразных. Потом — начинаются какие-то вкрапления Turbo C и Quick C… но их мало. На фоне Basic'а и Pascal — их вообще не слишком хорошо видно.

Дальше — интересная эпоха «взрыва C»: масса конкурирующих 32-битных компиляторов (GCC, High C, Watcom C, etc), однако Borland и Microsoft на этом «празднике жизни» отсутствуют. Равно как и Pascal (если кто-то что-то на 32-битных версиях Pascal'я и писал, то я таких артефактов не обнаружил).

А вот уже дальше — начинается эпоха Windows… и мощнейшие слои Visual Basic'а и Microsoft C. Borland очень быстро куда-то выпадает, Delphi ещё чуть-чуть можно найти, но C++Builder — артефактов почти не оставил за собой.

Вот такая картина складывается на основании раскопок. Если, как вы говорите, все перешли на Turbo C, как только смогли… то где оно, вот это вот всё? Куда артефакты девались?

Наоборот — складываеться впечатление, что переход с Pascal на C происходит вынуждено (ну вот не было 32-битных компиляторов Pascal под DOS в 90е… где-то уже в XXI веке они появились — но поезд уже ушёл), а вовсе не потому что кому-то вот конкретно C больше нравился.

Во-вторых не думаете ли вы, что кровавый (который энтерпрайз) попросту сместил свой фокус на что-то такое, где C# вообще не нужен?
«Кровавый энтерпрайз» как сидел на Java, так и сидит. Вообще Java — была «языком #1» почти весь XXI век. Сменила она, по слухам, Visual Basic (а вовсе не C и не Pascal) — но это было на рубеже веков, TIOBE так далеко статичтику не ведёт.

Этого я вообще не понимаю. Дело их конечно, но зачем? Чем он проще и понятнее? И вообще, любителям простоты и понятности нужно идти Си (это был сарказм).
Как я уже сказал — мало кто использует C, C++ или даже C# из-за их «простоты и понятности». У них много достоинств, но «простота и понятность» в их список не входят. Как и Rust, кстати.

Язык, который неплохо поднялся на «простоте и понятности» — это Python. Хотя есть подозрение, что это не качества языка, а хайп вокруг машинного обучения и TensorFlow.
Если синтаксис языка хорош, то вы не сможете запутать человека в трёх-пяти строках! Если это сделать можно — то это и значит, что синтаксис ужасен! В Ada — синтаксис хорош и даже в Pascal он вполне неплох. А вот в C и Rust — он паршив и разные правила типа «не бойтесь использовать много скобочек» или «не забывайте про typedef» — это костыли, многочисленные подпорки, позволяющие сгладить его недостатки.


В этом утверждении с вами трудно спорить, и тем не менее — синтаксис некоего такого «ограниченного Си» безупречен. В то время как Аду/Паскаль никакими ограничениями сделать лаконичными нельзя, да и расширениями — вряд ли.

Про C++ я вообще молчу — там есть много достоинств, но «понятный синтаксис» — это точно не про C++.


Горячо поддерживаю.

Почему в 80е было много групп, продававших миллионы пластинок, а сейчас таких мегазвёзд нету?


К слову — спорное утверждение. Новый альбом The Prodigy в прошлом году ждали очень многие, хотя уже давно не 80-е. Правда альбом оказался не очень, а потом и Кита Флинта не стало, но тем не менее.

То же самое и с языками: новые языки и компиляторы появляются косяками. Пачками. Но «взлететь», набрать критическую массу — им всё сложнее и сложнее.


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

С чего вы решили, что миллиарда хватит и что это будет окупаемым мероприятием? Последний язык (да, собственно, единственный язык) взлетевший таким образом — это Java была. Чтобы её «поднять» пришлось «спалить» целую компанию. Десятки тысяч человек на это работали — в результате Java взлетела, основной бизнес издох.


Я же написал — условный миллиард. И предположение насчет окупаемости было лишь предположением… или нет.

И почему вдруг единственный? Сишарп разве не был так же искусственно создан на частные инвестиции и успешно внедрен? И даже не убил никого.

Хде следы? Понимаете: я этой эпохи, массового пересаживания с Turbo Pascal на Turbo C (если таковая когда-то и была) — не застал. Для меня весь этот CP/M, DOS и прочее — это археология. Довольно увлекательная, но… археология. Я могу только лишь представить себе как вот всё это было.


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

Наоборот — складываеться впечатление, что переход с Pascal на C происходит вынуждено


Ну, ваш набор аргументов мне конечно крыть нечем, поскольку я принципиально не представляю, где бы мне найти такую куч софта на ТурбоСи, которая вас бы убедила.

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

Как я уже сказал — мало кто использует C, C++ или даже C# из-за их «простоты и понятности». У них много достоинств, но «простота и понятность» в их список не входят.


Если вам не нравится сравнение Паскаля и Си, то попробуйте ответить, почему взлетел Сишарп, причем хорошо так взлетел? Когда он только появился, то многие сказали «зачем он нужен, все то же самое можно делать на плюсах». И ведь можно, и ведь сколько легаси было! И тем не менее народ постепенно втянулся, потому что язык… ну, не в пример более внятный, чем современные плюсы. Я иного объяснения не вижу, потому что многие плюшки дотнета во-первых общие для всех языков, а во-вторых подтянулись позже. От «переносимости» же до сих пор отдачи не так много, хотя и есть. А пятнадцать лет назад у Сишарпа было ровно одно преимущество — внятность. То есть, как видите, популярность языка может зависеть не только от «политики».
В то время как Аду/Паскаль никакими ограничениями сделать лаконичными нельзя, да и расширениями — вряд ли.
Вы до сих пор программируете на C64? И у вас всё ещё 40 символов в строке?

Больше всего меня удивляют люди, сначала жалущиеся, что Pascal/Ada/etc многословны, а потом — вводящие кучу правил для того, чтобы «замечательный» синтаксис C хоть как-то читабелен был.

Я, например, несмотря на то, что 10 лет работаю с C и C++ (в основном впрочем, с последним) так и не могу с ним свыкнуться. Неудобен он. И нелогичен.

пятнадцать лет назад у Сишарпа было ровно одно преимущество — внятность.
Серьёзно? 15 лет назад… 2004й год. Ой — а это не тогда ли, когда Microsoft сказал мы ща новый мир построим… всем забыть про C++… у нас новый язык… новый API… новый прекрасный мир…

То есть, как видите, популярность языка может зависеть не только от «политики».
До-до-до, канечна-канечна. Когда все журналы трубят, конференции шумят, и все вокруг обсуждают, как нам жить «в светлом будущем, когда Win32 и C++ станет „пережитком прошлого“». Примерно так:
WinFX will replace Win32, which will be relegated to «legacy» platform status (just as Win32 relegated DOS/Win16). Developers should migrate their skills to .NET Framework managed code today to establish the experience and expertise needed to minimize problems in the eventual adoption of WinFX by 2008.
… это не политика? А что это?

Как раз 15 лет назад хайпа вокруг C# был «вагон и маленькая тележка». Borland в очередно раз вляпался: Delphi 8 была уже строго исключительно под .NET. Потому что WinFX же! Win32 скоро умрёт!

Потом, когда Microsoft со всеми своими WinFS и прочим обосрался разговоры про то, что «Win32 скоро конец» затихли… Delphi 2005 вернул поддержку Win32… ну и дальше, новые API начали быть доступными через «устаревший» C++…

Но нет, C# отнюдь не позиционировался как «классный язык для тех, кому интересно» — он очень аггрессивно продвигался как «полная и окончательная» замена C++. Просто когда стало понятно, что есть ненулевые шансы получить, вместо перехода на C#, полный отказ от Windows… Microsoft резко развернулся и начал петь другие песни: вначале о том, что «да, C# заменит C++… когда-нибудь… в светлом будущем», а потом и о «C# — как первый среди равных» (ну это уже после Windows Phone 7 фиаско — и сразу после этого C# начал достаточно быстро «сдуваться»).

И почему вдруг единственный? Сишарп разве не был так же искусственно создан на частные инвестиции и успешно внедрен?
Куда он был внедрён? Кто, кроме Windows-программистов на нём пишет? Это очередной «местный язычок для одной частной лавочки». Таких много. Objective C и Swift, C# и JavaScript, Visual Basic .NET и Delphi… не так сложно «вывести на орбиту» язык, привязанный к платформе.

Если платформа популярная — на нём будут писать, так или иначе. JavaScript — отличный пример. Более уродский язык — ещё поискать нужно. Брендан Айк чётко пишет: «I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.»

И что? На этом вот «silly little brother language» — написано масса всякого добра… потому что выбора нет: если ты хочешь, чтобы твоя программа работала в браузере — то обойти JS ты никак не сможешь.

Однако очень мало языков смогли получить популярность на нескольких платформах. В десятке на TIOBE это только «большая тройка» (Java/C/C++) и Python (хотя есть ощущение, что Python там тоже не «сам по себе», а как приложение к TensorFlow). Интересно будет увидеть что с ним будет, когда хайп вокруг нейросетей поутихнет…

И даже не убил никого.
Ну если не считать Windows Phone. Хотя есть шансы, что Windows Phone «утонул бы» и без C# — но тот факт, что Windows Phone 7 не поддерживал нативный код, а телефоны нельзя было обновить на Windows Phone 8 — несомненно сыграл очень большую роль в этой трагикомедии. Для сравнения: Android NDK вышел меньше, чем через год, после выхода HTC Dream и, разумеется, разработка под этот самый HTC Dream там поддерживалась.

Я конечно тоже не видел лично, на чем писали люди в 80-е, но работал с большим количеством немолодых уже людей, которые видели и сами в этом участвовали.
Ну тут, как бы, вполне возможен эффект «лицом к лицу лица не увидать». Например выходцам из стран СНГ сложно себе представить, что Norton Commander был сравним по популярности с XTree Gold… потому что «синие окошки Нортона» видели почти все, XTreeGold — почти никто… однако в мире — ситуация была иной… там ни NC, ни XTree никто особо не видел… недаром Symantec купил Peter Norton Computing, а не наоборот…

Собственно я говорил лишь о своих впечатлениях по памяти. Паскаль у всех был и оставался сугубо учебным языком, и написать на нем что-либо серьезное даже звучало как-то… странно.
Мне кажется, что это такой снобизм был: было «стыдно» признаться, что ты на «учебном языке» что-то такое большое и светлое делаешь. Но это всё уже было, я подозреваю, в эпоху «жизни после смерти» — когда выяснилось, что 7я версия — это таки всё, больше новых версий не будет… а C — открывал целый «дивный новый мир»: 32-битный DOS и разные всякие Windows и OS/2…
Вы до сих пор программируете на C64? И у вас всё ещё 40 символов в строке?


Нет, но для чтения много символов для простых действий — не очень удобно.

Возможно это просто профдеформация.

Серьёзно? 15 лет назад… 2004й год. Ой — а это не тогда ли, когда Microsoft сказал мы ща новый мир построим… всем забыть про C++… у нас новый язык… новый API… новый прекрасный мир…


Дадада, все так, обещали светлое будущее и т.д. Но ведь они не заставляли никого вот прямо завтра бросить в лаву вулкана все легаси MSVC. Люди переходили добровольно. Могли не переходить, в конце концов каждый сам выбирает, чьим обещаниям ему верить.

Но нет, C# отнюдь не позиционировался как «классный язык для тех, кому интересно» — он очень аггрессивно продвигался как «полная и окончательная» замена C++


Естественно, затем его и делали. Но, еще раз, все переходы совершались кустомерами добровольно. Возможно Майкрософт использовал при этой какой-то неконкурентный ресурс, ведь не просто так все те же самые люди задолго до того не перешли на Джаву, но в целом это было дело добровольное.

Куда он был внедрён? Кто, кроме Windows-программистов на нём пишет?


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

Ну тут, как бы, вполне возможен эффект «лицом к лицу лица не увидать»


Вполне возможно.

Мне кажется, что это такой снобизм был: было «стыдно» признаться, что ты на «учебном языке» что-то такое большое и светлое делаешь


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

Возможно это просто профдеформация.
Вопрос привычки. Самый популярный язык в мире (Java, да) умудряется соединять «лакончиность» линейки Algon/Pascal/Ada и «понятность» C… и ничего, пользуются.

Люди переходили добровольно
Когда им сказали «все новые фишки — только в C#»? Странное у вас понятие «добровольности». Или для вас «принудительно == когда пистолет к виску приставят», а всё остальное «добровольно»?

Могли не переходить, в конце концов каждый сам выбирает, чьим обещаниям ему верить.
Ну да, конечно. Когда весь ваш бизнес зависит от Microsoft «не верить их обещаниям» и надеяться, что «всё обойдётся»… особенно имея наглядный пример «заживо похороненного» Visual Basic'а и Visual FoxPro… И петиции писали и чуть ли не манифестации устраивали…

Нужно иметь вот реально «стальные яйца», чтобы после такой показетельной порки «тех, кто не понял» даже не думать о C#.

Возможно Майкрософт использовал при этой какой-то неконкурентный ресурс, ведь не просто так все те же самые люди задолго до того не перешли на Джаву
Они не перешли на Джаву ровно потому что Microsoft разосрался с Sun'ом, извините. И всем было объвлено, что «если вы хотите программировать под Windows — то никакой Java, вместо неё у нас C#».

но в целом это было дело добровольное.
Ещё раз: добровольно — это когда вам дают выбор. А когда выбора не дают, а ваших коллег — разработчиков на Visual Basic и Visual FoxPro показательно «выгоняют босиком на мороз»… с намёком «если не перейдёте на C# — завтра последуете их примеру»… это максимально далеко от добровольности. А что что они с Windows RT и Windows Phone 7 сделали… не помните? Вот там Microsoft, наконец, как и обещал, «закрутить гайки» по полной. Отказался от этой «чудесной идеи» только тогда, когда осознал, что может вместо повсеместного перехода на C# получить отказ от Windows…

Это неважно, он был внедрен. Этим не всякий язык похвастается.
Этом может похвататься всякий изык, на котором людей для популярной платформы обязывают писать. C# так и не взлетел как замена C++, но многие вещи в Microsoft-экосистеме вы иначе, как на C# писать было невозможно: игры в XBox store, программы для уже вышеупомянутого Windows Phone 7, плагины для Visual Studio и многое другое.

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

Это всё равно как сказать: QuakeC — безумно популярный язык в геймдеве (был одно время, по крайней мере), на нём столько всего написано! Ну да, конечно… а какие ещё варианты?
Или для вас «принудительно == когда пистолет к виску приставят», а всё остальное «добровольно»?


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

Когда им сказали «все новые фишки — только в C#»? Странное у вас понятие «добровольности».


Фраза про «все новые фишки» совершенно ничего не означает. Она не могла сама по себе заставить писавших на С++ перейти на Сишарп, если им «пока что всего хватает», а в перспективе можно любые новые «фишки» добавить для С++ (что и происходит совершенно независимо от Майкрософта).

Когда весь ваш бизнес зависит от Microsoft «не верить их обещаниям» и надеяться, что «всё обойдётся»… особенно имея наглядный пример «заживо похороненного» Visual Basic'а и Visual FoxPro


Аргумент засчитан, хотя Visual Basic и ФоксПро были фундаментально огорожены и не имели аналогов у других вендоров, если я не ошибаюсь. То есть немного иная ситуация.

если вы хотите программировать под Windows — то никакой Java


Очень классно это читать, имея на правом мониторе запущенный вод Виндой Эклипс )))

«если не перейдёте на C# — завтра последуете их примеру»


Не, ну правда, вы верите в то, что угрозы в сторону С++ были так же реальны, как угрозы в сторону Бейсика?

Этом может похвататься всякий изык, на котором людей для популярной платформы обязывают писать


Это тоже верно, но я не до конца согласен, что эта формулировка применима ко всем случаям перехода на Сишарп. Вотпрямщас куча моих коллег делает софт на Сишарпе, который вотпрямзавтра можно было бы без потери каких-либо возможностей переделать на С++. Но писать на Сишарпе им удобнее и приятнее, чем на С++ (правда без Эйгена дело не обходится, так что какое-то количество плюсОв у них все еще есть и долго будет).
Или для вас «принудительно == когда пистолет к виску приставят», а всё остальное «добровольно»?
Ну, вообще это общее такое определение, не только мое личное.
То есть в анкдоте про кота и горчицу вы считаете, что у Хрущева кот всё делал добровольно… ну интересная идея, да. Избави меня бог от подобной «добровольности»…

Она не могла сама по себе заставить писавших на С++ перейти на Сишарп, если им «пока что всего хватает»
Нельзя. Многие новые API были доступны только из C#. Так же, как сейчас в Android они доступны только из Java. В результате вы вынуждены писать программу на C#/Java. Хотя бы частично.

а в перспективе можно любые новые «фишки» добавить для С++
А вот это — случилось не 15 лет назад, а много позже. И 15 лет назад вообще не было очевидно — случится это или нет.

(что и происходит совершенно независимо от Майкрософта).
Ну да — расскажите как расширить функциональность Visual Studio с помощью модуля на C++ (как Visual Studio 6.0 расширялась), я послушаю.

Аргумент засчитан, хотя Visual Basic и ФоксПро были фундаментально огорожены и не имели аналогов у других вендоров, если я не ошибаюсь. То есть немного иная ситуация.
Ситуация иная — но не слишком. Планы по «изведению» Win32 обсуждались на полном серьёзе. То, что C/C++ имеется не только в Windows — действительно одна из причин того, что Microsoft не рискнул его удавить. Но в 2004м уверенности в том, что так и будет — не было.

если вы хотите программировать под Windows — то никакой Java
Очень классно это читать, имея на правом мониторе запущенный вод Виндой Эклипс )))
Eclipse — это чудесно. А как насчёт плагина для Visual Studio, всё-таки?

Кстати сегодня та же Visual Studio даже снова поддерживает Java (спасибо Android'у), но многие вещи программам на Java (не только возможности писать пресловутые плагины) по-прежнему недоступны.

Не, ну правда, вы верите в то, что угрозы в сторону С++ были так же реальны, как угрозы в сторону Бейсика?
Если бы план Гейтса-Баллмера удался и на сервере и сотовых телефонах Windows заняла бы те же 80-90%, что и на декстопе? Легко. Вспомните что они говорили в 2005. Да, планы были полностью заменить C/C++ на C# и заменить платформу полностью (собственно как я говорил Джоел ровно тогда все эти планы описывал). Но… «не шмогла я, не шмогла»…

Вотпрямщас куча моих коллег делает софт на Сишарпе, который вотпрямзавтра можно было бы без потери каких-либо возможностей переделать на С++.
Ну это уже второй вопрос: да, если вы заставите людей писать на каком-то языке, то его, иногда, будут использовать и добровольно… скажем в Android вы обязаны кое-то делать на Java (а кое-что обязаны делать на C++… класс), но в целом выбор между Java и C++ — довольно-таки произволен… и разные люди имеют разные предпочтения.

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

Самое сложное — заставить изучить его и хотя бы начать использовать.

И вот тут — основную роль играет принуждение… а вовсе не качества языка.
Многие новые API были доступны только из C#


Не знаю по правде говоря, о чем именно вы говорите. Если это были критичные апи, то тогда это конечно смахивает на технофашизм.

И 15 лет назад вообще не было очевидно — случится это или нет


Ну, ммм, разве логика исторического развития не подсказывала, что стандарт C++03 — лишь начало большого пути?

Ну да — расскажите как расширить функциональность Visual Studio с помощью модуля на C++


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

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


С этим не поспоришь.

Ну хорошо, допустим Сишарп на самом деле был ужасен (на самом деле нет), но его продавили. По-прежнему мучительно неясно, что мешает условному ARM Holdings на почти тех же условиях, но в контексте серьезной борьбы за рынок IoT среди прочего начать продвижение той же Ады? Допустим они сугубо корпорация зла и видят в этом только способ заработать. Делают свой компилятор «armac», он потенциально популярен вместе с Кейлом (до той пропорции, в которой популярен armcc). Нанимают для продвижения евангелистов (вроде вас), которые несут идею Ады в массы. Проплачивают сертификацию компилятора для спецприменений, ну и так далее. Дальше молодые разработчики, спропагандированные вами («Си ненадежен, Ада невероятна!»), огнем и мечом выжигают, например, IAR, который, например, не успеет за конкурентом (или пренебрежет, что вполне вероятно для этой конторы). Почему этот очевидный план не воплощается в жизнь? Наверное потому, что не только лишь все поддадутся на ваше убеждение?
Не знаю по правде говоря, о чем именно вы говорите. Если это были критичные апи, то тогда это конечно смахивает на технофашизм.
Ну как «критичные». Microsoft XNA, например. Либо заключай контракт на издание полноценной игры (а там речь идёт о весьма немалых суммах, которые нужно «вперёд» заплатить), либо $50 в год — но тогда только C# и Visual Basic.NET.

Ну, ммм, разве логика исторического развития не подсказывала, что стандарт C++03 — лишь начало большого пути?
Вот как раз C++03 и наводил на мысли, что C++ — это новый Cobol. Сколько новых фич появилось в C++03, по сравнению с C++98? Не знаете? Так я вам скажу: одна. Value initialization. Это — всё, что добавили в язык за пять лет. Ну и ошибки в документации поправили.

Но я ведь о других совершенно вещах говорил.
А от каких? В Visual Studio 6.0 вы пишите расширения на C++, в Visual Studio 2003 — уже только на C#. То же самое с MS Office (хотя там, вроде, «пересаживание на C#» случилось в 2007м) и многих других местах.

Полный отказ от C++ и переход на C# — да, не случился. Но об этом говорили как о неизбежности 15 лет назад. Не хватало только сроков.

Ну хорошо, допустим Сишарп на самом деле был ужасен
Он не был ужасен. Некоторый уровень качества для того, чтобы продвинуть технологию «в массы» всё же требуется. Даже Microsoft не сможет заставить разработчиков писать на Whitespace.

Делают свой компилятор «armac», он потенциально популярен вместе с Кейлом (до той пропорции, в которой популярен armcc).
Ну то есть он не слишком популярен.

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

Вот если ввести штрафы за ошибки в программах на уровне государств — тогда популярность языков типа Ada и Rust автоматически поднимется. А пока это всё касается только «спецприменений»… ну кому они интересны? 10% (или 1%?) людей, которые ими заняты?

Да, какую-то популярность для Ada можно было бы таким образом сделать… но зачем это ARM'у? Денег на этом не заработать… сделать так, чтобы люди перестали пользоваться clang'ом и gcc тоже не получится… тогда зачем?
Сколько новых фич появилось в C++03, по сравнению с C++98? Не знаете? Так я вам скажу: одна. Value initialization. Это — всё, что добавили в язык за пять лет. Ну и ошибки в документации поправили.


Да, я в курсе, что изменений было немного, и это как раз показатель внимания к языку! А не как у того же Си — «а, ну если никому ничего не надо, то посидим еще лет 15 на том же стандарте».

А от каких? В Visual Studio 6.0 вы пишите расширения на C++, в Visual Studio 2003 — уже только на C#. То же самое с MS Office (хотя там, вроде, «пересаживание на C#» случилось в 2007м) и многих других местах.


Ну блин, опять Студия, и теперь еще Офис в пример. Будто прям все разработчики делают плагины под Студию и Офис. Представьте себе, что вы пишете условный софт для постаматов. Сильно вас бьют эти проблемы? И таких ситуаций больше, чем «обоже, как мне написать плагин под Студию», причем к требованию писать плагины под Студию только на Сишарпе лично я отношусь с пониманием. Это совсем не то же самое, что заставить разработчиков Эклипса писать плагины только на Сишарпе.

Ну то есть он не слишком популярен


Это почему?

Вот если ввести штрафы за ошибки в программах на уровне государств — тогда популярность языков типа Ada и Rust автоматически поднимется


Или, что гораздо вероятнее, станет больше адептов у MISRA C и у других систем самоограничения. Как сейчас и имеем.
А не как у того же Си — «а, ну если никому ничего не надо, то посидим еще лет 15 на том же стандарте».
Какие 15? C11, как несложно догадаться, был выпущен в 2011м. И в нём было вполне себе не меньше фич, чем в C++03. Думаю в 2021м (или, может быть, в 2022м) выйдет следующий стандарт.

Будто прям все разработчики делают плагины под Студию и Офис.
Некоторые ещё OCX-конторы делали. Для того же Visual Basic'а. Им тоже пришлось на С# переучиваться.

Представьте себе, что вы пишете условный софт для постаматов.
А какой процент разработчиков под Windows пишет софт для постаматов? Есть подозрение, что гораздо меньше, чем «автоматизаторов» под тот же Office.

Это совсем не то же самое, что заставить разработчиков Эклипса писать плагины только на Сишарпе.
А в чём разница?

Ну то есть он не слишком популярен
Это почему?
Ну, например, потому что где-то 10 лет назад ARM перешла (как и Intel ранее) от упора на свой компилятор к поддержке GCC (а потом и Clang'а).

Ну нет у них возможности тягаться с «тяжеловесами» типа Apple и Google!

Или, что гораздо вероятнее, станет больше адептов у MISRA C и у других систем самоограничения. Как сейчас и имеем.
То, что мы имеем сейчас — оно от безвыходности. Ну не может маленькая часть индустрии позволить себе разработку своего инструмента, если большую часть подход «и так сойдёт» устраивает.

Если же требования будут наложены на всех — ситуация будет другой.
Какие 15? C11, как несложно догадаться, был выпущен в 2011м. И в нём было вполне себе не меньше фич, чем в C++03.


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

Думаю в 2021м (или, может быть, в 2022м) выйдет следующий стандарт


Ну то есть еще 11 лет в перспективе.

А какой процент разработчиков под Windows пишет софт для постаматов? Есть подозрение, что гораздо меньше, чем «автоматизаторов» под тот же Office.


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

А в чём разница?


Когда Майкрософт говорит «это наш инструмент, будьте добры с ним работать вот так» — это нормально. Вот если бы они сказали «все виндовые версии Эклипса должны быть написаны на Сишарпе, иначе мы там чего-нибудь намутим при запуске» — то это был бы былинный отказ.

Ну, например, потому что где-то 10 лет назад ARM перешла (как и Intel ранее) от упора на свой компилятор к поддержке GCC (а потом и Clang'а).


Э, нет, то, что для продвижения своих продуктов ARM поддержал деятельность по развитию GNU Toolchain, это никак не означает то, что они вдруг ощутили свой компилятор непопулярным. Даже сегодня, несмотря на действительно очень сильное улучшение бесплатного тулчейна, он по-прежнему страшно уныл вы сравнении с Кейлом+armcc и популярен только потому, что Кейл — платный. Собственно этой стандартная бизнес-схема — иметь нормальный коммерческий продукт и поддерживать комьюнити с их открытыми поделками, чтобы выглядеть хорошо. А так у них с armcc все в порядке, доля рынка есть и они могут вполне вывести и новый компилятор для хайпового языка.

Сугубо ИМХО конечно, но не от балды взятое.

Ну нет у них возможности тягаться с «тяжеловесами» типа Apple и Google!


А в чем они могли бы потягаться, я не понял?

То, что мы имеем сейчас — оно от безвыходности


Ну, стоп. Есть проблема, «малая часть индустрии» придумала для нее решение, если вдруг ВСЯ индустрия решит тоже «делать хорошо», то что их заставит не пойти по уже известному пути, а строить Новый Мир?
И фич в нем было больше (правда как-то они слабо зашли в массы, на мой скромный взгляд).
Вполне зашли. Вне Windows, конечно. Вплоть до написания транспилеров из C99/C11 в C89 для MSVC если, вдруг, проект таки нужно под Windows собрать.

Постаматы я для примера привел, на самом деле там и постаматы, и какие-то фундаментально огороженные торговые клиенты и клиенты баз данных, всякие утилиты для инженеров, и миллион прочего.
Ну ведь и клиентам баз данных нужно как-то в базы ходить? А ODBC мы, типа, хотим выбросить, у нас нонче ADO.NET и LINQ в моде — но надо перейти на С#, да.

И против этого — всего лишь плагины?
Плагины вот к этому вот «миллиону прочего», да. К постаматам их не пишут, а вот уже к каким-нибудь утилитам — легко. И если раньше их писали на VBA, то теперь — на VSTA.

Есть, конечно, и платформы со своими собственными языками (пресловутая 1C), но их относительно немного…

Вот если бы они сказали «все виндовые версии Эклипса должны быть написаны на Сишарпе, иначе мы там чего-нибудь намутим при запуске»
Ну — они хотели это сделать. Или вы думаете Singularity они «замутили» просто от «нефиг делать»?

— то это был бы былинный отказ.
В конечном итоге так и случилось. Но 15 лет назад, когда предполагалось, что «переход на Windows NT» будет повторён (только в этот раз уже Win32 будет играть роль DOS API, а Avalon и прочие вещи поверх CLR — будут «новым Win32») — это было совершенно неочевидно.

Даже сегодня, несмотря на действительно очень сильное улучшение бесплатного тулчейна, он по-прежнему страшно уныл вы сравнении с Кейлом+armcc и популярен только потому, что Кейл — платный.
Совершенно не поэтому. А потому, что никто не будет возиться с исправлением багов в каком-нибудь Eigenе, которые не воспроизводятся на популярных компиляторах. Clang/GCC/MSVC (причём последний — не всегда) работают? Достаточно. Хотите, чтобы у вас на ICC или ARMCC что-то заработало? Ну берите вот нам исходники, разбирайтесь…

Intel даже приплачивать пытался тем, кто пользуется ICC — всё равно не пошло.

А так у них с armcc все в порядке, доля рынка есть и они могут вполне вывести и новый компилятор для хайпового языка.
Статистика есть? Или опять как с Borland C++ Builder'ом?

Я сам, лично, видел как люди переходили с armcc на clang или gcc (устав бороться с совместимостью и наплевав на те несколько процентов производительности, которые они теряют) и ни разу не видел обратного. В большинстве случаев просто дропается платформа с кучей костылей, построенная вокруг Keil, и берётся новый SOC, заточенный уже под Android — после чего о Keil забывается, как о страшном сне.

А в чем они могли бы потягаться, я не понял?
А вот в поддрежке компиляторов, собственно…

Есть проблема, «малая часть индустрии» придумала для нее решение, если вдруг ВСЯ индустрия решит тоже «делать хорошо», то что их заставит не пойти по уже известному пути, а строить Новый Мир?
Потому что на строительстве Нового Мира можно поднять хайпа? Почему OPIE/GPE/Maemo/MeeGo, построенные на «решениях, придуманный малой частью индустрии» — не взлетели, а Android — взлетел?
Вполне зашли


Ну, я вообще не ПК имел в виду.

Ну ведь и клиентам баз данных нужно как-то в базы ходить? А ODBC мы, типа, хотим выбросить, у нас нонче ADO.NET и LINQ в моде — но надо перейти на С#, да.


Чорд, у вас на любое замечание есть контраргумент…

А не надо ODBC выкидывать, все с ним хорошо было. Кстати, будучи хозяевами одного из самых популярных SQL-серверов, они могли много чего еще напакостить.

Плагины вот к этому вот «миллиону прочего», да. К постаматам их не пишут, а вот уже к каким-нибудь утилитам — легко.


А, так вы не про плагины к Офису и Студии, а про плагины к сторонним приложениям?

Или вы думаете Singularity они «замутили» просто от «нефиг делать»?


Имхую, что да. Если бы они когда-нибудь все-таки сказали всему миру «чмоки всем старым ABI/API, мы тут решили подорвать фундамент», то… не то уже время было, нельзя было так все бросить, тем более что для юзверя это уже значило бы не так много, как переход от ДОС к Винде.

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


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

Intel даже приплачивать пытался тем, кто пользуется ICC — всё равно не пошло


Неправда. Разнообразный расчетно-моделирующий софт (который и у нас в стране внезапно пишется, и внезапно даже во многом силами всяких разных ИПМов) требует того компилятора, который быстрее, и тут ICC на интеловских процессорах заруливает по полной. Это конечно не самая широкая отрасль, но тем не менее — когда людям нужна максимальная производительность в имеющихся условиях, они идут в ICC (повторюсь — когда идут интенсивные вычисления на Зионах).

В большинстве случаев просто дропается платформа с кучей костылей, построенная вокруг Keil, и берётся новый SOC, заточенный уже под Android — после чего о Keil забывается, как о страшном сне.


Если берется Андроид, то это уже немного не эмбед, там переиспользуется такой объем кода, что лучше пожертвовать удобством. Я, повторюсь, говорил немного про другую область применения, где гнуевый тулчейн не конкурент Keil+armcc.

Потому что на строительстве Нового Мира можно поднять хайпа?


Это непоследовательно. Выше вы говорили, что никаким хайпом (потенциально монетизируемым) не соблазнить условный Фейсбук заняться продвижением Надежного Программирования. Теперь вдруг предполагается, что при наличии жестких требований регуляторов вся отрасль в дружном порыве (то есть никто конкретно) на волне хайпа массово ширнется Адой? Вместо того, чтобы просто взять уже имеющиеся «правила» и просто начать массово их использовать.

Почему OPIE/GPE/Maemo/MeeGo, построенные на «решениях, придуманный малой частью индустрии» — не взлетели, а Android — взлетел?


Понятия не имею. Как и не вижу, что их пример доказывает в нашем обсуждении.
Чорд, у вас на любое замечание есть контраргумент…
Это не у меня — это у Microsoft. Они реально планировали сменить платформу ещё раз. Когда Джоел пишет
Microsoft выросла, обзаведясь большим количеством программистов, которые увлекшись доходами с обновлений, внезапно решили, что перепрограммировать все – не очень большой проект. Черт побери, мы можем сделать это дважды!
… вы знаете — он ведь не шутит. C# был призван не дополнить C++, а заменить его. Полностью. Ну Ok, технически на CLR не только C# ходит… но классический C++ там не ходит — и его в этом «новом мире» не предполагалось иметь в принципе.

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

Если бы они когда-нибудь все-таки сказали всему миру «чмоки всем старым ABI/API, мы тут решили подорвать фундамент», то… не то уже время было, нельзя было так все бросить, тем более что для юзверя это уже значило бы не так много, как переход от ДОС к Винде.
Ну это сейчас так можно говорить из 2019го. А на рубеже веков, когда Microsoft как раз завершил перход с MS DOS на Windows NT (через промежуточную плослойку Windows 9X, да) — это вовсе не казалось невозможным.

Я недаром на статью Джоела так активно ссылаюсь: она, примерно, как раз до катастрофы вышла, когда эти планы уже начинали подвергаться сомнению — но ещё не были свёрнуты.

Конечно там, в конце, упоминается, чем всё кончилось: вместо того, чтобы ждать появления «дивного нового мира» люди перешли в Web… а потом былы проблемы с Longhorn… а потом катасрофа с Windows Phone… в конце-концов отказ от Win32 свернули. Но то, что на рубеже веков эти планы вполне были и C# продвигался как замена C++ в «дивном новом мире», а не его дополнение… мне странно, что вы на всё это не обратили внимания…

Этот аргумент важен далеко не для всех разработчиков, поскольку далеко не все библиотеки так плохо сделаны
Это не «плохо сделаны». Eigen, как раз, очень неплохо сделан. Просто на armcc им плевать. Вот реально плевать. И я вас уверяю: библиотек, разработчиков которых наплевать на armcc на порядок (а то и на два) больше, чем тех, кому это интересно.

А если вам не нужна быстрая математика, не нужны кодеки, не нужны свёртки, не нужно вот это вот всё — то зачем вам, собственно, «более качественный компилятор»? Байты из одного GPIO в другой пересылать? С этим и программа, скомпилированная GCC, справится.

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

Это конечно не самая широкая отрасль, но тем не менее — когда людям нужна максимальная производительность в имеющихся условиях, они идут в ICC (повторюсь — когда идут интенсивные вычисления на Зионах).
А вот когда люди играют не в максмимальную производительность, а считают деньги — нет.

Я видел попытку Intel «продать» ICC в Google. Не взлетело. Да, работает быстрее. Но даже с учётом того, что стоимость миллионов компьютеров — это, в общем, не копейки… оказалось дешевле купить их на 10% больше, чем бороться с ошибками ICC (у GCC ошибки тоже есть, но специально бороться с ними особо не нужно, так как разработчики программ и библиотек про них, в общем, знают и всё правят).

Да, на HPC кластерах, где кода мало, а скорость важна — ICC иногда используют. А вот есть чуть выйти за эту нишу — уже нет.

Я, повторюсь, говорил немного про другую область применения, где гнуевый тулчейн не конкурент Keil+armcc.
Не знаю про какую область применения вы говорите, но так ли она велика? Снизу у нас GCC-AVG, сверху — Android Platform (не обязательно полный Android, достаточно того, чтобы SOC под него изначально затачивался). Так ли много между ними остаётся?

Так-то можно обсуждаемую нишу сузить до того, что у вас вообще одна компания в ней останется — и не удивлюсь если конкретно там вообще только armcc и используется…

Выше вы говорили, что никаким хайпом (потенциально монетизируемым) не соблазнить условный Фейсбук заняться продвижением Надежного Программирования.
Совершенно верно. Потому что «Надежное Программирование» не монетизируется. Если вам удаётся заставить оплачивать ваши ошибки кого-то другого — то это дешевле, чем когда за них будете платить вы.

Теперь вдруг предполагается, что при наличии жестких требований регуляторов вся отрасль в дружном порыве (то есть никто конкретно) на волне хайпа массово ширнется Адой?
Ну зачем же Адой. Всё будет зависеть от времени, когда и если это случится. Если вот «прям завтра» — то я, скорее, ставил бы на Rust.

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

Почему OPIE/GPE/Maemo/MeeGo, построенные на «решениях, придуманный малой частью индустрии» — не взлетели, а Android — взлетел?
Понятия не имею. Как и не вижу, что их пример доказывает в нашем обсуждении.
Пример показывает, что вы не можете вот просто взять подход одной индустрии и перенести его в другую. Библиотеки, какие-то инструменты — возможно. Но не подход в целом.

Вот как вы себе представляете постепенный переход Android или Windows на MISRA? С сохранением совместимости? Я вот — никак не представляю. В принципе. А вот переход на Ada (или, что вероятнее, Rust) — вполне.
Конечно там, в конце, упоминается, чем всё кончилось: вместо того, чтобы ждать появления «дивного нового мира» люди перешли в Web… а потом былы проблемы с Longhorn… а потом катасрофа с Windows Phone… в конце-концов отказ от Win32 свернули. Но то, что на рубеже веков эти планы вполне были и C# продвигался как замена C++ в «дивном новом мире», а не его дополнение… мне странно, что вы на всё это не обратили внимания…


Мне просто кажется, что вы (и Спольски) оба слегка преувеличиваете потенциальные события. Не думаю, что руководство Майкрософт реально надеялось так легко поменять ВСЁ, история показывает, что там не дураки. Повторюсь — переход с ДОС на Винду был обоснован логикой исторического развития, а вот переход с Win32 на ту же «Сингулярность», например, представляет собой примерно того же масштаба «улучшение», как и ваша идея со всеобщей паскализацией населения. То есть оно может и хорошо было бы, но не совсем понятно, зачем столько боли.

Eigen, как раз, очень неплохо сделан. Просто на armcc им плевать.


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

зачем вам, собственно, «более качественный компилятор»


У Кейла не компилятор более качественный, а среда более вменяемая.

А что с ней не так?


А что там вообще так? Ну вот приведите пример чего-то, что хорошо работает, например, в Atollic TrueStudio.

Не знаю про какую область применения вы говорите, но так ли она велика?


Я говорю про MCU и bare metal, какой там Андроид?

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


Естественно. Но мы же об эмбеде говорили с самого начала? Откуда вдруг десктоп?

Вот как вы себе представляете постепенный переход Android или Windows на MISRA? С сохранением совместимости? Я вот — никак не представляю. В принципе. А вот переход на Ada (или, что вероятнее, Rust) — вполне.


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

Не думаю, что руководство Майкрософт реально надеялось так легко поменять ВСЁ
Нет, конечно, процесс много лет занял. Вначале планировалось всё сделать на основе Java, когда Sun не дал — сделали свою версию с блекджеком и поэтессами.

Повторюсь — переход с ДОС на Винду был обоснован логикой исторического развития, а вот переход с Win32 на ту же «Сингулярность», например, представляет собой примерно того же масштаба «улучшение», как и ваша идея со всеобщей паскализацией населения.
Те менее IBM смог пересадть пользователей IBM/34 и IBM/36 на AS/400 и осущесвить «паскализацию населения»… а чем Microsoft хуже?

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

А «руководители Microsoft» смотрели на это с позиций 70х-80х, когда платформы, разработка для которых не позволяет кодировать в машинных кодах, были нормой. Какие-нибудь классические HP 9100A или TI-99, MK-52 и ИСКРА 226… всё эти пересональные компьютеры не позволяли писать программы в машинном коде.

Да что там далко ходить: для IBM PC изначально предлагались три операционки, на выбор: CP/M-86, IBM PC DOS и UCSD p-System. Причём из этих трёх «настоящей» (и самой дорогой) считалась как раз UCSD p-System — потому что только она полностью изолировала разработчика от железа. А IBM DOS — считалась (да и являлась в версии 1.x) «загрушкой для сокета», копеешной поделкой, котороую можно было купить разве что от нехватки денег.

Правда то, что она стоила почти в десять раз (!) дешевле «настоящих» OS сыграло с ними злую роль… но как раз для руководства Microsoft переход от Win32 к Singularity не казался чем-то странным или, тем более, невыполнимым: как переход к Win32 отбирает у программиста доступ «к железу» и отдаёт контроль над этим важным разделяемым ресурсом OS — так и Singularity отбирает у программиста права свободно распоряжаться адресным пространством и отдаёт его на управление OS.

Это считалось логичным и разумным промежуточным шагом к созданию надёжной Capability-based OS… но не срослось. Обратите внимание, кстати, кто там в списке на последнем месте стоит…

То есть оно может и хорошо было бы, но не совсем понятно, зачем столько боли.
Как раз понятно: для надёжности и безопасности. В современных системах программы — это огромные монстры, внутри которых нет никакой защиты отдельных модулей (отсюда, кстати, решение зайти к продвижению C# через плагины). Решение, разрабатывавшееся ещё Intel в 1975 году — это capabilities. А для них — требуется либо полный переход на управляемый код, либо аппаратная поддержка.

Забавно что IBM реализовала сразу оба варинта: один — в AS/400, другой — IBM/370.

Вот это — и считали руководители Microsoft «настоящими программно-аппаратными системами» (на которых, в частности, их бухгалтерия тогда работала — надёжности NT они не доверяли, ага).

А вся история с iAPX 86 и IBM 5150 — воспринималась ими как «вышедшая из под контроля аберрация».

Это как с IPv4 и Винт Серфом: В 1970-х, когда было необходимо утвердить объем, доступный для определения пространства имен, я сказал, что 128 бит – это слишком много. 32 бита позволяли выделить около четырех миллиардов имен, и я посчитал, что для научного эксперимента такого количества более чем достаточно. Проблема в том, что этот эксперимент так и не закончился. Представляете, насколько сложно было бы донести это до начальства 40 лет назад?

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

Ну да, то есть когда библиотека под разными компиляторами работает как хочет — это хорошая либа, ага.
Она не «работает как хочет». Она работает на любом «100% совместимом C++14-совместимом компиляторе» — но имеет кой-какие заточки под Clang и GCC. Ну кто ж виноват, что armcc не на 100% C++14 поддерживает?

У Кейла не компилятор более качественный, а среда более вменяемая.
А. Ну это вообще мало интересно. Среда для меня — это Sublime + компилятор.

Ну вот приведите пример чего-то, что хорошо работает, например, в Atollic TrueStudio.
Понятия не имею. С моей точки зрения если Atollic TrueStudio не работает нормально с Clang/GCC — то это проблема Atollic TrueStudio, а не GCC. Все необходимые интерфейсы GCC предоставляет. Clang предоставляет ещё больше.

Я говорю про MCU и bare metal, какой там Андроид?
Простой такой. Под который железо, собственно, затачивают.

Естественно. Но мы же об эмбеде говорили с самого начала? Откуда вдруг десктоп?
Мы говорили о гипотетической ситуации слияния «safety cricital development»а с обычным програмированием. Неважно — из-за принятия законов или потому, что вдруг «общество созрело».

В этом случае разработка для этих двух ниш имеет шанс объединиться. И тут возможны два пути:
1. Все наработки более узкого рынка тупо выкидываются и используются наработки для более шырокого рыка (то есть тежнологии, разработанные под мобильники и десктоп пойдут на embedded рынок).
2. Что-то, что создано для нишевого рынка окажется достаточно хорошим, чтобы заменить собой разработку с «большого» рынка (так Linux попал на мобильники)

Если разработак под эмбед, декстоп, и автомобильные системы станут совместимыми по набору требований — то преимущества в объёме рынка у MISRA С точно не будет. Но и уникальных наработок, которые можно взять и использовать — там тоже нет!

То есть в лучшем случае получим то, что с мобильниками: в смартфонах, как известно, есть отдельное ядро, куда засунуты десятилетия работы телеком-индустрии. Его задача — передавать байты через эфир. Все остальные функции — ему недоступны.

И если что-то большое, заведомо не эмбед, например ядро Линукса, написано на Си, то соблюдение этих правил конечно вызовет огромную боль при его переписывании (ну и некоторые правила в принципе выполнить будет невозможно), но все же это проще, чем все переводить на Раст.
Linux — это тоже эбед, хотите вы этого или нет. Хотя и другой. Но мы сейчас о MISRA C vs Rust…

Принципиальной разницей между Ada и MISRA C с одной стороны и Rust, с другой стороны, является одно правило «All project’s code including used libraries (including standard and userdefined libraries) and any third-party user code shall conform to the MISRA C Coding Guidelines.»

И дело даже не в правиле, а в отношении к нему. MISRA C сообщество не примет Linux kernel до тех пор, пока его полностью не приведут в соотвествие к стандарту… а кто будет это делать? Люди извне? Им это нафиг не надо. Люди изнутри? А им это зачем — вбухать тысячи человеко-лет в проект из которого неизвестно — выйдет что-то или нет?

Напротив — Rust преднаначен для постепенной замены C/C++ модулей на Rust-модули. В конце-концов освновной и, пока что, самый большой проект на Rust, Firefox — именно так устроен.

Что позволяет переписать ядро Linux на Rust, при желании… а вот на MISRA C — не позволяет.

У меня есть знакомый эсперантист, который уже, наверное, лет 20 зудит под ухом на тему что как круто было бы, если бы все выучили Эсперанто и могли бы говорить друг с другом. Я его спрашиваю: если я выучу Эсперанто — это мне поможет купить еды в Испании или Германии? Ну или, вообще, хоть где-нибудь? Ответы обычно пространные, но сводится всё к тому, что нужно, чтобы все перешли на Эсперанто — и тогда станет «клёво». После чего я и отвечаю: «ну когда все перейдут — и я перейду», за что неизменно получаю «взгляд ненависти».

Любой переход из точки A в точку B, в нашем мире, происходит поэтапно. Проекты, где нужно потратить 10-20, ну 100 — от силы, человеко-лет до получения первого практического результата ещё осущесствимы… а вот больше — нет. Ну может особо большая компания может 1000 человеко-лет в какой-нибудь очень большой проект «влить». Но это — предел…
Те менее IBM смог пересадть пользователей IBM/34 и IBM/36 на AS/400 и осущесвить «паскализацию населения»… а чем Microsoft хуже?


Ну, это пример 80-х. Тогда уже пеклись о совместимости, но еще не боялись «взять и все переделать» (а десятью годами ранее это вообще было в порядке вещей). Чего говорить — в те же годы люди спокойно брали и переписывали весь код под i860, хотя он, мягко говоря, сильно отличался даже по способу программирования (по крайней мере участники событий описывают это как новый экспириенс, хотя они не были новичками в программировании). Все ради производительности, и «чтобы не быть в хвосте прогресса». Уже в середине 90-х ситуация выглядела немного иначе.

с позиций 70х-80х, когда платформы, разработка для которых не позволяет кодировать в машинных кодах, были нормой


Угу, а также в порядке вещей были платформы, для которых можно было кодить ТОЛЬКО в машинных кодах. То есть не вполне понятно, что заставляло их думать в рамках только одной парадигмы. Впрочем важно даже не это, читаем дальше.

как переход к Win32 отбирает у программиста доступ «к железу» и отдаёт контроль над этим важным разделяемым ресурсом OS — так и Singularity отбирает у программиста права свободно распоряжаться адресным пространством и отдаёт его на управление OS.


И вот тут-то дело внезапно не в уровнях абстракции ни разу, а в потере совместимости — только и всего. И это «только» очевидным образом убивало все. Условная софтина под ДОС, не работающая с железом (либо если железо можно было как-то эмулировать) могла потом работать и в винде. Условная софтина под Вин32, запущенная в ОС типа «Сингулярности» внезапно не запустилась бы «как есть», а в эмуляторе она работала бы… как в эмуляторе. Вот и вся разница между этими «очень похожими» примерами.

Как раз понятно: для надёжности и безопасности


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

А вся история с iAPX 86 и IBM 5150 — воспринималась ими как «вышедшая из под контроля аберрация».


Ну еще раз, при чем тут 80-е? Кто из Майкрософта в начале 2000-х мог рассуждать категориями «а вот в System 370 было иначе, вот это была настоящая система»?

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


Ну это, знаете, тоже популизм. Майкрософт чего-то там не смог, а мы теперь говорим, что «вот если бы смог, то наступил бы рай земной». А если бы просто получилось очередное гуано? Как обычно и получается.

Она не «работает как хочет». Она работает на любом «100% совместимом C++14-совместимом компиляторе» — но имеет кой-какие заточки под Clang и GCC. Ну кто ж виноват, что armcc не на 100% C++14 поддерживает?


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

Ну это вообще мало интересно. Среда для меня — это Sublime + компилятор.


Ну, тут на вкус и цвет. Опять же чего-то в вашем тулчейне моет не оказаться.

Понятия не имею. С моей точки зрения если Atollic TrueStudio не работает нормально с Clang/GCC — то это проблема Atollic TrueStudio, а не GCC


Да там другое все работает через пень колоду… Хотя не только другое по всей видимости. Когда компилятор не видит макроопределение, которое двумя строчками выше — я хз, кого в этом винить, Атоллик или гцц. Разбираться тогда было неохота, тем более что можно было обойтись, но в целом я охарактеризовал это обычным своим нытьем «опять у комьюнити все через Ж». И попробуй это нытье оспорить.

Простой такой. Под который железо, собственно, затачивают.


Еще раз — никаких Андроидов.

Мы говорили о гипотетической ситуации слияния «safety cricital development»а с обычным програмированием. Неважно — из-за принятия законов или потому, что вдруг «общество созрело».


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

Что позволяет переписать ядро Linux на Rust, при желании… а вот на MISRA C — не позволяет.


С приведенными в этом блоке аргументами не согласен. Переписать с Си на Си все же проще, чем с Си на Раст, а обозначенная возможность постепенного переписывания ничего нового не дает в контексте перехода к «безопасному программированию» — пока вы ВСЕ не перепишете, у вас и не будет этого программирования. Так не все ли равно, в каком порядке это делать?

Любой переход из точки A в точку B, в нашем мире, происходит поэтапно


Может тогда мы можем сделать следующее исключение — переписывать Линукс на Мисру поэтапно и говорить «ну вот смотрите, вот эта библиотека уже норм»? Правила Мисры ведь можно и слегка дополнить по такому случаю.

Другое дело, в этом вы правы, что сообщество само не захочет этого. Анмасс куда интереснее взять «стильный, модный молодежный» язык (например Раст) и заделать на нем очередное гуано.

UPD: By the way, кто и зачем вас так стабильно минусует в этом топике?
Условная софтина под ДОС, не работающая с железом (либо если железо можно было как-то эмулировать) могла потом работать и в винде.
А вы пробовали? Огромное количество софта под DOS в Windows NT (всех версий) либо не работают вообще, либо работают очень плохо. Win16 программы — работают неплохо, да.

Потому и потребовался промежуточный переход через Windows 9X… а уже в XXI веке — поддержку DOS выпилили окончательно… как и Win16, кстати…

Условная софтина под Вин32, запущенная в ОС типа «Сингулярности» внезапно не запустилась бы «как есть», а в эмуляторе она работала бы… как в эмуляторе.
Ну то есть так, как работают DOS-программы в Windows сегодня.

Вот и вся разница между этими «очень похожими» примерами.
Ну то есть никакой принципиальной разницы таки нету?

Вы вообще — в курсе, что в Windows x64 программы для DOS и Win16 не работают? Или сейчас будете рассказывать сказки о том, что только что об этом узнали?

Кто из Майкрософта в начале 2000-х мог рассуждать категориями «а вот в System 370 было иначе, вот это была настоящая система»?
Билл Гейтс, хотя бы. Он-то с мэйнфреймов начинал. И Бейсик свой присал на эмуляторе, если вы не в курсе.

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

Разумеется в таком мире заботится о надёжности и безопасности — по меньшей мере странно. А то что Singularity «не взлетела» — это так, мелкий «side effect».

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

Как пример:
template<typename T, typename U,
         bool NeedToTranspose =
            (int(T::RowsAtCompileTime) == 1 && 
// FIXME | instead of || to please GCC 4.4.0
// stupid warning "suggest parentheses around &&".
// revert to || as soon as not needed anymore.
              int(U::ColsAtCompileTime) == 1) |
             (int(T::ColsAtCompileTime) == 1 &&
              int(U::RowsAtCompileTime) == 1)
>
...
Как несложно заметить — выражение и с || и с | будет делать одно и то же. Однако GCC на «более естественную» версию ругается — потому ради него сделали некоторую странность… а для armcc такого никто делать не будет.

И попробуй это нытье оспорить.
Легко. Операционки, основанные на этом «комьюнити», стоящие на миллардах устройств и поддерживающие миллионы приложений — известны. Подобных же на Keil — не наблюдается.

Не вполне понятно, почему вдруг там должно сформироваться общее поле или общая платформа с ПК
А почему нет? Софт для мобил — тоже когда-то был «своей особой поляной». Всякие Java ME и прочее. Ну и где оно это всё?

Использовать общую среду — просто удобнее. Вопрос только в том — окажется ли ваша платформа достаточно мощной, чтобы использовать соответствующие инструменты или нет.

Когда-то и C казался в эмбеде экзотикой и считалось, что ассемблер — это «наше всё».

Почему вы считаете что на C всё остановится?

пока вы ВСЕ не перепишете, у вас и не будет этого программирования.
Однако у вас будет меньше ошибок, меньше утечек данных и меньше крешей. В этом ведь цель, а не в том, чтобы галочку где-то в отчёте поставить.

Так не все ли равно, в каком порядке это делать?
Нет, не всё равно. Очень сильно не всё равно.

Пример мы тут разбирали вот буквально несколькими абзацами выше: современные версии Windows ни программы под DOS, ни программы под Windows 3.1 не поддерживают (иначе как в эмуляторе) — и люди отлично ими пользуются. А что было бы, если бы вместо Windows 95 вышла Windows NT, которая поддерживала бы только Win32?

Я думаю сегодня мы пользовались бы какой-нибудь другой OS…

UPD: By the way, кто и зачем вас так стабильно минусует в этом топике?
Я-то откуда знаю?
А вы пробовали? Огромное количество софта под DOS в Windows NT (всех версий) либо не работают вообще, либо работают очень плохо.


Пробовал. Массу разных старых игрушек, какие-то as is, какие-то через эмуляторы. Давно было, еще под ХР.

Ну то есть так, как работают DOS-программы в Windows сегодня.


Когда ДОС-программы работают в эмуляторе, то от них никто ничего особенного не ждет (работают они между тем неплохо). А вот от «тяжелых» и неоднозначно спроектированных Win32-программ вряд ли бы кто-то ждал работы «как в эмуляторе».

Вы вообще — в курсе, что в Windows x64 программы для DOS и Win16 не работают? Или сейчас будете рассказывать сказки о том, что только что об этом узнали?


В курсе. Но что это доказывает, я не понял?

Билл Гейтс, хотя бы. Он-то с мэйнфреймов начинал. И Бейсик свой присал на эмуляторе, если вы не в курсе.


Угу, а я вот в детстве думал, что телефоны бывают только проводными. А вот дожил до чего… Времена и люди меняются, не находите?

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


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

Когда-то и C казался в эмбеде экзотикой и считалось, что ассемблер — это «наше всё». Почему вы считаете что на C всё остановится?


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

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

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


Тут вы правы конечно, хотя без «галочки» дело тоже не обойдется. Иначе грош цена такому «безопасному» программированию.
Вы вообще — в курсе, что в Windows x64 программы для DOS и Win16 не работают? Или сейчас будете рассказывать сказки о том, что только что об этом узнали?
В курсе. Но что это доказывает, я не понял?
Что один раз отказ от старых технологий сработал — почему бы ему не сработать ещё раз?

Когда ДОС-программы работают в эмуляторе, то от них никто ничего особенного не ждет (работают они между тем неплохо). А вот от «тяжелых» и неоднозначно спроектированных Win32-программ вряд ли бы кто-то ждал работы «как в эмуляторе».
Ну в 97м или 98м и от DOS программ никто не ожидал от «тяжёлых» программ, что они будут «как в эмуляторе» работать. Собственно Windows 1.x и 2.x мало кто пользовался именно потому, что там старые программы плохо работали.

Такой же план был и тут: создать новый «managed» мир, перевести всех пользователей туда — а уже лет через 5-10, когда других программ не будет писаться… сказать что «всё — теперь Win32 программы будут работать только в эмуляторе».

Не сложилось… но идея была именно в этом. Кстати отказались от неё весьма поздно: Windows 8 была последней попыткой эту идеё продавить-таки. Но массовое неприятие пресловутого интерфейса наконец-то положило крест этой затее.

И да, пожалуйста, на надо мне тут же примеров подключения подсветки аквариума к малинке, я говорю просто о пульте, простом китайском пульте из магазина.
Можно примерно прикинуть когда простой китайский пульт из магазина обзаведётся Linux'ом.

Угу, а я вот в детстве думал, что телефоны бывают только проводными. А вот дожил до чего… Времена и люди меняются, не находите?
Ну если вы застали времена до DECT (это 80е), то могли бы и вспомнить, что в те времена мейнфреймы (на которых, вообще-то многозадачная OS ходила) обладали меньшими ресурсами, чем этот самый китайский пульт сегодня.

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

Тут вы правы конечно, хотя без «галочки» дело тоже не обойдется. Иначе грош цена такому «безопасному» программированию.
Да, конечно, но, как известно, галочек сейчас и у Linux и Windows достаточно… а безопасности нету…
Что один раз отказ от старых технологий сработал — почему бы ему не сработать ещё раз?


Между 64-битными виндами и ДОСом мягко говоря гигантский зазор по времени, это нормально. И, повторюсь, отказ от ДОС-программ совсем не то же самое, что отказ от Win32-программ.

Можно примерно прикинуть когда простой китайский пульт из магазина обзаведётся Linux'ом.


Иии?

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


Не, стоп. Процитированный вами комментарий был призван обратить ваше внимание на то, что светлые воспоминания Билла про опыт работы на мейнфреймах вряд ли мог настолько затуманить его мозги, что он и в 2000-е рассуждал в тех же категориях. Примерно так же, как и я не возопляю «запретите смартфоны, реальная надежность данных — только в проводах, я помню!».

мне кажется, что более вероятно, что не станет самого пульта


Если кому-то будет нужен именно пульт — то пульт будет продаваться. Без линукса.

Теоретическая возможность в скором будущем всем управлять в рамках умного дома на мой взгляд для человечества стоит на втором месте. На первом месте — нейроинтерфейсы, позволяющие быстро переключать слух с Скайпа, на внешний шум, на разговор коллег, музыку и т.д. А, да, заодно там можно и тумц-тумц-уведомления от аквариума. Раньше появления такого интерфейса пульты не пропадут.
И, повторюсь, отказ от ДОС-программ совсем не то же самое, что отказ от Win32-программ.
А в чём разница? В том, что Project Avalon так и не взлетел? Ну кто ж тогда, когда его затевали, про это знал.

Процитированный вами комментарий был призван обратить ваше внимание на то, что светлые воспоминания Билла про опыт работы на мейнфреймах вряд ли мог настолько затуманить его мозги, что он и в 2000-е рассуждал в тех же категориях.
Почему «затуманить»? Скорее прояснить. Развитие персоналок шло, вообще, впараллель с развитием мейнфреймов — только со сдвигом на 15-20 лет. IBM/370 (1970й) — «плоское» адресное пространство и вирутализация… аналог — 386й в 1985м, векторные регистры в 1976м… повторёны 1997м и так далее. Исходя из этого 15-20 летнего сдвига и того факта, что AS/400 начала заменять IBM/36 в начале 80х (и закончила ближе к 2000м) рубеж тысячелетий как раз попадал на момент, когда программы должны были перестать писаться в машинных кодах, а где-то к 2010му, как раз, переход должен был быть завершён — что Microsoft, собственно, и попытался реализовать…

Не его беда, что персоналки вот в этом месте отказались следовать в фарватере «больших» машин…

Раньше появления такого интерфейса пульты не пропадут.
Когда-то подобные вещи говорились про фотоаппараты и даже будильники…

Они, конечно, не то, чтобы пропали — просто денег там нет, как и новых разработок…

P.S. Интересно, кстати, что программы, в итоге, сейчас зачастую в машинные коды не компилируются — однако и единой системы кодирования, как в AS/400, не появилось. Java, JavaScript, C#, Python… кто в лес, кто по дрова. Осталось понять только — хорошо это или плохо… Если честно — даже не знаю.
Не его беда, что персоналки вот в этом месте отказались следовать в фарватере «больших» машин


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

И что значит «это не его беда»? А чья в конечном итоге?

Они, конечно, не то, чтобы пропали — просто денег там нет, как и новых разработок…


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

Осталось понять только — хорошо это или плохо… Если честно — даже не знаю.


С одной стороны использование байткода (желательно одного для всех) было бы хорошо в контексте цивилизации. С другой стороны если все придут к одному байткоду, то в конечном итоге появятся исполняющие прямо его процессоры (а-ля Jazelle, а потом и глубже) и в конечном итоге только они и останутся. Это и хорошо и плохо одновременно (закон Линуса + security through obscurity), а кроме того не будет стимулировать развитие новых архитектур. Но это сугубые имхи конечно.
И что значит «это не его беда»? А чья в конечном итоге?
Нас всех, в некотором смысле. Вот весь этот бесконечный сериал со Spectre и его бесчисленными родственниками — он, в общем-то, от невозможности отказаться от поддержки старых C/C++ программ. Оттуда же — проблемы с многопоточностью и многим другим.

С другой стороны если все придут к одному байткоду, то в конечном итоге появятся исполняющие прямо его процессоры (а-ля Jazelle, а потом и глубже) и в конечном итоге только они и останутся.
А это уже и так произошло, в некотором смысле. Современный x86 процессор и многие ARMы исполняют код, имеющий мало отношения к x86 или ARM ISA. Он транслируется «на лету». Вот только поскольку этот, с позволения сказать, «байткод» слабо приспособлен к безопасности (ну не для этого его делали) — то имеем то, что имеем.

а кроме того не будет стимулировать развитие новых архитектур.
Дык их и так нет. Что у нас сейчас из нового? x86 родом из 1978го да ARM из 1983го? Ну да — ещё AVR из 1996го. Свежачок-с.

«Внутри» — да, там идёт масса разных исследований. А вот «снаружи», как раз — архитектора особо не меняется. Просто вместо байткода, который ну хоть как-то был спроектирован с какой-то там расширяемостью и продуманностью — имтируется архитектура «давно ушедших дней».
Вот весь этот бесконечный сериал со Spectre и его бесчисленными родственниками — он, в общем-то, от невозможности отказаться от поддержки старых C/C++ программ


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

А это уже и так произошло, в некотором смысле. Современный x86 процессор и многие ARMы исполняют код, имеющий мало отношения к x86 или ARM ISA. Он транслируется «на лету»


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

Дык их и так нет. Что у нас сейчас из нового? x86 родом из 1978го да ARM из 1983го? Ну да — ещё AVR из 1996го. Свежачок-с.


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

А, и еще — вы конечно не стали упоминать про Nios, Microblaze, Эльбрус, миллион различных DSP-архитектур, поскольку все они, дескать, не так распространены. Но они есть — а их бы не было, ага.
Ещё можно добавить к списку MSP430 (наследник PDP-11), PIC,Propeller, да и реализация различных микропроцeссорных ядер (в том числе и Forth) в рамках FPGA стала обычной практикой.
Даже появилась такая экзотика как GA144 (MISC архитектура)

P.S. Даже 8051-е ядро стало однотактным в современных реализациях. Жаль что разработки Форт процессорных ядер так и не вышли в сегмент массовых изделий (хотя даже у нас есть в чём то устаревший, но сделанный контроллер К1894, в Минском Интеграл осталась Дофин серия ядер и последнее делающееся K1881BE1T (IN16C)) У Atmel был в портфеле купленных разработок 4-х битный Форт контроллер серии MARC4 (наследие Temic)
В космос, например, летает Форт железо RTX2010.

+ А, разве существование JVM не подстёгивает производителей процессоров и «компиляторов» ускорять и этот код так или иначе подписывая всякие NDA взаимно?
Да, я перечислил лишь часть из мира архитектур, лежащих за пределами «большой тройки» (которая в общем-то уже и «двойка»).
+ А, разве существование JVM не подстёгивает производителей процессоров и «компиляторов» ускорять и этот код так или иначе подписывая всякие NDA взаимно?
Не работает. Jezelle и прочие подобные архитектуры — не работают. Потому что если у вас есть один байткод (неважно x86 или ARM) — то зачем вам ещё один? Вы всегда можете спуститься и реализовать критический участок кода на «нативной» ISA, вызвав его через JNI.

Все основные реализации CLI и JNI — сейчас открыты. Возможно у Ларри хватит ума попробовать закрыть JVM… ну так он только загонит свою версию JVM в нишу, откуда ей уже не выскочить.
Ну нет, в первую очередь это проблема некоторых производителей процессоров.
Ну да, конечно. Если учесть, что речь идёт от AMD, ARM, Intel, IBM и Oracle… кто там у нас остался-то? Zylog?

Ну нет, uops и байткод — не одно и то же.
Конечно нет. Откуда вообще такие идеи? Современный байткод — это x86 ISA и ARM ISA. Я думал уж это-то очевидно.

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

Во-первых я бы поостерегся утверждать, что ничего нового в означенных архитектурах не появляется
Я не сказал что там ничего нового. Я сказал ISA, байткод, «застыл». А внутри, где-то в недрах, скрытых от глаз, да, там движуха, разные интересные ирхитектуры. nVidia, МЦСТ — всё это вот… только оно, в силу того, что на нормальный байткод так и не перешли — делается с суррогатом байткода…

благодаря тому, что байткод не стал обязательным условием существования процессора.
Благодяря? Я бы сказал «вопреки». «Благодаря» тому, что мы нормального, общего для достаточно большого процента программ, байткода так и не получили — все разработки ведутся «за закрытыми дверьми», в частных компаниях. Средние века в чистом виде: накрылась Transmeta — все нароботки пропали, если, вдруг, накроется Huawei — эти тоже сгинут.

А, и еще — вы конечно не стали упоминать про Nios, Microblaze, Эльбрус, миллион различных DSP-архитектур, поскольку все они, дескать, не так распространены. Но они есть — а их бы не было, ага.
А они просто тут вообще никаким боком. Если на процессорах не запускаются «ширпотребные» программы — им от байткода, C# и прочего — ни горячо, ни холодно.

Байткод, кстати, выстрелил, хотя и ограниченно: если бы не Java, то скорее всего у нас, для этих программ, были бы не две (x86 и ARM), а одна (x86) архитектура…
x86 — вполне себе полноценный байткод. И его поддерживают как в железе, так и в софте (тот же E2k). Только, как и следовало ожидать, поскольку он изначально под такую роль не затачивался — эту функцию он исполняет плохо.


Интересную позицию вы заняли. Ну, тут я прямо даже и возразить ничего не могу — по такому принципу можно утверждать почти что угодно.

А внутри, где-то в недрах, скрытых от глаз, да, там движуха, разные интересные ирхитектуры. nVidia, МЦСТ


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

«Благодаря» тому, что мы нормального, общего для достаточно большого процента программ, байткода так и не получили — все разработки ведутся «за закрытыми дверьми», в частных компаниях


А должны вестись где? В public schools и центрах взаимопомощи?

И, возвращаясь к основной нити, поскольку сделать ну совсем хороший байткод «на века» пока что маловероятно, то если бы вдруг подобный байткод ввел бы какой-нибудь регулятор, то новые процессорные технологии появлялись бы с большим скрипом.
Интересную позицию вы заняли. Ну, тут я прямо даже и возразить ничего не могу — по такому принципу можно утверждать почти что угодно.
Возразить можно было бы что-то если бы на рынке остался хотя бы один x86 процессор. Но их нет. Вроде как Quark был последним. Все остальные — не исполняют внутри себя x86 инструкции вообще, а исполняют совсем другой набор инструкций.
Ну ведь и клиентам баз данных нужно как-то в базы ходить? А ODBC мы, типа, хотим выбросить, у нас нонче ADO.NET и LINQ в моде — но надо перейти на С#, да.

Скажите, а как вы относитесь к технологии JDBC? :-)

Скажите, а как вы относитесь к технологии JDBC? :-)
А как к ней можно относиться? Она существует пока Java на Windows существует. А с полным переходом на CLR что с ней было бы — непонятно.

Впрочем сейчас-то чего гадать? «Каменный цветок» не вышел…
А как к ней можно относиться? Она существует пока Java на Windows существует

При чем тут Java на Windows? Это как бы стандартный способ подключения к СУБД из Java, который работает на любой платформе...

Он работает на любой платформе на которой работает Java. Если бы Windows перешла на потомка Singularity (как планировалось), то Java там, скорее всего не было бы.

При чем тут Singularity? Вы в комментарии выше к существованию ADO.NET придирались же.

Ну как «критичные». Microsoft XNA, например.

Ой, но ведь это всего лишь очередной движок, которых на рынке десятки, и это не считая самописных! Исходно то вы про какое-то важное API говорили...

Ну как «критичные». Microsoft XNA, например.
Ой, но ведь это всего лишь очередной движок, которых на рынке десятки, и это не считая самописных!
Ну если движков, позволяющих Инди-разработчику опубликовать что-то для популярной без выкидывания десятков тысяч долларов «десятки» — то вас не затруднит назвать хотя бы пяток?

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

А что Longhorn «накрылся медным тазом» и после всем известной перезагрузки задача «перевести всех на C#» потеряла актуальность и на смену ей пригла задача «выпусть, чёрт побери, ну хоть что-нибудь»… ну а потом уже попытки были не такими радикальными — Windows RT, Windows Phone 7, etc.

Но, ещё раз повторяю, в 2004м о том, что Microsoft «обосрался» и никакого «поголовного перехода на C#» не будет — вне стен Microsoft не знал никто. Барабаны трубили, Avalon был неизбежен (как сегодня React, да), никто не знал что вместо свелого будущего, где он заменит вообще всё и везде — будет мёртворождённая поделка… а Microsoft всё ещё казался не «одной из компаний, которая выпускает OS», а «непобедимым монстром, который решает в индустрии всё»…
Когда им сказали «все новые фишки — только в C#»? Странное у вас понятие «добровольности».

Не Microsoft виновата, что комитет по стандартизации С++ в это время сладко спал.

А каким местом «комитет по стандартизации С++» вообще к графической подсистеме Windows?

Там были грандиозные планы касающиеся именно API, их немного Джоэл раскрывает.

С C++, кстати, должно было произойти то же самое, что и с Visual Basic — он должен был превратиться в совсем другой язык. А главным (и основным) — должен был стать C# («C с четырьмя плюсами», как тогда говорили).

Тот факт, что комитет по стандартизации отказался эту авантюру поддерживать — это скорее хорошо…

А причем тут графическая подсистема Windows? Когда C# набирал популярность и перетягивал программистов — .NET Framework был еще необязательной частью Windows, никакого "особого API" не было.


Про планы превращения C++ в C++/CLI тоже что-то не пойму. Разве C++/CLI не задумывался просто как язык для полноценной интеграции неуправляемого кода с управляемым?

Когда C# набирал популярность и перетягивал программистов — .NET Framework был еще необязательной частью Windows, никакого «особого API» не было


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

Разве C++/CLI не задумывался просто как язык для полноценной интеграции неуправляемого кода с управляемым?


Именно так и именно в таком виде и существует поныне, хотя лично я мало вижу проектов на нем. Ну, то есть у нас как раз его используют, но это скорее редкость.
Когда C# набирал популярность и перетягивал программистов — .NET Framework был еще необязательной частью Windows, никакого «особого API» не было.
Мы говорим конкретно про «15 лет назад». «Особый API» ожидали «на днях». Вот как выйдет Longhorn со всякими Avalon'ами… и заживём по новому. Avalon 3-D вместо «устаревшего» DirectX (почему, как вы думаете, DirectX 9 вышел в 2002м, а DirectX 10 — уже только в 2006м… и на XP не поддерживался никогда?). Идея была в том, что в Longhorn Win32 API «уйдёт в прошлое» — вместе с C++.

Практически — планы пришлось свернуть, когда разработчики (крупные разработчики — такие, как id и Adobe) недвусмысленно заявили, что если это случится — то новая версия Windows останется без софта (как, в результате, случилось с Windows RT).

Разве C++/CLI не задумывался просто как язык для полноценной интеграции неуправляемого кода с управляемым?
Он был призван сыграть ту же роль, что и Objective C++ — дать возможность как-то перенести модули, написанные на «устаревшем» C++ в «новый мир».

Никто не планировал его использовать в долгосрочной перспективе.
Он был призван сыграть ту же роль, что и Objective C++ — дать возможность как-то перенести модули, написанные на «устаревшем» C++ в «новый мир».

И это разве плохо?

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

Вот только само по себе наличие такого «промежуточного» звена не имеет смысла если вы не собираетесь «старый мир» выбрасывать.

Ну просто как пример компании, которая успешно проделала подобную манипуляцию (со сменой языка и API): Cabron не имеет смысла в мире, где вы собираетесь и Cocoa и Toolbox поддерживать. А вот если вы предлагаете разработчикам про и Toolbox забыть и готовиться к переходу на Cocoa… вот тогда Cabron вполне имеет смысл.

Но… «не шмогла»: массового перехода на C# не случилось (только один Borland, похоже в него «по настоящему» поверил), C++/CLI остался «историческим курьозом», а в сухом остатке — потеря Microsoft'ом лидирущей позиции в индустрии вообще и на смартфонах в частности…

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


В случае гипотетического массового перехода на C# никакого С++/CLI не требуется, ведь в C# уже будет всё, что нужно.

Напротив, промежуточное звено имеет смысл только в том случае, когда и «старый», и «новый» миры сохраняются.
Серьёзно? Примеров не подкините? Потому что ситуациях с успешным переходом через временное «промежуточное звено» я видел десятки раз.

Из тех, на слуху:

Apple: четырежды — два раза менялась архитектура и один раз API операционки, Microsoft — трижды, два раза OS API — причём первый они аж сумели увести разработчиков конкурента, выпустив MS-DOS 1.0, совместимый с FCB, один раз — «увод» разработчиков Java через J#.

Ну и по мелочи: введение generic'ов в Java (которые такие кривые и убогие для того, чтобы старые программы работали), развитие C++ (где очень серьёзно думают над тем, что будет если часть программы собрана под один стандарт, часть — под другой) и так далее.

В случае гипотетического массового перехода на C# никакого С++/CLI не требуется, ведь в C# уже будет всё, что нужно.
Примеры, примеры, примеры. Я видел ситуацию, когда людям предлагали просто сесть — и всё переписать, не предлагая «временных прослоек». Ну там — при переходе с MS-DOS на OS/2, при переходе с Windows Mobile на Windows Phone, да вспомните, хотя бы, сколько усилий занял переход с Python 2 на Python 3 (притом что разница между ними несравнимо меньше, чем разница между C++ и C#).

Так что извините — но ваша теория это типичная Аристотелевская муха с восемью лапками. Прекратите смотреть себе в пупок и осмотритесь вокруг.

И где вы в перечисленных вами ситуациях появлялись подобные гибридные языки?

Да хоть в самом первом примере — для портирования с CP/M-80 на MS-DOS 1.0 выпускался 8080-совместимый ассемблер.

Туда же — J#.

Objective C++ тоже близок — но тут ситация иная: так как C++ мир не захотел вымирать, то его пришлось поддерживать и дальше.

Но гибридные языки — это только одна из возможных «промежуточных» технологий. Всё-таки несовместимости на уровне исходников стараются избегать. Гораздо чаще речь идёт об уровне API.
За новые — почему бы и нет?
Потому что тогда либо никто не будет покупать новую Windows 11 BugFree за $356720, либо если вдруг Microsoft пообещает багфри просто так (с надеждой), то будет ровно то, что я описал.
Остапа понесло. Вам вообще хоть кто-нибудь что-нибудь бездефектное обещает? Ну там дом, машину, самолёт или хотя бы джинсы? Нет, конечно.

Обещают две вещи:
1. Если дефект приведёт к потерям, то компания компенсирует ущерб, однако есть но:
2. Для того, чтобы один дефект не банкротил весь Боинг, нафиг, компания может предлагать дефект бесплатно исправить (или, если это невозможно — отозвать продукт и снять его с продаж) пока он не нанёс потерь. Если вы отказываетесь — ССЗБ.

То есть для Microsoft вообще не изменится почти ничего: он должен будет платить что-то только в тех, очень редких, случаях, когда, скажем, простой в работе прокатного стана случился из-за сбоя Windows. Поскольку обновления он уже и так регулярно выпускает. С учётом того, что в 99% случаев проблемы возникают не из-за многочисленных дефектов Windows, а из-за чьего-то раздолбайства… цены серверных версий Windows таковы, что это требования вообще мало повлияет на прибыли Microsoft.

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

Когда я стал ходить в импортных, даже китайских — черт побери, они оказались лучше, и при этом доступнее!
Я советские ботинки видел у родитей на даче. Им было лет под 30 и они, конечно, были изрядно поношены, но их всё ещё носили иногда. И, как утверждали мои родители, они отходили свои 5-7 сезонов, когда они были новыми, легко. Большинство современных «импортных» ботинок, хорошо если выдержат 2-3 сезона, а чтобы они продержались 30 лет — об этом не может быть и речи. многие китайские — разваливаются через 5-7 лет лежания на полке, даже если их вообще не надевать.

То есть мы имеем ровно то, что описывали полвека назад… пусть пока ещё и в не такой патологической форме.

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

И в случае с ботинками и в случае с софтом — можно найти вещь, которая будет относительно неплоха — но стоить это будет, в обоих случаях, ой как недёшево.

При всем моем уважении к советскому строю, но он не мог делать ботинки лучше, чем их делают теперь, и это не проблема советского строя, это объективное следствие прогресса даже в такой консервативной отрасли, как ботинкостроение. Где тоже все идет по кругу и инновации ради инноваций.
И где мы тоже имеем кучу дерьма, а если производители ещё, иногда, заботятся о том, чтобы обувь доживала, хотя бы, до конца гарантийного срока — так это только потому, что закон этого требует.

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

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

Не хочу в политоту, но все же — США и сейчас единолично накладывают санкции на весь мир.
Дык вопрос не в том — могут ли они наложить санкции, а том — будет ли на это адекватные реакции. Наложить-то вообще все могут. Россия тоже санкции накладывает. И ЕС. И вообще куча стран.

Причем вообще как хотят.
В том-то и дело, что «не как хотят». Как хотят — это они полвека назад могли. А сейчас — как могут. А могут они… ограниченно. Схема обычно такая: вначале громогласно заявляется о том, что на Иран или там Венесуэллу накладываются санкции — а потом они так тихо-тихо игнорируются.

Самое смешное — это история с Huwei, SD Card Association и WiFi Association. Когда, вдруг, в обоих организациях одновременно возникли технические проблемы и Huawei, вдруг, синхронно из списков обоих пропал, а потом, так же синхронно, вернулся. Ага, конечно. Технические проблемы. Верим-верим.

Даже если где-то и не слышали про доллар, то санкции на них все равно наложить могут.
Вот только если у вас в руках — половина мирового производства и потребления — то ищутся способы с вами договориться. А если нет — то их обходят. Вот, например. Могло ли что-нибудь подобное случиться лет 30-40 незад? Вопрос риторический.

Скорее всего потому, что расплачиваться металлическими деньгами весьма неудобно. Решил я такой заказать гостиницу в Чили для командировки, и иду на почту — посылать им щепотку золота для предоплаты…
Вы знаете — я как-то заказал вот совсем недавно гостиницу в Токио… и баксы в сейфе мне для этого им посылать не пришлось.

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

А для наличных расчётов каждая страна может напечатать свою валюту, это непринципиально. Заплатить доллами где-нибудь в магезине в Германии вы не сможете и даже в России — это проблематично.
Обещают две вещи:
1. Если дефект приведёт к потерям, то компания компенсирует ущерб, однако есть но:
2. Для того, чтобы один дефект не банкротил весь Боинг, нафиг, компания может предлагать дефект бесплатно исправить (или, если это невозможно — отозвать продукт и снять его с продаж) пока он не нанёс потерь. Если вы отказываетесь — ССЗБ.


Угу, автомобильная отрасль, например, как раз регулярно демонстрирует примеры того, что такое «отозвать продукт». Это огромные убытки!

Ну и потом — первое ваше предложение идет против второго. Если условный стан встал, то убытки… мягко говоря будут большими, чтобы согласиться на «простое исправление дефекта».

С учётом того, что в 99% случаев проблемы возникают не из-за многочисленных дефектов Windows, а из-за чьего-то раздолбайства


Вот видите, какая победа. То есть Майкрософт просто наймет больше юристов, чтобы каждый раз доказывать свою невиновность.

На кого это реально повлияет — так это на прозводителей «одноразового» добра


И оно пропадет с прилавков? И смартфон у всех тогда будет один, да? И мы даже знаем какой, и по какой цене.

Я советские ботинки видел у родителей на даче.


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

Если прогресс ухудшает жизнь людей, а не улучшает её — то кому и зачем такой «прогресс» нужен?


Вот я и пытаюсь понять — кто из людей хуже жить стал?

Дык вопрос не в том — могут ли они наложить санкции, а том — будет ли на это адекватные реакции. Наложить-то вообще все могут. Россия тоже санкции накладывает. И ЕС. И вообще куча стран.


Гм, и что, кто из перечисленных наложил такие санкции на США, что в Вашингтоне вообще об этом узнали? Особенно про Россию порадовало, ЕС еще ладно — те иногда и правда изображают что-то из себя…

Схема обычно такая: вначале громогласно заявляется о том, что на Иран или там Венесуэллу накладываются санкции — а потом они так тихо-тихо игнорируются


Ничего подобного. На Иран наложили санкции — и там люди умирают от нехватки лекарств, попавших под санкции. Вот что такое US Power, как бы это ни было противно само по себе.

Упомянутый Хуавей как раз хороший пример того, что «они» могут делать. В том числе с этим вашим «очень мощным» Китаем.

Могло ли что-нибудь подобное случиться лет 30-40 незад?


Вот как 30 лет назад могло случиться, так же точно и сегодня НЕ случится. Попрыгают-попрыгают, как кое-кто, и вернутся к собирательству своим обычным занятиям.

Если вы всё равно физически ни доллары, ни какие-либо другие купюры в бронированных грузовиках никуда не возите — то абсолютно пофигу, зачисляется вас на счёт пятьдесят баксов или грамм золота.


Гм, вот тут-то собака и порылась. Вся суть золотых расчетов как раз в том, чтобы физически это золото перемещать. Если мы этого не делаем, то начинаются «мировые валюты» (сначала привязанные к золоту, а потом постепенно нет — запрет выдачи эквивалента, вольфрамовые слитки, блокировка золотого запаса Германии, вот это вот все), единые центры процессинга, вся эта мура. Будь я кем угодно — попросил бы мне мое золото привезти и положить. А вы там в своем интернете можете сколько угодно коммитить друг друга в гитхаб, фолловить, лайкать и майнить. А мне вот сюда металл положите. А то завтра опять санкции, или ошибки какие-то, вы мое золото заблокируете — и тю-тю.
Угу, автомобильная отрасль, например, как раз регулярно демонстрирует примеры того, что такое «отозвать продукт». Это огромные убытки!
Вы как-то не обратили внимание, что есть ещё и другой вариант: предложить обновление. И этот вариант выбирается гораздо чаще. Даже в той же «автомобильной отрасли».

Если условный стан встал, то убытки… мягко говоря будут большими, чтобы согласиться на «простое исправление дефекта».
Тем менее сегодня — ничего большего с Microsoft стрясти не удастся.

То есть Майкрософт просто наймет больше юристов, чтобы каждый раз доказывать свою невиновность.
Microsoft хотя бы минимум выполняет: регулярно выпускает исправления. Огромное количество разработчиков не удосуживаются делать даже этого.

И оно пропадет с прилавков? И смартфон у всех тогда будет один, да? И мы даже знаем какой, и по какой цене.
Интересно — что у вас за один смартфон вдруг выплыл из глубин подсознания, но… нет. Есть Android One, есть другие программы поддержки. Но пока принцип «и так сойдёт» принимается… конечно гораздо дешевле работать по принципе «мы тут сотворили нечто с бэкдорами и бог знает чем ешё — а вы жрите, и не жалуйтесь — дёшево же»!

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

Гм, и что, кто из перечисленных наложил такие санкции на США, что в Вашингтоне вообще об этом узнали?
А что — если санции не ощущают в Вашингтоне, а плачут только, скажем, в Кракове — это уже не санкции? У нас с каких пор Вашингтон стал сталицей мира?

Ничего подобного. На Иран наложили санкции — и там люди умирают от нехватки лекарств, попавших под санкции.
Вот только как раз на лекарства санкции не распространяются. Вообще с лекарствами всё непросто: на Украине, к примеру, тоже люди от нехватки лекарств умирают — тоже будем санкции США обвинять?

И вообще — о каких годах вы говорите? Я видел много сообщений о подобных событиях, случившихся до 2015года (когда санкции были введены не только США, но и другими страными и были реальными) и как-то очень мало — про новые, которые США уже «вообще как хотят» ввели — и которые все другие страны также «вообще как хотят» и исполняют… то есть никак.

Упомянутый Хуавей как раз хороший пример того, что «они» могут делать. В том числе с этим вашим «очень мощным» Китаем.
И чего они пока что сделали? Сказали, что введут такие… такие… прям ну такие санкции… с 19 августа, да.

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

Вот как 30 лет назад могло случиться, так же точно и сегодня НЕ случится. Попрыгают-попрыгают, как кое-кто, и вернутся к собирательству своим обычным занятиям.
Ну посмотрим, посмотрим. А кто-такий кое-кто? Не Русал, с которого санкции сняли, несмотря на то, что он теперь вообще зарегистрирован в России? А кто?

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

А то завтра опять санкции, или ошибки какие-то, вы мое золото заблокируете — и тю-тю.
Ну дык этот процесс уже идёт. Германия, Голландия, Турция — зачем своё золото из США вывозят? Чтобы долларом продолжать пользоваться? Ага, щаз. Отказ от доллара неизбежен — вопрос только в сроках.
Вы как-то не обратили внимание, что есть ещё и другой вариант: предложить обновление.


Толку от этого потребителю? Когда людям нужно реально надежное решение, то они прописывают совсем другую ответственность производителя.

Интересно — что у вас за один смартфон вдруг выплыл из глубин подсознания


Айфон. Будет один айфон, и никакого этого «великолепия», которое сейчас творится в мире Андроида.

Люди у которых увели деньги тем или иным способом, хотя бы. Платными SMSками или другими способами


Щито? А при чем тут производитель смартфонов? Деньги со счетов телефона воровали еще когда у меня была Нокия 3310.

А что — если санции не ощущают в Вашингтоне, а плачут только, скажем, в Кракове — это уже не санкции?


Ну мы же говорим об ответных санкциях России и ЕС в сторону США, а не в сторону Польши.

Вот только как раз на лекарства санкции не распространяются


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

И вообще — о каких годах вы говорите?


Начиная с 1950-х.

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


Да с Хуавеем же уже что-то происходит, нет?

А кто-такий кое-кто?


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

Отказ от доллара неизбежен — вопрос только в сроках.


Гм, думаю это крайне патриотическое, но слабо экономически обоснованное заявление ))
Щито? А при чем тут производитель смартфонов? Деньги со счетов телефона воровали еще когда у меня была Нокия 3310.
А троян в Nokia 3310 был «с завода» — или всё-таки его нужно было где-то подхватить?

Айфон. Будет один айфон, и никакого этого «великолепия», которое сейчас творится в мире Андроида.
Если вы про кучу телефонов с заводскими троянами (которые где только не обсуждаются, как я уже говорит, вот последняя статья на Хабре) — то не нужно нам такого «разнообразия». Спасибо.

И вообще — о каких годах вы говорите?
Начиная с 1950-х.
А какое имеют отношения санкции 1950х к тому бессилию, которые США демонстрируют последние 2-3-4 года? Когда они даже с Северной Корее ничего сделать не могут?

Вот давайте и посмотрим, что 19го августа таки случится и что из этих громогласных заявлений станет реальностью.
Да с Хуавеем же уже что-то происходит, нет?
Пока ничего. Много разговоров и шума в прессе. А дела… Месяц назад Европа США с их санкциями послала, а вот Испания только что подтвердила, что она тоже не собирается от Huawei отказываться.

Да, истерика в прессе — это тоже какой-то результат… но он бесконечно далёк от ожидаемого.

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

Отсюда и отсутствие результата при активном «надувании щёк» и шуме в прессе.

Это была не вполне уместная отсылка к самым известным любителям скакать. Которые тоже надеялись на что-то.
А… вы про Украину. Ну эти как раз поимеют возможность посмотреть чем реальные санкции отличаются от шума в прессе. Вот сейчас у них из-за Российских санкций скакнула цена на газ. А ведь основные «залпы» газовых войн случатся только «под ёлочку».

Отказ от доллара неизбежен — вопрос только в сроках.
Гм, думаю это крайне патриотическое, но слабо экономически обоснованное заявление ))
Это как раз чистая экономика: времена, когда мировая экономика получала больше выгод от «мировой валюты», чем теряла от перетока денег в США — давно прошли. Однако перед тем, как отказываться от доллара — нужно разработать альтернативу… репатриция золота всеми центробанками и многое другое — это звенья этой цепи. Ну а у жителей России, конечно, всегда есть выбор — следить за тем, что происходит… или вдруг, внезапно, оказаться в позиции той же Прибалтики.

Которая самозабвенно пилила сук, на котором сидит десятилетиями, не обращая внимание на то, как отстраивается Усть-Луга и реконструируются железные дороги, строятся электростанции и терминалы СПГ… ну а теперь, конечно, пришлось в Россию лететь… вот только не факт, что это поможет.

Ну блин, это ж та же самая история, что и с программированием: представьте себе, что вы хотите перевести какой-нибудь крупный банк с MS SQL на Oracle или, того круче, на NoSQL базу данных. Вы что — на следующий день как решите побежите всё отключать? Нет же — будут пилотные проекты, постепенный перезод, много тестов… а потому «вдруг», когда всё будет готово — произойдёт резкий переход.

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

Если же хочется шумихи в прессе — тогда да, можно и как Трамп: трах-бах-и-тишина… в смысле — ничего толком не случилось…
А троян в Nokia 3310 был «с завода» — или всё-таки его нужно было где-то подхватить?


При чем ту троян? Банальные СМС-подписки, на которые тебя тайно подписывал хитрый опсос.

Когда они даже с Северной Корее ничего сделать не могут?


Гм, ну Северная Корея просто научилась жрать траву и делать из нее ракеты, их так просто не проймешь, бомбить надо. Так что это не «даже», а вполне себе «огого». А на России санкции сказываются вполне конкретно например.

Да, истерика в прессе — это тоже какой-то результат… но он бесконечно далёк от ожидаемого.


Ну, не только в прессе… Изгнание хуавеевцев из числа рецензентов IEEE ИМХО сильный удар сразу и по Хуавею и, к сожалению, по IEEE. Отказ ARM Holdings в сотрудничестве я уж и не знаю как называть тогда уж… Это наверное не санкции, а гумпомощь?

Нет же — будут пилотные проекты, постепенный перезод, много тестов… а потому «вдруг», когда всё будет готово — произойдёт резкий переход.


То есть вы ожидаете некий внезапный отказ от доллара? А также от Свифта, от Визы/Мастеркарда, и вообще всех основ современной международной экономики?
А меня вот, как человека от сохи, не удовлетворяет Форт в общем и целом, ну вырвиглазный же язык.

А, для меня, например, китайский и др. такие языки — «вырвиглазные», но как это «китайцам» объяснить, чтобы поняли? :)
Китайские Форт исходники, кстати, тоже существуют. Где то (несколько лет назад) даже мелькала новость, что Форт предлагали как основу Всекитайского языка программирования.

P.S. Отмечу отдельно, что какой то программный Форт код без повторения особенностей Форт виртуальной машины в Си язык не преобразовать простым способом, а вот обратно болеe менее решаемо.
Пример с китайцами не совсем в кассу, ведь на Форте пробовали писать представители всех рас и национальностей, и итог вот он вот.
А троян в Nokia 3310 был «с завода» — или всё-таки его нужно было где-то подхватить?
При чем ту троян? Банальные СМС-подписки, на которые тебя тайно подписывал хитрый опсос.
А причём тут Nokia? Опсос может и на SIMку, лежащую в ящике стола, подписок навесить… к софту, установленному на телефоне это вообще никакого отношения не имеет.

А на России санкции сказываются вполне конкретно например.
Ну… они оказывают какое-то «неправильное» действие. Вместо того, чтобы спровоцировать массовые протесты — они позволили ей перевести важные предприятия в российскую юрисдикцию, а также стать крупным экспортёром продовольствия. Что, в свою очередь, резко снижает эффективность дальнейших санкций — траву жрать не особо надо, если ты едой себя обеспечиваешь, ведь правда?

Изгнание хуавеевцев из числа рецензентов IEEE ИМХО сильный удар сразу и по Хуавею и, к сожалению, по IEEE.
Вот только больше по IEEE, чем по Huawei. Потому что с IEEE «разговоры в тихой комнате» китайцы уже провели — и в IEEE всё поняли правильно. А вот не решат ли, в результате, китайцы создать альтернативную организацию по стандартизации… думаю скоро увидим.

Отказ ARM Holdings в сотрудничестве я уж и не знаю как называть тогда уж… Это наверное не санкции, а гумпомощь?
Отчасти. Хотя для ARM — это, скорее, изощрённая форма самоубиства. У них есть время до 19 августа. И они либо придумают как «сдать назад», либо, лет через 10, ARM будет так же популярен, как сегодня — какой-нибудь SuperH.

Подготовка, судя по всплывающим заявлениям уже началась. Наиболее вероятное решение — отказ от передачи технологий, но при этом — продажа соотвествующих патентов. Свои ядра у Huawei уже есть, так что катастрофой это не будет. И в долгосрочной перспективе всё это будет куда более сильным ударом по ARM, чем по Huawei.

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

А также от Свифта, от Визы/Мастеркарда, и вообще всех основ современной международной экономики?
Ну это от США зависит. Если будут продолжать махать дубинкой санкций — может и полный отказ случиться. Если успокоятся и будут «держать себя в рамках» — сохранят за собой часть мировой торговли.

США уже достаточно дров наломали, для того, чтобы страны, которым это дуболомство надоело, твёрдо решили «основы мировой экономики» отвязать от долларовой зависимости. Процесс идёт — вопрос в сроках.

Задумайтесь на минуточку: что делают в азиатском банке такие «азиатские» страны как Великобритания и Бразилия? Этот банк, вообще-то, о Азиатско-Тихоокеанском регионе… Вы на карту смотрели?

Это всё — тоже подготовка к отказу от «услуг США» по решению вопроса о том кого казнить, кого миловать. А сам по себе доллар… ну да, будут использовать — как с самой-то Америкой торговать? Но уже «отключение» кого-то от SWIFT'а — проблемой не будет.
Это-то да, но суть в том, что подобный код в принципе писать нельзя. Зачем же его обсуждать?
Одни языки более/менее пытаются делать некорректные состояния невыразимыми, то есть код даже не соберётся. Это языки простые для написания программ. И есть языки простые для написания компиляторов, в которых отстрелить ногу можно на ровном месте.
Это что за ассемблер такой, который берёт и выкидывает куски кода?

Обычный GCC c флагом "-Os". Вполне нормально поведение. Ну если не забывать про некоторые тонкости типа использования volatile для static переменных, которые используются только в прерываниях.


Речь идёт вот подобных вещах. Когда вот такая функция:…
проверку на NULL содержит. А вот такая вот:… уже нет. И вызова foo — там тоже нет.

Вы меня удивили… решил даже проверить. Неа… проверка остается.
В каком компиляторе подобное поведение (нет проверки) наблюдали?


 269:main.c        **** int foo() { return 1;}
 20956                      .loc 1 270 0
 20957                      @ args = 0, pretend = 0, frame = 0
 20958                      @ frame_needed = 0, uses_anonymous_args = 0
 20959                      @ link register save eliminated.
 20960                      .loc 1 270 0
 20961 0000 0120            movs    r0, #1
 20962 0002 7047            bx  lr
 20963                  .LFE44:
 20965                      .global __aeabi_f2iz
 20966                      .section    .text.bar,"ax",%progbits
 20967                      .align  1
 20968                      .global bar
 20969                      .thumb
 20970                      .thumb_func
 20972                  bar:
 20973                  .LFB45:
 270:main.c        **** 
 271:main.c        **** int bar(float *p) {
 20974                      .loc 1 272 0
 20975                      @ args = 0, pretend = 0, frame = 0
 20976                      @ frame_needed = 0, uses_anonymous_args = 0
 20977                  .LVL30:
 20978 0000 08B5            push    {r3, lr}
 20979                  .LCFI4:
 272:main.c        ****    if (p==NULL) {
 20980                      .loc 1 273 0
 20981 0002 18B1            cbz r0, .L35
 20982                  .LVL31:
 273:main.c        ****       return foo();
 274:main.c        ****    } else {
 275:main.c        ****        return *p;
 20983                      .loc 1 276 0
 20984 0004 0068            ldr r0, [r0, #0]    @ float
 20985                  .LVL32:
 20986 0006 FFF7FEFF        bl  __aeabi_f2iz
 20987 000a 00E0            b   .L34
 20988                  .LVL33:
 20989                  .L35:
 274:main.c        ****       return foo();
 20990                      .loc 1 274 0
 20991 000c 0120            movs    r0, #1
 20992                  .LVL34:
 20993                  .L34:
 276:main.c        ****    }
 277:main.c        **** }
 20994                      .loc 1 278 0
 20995 000e 08BD            pop {r3, pc}
 20996                  .LFE45:
 20998                      .section    .text.baz,"ax",%progbits
 20999                      .align  1
 21000                      .global baz
 21001                      .thumb
 21002                      .thumb_func
 21004                  baz:
 21005                  .LFB46:
 278:main.c        **** 
 279:main.c        **** int baz(float *p) {
 21006                      .loc 1 280 0
 21007                      @ args = 0, pretend = 0, frame = 0
 21008                      @ frame_needed = 0, uses_anonymous_args = 0
 21009                  .LVL35:
 21010 0000 08B5            push    {r3, lr}
 21011                  .LCFI5:
 280:main.c        ****    float x = *p;
 281:main.c        ****    if (p==NULL) {
 21012                      .loc 1 282 0
 21013 0002 18B1            cbz r0, .L38
 21014                  .LVL36:
 282:main.c        ****       return foo();
 283:main.c        ****    } else {
 284:main.c        ****        return *p;
 21015                      .loc 1 285 0
 21016 0004 0068            ldr r0, [r0, #0]    @ float
 21017                  .LVL37:
 21018 0006 FFF7FEFF        bl  __aeabi_f2iz
 21019 000a 00E0            b   .L37
 21020                  .LVL38:
 21021                  .L38:
 283:main.c        ****       return foo();
 21022                      .loc 1 283 0
 21023 000c 0120            movs    r0, #1
 21024                  .LVL39:
 21025                  .L37:
 285:main.c        ****    }
В каком компиляторе подобное поведение (нет проверки) наблюдали?
Там, вообще-то, ссылка на godbolt. Где есть много компиляторов. Убирает GCC большинства версий (начиная с 6й, если мне не изменяет память).

И да, если вы выключите -fdelete-null-pointer-checks (умолчание для AVR, CR16 и MSP430, как говорит мануал) — то ссылки убираться не будут. Но большинство компиляторов проверку убирает и функцию тоже.

Это — корректное поведение с точки зрения языка C (хотя, как мы видим, некорректное с точки зрения «православного эмбеддера»).
А если сравнить его с другими языками, столь же хорошо поддержанными в распространенных тулчейнах для эмбеда, то какой же интересно окажется проще, чем Си?
Извините, но «в распространённых тулчейнах для эмбеда» поддерживаются, очевидно, те языки, на которых пишут для эмебеда. Ну а пишут, не тех, что поддерживаются, логично.

То есть да, сегодня Си популярен просто потому, что он популярен.

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

Есть ощущение, что всё упирается в Столмана и Гилмора и Тименна. Которые устроили, как бы, банальный демпинг в эмбеде — который кончился фактически полным вытеснением других языков.

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

Насчет «высокоуровневого ассемблера» — был бы рад услышать внятные возражения этому, весьма популярному и отнюдь не дураками придуманному утверждению.
Возражение — самое простое: язык C призван не быть ассемблером. В этом — сама его суть. Что такое ассемблер? Это нечто, что позволяет использовать возможности машинного кода наиболее полно. То есть он — привязан к процессору.

Язык C же — как раз наоборот: создан для того, чтобы писать программы не привязанные к процессору. Если какая-то особенность является особенностью одного конкретного процессора и в других процессорах не встречается — с вероятностью 99% это, в C, будет UB — и использовать эту особенность будет запрещено.

Это напрямую проистекает из цели, которую ставили перед собой создатели C, но это, как бы, является полной противоположностью идее «высокоуровневого ассемблера».

Пока скажу только одно — если, например, расположить Java и C# (на чем тоже писал, представление имею) на одном полюсе, а Си на другом, а потом попытаться где-то здесь расположить любой ассемблер, то он скорее к Си притянется, что как бы намекает.
Тот факт, что популярные языки являются более далёкими от ассемблера, чем С — вовсе не значит, что C — близок к ассемблеру. К ассемблеру куда ближе языки типа Форта или PL/M… но почему-то «ёжики продолжают жрать кактус».

Ну ладно вам, нытье не зависит от языка.
Однако будете ли вы записвывать документированные свойства языка в «ошибки компилятора» или нет — зависит.

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


Угу, «так вышло»…

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


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

Однако при этом они не понимают ни того, зачем нужен UB, ни как писать переносимые программы


То есть, если кратко — они плохо пишут программы. Это так и есть, большинство программистов, в том числе эмбеддеров — плохие. Замена Си на что-то другое решит эту проблему?

Возражение — самое простое: язык C призван не быть ассемблером


Ок, предлагаю следующее — я отказываюсь от утверждения про «высокоуровневый ассемблер» в пользу в общем-то более верного «низкоуровневый язык». С этим не будете спорить?

К ассемблеру куда ближе языки типа Форта или PL/M


На которых никто не пишет, из чего следует некоторый вывод…

Однако будете ли вы записвывать документированные свойства языка в «ошибки компилятора» или нет — зависит


Приведите пример языка, в котором все ошибки воспринимаются программистом как «свои».

Ну то есть надёжные решения в эмбеде тоже никому не нужны — нужны работающие как-нибудь… а как же рассказы про то, что всё должно быть суперпроверено и надёжно?


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

Пишут, но Вы не в курсе т.к. даже не произвели репрезентативный поиск.

Приведите пример языка, в котором все ошибки воспринимаются программистом как «свои».

В Форте так оно и есть. Попробуйте опровергнуть. :)

P.S. Ну и, не забываем историю появления Си, как замену ассемблера в системе команд процессора PDP-11 для написания ядра ОС Unix под данный процессор (отуда ++ — и другие элементы дизайнa синтаксиса языка)
Пишут, но Вы не в курсе т.к. даже не произвели репрезентативный поиск


Здесь сразу задам простой вопрос — вы из их числа?

В Форте так оно и есть. Попробуйте опровергнуть. :)


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

Любопытно, зачем вообще разрабатывать новые языки. Теоретически, они должны давать новые возможности, но на самом деле, многие из новых языков на 90% совпадают с существующими. Кому-то не сильно не нравится тернарный оператор в языке X и этот человек создает язык Y, который почти как X, только без «противного» тернарного оператора. Через 10 лет в Y под давлением коммьюнити появляется тернарный оператор.


В итоге, мы имеем зоопарк языков, на этих языках написаны гигабайты кода, которые тихо разлагаются на забытых FTP серверах, потому что не совместимы с новыми языками и API/ABI.


В итоге мы имеем массу незавершенных проектов, которые никогда и не будут завершены. Не будут исправлены баги, не будут дописаны фичи. Просто проект начнут писать заново на новом языке. Естественно, пока в нем будет реализована хотя бы часть функциональности старого проекта и исправлены заново созданные ошибки, появится следующее поколение языков, фреймворков, ОС. И снова начнется переписывание с нуля.


Мне одному это кажется каким-то патологическим повторением одного и того же, сизифовым трудом?..

Это нормальный процесс эволюции, в живой природе вообще бесчисленное число видов вымерло к примеру.

immaculate, вы не одиноки.

Gorthauer87, не путайте нормальный процесс эволюции с работой человеческих мозгов. Мозг — это механизм, который может повторять лишь то, что знает. Крайности не свойственны природе, она всегда находится в равновесии. Биологические же виды вымирают по иным причинам, нежели это происходит с яп. Яп может создаваться конкретной компанией для решения конкретных задач и так там и умереть. Сколько таких языков придумано и еще будет придумано остается загадкой (напоминает легенду о Вавилонской башне). Хотя, эти же задачи можно решить, используя имеющиеся языки. В этом то и есть главное отличие. Природа никогда не делает лишнюю работу.
Почти вся работа которую делает природа (если под делами природы мы имеем в виду эволюцию посредством естественного отбора) является лишней. Подавляющее число всех мутаций, которые происходят при размножении организмов не несёт никакой пользы. А некоторые и совсем несовместимы с жизнью.
Вообще я очень не люблю фразы вроде «природа делает», «природа знает» (это отсылка к законам Коммонера). Строго говоря, у природы нет цели и вообще непонятно по какому критерию можно отнести какие-то события к «нелишним».
Кроме того, почему работа человеческих мозгов не является работой природы?
Хотя, эти же задачи можно решить, используя имеющиеся языки.
Без одних языков(javascript, python) решать задачи так-же легко, так как существует замена, без других(rust, erlang) решать туже самую задачу будет в разы сложнее. Новые языки — новые попытки решить уже существующие проблемы. Какие-то проблемы решены криво (вместо возможности автоформатирования принудительные отступы в python, громкое имя java в javascript), какие-то достаточно хорошо, чтобы рассматривать язык как замену (rust заменяет си улучшая безопасность, erlang заменяет *** для распределённых вычислительных систем).
Природа никогда не делает лишнюю работу
Природа разумна?

Вот как раз JavaScript в этом плане замены полноценной нет. На каком языке вы напишите что-то, что работало бы в и в последнем Хроме и в ИЕ11?

Вот как раз JavaScript в этом плане замены полноценной нет. На каком языке вы напишите что-то, что работало бы в и в последнем Хроме и в ИЕ11?
В данной ветви речь идёт о следующей ситуации: есть какая-то задача и нужно решить, создавать для этого язык или нет. В год создания js 1995 были и другие языки, например python 1991, lua 1993, scheme 1975. Веб прекрасно бы работал, даже если бы скрипты в вебе были на python|lua|scheme. Соответственно «прорыв» «пиши на одном языке на бекэнде и на фронтенде» произошёл бы гораздо раньше.

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

Субъективно, порог вхождения в эти языки выше чем в js
И это — их огромное преимущество в долгосрочной перспективе.

да и внедрить их бы в браузеры было бы сложнее вероятно.
Ну да, включить пару хидеров и подключить библиотеку — это же так сложно.

Изобретение JS — это одна из трагических страниц в развитии IT, с какой стороны к ней не подойти. Увы.
И это — их огромное преимущество в долгосрочной перспективе.

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


Ну да, включить пару хидеров и подключить библиотеку — это же так сложно.

Уверен на 99%, что такой вариант автором рассматривался.


Изобретение JS — это одна из трагических страниц в развитии IT, с какой стороны к ней не подойти. Увы.

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

Далеко не всем нужны заграждающие барьеры в разработке. Собственно не могу предсьавить зачем, кроме как стать элитой.
Чем меньше у вас ошибок в программе изначально — тем меньше денег на всё это уходит, в конечном итоге. Количество денег, потерянных из-за того, что Web создавался по принципу «и так сойдёт» — измеряется миллиардами… и в то же время совершенно непонятно, что общество бы потеряло, если бы свистелок и перделок (на которые и уходит основное время разработки) в нём было бы чуть меньше.

Уверен на 99%, что такой вариант автором рассматривался.
Конечно. И было отвергнут: они были слишком хороши. Техзадание было следующим: I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.

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

Судя по результатам, это один из нескольких двигателей веба
Сюдя по результатам — это один из тормозов веба. Масса решений, который были внедрены в JavaScript специально для того, чтобы это не оказался бы, вдруг, язык, сравнимый по качеству с Java — до сих пот отравляют жизнь разработчикам и стоят, и итоге, всей индустрии миллиарды долларов.
Не факт, что мы имели бы такой же веб.
Проблемой могли бы быть отступы python, так как их нельзя просто выкинуть. Либо заменять на табуляции, либо довольстоваться одним единственным пробелом. Это бы даже не должно было бы повлиять на появление TypeScript, Flow, Elm,… так как у этих языков те же самые проблемы, типа необъявленных переменных или обноружения несоответствия типов во время выполнения. Даже у CoffeeScript есть аналог в виде MoonScript.
Субъективно, порог вхождения в эти языки выше чем в js
Все эти языки учаться по схеме за 15 минут. Ну плюс пару статей по преодолению каких-то местных костылей. И некоторое время практики, если до этого не программировал ни разу.
да и внедрить их бы в браузеры было бы сложнее вероятно.
Работа по подключению языка к программе одинакова что в случае js, что в случае, например, lua. Только js перед этим нужно было ещё создать, тогда как lua уже был готовым.
vonabarak, люблю, не люблю, факты не обращают на это внимания. Вот мне, например, не нравится, что в сутках всего лишь 24 часа… Перефразирую, природа очень щедра и в ней всего с избытком. Природа ежедневно окрашивается новыми, свежими красками, каждое утро — новые цветы. Этот праздник не прекращается ни на мгновение — он бесконечен. Вот вы, например, даже и не думали появляться на свет, а природа дала вам такую возможность! Истинная щедрость. Согласен с вами, что у природы нет цели, но здесь противовесом выступает уже человек, который придумывает и развивает идеи, хотя по сути — это лишь его иллюзии.

Да, работа человеческих мозгов, отчасти, является работой природы. Каждый из нас часть природы все-таки, мы живем внутри природы, а не сбоку или сверху, внутри! (to alsoijw вот и ответ на ваш вопрос, только не говорите, что вы не часть природы, тогда она потеряет капельку разумности ;) )

А теперь про языки, VolCh, alsoijw, vonabarak, khim вы разработчики или где? Откуда взялись все эти языки программирования? Неужели вы думаете, что инициаторами были инженеры-программисты? Представьте, что у нас не одна математика, а 15ть разных. В некоторых нет нулей, в некоторых единиц, в некоторых чет/нечет одно и то же и т.д. Кому это придется по вкусу? — Правильно, только тем, кто в этом ни черта не соображает. Поэтому у нас одна математика, универсальный язык общения между нами и природой. я пытаюсь донести следующее — лучше развивать пару-тройку языков и довести их до ума, чем каждый день придумывать «новый» язык (у природы это получается придумывать новое, но у человека, как части природы, с этим делом по-хуже. все логично, вниз по иерархии :) ).

tj VolCh, я напишу на плюсах то, что будет работать вместо хрома и ие11; более того, я напишу на плюсах то, на чем вы будете запускать это самое нечто, работающее вместо хрома и ие11 ;)
Заголовок при лисп — статья про джаваскрипт (
насколько я знаю трагедия LISP была как раз в другом — он настолько гибок в смысле изменения синтаксиса (из-за гомоиконности и мощнейшей системы макросов), что люди очень легко начинали делать с нуля (и делали) то, для чего в других языках применили бы чужую библиотеку. В итоге получился зоопарк собственных решений и раздробленность сообщества.
Это другая проблема. Та проблема, которую имеет в виду автор (хотя чёрт его знает, что он имеет в виду на самом деле) — это просто тот факт, что в Common Lisp есть куча вещей, которые мало кто использует реально. Хотя я думаю тут скорее PL/M или C++ подошли бы… но тут как раз странно: в C++, как раз, долгие годы не хотели добавлять некоторые критически важные вещи (типа лямбд, сопрограмм или variadic'ов) и в результате были порождены просто горы костылей для их замены. Точно ли это лучше, чем иметь большой язык из которого нужно выбирать подмножество для работы?
Согласен насчёт С++. Я читал книгу Сайбеля по Common LISP, язык не больше большинства современных мейнстримовых, например Python (там на самом деле очень много всего) или Java. Но у него есть возможности, которых нет ни у кого, так что лично для меня это адекватная цена. Особенно с учётом того, что нотация для всех этих фич одна и та же — списки и её можно объяснить за минуту человеку с опытом программирования.

Так что в этом смысле LISP (и диалекты) кардинально проще других ЯП (где нужно помнить много хитрых значков, отступов и ключевых слов и что они значат в том или ином контексте). В этом смысле он ближе всех к естественным языкам (русский, английский), где у нас есть очень маленький ортогональный базис (существительное, прилагательное, глагол, ..., грамматика) и множество предметных областей, включая саму лингвистику (как это похоже на мета-возможности LISP !).
Так что в этом смысле LISP (и диалекты) кардинально проще других ЯП (где нужно помнить много хитрых значков, отступов и ключевых слов и что они значат в том или ином контексте).
А вот как раз неочевидно. Математически LISP — проще. Но вот для человека — вовсе нет. Вот именно потому что в нём нет образов, за которые «цепляется» взгляд. Самые разные конструкции — все выглядят единообразно.

Для компьютера это, может, и хорошо. Для человека — не очень…
Для человека неискушённого любое современное программирование одинаково дико выглядит — говорю как part-time школьный учитель информатики. Попробуйте объяснить что такое присваивание незнакомому с этим человеку, что x = x + 1 это норма и пр. И любой вообще ЯП требует понимания таких вещей как функция хотя бы на каком-то уровне, т.е. люди с тройкой по математике сразу идут лесом.
Попробуйте объяснить что такое присваивание незнакомому с этим человеку, что x = x + 1 это норма и пр.
Действительно — человеку, мозги которого не поломаны императивщиной рассказывать про функциональное программирование (где такого нету) проще. Но это отдельная история.

И любой вообще ЯП требует понимания таких вещей как функция хотя бы на каком-то уровне, т.е. люди с тройкой по математике сразу идут лесом.
Куда девать людей с тройкой по математике — вообще неясно. Количество Yuotube каналов, на которых можно заработать, всё-таки ограничено, а ни на какое производство их «приспособить» нельзя…

Всякие же места продавцов, грузчиков и водителей сокращаются со страшной силой…
Действительно — человеку, мозги которого не поломаны императивщиной рассказывать про функциональное программирование (где такого нету) проще.
Империативщина не ломает мозги. Можно начать с чисто империативного подхода, постепенно добавляя паттерны из функционального программирования. А то при буквальной трактовке так же можно споткнуться на неявном умножении Debug.log = D*e*b*u*g.l*o*g или же на том как ставить скобки
text (min x y)
А то при буквальной трактовке так же можно споткнуться на неявном умножении Debug.log = D*e*b*u*g.l*o*g или же на том как ставить скобки
text (min x y)
А как человек, не понимающий, что Debug — это не D*e*b*u*g работает с синусами или логарифмами? Про скобки — вообще не понял: если вы не про LISP, то скобки ставятся как на уроках математики…

Империативщина не ломает мозги.
Ломает-ломает. Квадратные уравнения в школе решают все, а понять, что ФП это тоже самое, для человека, чего-то написавшего на каком-нибудь Basic'е — проблема. А вот для человека, не программированного вообще, но знающего математику — проблем никаких.
А как человек, не понимающий, что Debug — это не D*e*b*u*g работает с синусами или логарифмами?
Достаточно один раз прочитать «сначала вычисляется правая часть выражения, потом левая», чтобы не испытывать больше проблем, точно так же как и с неявным умножением в математике. В крайнем случае можно писать на tcl или pascal. Открытые/закрытые диапазоны точно так-же не имеют отношения к программированию, и запись типа [10, 5) является ошибкой.
Про скобки — вообще не понял: если вы не про LISP, то скобки ставятся как на уроках математики…
В математике — функция(аргумент), в си подобных функция(аргументы), в хаскельподобных(?) (функция аргументы). В lisp скобки обязательны, в других фп скобки можно опустить если не вкладывать вызовы друг в друга.
Квадратные уравнения в школе решают все, а понять, что ФП это тоже самое, для человека, чего-то написавшего на каком-нибудь Basic'е — проблема
Я как раз начинал с VB .NET. В квадратных уравнениях нет никакой ни рекурсии, ни локальных переменных, ни замыканий, ни сопоставлений с образцом, ни ленивых вычислений, ни с деструктирующим присваиванием, ни с макропроцессором, ни с шаблонизаторами. Точно так-же в математике нет отдельно присваивания и отдельно сравнения, там сравнивать не с чем. Точно так-же переносить из одной части в другую в функциональном программировании нельзя. При их решении уравнений не нужно следить ни за стеком вызовов, ни за условиями выхода из цикла, ни за чем иным.
Достаточно один раз прочитать «сначала вычисляется правая часть выражения, потом левая»
Что значит «вычисляется»? Как это вообще понять? Если у меня написано, что a = b + c, то это, как известно, значит то же самое, что и b = a - c. То есть если написано, что x = x + 1, то это значит, что x = x + 1… но это же бред! Как такое может быть?

точно так же как и с неявным умножением в математике.
Неявное умножение — это как раз ближе к вызову функций в Hasekll'е. Вместо a × b или a × ba ⋅ b пишем a b для краткости. Но это значит то же самое. А вот это вот x = x + 1 — оно, извините, вообще непонятно что значит.

Открытые/закрытые диапазоны точно так-же не имеют отношения к программированию, и запись типа [10, 5) является ошибкой.
В Mesa, кстати, нет. Но это так, к слову.

В крайнем случае можно писать на tcl или pascal.
Там всё равно переменная ведёт себя совсем-совсем не так, как на уроке математики.

Точно так-же в математике нет отдельно присваивания и отдельно сравнения, там сравнивать не с чем.
Есть-есть, вы просто про них забыли. Вот буквально то же квадратное уравнение когда решаете — там фигурная скобочка появляется и, справа от неё, три варианта: D > 0, D = 0, D < 0. Вот там знак равенства — обозначает не то же самое, что в записи самого квадратного уровнения… но то же самое, что обозначает знак == в Haskell'е.

Да, тут, конечно, тоже некоторое несовпадение записи… но суть — та же.

В квадратных уравнениях нет никакой ни рекурсии,
В квадратных уравнениях — нет. Это нужно аж до биномиальных коэффицентов дойти или до разложения в ряд.

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

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

ни сопоставлений с образцом,
есть, конечно. Вот та самая фигурная скобочка при решении уравнений возникает — это вот оно самое и есть.

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

ни с деструктирующим присваиванием,
А вот этого — нету в математике, да.

ни с макропроцессором,
А где в C# впервые встречается макропроцессор?

ни с шаблонизаторами.
Ну это уже чистая косметика… как и макропроцессор…

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

Точно так-же переносить из одной части в другую в функциональном программировании нельзя.
В Prolog — можно.

При их решении уравнений не нужно следить ни за стеком вызовов, ни за условиями выхода из цикла, ни за чем иным.
Дык и в Haskell за всеми этими вещами — тоже не нужно следить.

Собственно основная проблема с прологом — как раз в том, что если компьютеру просто так взять и разрешить переносить из одной части в другую и никак его не ограничить, то он преобразует a = b + c в b = a - c, потом обрано в a = b + c — и так и будет переносить по кругу, пока солнце не потухнет (или, что более вероятно, пока программу не остановят).

Такого объяснения обычно вполне хватает: всё-таки компьютер туп и потому переносить приходится программисту… но зато уж он это всегда может сделать — и это не приведёт к катастофе.
Что значит «вычисляется»? Как это вообще понять?
Разименновываем переменную и вычисляем. До левой части ещё не дошли. Для закрепления предлагаю подумать над
a, b = b, a + b

То есть если написано, что x = x + 1, то это значит, что x = x + 1… но это же бред!
Бред это haskell, не позволяющий в одном пространстве имён держать две структуры с одинаковым названием полей. И потом
a : List String -> List Int
a i = List.map String.length i

b : Int -> Int
b i = i + 1

c i = List.map (\x -> x + 1) i

Как же так, в одном месте i это список, а в другом — число? А x вообще в одной и той-же строке значение меняет.
Неявное умножение — это как раз ближе к вызову функций в Hasekll'е.

Подобный сахар есть и в ruby
puts "a"
puts("a")

Там всё равно переменная ведёт себя совсем-совсем не так, как на уроке математики.
На уроке математики есть неизвестная, которая является локальной константой на протяжении всего уравнения.
Есть-есть, вы просто про них забыли. Вот буквально то же квадратное уравнение когда решаете — там фигурная скобочка появляется и, справа от неё, три варианта: D > 0, D = 0, D < 0.
Только вот алгоритм записывается не математическим языком, а самым обычным разговорным. А в разговорном языке нет разницы между «присваиванием» и «сравнением», есть только «равно». А почему «равно» не важно. В императивном есть ещё «повтороное присваивание». Присваивание или инициализация выглядит так
a : Int
a = 1

А где в C# впервые встречается макропроцессор?
В C# нет, в nemerle, rust, nim…
Ну это уже чистая косметика… как и макропроцессор…
Эта косметика нужна, если не хочется интерфейс командной строки использовать
Дык и в Haskell за всеми этими вещами — тоже не нужно следить.
И как haskell решил проблему остановки? И зачем тогда нужен "!", кроме как стек подпирать, чтобы он не разбух?
Разименновываем переменную и вычисляем. До левой части ещё не дошли.
Что значит «не дошли»? Что значит «разименовываем»? Вы тут заменили одну непонятную вещь парой-тройкой других. Столь же непонятных.

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

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

В императивном есть ещё «повтороное присваивание».
И вот, собственно, повторное присваивание и «взрывает мозг» новичкам… потому что в математике его нет.

И как haskell решил проблему остановки?
Никак не решил. А надо?

И зачем тогда нужен "!", кроме как стек подпирать, чтобы он не разбух?
Строго говоря он и не нужен. Однако позволяет обнаружить ошибки гораздо раньше. Если рассматривать это только как пометки для оптимизатора
то это примерно на том же уровне полезности, что и какой-нибудь std::launder в C++.

К тому моменту, как вам это потребуется знать — вы уже сможете написать куча практически полезных программ.

А вот с x = x + 1, в императивном языке, вы столнётесь сразу. Чуть не в первой программе.

Кстати в этом смысле неплох Python как первый язык: в нём можно достаточно долго поддерживать иллюзию, что переменные у нас — это переменные в математическом смысле. Конечно в какой-то момент вы упрётесь в a, b = b, a + b, но, по крайней мере, к этому времени вы уже будете что-то уметь и знать. Это не будет тем, с чем вы столкнётесь «с самого начала»…
Что значит «не дошли»? Что значит «разименовываем»? Вы тут заменили одну непонятную вещь парой-тройкой других. Столь же непонятных.
Вам нужно прямо тут расписать алгоритм для новичков?
Однако может приниматься разные значения в многократно применённой лемме.
Можно пример на уровне «квадратных уравнений»? Или речь о системах уравнений, где каждое из них надо сокращать?
И вот, собственно, повторное присваивание и «взрывает мозг» новичкам… потому что в математике его нет.
В математике и химческих веществ нет. Так что, когда ученики видят реакцию химических веществ/ядерные реакции, то у них тоже мозг взрывается? Во-первых реакции протекают односторонне, во-вторых там ни сокращений, ни общих множителей, ничего подобного.

Неужели они ни разу не пользовались ни почтовыми ящиками, ни гардеробом с жетонами, ни ящиками для сумок в супермаркете, ни папками с названиями, ни листочком на который записывают траты за месяц, ничем иным? Не верю.
Никак не решил. А надо?
Бесконечная рекурсия ничем не отличается от бесконечного цикла, разве что может весь стек съесть.
Строго говоря он и не нужен
space leak не существует?
Что значит «не дошли»? Что значит «разименовываем»? Вы тут заменили одну непонятную вещь парой-тройкой других. Столь же непонятных.

Вам нужно прямо тут расписать алгоритм для новичков?
Нет. Объяснить как вдруг, внезапно, человек, который всего этого не знает — должен вдруг понять и осознать всё это. Всего лишь, чтобы понять что такое x = x + 1 в одной из первых программ в его жизни. Для этого ему нужно одномоментно освоить массу новых понятий. Что сложно.

Можно пример на уровне «квадратных уравнений»? Или речь о системах уравнений, где каждое из них надо сокращать?
Да. Хотя бы система из двух квадратных уравнений (а можно и в одно уравнения их пару засунуть). Там у вас будет несколько дискриминантов — и они все будут обозначаться буквой «D».

Так что, когда ученики видят реакцию химических веществ/ядерные реакции, то у них тоже мозг взрывается?
Вы не поверите, но да. Мы как-то проводили исследование, но оказалось, что программистов с Химфаков и Физфаков — у нас чуть ли не больше, чем с Мехмата.

Неужели они ни разу не пользовались ни почтовыми ящиками, ни гардеробом с жетонами, ни ящиками для сумок в супермаркете, ни папками с названиями, ни листочком на который записывают траты за месяц, ничем иным? Не верю.
Они, конечно, всем этим пользовались. И выделив на эту пару уроков можно-таки объяснить что такое x = x + 1… но это занимает именно что пару уроков, а не 10-15 минут.

Строго говоря он и не нужен
space leak не существует?
На учебных задачах — нет. А к тому моменту, когда вам это реально потребуется — вы уже будете не новочком, а человеком написавшим не одну программу и не две.
Объяснить как вдруг, внезапно, человек, который всего этого не знает — должен вдруг понять и осознать всё это. Всего лишь, чтобы понять что такое x = x + 1 в одной из первых программ в его жизни. Для этого ему нужно одномоментно освоить массу новых понятий. Что сложно.
С ассемблером у них тоже проблемы? Там как-никак регистры, а не переменные.
Мы как-то проводили исследование, но оказалось, что программистов с Химфаков и Физфаков — у нас чуть ли не больше, чем с Мехмата.
Что ещё, кроме количества, учитывалось?
А к тому моменту, когда вам это реально потребуется — вы уже будете не новочком, а человеком написавшим не одну программу и не две.
Даже 200 программ из учебника не дадут большого опыта. Разве что к синтаксису языка привыкнуть и названия функций запомнить. Я не слышал о лабораторных работах, более-менее приближённых к реальным задачам. Понимание приходит либо во время работы, либо во время попыток сделать что-то для себя. И вот во втором варианте на space leak наткнуться возможно.
С ассемблером у них тоже проблемы? Там как-никак регистры, а не переменные.
Ассемблер. Школьникам. Нет, ну из тех 2-3%, которые это переживут — может что-то и получится. Но с остальными 95-97% как?

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

P.S. На самом деле, конечно, сразу давать Haskell — это жестоко. У нас в школе использовали LISP — причём упрощённую версию.
Ассемблер. Школьникам. Нет, ну из тех 2-3%, которые это переживут — может что-то и получится. Но с остальными 95-97% как?
Зачем прораммирование 97% школьников? Одно дело обучать тех, кто в этом заинтересован и не будет саботировать занятия, и совсем другое — тех кому это совершенно не нужно.

По своему опыту могу сказать: тянуть одновременно все предметы невозможно, и рано или поздно возникает вопрос в том что не учить. В моей школе под удар попала химия, и подавляющее большинство не могло написать даже элементарную реакцию, вроде SO₃ + H₂O. Даже если предыдущему ученику только что объяснили как уравнивать коэфициенты, следующий всё равно не мог это сделать. Вызывали не каждый урок, и за это время гарантированно забывались.

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

Я не верю в то, что школьники не способны понять концепцию повторного присваивания. Они просто всеми правдами и неправдами пытаются тратить меньше времени на просиживание в школе и дома за домашней работой. Я немного общался с теми кто «программировал», все они как по мановению волшебной палочки забывали все свои навыки и любой вопрос, например «почему программа не работает, если под одним бесконечным циклом поместить другой», ставил их в тупик.
Ну и ничего особо страшного в этом нет: те, кто смогут забраться так быстро и так далеко, что им в первый год это потребуется — скорее всего смогут всё осилить.
ИМХО сравнивать сложность империативного и функционального программирования для школьников — бессмысленно. Я лишь хотел сказать, что для функциональных языков тоже характерны некоторые вещи, напрямую следующие из особенностей выполнения программы компьютером. И что сложная программа на C++ будет иметь определённые подпорки, что на Haskell
P.S. На самом деле, конечно, сразу давать Haskell — это жестоко. У нас в школе использовали LISP — причём упрощённую версию.

В этом вся суть — знания подаются достаточно специфические, в реальности либо бесполезные, либо требующие дополнительной подготовки, что дополнительно снижает мотивацию всё это изучать. Я промолчу про выбор динамически типизированного языка для старта. При этом прививается навык зубрёжки, так как на ЕГЭ всё равно нельзя будет пользоваться ни калькулятором, ни формулами.

ЗЫ я не против обучения школьников, но только в случае если они сами этого хотят и если это происходит «как у взрослых», без всяких примитивных диалектов, надуманных примеров и прочего.
При этом прививается навык зубрёжки, так как на ЕГЭ всё равно нельзя будет пользоваться ни калькулятором, ни формулами.
Когда я учился в школе, слава богу, ЕГЭ не был целью обучения.

Так-то если у вас задача — не научить людей программировать, а «натаскать» на ЕГЭ, то всё это однозначно не нужно.

ИМХО сравнивать сложность империативного и функционального программирования для школьников — бессмысленно.
Почему бессмысленно? У нас было очень мало людей, не сумевших, скажем, расставить ферзей на доске на LISP — до достаточно тех, кто не сумел написать сортировку слиянием на Pascal.

Это достаточно объективный критeрий. Просто когда вы говорите, что программа — это, на самом деле, просто функция, которая может быть записана так, что её может посчитать компьютер… то как бы это сразу позволяет «подключить» всю математику, которые школьник изучал долгие годы. А когда вы начинаете вводить кучу понятий до того, как что-то можно сделать… это сложнее.

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

Объяснения всего языка — занимают полчаса. С запуском интерпретатора и показом того, как это всё работает. И сразу можно решать задачки. В том числе довольно сложные — вплоть то метапрограммирования.

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

При решении квадратных уравнений — да, скорее всего замыканий не будет. А вот "немного" дальше...


Рассмотрим широко известное преобразование Фурье:


формула


В правой части этого преобразования интегрируется довольно простая функция: h(x) = f(x)e-ixω. Внимание, вопрос: откуда в этой функции взялась переменная ω? :-)

Так что в этом смысле LISP (и диалекты) кардинально проще других ЯП (где нужно помнить много хитрых значков, отступов и ключевых слов и что они значат в том или ином контексте).
Хитрые значки/ключевые слова всё равно придётся запоминать, только идти они будут не из коробки.

Трагедия Common Lisp в том, что мало у кого есть желание как следует разобраться в этом чрезвычайно интересном и мощном языке, спроектированном лучшими умами того времени. Все в основном слышали звон про размер стандарта и скобки. Автор оригинальной статьи тоже не удосужился, что совершенно явственно из его комментариев к оригинальной статье.


Рекомендую, кстати, также почитать оригинальное обсуждение по ссылке. Там автор статьи решительно выступает против введения let-statements.

Sign up to leave a comment.

Articles

Change theme settings