Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП?

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

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

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

Интересно, продолжайте.

Также вопрос: какие языки выбирают сообразительные программисты или какие языки делают программиста сообразительным?

Всё ж примитивно. Чтоб аргументировано утверждать что дело только в «детской талантливости», нужно убрать другие отличие. Я перечислил важные по моему мнению.

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

Лень впереди всего бежит.

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

Лень впереди всего бежит.

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

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

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

Почему же тогда дети не сидят в офисах по 8 часов или не точат болванки у станков?

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

Вот к примеру, почему на форумах диалоги часто переходят на «личности»?

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

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

Вот к примеру, почему на форумах диалоги часто переходят на «личности»?

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

Но ты почему-то не хочешь связывать это симптомы со школой.

С школы только пару учителей и вспоминаются иногда /да и с ВУЗа/.
Здесь «замес» очень крутой.
Учитель может быть и хорошим, ... и да некоторые из них помогают детям прочувствовать, что «доброта» это хорошо.
Но детей окружает такой «замес» /надеюсь понятно о чем речь/, что они в многом разочаруются и более того.
Сейчас мы быстренько подойдем к обсуждению того, что такое «мораль» и что бывает с теми, кому «все дозволено».

Также вопрос: какие языки выбирают сообразительные программисты или какие языки делают программиста сообразительным?

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

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

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

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

Совсем уже в оффтоп скатываемся, модеры достали мне уже карму резать. Коротко: да, про этот замес я уже который пост и пишу.

Совсем уже в оффтоп скатываемся,

Так форум то профильный ...
Чтобы модераторы «не сердились» вам, мне и другим «меру» нужно знать /мне правда проще/.

Позволю себе еще один /и пора меру знать/ коммент.
«Плохим стать не сложно, хорошим куда трудней».

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

Java была создана для превращения кодеров в скот.

Значит нужно изучать хорошие языки.
Хотя Джава не мешает писать хорошие программы. Скорее мешает что-то другое.

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

Это проблема курицы и яйца: окружение формирует человека, а человек формирует окружение. Искать, кто был первый и кто был виноват - неблагодарное дело: то ли человек случайно попал в некоторое окружение, то ли мама не хотела, то ли папа не старался, то ли всё это вместе. Я лишь хотел сказать, что механические исполнители тянутся к жаве, а жава поощряет механическое исполнение. Человек, может быть, и мог бы стать хорошим программистом, но вместо этого он пишет на жаве - потому что востребовано. Может он и хотел бы научиться чему-то, но не может, потому что он пишет на жаве и других вариантов на текущий момент не видит. И чтобы научиться говорить на английском языке, нужен кто-то, с кем он может общаться на английском - но вокруг люди говорят только на жаве. Ферштейн? Окружение сформировало человека и человек сформировал окружение. Разорви круг с любой стороны - сможешь выйти.

Хотя Джава не мешает писать хорошие программы. Скорее мешает что-то другое.

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

Инструмент решает очень много, он составляет половину успеха, а вторую половину - сам мастер, пользующийся инструментом.

Кармак и Линус вообще на сях писали и пишут, другого не признавали (хотя Кармак таки осилил cpp и сказал что некоторое его разумное подмножество не говно). А теперь вспомним как си убог, нету неймспейсов, перегрузки операторов и тем более паттерн матчинга, и тем не менее это инструмент суперзвезд которые двигают индустрию, они делают чудеса таким инструментом. Так что даже жаба не помешает хорошему разработчику, просто 90% разрабов это посредственности, обычные люди со средними способностями, я сам такой, но мне нравится писать код, я не вайтишник, даже если бы за эту работу не платили как платят сейчас скорее всего я бы стал программистом. Пишу на жабе за деньги, на котлин и тайпскрипт для себя. Хочу ли я чтоб моя команда перешла на котлин? Нет, я вижу как написан код проекта, вижу что во многих местах можно было написать на жабе лучше, но сделано как сделано, и язык с большим количеством абстракций не поможет, станет еще хуже потому что появится еще N новых способов сделать паршиво и нечитаемо.

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

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

Давай разберем сказанное по частям.

Кармак и Линус вообще на сях писали и пишут, другого не признавали

Я уже описывал здесь это явление - это никсовые ретрограды. Это те самые люди, которые будут писать на баше с сями и в экосистеме юникса до последнего, даже если это уже неудобно, даже если создает кучу издержек. Здесь многие поклоняются Торвальдсу, но давайте посмотрим правде в глаза: при всех его высоких способностях к кодингу и оперированию сложными логическими сущностями, он - аутист, которому просто нравится пердолиться ради пердолинга, выкладывать пирамидки из сущностей как самоцель:
https://commons.wikimedia.org/wiki/File:Autism-stacking-cans_2nd_edit.jpg?use...
https://commons.wikimedia.org/wiki/File:Autistic-sweetiepie-boy-with-ducksina...
Торвальдса не просто не волнует кол-во ошибок, которое есть и будет в ядре вследствие использования низкоуровневого языка - его даже радует, что ему есть с чем пердолиться, что можно развлекаться отловом ошибки неправильного барьера памяти с шансом воспроизведения 1/10 000 000.

хотя Кармак таки осилил cpp и сказал что некоторое его разумное подмножество не говно

Я тоже это говорю. Но здесь есть люди, которые не согласны с игроделами, вроде Кармака или кого-то там из Unity.

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

Ком-пи-ля-тор. Двигает индустрию именно он, а не какие-то там суперзвезды. Сделай сверхоптимизирующий компилятор для паскаля - будут проекты на паскале, будет тебе квейк и юнити на паскале. Собсна, паскаль и получил распространение из-за того, что борланд сделал такой компилятор. Но на стыке веков у борланда возникли проблемы, и паскаль сдох: современные продукты Embarcadero пишут индусы за еду, а FPC довольно вяло разрабатывается.

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

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

просто 90% разрабов это посредственности, обычные люди со средними способностями, я сам такой, но мне нравится писать код

А ты - оптимист. Я бы давал оценку 95-98%.

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

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

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

Пишу на жабе за деньги, на котлин и тайпскрипт для себя

А я на Делфи писал за деньги. Но я не строю никаких иллюзий по этому поводу - оно меня вполне ощутимо разлагало. Особенно разлагали отбитые наглухо коллеги, которые являются целевой аудиторией сего средства разработки. Идея Object Pascal была изначально провальна как инструмент, но успешна коммерчески - по крайней мере в конце 80-х и в 90-х. Настоящий наследник паскаля - это Rust, пусть и опосредовано. Я имею в виду строгую типизацию указателей на фоне ручной работы с памятью.

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

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

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

У психиатра наблюдаешься?

У психиатра наблюдаешься?

Нет, но был однажды на обследовании. А что?

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

Возможно стоит сходить и рассказать о планах джавистов, и всем таком

А ты, я смотрю, там не был. Там есть много поехавших, и это не пациенты.

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

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

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

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

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

Поэтому выводок разноплановых вундеркиндов будет лучше всяких слов. И вам хорошо и меня посрамите.

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

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

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

что такое „машина общего назначения“? байткод (или машинные коды) для лифта это машинный код или нет?

В байткоде JVM нету GC. Никто не будет делать сборку мусора в железе - ему месте в софте.

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

Что в словах «те же» тебе непонятно?

Мне не понятно, с чего ты взял, что

JVM - это штука, весьма близкая к машинному коду обычного процессора, потому машинная реализация провалилась - она не давала никакого значимого преимущества над обычным процессором

поищи в гугле „fpga jvm“ и прозрей. железной джавой кто только не занимался и всё ради оптимизации. даже джазель в армах именно для этой цели была. Так что ты херню сморозил.

есть jal/jr для вызова подпрограмм и возврата из них

а теперь попробуй вызвать jal два раза подряд без сохранения %ra и догадайся куда вернётся второй ret, хехе)

регистр $sp (29)

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

в дополнение к стэку есть 16 регистров для передачи аргументов

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

Язык мне незнаком, скорее всего какой-то идрис, но идея примерно ясна. Здесь нет состояния модуля, а ты определял объект, как функцию с состоянием модуля. Давай тогда отказывайся от этого определения, и определяй объект как имеющий отдельное состояние.

это окамель обыкновеный. никаких „модулей“ тута нету, это ф-ия возвращающая кложуру и всё.

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

с какого? а если я в спп члены класса засуну в отдельную структуру, и агрегирую её в клас, мне тоже надо „определять объект как имеющий отдельное состояние“? ты смешной))

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

Типов реальных задач ровно два:

- накидать побырому прототипчик чего-нибудь

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

А поскольку ресурсов всегда ограниченное количество (сюрприз, сюрприз), то и вариантов немного.

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

В скриптоте ничего плохого нет, какой-нибудь там VSCode вполне себе, если не падать в обморок от некошерного js.

Та же жаба тоже хороша на своем месте.

Код, который есть, всегда лучше, чем гораздо более совершенный код, которого нет.

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

Научитесь пользоваться тем что есть и будет вам счастье.

Поэтому выводок разноплановых вундеркиндов будет лучше всяких слов

Я не понял смысла запроса. Имеется в виду, что я должен предоставить какой-то эксперимент, где поголовно все обученные дети добивались больших успехов? Я тебе больше скажу - мне удалось однажды пообщаться с очень известным вам человеком, правда, на тот момент я не знал, кто он (чисто случайно получилось). Дети в семье поголовно хорошо интеллектуально развиты, просто один из них стал еще и известен на всем СНГ и за пределами. Мне удалось по крупицам собрать инфу об воспитании - оно серьезно отличается от того, через что проходит житель офиса. По понятным причинам эти детали не публичны, и я тоже не собираюсь их публиковать.

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

Еще есть некоторые школы/культуры, которые, грубо говоря, вместо 98% брака выпускают только 95%. Можно ещё меньше, но людям наверху это невыгодно.

... почему ООП .. а не ФП? ...

... целая куча функциональных языков (APL ...

А вы вебсайт сверстать могли бы На скобках Айверсона в APL?

байткод (или машинные коды) для лифта это машинный код или нет?

Лифт - вычислительная машина специального назначения.

что такое „машина общего назначения“? байткод (или машинные коды) для лифта это машинный код или нет?

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

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

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

поищи в гугле „fpga jvm“ и прозрей. железной джавой кто только не занимался и всё ради оптимизации. даже джазель в армах именно для этой цели была.

Хайп-хаупусик. Старая Jazelle DBX представляла собой аппаратный транслятор байткода в машинный код - как видишь, этот байткод повис в классификации где-то посередине. А вообще, Jazelle сдохла, хвост облез, кто промолвит - тот и съест.

Остался только ThumbEE, оно же Jazelle RTC (на Cortex-A8 старую джазелю выкинули вообще), который по сути есть Thumb-2 плюс таблица обработчиков и 5 дополнительных инструкций, являющийхся тупо командами условного и безусловного перехода к этим обработчикам, а также в старые команды «читать-писать в сопроцессор» и «ветвление по таблице» добавлен встроенный условный переход на обработчик NullCheck.
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489i/CHDHBBHG...

Так что как ни крутись, а машинный код все равно сохраняет свою форму.

есть jal/jr для вызова подпрограмм и возврата из них

а теперь попробуй вызвать jal два раза подряд без сохранения %ra и догадайся куда вернётся второй ret, хехе)

Ты думаешь, почему в ARM-е сделали LR, который в том числе используется для вышеупомянутых инструкций ThumbEE, HBL и HBLP? Это реально эффективнее, особенно если обработчик короткий. А адрес возврата ты уже сохраняй куда хочешь: хоть в статическую память, хоть в динамическую, хоть в какой-то другой регистр. Функция ведь может отработать вообще без обращения к памяти, но x86 заставляет процессор писать в память.

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

Кобол, Фортран, Алгол 58 решали эту проблему очень просто: локальные переменные выделялись в памяти статически, так что не нужно было никакого стэка. Я смотрю, интель со своим стэком из x86 совсем уже заморочил кодерам мозги. Аппаратный стэк x86 ущербен и на динамике, на самом деле, потому что сам стэк статичен, его нельзя просто разбить на какие-то части, чтобы не было stack overflow - классической ошибки, характерной для архитектуры x86.

а если я в спп члены класса засуну в отдельную структуру, и агрегирую её в клас, мне тоже надо „определять объект как имеющий отдельное состояние“?

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

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

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

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

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

Управление памятью? Нивапрос. И это не обязательно GC или подсчет ссылок, хотя об этом любят кудахтать на каждом углу. ОК, эмбедщики еще могут вспомнить о memory pool. Если приложить мозг, то есть и другие, гораздо менее замороченные и более дешевые в имплементации (и в тактах) решения.

Инкапсуляция? Полиморфизм? Их есть у меня.

Обработка ошибок? Да пожалуйста.

Автоматическое управление ресурсами? Нате. (Восторженные бурления вокруг try-with-resources это цирк еще тот, если учесть что все это делается на примитивном С и без этого хайпа.)

Грин-трэды? Корутины? Горутины? С планировщиками или без?

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

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

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

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

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

Управление памятью? Нивапрос. И это не обязательно GC или подсчет ссылок, хотя об этом любят кудахтать на каждом углу. ОК, эмбедщики еще могут вспомнить о memory pool. Если приложить мозг, то есть и другие, гораздо менее замороченные и более дешевые в имплементации (и в тактах) решения.

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

Инкапсуляция? Полиморфизм? Их есть у меня.

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

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

Обработка ошибок - это большая проблема для сей, из-за которых приходится городить многочисленные вложенные блоки, которые все равно после пары правок сломаются. Просто часто программисты делают ошибки еще и при написании кода обработки ошибок, а проверять ошибочные ситуации часто тяжелее, чем правильные. Эталонную реализация обработки ошибок ты можешь увидеть в Go - там ее собираются немного подсластить, чтобы упростить синтаксис if err != nil {...}, но в реальности это необязательно, и вполне можно обойтись имеющимися средствами, а именно - defer, panic, recover.

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

Хорошо. Вылепи мне реализацию defer из Go в Си. Желательно, так, чтобы с ним было проще, чем без него.

Сишечка как пластилин, можно вылепить любой фреймворк

Именно так!
Кто «лепить» не может, тот этого не поймет.

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

Это основная беда людей. Проблемы управления памятью проистекают из того, что ей не управляют. malloc & free - яйца и мука, а пирог еще надо уметь испечь. У большинства получается гуано, а не пирожное. Однако мука и яйца тут ни при чем.

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

У этих слов есть вполне себе прикладной смысл. И ООП тут только тем боком, что на соседнем гектаре лежало.

Обработка ошибок - это большая проблема для сей из-за которых приходится городить многочисленные вложенные блоки

Да ладно. Не буду напрягать модными концепциями, но посмотри хотя бы как выполняется обработка ошибок( а также освобождение ресурсов) в ядре. Дешево и сердито.

Хорошо. Вылепи мне реализацию defer из Go в Си. Желательно, так, чтобы с ним было проще, чем без него.

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

src, err := os.Open(srcName, os.O_RDONLY, 0)
    if err != nil {
        return
    }
    defer src.Close()

with_file(f, "somefile.txt") {
  // file should be closed automatically
  fread(f, ....);
}

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

Если не пойдет - хотелось бы понять почему.

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

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

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

with_file(f, «somefile.txt») {
Если пойдет, то при помощи небольшой ловкости рук на сях запилить несложно.

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

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

Буквально минуту потратил, чтобы наугад найти более-менее большой модуль. Пожалуйста, 13 строк из штатного алгоритма, но плюс к ним - куча условий и goto. Именно об этом я и писал:
master/ipc/mqueue.c

static inline struct msg_msg *msg_get(struct mqueue_inode_info *info)
{
	struct rb_node *parent = NULL;
	struct posix_msg_tree_node *leaf;
	struct msg_msg *msg;

try_again:
	/*
	 * During insert, low priorities go to the left and high to the
	 * right.  On receive, we want the highest priorities first, so
	 * walk all the way to the right.
	 */
	parent = info->msg_tree_rightmost;
	if (!parent) {
		if (info->attr.mq_curmsgs) {
			pr_warn_once("Inconsistency in POSIX message queue, "
				     "no tree element, but supposedly messages "
				     "should exist!\n");
			info->attr.mq_curmsgs = 0;
		}
		return NULL;
	}
	leaf = rb_entry(parent, struct posix_msg_tree_node, rb_node);
	if (unlikely(list_empty(&leaf->msg_list))) {
		pr_warn_once("Inconsistency in POSIX message queue, "
			     "empty leaf node but we haven't implemented "
			     "lazy leaf delete!\n");
		msg_tree_erase(leaf, info);
		goto try_again;
	} else {
		msg = list_first_entry(&leaf->msg_list,
				       struct msg_msg, m_list);
		list_del(&msg->m_list);
		if (list_empty(&leaf->msg_list)) {
			msg_tree_erase(leaf, info);
		}
	}
	info->attr.mq_curmsgs--;
	info->qsize -= msg->m_ts;
	return msg;
}

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

Нет, Си безальтернативен в предметных областях, где они работают. У Линуса, грубо говоря, все языки делятся на «подходит для написания ядра» и «НЕ подходит для написания ядра». Ему, как правило, не интересны другие предметные области. Он писал «С++ не подходит потому, что ...», а как только понадобилось написать ПРИКЛАДНУЮ программу - взял С++ (хотя на самом деле Си с классами, но всё же) и Qt и написал программу. На инструменте, сделанном для этой предметной области, где его знания сишки были актуальны. Ну а то, что гит написал на сишке - гит низкоуровневый инструмент, он был как рыба в воде.

У Кармака пик карьеры пришёлся на зарождение геймдева под PC. С помощью хитрых оптимизаций на си (у него тогда не было современных компиляторов с крутыми оптимизациями) он обеспечил работоспособность продуктов на том железе. Только настоящий лоу левел позволяет нормально оптимизировать. Потом переметнулся в VR и что-то с ракетами, где требования к надёжности и максимальной производительности признают состоятельным только си.

он - аутист

Это все «диванные психиатры» - аутисты, ставят диагноз на основании малого количества данных. Предметная область ядра гораздо больше и разнообразнее, чем какой-нибудь web fullstack.

которому просто нравится пердолиться ради пердолинга

Под это описание подходят все адепты малопопулярных ЯП. Используя твои аргументы, можно назвать всех адептов раста, хаскеля, лиспов... аутистами.

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

Прими разупорин, ядро можно писать ТОЛЬКО на лоулевел языке.

Ком-пи-ля-тор. Двигает индустрию именно он, а не какие-то там суперзвезды.

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

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

У игроделов жёсткие дедлайны и бОльшая объективная сложность задач. Движок минимум на Си с классами, а как раз описание механик геймплея - как правило скриптуха (луа или велосипед). Глючит код, написанный геймдизайнерами на скриптухе, которые программистами себя не считают. Когда ошибка в коде на С++ - игра, как правило, вылетает. Действительно, месяц работать по 12+ часов в сутки - откуда могут быть баги?

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

Как раз Java и C# изначально проектировались на полную интеграцию с ide. Си с классами тоже ide-friendly.

А я на Делфи писал за деньги. Но я не строю никаких иллюзий по этому поводу - оно меня вполне ощутимо разлагало.

Чувствовать ущербность инструмента, с которым работаешь - хороший знак.

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

Вот такой стиль имеется в виду? )

int foo(int bar)
{
    int return_value = 0;
    if (do_something(bar))
    {   
        if (init_stuff(bar))
        {
            if (prepare_stuff(bar))
            {
                return_value = do_the_thing(bar);
                cleanup_3();
            }
            cleanup_2();
        }
        cleanup_1();
    }
    return return_value;
}

Но зачем? Ведь можно и так.

int foo(int bar)
{
    int return_value = 0;
    if (!do_something(bar)) {
        goto error_1;
    }
    if (!init_stuff(bar)) {
        goto error_2;
    }
    if (prepare_stuff(bar))
    {
        return_value = do_the_thing(bar);
        cleanup_3();
    }
error_2:
    cleanup_2();
error_1:
    cleanup_1();
    return return_value;
}

А можно и так:

#include <stdio.h>
#include <stdlib.h>

#define error_if(condition, message) if(condition) { perror(message); goto done; }

int f(const char* filename) {
   int return_code = EXIT_FAILURE;
   FILE* f = NULL;
   int* xs = NULL;

   f = fopen(filename, "r");
   error_if(NULL == f, "Could not open input file");

   size_t n;
   error_if(EOF == fscanf(f, "%zu ", &n), "Could not read array size from input file");

   xs = calloc(sizeof(int), n);
   error_if(NULL == xs, "Could not allocate int array");


   for(int i = 0; i < n; i++) {
      error_if(EOF == fscanf(f, " %d ", &xs[i]), "Could not read from input file");
   }

   for(int i = n - 1; i >= 0; i--) {
      printf("%d ", xs[i]);
   }
   printf("\n");

   return_code = EXIT_SUCCESS;

done:
   free(xs);
   if(NULL != f)  fclose(f);
   return return_code;
}

int main(int argc, char* argv[]) {
   f(argv[1]);
   return 0;
}

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

Улавливаешь?

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

Учите матчасть (с).

master/ipc/mqueue.c

ядреный легаси.

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

Семен Семеныч (с)

for(initialize_what_you_want(); check_everything_you_want(), done_and_gone(); prepare_each_iteration_you_know_how()){
  // do smth important
}

И мильон других способов сахара добавить. Но не слишком много - от сладкого диабет )

Не всегда это нужно\ оправдывает себя. Нужно - делаем, не нужно - не делаем. Почувствуйте разницу (с).

Т.е. фактически заменить массовую школу у вас нечем.

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

Вот такой стиль имеется в виду?
Но зачем? Ведь можно и так.
goto error_1;
goto error_2;
goto error_3;
А можно и так:
#define error_if(condition, message) if(condition) { perror(message); goto done; }

Ты сейчас серьезно, да? Отсутствие достаточно эффективных механизмов структурированного описания задач вынуждает использовать профессора Гото, из-за чего задача сохранения корректности скомпилированного кода перекладывается на плечи программиста - и он обязательно в ней ошибется. Да, в Go defer делается тем же Гото, и try-finally в крестах/жаве/etc работает на Гото, но дело в том, что там транслятор гарантирует корректность выполнения, ему проще управлять спагетти кодом.

В версии Go 2 и вовсе большинство функций с подобными проверками будут записаны линейно, но пока что как-то так:

int foo(int bar)
{
    int return_value = 0;
    defer cleanup_1();
    if !do_something(bar)
        return return_value;
    defer cleanup_2();
    if !prepare_stuff(bar)
        return return_value;
    if init_stuff(bar)
    {
        defer cleanup_3();
        return return_value;
    }

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

Не, ты забываешь про вторую половину гит - это баш. Баш, потому что Линус ничего другого не умеет. Сравни какой-нибудь меркуриал, который написан на C+Python - вот это грамотный выбор инструментов.

Он писал «С++ не подходит потому, что ...», а как только понадобилось написать ПРИКЛАДНУЮ программу - взял С++ (хотя на самом деле Си с классами, но всё же) и Qt и написал программу.

Какую прикладную программу он писал на Qt?

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

Си, надежность - смешно, спасибо.

Под это описание подходят все адепты малопопулярных ЯП. Используя твои аргументы, можно назвать всех адептов раста, хаскеля, лиспов... аутистами.

Хаскель - да. Лисп, раст - нет, это вполне прагматичные языки.

Прими разупорин, ядро можно писать ТОЛЬКО на лоулевел языке.

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

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

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

Глючит код, написанный геймдизайнерами на скриптухе, которые программистами себя не считают. Когда ошибка в коде на С++ - игра, как правило, вылетает.

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

Действительно, месяц работать по 12+ часов в сутки - откуда могут быть баги?

Баги будут всегда. Хоть ты будешь работать по 12+ часов, хоть 2 часа в день и тщательно анализировуешь код - все равно в достаточно большом проекте будут ошибки, просто их будет меньше.

Как раз Java и C# изначально проектировались на полную интеграцию с ide. Си с классами тоже ide-friendly.

Так почему же их не было ни при Oak, ни при релизе Java в 1995? Почему же потом появились только отдельные инструменты, а первую IDE начали делать чехи в 1996 году с пре-релизом в 1997 году? В Visual Age поддержку Java только в 1997 году сделали, где-то в то же время переделали и VisualAge со Smalltalk на Java. Это при том, что Oak разрабатывался с 1991 года! Это была очевидная реакция на популярность языка. Что делал в это время Sun в плане IDE для языка, который разрабатывался для IDE? Ничего. Sun запрыгнул в уже едущий поезд, приобретя в 1999 году Xelfi, он же NetBeans. Очевидно, Sun сам не знал, что проектировал Java на полную интеграцию с IDE.

Ты точно читал код из примера номер три? Тот , в котором макро

#define error_if(condition, message) if(condition) { perror(message); goto done; }

Расскажи-ка мне что там помнить и где можно ошибиться.

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

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

На вкус и цвет, но готов принять что тебе так проще жить.

Тогда сделай так

  with(int *myint, my_malloc(sizeof(int)), free){
    *myint = 10;
    printf("myint is located at %p and contains: %d\n", myint, *myint);
    printf("%s\n", __func__);
  }
 //printf("%d", myint); // <- Will not compile because `myint` is out of scope

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

defer всего лишь помещает вызовы в стэк. И при выходе из ф-ции стэк освобождает. Тебе прям вот написать как именно это запилить? Или сам?

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

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

Повторяю, в отличие от го\жабы\пайтона\подставить нужное тебя никто не принуждает к «заведомо правильному решению». Сделай как целесообразно,как ТЕБЕ удобно и пользуйся.

for(initialize_what_you_want(); check_everything_you_want(), done_and_gone(); prepare_each_iteration_you_know_how())

Нормус. Но мне кажется, что для варианта с return/break это не помогает.

фактически заменить массовую школу у вас нечем

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