Ну ясно блин. Нашлись придурки которые помогают microsoft'у продвигать .NET делая mono, а санки держатся за свою java. Но кто сказал что C не подходит? Вот в чем на самом деле вопрос.

В статье есть одно упущение. C/C++ упоминаются как языки низкого уровня.
Насчет С я согласен. Но С++ в сочетании с необходимыми библиотеками вполне подходит для прикладного программирования.
Так что автор ведет читателя в заведомо ложном направлении.

ну здрасьте, вы хоть gtk и приложения на нем в жизни видели? =) а про портабельность знаете?

gtk и приложения на нем в жизни видели?

Не видели - расскажи а еще лучше покажи.

Людям обделенным знанием иносранного языка - общий смысл расскажите пожалуйста.

>Ну ясно блин. Нашлись придурки которые помогают microsoft'у продвигать .NET делая mono, а санки держатся за свою java. Но кто сказал что C не подходит? Вот в чем на самом деле вопрос.

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

>С++ в сочетании с необходимыми библиотеками вполне подходит для прикладного программирования.

Конечно подходит. Но сильно хуже других;-)

А насчет ложного направления - согласен, Ява вкупе с C#пом - ложное направление.

PS. Сейчас начнется holy war;-)

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

Кстати, С тоже "подходит" для прикладного программирования. Только далеко не для всех классов задач, а в определенных нишах.

А то Вы думали - зачем Хавок это все понаписал? Чтобы каждый линуховый форум взорвался флеймом. Одни только блоги гномовцев чего стОят - а ведь это еще, можно сказать, наиболее конструктивная и адекватная публика. Чего уж ждать от всяких ЛОРов и слышдотов?

Общий смысл

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

Некоторые проекты уже движутся в этом направлении. Например OpenOffice
частично написан на Java, Evoulution собирается писать новый код на
C#/Mono, но пока ожидает общего решения для всего проекта GNOME.

В первую очередь важен язык программирования, а не платформа целиком,
так как например GNOME будет использовать GTK+, а не XAML или Swing.

Высоко-уровневый язык нужен, потому что это
- более эфективное кодирование
- позволит построить открытую альтернативу MS XAML
- компонентная модель
- объеденение серверных и десктопных API, следовательно проще обучать
разработчиков
-

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

Некоторые проекты уже движутся в этом направлении. Например OpenOffice
частично написан на Java, Evoulution собирается писать новый код на
C#/Mono, но пока ожидает общего решения для всего проекта GNOME.

Основные причины:
- эффективное кодирование, в том числе уменьшение разнородности API,
кроссплатформенность, компонентная модель, итп.
- необходимость конкурировать с Большими Компаниями, в частности нужна
альтернатива XAML

Основные сложности:
- очень сложно принять какое-либо решение, так чтобы избежать
массированного ветвления (forks)
- решать надо быстро, пока MS не превратило инетрнет в один большой MSN

Что выбрать:
- NET не годится из-за проблем с IP и контроля MS за значительной частью
платформы
- Java может быть, но только если станет полностью открытой
- Такие языки как python/ruby/perl следует поддерживать в смысле
предоставления биндингов для них, но для больших приложений, как GNOME
или OO они -- не cамое верное решение

Предлагается начать кодировать на Java для GNOME, в качестве
proof-of-concept.

--------------------------------------

РЕЗЮМЕ:

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

>- NET не годится из-за проблем с IP и контроля MS за значительной частью платформы

Просвятите кто-нибудь, что за проблемы с IP, и что означает контроль МС применительно к пректу mono

>- Java может быть, но только если станет полностью открытой

А это утверждение на чём может основываться?

> Все эти явы и дот неты не на пустом месте возникли.

Вот уж кто не на пустом месте так это java. Я бы сказал "суровая необходимость". Да только java создавалась одной фирмой и пока решает (я имею ввиду "полностью решает") проблемы только этой фирмы (что вполне естественно). А если через 4 года у санок будет финансовый кризис? Прийдёт microsoft и скажет "покупаю java". Что тогда? Думаете откажутся ради "высоких идей". Скорее согласятся и тогда всё что будет сделано в Open-Source за эти годы станет только на руку M$. А M$ как всегда выкрутятся скажут что раз есть MONO, то они не монополисты :( Э-э какой однако нехороший каламбур получился :)

> А это утверждение на чём может основываться?

На том что контроль со стороны санок ничем не лучше контроля со стороны M$.

>На том что контроль со стороны санок ничем не лучше контроля со стороны M$.

А что может плохого от контроля конторы над языком произойти?

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

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

>А что может плохого от контроля конторы над языком произойти?

Известно, что. Зависимость от конторы, со всеми втекающими и вытекающими.

>Вот уж кто не на пустом месте так это java. Я бы сказал "суровая необходимость".
Ты бы почитал для начала, как и для чего делалась жаба. А потом бы позорился здесь

>Даже если бы я любил С++ (а я его очень не люблю), я бы все-таки признал, что разработка на жабке (не говоря уже про всякие скриптовые язычки - и про васик) - проще, быстрее и дешевле.

А если сюда добавить стоимость разработки необходимых оберток?
Я в этом отношении гномовцев не понимаю, честно говоря. Сначала они выбирают С, а не С++, аргументируя это тем, что к С можно понаписывать различных оберток для Perl/Phyton/etc, а потом отказываются использовать эти же обертки для прикладного программирования. Смысл в чем тогда был программить все на чистом С?

>Кстати, С тоже "подходит" для прикладного программирования. Только далеко не для всех классов задач, а в определенных нишах.
Я не говорю, что на С чего-то сделать нельзя. Я говорю, что это или трудно, или дорого, или долго. Что и подтверждает эта статья.

> Прийдёт microsoft и скажет "покупаю java".

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

> Ты бы почитал для начала, как и для чего делалась жаба.

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

> На том что контроль со стороны санок ничем не лучше контроля со стороны M$.

Есть разница. Если заглянешь на JCP то заметишь, что в экспертных группах сидит туча народу из разных контор "антимикрософтовского консорциума", которая стандартизирует все что папало, просто стандарт принадлежит Sun. Например из последнего спека на Portlets практически единолично сделана IBM. А с микрософтом вся беда, что все будет двигаться туда куда захочет 20 человек, о которых упоминал Билл. И в этом случае Novell остаеться только скрипеть зубами и делать решения, которые приняты внутри MSа. При чем MS Новелу копии спек посылать не будет, и все будет только postfactum, учитывая что моно это не просто .NET for xNIX, а альтернативный Runtime и под винду в том числе.

> А если сюда добавить стоимость разработки необходимых оберток?

Ну, тут можно как угодно считать. Я бы считал так, что обертки делаются один раз, а используются (в идеале:) многократно. Если нет многократного использования - конечно, тогда только С:)

> Я в этом отношении гномовцев не понимаю, честно говоря. Сначала они выбирают С, а не С++, аргументируя это тем, что к С можно понаписывать различных оберток для Perl/Phyton/etc, а потом отказываются использовать эти же обертки для прикладного программирования. Смысл в чем тогда был программить все на чистом С?

Ой, ну я же много раз объяснял свою и гномовцев точку зрения (в этом мы совпадаем). С++ - язык не годный в роли платформообразующего. С - годятся. И дело не только в написании различных оберток (ну, в конце концов через extern C можно было бы написать обертки для скриптовых языков) - а просто в том, что платформа, предназначенная для массового и кросс-языкового пользования, должна иметь API на С (сколь угодно ОО) - разумеется, это не касается таких "сама себе платформа", как Java и .NET. Посмотрите, опять же, как плюсанутая упертость kde мешает freedesktop.org.

Никто не "отказывается" использовать скриптовые языки. Просто пытаются осмыслить их место и роль в разработке гномовского десктопа. И определиться с нишами - для низкоуровных языков, для скриптовых, для "среднего звена" (Java/C#).

>А то Вы думали - зачем Хавок это все понаписал? Чтобы каждый линуховый форум взорвался флеймом. Одни только блоги гномовцев чего стОят - а ведь это еще, можно сказать, наиболее конструктивная и адекватная публика. Чего уж ждать от всяких ЛОРов и слышдотов?

Да, флейм - это святое)
Думаю, гномовцам нужно пойти по своему пути. Принятие Java или моно будет выглядеть, как очередное признание несостоятельности гнома, как платформы. Но ИСПОЛЬЗОВАТЬ привязки. Не все, но хотя бы сделать упор на одной из существующих. Python, например.
Привязки С++ к гному вряд ли будут пользоваться популярностью, т.к. те, кто хотел С++ давно уже на Qt/KDE сидят.
Короче, делать свою платформу, а не оглядываться, чего там Sun с IBM подкинут.

> А что может плохого от контроля конторы над языком произойти?

Отсутствие "равных возможностей" для всех сейчас или в будущем. Т.е. допустим если я захочу сейчас сделать форк java (причины это отдельный вопрос может мне просто так захотелось от нефиг делать :) то теоретически это может вызвать лицензионные проблемы. А практически это их вызовет в том случае если моя java будет угрожать фирме (например будет популярнее). Я прекрасно понимаю что это маловероятно, но не иметь перспективы означает не иметь стимула.

Возможное изменение стандарта "без спроса" (это без коментариев)

Проблемы с включением java в дистрибутивы linux'a (имеется ввиду "настоящие" т.е. те которы не плевать на нарушения GPL)

> А если сюда добавить стоимость разработки необходимых оберток?

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

> Я в этом отношении гномовцев не понимаю, честно говоря. Сначала они выбирают С, а не С++, аргументируя это тем, что к С можно понаписывать различных оберток для Perl/Phyton/etc, а потом отказываются использовать эти же обертки для прикладного программирования.

Вроде в статье сказано, что ипользование этих языков для прикладного программирования они очень даже приветствуют, но в качестве основного средства разработки проекта GNOME не возьмут. Могли бы взять технологию класса Java/NET, но такой пока нет.

Мне другое не ясно -- откуда такое стремление все написать на одном языке? Сколько лет уже люди пишут на Си и Фортране вперемежку, и не жалуются. Так же можно было бы писать на C/ruby, или C++/Scheme, почему нет?

> Мне другое не ясно -- откуда такое стремление все написать на одном языке?

Видимо так лучше взаимопонимание. Как минимум некому кричать RULEZZ, MUSTDIE и т.д.

>Ну, тут можно как угодно считать. Я бы считал так, что обертки делаются один раз, а используются (в идеале:) многократно. Если нет многократного использования - конечно, тогда только С:)

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

>Ой, ну я же много раз объяснял свою и гномовцев точку зрения (в этом мы совпадаем). С++ - язык не годный в роли платформообразующего. С - годятся. И дело не только в написании различных оберток (ну, в конце концов через extern C можно было бы написать обертки для скриптовых языков) - а просто в том, что платформа, предназначенная для массового и кросс-языкового пользования, должна иметь API на С (сколь угодно ОО) - разумеется, это не касается таких "сама себе платформа", как Java и .NET.

BeOS была полностью на С++ написана. Это так, пример "платформообразующего" языка.
С годится, когда проект небольшой. А "платформообразующий" проект таковым не является.

>Посмотрите, опять же, как плюсанутая упертость kde мешает freedesktop.org.
Чего они там не поделили, можно поинтересоваться?

> > На том что контроль со стороны санок ничем не лучше контроля со стороны M$.

> Есть разница.

Только до тех пор пока санки не могут себе позволить вести себя как M$. А до этого буквально рукой подать. Всего лишь один бизнес день в который Sun заключат "стратегическое соглашение" с M$. И снова таки никаких претензий насчёт монополизма не выдвинешь.

>Вроде в статье сказано, что ипользование этих языков для прикладного программирования они очень даже приветствуют, но в качестве основного средства разработки проекта GNOME не возьмут. Могли бы взять технологию класса Java/NET, но такой пока нет.

Привожу в оригинале:

My view, which will doubtless get me flamed, is that these languages aren't really the right thing for writing large desktop apps such as GNOME or OO.org, though they are nice for a lot of other purposes.

То есть Java для этих целей лучше подходит что ли? В общем, что бы гномовцы не выбрали (если не С/С++ конечно же), гном будет все тормознее и тормознее.

>Мне другое не ясно -- откуда такое стремление все написать на одном языке? Сколько лет уже люди пишут на Си и Фортране вперемежку, и не жалуются. Так же можно было бы писать на C/ruby, или C++/Scheme, почему нет?

А зачем вводить лишние сущности? Тем более если проект реализуем на одном языке? Просто дешевле в сопровождении.

> Видимо так лучше взаимопонимание. Как минимум некому кричать RULEZZ, MUSTDIE и т.д.

Бред. Flamewars здесь совсем непричем.

> Вот поэтому я и предлагаю большее внимание уделять оберткам (то, ради чего и планировался сам гном, как я понимаю).

Я - только за внимание к оберткам. Более того, недавнее введение единой политики с системы релизов GNOME Bindings - как раз про это. Неужели плохо?

> BeOS была полностью на С++ написана. Это так, пример "платформообразующего" языка.

И где она теперь?:) Если серьезно, без флейма, то я ставлю памятник авторам BeOS, если им удалось обойти все потенциальные грабли, на которые провоцирует наступать С++ - и, что более важно - сделать эти грабли видимыми и не лежащими на пути всех тек, кто будет их API пользовать.

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

Угу. Стандартная libc и ее реализация glibc - совсем маленький "проект". А еще xlib и всякие api иксовых расширений - тоже маленькие. Про windows.h (может, не самый лучший в мире API - но уж точно не самый худший, особенно с учетом того, что в нем наслаиваются результаты десятилетнего развития). С - язык достаточно масштабируемый (да, не настолько, насколько Java).

Но С++ в этом смысле, МНЕ КАЖЕТСЯ, хуже. Он провоцирует - и не держит своих обещаний. С изначально настраивает на то, чтобы думать для достижения масштабируемости. С++ обещает скорость С при масштабируемости, догоняющей более высокоуровневые языки - но в большинстве случаев так не получается. Потому как народ "расслабляется" и начинает лепить горбуху, теряя по дороге и скорость, и (позже) способность развивать проект. На С - не расслабишься:) Это мои субъективные ощущения от опыта работы на С++ и опыта общения с разработчиками на С++ - но указания на подобный опыт я встречал.

> Чего они там не поделили, можно поинтересоваться?

Разумеется, можно:) freedesktop.org, как всем присутствующим известно, пытается устанавливать стандарты, которые обеспечивали бы интеграцию десктопов на "среднем" уровне (если считать нижним уровнем голые иксы и позикс). Взаимодействие приложений, единая система конфигурации и пр. и пр. Частью работы над стандартами является создание API и reference implementations (что тоже логично). Так вот хроническая проблема в том, что народ из KDE не любит, не уважает API на C. Давно была идея - стандартизовать glib в виде объектной модели freedesktop.org - как некий минимальный уровень переносимой объектности, доступной любой среде, оконному менеджеру и пр. Линковка с glib добавляет копейки в любой, даже самый маленький wm. Но нет, гордые любители С++ не хотят оборачивать glib своей QT/C++ моделью. Поэтому те reference implementations, которые все-таки используют glib, делают это стыдливо, подпольно (просто импортируют дерево glib в свой проект). Или просто копи-пастят код, что тоже замечательно (кстати, я бы лично с удовольствием использовал glib в libxklavier - но не буду этого делать, пока freedesktop.org не стандартизует ее). И дальше будет хуже. Чем сложнее будут стандарты freedesktop.org (например, единая система конфигурирования) - тем сложнее должны быть API и reference implemenations - и тем острее встанет проблема нелюбви к С. Или - как альтернатива - больше не будет API, все будут работать через DBUS - таким образом, политическая проблема будет решена за счет технических средств (ценой производительности, разумеется).

> Ты хочешь сказать, что она от нефиг делать возникла? Без необходимости?
Жаба - это 100% маркетинг. Она возникла вопреки. И агрессивно (хлеще MS)насаждалась. Технологически - это порнуха. Можно найти воспоминания какого-то оберонщика, где он без прикрас описывает деятельность Гослинга в начале пути.

В конце-концов, вся архитектура жабы проектировалась под АППЛЕТЫ.
А потом стали подтыкать ей костыли вроде jit'ов.

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

Ты не понял. Я не знаю, чем отличается IP от Microsoft от... И прошу это объяснить.

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

/But momentum is already shifting; Microsoft's monopoly power threatens to deflate Java and substitute .NET. The large open source projects could drive Java deep into Linux, and bring it new life, just as Linux revived UNIX as a whole. But first we need an open source Java implementation./

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

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

А этого как раз допускать нельзя, враг не дремлет и постепенно готовится певратить интернет в msn, прямо как в xbill ;)

>Но С++ в этом смысле, МНЕ КАЖЕТСЯ, хуже. Он провоцирует - и не держит >своих обещаний. С изначально настраивает на то, чтобы думать для >достижения масштабируемости. С++ обещает скорость С при >масштабируемости, догоняющей более высокоуровневые языки - но в >большинстве случаев так не получается. Потому как народ "расслабляется" >и начинает лепить горбуху, теряя по дороге и скорость, и (позже) >способность развивать проект. На С - не расслабишься:) Это мои >субъективные ощущения от опыта работы на С++ и опыта общения с >разработчиками на С++ - но указания на подобный опыт я встречал.


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

лукавствуете ведь. гугли вам в помощь и попутный ветер в...

> Более откровенного бреда я еще не встречал... > Милейший! Для того, чтобы делать заключения о полезности или безполезности того или иного инструмента, нужно научится этим инструментом владеть. Ну а если не судьба, то - "на зеркало неча пенять коли рожа крива".

Несколько хамовато, но это поскипаем.

Даже если счесть меня никудышным плюсистом, я слышал подобные отзывы о языке С++ от тех, которых я бы посчитал достаточно компетентными в данном вопросе. Кроме того, я не сказал, что на С++ НЕЛЬЗЯ писать эффективно и масштабируемо. Можно ("если осторожно") - именно про это я говорил в параграфе о BeOS. Но я ВИДЕЛ немалое кол-во C++ кода, написанного так, будто человека "подталкивали" писать криво. И задавая вопрос - что именно подталкивало, что общее у этого кода, написанного достаточно разными людьми - я видел, что это язык. Да, криво можно написать на любом языке. Но кривой С++ код - это совсем не то, что кривой С код (или кривой жабский код). С ничего не обещает - поэтому с ним, традиционно, работают достаточно осторожно. С++ создает видимость защищенности - и обманывает.

>Я - только за внимание к оберткам. Более того, недавнее введение единой политики с системы релизов GNOME Bindings - как раз про это. Неужели плохо?

Плохо, что в статье это не нашло должного внимания.

>И где она теперь?:)

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

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

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

>Угу. Стандартная libc и ее реализация glibc - совсем маленький "проект". А еще xlib и всякие api иксовых расширений - тоже маленькие.

glibc на С по определению. А вот создателям xfree/xlib я бы памятник не поставил. Потому как развиваются очень медленно. Потому как когда-то выбрали С.

>Но С++ в этом смысле, МНЕ КАЖЕТСЯ, хуже. Он провоцирует - и не держит своих обещаний. С изначально настраивает на то, чтобы думать для достижения масштабируемости. С++ обещает скорость С при масштабируемости, догоняющей более высокоуровневые языки - но в большинстве случаев так не получается. Потому как народ "расслабляется" и начинает лепить горбуху, теряя по дороге и скорость, и (позже) способность развивать проект. На С - не расслабишься:) Это мои субъективные ощущения от опыта работы на С++ и опыта общения с разработчиками на С++ - но указания на подобный опыт я встречал.

Я бы настоятельно порекомендовал почитать Страуструпа по этому поводу. Очень отрезвляет. "Дизайн и эволюция С++".

>Давно была идея - стандартизовать glib в виде объектной модели freedesktop.org - как некий минимальный уровень переносимой объектности, доступной любой среде, оконному менеджеру и пр. Линковка с glib добавляет копейки в любой, даже самый маленький wm. Но нет, гордые любители С++ не хотят оборачивать glib своей QT/C++ моделью.

Это не их (кдешников) вина. Я бы сказал, что это вина Trolltech, но это будет неправдой. КДЕ завязаны на классах Qt. А классы Qt должны быть максимально переносимы. Не думаю, что объектная завязка на glibc этому поспособствует.

>Поэтому те reference implementations, которые все-таки используют glib, делают это стыдливо, подпольно (просто импортируют дерево glib в свой проект).

Как это? А почему не прилинковаться динамически?

>И дальше будет хуже. Чем сложнее будут стандарты freedesktop.org (например, единая система конфигурирования) - тем сложнее должны быть API и reference implemenations - и тем острее встанет проблема нелюбви к С.

Оправдывает ли цель средства?
Только Qt и KDE используют разные системы конфигурирования. По историческим причинам. И этот недостаток устранить легче, чем внедрить единую в пределах всей ОС систему конфигурирования. Но он не устранен, насколько мне известно. Наверно из-за совместимости. Поэтому вопрос, стоит ли эта цель затраченных средств (как минимум, потеря совместимости)?

> Жаба - это 100% маркетинг. Она возникла вопреки.

> В конце-концов, вся архитектура жабы проектировалась под АППЛЕТЫ.

Сам себе противоречишь. Определись либо для апплетов либо вопреки (и если вопреки то чему).

> И агрессивно (хлеще MS) насаждалась.

M$ ни кем не насаждается. Ты сам её вибираешь потому что или не разбираешься больше ни в чём (возможно просто не хочешь) или потому что M$ купила то что тебе нравиться. Или благодаря лучшей поддержке плохого (noname) железа.

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

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

>Кроме того, я не сказал, что на С++ НЕЛЬЗЯ писать эффективно и масштабируемо. Можно ("если осторожно") - именно про это я говорил в параграфе о BeOS. Но я ВИДЕЛ немалое кол-во C++ кода, написанного так, будто человека "подталкивали" писать криво. И задавая вопрос - что именно подталкивало, что общее у этого кода, написанного достаточно разными людьми - я видел, что это язык. Да, криво можно написать на любом языке. Но кривой С++ код - это совсем не то, что кривой С код (или кривой жабский код). С ничего не обещает - поэтому с ним, традиционно, работают достаточно осторожно. С++ создает видимость защищенности - и обманывает.

С++ очень сложный инструмент (во всяком случае, по сравнению с С). Поэтому при неумелом использовании он более опасен, чем С. Но при умелом - он более эффективен. Конечно, вы можете предпочесть "ручную дрель" "станку", потому что она более безопасна. Но вопрос в том, сколько "отверстий" вам надо сделать и за какое время.

> Плохо, что в статье это не нашло должного внимания.

Встречу Хавока - передам Ваше недовольство:)

> glibc на С по определению. А вот создателям xfree/xlib я бы памятник не поставил. Потому как развиваются очень медленно. Потому как когда-то выбрали С.

Да, libc (я не про реализацию glibc - я про позиксовую семантику) на С по определению. Но ведь не маленький API. И вполне справляется определять базовые униховые функции. xfree и xlib Вы совершенно зря в один флакон запихали. Если xfreе еще можно обвинять в разных смертных грехах - то xlib - это только нижнеуровневый клиентский API к x window system (одна из реализаций которого входит в xfree). Так вот API xlib тоже очень немаленький (и, кстати, развиваться-то ему особо не надо - он делает именно то, для чего задумывался).

> Я бы настоятельно порекомендовал почитать Страуструпа по этому поводу. Очень отрезвляет. "Дизайн и эволюция С++".

Спасибо, вообще я его читал, но конкретно эту работу - нет. На досуге посмотрю. Но, при прочтении ДРУГИХ работ у меня было некоторое ощущение того, что на бумаге все гладко, но овраги при этом все-таки есть (я читал их уже после некоторого времени индустриального программирования на С++). В этом смысле он у меня ассоциируется с книжками про UML - хотя там, конечно, все значительно более запущено:)

> А классы Qt должны быть максимально переносимы. Не думаю, что объектная завязка на glibc этому поспособствует.

Вы путаете glibc и glib. Я говорю про glib. Она очень маленькая и очень переносима (кстати, я бы не стал говорить про объектную модель glibc).

> Как это? А почему не прилинковаться динамически? Потому как на KDE десктопе нельзя рассчитывать на наличие glib.h - а собирать как-то базовые пакеты надо. Например, смотрите сюда: http://freedesktop.org/cgi-bin/viewcvs.cgi/pkgconfig/pkgconfig/. Видите там glib-...tar.gz?

> Поэтому вопрос, стоит ли эта цель затраченных средств (как минимум, потеря совместимости)?

Мне кажется, стОит. Да, есть проблема совместимости во временнОм измерении. Но есть и проблема отсутствия ее в смысле совместной работы разных приложений. Например (это уже тут обмусоливали) - хочется, чтобы пользователь ОДИН раз сообщил системе про любимый браузер и терминал. Как Вы это сделаете, если KDE приложения используют свою систему конфигурирования, GNOME приложения - свою - а пользователь хочет использовать оба мира (например, будучи пользователем гнома, я не знаю лучшей оракловой утилиты для линуха, чем Tora)?

Проблема временнОй совместимости есть. Но достаточно длительный "переходной период" может смягчить ее остроту.

> "Достаточно компетентные" в этом вопросе так бы не сказали, если бы таковыми были. В общем, как всегда, было лень разбираться...

Кому? Мне, им? Или Вам?:) Короче, обвинение собеседника в умопомрачительной некомпетентности - было и остается главным оружием ЛОРа. Ну, как Вам будет угодно...

> С++ очень сложный инструмент (во всяком случае, по сравнению с С). Это точно! Неоправданно сложный.

> Поэтому при неумелом использовании он более опасен, чем С. Но при Во! И тут я почти согласен! А ответьте - откуда эта повышенная опасность взялась? Не Страуструп ли ее принес, пытаясь совместить высоты ОО с ассемблером PDP?

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

Вот и договорились - речь идет о сравнении дрели и станка. Так вот по количеству отверстий python/perl/visual basic обгонят С++. А вот если я хочу сделать ажурненькие украшения на спинке кресла - я, извините, возьму ручную дрель. И, заметьте, станки скриптовых языков (как и станки всяких жаб и шарпов), по сравнению со станком С++ - гораздо безопаснее (хотя, возможно, отверстия будут не столь аккуратными, как те, которые МАСТЕР сделает на С++ - но в пределах допусков, принятых в индустрии).

>Встречу Хавока - передам Ваше недовольство:)

Да его уже, наверно, засыпали письмами)

>xfree и xlib Вы совершенно зря в один флакон запихали. Если xfreе еще можно обвинять в разных смертных грехах - то xlib - это только нижнеуровневый клиентский API к x window system (одна из реализаций которого входит в xfree). Так вот API xlib тоже очень немаленький (и, кстати, развиваться-то ему особо не надо - он делает именно то, для чего задумывался).

А разве разработчики у них не одни и те же?

>Вы путаете glibc и glib. Я говорю про glib. Она очень маленькая и очень переносима (кстати, я бы не стал говорить про объектную модель glibc).

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

>> Я бы настоятельно порекомендовал почитать Страуструпа по этому поводу. Очень отрезвляет. "Дизайн и эволюция С++".

>Спасибо, вообще я его читал, но конкретно эту работу - нет. На досуге посмотрю.

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

Мне знакомы проблемы о которых Вы говорите. Я писал/пишу на С++. С этими проблемами я сталкивался в первые 3 года использования языка. Проект вдруг неожиданно превращается в кашу в которой невозможно что-то изменить. Это прошло с появлением опыта в написании больших (я оцениваю так проекты в полмиллиона строк) проектов, долгих раздумий как улучшить код, чтения литературы по проектированию (GoF), рефакторингу и повышения уровня владения языком.

>Мне кажется, стОит. Да, есть проблема совместимости во временнОм измерении. Но есть и проблема отсутствия ее в смысле совместной работы разных приложений. Например (это уже тут обмусоливали) - хочется, чтобы пользователь ОДИН раз сообщил системе про любимый браузер и терминал. Как Вы это сделаете, если KDE приложения используют свою систему конфигурирования, GNOME приложения - свою - а пользователь хочет использовать оба мира (например, будучи пользователем гнома, я не знаю лучшей оракловой утилиты для линуха, чем Tora)?

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

> А разве разработчики у них не одни и те же?

М-м. У xlib, строго говоря, разработчиков нет. Были - те, которые стандарт разрабатывали (и, наверно, первую реализацию). Это просто стандартный API, реализации которого поставляются в составе всех x servers, которые мне известны (включая xfree)

> Но если она такая маленькая, то и экономия от ее использования будет небольшой.

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

> А вообще, это лучше с троллями связываться.

Да я не прошу Вас немедленно установить мир во всем мире и убедить троллей в полезности стандартизации glib. Я просто демонстрирую, как плюсовая упертость - и ориентация на С++ как платформообразующий язык - мешает обьективно прогрессивным процессам.

Какого "этого файла"??? А если мы хотим хранить установки на LDAP сервере - и менеджить централизованно для всего офиса (например хотим централизованно запрещать одним - разрешать другим пользователям вызывать терминальное окно)? Извините, но система конфигурации - это более сложно, чем просто договоренность о файле ~/.config/mime. Это архитектура. И пользовательская сторона архитектуры - API.

Чай? Кофе? Потанцуем? :)

2 ANDI:

У тебя тут опечатка (по-Фрейду). Судя по тому, с какой легкостью ты путаешь glibc и Glib, я заключаю, что не знаешь ты идею Glib и архитектурные особенности GNOME (ну или плохо понимаешь). Просто svu с присущей ему вежливостью весьма политкорректно тебе об этом намекнул. :)

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

И это предлагает программист на C++! А где же абстракция? :-) Кровью запахнет, когда формат этого файла потребуется изменить или вообще поменять способ хранения информации. Мне кажется, что лучше иметь одну библиотеку с хорошо определенным интерфейсом, а там уж пусть она сама со всем разбирается.

> > "Достаточно компетентные" в этом вопросе так бы не сказали, если бы таковыми были. В общем, как всегда, было лень разбираться...

> Кому? Мне, им? Или Вам?:) Короче, обвинение собеседника в умопомрачительной некомпетентности - было и остается главным оружием ЛОРа. Ну, как Вам будет угодно...

Я только сделал предположение, почему они это вам сказали. Ничего личного.

> > С++ очень сложный инструмент (во всяком случае, по сравнению с С). Это точно! Неоправданно сложный.

Оправданно. Не надо думать о программистах, что они ни на что не способны. Это их работа.

> Во! И тут я почти согласен! А ответьте - откуда эта повышенная опасность взялась? Не Страуструп ли ее принес, пытаясь совместить высоты ОО с ассемблером PDP?

Вы знали :)

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

>Так вот по количеству отверстий python/perl/visual basic обгонят С++.

Одного языка недостаточно для эф.программирования.

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

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

Конечно. И сколько это кресло потом будет стоить?

> И, заметьте, станки скриптовых языков (как и станки всяких жаб и шарпов), по сравнению со станком С++ - гораздо безопаснее (хотя, возможно, отверстия будут не столь аккуратными, как те, которые МАСТЕР сделает на С++ - но в пределах допусков, принятых в индустрии).

У всех этих "станков" перед С++ есть один большой недостаток - у них низкооборотный двигатель :)