По статье, собственно. Позвольте высказать скептическую точку зрения. IMHO, ситуация, обрисованная Havoc, безвыходна. Я подума-подумал и пришел к выводу, что путь, по которому идет сейчас GNOME - весьма правильный и не надо обращать взоры ко всяким Java/.NET Но если рассматривать две эти платформы между собой, то лично мне больше нравится .NET, но не потому что она там частично открыта и частично стандартизована. Совсем нет. Важно, что .NET - многоязыковая платформа, в отличие от Java. А кто сказал, что я зык должен быть один? Уже сколmко попыток у человечества было в попытках найти универсальный язык... Но тщетно... We are different... И это аксиома.

А чем GNOME не многоязыковая платформа? Биндинги, скажем, для GTK+ (который базируется на объектной модели, описанной в Glib) без особого труда делаются для разных языков. И это благодаря именно использованию Cи, который есть - промышленный стандарт, стандартизированный не только американским ANSI, но и ISO! А что Java? А что там .NET? Тишина...

Кто не согласен?

Почти уговорили. Дойдут руки, найду время - почитаю.

Первые 3 года, говорите. Ну, скажем, я плюсами занимался лет ... 5, наверное. Да, большинство грабелек я научился обходить (спасибо, учителя были хорошие). Но потом достало. И достало слышать вокруг треск этих грабель по чужим лбам (особенно бывает обидно, когда чужие грабли бьют по твоем собственному лбу). Потом я ушел зарабатывать деньги на жабских станках - и заниматься художественной резьбой на С в свободное время.

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

Вон Вы куда клоните...
По-моему, это нужно делать др. средствами, а не системой конфигурирования.

Ну, насчет .NET как многоязыковой платформы... Я не буду ничего утверждать, т.к. видел .NET раз или два, но действительно ли языки .NET отличаются друг от друга не только формой записи цикла, объявлением переменных и прочей мелочью? Мне кажется, например, что тем, кто программировал на VB потребуется некоторая адаптация к VB.NET. Очень даже могу ошибаться.

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

Ладно, замяли:)

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

Ну, строго говоря, и жабка тоже гибридый. И шарп. И питон. Но вот то, что Бьярн выбрал совместимость - мне кажется, было не очень хорошо. Конечно, мне вольнО тут рассуждать с умным видом о работе человека, трудами которого пользуются и кормятся тысячи - но, я думаю, что лучше бы он был не настолько последовательным в смысле совместимости с С. Да и полной совместимости все равно не получилось - не весь С код компилируется С++ компилятором, у них достаточно разная строгость в отношении к типам и пр. Да и не только в совместимости дело. Я видел кучу лбов (включая собственный), разбитых конструкторами (особенно - конструкторами копирования), переопределенными операторами (особенно - операторами присваивания) и пр. и пр. - к чему совместимость с С имела опосредованное отношение.

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

Не уверен. Дело не только в библиотеках (которых на С наверняка больше:). Скажите, что будет с программой на С++, если она разыменует нулевой указатель? Сколько времени у Вас уйдет на определение точки падения? Или Вы везде используете только безопасные? И чего Вам это стОит по производительности?

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

Дорого. Однозначно. А если мне нужно по-быстрому понаделать табуреток для гарнизонной столовой - я беру жабу в руки и ... А другой возьмет питон. Зато уж креслице можно заделать такое ...:) - и руки не оторвет, потому как ручная дрель, обороты нестрашные, точность большая.

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

Угу. Я же пишу: "в пределах допусков, принятых в индустрии":) И, кстати, "против" С++ играет то, что производительность железа сильно дешевле труда программистов (даже не очень квалифициарованных). А уж если вознимают "такие" требования к производительности - тогда, может, и за ручную работу можно заплатить, а? Не всегда, конечно С годится - ниша для С++ безусловно существует. Но уж никак в роли платформообразующего языка.

> Важно, что .NET - многоязыковая платформа, в отличие от Java.

Тут у Сана маркетинговый перекос, недоработочка. JVM выполняет байт-код. Так вот МНОЖЕСТВО компиляторов для РАЗНЫХ языков в жабский байткод существовало задолго до того, как МС объявил дотнет. Ссылки нужны?

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

Незнание арх. особ. гнома я не скрываю.
А Glib вообще никогда не использовал, и знал его только под именем пакета "libglib".
А замечание svu расставило мне все точки над i.

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

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

Интерестно, значит стандартизировать формат desktop-файлов - это нормально, а конфигурационных - это уже преступление?

Эк Вы его уели!:) Но ведь мы же договорились, что это может быть не файл вааще, правда?

>Раскрываю карты. Я клоню к gconf (ну или к чему угодно, реализующему ту же функциональность при независимости от бекенда).
>Эк Вы его уели!:) Но ведь мы же договорились, что это может быть не файл вааще, правда?

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

Ну Вы же взрослый человек, Вы же понимаете - что API - это одно, реализация бэкенда - другое. Там Вам и локальный кэш, и значения по умолчанию, и кластеризация-репликацией и все изыски, какие в голову придут. Но ведь Вы уже поняли, что нужен хороший API. И на каком языке он должен быть сформулирован? Правильно! И на каком языке лучше делать reference implementation? Правильно!!

Ну, во-первых, я не говорил этого: "стандартизировать формат desktop-файлов - это нормально, а конфигурационных - это уже преступление".

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

Ну а в-третьих, я всегда считал, что desktop-файлы из разряда конфигурационных.

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

Иначе язык просто не приняли бы. Вначале это был просто "С с классами". В книге все причины расписаны ;-)

>Я видел кучу лбов (включая собственный), разбитых конструкторами (особенно - конструкторами копирования), переопределенными операторами (особенно - операторами присваивания) и пр.

Вы имеете ввиду, что может произойти неявное преобразование типа в конструкторе? Дык на то explicit существует.

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

Грохнется, как и программа на С.

>Сколько времени у Вас уйдет на определение точки падения?

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

>Или Вы везде используете только безопасные? И чего Вам это стОит по производительности?

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

>И, кстати, "против" С++ играет то, что производительность железа сильно дешевле труда программистов (даже не очень квалифициарованных).

но согласно этому утверждению, стоимость С программы выше.

Чай? Кофе? Водки? :)

2 svu: Если не очень долго искать и у тебя есть времени немного на это, то приведи. Было бы интересно... А еще интересны комментарии по теме "и куда же это все подевалось?" :) А не является ли JVM "заточенной" (читай "оптимизированной") именно под язык Java? Может по причине этой оптимизированности все другие компиляторы исчезли? В этом надо опять маркетинг Sun объявить виноватым или все-таки были другие причины? Я истории по этому вопросу, к сожалению, не знаю... Поэтому и спрашиваю.

2 ANDI: Я не хотел наезжать. Просто так получилось. Хорошо, что я хоть смайл поставил в конце :)

В общак. С первого взгляда Glib можно было бы назвать так - "объектная библиотека для хакеров, не желающих писать на C++" и относиться к ней соответсвующим образом. Вот именно так бы подумал школьник/студент, у которого в голове только Delphi. Но когда начинаешь задумываться не только об обычном софтостроительстве, но и о глобальных вещах: "переносимость", "многоязыковость", "платформообразующие технолигии", то постепенно приходишь к пониманию, что такое Glib с ее GObject и пр. ее компонентами. Да, в Glib есть компромисы. Да, там есть некоторые корявости, заставляющие писать гораздо больше кода, чем если все делать на плюсах. При работе в C надо постоянно быть внимательным, к тому, что пишешь... А вот использование C++ в качестве платформообразующего языка, как правильно заметил svu, в корне неправильно. Язык хороший, но в качестве "общего знаменателя" не подходит. Си подходит больше.

> Не уверен. Дело не только в библиотеках (которых на С наверняка больше:).

Именно в них. Для языка, который даже не имеет своей системы ввода-вывода, эффективность зависит именно от библиотек.

>Скажите, что будет с программой на С++, если она разыменует нулевой указатель? Сколько времени у Вас уйдет на определение точки падения? Или Вы везде используете только безопасные? И чего Вам это стОит по производительности?

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

>Дорого. Однозначно. А если мне нужно по-быстрому понаделать табуреток для гарнизонной столовой - я беру жабу в руки и ... А другой возьмет питон. Зато уж креслице можно заделать такое ...:) - и руки не оторвет, потому как ручная дрель, обороты нестрашные, точность большая.

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

> Иначе язык просто не приняли бы. Вначале это был просто "С с классами". В книге все причины расписаны ;-)

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

> Вы имеете ввиду, что может произойти неявное преобразование типа в конструкторе?

Не только. На моей памяти больше всего народу страдало от склероза - забывали "&" поставить. А также путались, что же будет вызываться - присвоение или конструктор присваивания в некоторых нетривиальных ситуациях (да чего греха таить, и в тривиальных тоже:). А передача объектов в функции по значению, когда люди просто "забывают", что объекты начинают копироваться-конструироваться. Были и другие грабли, просто эти всплыли в голое первыми, как самые частые. Да, они все лечатся опытом и медитацией. Но сколько времени проходит, пока народ научится замечать их издали!

> существуют инструменты нахождения подобных ляпов

> а в релизе проверка на нулевой указатель внутри него отключается

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

> остаётся только стоимость смарт-поинтера ... составляет буквально несколько тактов

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

> но согласно этому утверждению, стоимость С программы выше.

Мы уже договорились, что кресла, сделанные на С - жутко дОроги. Но на них всегда будут богатенькие покупатели:)

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

Никуда не подевалось. Живет. Из самых попсовых - живы jpython, jscheme. Просто сантехники не хотят этого поднимать на свой маркетинговый щит. Почему - спросите их. Какие-то политические причины, наверное.

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

>Ну Вы же взрослый человек, Вы же понимаете - что API - это одно, реализация бэкенда - другое. Там Вам и локальный кэш, и значения по умолчанию, и кластеризация-репликацией и все изыски, какие в голову придут. Но ведь Вы уже поняли, что нужен хороший API. И на каком языке он должен быть сформулирован? Правильно! И на каком языке лучше делать reference implementation? Правильно!!

Если эта система будет разработана, то какие могут быть проблемы с ее использованием в KDE?
Насчет использования С в данном случая я полностью согласен.

> эффективность зависит именно от библиотек

Не только. Легкость сопровождения, скорость обнаружения ошибок, длительность цикла отладки - это тоже немаловажно.

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

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

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

А если она будет основана на объектной модели glib?

>назовем это просто маркетинговым ходом, за который приходится иногда платить:)

Не, маркетинга там не было вообще, об этом в книге написано ;-)

>Не только. На моей памяти больше всего народу страдало от склероза - забывали "&" поставить. А также путались, что же будет вызываться - присвоение или конструктор присваивания в некоторых нетривиальных ситуациях (да чего греха таить, и в тривиальных тоже:). А передача объектов в функции по значению, когда люди просто "забывают", что объекты начинают копироваться-конструироваться. Были и другие грабли, просто эти всплыли в голое первыми, как самые частые. Да, они все лечатся опытом и медитацией. Но сколько времени проходит, пока народ научится замечать их издали!

Года два, три ;-) чесное слово. А, вообще, я думаю, если бы начальство регулярно заставляло бы программеров в обязательном порядке тесты сдавать на такую хрень, о которой надо обязательно всегда помнить когда пишешь на С++, то проблем было бы гораздо меньше.

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

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

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

>Угу. А эти несколько тактов в цикле будут умножены на кол-во итераций, правда?

Ну мы щас переходим на сферического коня в ваккуме. Зависит от того какой цикл, где цикл и т.д. Что толку говорить об абстракции?

>Мы уже договорились, что кресла, сделанные на С - жутко дОроги.

;-) Отмазка прИнята.

По C++. Кстати, присутствие C, как платформообразующего языка никак не идет в разрез с программированием на C++, да и на какого-либо другом языке... Ведь именно благодаря тому, что GTK+ написан на C, мы имеем возможность написать приложение с его использованием и на C++, и на Python, Perl, и на Ruby, и Prolog... Список можно продолжать (продолжение списка биндингов можно без труда найти в интернете). А вот использовать, скажем, Qt из языков, несовместимых с C++, невозможно. Отсюда - ценность GTK+ и явные преимущества подхода. Но! Идеология написания всего и вся на C не является догмой. Эта идеология не заставляет вас писать приложения именно на C. Пожалуйста - пишите и на C++. Но при этом вы сможете использовать всю инфраструктуру "сишной" платформы из-за того, что API доступен, прост, нет никаких проблем с его использованием.

Для ясности. Glib - это библиотека для тех, кто хочет писать программы именно на Си, но в объектном стиле. Желание писать на Си у многих порождено не только привычкой и любовью к этому языку, но и желанием с большей легкостью портировать свой софт не разные архитектуры/платформы/чего пожелаете. А многим пишущим на C Glib вообще не нужен. То есть я это пишу для того, чтобы указать место Glib в общей картине бытия :)

>Ну, во-первых, я не говорил этого: "стандартизировать формат desktop-файлов - это нормально, а конфигурационных - это уже преступление".

Я имел ввиду действия freedesktop.org.

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

Смена формата - всегда проблема. Но для конф.файлов она надумана. Часто меняется формат /etc/passwd ?

>Ну а в-третьих, я всегда считал, что desktop-файлы из разряда конфигурационных.

Я их так назвал, чтобы привести в сравнении как-то. Но суть та же.

>Смена формата - всегда проблема. Но для конф.файлов она надумана. Часто меняется формат /etc/passwd ?

Так и я о том же ;-). Ведь не меняется он не потому, что всех устраивает, а потому, что его уже _нельзя_ изменить.

>Не только. Легкость сопровождения, скорость обнаружения ошибок, длительность цикла отладки - это тоже немаловажно.

Непременно! А хорошая библиотека за тобой еще и память почистит ;)

>Про Ваши приемы работы с указателями - я понял. Скажите, они гарантируют Вам отсутствие проблем с указателями?
Да. При одном условии - в системе достаточно ОЗУ.

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

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

"Во-вторых" - мне кажется более правдивым ответом.
Тогда Гному предстоит быть всегда вторым.

> Не, маркетинга там не было вообще, об этом в книге написано ;-)

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

> Я имел ввиду тот случай, когда забыли при объявлении инициализировать указатель. Ведь об этом первоначально речь шла?

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

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

>А если она будет основана на объектной модели glib?

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

> Да. При одном условии - в системе достаточно ОЗУ.

Или нагрузка в некоторых пределах, ограниченных этим самым объемом ОЗУ.

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

И он останется включенным в production системе? Или все-таки соптимизируете?

> "Во-вторых" - мне кажется более правдивым ответом.

> Тогда Гному предстоит быть всегда вторым.

М-м. Не уверен. Вот, например, тут (http://oss.mri.co.jp/floss-asia/floss_asia_en.html) гном первый 40% vs 20% (Fig. 30). Но это все беспредметный разговор и мерянье .. сами знаете чем. Да, основные разработчики гнома действительно любили и любят делать креслица. Но их крутизна в том, что они пытаются поставить кресла на поток, не превратив их в табуретки (увы, не всегда выходит:). И, что важно, они пытаются помогать другим делать табуретки - отсюда gnome bindings и этот самый дурацкий mono (ну не люблю я его, будучи жаваписцем:). Заметьте, изготовление самого mono - это ручная работа, это такое очень ажурчатое креслице (с т.зр. разработчиков mono). Но в результате получается ... станок для изготовления табуреток - такой себе безопасненький environment. Так что далеко не всегда желание одних сделать креслице непримиримо конфликтует с необходимостью других производить табуретки. Нужно просто найти точку разрешения конфликта:)

Вашими бы устами.. Боюсь, ребята из КДЕ с Вами не согласны.

>Так и я о том же ;-). Ведь не меняется он не потому, что всех устраивает, а потому, что его уже _нельзя_ изменить.

Возможно и так. Но это дело уже PAMа.

>Или нагрузка в некоторых пределах, ограниченных этим самым объемом ОЗУ.

Конечно.

>И он останется включенным в production системе? Или все-таки соптимизируете?

Останется, потому как затраты на это невелики.

>Вот, например, тут (http://oss.mri.co.jp/floss-asia/floss_asia_en.html)

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

>Заметьте, изготовление самого mono - это ручная работа, это такое очень ажурчатое креслице (с т.зр. разработчиков mono). Но в результате получается ... станок для изготовления табуреток - такой себе безопасненький environment. Так что далеко не всегда желание одних сделать креслице непримиримо конфликтует с необходимостью других производить табуретки. Нужно просто найти точку разрешения конфликта:)

Конечно. И знаете какая это точка? То что десктопов должно быть 2. Как минимум. Такова се ля ви. Потому как в будущем при их объединении все равно будут возникать коллизии. А пострадает конечный пользователь. Хотя бы тем, что теперь при запуске KDE будет загружаться еще и libglib. Это печально, но не так плохо с другой стороны. Всегда будет конкуренция.

>Вашими бы устами.. Боюсь, ребята из КДЕ с Вами не согласны.

Я ж говорю, не от них это зависит. Свяжитесь с тролями. И они четко скажут, выиграют они от libglib хотя бы на платформе Linux или проиграют. И вообще, возможно ли это (повторю, API libglib я не знаю, поэтому сам по этому поводу ничего не могу сказать.)

> Несмотря на то, что гном делает в 2 раза больше народу...

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

То, что десктопов должно быть >1 я согласен целиком и полностью. Конкуренция необходима - но нужно и сотрудничество. Я просто хочу стандартов. Хочу, чтобы не десктоп меня заставлял выбирать приложения - а я сам выбирал приложения - и они бы все работали дружно и сообща. И без freedesktop.org я не вижу осуществления этой мечты. Например, я хочу, чтобы, выбрав в наутилусе какой-то файл с именем supermuperprotocol://mightyserver/script.sql - я бы мог его сразу открыть в Tora. Мечты, мечты...

Поэтому я хочу единства базовых библиотек. Если уж мечта уважаемого DSelect о микроядерном линуксе неосуществима (поплачем над ней), то уж хотя бы сделать единый набор API для каких угодно десктопов - вполне реальная цель. А уж там пусть они соревнуются, чей интерфейс удобнее, чья концепция файлового менеджера юзабельнее и т.д. и т.п.

Может, тролли и проиграют от glib - а вот пользователи могли бы выиграть.

>Возможно и так. Но это дело уже PAMа.

Ну вот мы и пришли к согласию :)

Кола-као с молоком :)

Пеннингтон хотел, чтобы началась дискуссия. Она вот и началась :) Усилим некоторые его слова.

Начнем с .NET . Есть некий (хоть какой-то) стандарт. Ура! Взяли за основу .NET и забазировались на реализации Mono. Отлично! Пишем... Пишем... Сделали GNOME#. И тут узнаем, что Микрософт имеют кое-что дополнительно в реализации .NET, что делает софт MS и софт многих коммерческих поставщиков ПО просто неработоспособными на Mono. "И что же нам теперь делать?" - заплачут все. "Мы же хотим на Линуксе пускать купленный Office! Здесь же на коробке написано "Designed for .NET". А почему у нас не запускается?" - захнычут. А потому, что вот используют приложения эти проприетарные куски, которые не попали в стандарт и были придержаны MS "для себя". А в худшем случае, когда .NET станет безумно поплуярной, вообще MS изменит спецификацию и все свои компайлеры порихтует так, что больше нигде, кроме платформ, которые выберет сама MS, софт не пойдет?

Приведу слова одного человека из одной общеизвестной книжки. "Мы не ставили прямую цель - зарабатывать деньги на IBM, нам было выгоднее другое - лицензировать MS-DOS всем компьютерным компаниям, предлагавшим машины, более или менее совместимые с IBM PC. IBM могла свободно использовать наше программное обеспечение, но у нее не было эксклюзивной лицензии или контроля за будущими улучшениями...". Автора сами угадаете? :)

Теперь JVM. Ну и что? Сейчас Java популярна. Когда-тои Netscape был популярен, был на первом месте. Все когда-то говорили: "Если мы говорим браузер, то подарузамеваем Netscape"... Ау! Ау? Нетскейп, ты где? Как дела? Как в анекдоте: "Лягушка, тебе хреново? / Мне не хреново - мне п#$##ц". Или это не лягушка была? А, может, Жаба? :))... Так вот. Силы у MS большие. Sun уже заявила о том, что открывать Java не будет. И правильно! И правильно! Это сейчас такая замечательная дойная коровка. Зачем же ее на мясо (читай "открывать")? А вот когда припрет .NET их к стенке, то тогда либо Жаба исчезнет, либо ее откроют... Но кому она уже тогда будет нужна, когда инфраструктура .NET будет процветать?

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

Компиляторы для JVM

2 svu: Спасибо за ссылку. Да, действительно... Есть компиляторы под байт-код сановской VM. Тогда одноязыковость у JVM я снимаю.

Все правильно. Смешно только то, что каку делает какой именно то, что она от известного производителя:)

Я охотно верю, что с МС станется в нужный момент поставить подножку дотнету. У них же СТОЛЬКО денег на юристов. Вопрос в том, выживет ли жабка, если, несмотря на все слухи о смерти, сан все-таки помре. Но проверить это, увы, можно только одним способом...

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

Милейший может сравнить стандарты ANSI C ~40 страниц и стандарт 99 С++ 750 страниц. И где больше граблей ??? Что бы _нормально_ писать на С++ нужен очень не хилый опыт. И очень легко С++ проект превратить в кашу из всего насвете. Нет ничего хуже чем С++ код чайника.

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

Если _внимательно_ прочитать выше названное произведение, то там куча межстрочный извенений мёртвого страуса за то что получилось из С++. Мощь ООП и эффективность С, но противовес феноменальная сложность для крупный проектов.

> Биндинги, скажем, для GTK+ (который базируется на объектной модели, описанной в Glib) без особого труда делаются для разных языков.

В теории. На практике же если взглянуть на существующие биндинги gtk даже для таких высокоуроневых языков, как lisp, scheme и т.д. - вы увидите тот же скопированный 1-в-1 сишный API, то же полуассемберное сишное (или С++-ное :) ) низкоуровневое вышивание на несколько страниц маловразумительно-многословного кода.

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

про выбор

> Хочу, чтобы не десктоп меня заставлял выбирать приложения - а я сам выбирал приложения - и они бы все работали дружно и сообща. И без freedesktop.org я не вижу осуществления этой мечты.

А я и с freedesktop.org не вижу. :(

> Например, я хочу, чтобы, выбрав в наутилусе какой-то файл с именем supermuperprotocol://mightyserver/script.sql - я бы мог его сразу открыть в Tora.

Возвращаемся к разговору о трансляторах и OO FS ? :)

Lisp/Scheme + Gtk+

Стой! А как по-другому ты себе видишь биндинг Gtk+ для Lisp'а и его диалекта Scheme? По моему, здесь очевидно все - функция Лиспа однозначно соответсвует C-фукции API Gtk+. А если тебя не устраивают столь низкоуровневая работа с Gtk+ из Lisp, то никто тебе не запрещает (и даже, возможно, поощрят, если понравится) написать некую библиотеку функций для построения интерфейсов, которая несколько укрупняет, облагораживает взаимодействие с Gtk+. Но в основе этой твой библиотеки все-равно будет лежать непосредственные вызовы из Lisp функций Gtk+, которые будут 1-в-1 соответсвовать сишному API. Я правильно уловил твое негодование по поводу биндинга или я не так тебя понял?

> А я и с freedesktop.org не вижу:(

Закрыли глаза. Представили себе кросс-десктопный gnome-kde-vfs (НЕ ЗАВИСЯЩИЙ ОТ ТОГО, МОНОЛИТНОЕ ЯДРО ИЛИ МИКРО: специально для DSelect:). Открыли глаза. Пригорюнились.

> Возвращаемся к разговору о трансляторах и OO FS ? :)

Неет! В нас камни полетят. Я только хотел уточнить (после того, как еще раз прочел тот документ): как Вы будете реализовывать атомарный write/read без временных файлов? Типа функции

double calculateSomething( double param1, double param2, double param3 ) - если все, что у Вас есть, это файловая система.

>В теории. На практике же если взглянуть на существующие биндинги gtk даже для таких высокоуроневых языков, как lisp, scheme и т.д. - вы увидите тот же скопированный 1-в-1 сишный API, то же полуассемберное сишное (или С++-ное :) ) низкоуровневое вышивание на несколько страниц маловразумительно-многословного кода.

Ну не знаю, что с lisp, но отзывы о pyGTK и GTK# - сугубо положительные.

Ряженка с кефиром рулят.

> А еще интересны комментарии по теме "и куда же это все
> подевалось?" :)

Встречное предложение. Пойди на $(ms)/netframework/overview, посмотри тоже нехилый список существующих под dotnet компиляторов и задайся вопросом - "куда оно всё подевалось?" :)
А потом задайся вторым вопросом - "а может, оно всё нахрен не нужно?". Это конечно риторический вопрос, потому как ответ ясен.

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

Реально нужны только компиляторы тех языков, под которые написано дофига кода, который неплохо бы ещё попользовать. Поэтому под дотнет кроме c# реально есть только vb.net (реально - значит используется. Да и то бейсикописателей к сишарпу морально готовят), а под jvm реально нет ничего кроме собственно джавы. И это нормально.

> Вот именно так бы подумал школьник/студент, у которого в голове
> только Delphi

Сам-то на чём писал, орёл? ;)
Кстати на тему - у борланда ещё давным-давно был вариант дельфи под jvm. Задолго до появления дотнета. Но доведён и выпущен не был.

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

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

Кал-а-као с молоком ....

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

Ты начал употреблять наркоту, что ли? ;-)))

> Нефиг всякую каку нести в свой дом ...

Вот тут консенсус ! ;-)

Ну вот, пришел строгий Дементий и всех построил.

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

Плюсовый манглинг сюда же, к соглашениям о вызовах?:)

Ща-ща... только Диментию отвечу :) Сейчас уже поздно, я хочу спать. Могу быть неубедительным. :)

>Ты начал употреблять наркоту, что ли? ;-)))

Нет, перешел на следующий уровень - почитываю труды В. И. Ленина перед сном :)

В этом треде все намешано в кучу - и библиотека виджетов, и язык написания приложений, и языки написания инфраструктуры среды (такой как GNOME). Ну, думаю, умные люди разделят все эти вопросы.

На самом деле, статья про то, что выбрать за платформу для написания приложений и делается попытка подвергнуть сомнению существующую гномячую стройную (или пытающуюся казаться таковой) архитектуру и ее ориентированность на C. В конечном итоге же и Ximian тоже хочет делать переносимые приложения. Вот и думают - согласятся ли гномовцы ориентироваться на Mono или нет. Я надеюсь, что все-таки не согласятся. Это означает, разумеется, однозначный форк многих приложений и адаптация их под Mono (например, Evolution). Вот я и высказался на тему, что этого делать нельзя по политическим долгосрочным и стратегическим соображениям. Почему - см. выше.

Что касается интерфейсов. Дык об чем и речь, собственно. На самом деле, хочешь ты этого или не хочешь, язык написания проступает наружу. То есть твои слова о независимости от языка имплементации хороши, как теоретическая вводная. Напишешь на C++ - и инфраструктурой смогут пользоваться только приложения на C++. А также нельзя будет воспользоваться из языков, которые имеют inconsistency с ОО-подходом. Вот тебе уже пример, когда язык - немаловажная деталь. Ведь используемый язык *в общем случае* - это и есть интерфейсы, о которых ты говоришь. Кстати, Win API - тоже сишный. И это не только исторически сложившийся факт. Это также и разумный выбор.

Поэтому термин "платформообразующий язык" имеет под собой почву до тех пор, пока интерфейсы, о которых ты говоришь, описываются в терминах этого языка. Что касается обычных приложений, то, разумеется, неважно на чем они написаны. Об этом я говорил. Главное, чтобы можно было пользоваться инфраструктурой платформы. Вот пример. Есть AutoCAD, и есть там такая штука, как ARX (AutoCAD Runtime eXtension). Это типа API AutoCAD, который позволяет написать внешние прикладухи. Так вот он написан на C++. Я так мельком смотрел описание (актуально было когда-то). Иначе, чем из C++ егоне поюзаешь. Там, по-моему (могу врать!), наружу даже абстрактные классы торчат. А вот еще есть библиотека OpenCascade. Тоже написана на C++. Один из проектов в рамках OpenCascade - это попытка прикрутить к библиотеке Питон. Автор этого проетка где-то на сайте так и говорит, что вот не может он поиспользовать все возможности, ибо в Питон не совсем аналогичен C++ (я не помню точно, на что он жаловался, но легко найти). Пожалуйста тебе - интерфейсы... :)

Вдогонку

Да, уточню, что JVM/.NET я никак и нигде с интерфейсами не увязывал. Это по другой канве обсуждения шло. А вот Gtk+, Glib и интерфейсы на C - по-другой совсем. Эти темы никак не связаны. Но в деталях, как ни странно, имеют очень много точек соприкоснования...