Почему большинство софта для *nix систем написано на С, а не на С++

[blackSun]

ctype еще вспомнил. осилить это всё не составляет проблем. только зачем ?

[victor_im]

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

.net это в основном чтобы продажи выньдовс солюшенов двигать и джаву теснить из ентерпрайс сектора. большая часть кода Windows (включая Vista) написана на C++. MS Office , Outlook, Exchange Server тоже. Visual Studio - частично на C# (гуй), "потроха" к которым она внутри обращается на C++

[victor_im]

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

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

[M@}{]

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

Ну в java есть generics. Пусть они не как templat-ы compile time, a runtime, но позволяют избежать c++ template проблем (code bloat например).

[M@}{]

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

[pal]

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

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

[homo ludens]

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

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

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

О том, что читая Бхаватгиту можно постичь истину - написано ненамного меньше.

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

Убейте поток который висит в синхронном вызове БД внутри чужой либы.
Реализуемы кстати вполне (не на С++) и иногда единственный способ прибить трид,

прикол в том, что то же самое можно сделать и на с++
но не нужно

Если знать все переопределенные операторы и конструкторы включая вызовы чужого кода - да. Вы их знаете?

это называется userlevel threads
и я имел счастье сталкиваться с этим уродством в freebsd
это был костыль с O(n^2) сложностью переключения контекста, созданный теми, кто не осилил kernellevel threads

Я нигде не говорил о userlevel threads, я говорил о монотридном сервере.
Поинтересуйтесь как пишутся c10k сервера или реалтайм.
Если слово FSM ни о чем не говорит.
Я с массивными мультитридами не работаю уже лет 5 как минимум.
Ибо знаю к чему это ведет на нагруженных системах.

в с++ не больше запретов, чем там, где ты подумал, просто они нагляднее(что есть плюс)

Неправда ваша.
Я что теперь могу void* не приводить к типу в С++?

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

Потому что по умолчанию предполагается стабильность и простота языка с навороченными и развивающимися библиотеками,
В С++ этот принцип нарушен и очень сильно, Там постоянно развивается язык. Если вы считаете, что это хорошо и правильно - вы нерпавы.
В свое время IBM начала выделять бабло на Линукс при условии, что новая версия ядра будет появляться не чаще раза в два года.
Если вы не понимаете почему это надо - то это не ко мне.
Посчитайте человеко-часы затраченные на переобучение и переписывание программ по новому стандарту и перевдите их в человеко-жизни - Освенцим получится.
Snacc ASN library написанная в 80-х на С компилится на ура - вы можете похвастаться тем же?
А на вопрос почему написанное под gcc не пашет под MSVC или наоборот - у вас две дежурных отмазки - неправильно написана или UB,

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

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

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

Да только базовые требования виляли круче чем линия партии.

кому-то может показаться, что на дереве жить проще, но это не так

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

lol
с++ унаследовал понятие undefined behavior из с

Но только в С++ оно сократилось до постоянно употребляемой аббревиатуры...
Которая кстати объединяет еще одно специфичное понятие - unspecified behavior.
Многие плюсовики путаются.

[blackSun]

что же такое "монотридный сервер". гугление бесполезно.
что то вроде monothread'ный ? poll шоле ?

[pal]

Не менее линейной а дальше - как получится.

это не то, что было написано в формуле

При ограничениях типа 17 уровней - наверное до O(n^17), хз надо посчитать

17 шагов это 17 шагов, возведение в степень там никаким боком, считай лучше

В любом случае нелинейная.

в с она тоже нелинейная

О том, что читая Бхаватгиту можно постичь истину - написано ненамного меньше.

если книги не устраивают - займись изучением стл, там ооп отсутствует

Убейте поток который висит в синхронном вызове БД внутри чужой либы.
Реализуемы кстати вполне

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

(не на С++) и иногда единственный способ прибить трид,

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

естественно, стандарт с++ ничего не говорит о реализации pthread_cancel, т.к. не имеет к ней никакого отношения, однако в качественных реалиациях(например, в той, которой пользуюсь я) pthread_cancel раскручивает стек

Если знать все переопределенные операторы и конструкторы включая вызовы чужого кода - да.

надо просто знать, что чужой код thread- и exception-safe
однако, без этих знаний им в любом случае нельзя пользоваться

Я нигде не говорил о userlevel threads, я говорил о монотридном сервере.

который есть то же самое, только вырубленное своим собственным топором

Поинтересуйтесь как пишутся c10k сервера или реалтайм.

естественно, все на потоках

Если слово FSM ни о чем не говорит.

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

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

Я с массивными мультитридами не работаю уже лет 5 как минимум.
Ибо знаю к чему это ведет на нагруженных системах.

либо не повезло с реализацией потоков, либо не осилил

Неправда ваша.
Я что теперь могу void* не приводить к типу в С++?

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

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

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

Если вы считаете, что это хорошо и правильно - вы нерпавы.

что "это" ? что стандарт не менялся или что ты об этом не знаешь ?

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

не знаю, что они тогда говорили, но щас ядра выходят раз в 3 месяца, а они все еще выделяют
собственно, выбор у них не богатый

Если вы не понимаете почему это надо - то это не ко мне.
Посчитайте человеко-часы затраченные на переобучение и переписывание программ по новому стандарту и перевдите их в человеко-жизни - Освенцим получится.
Snacc ASN library написанная в 80-х на С компилится на ура - вы можете похвастаться тем же?

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

А на вопрос почему написанное под gcc не пашет под MSVC

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

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

он может даже и не чекать ничего, только толку в этом мало

А оптимизация и проверка ошибок задачи принципиально разные,

это только если языком чесать
а если реализовывать, то близко связанные
до такой степени, что у gcc некоторые ворнинги без -O не работали совсем до 4.4, а в 4.4 работают но не лучшим образом

Да только базовые требования виляли круче чем линия партии.

только в фантазиях непосвященных
в реальности они не менялись

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

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

Да и критерий здесь не простота и удобство - а функциональность.

деревья с повышенной функциональностью ?

Но только в С++ оно сократилось до постоянно употребляемой аббревиатуры...
Которая кстати объединяет еще одно специфичное понятие - unspecified behavior.
Многие плюсовики путаются.

которое тоже унаследовано из с

будем обсуждать пользу аббревиатур или соотношение путающихся ?

[Guffy]

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

[homo ludens]

в с она тоже нелинейная

ORLY?
Умолкаю перед гуру : -)

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

примерчик дашь?
Образуй плз, человека имевшего в 1999-м второе место в Одессе по С++ по Brainbench. : -)

естественно, стандарт с++ ничего не говорит о реализации pthread_cancel, т.к. не имеет к ней никакого отношения, однако в качественных реалиациях(например, в той, которой пользуюсь я) pthread_cancel раскручивает стек

Пользуйся на здоровье.
Вот тебюе примерчик использования.
http://sources.redhat.com/ml/glibc-bugs/2007-03/msg00006.html
Что характерно в С работает нормально. : -)

естественно, все на потоках

ORLY? : -)
Страшно далеки они от народа... (c)

говорит, только оно не работает

Как написать - так и работает

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

За всех людей не расписывайтесь. кое-кто думает и пишет
Промежуточное состояние отлично храниться где ему надо, с longjmp вообще все чистенько происходит и куча проблем уходит сразу.
И еще такой код умеет то, что мультипоток не сможет в принципе без очень большого геммороя. Рассчитанные тайминги в каждом участке кода. Что для RT-систем обслуживающих сотни тысяч соединений немаловажно. Плюс детерминированный код, который можно гарантированно оттестить (в отличие от мультипотока). Плюс отсутствие затрат на лишние переключения в мультитриде. Плюс жесткая привязка к конкретному ядру/процессору.
Масштабируемость в пределах мультиядра или мултипроца решается кластеризацией сервера - при этом можно расти сразу на кластерные системы. В отличие от мультитрида, за пределы компа не масштабируемого никак.
Хотя мультитрид удобней, да. : -)
Но если требования функциональности давят удобство - удобство идет лесом.
А если находятся программисты которые привыкли так писать (удобно) - то они идут лесом вместе с их концепциями.

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

Автоматы не могут работать не всегда или медленнее. : -)
Построение автомата - формальный процесс. Без переключения контекста автомат всегда будет быстрее (на одно ядро разумеется).
Хотя если писать его руками, без автоматической генерации кода зато с паттернами.... Жуть.
Вы наверное так писали? Бедняга...

не знаю, что они тогда говорили, но щас ядра выходят раз в 3 месяца, а они все еще выделяют
собственно, выбор у них не богатый

Естественно речь шла о переходе 2.2-2.4-2.6

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

Тогда огласите пожалуйста соотношение программ написанных по стандарту и не по стандарту.
А то что-то большой процент программ написанных не по стандарту попадается. Значительно больше чем на С

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

Огласите список кошерных компиляторов (если таковые существуют). И количество некошерных.
И объясните почему тогда программы для gcc 3 не всегда компилятся под gcc 4.
Его тоже мелкомягкие писали?

это только если языком чесать
а если реализовывать, то близко связанные
до такой степени, что у gcc некоторые ворнинги без -O не работали совсем до 4.4, а в 4.4 работают но не лучшим образом

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

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

Приводили уже на форуме ссылку - ни фига не падает.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

будем обсуждать пользу аббревиатур или соотношение путающихся ?

Аббревиатуры возникают не просто так. Это очень четкий симптом. Как план ГОЭЛРО или ВЧК.

[blackSun]

И объясните почему тогда программы для gcc 3 не всегда компилятся под gcc 4.

Ну они же развиваются. с внедрением C99 тоже не всё гладко. третий гцц забивает на inline. структуры там.

IDE ... Но это не значит что ее надо включать в компилятор.

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

трэды называть тридами это как то совсем никак. "монотридный" блин. вы же не химик... polling это кличут простые смертные. неблокирующий йо.

[mutex]

Мне кажется, что насчет "большинство софта" - это надо говорить очень осторожно. Если говорить о всяком софте который написан еще во времена царя гороха, то да там конечно почти везде Си, но новый софт как правило написан именно на Си++. Кеды как мне помнится на Си++ написаны... Гномеры сейчас полюбили libgtk-mm и тоже стали писать на Си++ (хотя мне кажется они скора все на mono перепишут).
Как язык для системного уровня Си++ имхо хуже Си. Иначе оно превращается в Си с элементами Си++. Ну и Си компиляторов всетаки под больше платформ есть.

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

[homo ludens]

Ну они же развиваются. с внедрением C99 тоже не всё гладко. третий гцц забивает на inline. структуры там.

Я говорил об совместимости снизу вверх. понятно что С99 или gnu99 код может не глако компилиться под gcc3.
Но здесь обратная ситуация - кошерный код под gcc3 не компилиться под gcc4.

трэды называть тридами это как то совсем никак. "монотридный" блин. вы же не химик... polling это кличут простые смертные. неблокирующий йо.

Ну, поллинг тоже разный бывает. Между epoll и select есть большая разница.
(почемуто вспомнился химик Лайнус Поллинг)
Сорри за непривычную терминологию.

Мне кажется, что насчет "большинство софта" - это надо говорить очень осторожно. Если говорить о всяком софте который написан еще во времена царя гороха, то да там конечно почти везде Си, но новый софт как правило написан именно на Си++. Кеды как мне помнится на Си++ написаны...

Я работаю на анализе и внедрении новых алгоритмов. Таких где статья выходит 2 года назад а код (академический) надо адаптировать сейчас.
С++ кода очень мало. В основном - С, иногда даже фортран встречается (там где надо, в математике например). Более того там где все-таки С++ - работает жутко. Если вообще работает. Исключения крайне редки (вот libsvm пользую - написан на С++ но интерфейсы - С. И с освобождением памяти проблемы есть).
Есть на джаве, но больше как proof of concepts либо как оболочки для интеграции других алгоритмов уже существующих на джаве (типа Weka).
Для large-scale неприменимо в 99%.
Парадокс кстати в том, что взглянув внутрь академического С-кода можно упасть в обморок.
Например http://www.rulequest.com/Personal/c4.5r8.tar.gz
Но посему-то, несмотря на огромное количество ворнингов при компиляции (включая например присваивание указателей int-ам) , на жуткий стиль - это отлично работает, в тч и на large-scale и на непривычных платформах.
С С++ - не так.
Последний пример - OpenDT library с отличным ООП дизайном у меня на 10000 примерах висела 40 часов пока я ее не убил. C-шный древний c4.5 250 миллионов координат просчитал за час и не пукнул.
Много таких примеров накопилось. Включая личную проверку STxxL на работоспособность.
С предсказуемым результатом.

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

Гномеры сейчас полюбили libgtk-mm и тоже стали писать на Си++ (хотя мне кажется они скора все на mono перепишут).

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

Вообще что думают Unix-way guys про С++ хорошо видно на этом классическом треде
http://thread.gmane.org/gmane.comp.version-control.git/57643/focus=57815
Я с мнением Торвальдса (и особенно с мнением Miles Bader) полностью согласен.
Так что получается, что это не только мое личное мнение, многократно высказываемое в коммьюнити до того как Торвальдса достали фанатичные плюсовики.

[blackSun]

код шикарен. даже конкретные примеры в двух случайных файлах..
ForEach(i, Xp, Lp - 1)
Verbosity(3) printf("\n");
if ( *Option++ != '-' ) return '?';

[homo ludens]

код шикарен. даже конкретные примеры в двух случайных файлах..
ForEach(i, Xp, Lp - 1)
Verbosity(3) printf("\n");
if ( *Option++ != '-' ) return '?';

Вот-вот. Там еще много таких моментов, сам фигел когда код читал.
Но при этом, в отличие от С++ клонов - работает на ура.
А правильно написанные C++ программы - падают.
Или вообще не компилятся.

Академический код - отдельная тема...
Хотя конечно бывают варианты разные.

C4.5 - показательный пример, написанный кстати автором метода и алгоритмов и никак не предназначенный для code-sharing между группами разработчиков. Т.е. при таком подходе все требования к стилю и все правила идут лесом - главное чтоб работало.
Что и наблюдаем.
При этом одна из лучших open-source реализаций DecisionTree от автора метода.
Так что не все то золото, что блестит.

[blackSun]

вы интересными вещами занимаетесь...

[pal]

ORLY?
Умолкаю перед гуру : -)

никаким количеством смайлов ты ее линейной не сделаешь

примерчик дашь?

https://fedoraproject.org/get-prerelease

Образуй плз, человека имевшего в 1999-м второе место в Одессе по С++ по Brainbench. : -)

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

Пользуйся на здоровье.
Вот тебюе примерчик использования.
http://sources.redhat.com/ml/glibc-bugs/2007-03/msg00006.html
Что характерно в С работает нормально. : -)

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

ORLY? : -)
Страшно далеки они от народа... (c)

народ это в зеркале ?

Как написать - так и работает

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

За всех людей не расписывайтесь. кое-кто думает и пишет

на этой планете люди думают не автоматами

Промежуточное состояние отлично храниться где ему надо,

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

с longjmp вообще все чистенько происходит и куча проблем уходит сразу.

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

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

это все пустая болтовня, т.к. к ненаписанной системе не применимо, а ничего сложного на автоматах не написано

Плюс отсутствие затрат на лишние переключения в мультитриде.

лишних переключений можно не делать, а можно делать и в автоматах

Плюс жесткая привязка к конкретному ядру/процессору.

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

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

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

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

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

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

где такую траву берут ?

Автоматы не могут работать не всегда или медленнее. : -)
Построение автомата - формальный процесс.

я бы еще добавил "воображаемый"
нету крупных программ, целиком реализованных в виде автомата

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

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

(на одно ядро разумеется).

т.е. в прошлом тысячелетии ?

Естественно речь шла о переходе 2.2-2.4-2.6

бессмысленное требование, т.к. они и так не выходили чаще, чем раз в 2 года
а теперь это заменено прогрессией 2.6.n->2.6.n+1 раз в 3 месяца

Тогда огласите пожалуйста соотношение программ написанных по стандарту и не по стандарту.

я не гугл

А то что-то большой процент программ написанных не по стандарту попадается. Значительно больше чем на С

в с стандарт слегка на 10 лет старше

Огласите список кошерных компиляторов (если таковые существуют). И количество некошерных.

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

И объясните почему тогда программы для gcc 3 не всегда компилятся под gcc 4.

потому что они для gcc3, а не для с++98
правильный вопрос - почему gcc3 их компилировал
ответ: потому что в то время они были больше заняты решением политических проблем, собственно их и до сих пор не перерешали

Его тоже мелкомягкие писали?

ну, в 2001 году у мелкомягких было только непотребство в виде msvc6

Если реализовывать то и IDE для оптимизации может быть полезна. Но это не значит что ее надо включать в компилятор.

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

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

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

Но людям, которые для развития языка (т.е. синтаксиса)

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

потребовалось переписывать линкер это похоже непонятно.

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

Приводили уже на форуме ссылку - ни фига не падает.
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

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

[blackSun]

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

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

ничего сложного на автоматах не написано

А те кто пишет на эрланге так не думают.
Десятое правило Гринспена подтверждает...

Отвлекёмся от темы. что господа думают о D ? Мне всёже захотелось ощутить вкус написания программ которые пишут программы в которых используются высокоуровневые абстракции в контексте "макроассемблера"(если так можно назвать си).

[blackSun]

мне кажется там настолько критическая концентрация плюсофилской фанатичности, что немножко догоняет лисп и хаскель. Они надумали compile-time execution. а если функция чистая то темболее. может даже надумают тайпклассы, чтобы сразу в compile-time оставлять только нужную логику. и лисповые макросы им покоя не дают. еще можно сделать partial compile-time application, или вкомпиливание результатов вычислений в зависимости от диапозона аргумента(тут хороши были бы тайпклассы) - просто такой массив на 65к элементов, если параметр - int