Линус Торвальдс унижает C++

Barbie29

http://www.realworldtech.com/forums/index.cfm?action=detail&...
Name: Linus Torvalds (linux-foundation.org) 6/8/10
anon2 (anons.com) on 6/8/10 wrote:
>
>But productivity is a difference thing when it comes to
>kernel code. Linux devs are working practically for free.
>So the same amount of budget can get you whole lot work
>done.
Actually, this is wrong.
People working for free still doesn't mean that it's fine
to make the work take more effort - people still work for
other compensation, and not feeling excessively
frustrated about the tools (including language) and getting
productive work done is a big issue.
So if a language change were to make people much more
productive, that would be a good thing regardless of how
much people end up getting paid. It's definitely not about
the money.
But the thing is, "lines of code" isn't even remotely close
to being a measure of productivity, or even the gating
issue. The gating issue in any large project is pretty much
all about (a) getting the top people and (b) communication.
In the kernel, we have roughly a thousand people being
attributed for each and every kernel release (at
about three months apart). Now, there's a long tail, and
the hundred (or even fifty) top contributors do most of
the bulk work, but even then, the biggest issue that I end
up worrying about is not even the code, but the "flow" of
code and development.
For example, I personally don't even write much code any
more, and haven't for years. I mainly merge (and to a
large degree - don't merge: a large portion of what
I do is telling people "No, I won't take this, because of
xyz". Even if rejection ends up being the rare case, it's
actually the main reason for me existing. Anybody can say
"yes". Somebody needs to say "no").
And the best way to make things work is to not need
to communicate at all. It's exactly the same issue as in
parallel programming - any communication inevitably is the
main bottleneck.
And the best way to avoid communication is to have some
"culture" - which is just another way to say "collection of
rules that don't even need to be written down/spoken, since
people are aware of it". Sure, we obviously have a lot of
documentation about how things are supposed to be done,
but exactly as with any regular human culture, documentation
is kind of secondary.
(Put another way: there are lots of books about culture,
and you can get a PhD in anthropology and spend all your
life just studying it - but for 99% of all people, you
don't read a book about your culture, you learn it by
being part of the community).
And there is a very strong "culture" of C (and UNIX, for
that matter). And this is also where it's so important for
the language to be simple and unambiguous. One of the
absolute worst features of C++ is how it makes a
lot of things so context-dependent - which just means
that when you look at the code, a local view simply seldom
gives enough context to know what is going on.
That is a huge problem for communication. It immediately
makes it much harder to describe things, because you have
to give a much bigger context. It's one big reason why I
detest things like overloading - not only can you not grep
for things, but it makes it much harder to see what a
snippet of code really does.
Put another way: when you communicate in fragments (think
"patches" it's always better to see "sctp_connect"
than to see just "connect" where some unseen context is
what makes the compiler know that it is in the sctp module.
And you have to communicate in fragments in order
to communicate efficiently. And I don't mean "efficiently"
as in network bandwidth - I mean as in "in general". The
reason we use patches instead of sending the whole project
(or even just a couple of whole files) around is not because
it's denser in email - it's because the only thing that
matters is the change, not the end result.
So that is a very fundamental reason for development to
avoid ambiguity and context. And that, btw, has absolutely
nothing to do particularly with "kernel programming". It's
true in general in any sw project, but it's true in real
life too: speaking or writing ambiguously is not good in
normal human communication either.
So a simple and clear language is a good thing. You don't
want to be unnecessarily verbose (meaningless syntactic
fluff is always bad but at the same time you do not want
to require too much context either.
[ Lots of implicit context is fine if everybody is an
expert on the subject. Which is why really esoteric
scientific literature is basically unreadable unless
you're an expert - it requires huge amounts of context
to make sense at all. But that is simply not possible
in a large project that has many different areas.
For example, I know the VM and core kernel really well,
but I still need to be able to read the code of various
filesystems and networking code. So even for somebody
like me, the code needs to be written without hidden
context. ]
And C is a largely context-free language. When you see a
C expression, you know what it does. A function call does
one thing, and one thing only - there will not be some
subtle issue about "which version" of a function it calls.
Of course, you can use the preprocessor and inline functions
to do that, but even then you have to be pretty explicit:
you can still grep for that preprocessor symbol, and it's
all pretty "direct".
Now, in other situations you do want more language support,
and you do want the language to do memory allocation etc
for you (ie GC - I'm not talking about that idiotic
"new" keyword in C++, or other crap). In the kernel, we
couldn't do that anyway. Similarly, in the kernel, we do
really require very specialized locking and direct control
over memory ordering etc, so a language that exposes some
model of concurrency would almost certainly be too limited
in that concurrency too.
So there are particular reasons why I think C is "as simple
as possible, but no simpler" for the particular case of an
OS kernel, or system programming in particular. That's why
I'm absolutely not saying that you should use C for all
projects.
But C++? I really don't think the "good features" of it
are very good at all. If you leave C behind, do it properly
and get some real features that matter. GC, some
concurrency support, dynamic code generation, whatever.
Linus

yolki

всё правильно делает. Ты бы ещё предложил на яве написать ОС

Barbie29

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

Papazyan

C++ - говно, его дни уже сочтены.

kokoc88

C++ - говно, его дни уже сочтены.
Бедненький Си++, ему на этом форуме предрекают смерть уже лет восемь.

uncle17

стабильность рулез!

agent007new

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

rosali

> it's always better to see "sctp_connect"
> than to see just "connect" where some unseen context
во-первых, если программисты умудрились назвать одним и тем же словом connect две настолько разные функции, что от того какая из них вызывается, зависит правильность патча, то это ошибка дизайна которую надо исправлять. никого же не смущает что когда вызываешь write(int fh, ...) то делаются ну совершенно разные вещи, в зависимости от того, что обозначает этот fh. то есть в Си (о чудо!) тоже есть виртуальные функции, так же как в С++, а они в смысле этого аргумента намного "страшнее" чем перегруженные, как только ими люди пользуются вообще ;)
во-вторых чтобы понять "sctp_connect" нужно быть очень даже глубоко погруженным в контекст "wtf is sctp_" =)
> When you see a C expression, you know what it does.
о, этот аргумент меня всегда вымораживал. когда я в С++ вижу
A = *B + C;
я тоже "know what it does" - эта строчка достает значение по указателю B, складывает его с C и кладет результат в A. разница исключительно в том что если это Си то детали понятий "достает", "складывает" и "кладет" зависят от автора компилятора, а если это С++, то они еще зависят от автора этих операторов *, = и +. ну и какие у меня причины больше доверять автору компилятора и меньше автору библиотеки? между прочим даже в Си за невинной операцией *B может стоять обращение к устройству по PCI шине, жуть как страшно и непонятно!
и вообще когда ты ревьюишь патч
- f(x)
+ g(x)
то ты на самом деле должен проверить его правильность не только при текущем коде функции g, но и при будущих разумных её изменениях. так что вопрос
> "which version" of a function it calls.
для Си точно так же актуален.

vall

Тут-то ты с кем спорить собрался? Пиши в LKML, Торвальдса и Мортона в CC.

rosali

=) так а о чем с ними спорить, я на интуитивном уровне согласен что нафик C++ при разработке ядра не сдался, мне просто хочется аргументы правильные услышать, чтобы прозрение наступило. пока вот аргументы как-то не очень B-)

oliver11

никого же не смущает что когда вызываешь write(int fh, ...) то делаются ну совершенно разные вещи, в зависимости от того, что обозначает этот fh. то есть в Си (о чудо!) тоже есть виртуальные функции,
Поподробнее, пожалуйста.

Maurog

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

rosali

не понял что именно поподробнее? насколько разные write-ы когда пишешь в файл, в пайп и в сеть? а еще fuse есть!..

oliver11

Только при чём здесь Си и виртуальные функции?

Dasar

Только при чём здесь Си и виртуальные функции?
то, что в си виртуальное поведение есть, но делается оно руками.

Maurog

кстати, Си - говно, а Си++ стал говном из-за обратной совместимости :grin:

vall

Ну в принципе достаточно прочитать последний абзац торвальсовского опуса чтоб всё понять.
Все "фичи" c++ заменяются грамотным дизайном. При этом я сомневаюсь после использования c++ со всеми этим его модным полиморфным сахаром вообще возможно будет ассемблерный код сопоставить с конкретными конструкциями, а без этого часто не обойтись.
Возможно товарищи что собрались разрешать c++ в gcc соорудят свой стандарт на диалект без всех этих тонн булшита. Тогда вот уже можно будет поспорить.

Dasar

Все "фичи" c++ заменяются грамотным дизайном.
не понятный довод. так можно сказать про любую вещь: все фичи мерседеса заменяются грамотным дизайном жигулей.
важно же всегда соотношение - грамотный дизайн/кол-во усилий.

vall

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

erotic

Все "фичи" c++ заменяются грамотным дизайном.
Вот и заменяют в сишных программых виртуальные функциями "правильными" самодельными вариантами, делая, например, указатели на нужные функции в структурах. Явно? Явно. Правильный дизайн? Может быть и да. Но зачем изобретать велосипед?

VendettA


ну и какие у меня причины больше доверять автору компилятора и меньше автору библиотеки?
Компиляторов меньше чем библиотек. И багов в компиляторах обычно поменьше.

pitrik2

C++ - говно, его дни уже сочтены.
ага, наши начальники в дб тож так думали когда начали проект на джаве писать
вот токо скорость которая получилась при каждом следущем входящем данном: 3мс, 3мс, 3мс, 50 мс, 3мс
обана, гарбадж коллектор включился
щас проект полностью с нуля на с++ переписали
то что на джаве его 2 года писали а на с++ полгода - фиг с ним, будем считать что не повезло с прогерами
а вот то что скорость стала микросекундами вместо миллисекунд измеряться, да еще и стабильной стала - вот это показатель говености языка
P.S.
есть кстати еще гуёвый пример, был гуй на джаве а потом переписали на с шарп, скорость раза в три упала :(

kokoc88

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

pitrik2

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

kokoc88

ну еще можно добавить что на джаве с нуля писали, а на с++ взяли за основу некую либу
Я думаю, что здесь просто большая разница в профессионализме разработчиков. ИМХО, при равных условиях Java никак не может слить C++ по скорости разработки и стабильности.

sergeikozyr

Я думаю, что здесь просто большая разница в профессионализме разработчиков. ИМХО, при равных условиях Java никак не может слить C++ по скорости разработки и стабильности.
по скорости работы большой разницы тоже быть не должно
уж точно не микросекунды vs милисекунды

kokoc88

по скорости работы большой разницы тоже быть не должно
уж точно не микросекунды vs милисекунды
Это так, но думаю, что можно придумать какие-то специфические области, где Java будет в 2-5 раз медленнее. Разницу в 1000 раз, действительно, представить сложно.

Papazyan

вот токо скорость которая получилась при каждом следущем входящем данном: 3мс, 3мс, 3мс, 50 мс, 3мс
обана, гарбадж коллектор включился
Криво писали. У меня прога на интерпретируемом языке! спокойно обрабатывает больше 100.000.000 сообщений за рабочий день в одно рыло. Я проверял, и на 400.000.000 не поперхнется. И времени в среднем на сообщение уходит микросекунд 20-80.

ava3443

Это так, но думаю, что можно придумать какие-то специфические области, где Java будет в 2-5 раз медленнее. Разницу в 1000 раз, действительно, представить сложно.
не-специфические области заняты индусами и Java, смысл на них ориентироваться?
разницу в 1000 раз легко себе могу представить например в движке торговой системы любой биржи, или в других расчётных системах, в частности по следующим причинам:
1) выделение памяти: как разрабатывать на Java без постоянного динамического выделения памяти на каждый чих? на C/C++ выделил достаточно памяти один раз в начале, и полетели;
2) обработка транзакций в памяти: кто сейчас из Java-разработчиков при доступности бэкэнда в виде СУБД не обращается к ней на каждый чих, да ещё и через ORM? кто пишет сам лог транзакций, а в БД пишет асинхронно? тоже самое естественно можно на Java делать, но пункт (1) всё равно остаётся.
культура другая, короче. отсюда и разница легко получается

kokoc88

1) выделение памяти: как разрабатывать на Java без постоянного динамического выделения памяти на каждый чих? на C/C++ выделил достаточно памяти один раз в начале, и полетели;
В языках с GC выделение памяти в районе O(1 а в C++ в районе O(log так что этот пункт никак не может создать разницу в 1000 раз.
2) обработка транзакций в памяти: кто сейчас из Java-разработчиков при доступности бэкэнда в виде СУБД не обращается к ней на каждый чих, да ещё и через ORM? кто пишет сам лог транзакций, а в БД пишет асинхронно? тоже самое естественно можно на Java делать, но пункт (1) всё равно остаётся.

На каждый чих в ORM давно придумали кэш. Кроме того, мало кто может написать "лог транзакций" так же быстро и надёжно, как это сделано в БД. Два этих подхода не дают разницу в 1000 раз.

ava3443

Видишь, подтверждаешь мой тезис про другую культуру...
Про память - я пишу что выделять её нужно поменьше, в идеале всё выделить на старте сервера, и ни одного выделения на транзакцию, а ты пишешь про O(1) и O(log).
Про ORM - тоже подтверждаешь что "современный программист" без него как без рук, а альтернативы "мало кто может написать". И я с тобой полностью согласен: вот эти "мало кто" и отличаются от индусов, индусы им не конкуренты. Хочешь конкурировать с индусами на их поле? Твой выбор.

kokoc88

Про память - я пишу что выделять её нужно поменьше, в идеале всё выделить на старте сервера, и ни одного выделения на транзакцию, а ты пишешь про O(1) и O(log).
Ты собираешься выделить огромный кусок памяти и потом использовать какой-то менеджер для всех объектов? И что, этот менеджер будет быстрее O(log)? Выделение памяти - это не обязательно запрос в ядро, языки с GC давно это оптимизировали. В C++ будет очень сложно добиться O(1 и то это будет только для объектов фиксированного размера. И даже это не даст тебе разницу в 1000 порядков.
Про ORM - тоже подтверждаешь что "современный программист" без него как без рук, а альтернативы "мало кто может написать". И я с тобой полностью согласен: вот эти "мало кто" и отличаются от индусов, индусы им не конкуренты. Хочешь конкурировать с индусами на их поле? Твой выбор.

Ты готов сходу написать код на C++, который безопасно пишет транзакции с сериализацией в базу данных и работает в 1000 раз быстрее Hibernate? (Безопасно - значит при отключении питания компа всё восстановится.) При этом твой код должен быть стабильнее, чем то же самое на Java. И ещё у тебя на это в три раза меньше времени. Что-то я сомневаюсь, но если хочешь, можем попробовать. Благо на Hibernate всего-то 100-200 строчек - пишется максимум за 30 минут.

evolet

а если бы, напрмер, gcc (т.е. компилятор) был бы написан на яве, как думаешь, по скорости тоже бы было соотношение порядка 1:1 к c++?

kokoc88

а если бы, напрмер, gcc (т.е. компилятор) был бы написан на яве, как думаешь, по скорости тоже бы было соотношение порядка 1:1 к c++?
А что, ты думаешь, оно было бы 1 к 1000?

evolet

хз насчет 1000, но накладных расходов имхо должно быть оч много, имхо соотношение должно быть не менее чем 1:10...

kokoc88

хз насчет 1000, но накладных расходов имхо должно быть оч много, имхо соотношение должно быть не менее чем 1:10
Ты так авторитетно об этом заявляешь, что мне стало интересно, какие именно накладные расходы сделают соотношение не менее 1:10?

evolet

я не авторитетно, я написал имхо)
на тех задачах, где, грубого говоря, много кода и много данных, где нет 2-3-5 процедур, в которых задача проводит все основное время, где характер обработки внутренних данных не носит "потоковый характер"(обработали, сохранили и забыли накладные расходы на run-time компиляцию возрастают + те-же ограничения , которые накладывает "Java-стиль", т.е. как ни крути , будет больше косвенностей (с которыми в Java наверно ничего не сделашь, в отличие от плюсов которые начинают заявлять свое слово в условиях, когда кэша не хватает.
gcc - это как классический пример "неудобной" задачи
короче, имхо здесь счет будет не на разы...

kokoc88

много кода и много данных, где нет 2-3-5 процедур, в которых задача проводит все основное время

Как скорость работы программы зависит от количества кода и количества функций, в которых программа проводит всё время?
накладные расходы на run-time компиляцию возрастают + те-же ограничения , которые накладывает "Java-стиль", т.е. как ни крути , будет больше косвенностей
Ты на Java вообще много разрабатываешь? А то я что-то не понял, какие расходы и на какую runtime компиляцию? Какие ограничения накладывает Java стиль, чтобы затормозить программу в десятки раз?

oliver11

Какие ограничения накладывает Java стиль, чтобы затормозить программу в десятки раз?
Некоторые недостатки языка Java, делающие практически невозможной хорошую оптимизацию, приводятся, например, в этой статье:
http://www.jelovic.com/articles/why_java_is_slow.htm
Интересно было бы почитать комментарии/возражения от опытного java-разработчика.

karkar

Как скорость работы программы зависит от количества кода и количества функций, в которых программа проводит всё время?
Думаю, речь шла о JIT'e, объему работы для него и возможности разгуляться hotspot'у.

kokoc88

Некоторые недостатки языка Java, делающие практически невозможной хорошую оптимизацию, приводятся, например, в этой статье:
http://www.jelovic.com/articles/why_java_is_slow.htm
Интересно было бы почитать комментарии/возражения от опытного java-разработчика.
Например, эта статья была написана лет эдак 8 назад. Она наивна до безобразия, похоже, автор услышал где-то, что Java тормозит и решил придумать, почему.

kokoc88

возможности разгуляться hotspot'у
Если речь шла об этом, то какая разница между C++ и Java?

oliver11

Там есть по крайней мере два пункта, похожие на правду.
Первый — сложности выполнения агрессивного inlining-а, какой имеет место в C++. Скорость работы программы, использующей шаблоны, благодаря нему повышается на порядок.
Есть пример, когда один и тот же алгоритм моделирования после переписывания его с шаблонами с целью обеспечения компилятору возможности подстановки всех часто вызываемых в процессе счёта довольно немаленьких функций начинал работать в 4 раза быстрее. До этого 3/4 времени уходило на вызовы и передачу параметров.
Можно ссылку на достоверные источники, которые говорят, что Java научилась инлайнить что-то сложнее getter- и setter-like методов?
Второй — неоправданное повышение уровня косвенности обращений к данным. Как следствие, увеличение объёма используемой памяти, ухудшение пространственной локальности доступа к данным, менее эффективное использование кэша. Как с этим научились бороться? Подозреваю, что никак.

6yrop

пишет транзакции с сериализацией в базу данных
видимо я что-то пропустил, хибернейт ведет свой transaction log что ли?
Безопасно - значит при отключении питания компа всё восстановится

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

kokoc88

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

karkar

Ежели программа состоит из множества мелких методов, которые вызываются малое число раз, то доля времени на их JIT или даже интепретацию (вроде, в джаве они не при первом обращении джитятся) примерно на "1000 порядков" больше, чем в С++, где все уже скомпилировано.

6yrop

Он ничего такого не делает. Прочитай тему внимательнее, и поймёшь, о чём именно я писал.
Тогда зачем вот здесь ты вообще упомянул Hibernate?
Ты готов сходу написать код на C++, который безопасно пишет транзакции с сериализацией в базу данных и работает в 1000 раз быстрее Hibernate? (Безопасно - значит при отключении питания компа всё восстановится.)

Вопрос только в использовании/неиспользовании СУБД.

kokoc88

Ежели программа состоит из множества мелких методов, которые вызываются малое число раз, то доля времени на их JIT или даже интепретацию (вроде, в джаве они не при первом обращении джитятся) примерно на "1000 порядков" больше, чем в С++, где все уже скомпилировано.
Да, я теперь понял, о чём было написано. Насколько мне известо, это всё уже давно оптимизировали. То есть чтобы получить понижение производительности, тебе придётся написать программу, в которой куча методов и каждый метод вызывается ровно 1 раз.

kokoc88

Вопрос только в использовании/неиспользовании СУБД.
Ты придираешься к словам. Hibernate здесь упоминался в контексте "все так пишут на Java". Как я понял, предлагалось сравнить этот подход и продвинутое решение, когда в базу данных ты пишешь из асинхронной очереди.

kokoc88

Первый — сложности выполнения агрессивного inlining-а, какой имеет место в C++. Скорость работы программы, использующей шаблоны, благодаря нему повышается на порядок.
Ты знаешь, я только что ради интереса сравнил XML сериализацию на C++ и Java из моих коммерческих проектов. В C++ привязки были сделаны через макросы и шаблоны, а в Java через Reflection с кэшированием.
Очень важно, что в обоих случаях решения написаны в лоб. В обоих случаях задача производительности никогда не ставилась, не оценивалась и вообще профилировка всегда отсутствовала.
Сериализация на Java рабоатет в два раза быстрее, чем на C++. Я сам удивлён, видимо, на плюсах что-то сделано совсем криво.
Ради интереса надо бы сделать review, но лень копаться... Скорее всего, плюсы подтормаживают из-за того, что там есть boost::shared_ptr и динамическое выделение памяти для объектов, которые выполняют валидацию одного элемента и являются описателями схемы. В Java описание схемы сделано на immutable объектах, но валидация выполняется на динамических объектах.
Второй — неоправданное повышение уровня косвенности обращений к данным. Как следствие, увеличение объёма используемой памяти, ухудшение пространственной локальности доступа к данным, менее эффективное использование кэша. Как с этим научились бороться? Подозреваю, что никак.
Да, я думаю, что во всех языках с GC кэш процессора - это стандартная проблема. Объём используемой памяти увеличивается, но не в десятки раз.

kokoc88

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

sergeikozyr

то плюсы догонят Java по скорости
"перегонят в тыщу раз" :grin:

Hastya

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

Anturag

Препроцессор это чертовски неприятное явление в С.

WTF?
Перепиши, пожалуйста, следующий кусочек, хочу мир без препроцессора для себя открыть.


#define offsetof(type, member) size_t) &type*)0) -> member) 

#define container_of(ptr, type, member) ({                      \

        const typeof( type *)0)->member ) *__mptr = (ptr);    \

        (type * (char *)__mptr - offsetof(type,member) );})

Ты скажи ещё, что и от goto надо отказаться в С, которого в среднем 5 штук на файл сорца в Linux.

Maurog

Перепиши этот код без UB :grin:
#define offsetof(type, member) size_t) &type*)0) -> member)

Anturag

Пожалуйста :)
 #define offsetof(type, member) size_t) ( (char *)&type *0->member - (char *)0

Papazyan

Ну и че? Ты только подтвердил, что препроцессор источник говнокода.

Papazyan

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

asvsergey

Ну и че? Ты только подтвердил, что препроцессор источник говнокода.

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

asvsergey

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

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

Papazyan

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

asvsergey

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

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

Maurog

ты не понял, видимо, где тут UB

Papazyan

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

asvsergey

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

Maurog

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

asvsergey

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

Я не считаю, что написание ядра ОС это только промышленная задача :)
От промышленного языка ожидают простые средства для решения промышленных задач :)
А язык на котором можно будет просто решать все сложные задачи это сказка :)

slonishka

публичноеунижение.ком
Оставить комментарий
Имя или ник:
Комментарий: