[@] C/C++, Mono, D

рано ещё... с/с++ используются по инерции и мало поддерживается средствами разработки :(

> но почему как альтернатива (очевидно неприемлимая для большинства С/С++ программистов) выдвигается именно VM-решение

Мода

> почему сторонники C не используют Cyclone ?

Как минимум потому, что Cyclone мертв.

> почему сторонники C++ не используют D ?

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

А вообще, есть старое правило: пока выгода от перехода не превышает расходы на него на какую-то цифру (вроде 37%), перехода не происходит. ИМХО, ни Cyclone, ни D такой выгоды не предложили.

>Как минимум потому, что Cyclone мертв.

А ссылочку можно?

>А вообще, есть старое правило: пока выгода от перехода не превышает расходы на него на какую-то цифру (вроде 37%), перехода не происходит. ИМХО, ни Cyclone, ни D такой выгоды не предложили.

А C#/Java -- предлагают?

Маркетинг ???

>> Как минимум потому, что Cyclone мертв.

> А ссылочку можно?

Я читал об этом на его официальном сайте. Интересно - поищи.

>>А вообще, есть старое правило: пока выгода от перехода не превышает расходы на него на какую-то цифру (вроде 37%), перехода не происходит. ИМХО, ни Cyclone, ни D такой выгоды не предложили.

>А C#/Java -- предлагают?

Видимо, да. Учти еще, что выгоды могут быть не только техническими (софт пишется быстрее/проще/качественнее), но и маркетингвыми ("Мы используе технолгии лидеров промышленности блаблабла").

>Маркетинг ???

Он самый. И толпы индусов/негров/китайцев-быдлокодеров.

>Я читал об этом на его официальном сайте. Интересно - поищи.

Полазил на http://cyclone.thelanguage.org/ -- никаких заявлений о закрытии проекта не нашёл.

>Видимо, да. Учти еще, что выгоды могут быть не только техническими (софт пишется быстрее/проще/качественнее), но и маркетингвыми ("Мы используе технолгии лидеров промышленности блаблабла").

Увы, но согласен. как это не печально, но всем сейчас рулит маркетинг.

>Как минимум потому, что Cyclone мертв

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

>Увы, но согласен. как это не печально, но всем сейчас рулит маркетинг

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

> Полазил на http://cyclone.thelanguage.org/ -- никаких заявлений о закрытии проекта не нашёл.

А ты не "лазь", ты внимательно посмотри... на даты в блоге, на активность списка рассылки.

Почитай http://lists.cs.cornell.edu/pipermail/cyclone-l/2006-October/000776.html

> всем сейчас рулит маркетинг.

Не всем, хотя и маркетинг важен. Языки типа Java и C# предоставляют реальные технические преимущества.

>Он самый. И толпы индусов/негров/китайцев-быдлокодеров.

Индус бы написал толпы русских/негров/китайцев :-)
Чем отличается восточноевропейский кодер от кодера-индуса ?
Для западной и центральной Европы разницы нет .
Давайте без шовинизма .

>А ты не "лазь", ты внимательно посмотри... на даты в блоге, на активность списка рассылки.

>Почитай http://lists.cs.cornell.edu/pipermail/cyclone-l/2006-October/000776.html

Хм... Действительно, оригинальная команда его забросила. Но, ИМХО, это не повод считать сам язык мёртвым.

>Языки типа Java и C# предоставляют реальные технические преимущества.

Пример?

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

А с каких пор OSS и бизнес -- несовместимые понятия? Ну да ладно, будем рассматривать некоммерческие приложения.

Тогда -- ИМХО -- привычка, популярность языков... Мода. Других причин придумать пока не могу...

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

Средней квалификацией. Хотя тут вопрос скорее субъективный. Ещё отличаются количеством.

>Для западной и центральной Европы разницы нет .

Таки есть. кодеры восточной Европы подороже индусов.

>> Языки типа Java и C# предоставляют реальные технические преимущества.

> Пример?

безопасная работа с памятью, массивами и строками (как следствие - низкий порог вхождения), всеобщая стандартность ABI (как следствие - огромные библиотеки), рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов).

>А с каких пор OSS и бизнес -- несовместимые понятия?

а где я подобное утверждал ? маркетинговые решения как главный аргумент выбора средства разработки в OSS-среде - вот это бред

>Тогда -- ИМХО -- привычка, популярность языков... Мода. Других причин придумать пока не могу...

к mono тоже привычка уже выработалась ? а касательно моды - жду откровений ЛОРовцев о том, как они выбрали свой основной ЯП следуя модным тенденциям

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

Есть в любом скриптовом языке. А уж сколько либ для перла....

> рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов).

Она не всегда нужна.

Кстати, где куча удобных жава-приложений в Linux? Почему с низким порогом вхождения нет кучи программ? Почему большинство софта написано на сложных с/с++, а не на простой java?

> а касательно моды - жду откровений ЛОРовцев о том, как они выбрали свой основной ЯП следуя модным тенденциям

Думаете таких нет? По-моему, c++/qt -- это вполне модно.

>безопасная работа с памятью, массивами и строками (как следствие - низкий порог вхождения)

Как раз в случае с D и Cyclon она и является вполне безопасной, но при этом не порождает программистов, для которых "память? Ачойта?"

>всеобщая стандартность ABI (как следствие - огромные библиотеки)

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

>рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов)

...и расплата в виде виртуальной машины со всеми вытекающими. Да и (ИМХО) для метапрограммирования есть совсем другие языки, и тут ни Cyclon, ни D, ни C# с жабой не являются идеалом. И близко не стоят.

>маркетинговые решения как главный аргумент выбора средства разработки в OSS-среде - вот это бред

В случает non-comercial OSS -- да, бред, согласен.

>к mono тоже привычка уже выработалась ?

К моно скорее мода. Ну и привычка к .NET у "вновьприбывших" с оффтопичной платформы.

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

> Есть в любом скриптовом языке

Ты внимательно прочитал OP? Где там про скриптовые языки? Там исключительно статически типизированные.

> А уж сколько либ для перла....

Много. Но для Явы - больше.

>> рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов).

>Она не всегда нужна.

Уфф. Я сказал. что она нужна _всегда_? Но там, где она нужна, там без нее очень сложно.

> Кстати, где куча удобных жава-приложений в Linux?

Как среда написания настольных приложения Ява провалилась из-за прожорливости, ты это хотел услышать?

> Почему с низким порогом вхождения нет кучи программ?

Они есть. Просто они не на твоем десктопе.

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

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

> выдвигается именно VM-решение, будь то Java или Mono ?

vm решения выгодны корссплаформенностью или потенциальной кроссплатформенностью.

> почему сторонники C не используют Cyclone ?

а зачем он нужен? cyclone - не нужный костыль.

> почему сторонники C++ не используют D ?

D чертовски хороч, но сыроват.

> почему эти ЯП, имеющие практически полный набор преимуществ своих предшественников, и избавляющие программиста от многих и многих недостатков С/C++, имеют под Linux аудиторию куда меньшую, чем у того же C# ?

1) бред вы несёте. каждый удачно спроектированный язык выгодно применять в некоторой сфере или нескольких связанных сферах деятельности. разрабатывать high-level приложения на сях будет только ксеноцефал, как и писать драйвера на d.

2) см. выше: cyclone - костыль, d пока что сырой.

> Как раз в случае с D и Cyclon она и является вполне безопасной, но при этом не порождает программистов, для которых "память? Ачойта?"

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

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

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

для ынтырпрайз решений более чем приемлемо.

> Как раз в случае с D и Cyclon она и является вполне безопасной, но при этом не порождает программистов, для которых "память? Ачойта?"

Язык называется Cyclone, и на нем не написано ни одного серьезного приложения, тоже самое - и на D. Так что про "порожденых" ими программистов ты ничего не знаешь, потому что их нет. А вот единственная прога на Хаскеле, которую я знаю, временами отличается такими аппетитами к памяти, что Ява нервно курит.

>>всеобщая стандартность ABI (как следствие - огромные библиотеки)

>Это и плюс и минус -- далеко не всегда нужно всё-в-одном-флаконе.

А тебя прямо таки заставляют вкрячить все существующие в мире библиотеки в свою систему?

>> рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов)

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

VM и рефлексия совершенно ортогональны.

> Да и (ИМХО) для метапрограммирования есть совсем другие языки, и тут ни Cyclon, ни D, ни C# с жабой не являются идеалом.

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

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

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

>если не пихать c унд c++ во все дыры, то и "существенный ряд недостатков" отпадёт

http://www.digitalmars.com/d/comparison.html - в качестве примера того, о чём я говорю. тут сравнение не "дригих", а просто "лучших" подходов, причём сравнение ведётся как с C++03, так и с C++0x. никакого отношения к области применения эти моменты не имеют

>vm решения выгодны корссплаформенностью или потенциальной кроссплатформенностью

любой интерпретируемый язык даст тот же эффект

>а зачем он нужен? cyclone - не нужный костыль

http://cyclone.thelanguage.org/wiki/Why%20Cyclone - тут и коротко и понятно. касательно ненужный костыль - обоснуйте

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

хорошо. какова сфера применения С ? С++ ? и по каким критериям считается удачность проектирования ? бенчмарки - в студию

>2) см. выше: cyclone - костыль, d пока что сырой

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

>для ынтырпрайз решений более чем приемлемо.

В оригинальном треде упоминались non-comercial OSS-проекты, при чем тут ынтерпрайз?...

> D выпущен в релизе

релиз 1.0 обычно за релиз не считается :D

> сейчас в разработке вторая версия спецификации языка

...несовместимая с первой

> В оригинальном треде упоминались non-comercial OSS-проекты

В постинге, с которого всё началось, не было ни слова про OSS и non-commercial

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

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

1. Как раз сырой. вот уже вторая верся выпускается =) Он ещё не сформировался. Вообще рулит не столько ЯП сколько _инфраструктура_. И это верно не только для ЯП, а также для ОС и прочего. У D щас вообще платформы нет. Библиеотек - кот наплакал. можно даже не считать. Разработчиков в этой области почти нет. Что очень важно - у него нет реально мощной IDE хоть как то сравнимой с IDE для java. А оно и понятно - язык то на самом деле сильно сложный, по совести говоря - не особенно проще С++... Так что плюсов при переходе не много... А минусов - куча. Либо уж действительно патчить С++ и получать С#, либо оставть java... А вот этих градаций между...

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

>> Есть в любом скриптовом языке

> Ты внимательно прочитал OP?

Что прочитал? Не разобрал аббревиатуру.

> Где там про скриптовые языки? Там исключительно статически типизированные.

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

>> А уж сколько либ для перла....

> Много. Но для Явы - больше.

Половина из которых - биндинги к сишным(xerces-java, qt jambi...).

>>> рефлексия (как следствие - широкое распространение метапрограммных инструментов типа ORM'ов).

>>Она не всегда нужна.

> Уфф. Я сказал. что она нужна _всегда_? Но там, где она нужна, там без нее очень сложно.

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

>> Кстати, где куча удобных жава-приложений в Linux?

> Как среда написания настольных приложения Ява провалилась из-за прожорливости, ты это хотел услышать?

Да. И кстати, почему только настольных? Неинтерактивные утилиты из неё тоже плохо делаются.

>> Почему с низким порогом вхождения нет кучи программ?

> Они есть. Просто они не на твоем десктопе.

Есть. На sunfire-ах с гигами оперативы и базами в оракле. По одной на сервак. И где тут рулит низкий порог вхождения?

>> выдвигается именно VM-решение, будь то Java или Mono ?

> vm решения выгодны корссплаформенностью или потенциальной кроссплатформенностью.

Кому нужна _потенциальная_ кроссплатформенность, если проект надо сдать через полгода?

> Что очень важно - у него нет реально мощной IDE хоть как то сравнимой с IDE для java.

Самая мощная IDE - это vim. Многофункциональные IDE для жабы нужны для того, чтобф прикрыть собой убогость языка. Да-да, менюшки "generate getters and setters" -- это от убогости.

> Либо уж действительно патчить С++ и получать С#, либо оставть java...

C# -- это не патченый C++. Не читайте микрософтской макулатуры.

>> Ты внимательно прочитал OP?

> Что прочитал? Не разобрал аббревиатуру.

Original Poster. Топикстартер.

>>> А уж сколько либ для перла....

>> Много. Но для Явы - больше.

> Половина из которых - биндинги к сишным

4.2 в особо циничной форме.

> (xerces-java, qt jambi...)

Еще что-нибудь? А то вот у меня в JDK6 десятки мегабайты jar-ов, а "родного" кода - кот наплакал. То же и с Eclipse, NetBeans...

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

Ээээ... не понял. Рефлексия нужна для, например, ORM. Использование Java для ORM - не оправдано? o_O

>> Как среда написания настольных приложения Ява провалилась из-за прожорливости, ты это хотел услышать?

>Да.

Ну вот, услышал :D

>>> Почему с низким порогом вхождения нет кучи программ?

>> Они есть. Просто они не на твоем десктопе.

> Есть. На sunfire-ах с гигами оперативы и базами в оракле. По одной на сервак. И где тут рулит низкий порог вхождения?

Там, где их пишут не очень грамотные индусы.

> Еще что-нибудь? А то вот у меня в JDK6 десятки мегабайты jar-ов, а "родного" кода - кот наплакал. То же и с Eclipse, NetBeans...

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

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

> Ээээ... не понял. Рефлексия нужна для, например, ORM. Использование Java для ORM - не оправдано? o_O

ORM -- единственное место для применения рефлексии? Вот мне скорее на ум "редактор свойств" приходит.

Да даже и с ORM: использование жабы там оправдано потому что база тормозит сильнее жабы, чьё влияние на скорость незаметно. Потому, как говорят физики, этим влиянием можно пренебречь.

>> Есть. На sunfire-ах с гигами оперативы и базами в оракле. По одной на сервак. И где тут рулит низкий порог вхождения?

> Там, где их пишут не очень грамотные индусы.

В итоге получаем не сегфолт или утечки памяти а ошибки в логике. Зато писать легко :)

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

Ну что же, попробуйте объяснить алгоритм "близнецов", используя Java, и поймёте, что ошибаетесь.

> ошибки в логике.

Добавка: и ещё алгоритмы, работающие за O(n!) :)

>> Еще что-нибудь? А то вот у меня в JDK6 десятки мегабайты jar-ов, а "родного" кода - кот наплакал. То же и с Eclipse, NetBeans...

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

Ни о чем подобном они не говорят.

> ORM -- единственное место для применения рефлексии?

Нет.

> Вот мне скорее на ум "редактор свойств" приходит.

Тоже применение. Что плохого в "редакторах свойств"?

> В итоге получаем не сегфолт или утечки памяти а ошибки в логике. Зато писать легко :)

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

> С++ позиционируется как универсальный ЯП, таким образом и используется.

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

> http://www.digitalmars.com/d/comparison.html - в качестве примера того, о чём я говорю. тут сравнение не "дригих", а просто "лучших" подходов, причём сравнение ведётся как с C++03, так и с C++0x. никакого отношения к области применения эти моменты не имеют

как же это не имеют? именно функциональность языка позволяет занять ему сво[ю|и] ниш[у|и].

> любой интерпретируемый язык даст тот же эффект

в принципе да, но по скорости будет отставать, хотя это и не существенно.

> касательно ненужный костыль - обоснуйте

from http://cyclone.thelanguage.org/wiki/Why%20Cyclone

1) "C is unsafe"
а что вы ещё хотели от кроссплатформенного ассемблера?

2) "Cyclone thus tries to fill an empty niche: the safe language that with C’s level of control and efficiency."
разве это повод использовать cyclone? а про си код чекеры вам ничего не известно? http://www.google.ru/search?hl=en&q=c+code+checker&lr=lang_en%7Clang_...

3) основная ниша си - embedded, драйвера и программы в которых скорость играет наиболее важную роль, например кодеки. далее, cyclone != c. это значит, что он будет ограничивать кучу мегаполезных в данных сферах сишных фичей:
* NULL checks are inserted to prevent segmentation faults
* Pointer arithmetic is restricted
* Pointers must be initialized before use
* Dangling pointers are prevented through region analysis and limitations on free()
* Only "safe" casts and unions are allowed
* goto into scopes is disallowed
* switch labels in different scopes are disallowed
* Pointer-returning functions must execute return
* setjmp and longjmp are not supported

In order to maintain the tool set that C programmers are used to, Cyclone provides the following extensions:

* Never-NULL pointers do not require NULL checks
* "Fat" pointers support pointer arithmetic with run-time bounds checking
* Growable regions support a form of safe manual memory management
* Garbage collection for heap-allocated values
* Tagged unions support type-varying arguments
* Injections help automate the use of tagged unions for programmers
* Polymorphism replaces some uses of void *
* varargs are implemented as fat pointers
* Exceptions replace some uses of setjmp and longjmp
http://en.wikipedia.org/wiki/Cyclone_programming_language

более того, он не всегда совместим с сями. т.о. не каждая сишная либа может быть заюзана без правки. ещё аргументы? поскольку си применяется в embedded, подразумевается, что си-компилятор заимплеменчен под мн-во архитектур: http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures. а что циклоп? а циклоп отсасывает.

> хорошо. какова сфера применения С ?

см. выше

> С++ ?

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

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

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

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

ok, отлично. дайте мне xml парсер на d, хочу библиотеку для работы с матрицами, дайте мне x, дайте мне y.... это я к тому, что библиотек покамест мало. а зачастую именно наличаем той или иной библиотеки определяется выбор инструмента.

>>> Еще что-нибудь? А то вот у меня в JDK6 десятки мегабайты jar-ов, а "родного" кода - кот наплакал. То же и с Eclipse, NetBeans...

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

> Ни о чем подобном они не говорят.

Как мне легко и красиво использовать библиотеку на жаве в проекте на c++? Или как мне прикрутить код на жаве к гуйку на tcl? Вот с c/c++/fp я могу это сделать.

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

>> Вот мне скорее на ум "редактор свойств" приходит.

> Тоже применение. Что плохого в "редакторах свойств"?

Всё с ним хорошо. Но зачем для него жава!?

>> В итоге получаем не сегфолт или утечки памяти а ошибки в логике. Зато писать легко :)

> Не "вместо" - ошибки в логике были бы и в Си/Си++.

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

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

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

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

Если б... Обычно указание типа "пишем на j2ee и нии пёт" идёт свыше.

> ok, отлично. дайте мне xml парсер на d,

libxml2.

> хочу библиотеку для работы с матрицами

atlas

D совместим со всеми c-шными либами. Хотя и использовать их придётся в сишном виде а не в родном для языка.

> Как мне легко и красиво использовать библиотеку на жаве в проекте на c++?

Легко и красиво - никак. Ну а вообще - ты сам приводил примеры враперов.

> Вот с c/c++/fp я могу это сделать.

С++ и Tcl - легко и красиво, я правильно понял? Создавать классы, наследовать Си++-классы - это всё можно, причем легко?

>> Тоже применение. Что плохого в "редакторах свойств"?

>Всё с ним хорошо. Но зачем для него жава!?

Уфф... не Ява для редактора свойств, а редактор свойств для Явы. Скажи мне, как написать такой же "редактор свойств" для Си++?

>> Не "вместо" - ошибки в логике были бы и в Си/Си++.

> Там требуется несколько большая культура программирования, которая обычно коррелирует с квалификацией.

Довольно смелое заявление :D То, что прогер освоил Си++, не означает, что он не делает логических ошибок. В любом случае, такой компромисс был сочтен приемлемым.

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

Ха, это проблемы Явы? Это проблемы криворуких прогеров.

P.S. мне не особо нравится Ява, мне совсем не нравится ее реализация в виде байткодной VM, но у Явы масса достоинств для ее области применения.

>Самая мощная IDE - это vim. Многофункциональные IDE для жабы нужны >для того, чтобф прикрыть собой убогость языка. Да-да, менюшки >"generate getters and setters" -- это от убогости.

1. Ничего лучще пока не придумали. И не надо мне про проперти расказывать. Это раз. Во вторых. Ты видимо из за своих идеологий давно, лет эта 8 не следишь за развитием ИДЕ. поверь, generate setter and getters - это процент от использования. Или может скажешь что autocomplit, extract method, extract superclass, extract interface, удобная навигация, _инкрементальная компиляция_ всё это так, хрень?

>C# -- это не патченый C++. Не читайте микрософтской макулатуры.

Не читаю. Я про то, что это в каком то смысле натянаутый C++ синтаксис на джаву. Ну может выраился не правильно =)

> libxml2.

На сколько я понял она Сшная и привязок к D не имеет. Да, мы в курсе что в D можно использовать сишный код. Но было интересно именно Dшные библиеотеки. Иначе преимущества не очевидны

>> Как мне легко и красиво использовать библиотеку на жаве в проекте на c++?

> Легко и красиво - никак. Ну а вообще - ты сам приводил примеры враперов.

Я приводил пример врапперов C -> java. Про врапперы Java -> C я не говорил ничего.

>> Вот с c/c++/fp я могу это сделать.

> С++ и Tcl - легко и красиво, я правильно понял? Создавать классы, наследовать Си++-классы - это всё можно, причем легко?

C с++ я могу использовать его C-подмножество и делать интеграфию с tcl. Хотя да, интеграции [incr]Tcl или XOTcl и C++ нету :) Если б была - то это был бы уродский дотнет.

>>> Тоже применение. Что плохого в "редакторах свойств"?

>> Всё с ним хорошо. Но зачем для него жава!?

> Уфф... не Ява для редактора свойств, а редактор свойств для Явы.

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

> Скажи мне, как написать такой же "редактор свойств" для Си++?

Никак. В C++ рефлексии "искаропки" нет. Зато на том же tcl - влёгкую.

> То, что прогер освоил Си++, не означает, что он не делает логических ошибок.

Не означает. Но вероятность этого выше.

> В любом случае, такой компромисс был сочтен приемлемым.

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

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

> Ха, это проблемы Явы? Это проблемы криворуких прогеров.

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

> P.S. мне не особо нравится Ява, мне совсем не нравится ее реализация в виде байткодной VM, но у Явы масса достоинств для ее области применения.

И мне тоже. И я всегда задаю себе вопрос "а чем жава лучше tcl?" и не нахожу ответа. А связываться ради тех же возможностей с java-каками мне неохота.

> D совместим со всеми c-шными либами. Хотя и использовать их придётся в сишном виде а не в родном для языка.

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

> Самая мощная IDE - это vim. Многофункциональные IDE для жабы нужны >для того, чтобф прикрыть собой убогость языка. Да-да, менюшки >"generate getters and setters" -- это от убогости.

> 1. Ничего лучще пока не придумали. И не надо мне про проперти расказывать. Это раз. Во вторых. Ты видимо из за своих идеологий давно, лет эта 8 не следишь за развитием ИДЕ. поверь, generate setter and getters - это процент от использования.

Ну да, рефакторинг... В coding style Вашей фирмы не написано, что при фиксах не надо лезть в те строки, которые не изменялись?

> Или может скажешь что autocomplit, extract method, extract superclass, extract interface, удобная навигация,

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

Мсье так часто меняет структуру наследования во время работы над проектом? ССЗБ, ибо Rational Rose да и просто бумажку никто не отменял :)

> _инкрементальная компиляция_ всё это так, хрень?

Это не преимущество IDE. Это относится к компилятору. Уже прошло время когда компилятор был встроен в "синее окошко".

>> D совместим со всеми c-шными либами. Хотя и использовать их придётся в сишном виде а не в родном для языка.

> а теперь вопрос: если я пишу на объектно-ориентированном языке d в ооп парадигме, насколько "комфортно" мне будет использовать сишные либы?

Некомфортно, с чем я и не спорю.

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

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

> Хотя да, интеграции [incr]Tcl или XOTcl и C++ нету :)

О чем и речь.

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

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

>Ну да, рефакторинг... В coding style Вашей фирмы не написано, что >при фиксах не надо лезть в те строки, которые не изменялись?

Не понял вопроса. мосье не рефакторит?

>Мсье так часто меняет структуру наследования во время работы над >проектом? ССЗБ, ибо Rational Rose да и просто бумажку никто не >отменял :)

Мосье не слышал про XP? Итеративне процессы? TTD =) ? Расскажи всем, что рефакторинги не нужны.

Кстати, autocomplititon мне - удобен, например мне UOE<CtrlSpace> быстрее чем UnsupportedOperatorionException =) и это только малу часть всех удобств иде уровня Eclipse/JDT. Ты просто не в курсе =)

Инекрементальная компиляция без ИДЕ не имеет смысла.