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

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

goto еще забыл.

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

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

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

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

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

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

среда такая в любом случае создаётся, даже интуитивно.

школа и ВУЗ мешает изучать ин.яз.

ну не знаю, я билингва/трилингва с детства, лет с 5 третий язык. в школе опять же третий инглиш более подробнее, где-то с третьего класса. вырезали из бумаги квадратики, треугольничики, круги (подлежащие/сказуемые/ит.п., Verb/Subject/Object), выкладывали их в нужном порядке, рисовали схемки для утвердительных/вопросительных и т.п. предложений, запоминалось очень наглядно. потом аудирование в слух, 2-3 часа только на инглише. потом параллельно для себя учил немецкий, японский, китайский. скажу так, изучение инглиша первым иностранным после двух нативных помогло изучению второго немецкого (который даже проще, просто произносить мозголомнее), и наоборот.

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

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

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

Почему-то это получается у почти всех детей, но получается плохо почти у всех взрослых.

просто они изучают неправильно, ненаглядно, запутанно. вот и результат — плохо.

Ты точно читал код из примера номер три? Тот , в котором макро
#define error_if(condition, message) if(condition) { perror(message); goto done; }
Расскажи-ка мне что там помнить и где можно ошибиться.

Хорошо, давай разберем по пунктам, в чем проблема этого кода:
- код высвобождения отделен от кода выделения, хотя логически они долны стоять вместе;
- здесь второй ресурс - это xs = calloc, которая в неинициализированном состоянии xs = NULL. Если бы это была какая-то критическая секция, то пришлось бы ставить дополнительный флаг, или делать error2_if для освобождения секции;
- скажи мне, что ты будешь делать, если printf("%d ", xs[i]) не сможет вывести строку из-за того, что stdout был закрыт? Здесь я говорю о принципиальной нерасширяемости подхода.

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

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

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

а по-моему, «программеров», неспособных изучить Java/Basic/1C/Python/C и далее по списку нужно дисквалифицировать как профнепригодных.

потому что языки-то не сложные, и человек который не может выучить условный бейсик или там объектно-ориентированный бейсик типа питона/явы/PHP вообще мало что может выучить.

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

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

сложность написания реального кода на Java/1C/Python/далее по списку — это скорее понимание предметной области и известных популярных фреймворков/конфигураций/батареек, а не самих конструкций языка, который ни разу не сложный.

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

ну это типа писать лонгфеллоу на simple english. java и есть такой simple english.

какие языки выбирают «сообразительные программисты»

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

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

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

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

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

with(int *myint, my_malloc(sizeof(int)), free){
Теперь у тебя в одном контролируемом месте однозначно определено что ты инициализируешь, как ты это делаешь и то, как освободить ресурс.

И что оно делает при return/break? Как оно обрабатывает ошибку выделения ресурса?

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

Может быть Го на текущий момент не умеет оптимизировать defer. Но try..finally работают вполне безо всяких стэков.

просто они изучают неправильно, ненаглядно, запутанно. вот и результат — плохо.

Почти это я и имел в виду, когда писал

школа и ВУЗ мешает изучать ин.яз.

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

ВУЗ-е никогда не выучит язык

Да им некогда.

Знаете, что такое «ВУЗ» /ни к тому, что у вас образования нет/?
Знаете, что такое «общага»?

Далее мысль развивать не хочу - противно.

«программеров», неспособных изучить Java/Basic/1C/Python/C и далее по списку нужно дисквалифицировать как профнепригодных.

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

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

сложность написания реального кода на Java/1C/Python/далее по списку — это скорее понимание предметной области и известных популярных фреймворков/конфигураций/батареек, а не самих конструкций языка, который ни разу не сложный.

Вот. Это вопрос того, насколько язык дает возможности работать со сложной системой. Java этих возможностей не дает, тебе постоянно приходится ползать на низком уровне - потому создано столько языков на JVM, призванных заменить слишком неудобную Жаву. Ровно как возникли Java и C++ вместо Си - они были шагом в сторону более высоких абстракций.

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

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

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

Предпочитаю общаться с людьми на том языке, который они «понимают».

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

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

по которой бьют при помощи воспитания, учебы, работы.

«бьют» - запросто.
Что касается другого, то как «безграмотный» может научить «грамоте»?

как «безграмотный» может научить «грамоте»?

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

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

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

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

И что оно делает при return/break?

Агааа! - сказали сибирские лесорубы (с) Зачем? Вот конкретно - зачем return втыкать в 100500 мест ф-ции? Ради каких профитов? Хинт - и внезапный return тоже можно обработать.

break зачем? чтобы что? Хинт - эту мандулу можно запилить и без for.

Как оно обрабатывает ошибку выделения ресурса?

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

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

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

Но try..finally работают вполне безо всяких стэков.

try-catch-finally на сишечке запиленных вагон, просто они нахрен никому не сдались. Есть максимально облегченные реализации, даже без setjmp\longjmp, и без libunwind. Обычно этим страдают люди, у которых мышление деформировано скриптотой. Тащут в карманы всякую каку.

Здесь я говорю о принципиальной нерасширяемости подхода.

Как только у тебя возникнет необходимость расширить - расширяй. Нет необходимости? Используй простые решения.

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

Ну жрите, чо.

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

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

Вот конкретно - зачем return втыкать в 100500 мест ф-ции? Ради каких профитов? Хинт - и внезапный return тоже можно обработать.

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

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

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

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

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

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

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

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

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

который написан на C+Python - вот это грамотный выбор инструментов.

То написание на си плохо, то теперь уже на си - хорошо, но вместе с питоном, а не башем.

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

https://github.com/torvalds/subsurface-for-dirk

Гуглится на раз-два.

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

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

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

Что на них ценного и уникального написали?

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

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

Баги будут всегда.

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

Почему же потом появились только отдельные инструменты

Значит, с джавой я погорячился. Язык оказался достаточно простым, чтобы запилить ide, «читающие мысли». А более мощный C# изначально проектировался, чтобы «писать и хвалить какая Visual Studio классная». Вендорлок, все дела. А Си с классами - простое (на уровне джавы) подмножество С++.

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

Царь уже ответил - gnuc с _cleanup_fclose_ FILE *f = NULL;, _cleanup_free_ char *p = NULL;. Сразу объявлено, как этот ресурс освободить. Компилятор заботится о том, чтобы сделать это при любом выходе из функции. А там, где такого нету - называет «это не си, а говно». Кстати, mingw такое тоже поддерживает.

А там, где такого нету - называет «это не си, а говно».

Ты всё препутал.

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

К тому же, данный клоун эникей и уровень знаний в сишке там в районе помойки. Он большинство примеров даже распарсить не сможет, не то что осознать.

Возьми багтрекер любого проекта на Си, и посмотри, сколько там проблем возникло из-за проблем работы с памятью.

Спасибо, я в курсе

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

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

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

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

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

Это называется наводить тень на плетень. Вопрос был насчет конкретного юз-кейса - зачем там break\return?

И, кроме того structured programming says you should only ever have one return statement per function.

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

Все ресурсы объявляются в начале функции и освобождаются в конце. Все прямо перед глазами. Сложно? Ну ок.

Кроме того, в конкретном кейсе благодаря goto вообще нет спагетти-кода.

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

Трудоемко думать, а не херачить по клавишам. Если нас интересует только количество символов\строк, то Линусу сотоварищи давно пора на покой, миллионы макак кого хочешь заткнут за пояс по количеству килобайт нахераченного текста. Еще раз - проблема не в набрать на клаве. Проблема в том, чтобы в рамках задачи выстроить адекватную архитектуру и создать подходящий набор инструментов. Закодить - это 5 процентов стоимости проекта. Сколько можно сэкономить? Максимум 5 процентов, если не кодить вообще.

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

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

И где многонациональный народ России будет изучать русский? В армии от сержанта.

моё имхо:

всё так круто (про ФП)

весьма конкретный математический базис

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

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

Был бы на ооп написан - читался бы легко и без комментариев (а там в коде куча комметов была в добавок)

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

То написание на си плохо, то теперь уже на си - хорошо, но вместе с питоном, а не башем.

Ты пишешь на крестах, но библиотека у тебя на сях - на чем в итоге у тебя получится продукт?
В Hg на Cи написана меньшая часть кода, а большая часть логики работает в питоне, который идеально подходит для задачи.
В то же время, баш ужасно подходит для сложных задач, потому пришлось много чего засовывать в хитросплетенный клубок кода на си, который дергается из баша. Один из результатов - заслуженное звание у git «самый сложный интерфейс среди систем управления версиями кода».

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

https://github.com/torvalds/subsurface-for-dirk
Гуглится на раз-два.

К сожалению, нет. Эту программу торвальдс написал на Си и GTK. Кто и когда ее переписывал на Qt - не знаю, с тех пор структура файлов в репозитории полностью изменилась.

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

Там нет никаких стимулов, вроде холодной войны или космической гонки, наса нынче - это вполне обычная контора, которая тот же питон использует, хоть и не на самих запускаемых аппаратах. Причем, на аппаратах предпочитают использовать старые программы на старом оборудовании вместо разработки новых. Например, THEMIS в 2007 летал на 8-битном Intel 8085, созданном в 1976 году, когда у НАСА еще было достойное финансирование. Когда у тебя девайсы на таком древнем оборудовании - у тебя не особо много вариантов для софта. Они, по сути, не разрабатывают технологии, а поддерживают их.

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

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

Что на них ценного и уникального написали?

Объясняю. Что ценного и уникального написали на питоне? Ютьюб? Гугл? Но ты не видел ни строчки кода ютьюба или гугла, правильно? А, тем не менее, миллионы строчек кода написаны. Точно так же на лиспе делались огромные проекты под конечную задачу, но они не были опубликованы. Вот эта штука, например, была на лиспе сделана https://www.cleartrip.com/ Или вот эта https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool , или эта https://en.wikipedia.org/wiki/Mirai_(software). Но все эти системы в опенсорс не попали. В открытом же доступе остались только мелкие/средние библиотеки/фреймворки, которые нынче забываются в связи с переходом от CL на более современные диалекты.

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

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

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

Разговор шел о том, что нам не важны готовые решения, нам не важен оптимизирующий компилятор - мы просто выбираем язык, который нам удобен, а потом уже когда-нибудь может быть будем оптимизировать. Тогда можешь мне пояснить, почему они писали не на фортране, не на коболе, не на крестах, не на паскале, не на лиспе, не на схеме - а на Си? Он настолько удобен, гибок, фундаменталенг, что с ним даже кресты не нужны? Может быть популяризаторы крестов вообще ничего не понимали в программировании? Зря создали язык - могли бы писать на Си всё, он же удобнее.
Про «внутренние механизмы работы прозрачны и понятно „как работает под капотом“» можно согласиться - правда, не ясно, почему Си, а не Ассемблер - вот где-где, а в нем уж точно всё понятно как устроено.

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

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

Разработка большой системы на Си подразумевает большой риск, потому, например, никакой банк не будет строить свою логику на Си, иначе весь банк рискует от дуновения ветра сорваться и упасть в пропасть. По этой причине в ответственных приложениях довольно долго применяли Кобол - он дает намного меньше неожиданностей, чем Си, хоть и тоже не отличается особой высокоуровневостью, казалось бы. Сколько космических аппаратов было потеряно из-за элементарнейших ошибок в программе?
https://ru.wikipedia.org/wiki/Маринер-1
https://en.wikipedia.org/wiki/Cluster_(spacecraft)
https://ru.wikipedia.org/wiki/Mars_Polar_Lander
https://ru.wikipedia.org/wiki/Mars_Climate_Orbiter
https://ru.wikipedia.org/wiki/Венера-3
https://www.businessinsider.com/nasa-voyager-probes-rocket-leak-computer-prob... - Оба вояжера живы, но поволноваться они заставили солидно. А сколько ошибок софта оказалось не удалось расследовать из-за недоступности/разрушения аппарата?

Язык оказался достаточно простым, чтобы запилить ide, «читающие мысли»

Ты хотел сказать «костыль, читающий мысли»? Язык программирования - это программа для транслятора, прежде всего, и транслятор должен читать мысли. Но очень скоро выяснилось, что без костылей писать на жаве просто невыносимо. Фактически можно говорить о том, что был создан совершенно новый инструмент разработки «Java+IDE». Ну, примерно как документ в MS Word - это не просто текст, это все-таки «MS Word+текст», они уже неотрывны. Для какого-нибудь Latex, однако, не нужно никакой IDE - он сам по себе является достаточно удобным инструментом. А вот Java не является достаточно удобным инструментом, потому для нее нужны дополнительные инструменты - костыли.

Царь уже ответил - gnuc с _cleanup_fclose_ FILE *f = NULL;, _cleanup_free_ char *p = NULL;

Ну вот же, другое дело. Правда, что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно. Сейчас функции высвобождения ресурсов реализованы как-то так:
systemd/src/basic/fd-util.c

int fclose_nointr(FILE *f) {
        assert(f);
        if (fclose(f) == 0)
                return 0;
        if (errno == EINTR)
                return 0;
        return -errno;
}
FILE* safe_fclose(FILE *f) {
        if (f) {
                PROTECT_ERRNO;
                assert_se(fclose_nointr(f) != -EBADF);
        }
        return NULL;
}

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

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

Давай возьмем пример морально и физически разложившихся людей - водители грузовиков. Они уже давно вручную не поворачивали колеса - за них это делает гидроусилитель руля. Но как же так, где отдача себя инструменту, где «фундаментальность»? Дальнобойщик же должен быть в хорошей форме, как Вирастюк - чтоб поднимал хотя бы 300 кг от груди. Это ж твоя работа - крутить руль, да? Как ты можешь работать, и не иметь силы для кручения руля без ГУР-а - так же и заснуть на работе можно, ничего не делая.

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

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

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

Это называется наводить тень на плетень. Вопрос был насчет конкретного юз-кейса - зачем там break\return?

У самых придирчивых такое построение алгоритма называется «иерархия Косарайю», и тоже считается вариантом структурного программирования:
https://link.springer.com/chapter/10.1007/978-3-540-70594-9_11
Самый банальный пример применения break/return - это поиск в массиве. Когда элемент найден - происходит выход из цикла. Это был основной аргумент за goto и против устройства алгоритмов по Бёму-Якопини (последовательность, условие, цикл), поскольку в последнем приходилось применять дополнительные переменные для выполнения той же задачи. Хоть дополнительные переменные и решали задачу, но они усложняли алгоритм. Если посмотреть статью Кнута про пользу goto:
https://dl.acm.org/citation.cfm?doid=356635.356640
то можно увидеть, что почти все применения goto - это выход из цикла. Именно за структурное программирование в форме иерархии Косарайю я и выступаю.

Все ресурсы объявляются в начале функции и освобождаются в конце. Все прямо перед глазами. Сложно? Ну ок.
Кроме того, в конкретном кейсе благодаря goto вообще нет спагетти-кода.

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

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

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

И где многонациональный народ России будет изучать русский? В армии от сержанта.

Я говорил, писал, и читал на русском до школы. Шах и мат!

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

Опачки.

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

Постгрес в качестве альтернативы? Ооок, но постгрес - тоже не питон, и даже мысли ни у кого не возникает.

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

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

Задач типа quick'n'dirty в банковской сфере (как впрочем и в любой другой) тоже хватает. Для задач такого рода какая-нибудь модная платформа - самое оно. Апатамушта там не надо изысков.

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

Остаются рюшечки. Но это уже хоть на чем, плюс-минус.

что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно

Никого не хочу обидеть, но писать на си - это не твое.

Финальное итого.

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

Короче вся чистота и математичность убивается нечитаемостью на больших проектах.

Сейчас бы в тред призвать егорку, который вам расскажет, что 2000 строк на Жаве - это нечитаемый и неподдерживаемый модуль.

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

Блин, ну оракель - это слишком тонко. Ты бы лучше вспомнил ОС, которые написаны на C/C++, и которые составляют основную угрозу для серьезных дядь. Базу данных-то можно изолировать, но как изолировать ОС, которая должна принимать данные по сети, читать-писать файлы? При этом, абсолютно все ОС - это дырявые друшлаги, в которых регулярно находят удаленное выполнение кода. И именно потому, что от них требуется высокая производительность - отсюда Asm/C/C++ и большое число багов.

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

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

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

что ты будешь делать, когда в функции нужно будет вызывать cleanup только для выделенного ресурса или когда само высвобождение выдает ошибку - мне не совсем ясно

Никого не хочу обидеть, но писать на си - это не твое.

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

Обсуждают ООП, исключения, ...
Корни того почему так или иначе сделано в многом определяются архитектурой x86 /проще говоря, возможностями железа/.
Маленький намек ...
Если бы бит мог хранить несколько значений /например 65536/, то подход к разработке алгоритмов, компиляторов, ... был бы совсем иной.

Корни того почему так или иначе сделано в многом определяются архитектурой x86 /проще говоря, возможностями железа/.
Если бы бит мог хранить несколько значений /например 65536/, то подход к разработке алгоритмов, компиляторов

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

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

Переход с Си на высокоуровневый язык как раз и нужен, чтобы снизить число «аварий»

Любая библиотека, любая инструментальная обвязка - это и есть повышение «уровня». DSL для решения (узко) специфических задач.

Кто-то приговорил лишить себя удобств и жить в пещере? Си запрещает? Вынуждает писать лапшеобразный нечитаемый код? Препятствует желанию запилить легкий инструмент обслуживания ресурсов? По рукам бьет?

Нет из коробки всего того, о чем мечталось жаркими южными ночами? Сделай. Запиливаешь однажды - работает всегда.

Напиши функцию в 50 строк

И SonarLint настучит тебе по щам.

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

Как страшно жыть.

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

Вестник параллельной вселенной. Репликация данных нужна потому что си откажет? )

Жжошь напалмом.

Ответ на мой вопрос где?

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

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

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

Если бы бит мог хранить несколько значений /например 65536/, то подход к разработке алгоритмов, компиляторов

Экспромтом.

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

Любая библиотека, любая инструментальная обвязка - это и есть повышение «уровня». DSL для решения (узко) специфических задач.

Да, написать DSL на Си, потом переписать DSL на нем самом, и выкинуть Си на помойку.

Напиши функцию в 50 строк

И SonarLint настучит тебе по щам.

Серьезно? Что же он мне скажет про функцию на 400-700 строк? Если функционал достаточно целостен, то есть, например, выполняет обработку некоторой таблицы - почему я должен раскидывать отдельные шаги в отдельные функции? Ты думаешь, почему в C++, Rust, Java, C# сделали лямбды и локальные/анонимные классы? Чтобы повысить локализацию кода! И тут ты такой выпрыгиваешь, и гришь «всё говно, я - дартаньян, вы, дурачье, пишете код, а я - архитектуру строю».

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

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

Да, консервативная медицина консервативна, антибиотики это вам не эко-грин-смузи-лайт, но когда надо - работает.

Здоровья вам, берегите себя.

Конечно примеры мои немного «надуманные».
Еще раз акцентирую на то, что компиляторы разрабатываются с учетом архитектур CPU, ...
Для квантовых компьютеров /к примеру/ нужны совершенно иные алгоритмы, компиляторы, СУБД ..., а не как для x86.

Серьезно? Что же он мне скажет про функцию на 400-700 строк?

Без мата? Тогда ничего.

Все претензии к статическим анализаторам. Best Practices они такие. Суровые, но справедливые. Всегда (почти).

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

Ты о чем? Я тебе даже код привел конкретно реализации: «всё учтено» - это assert_se, который при отладке тебе сделает

log_assert(LOG_CRIT, text, file, line, func, "Assertion '%s' failed at %s:%u, function %s(). Aborting.");
abort();

И 1 + 1 это была операция не просто сложения двух чисел, а при желании с учетом типа значения.

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

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

а в релизе и вовсе ничего не сделает - как и положено обрабатывать ошибки в Си.

Вечер перестает быть томным.

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

Серьезно? Что же он мне скажет про функцию на 400-700 строк?

Без мата? Тогда ничего.
Все претензии к статическим анализаторам. Best Practices они такие. Суровые, но справедливые. Всегда (почти).

Не вижу никаких причин для того, чтобы 20 функций по 30 строк были бы удобнее для поддержки, чем одна функция на 600 строк. Конечно, при условии, что код взаимосвязан и выполняет одну функцию. То ли ты будешь ползать по блокам одной функции, то ли прыгать по разным функциям - и для внесения серьезных правок все равно нужно будет прочитать большую часть кода в обоих вариантах.

Ты хочешь сказать, что этого сейчас нет?

Не об этом речь.

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

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

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

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

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

Не вижу никаких причин для того, чтобы 20 функций по 30 строк были бы удобнее для поддержки, чем одна функция на 600 строк.

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

А библиотеки и книжки? Сплошной отстой. Главы какие-то понапридумывали. Кто убил дворецкого? Отвечайте. Просто и ясно, на первой странице, без соплей.

Нахрена вообще структурировать? Удобочитаемость? В жопу. Сопровождение? Пусть слон сопровождает, у него голова большая. Даешь брейнфак во все поля!

Мы рождены, чтоб Кафку сделать былью. А сказку пылью.

Идея - огонь. Не все поймут, не все согласятся. Консерваторы, ретрограды и все такое.

Не вижу никаких причин для того, чтобы 20 функций по 30 строк были бы удобнее для поддержки, чем одна функция на 600 строк.

Ну вот конкретный пример.

Сначала загрузка 1С mxl у меня была функцией из 600 строк.

Это был всего лишь прототип.

Конечно такой код был не readable.
Теперь конечно логика 600 строк реализована с использованием отдельных функций для каждой секции и код стал - ЧИТАБЕЛЬНЫМ /и не только ... /.

Вообщем все зависит от задачи.

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

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

И как же ты собрался обрабатывать ошибки в сторонней либе?

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

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

Видимо, у создателей systemd есть эти проблемы с работой, раз они так код пишут. А писали бы хорошо - не занимались бы такой ерундой, как systemd.