DNF будет переписан на языке C

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

Чтобы стать системным программистом - да. Но научиться писать на Си - не сложнее, чем на Питоне. Правда, получаться будет говно, и это будет более опасное говно, чем на Питоне.

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

Польза ещё есть в напоминании окружающим о том, что существует такое явление, как старческий маразм :-) Ну и о «плюсах» цепепе тоже, стоит периодически напоминать :-)

Ты хочешь сопоставить создание компилятора для цепепе с процессором?

про компилятор никто и не говорил. теория компиляторов - это отдельная вещь и она не относится ни конкретно к си, ни к процессорам. вещь весьма занятная, но стоит особняком. одно время я этим увлекалась, читала про всяческие парсеры слева направо и наоборот, и т.д.
сколько было создано процессоров? сложно оценить. крайне много. я всех не видела даже близко. но даже документация на простой мост PCI-PCIe может занимать около 3000 страниц, для примера. и это ещё не процессор! это относительно простая железка, которая просто используется при переходе с одной шины на другую.

Да и знания Си гораздо важнее, чем знания цепепе для любого серьёзного программёра

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

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

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

Но научиться писать на Си - не сложнее, чем на Питоне. Правда, получаться будет говно, и это будет более опасное говно, чем на Питоне.

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

про компилятор никто и не говорил.

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

синтаксис языков и семантика - это фигня

Первое фигня :-) Второе - очень важно :-) Плохого программиста можно судить по его отношению к семантике :-) Синтаксис же важен только для плохого программиста :-) Ты уж извини, если что :-)

знание и умение применять алгоритмы и паттерны - это уже не фигня

Про паттерны - полнейшая фигня :-)

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

Согласен :-)

дело не в си, а в том, где и для чего он применяется.

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

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

В отличии от того же цепепе, который далеко не везде

Назови популярный компилятор С не на С++.

Назови популярный компилятор С не на С++.

«популярный» и «везде» далеко друг от друга :-)

«популярный» и «везде» далеко друг от друга :-)

«далеко не везде» и «не везде» тоже.

А был ведь когда-то во времена Red Hat 9 порт apt-get для rpm, помню пользовался даже...

Назови популярный компилятор С не на С++.

Во-вторых, причём тут язык, на котором написан компилятор для языка X? :-) Про кросс-компиляцию ты ничего не слышал, видать :-)

Речь изначально шла о гиперсложности цепепе :-) Чем сложнее язык, тем сложнее компилятор

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

Ты сюда приплела создание камней

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

Си - практически везде и в этом то его сила :-) В отличии от того же цепепе, который далеко не везде

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

си - лишь инструмент

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

А был ведь когда-то во времена Red Hat 9 порт apt-get для rpm, помню пользовался даже...

Даже во время Redhat 7. Назывался, внезапно, apt-rpm. Отличной штукой был.

Во-вторых, причём тут язык, на котором написан компилятор для языка X? :-) Про кросс-компиляцию ты ничего не слышал, видать :-)

Покажи компилятор С, написанный на С++, который кросскомпилит на платформу, где нет компилятора С++.

А был ведь когда-то во времена Red Hat 9 порт apt-get для rpm,

А в Альте разве не оно? Правда я очень давно его не пробовал.

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

А скажи честно, ты от корки до корки осилила стандарт C++? :-)

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

Ядра операционок на плюсах смысла писать нет :-)

это технически быстрее.

Это быть может только в случае исключительных знаний цепепе :-) В случае отличных знаний Си, на нём писать быстрее :-)

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

Мне аж прям интересно, для каких, конкретно, задач удачно подходят шаблоны цепепе? :-) Не уж то boost 2? :-)

Покажи компилятор С, написанный на С++

С чего вдруг такое условие? :-) цепепе идёт лесом вообще :-)

Который гораздо легче для использования, чем цепепе

не всегда. зависит от задачи. темплейты иногда сокращают количество кода в сотни раз. так что всё зависит от задачи.

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

А скажи честно, ты от корки до корки осилила стандарт C++? :-)

А ты стандарт Common Lisp?

Ядра операционок на плюсах смысла писать нет :-)

Вот тебе самая популярная на десктопах:

https://en.wikipedia.org/wiki/Windows_Runtime

Вот вторая:

https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptua...

А есть еще и всякие Haiku.

Это Сережка Марков

лол :-)

С чего вдруг такое условие? :-) цепепе идёт лесом вообще :-)

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

А скажи честно, ты от корки до корки осилила стандарт C++? :-)

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

А ты стандарт Common Lisp?

Нет, не весь :-) Но я и не заявлял, что несколько тысяч страниц технической документации - это фигня, которую настоящим про осилить нет проблем :-) Ты забыл ещё одну упомянуть :-) Лол :-) https://ru.wikipedia.org/wiki/BeOS

И действительно: www.linux.org.ru/search.jsp?range=COMMENTS&user=SergMarkov&sort=DATE

Ты забыл ещё одну упомянуть :-) Лол :-) https://ru.wikipedia.org/wiki/BeOS

Не забыл, ее место как раз заняла Haiku.

зачем?

Затем, чтобы не напрограммировать undefined behaviour, который всегда тут как тут в цепепе :-) Цепепе ошибок не прощает :-)

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

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

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

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

Не забыл, ее место как раз заняла Haiku.

Аа, мне это так надо, как видишь, что даже и не знал :-) Такая вот нужна ОС на цепепе :-)

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

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

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

Извините, но чушь. GCC изначально был написан на паскале, сейчас на С++, glibc, например, собиралась и собирается им же. Про какую курицу и яйцо может идти речь?

GCC изначально был написан на паскале

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

Аа, мне это так надо, как видишь, что даже и не знал :-) Такая вот нужна ОС на цепепе :-)

Ну мне, например, и Windows не нужна, но если бы мне ее привели в пример, я бы прежде всего обратил внимание на нее, а не на клон BeOS. А у тебя видимо какая-то особая логика.

на ассемблере нормально написаны многие сишные компиляторы

Назови Топ5

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

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

И не только сишные.

паскаль ненужен

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

про порядок сборки - рекомендую пару раз собрать LFS.

Там, как я понимаю, GCC на С++, который кросскомпилируется GCC же. Если так, причем тут порядок сборки?

но он выполнил роль курицы для С

Для конкретного компилятора С, конечно.

на ассемблере нормально написаны многие сишные компиляторы

Назови Топ5

все компиляторы для микроконтроллеров. любые их реализации

Какой бред.

Вот тебе ... Вот вторая

бгг, и ядра у всех на чистом С

http://stackoverflow.com/questions/580292/what-languages-are-windows-mac-os-x...

Для конкретного компилятора С, конечно.

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

Если так, причем тут порядок сборки?

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

Отличная новость! Как релизнут - сравню с zypper-ом

И компилятор вывел не то, что нужно :-) Хотя программист указал using namespace Inner; :-)

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

#define My_package_f f :-)

Вот это больше на проблемы похоже.

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

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

Сколько я подобных обещаний слышал про portage — не счесть

бгг, и ядра у всех на чистом С

Ты бы еще у бабушек мнение про Windows 95 спросил. Тебе русским английским языком написали, что Win32 уже устарел, как и комментарии лохматых годов на форумах, и ему сделали замену на С++. Код WinRT ес-но закрыт, но то, что он на С++ не является секретной информацией. Плюс вот тебе код WDF и пример драйвера от Microsoft:

https://github.com/Microsoft/Windows-Driver-Frameworks/blob/master/src/framew...

https://github.com/Microsoft/Windows-driver-samples/blob/master/audio/sysvad/...

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

Как удобно: сравнить драйверы на си с гуями на питоне.

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

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

Питон, кстати, сложнее чем си - возможностей больше, и они сложнее.

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

Как удобно: сравнить драйверы на си с гуями на питоне

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