Re[5]: C++0X vs D programming lang - Философия программирования

Здравствуйте, kaa.python, Вы писали:

KP>Здравствуйте, alexeiz, Вы писали:

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

KP>А что в плохого в простых указателях на функции?

Эээ, с чего изволите начать?
* состояние в указатель на функцию не положишь, нужно передавать отдельно.
* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.
* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.
* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.
* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.

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

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

В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Здравствуйте, alexeiz, Вы писали:

A>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."

Здравствуйте, Mr.Cat, Вы писали:

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

Именно что трудозатраты и именно что на кодинг.
Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше.
А насколько сложнее станет тестирование? А саппорт?

Здравствуйте, Mr.Cat, Вы писали:

А>>А может на JavaScript будем драйверы писать?
MC>На C# когда на сингулярити пересядем. ;)

Ну и пересаживайтесь, а наше всё — это Hurd.

Здравствуйте, alexeiz, Вы писали:

E>>Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.
A>К сожалению, потому что код писать с применением высокоуровневых возможностей языка проще. Но эти возможности большинство не знает.
Ну мой опыт показывает мне, что чем более высокоуровневыми конструкциями С++ пользуются разработчики, тем легче его написать WriteOnly. В результате либо падает качество разработки (те же спецы + продвинутые конструкции), либо растёт её цена (продвинутые конструкции + более крутые, и следовательно дорогие разработчики)
Фишка в том, что некоторые задачи проще решать при помощи функторов, но таких задач не много, и это не повод усложнять и, следовательно, удорожать весь остальной код.
A>Поэтому если ты в команде, где никто не знает что такое функтор (забудьте о boost::function), и любое применение функтора их в шок бросает, то приходится использовать тупые указатели на функции. А это гемор, не говоря уже о том, что просто тошнить начинает от такого подхода.
IMHO, в функторах нет ничего особенно крутого, но и в указателях на функции нет ничего плохого. Наоборот, при использовании указателей на функции и интерфейсов уменьшается количество шаблонного кода, например...

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.
Ну создавай свой бизнес и вперёд...

Только ты быстро очень столкнёшься с экономической неэффективностью подобных, отрентированных на "красоту кода" решений...

Здравствуйте, kaa.python, Вы писали:

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

А разве в MS используют особо продвинутые инструменты?

Здравствуйте, alexeiz, Вы писали:

A>* состояние в указатель на функцию не положишь, нужно передавать отдельно.
Если требуется состояние, то, иногда, хватает и интерфейса. Кроме того, можно и функтор использовать, но только если не слишком много шаблонного кода прийдётся породить из-за этого
В конце концов, если рассматривать два решения -- через интерфейсы и через функторы, передающиеся в шаблонный алгоритм, то второе -- это всего лишь оптимизация первого. Ну а нужна ли в каком-то конкретном месте оптимизация -- вопрос отдельный...

A>* состояние передается обычно как void*, нужно приводить к нужному типу с помощью unsafe C-style cast-а, type-safety никакая.
Юзай интерфейсы. Интерфейсы в твоей компании использовать ведь не запрещено? void* обычно используют в чисто С'шном API. Вдруг теми же сервисами не только из C++ пользуются?

A>* если у объекта состояния еще есть деструктор, который надо вызвать, когда ... а когда, кстати? — это еще прийдется выяснить для каждого конкретного случая. С boost::function все элементарно.
1) IMHO, нетривильный деструктор функтора -- не очень хорошо.
2) Вариант с интерфейсами просто и понятно решает проблемы с владением. Например объект, реализующий интерфейс может быть автоматическим в месите вызова
3) Я бы не стал, в случае деструктора функтора, делающего что-то нетривильное (например закрывающего файл), звать его как-то неявно. Типа код вида //// Evaluation.h

struct IEvaluator {
    virtual int GetEvaluation( /* params */ ) const  = 0;
};
extern int UseEvaluator( const IEvaluator* );
// Мой файл
class ByFileEvaluator : public IEvaluator {
    //        тут реализация
} 
void foo()
{
    ByFileEvaluator evaluator( "data.file" );
    UseEvaluator( &evaluator );   
}

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

A>* параметры функции должны совпадать с параметрами, указанными в типе указателя на функцию. В boost::function могут производится конвертация параметров.
Опять же, не ясно зачем это так надо.

A>* по удобству использования указатели на функцию явно проигрывают boost::function, благодаря тому, что function — это гораздо более высокоуровневая конструкция, чем тупой указатель на фукцию.
Зато по удобству отладки/поддержки лучше средства традиционные...
Ну тупо в отладчике хорошо вижно, лог проще впихнуть, компиляция быстрее и т. д

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

A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

Почему, как без шаблонов, так сразу не С++?

Здравствуйте, alexeiz, Вы писали:

A>>Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

A>Добавлю: а потом еще и жалуются — "C++ такой низкоуровневый язык, такой низкоуровневый! У него столько проблем. Вы только посмотрите, какие в нем тупые указатели на функции! Пора на новый язык переходить."

Все оно конечно так, да не так. Поддержка абстракций на уровне библиотек (ala boost) и на уровне языка — это две большие разницы.
И именно поэтому "пора на новый язык переходить".

Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Mr.Cat, Вы писали:

А>>>А может на JavaScript будем драйверы писать?
MC>>На C# когда на сингулярити пересядем.

RO>Ну и пересаживайтесь, а наше всё — это Hurd.

Вот именно что "все". В смысле "все, приплыли". А мы вот пересядем, и дальше поплывем :-Р

Здравствуйте, <Аноним>, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?

Ну если говорить о мейнстриме в unmanaged мире, то, безусловно, первый. Поддержка его элементов уже скоро будет в том же VS 2010, а вот для D есть только пара компиляторов и оба в неособо стабильном состоянии.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Erop, Вы писали:

E>А разве в MS используют особо продвинутые инструменты?

Используют. МС большой.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, alexeiz, Вы писали:

A>В результате получаем, что с boost::function код упрощается до невозможности. Ан нет! Мы хотим указатели на функции и все тут! Уберите эти шаблоны! Не хотим ничего нового учить, никаких новых концепций нам не надо. Cи наше все!

На D подобный код еще больше упрощается, вот только все равно он будет написан на C++

Здравствуйте, AndrewVK, Вы писали:

E>>А разве в MS используют особо продвинутые инструменты?
AVK>Используют. МС большой.
Ну в смысле, что "матан большой, что-нибудь да не знает", понятно...
Но масоово разве используют?

Здравствуйте, Didro, Вы писали:

D>Если язык А поддерживает абстракцию F как "first class citizens" ("как родную" другими словами), а язык B сам по себе не поддерживает F — а только через библиотеки, то при прочих равных работать с F будет удобнее в А.

IMHO, это отличие искусственное. Что там из библиотеки, а что из самого языка -- вопрос крайне мутный, кроме того, например, то, насколько ту или иную фичу поддерживают IDE, часто важнее, чем что там язык, а что нет.

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

Здравствуйте, alexeiz, Вы писали:

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

Советую обратить внимание на автора этого сообщения

Здравствуйте, kaa.python, Вы писали:

KP>Viva проект в срок, с использованием тех ресурсов, которые на данный момент доступны.
С этим никто и не спорит. Меня удручает другое — когда этим "довольно слабым разработчикам" не (дают/разрешают/предоставляют возможность) повышать квалификацию, в результате общий уровень команды так и остаётся на уровне "Си начала 90х" или "Си плюс проект". Понятно, что есть ещё и самообразование, но и компания ведь должна быть заинтересована в повышении квалификации работников. Оффтоп, но наболело

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Didro, Вы писали:

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

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

но мне кажется, мы говорили про C++.

Здравствуйте, byleas, Вы писали:

B>С этим никто и не спорит. Меня удручает другое — когда этим "довольно слабым разработчикам" не (дают/разрешают/предоставляют возможность) повышать квалификацию, в результате общий уровень команды так и остаётся на уровне "Си начала 90х" или "Си плюс проект". Понятно, что есть ещё и самообразование, но и компания ведь должна быть заинтересована в повышении квалификации работников. Оффтоп, но наболело

Если кратко, то поинт состоит в том, чтобы совершенствоваться не в овладениями шаблонами С++, а в овладении искусством писать хорошие программы...

Здравствуйте, kaa.python, Вы писали:

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

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

... << RSDN@Home 1 alpha 3 rev. 0>>

Здравствуйте, Didro, Вы писали:

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

Здравствуйте, Ocelot, Вы писали:

MC>>Тем не менее, иногда более сложные инструменты (после их изучения, конечно) позволяют сократить трудозатраты на кодинг. Не согласны?
O>Именно что трудозатраты и именно что на кодинг.
Как будто средства языка и библиотек могут сократить трудозатраты на что-то еще.

O>Более опытному специалисту, освоившему более сложные инструменты и способному все сделать быстрее, придется заплатить больше ... А саппорт?
А вот тут уже надо думать, кто будет писать код, кто будет править в нем баги и т.п.

Например, вот c-smile, в одиночку ну или в небольшой команде (возможно, я ошибаюсь, но пример показательный) делает свой htmlayout и, по его словам, там используется "хардкорный" (как-то так он сам выражался) C++. Вполне логично, т.к. ему самому такой стиль только пользу приносит, а всяким индусам лазить в код ни к чему.

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

O>А насколько сложнее станет тестирование?
А почему тестирование должно стать сложнее?

Здравствуйте, Erop, Вы писали:

E>Но масоово разве используют?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Аноним, Вы писали:

А>Просто интересно мнение что будет следующим мэйн-стримом: C++0X или язык D?

Если коротко...
C++ уже не будет мэйнстримом. D еще не будет мэйнстримом.

Здравствуйте, kaa.python, Вы писали:

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

Да все верно говоришь, код должен быть настолько простым насколько это возможно, но не проще

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

Здравствуйте, alexeiz, Вы писали:

A>Была бы моя воля, всех бы уволил и набрал людей, кто хоть немного современный C++ знает.

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

Здравствуйте, Roman Odaisky, Вы писали:

RO>Мэйнстримом будут Java, .NET, Python и т. п.

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

Здравствуйте, Pzz, Вы писали:

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

За что, боярин?!

Здравствуйте, Pzz, Вы писали:

Pzz>Чтобы стать мейнстримом, Питону очень не хватает возможности кросс-платформенно создавать нормальные standalone программы.

NET'у этого же самого тоже тогда не хватает
А у питона такая возможность есть, даже из коробки.

Здравствуйте, Mr.Cat, Вы писали:

MC>Блин, написал и ужаснулся. Даже форумы вместо лиспа уже nemerle троллят. Куда мир катится?..

А что, лисперы много троллили по форумам?

Здравствуйте, MasterZiv, Вы писали:

>> Не размахивай красной тряпкой. Сейчас как понабежит стадо розовых слонов!
MZ>уже позно. Как почётный розовый слон официально заявлаю:
MZ>следующим мейнстримом будет CommonLisp.

Ужас. Нет уж, пускай мейнстрим наперегонки барахтается в своих самонаилучших языках по маковкиного заговения. Зато весело: каждый год — революция. Лепота и ништяк!

Здравствуйте, Mr.Cat, Вы писали:

MC>Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара.

В мейнстриме 80х под названием xBase

. А вот называть ли это сахаром.

Здравствуйте, FR, Вы писали:

FR>NET'у этого же самого тоже тогда не хватает

У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

FR>А у питона такая возможность есть, даже из коробки.

А вы этой возможностью пользоваться пробовали, или вы теоретик?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, kaa.python, Вы писали:

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

E>А разве в MS используют особо продвинутые инструменты?

В майкрософте не используют не только особо продвинутые инструменты, но и сколько-либо мало-мальски продвинутые инструменты. В таких крупных группах как Windows, DevDiv, Windows Mobile (это те, о которых мне известно не понаслышке) C++ используется на уровне C with classes. Office, Search, Exchange — то же самое. SQL — не знаю, но буду сильно удивлен, если там что-то по другому. Где-то что-то слышали о RAII. Исключения используют еще меньше. Коды возврата повсеместно. Свою собственную реализацию STL, поставляемую с VC++ нигде не используют. Пишут свои велосипеды, кривые, без исключений. Может доходить до смешного: серьезный проект, делающий важные и сложные вещи, в котором нет даже и намека на библиотеку контейнеров (внутреннюю или внешнюю к проекту). О бусте и речи не идет (и не удивительно, для начала неплохо было бы STL задействовать). Хотя вру. Слышал, что буст использовали один раз где-то в VS setup-е и еще где-то по мелочам. Under the radar, так сказать. Но буст проблематичен, у него open sauce лицензия. А вот TR1 свой собственный есть — бери не хочу. Не берут.

Здравствуйте, Трурль, Вы писали:
Т>А вот называть ли это сахаром.

Ну, ну я не имею в виду, что это синтаксический сахар. Просто удобная, но не особо важная фича.

Здравствуйте, Pzz, Вы писали:
Pzz>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.
Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

Pzz>А вы этой возможностью пользоваться пробовали, или вы теоретик?
А что конкретно у питона Вас не устраивает? То, что под виндой надо отдельно ставить питоновский рантайм и все дополнительные библиотеки (тогда как под линухом питон как правило притягивается по зависимости с DE, а все дополнительные вещи как правило лежат в репозитории)? Или что-то другое?

Здравствуйте, Mr.Cat, Вы писали:

Pzz>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.
MC>Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

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

Pzz>>А вы этой возможностью пользоваться пробовали, или вы теоретик?
MC>А что конкретно у питона Вас не устраивает? То, что под виндой надо отдельно ставить питоновский рантайм и все дополнительные библиотеки (тогда как под линухом питон как правило притягивается по зависимости с DE, а все дополнительные вещи как правило лежат в репозитории)? Или что-то другое?

У меня есть простая задача: мне надо дистрибутировать программу в собранном виде простым нормальным пользователям. Чтобы скачал-поставил-работает.

Можно по пунктам, как вы предлагаете эту задачу решать?

Здравствуйте, alexeiz, Вы писали:

A>C++ используется на уровне C with classes.
Ну еще чуть чуть темплейтами припорошить и будет как раз самое распространенное использование С++

A>Исключения используют еще меньше. Коды возврата повсеместно. Свою собственную реализацию STL, поставляемую с VC++ нигде не используют.
И в общем то правильно делают, если подумать.

A> Пишут свои велосипеды, кривые, без исключений.
Что кривые — плохо. Что без исключений — это как еще посмотреть...

A>А вот TR1 свой собственный есть — бери не хочу. Не берут.
Видимо тоже есть основания.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pzz, Вы писали:
Pzz>У меня есть простая задача: мне надо дистрибутировать программу в собранном виде простым нормальным пользователям. Чтобы скачал-поставил-работает.
Pzz>Можно по пунктам, как вы предлагаете эту задачу решать?

Под виндой:
1. Тащим рантайм с собой и юзаем его для запуска программы (а-ля komodo).
или
2. Берем msi-дистрибутив питона с python.org и включаем в инсталляционный пакет. Во время инсталляции проверяем, есть ли на компе питон нужной версии и, если нет, ставим.

Под линухом:
Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.

Здравствуйте, Mr.Cat, Вы писали:

MC>Ну, ну я не имею в виду, что это синтаксический сахар. Просто удобная, но не особо важная фича.

А я имею в виду, что это совсем не сахар. Скорее, крысиный яд.

Здравствуйте, Трурль, Вы писали:
Т>А я имею в виду, что это совсем не сахар. Скорее, крысиный яд.

Ну... никто ж не заставляет это использовать. Не нравится — не надо. Всего лишь еще один способ работы с глобальными мутабельными данными.

Здравствуйте, VladD2, Вы писали:

VD>Если коротко...
VD>C++ уже не будет мэйнстримом. D еще не будет мэйнстримом.

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

Ди не обсуждается вовсе. С++ обсуждается только вскользь. Зато, как всегда обсуждаются Nemerle, Python и даже VladD2. Хотя козалось бы причем тут VladD2?

Здравствуйте, VladD2, Вы писали:

VD>C++ уже не будет мэйнстримом.
да он и сейчас, вроде как не мэйнстрим.

VD>D еще не будет мэйнстримом.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Mr.Cat, Вы писали:

MC>Под виндой:
MC>1. Тащим рантайм с собой и юзаем его для запуска программы (а-ля komodo).
MC>или
MC>2. Берем msi-дистрибутив питона с python.org и включаем в инсталляционный пакет. Во время инсталляции проверяем, есть ли на компе питон нужной версии и, если нет, ставим.

Под вендой как раз относительно просто. Там есть py2exe, он работает.

Идея с msi-дистрибутивом мне не кажется очень уж удачной: нет никаких гарантий, что никто не сломает мне мою питонию программу, поставив какой-нибудь 2.6 (не говоря уж о 3.0) поверх того 2.5, который я приволок с собой.

MC>Под линухом:
MC>Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.

Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.

Я не говорю уж о том, что немного потрахавшись, на C/C++ я соберу все же программу так, что единый бинарник будет работать на всех интересных мне платформах. И мне останется его только распаковать по-разному. А с Питоном действительно похоже что придется держать десяток дистрибутивов.

Здравствуйте, Геннадий Васильев, Вы писали:

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

ГВ>За что, боярин?!

За дело!

Здравствуйте, kaa.python, Вы писали:

VD>>C++ уже не будет мэйнстримом.
KP>да он и сейчас, вроде как не мэйнстрим.

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

VD>>D еще не будет мэйнстримом.

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

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

С точки зрения проектирования — это два языка урода. Если индустрии и нужено нечто новое, то не такое как Ди и уж точно не такое как С++Ох. Кстати, только сейчас понял глубинный смысл имени. Было в лом переключаться на английский по этому написал на русском... когда стал думать чем заменить 0x, понял что русские буквы О и ха подходят лучше всего. В общем, си плюс плюс ох. Или точнее ох, ох, ох...

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

ЗЫ

Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++

Здравствуйте, VladD2, Вы писали:

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

VD>Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++

.

[читать голосом диктора с заставки к Fallout]
Vlad...
Vlad never changes...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

VD>>Извините, что вторгаюсь в это милое обсуждение Nemerle, Питоне и VladD2 с какими то мыслями о никому не интересных Ди и С++

.

CC>[читать голосом диктора с заставки к Fallout]
CC>Vlad...
CC>Vlad never changes...

Кстати, я же заранее извинился, что говорю по теме. Зачем меня в тягивать в споры о Владах?

Здравствуйте, Pzz, Вы писали:
Pzz>Идея с msi-дистрибутивом мне не кажется очень уж удачной: нет никаких гарантий, что никто не сломает мне мою питонию программу, поставив какой-нибудь 2.6 (не говоря уж о 3.0) поверх того 2.5, который я приволок с собой.
2.6 вроде обратно совместим с 2.5 (если не включать 3.0-mode или как его там). 3.0 — другой продукт вообще. Как он уживается с 2.х — не знаю, но, думаю, уживается.

MC>>Под линухом:
MC>>Собираем пакеты для нескольких дистрибутивов, в зависимостях указываем питон.
Pzz>Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.
А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.

PS: Впрочем, в опенсорсном *nix python — уже мейнстрим.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Mr.Cat, Вы писали:

Pzz>>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.
MC>>Как будто за питоном не стоит гугл. Просто область интересов гугла — по большей части веб. Потому пришествия питона на виндовые десктопы пока не состоялось.

Pzz>Гугл может и любит питон внутри себя, но не продвигает его в качестве именно платформы для всех.

Вы ошибаетесь: http://code.google.com/appengine/

Здравствуйте, VladD2, Вы писали:

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный).
Не совсем то, конечно, но Erlang вроде — как раз пример ФП + битодробления...

VD>Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++.
Да... Не похож.

VD>Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.
Массы вроде бы его приняли.

Здравствуйте, Pzz, Вы писали:

Pzz>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

Так и за питоном сейчас тоже не маленькие компании стоят, например гугль.

FR>>А у питона такая возможность есть, даже из коробки.

Pzz>А вы этой возможностью пользоваться пробовали, или вы теоретик?

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

Здравствуйте, Mr.Cat, Вы писали:

Pzz>>Я не уверен, что бинарно скомпилированные пакеты выдержат локальный update питона. Никто вроде бинарной совместимости байт-кода не обещал.
MC>А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.

Собираюсь я их прятать или нет, это отдельный вопрос, но уж точно не хочу лишать пользователей возможности использовать precompiled byte code. И самостоятельно их компилировать не собираюсь заставлять.

Здравствуйте, VladD2, Вы писали:

VD>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.

Выше замени Ди на немерле

VD>С точки зрения проектирования — это два языка урода. Если индустрии и нужено нечто новое, то не такое как Ди и уж точно не такое как С++Ох. Кстати, только сейчас понял глубинный смысл имени. Было в лом переключаться на английский по этому написал на русском... когда стал думать чем заменить 0x, понял что русские буквы О и ха подходят лучше всего. В общем, си плюс плюс ох. Или точнее ох, ох, ох...

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

Для масс D как раз и хорош, так же как и шарп.

Здравствуйте, FR, Вы писали:

Pzz>>У .Net'а это компенсируется тем, что за ним стоит мелкософт воооот с таааким вагоном денег. И при необходимости им пользуется для продвижения.

FR>Так и за питоном сейчас тоже не маленькие компании стоят, например гугль.

Ага, и еще Майкрософт.

Здравствуйте, FR, Вы писали:

FR>Около года выпускали продукт, потом когда py2exe стал достаточно стабильным перешли на него.
FR>Кроме того собирал так же немало небольших утилиток.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Обиднее всего, что в венде эта проблема более-менее решается. С помощью того же py2exe. А вот как раздавать питоновские standalone executables на линухе, совершенно непонятно. Ну не таскать же с собой свой питон, в самом деле?

Так freeze же вроде родная юниксовская утилита, нам до py2exe пришлось свою ваять чтобы полную сборку в один exe со всеми нужными библиотеками делать.

Здравствуйте, Pzz, Вы писали:
Pzz>Собираюсь я их прятать или нет, это отдельный вопрос, но уж точно не хочу лишать пользователей возможности использовать precompiled byte code. И самостоятельно их компилировать не собираюсь заставлять.

Мне кажется, питону это не поможет.

Здравствуйте, FR, Вы писали:

FR>Так freeze же вроде родная юниксовская утилита, нам до py2exe пришлось свою ваять чтобы полную сборку в один exe со всеми нужными библиотеками делать.

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

Здравствуйте, Pzz, Вы писали:

Pzz>Я напускал на зафризенную программу strace и выяснил, что она долго и нудно ищет всякие питоньи запчасти в том месте, где они лежали в момент фриза, и если находит, то использует. Не знаю, что будет, если не найдет, но еще больше меня волнует, что будет, если найдет, но не от того питона.

А сборку с полной статической линковкой нельзя разве сделать? У нас сначала была полная статическая линковка потом, зависимость только от python23.dll который лежал рядом с exe.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, kaa.python, Вы писали:

VD>>>C++ уже не будет мэйнстримом.
KP>>да он и сейчас, вроде как не мэйнстрим.

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

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

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

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

Здравствуйте, VladD2, Вы писали:

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

Не только. Есть довольно много задач, которые решать без C/C++ будет крайне затруднительно. Просто на нем перестали писать все что ни попадя, что безусловно хорошо.

Mr.Cat,

MC>Эх, не думаю... Все фишки CL и схемы уже расхватали дизайнеры других языков. Ну или почти все (Где еще есть динамическая область видимости переменных? Хотя это, конечно, всего лишь маленький кусочек сахара).

Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.

Здравствуйте, Ocelot, Вы писали:

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

Поэтому сначала появляется версия 1.0 по дешевому сценарию, набиваются шишки и следует переход к более дорогой v2.0 (и так далее

)

Здравствуйте, <Аноним>, Вы писали:

А>А может на JavaScript будем драйверы писать?

Насмешил, подобные вопросы рассматриваются вполне серьезно

Здравствуйте, VladD2, Вы писали:

VD>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

У C/C++ есть несколько очень больших преимуществ:

— не нужна VM (не считая статически подвязываемого C runtime);
— стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);
— чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);
— все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

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

И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.

Другое интересное следствие, заключается в том, что самый прогрессивный и прагматичный путь для индустрии на сегодняшний день — это продолжать развивать C++, поскольку он единственный из распространённых языков, который сможет плавно занять нишу C и привнести в общую среду программирования те самые новые веяния. Другого пути лично я не вижу, а пионерские рассуждения о том, что нужно выкинуть всё и всё переколпакировать лучше оставить пионерам.

Здравствуйте, Pzz, Вы писали:

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

ГВ>>За что, боярин?!

Pzz>За дело!

Надо мужикам рассказать: Певзнер за безделье не забанит! Добрый боярин!

Здравствуйте, yumi, Вы писали:

Y>Да все верно говоришь, код должен быть настолько простым насколько это возможно, но не проще

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

Чем, кроме оптимизации, функтор лучше интерфейса?

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, yumi, Вы писали:

Y>>Да все верно говоришь, код должен быть настолько простым насколько это возможно, но не проще

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

E>Чем, кроме оптимизации, функтор лучше интерфейса?

Интерфейс (в смысле абстракного понятия), требующий фуктора или, например, boost::function будет гораздо проще в определении и в использовании, чем интерфейс, требующий интерфейса (в смысле интерфейсного класса). Сравни, например, Java Runnable и boost::thread.

Чтобы создать поток, с помощью Runnable, нам нужно определить свой собственный класс, унаследованный от Runnable, потом определить у него метод run(), а после этого создать объект этого класса и передать его в класс Thread, и — наконец-то — поток запустится.

Для сравнения, в boost::thread создание потока, исполняющего любую наперед существующюю функции или метод класса или объекта функтора, является тривиальной операцией:

boost::thread thr(&my_arbitrary_function);

И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.

Здравствуйте, Pzz, Вы писали:

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

IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...

Здравствуйте, alexeiz, Вы писали:

A>И все!

Не, еще не все. Еще есть лямбды с С++0Х

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, alexeiz, Вы писали:

A>И все! Никаких дополнительных интерфейсов и классов, ничего не надо реализовывать, и никаких ненужных сущностей создавать не надо. Все предельно кратко и лаконично.

Да ничего не просто и не лаконично.
Если тебе надо просто существующую функцию звать, то всё пофиг. А если какой-то метод какого-то класса, то всё равно этот класс и этот метод надо писать. Какая разница в реализации интерфейса или ещё где? Мало того, если тебе надо какой-то метод какого-то уже существующего объекта позвать, то тоже не сложно написать шаблонную реализацию такого класса, который хранит в себе указатель на объект и указатель на метод...

Просто в твоём "кратком и лаконичном" варианте есть два существенных недостатка
1) Интерфейс плохо описан формально
2) Весь код, использующий интерфейс должен быть шаблонным. Иногда это довольно неприятное требование. А иногда и неприемлемое (например когда ты поставляешь наружу из DLL функцию, в которую надо передавать функтор)

Здравствуйте, Erop, Вы писали:

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

E>IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...

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

Здравствуйте, Pzz, Вы писали:

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

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

Здравствуйте, Mr.Cat, Вы писали:

MC>Не совсем то, конечно, но Erlang вроде — как раз пример ФП + битодробления...

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

VD>>Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.
MC>Массы вроде бы его приняли.

Где? Что-то эти массы не видно в микроскоп.

Здравствуйте, FR, Вы писали:

VD>>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.

FR>Выше замени Ди на немерле

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

FR>Для масс D как раз и хорош, так же как и шарп.

Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.

А про массы просто смешно слушать. Где они?

Здравствуйте, VladD2, Вы писали:
VD>Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных.
Да.

VD>Насколько я знаю, она написана не на Эрлаге.
Ессно. Я имел в виду, что "бинарный" паттерн-матчинг там — довольно удобная штука. Просто неправильно понял, что Вы имели в виду под "битодроблением".

VD>Где? Что-то эти массы не видно в микроскоп.
Смотря с чем сравнивать. Если с C++\C# — то да, до их популярности он не дотягивает.
Тем не менее, насколько я понимаю, он уже довольно широко, вон даже на сайтах, типа hh, стали появляться вакансии erlang-разработчиков (это если сравнивать с D, CL и т.п.)

E>>IMHO, это слишком радикально. Вполне достаточно потребовать и добиться того, чтобы они не писали неоправданно сложно...

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

Неужто все, кто "знает современный C++" этакое творят?

Здравствуйте, Didro, Вы писали:

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

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

VD>>Возможно было бы не плохо если появился бы язык нового поколения поддерживающий как современные стили программирования (ООП, ФП, МП), так и имеющий полноценный низкоуровневый режим (битодробильный). Но на мой взгляд этот язык уж точно не должен быть похож ни на Ди, ни на С++. Но при этом его скорее всего не примут массы. Потому как у них уже есть лопата которую поддерживает весь мир.

D>Обработка изображений и видео в реальном времени, на ПК + embedded платформах.

Ну, про встраиваемые приложения — это явно слишком большое обобщение. Наверно среди них есть местах коде С++ по прежнему хороший выбор. Но в большинстве случаев — нет. Скажем терминалы оплаты или банкоматы в нашей стране внутри себя содержат как минимум четвертые пни и Windows 2000, что позволяет писать софт для них почти на чем угодно. Никакой супер вычислительной мощности там не надо.

А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.

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

Для меня слова "интеллектуальная" и С++ просто не совместимы. Так что не смешите мои тапочки. Хотите интеллекта, берите МЛ-клоны. По скорости они будут на уровне, а интеллекта там в разы больше. Ну, и "когда обрабатывают на биты пикселей" — это простите просто маразм. Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно). Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.

Ну, и опять же это, что называется, штучная работа.

D>И если задумаетесь, что вот вам прямо сейчас будет необходимо проектировать систему для решения задач именно этой области, то вряд ли предложите что-то другое, окромя С++.

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

Здравствуйте, kaa.python, Вы писали:

KP>Не только. Есть довольно много задач, которые решать без C/C++ будет крайне затруднительно. Просто на нем перестали писать все что ни попадя, что безусловно хорошо.

Много? Перечисли их и сам увидишь, что это не так. Потом зайди на наш форум по плюсам и погляди сколько там народа ошивается. Думаешь они все решают задачи для которых С++ лучший выбор?

В последние два раза когда я спросил чем занимается на работе С++-программист ответы были "корверторы пишу" и "финансовую систему делаю". На мой взгляд выбор С++ для этих задач — это просто идиотизм.

Здравствуйте, VladD2, Вы писали:

VD>Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.
А Ада?

VD>А про массы просто смешно слушать. Где они?
Это ты про шарп?

Здравствуйте, VladD2, Вы писали:

VD>Слишком часто на С++ пишут разные конверторы
Это как раз нормально. Конверторы они разные бывают.

VD> системы управления бизнес-задачами и прочую муть для которой С++ явный оверкил.
Это да

VD>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.
"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.

VD>Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно).

VD>Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.
Ты писал на С++ с использованием современных (не микрософт) компиляторов?
Непосредственно на асме писать нужда практически возникает только тогда, когда на нужные команды нет интринсиков. А так — ICC рулит.
Видеокарты, пригодные под обработку не-игровых данных покуда не сильно распространены да и специфичный очень софт получается. Плюс у них свои ограничения и специфика.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>У C/C++ есть несколько очень больших преимуществ:

ГВ>- не нужна VM (не считая статически подвязываемого C runtime);

Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

ГВ>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);

Ну, да. Вот только скажем тот же Окамл тоже не вчера родился и имеет весьма стабильные реализации. Вот только 90% офисного планктона не в состоянии освоить этот язык. Они и С++, то используют процентов на 30.

ГВ>- чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);

Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно. Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.

ГВ>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).

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

ГВ>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.

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

Преимуществом является другое:
* Огромная разрекламмированность.
* Наличие огромного количества учебников и другой литературы.
* Наличие большого комьюнити.
* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
* Поддержка гигантами вроде МС.

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

ГВ>И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.

Это вообще заблуждение. С++-программистов в конце девяностых начале десятых было очень много. Чуть ли не 50%. А вот сейчас уже виден явный спад. Найти работу С++-нику стало намного сложнее. И эта тенденция будет только нарастать.

ГВ>Другое интересное следствие, заключается в том, что самый прогрессивный и прагматичный путь для индустрии на сегодняшний день — это продолжать развивать C++, поскольку он единственный из распространённых языков, который сможет плавно занять нишу C и привнести в общую среду программирования те самые новые веяния. Другого пути лично я не вижу, а пионерские рассуждения о том, что нужно выкинуть всё и всё переколпакировать лучше оставить пионерам.

Блин, ниша С уже давно свернулась в трубочку. Ей богу как на юмористическом концерте. Такие пафосные утверждения имели смысл лет 10 назад.

Будущее точно не за С++. И потихонечку это осознается массами. Просто планктон есть планктон. Чтобы он проникся банальными мыслями ему их нужно десятилетиями в голову втемяшивать.

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

Здравствуйте, Mr.Cat, Вы писали:

VD>>Где? Что-то эти массы не видно в микроскоп.
MC>Смотря с чем сравнивать. Если с C++\C# — то да, до их популярности он не дотягивает.
MC>Тем не менее, насколько я понимаю, он уже довольно широко, вон даже на сайтах, типа hh, стали появляться вакансии erlang-разработчиков (это если сравнивать с D, CL и т.п.)

Дык C++, C#, Васик и Java и есть на сегодня мэйнстрим. Ну, с огромной натяжкой туда можно отнести Питона.

Здравствуйте, CreatorCray, Вы писали:

VD>>Слишком часто на С++ пишут разные конверторы
CC>Это как раз нормально. Конверторы они разные бывают.

Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.

VD>>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.
CC>"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.

Ну, пусть откликнутся те кто его пишут. Ау... Где вы...

VD>>Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно).
CC>

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

Intel и GNU в их число входят?

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

А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
Вот только решение на видюже один фиг порвет все твои выкрутасы.

VD>>Дык как только начинаешь задумываться, так сразу становится ясно, что С++ как раз наихудший выбор почти всегда.
CC>Для тебя — несомненно!

Мы меня обсуждаем? Ну, да меня люди что не задумываются вообще не интересуют.

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

В нем что-то изменилось с 1998-го года? Можно ссылочку?
Ну, и на такие "думы" могу ответить только одно "сам ты дурак".

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.

Ага, неплохой. Еще бы не было этой фичи и было бы по больше контроля, и вообще бы бы замечательным.
На мой взгляд это была ошибка дизайна. Потом автор создал шаблоны с параметрами и они полностью утранили необходимость в динамической области видимости.

Здравствуйте, VladD2, Вы писали:

VD>Ты наверно говоришь о библиотеке позволяющей разбирать бинарные структуры данных. Насколько я знаю, она написана не на Эрлаге.
как раз на Эрланге, binary matching очень удобная вещь для разбора пакетов.
MC>>Массы вроде бы его приняли.

P.S. Почему бы в Nemerle не добавить такуе фишки как например actor model и аналог OTP пусть и без горячей замены кода, MS своим DSS как раз пытаются это делать? насколько я знаю в Scala пытаются это сделать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

VD>>>Слишком часто на С++ пишут разные конверторы
CC>>Это как раз нормально. Конверторы они разные бывают.
VD>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.
Для финансов — вполне могу поверить. У меня правда на слово конвертор совершенно далекие от финансового применения ассоциации.

VD>>>А обработка видео... Да, наверно. Возможно и С++ тут не всегда хороший выбор, а часть библиотек стоит написать на ассемблере с использованием расширенных команд. Но сколько людей занимаются написанием такого софта? Думаю, что на нашем сайте таких нет. Или есть 1-2 человека.
CC>>"Такого софта" == числодробящего существенные объемы данных? Думаю гораздо больше.
VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...
Я тут

Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++. Сейчас правда основная занятость в другой отрасли.

CC>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?
VD>Intel и GNU в их число входят?
ICC == Intel C++ Compiler

CC>>Непосредственно на асме писать нужда практически возникает только тогда, когда на нужные команды нет интринсиков. А так — ICC рулит.
CC>>Видеокарты, пригодные под обработку не-игровых данных покуда не сильно распространены да и специфичный очень софт получается. Плюс у них свои ограничения и специфика.
VD>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
VD>Вот только решение на видюже один фиг порвет все твои выкрутасы.
Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

VD>>>Дык как только начинаешь задумываться, так сразу становится ясно, что С++ как раз наихудший выбор почти всегда.
CC>>Для тебя — несомненно!
VD>Мы меня обсуждаем?
Нет. Просто ты все время выдаешь категоричные заявления, на "ИМХО" совсем не похожие.

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

VD>В нем что-то изменилось с 1998-го года? Можно ссылочку?
Я про твое общеизвестное предвзятое отношение.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Pzz, Вы писали:

MC>>А, так Вы собрались исходники прятать? Тогда — действительно не знаю, как лучше поступить.

Pzz>Собираюсь я их прятать или нет, это отдельный вопрос, но уж точно не хочу лишать пользователей возможности использовать precompiled byte code. И самостоятельно их компилировать не собираюсь заставлять.

Зачем самостоятельно? Например, в deb-пакетах для этого есть отлаженная инфраструктура: всё прекомпилирует и куда надо положит.

Здравствуйте, VladD2, Вы писали:

Какая экспрессия.

ГВ>>У C/C++ есть несколько очень больших преимуществ:
ГВ>>- не нужна VM (не считая статически подвязываемого C runtime);
VD>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

Правильно. Разница в размерах, как минимум.

ГВ>>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);
VD>Ну, да. Вот только скажем тот же Окамл тоже не вчера родился и имеет весьма стабильные реализации. Вот только 90% офисного планктона не в состоянии освоить этот язык. Они и С++, то используют процентов на 30.

Кто есть "офисный планктон"?

ГВ>>- чудовищное количество наработанного и используемого ПО (это миллиарды копий, вдумайтесь в это число — 10^9, вы хочите аргументов массой? Их есть у меня);
VD>Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно.

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

VD>Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.

Ну, то, что ты фыркаешь в адрес "велосипедостроителей", означает для меня только то, что ты не совсем понимаешь, почему иной раз приходят к выводу о необходимости построения своего велосипеда. Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.

ГВ>>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).
VD>И это не преимущество. Потому как именно, что С, а не С++ и уж точно не С++ Ох. В этом Лисп ни чем не хуже чем С++. В .нет и вовсе есть собственный компилятор С++ который оносительно просто может завернуть программу на неуправляемм С++ в дотнетную сборку.

Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.

ГВ>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

VD>Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.

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

VD>На самом деле все вышеперечисленное не является приемуществом С++. Иначе каой-нить Ди уже давно бы его стер с лица земли.

VD>Преимуществом является другое:
VD>* Огромная разрекламмированность.

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

VD>* Наличие огромного количества учебников и другой литературы.

Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно.

VD>* Наличие большого комьюнити.
VD>* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
VD>* Поддержка гигантами вроде МС.

Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.

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

Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования. С теоретической точки зрения его не совсем разумно тыкать в те области, система терминов которых далеко отстоит от таких, как "память" и "процессор", равно как и функциональные языки не совсем правильно запихивать туда, где задача не описывается выражениями "найти решение" и "анализ". Кстати, применение функциональных языков в областях, связанных с коммуникацией, ИМХО, связано лишь с тем, что зачастую тут "операцию" можно свести к "функции от входящего сообщения".

ГВ>>И если учесть эти факторы, то кто там станет мейнстримом завтра — да какая, на фиг, разница? Программистов на C/C++ всегда было относительно немного — 10-15% от общей массы, не считая, — как ты это правильно заметил, — глюка начала 2000-х, когда "плюсовиками" называли себя все, кому не лень.

VD>Это вообще заблуждение. С++-программистов в конце девяностых начале десятых было очень много. Чуть ли не 50%. А вот сейчас уже виден явный спад. Найти работу С++-нику стало намного сложнее. И эта тенденция будет только нарастать.

Вынужден тебя огорчить: из тех "50% сиплюсплюсников" действительно хороших специалистов было хорошо, если 1/5. Написать в резюме "C++" дело не хитрое, равно как и "Java", ".Net" и т.п.

ГВ>>Другое интересное следствие, заключается в том, что самый прогрессивный и прагматичный путь для индустрии на сегодняшний день — это продолжать развивать C++, поскольку он единственный из распространённых языков, который сможет плавно занять нишу C и привнести в общую среду программирования те самые новые веяния. Другого пути лично я не вижу, а пионерские рассуждения о том, что нужно выкинуть всё и всё переколпакировать лучше оставить пионерам.

VD>Блин, ниша С уже давно свернулась в трубочку. Ей богу как на юмористическом концерте. Такие пафосные утверждения имели смысл лет 10 назад.

Не знаю насчёт трубочки. Ниша C как была, так и осталась в области системного программирования и правильнее всего ничего не пытаться с этим сделать. Когда стеки tcp/ip будут повсеместно заменены реализациями на ML — тогда и рассуждать будем о трубочках. Покуда родной интерфейс этих библиотек сугубо сишный — в трубочку сворачиваются только аргументы борцов с C/C++. И с каждым днём ситуация усугубляется.

VD>Будущее точно не за С++. И потихонечку это осознается массами. Просто планктон есть планктон. Чтобы он проникся банальными мыслями ему их нужно десятилетиями в голову втемяшивать.

Признаться, я понятия не имею о том, за каким языком будущее. Больше того, я вообще не представляю, как за языком может быть какое-то "будущее", кроме как за инструментом решения тех или иных задач. В случае C/C++ оказалось, что они заняли нишу системного программирования, хотя... Хотя, сколько занимаюсь программиованием, столько нахожу массу критических отзывов об этих языках. Уж как C клеймили, противопоставляя ему то Аду, то ещё что-нибудь!

Я могу примерно представить причины, по которым C/C++ получили такое большое распространение, но и не более того. Ещё могу примерно представить, почему разработчики современных языков обречены на провал, желая повторить этот самый "успех".

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

Спили мушку.

Здравствуйте, Erop, Вы писали:

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

Довольно трудно формально сформулировать, что такое "правильный" C++ код. Как начнешь формулировать, на выходе все pure ANSI C получается

Ну и следить все время за соблюдением сил никаких нет.

Штрафы, кстати, запрещены Трудовым Кодексом. Остается только гнать в шею

Здравствуйте, cadet354, Вы писали:

C>P.S. Почему бы в Nemerle не добавить такуе фишки как например actor model и аналог OTP пусть и без горячей замены кода, MS своим DSS как раз пытаются это делать? насколько я знаю в Scala пытаются это сделать.

Да все по тому же почему туда не добавлено еще 20 классных и полезных фич. Нет свободных рук которые могут это сделать.

Какие-то макры для работы в многопоточном окружении там есть.

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

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

Здравствуйте, CreatorCray, Вы писали:

CC>Я тут

Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.

Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.

CC>Сейчас правда основная занятость в другой отрасли.

Боюсь спросить в какой. Не ужели снова финансы?

CC>>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?
VD>>Intel и GNU в их число входят?
CC>ICC == Intel C++ Compiler

Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.

CC>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.

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

VD>>Мы меня обсуждаем?
CC>Нет. Просто ты все время выдаешь категоричные заявления, на "ИМХО" совсем не похожие.

Я "выдаю" свое мнение. Это априори.
По любому если тебе оно не нравится, то и обсуждай его (мнение), а не меня. Или уж тогда говори конкретно, а не свое "имхо" о моем общер развитии.

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

VD>>В нем что-то изменилось с 1998-го года? Можно ссылочку?
CC>Я про твое общеизвестное предвзятое отношение.

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

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>>У C/C++ есть несколько очень больших преимуществ:
ГВ>>>- не нужна VM (не считая статически подвязываемого C runtime);
VD>>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.

ГВ>Правильно. Разница в размерах, как минимум.

Размерах, чего, простите? Или это снова пенисометрия?

ГВ>>>- стабильность языка (ага, как раз то, что новые веяния впитываются в C/C++ достаточно медленно);
VD>>Ну, да. Вот только скажем тот же Окамл тоже не вчера родился и имеет весьма стабильные реализации. Вот только 90% офисного планктона не в состоянии освоить этот язык. Они и С++, то используют процентов на 30.

ГВ>Кто есть "офисный планктон"?

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

VD>>Это вообще не преимущество. Мало ли что и на чем написано? Может ты о библиотеках? А вот с ними то на С++ полная задница. Есть 3-4 либы используемые более менее повсеместно.

ГВ>Да ну?

Ну, да.

ГВ>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.

Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.

VD>>Но в основном С++ стал отличной гаванью для велосипедостроителей. Мы вот только что сдали новый номер журнала и в нем есть ряд статей С++-ников. Все как одна — это описание собственных велосипедов. Их авторы еще не знаю, что другие С++-ники тоже любят велосипеды, но собственного производства.

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

Я все могу понять. Но при этом я прекрасно понимаю, что стремление к велосипедостроению вызвано двумя основными факторами:
1. Дурью в бошке.
2. Низкоуровневостью и отсуствием полноценных стандартов в С++.
Если сравнить положение дел с библиотеками в С++ и Яве/.NET, то разница видна невооруженным взглядом.

Можно сказать, что Яве и .NET проектировались так, чтобы стать отличной платфоромой для библиотек и фрэймворков. Да и не маловажно, что прямо в составе платформ поставляется огромнейшая стандартная библиотека. Чего в С++ не было, нет и видимо никогда не будет.

ГВ>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.

Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?

ГВ>>>- все (AFAIK) более или менее широко используемые языки и системы имеют foreign-интерфейс с C (не Lisp, не Java, не .Net).
VD>>И это не преимущество. Потому как именно, что С, а не С++ и уж точно не С++ Ох. В этом Лисп ни чем не хуже чем С++. В .нет и вовсе есть собственный компилятор С++ который оносительно просто может завернуть программу на неуправляемм С++ в дотнетную сборку.

ГВ>Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.

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

ГВ>>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

VD>>Да кого трогает где и кем была создана ванна? Большинство людей волнует удобство этой ванны и ее чистота.

ГВ>Большинство вообще ничего не волнует, кроме холодильника и комфортабельности кресла. Статус-кво это никаким образом не меняет.

Ну, да. Некоторые по году не моются. Но мы вроде не об этом...

VD>>На самом деле все вышеперечисленное не является приемуществом С++. Иначе каой-нить Ди уже давно бы его стер с лица земли.

VD>>Преимуществом является другое:
VD>>* Огромная разрекламмированность.

ГВ>Странно, что при этом взрывное распространение C++ не сопровождалось рекламной компанией. Больше того, в то время существовала ещё груда объектных языков. На вскидку могу вспомнить

У того времени были свои особенности. Сейчас все не так. Да и реклама была не хилая. АтиЭндТи тогда была очень влиятельная контора. Они вот ОС свою протащить сумели.

VD>>* Наличие огромного количества учебников и другой литературы.

ГВ>Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно.

Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

VD>>* Наличие большого комьюнити.
VD>>* Наличие множества хорошо оптимизированных компиляторов промышленного качества.
VD>>* Поддержка гигантами вроде МС.

ГВ>Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.

Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.

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

ГВ>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования.

Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.

Здравствуйте, skeptik_, Вы писали:

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

_>Не чуть ли, а основным. А с 2001 года и по сей день он является вторым номером.

Да, даже не третьи. Просто сейчас Ява и Шарп вышли в лидеры, а тогда лидером в бизнесе был Васик и уже Ява. На его фоне С++ выглядел неплохо. Но сейчас С++ как минимум идет за ними всеми, то есть, в лучшем случае на четвертом месте.

Здравствуйте, VladD2, Вы писали:

VD>>>На мой взгляд Ди бесперспективен. Останови автор его развитие и никто не будет его использовать. Развивай автор его далее и никто не будет его использовать просто потому, что никто не хочет использовать "нестабильный язык". Хотя про его нестабильность еще бабушка на двое сказала.

FR>>Выше замени Ди на немерле

VD>Зачем? В тебе указан Ди и С++.

Затем что оба в одинаковой ж...

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

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

Для своей ниши D вполне сбалансированный и адекватный. И для тех кто ищет замену C++ он дает не меньше плюшек чем немерле для тех кто ищет замену шарпу.

FR>>Для масс D как раз и хорош, так же как и шарп.

VD>Шарп — это язык с ошибками в проектирование. Ди — это язык без проектирования. Так что он хорош только для тех кто находится в совсем уж узких рамках выбора.

Угу вот только как показывает практика именно языки без проектирования и становятся массовыми и популярными, эволюция рулит

VD>А про массы просто смешно слушать. Где они?

Угу

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, skeptik_, Вы писали:

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

_>>Не чуть ли, а основным. А с 2001 года и по сей день он является вторым номером.

VD>Да, даже не третьи. Просто сейчас Ява и Шарп вышли в лидеры, а тогда лидером в бизнесе был Васик и уже Ява. На его фоне С++ выглядел неплохо. Но сейчас С++ как минимум идет за ними всеми, то есть, в лучшем случае на четвертом месте.

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

ЗЫ На немерле там до сих пор нет ни одного проекта.

Здравствуйте, VladD2, Вы писали:

VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

Да ну SICP есть, финская книжка.

Здравствуйте, VladD2, Вы писали:

VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.

Осталось обосновать отсутствие влияния языка на инфраструктуру.
Я это к тому, что если бы вместо Си++ в то время и в том месте оказался бы OCaml, далеко не факт, что он бы стал мейнстримом вместо Си++.
Или ты считаешь, что стал бы?
Просто звучит это так, будто от языка вообще ничего не зависит, кругом правят деньги и большие корпорации. Оно, конечно, ради бога, только к чему тогда споры о языках вообще, если от них толку ноль?
Divide et impera это, конечно, хорошо, только для начала следует убедиться, что разделять можно.

Здравствуйте, VladD2, Вы писали:

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

На злобу дня, что называется:

Realtime audio processing with Lisp

Просто как иллюстрация этой ветки.

Здравствуйте, VladD2, Вы писали:

VD>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.

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

VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...

Я. По работе — анализ видео. Есть, например, ограничение по времени на обработку одного кадра стандартного разрешения — 5 млсек. Это на сжатие (или, наоборот, разжатие), анализ, сохранение на диск. Система мягкого реального времени.
Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же

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

Видеокарты, например, умеют работать только 4-х байтовыми float. Для многих задач это принципиальное ограничение. И оно не единственное.

VD>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
VD>Вот только решение на видюже один фиг порвет все твои выкрутасы.

Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.
Возьмём очень универсальный пакет Матлаб. Ох, и у него математика лежит в dll, написанных на С++.

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

VladD2,

LCR>>Динамическая область видимости есть ещё в StringTemplate — неплохой язык для построения генераторов.

VD>Ага, неплохой. Еще бы не было этой фичи и было бы побольше контроля, и вообще бы бы замечательным.
VD>На мой взгляд это была ошибка дизайна. Потом автор создал шаблоны с параметрами и они полностью устранили необходимость в динамической области видимости.

И как обращаться из глубоко вложенного шаблона к параметру внешнего шаблона? Если бы не было динамической области видимости, пришлось бы писать такие кренделя (протаскиваем var вглубь до template10):

block(var) ::=
  много текста <template0(p1=var, p2="preved")>
template0(p1, p2) :=
  много текста <template1(p1=var, p2="medved")>
template1(p1, p2) :=
  много текста <template2(p1=var, p2="andvvp")>

...

template10(p1, p2) :=
  наконец тут мы получаем доступ к <p1> 
  который равен <var> и можем его использовать

А с динамической областью видимости можно обратиться прямо к var из template10 не протаскивая его через всю цепь вызовов. В обычных языках это конечно решается просто созданием глобального относительно template0..template10 бинда, а здесь такого нет. Или как?

Здравствуйте, Pzz, Вы писали:

Pzz>Довольно трудно формально сформулировать, что такое "правильный" C++ код. Как начнешь формулировать, на выходе все pure ANSI C получается

Да не надо формулировать. Вполне достаточно понимать

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

Pzz>Ну и следить все время за соблюдением сил никаких нет.
Ну при всплытии факта имеют сильно исполнителя и очень сильно его начальника и далее по цепочке...

Pzz>Штрафы, кстати, запрещены Трудовым Кодексом. Остается только гнать в шею

Вот тоже мне проблема. Зато премии не запрещены...

Здравствуйте, VladD2, Вы писали:

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

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

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

VD>Для меня слова "интеллектуальная" и С++ просто не совместимы. Так что не смешите мои тапочки. Хотите интеллекта, берите МЛ-клоны. По скорости они будут на уровне, а интеллекта там в разы больше. Ну, и "когда обрабатывают на биты пикселей" — это простите просто маразм. Такие вещи что на JavaScript, что на C++ будут работать дико медленно (относительно конечно). Тут как минимум нужно использовать библиотеки написанные на ассемблере с применением симд-инструкций, а по уму данные вычисления вообще стоит переложить на плечи современных видеокарт которые имеют и соотвественный набор команд, и вычислительные мощьности в разы большие чем у современных универсальных процессоров.

IMHO, ты не там интеллект ищешь...
Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
И тогда, зачастую, конкурируют как раз С++ и C... Следующий кандидат (уже сильно хуже) -- что-то ООП из наследников PASCAL...

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

Вот тебе три задачи:
1) Написание базы данных
2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

На чём реализовывать будем?

Здравствуйте, VladD2, Вы писали:

CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.

VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.

Зато идут на любой машине... И на любой машине одинаково работают, к тому же...

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

Здравствуйте, VladD2, Вы писали:

VD>>>Ага. То же преимущество имеют Лисп (есть компилятор в нэйтив), Окамл, и еще пара десятков не так распространенных языков.
ГВ>>Правильно. Разница в размерах, как минимум.
VD>Размерах, чего, простите? Или это снова пенисометрия?

В размерах добавляемого кода к распространяемому исполняемому модулю.

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

Иными словами, офисный планктон — это мейнстрим в кристалльном виде. Интересно.

ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.
VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.

Со свечкой везде постоял, чтобы такое утверждать?

VD>Я все могу понять. Но при этом я прекрасно понимаю, что стремление к велосипедостроению вызвано двумя основными факторами:
VD>1. Дурью в бошке.

Оставим за скобками.

VD>2. Низкоуровневостью и отсуствием полноценных стандартов в С++.

Полноценных — это каких?

VD>Если сравнить положение дел с библиотеками в С++ и Яве/.NET, то разница видна невооруженным взглядом.

Безусловно. Велосипеды явы и дотнета ещё впереди.

VD>Можно сказать, что Яве и .NET проектировались так, чтобы стать отличной платфоромой для библиотек и фрэймворков. Да и не маловажно, что прямо в составе платформ поставляется огромнейшая стандартная библиотека. Чего в С++ не было, нет и видимо никогда не будет.

И это просто замечательно, что C++ не занимается предписыванием реализации примитивов.

ГВ>>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. [...]
VD>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?

Как это — OK? Почему же тогда bltoolkit появилась? Натуральный велосипед.

ГВ>>Что лишний раз подтверждает тезис об интерфейсе с C. Теперь в этой компании ещё и .Net. Ну что ж, пусть зацветают все цветы.

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

Я не собираюсь спорить с тем, что C-интерфейса зачастую достаточно. Насчёт рассуждений относительно C++ в этом контексте — так он сам в каком-то смысле находится в компании языков, имеющих интерфейс с C.

И ещё пара интересных моментов: например COM имеет хорошие такие корни в C++ (за что его и ругали одно время), GDI+ — пусть не корни, но как минимум интерфейс.

ГВ>>>>А остальные прогрессивные парадигмы благополучно плещутся в среде, которое создало ПО на C/C++. Вот такая вот идиллия.

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

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

VD>>>* Огромная разрекламмированность.
ГВ>>Странно, что при этом взрывное распространение C++ не сопровождалось рекламной компанией. Больше того, в то время существовала ещё груда объектных языков. На вскидку могу вспомнить
VD>У того времени были свои особенности. Сейчас все не так. Да и реклама была не хилая. АтиЭндТи тогда была очень влиятельная контора. Они вот ОС свою протащить сумели.

Ты считаешь, что кроме рекламы от нехилой AT&T никаких больше факторов не способствовало продвижению Unix? А может быть, дело в том, что Unix оказался вполне удачной переносимой многопользовательской ОС, которая в самом деле позволила переносить ПО с одной машины на другую?

VD>>>* Наличие огромного количества учебников и другой литературы.
ГВ>>Достаточно одного хорошего учебника по языку. По тому же Lisp, например, их вполне достаточно.
VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

Надо, чтобы ещё их хотели купить. Не находишь, что есть некоторая разница между "валялись" и "хотели приобрести"?

ГВ>>Ну вот видишь, даже ты нашёл кучу преимуществ у C++. Хотя казалось бы.

VD>Я я их не терял. Просто это все преимущества инфраструктуры, а не языка.

Так или иначе, но это имеет прямое отношение к языку. Если отставить в сторону пассажи про "офисный планктон", то наличие коммьюнити и поддержка гигантов в современных условиях — очень существенный аргумент. Я отнюдь не пытаюсь сказать, что он единственный, но то, что немаловажный — это бесспорно. Если ты не заметил, я здесь сам прибегаю к аргументам массовостью.

ГВ>>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования.
VD>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.

Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.

Кроме того, в системное программирование, в общем, не только ОС включаются. В этот класс, скорее, имеет смысл зачислить весь "инфраструктурный" софт — в том числе библиотеки, серверы баз данных и, вполне очевидно, трансляторы языков программирования. То есть как раз вот тот самый ACE, про который ты вспомнил, вполне себе пример такой библиотеки.

Здравствуйте, Erop, Вы писали:

E>Вот тебе три задачи:
E>1) Написание базы данных
E>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>На чём реализовывать будем?

Ко всем трем неплохо подходит OCaml.

Здравствуйте, nikov, Вы писали:

E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

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

2) (Кстати) Много баз на нём уже реализовали?

Здравствуйте, nikov, Вы писали:

E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

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

OCaml Language Sucks
Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks

И весь мой пыл куда-то улетучился..

Здравствуйте, Erop, Вы писали:

E>IMHO, ты не там интеллект ищешь...
E>Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...

А этот факт всегда игнорируется языкодвинутыми товарищами.
Могу свой недавний пример привести 182 строки кода на С++, 50 чистых рабочих часов. Интеллекта кстати немного, просто нужно было получить от WinAPI то что он не дает напрямую.

Здравствуйте, nikov, Вы писали:

E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

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

Здравствуйте, Didro, Вы писали:

D>Я тоже так думал, и почти уже был готов идти "аргументировать" смену языка разработки, но потом наткнулся на это:

D>

D>OCaml Language Sucks
D>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks

D>И весь мой пыл куда-то улетучился..

Не надо читать ушибленных лиспом, это трава уровня немерле

Здравствуйте, FR, Вы писали:

D>>OCaml Language Sucks
D>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks

FR>Не надо читать ушибленных лиспом, это трава уровня немерле

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

Здравствуйте, Didro, Вы писали:

FR>>Не надо читать ушибленных лиспом, это трава уровня немерле

D>Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет

Ocaml конечно корявый язык, но эти проблемы вполне разрешимы:

Arithmetic's readability — http://pa-do.forge.ocamlcore.org/

No Polymorphism — в сравнении с динамическим лиспом конечно, но даже для этого есть Object.magic который хоть и считается дурным тоном но вполне доступен.

Standard Library Sucks — тут он похоже просто искал к чему прикопатся

Здравствуйте, VladD2, Вы писали:

ГВ>>Ты на порядок-другой не ошибся? Только у меня в одном небольшом относительно проекте используется четыре сторонних библиотеки.

VD>Нет. В лубщем случае буст, асе и еще пара либ. И то не всегда. Чаще все же велосипеды.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Didro,

D>

D>>>OCaml Language Sucks
D>>>Обратить внимание на: Arithmetic's readability \ No Polymorphism \ Standard Library Sucks

Про Arithmetic readability — это критика чисто базовых возможностей без учёта продвинутых. В Ocaml Mathematical Framework эта проблема решена вполне успешно с помощью ocamlp4:

let symb p = 3*x**2-2*x-3;;
let symb e = p*(sin(x+1)+log(x**2-2*x+2)-2);;

По моему вполне ридабле

Здравствуйте, VladD2, Вы писали:

CC>>Я тут

Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.
VD>Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.
Это уже и не ява будет

CC>>Сейчас правда основная занятость в другой отрасли.
VD>Боюсь спросить в какой. Не ужели снова финансы?

Ага

на C#

CC>>>>Ты писал на С++ с использованием современных (не микрософт) компиляторов?
VD>>>Intel и GNU в их число входят?
CC>>ICC == Intel C++ Compiler
VD>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.
Ты — может и нет. А вот компилер — с удовольствием.

CC>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.
VD>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Nuzhny, Вы писали:

N>Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же

Угу. Переписывали как то для одного банка систему, которая за ночь на гриде не справлялась с обработкой данных. Так что бывает что и "Скорость = Деньги".

N>Видеокарты, например, умеют работать только 4-х байтовыми float. Для многих задач это принципиальное ограничение. И оно не единственное.
Сейчас уже научили и int и вроде как double

N>Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.
+1
IPP, MTL — просто глаза разбегаются чего там есть.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.
Добавлю. Еще надо приплюсовать время, потраченное на допиливание найденного под свои нужды (найти на 100% подходящее не всегда возможно), + есть риск понять что то что ты нашел, все таки не устраивает по какому то из параметров и быстрее было бы все таки написать специализированный под свою задачу аналог.

ГВ>Скажу тебе по секрету, что С++ на самом деле — язык "системного" программирования. С теоретической точки зрения его не совсем разумно тыкать в те области, система терминов которых далеко отстоит от таких, как "память" и "процессор", равно как и функциональные языки не совсем правильно запихивать туда, где задача не описывается выражениями "найти решение" и "анализ". Кстати, применение функциональных языков в областях, связанных с коммуникацией, ИМХО, связано лишь с тем, что зачастую тут "операцию" можно свести к "функции от входящего сообщения".
+100

ГВ>Уж как C клеймили, противопоставляя ему то Аду, то ещё что-нибудь!
..а он все жив

ГВ>Спили мушку.
+1

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

ГВ>>Кто есть "офисный планктон"?
VD>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
Тогда по моим наблюдениям это уже С# и Java

ГВ>>Попробуй просто поверить, что если бы, например, Lisp оказался столь же распространён, как C++, то на нём велосипеды строили бы не реже. Здесь есть сугубо объективные факторы: невозможно знать обо всех решениях, имеющихся для решения некоторой задачи на некотором языке, потому иной раз лучше написать что-то своё за известное время, чем потратить неизвестное на поиск уже имеющегося.
VD>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?
То, что с ними поставляется большая куча говна на все случаи жизни еще не означает, что никому и никогда не понадобится аналог, отличающийся от стандартной реализации по каким либо параметрам.

VD>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.
Windows 7 на чем пишут? Вроде ж новая...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>>>Я тут

Числодробилки (не видео, но графические данные в том числе) писал до недавнего времени. С использованием SSE на Intel С++.
VD>>Значит должен понимать, что это уже не совсем С++. И что имея оптимизированную библиотеку примитивов и на Яве можно весьма шутсрый код писать.
CC>Это уже и не ява будет

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

CC>>>Сейчас правда основная занятость в другой отрасли.
VD>>Боюсь спросить в какой. Не ужели снова финансы?

CC>Ага

на C#

Я всегда подозревал, что ты разумный человек

.
Тогда что спорить, если ты и сам делом подтверждаешь мои тезисы?

VD>>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.
CC>Ты — может и нет. А вот компилер — с удовольствием.

На практике код опережал VC в очень редких случаях и не принципиально.

CC>>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.
VD>>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
CC>В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.

В смысле те что есть.

Здравствуйте, Nuzhny, Вы писали:

VD>>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.

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

Мнение, что высокое быстродействие достигается ковырянием битов на плюсах очень распространено среди (мягко говоря) людей с ограниченным кругозором.
На практике же при мало-мальски сложных задачах использование компилируемых вариантов Lisp-а или клонов ML даст значительное преимущество хотя бы потому, что можно будет воспользоваться всей мощью частичных вычислений и паттерн-матчинга.

ИИ на С++ — это вообще для человека в этом немного понимающего должно звучать как Чубайс на нанотехнологиях

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

Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.

Если же я ошибаюсь, то просьба купить крутую программу-предсказатель и заработать миллион. 10% от него отдать мне. Это будет замечательным доказательством правоты и я возьму свои слова обратно

.

VD>>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...

N>Я. По работе — анализ видео. Есть, например, ограничение по времени на обработку одного кадра стандартного разрешения — 5 млсек. Это на сжатие (или, наоборот, разжатие), анализ, сохранение на диск. Система мягкого реального времени.

"мягкого реального времени" — это по русски будет называться система не реального времени

.

N>Как хобби занимаюсь иногда как раз предсказанием курса валют. На выходных, бывает, загружаю простаивающую сетку на работе — тот же анализ данных, расчёт статистики всякой и т.п. Представь, что обработка работала бы в 5 раз медленнее — ждать пришлось бы не 2, а 10 дней. Плохо же

Хоби меня не интересует. Главное, что ты пока что один (ОДИН) откликнулся и сказал, что твои задачи действительно соответствуют выбранному инструменту. А наши главные крикуны ставящие мне минусы на любое не лестное слово в адрес С++ тихо молчат в тряпочку. Подозреваю, что они как раз из тех, кто пишет софт для офисов и обосновывают это тем, что им дико не хватает производительности.

VD>>А так и просто библиотека будет рулить. Напиши ее или возьми от того же Intel-а и использовать из любого компилируемого языка.
VD>>Вот только решение на видюже один фиг порвет все твои выкрутасы.

N>Можно посмотреть на содержание тех же интеловских библиотек, на задачи которые они решают. Это область применения С++. А там и обработка сигналов, видео/аудио, сжатие, криптография, строки/регэкспы даже есть. Не говоря уже об универсальных математических библиотеках.
N>Возьмём очень универсальный пакет Матлаб. Ох, и у него математика лежит в dll, написанных на С++.

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

N>Я хочу сказать, что адекватных задач для языка С++ много. Кому-то они встречаются редко, а у кого-то постоянно перед глазами. Не стоит абсолютизировать собственный опыт.

Много? Мне кажется мы это понятие по разному понимаю. Вот долболомов пишущих на С++ что не попадя — много. А задач которые действительно требуют использования С++ отнюдь не много и большинство из них сводится к написанию библиотек, если конечно, по уму все делать, а не писать велосипеды на каждый чих объясняя их появление кривостью всего вокруг и особенностями своих задач.

Здравствуйте, Erop, Вы писали:
E>Вот тебе три задачи:
E>1) Написание базы данных
E>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>На чём реализовывать будем?

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

У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?
Если, нет, то чем занимаешся?

Здравствуйте, VladD2, Вы писали:

VD>Отнюдь. Все же есть огромная разница между специализированной либой используемой в программе написанной на переносимом, стандартизованном языке и специально заточенным под конкретный тип процессора языком.
Если >90% времени исполняется код из либы — то вообще пофигу на чем писать управление. Хоть на брейнфаке.

CC>>Ага

на C#
VD>Я всегда подозревал, что ты разумный человек

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

VD>Тогда что спорить, если ты и сам делом подтверждаешь мои тезисы?
Не, не подтверждаю. У нас и на С++ и на Java и на С# проекты есть. Даже perl под линухом был.
Просто на данный момент я на C# проекте. Только и всего.

VD>>>Это я догадался. Я это к тому, что я ими пользовался. Правда SSE не использовал.
CC>>Ты — может и нет. А вот компилер — с удовольствием.
VD>На практике код опережал VC в очень редких случаях и не принципиально.
Какой код опережал VC? Что то ты в последнее время загадками говоришь.
У меня по тестам разница между VC 7.1 и ICC 10.1 — более двух раз на криптографии, написанной на С++. 56Mb/s vs 120Mb/s.

CC>>>>Не все алгоритмы возможны на видяхе. Баловался с CUDA — пока оно применимо в частных случаях.
VD>>>Не все. Но по иронии судьбы те что доступны один фиг пишутся на С++ и их разработчики гордятся "высокой" производительностью. Хотя реально она просто никакая... в сравнении.
CC>>В смысле доступны? кому доступны. Переформулируй, т.к. не понятно про что ты.
VD>В смысле те что есть.
Тогда в сравнении чего с чем у кого никакая производительность?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, nikov, Вы писали:

E>>Вот тебе три задачи:
E>>1) Написание базы данных
E>>2) Написание системы, которая в реальном времени анализирует изображение с размещённых в здании камер и привлекает внимание оператора к подозрительным случаям (несанкционированный доступ кого-то куда-то, несанкционированное поведение и т. д.)
E>>3) Написание системы, которая анализирует видео с камеры наблюдения ГИБДД и выдаёт чкриншоты с наилучшими фотками нарушителей + госномер машины нарушителя.

E>>На чём реализовывать будем?

N>Ко всем трем неплохо подходит OCaml.

Да любой клон МЛ-я или даже компилируемый Лисп.

Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.

Здравствуйте, VladD2, Вы писали:

VD>Глупость — использовать эту библиотеку для прикладных задач из С++ же и рассказывать окружающим, что рекеспы и шифрование — это область применения С++.
Ну расскажи тогда, к области применения чего относить криптографию?
На примере RC6 например, как одного из наиболее просто реализуемых современных шифров.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Erop, Вы писали:

E>>>На чём реализовывать будем?

N>>Ко всем трем неплохо подходит OCaml.

E>1) А что, уже есть много пром. компиляторов, программистов, средств разработки, тоже промышленного уровня?..

Лет эдак 10.

E>2) (Кстати) Много баз на нём уже реализовали?

Море. Вопрос только в том, что пользуются люди в основном коммерческими раскручеными субды: IBM DB 2, MS SQL Server и Orcle.
Они конечно хороши, так как в них вложили сотни миллионов долларов (а может и больше), но они были бы во много раз лучше, если бы их писали на более адекватном инструменте.

Кстати, еще один встречный вопрос... Ты знаком хотя бы с одним клоном МЛ? Писал что-нибудь на нем? Подождут даже Scala, F# или Nemerle.

Здравствуйте, VladD2, Вы писали:

VD>"мягкого реального времени" — это по русски будет называться система не реального времени

.

...Как авторитетно заявил видный специалист в области систем реального времени VladD2.

Здравствуйте, FR, Вы писали:

FR>Угу только можем получить тормоза, компиляторы C++ намного лучше (особенно в графических алгоритмах) оптимизировать будут.

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

.

Да и достали вы уже с этими графическими алгоритмами возмите готовую библиотеку (того же McКакЕгоТам) и пишите логику, а не утыкайтесь в частности обработки графики.

Здравствуйте, FR, Вы писали:

FR>А этот факт всегда игнорируется языкодвинутыми товарищами.

Это ты о питонистах?

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Так или иначе, но это имеет прямое отношение к языку. Если отставить в сторону пассажи про "офисный планктон", то наличие коммьюнити и поддержка гигантов в современных условиях — очень существенный аргумент. Я отнюдь не пытаюсь сказать, что он единственный, но то, что немаловажный — это бесспорно. Если ты не заметил, я здесь сам прибегаю к аргументам массовостью.

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

ГВ>Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.

Оберон ОС. Да их куча если покапаться. Просто в фаворе сейчас Вынь и Линл. И хрен ты что с этим сделаешь все по тем же причинам.

В общем, все варится в рынке где игроки имеют слишком не равные возможности. Это тормозит прогресс.

Здравствуйте, kaa.python, Вы писали:

KP>по большому счету, этих 3-4 либ хватает для решения всех задач которые действительно стоит, можно и нужно решать на С++.

Да, да. Это фраза такая же крылатая, как и "640 Кбайт хватит всем"...

Здравствуйте, CreatorCray, Вы писали:

ГВ>>>Кто есть "офисный планктон"?
VD>>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
CC>Тогда по моим наблюдениям это уже С# и Java

Человек выбирающий С# или Java для подобных задач значительно более разумен. А высшие существа и отличается от планктона тем, что могут думать и принимать разумные решения. Другое дело, что есть разные стадии развития. То что человек может понять, что С++ не лучшее средство для офисной автоматизации — еще не означает, что он дальше не выключит мозг и не начнет закидывать задачи буденновками.

Собственно, можно тебя привести в пример. Ты же себя наверно идиотом не считаешь? И ведь ты как раз предпочел C# для решения тех самых офисных задач?

VD>>Зачем мне представлять "бы"? Я привел совершенно конкретный пример Яве/.NET. В них же все ОК с либами?
CC>То, что с ними поставляется большая куча говна на все случаи жизни еще не означает, что никому и никогда не понадобится аналог, отличающийся от стандартной реализации по каким либо параметрам.

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

VD>>Да чушь это. И используют его не для системного программирования, а для черт знает чего. А тот же Линкус и ядро НТ один хрен на С написано. А новые ОС пишутся но новых языках.
CC>Windows 7 на чем пишут? Вроде ж новая...

В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
Намек ясен? Ядро как было на С, так и остается. Ну, иногда пара, тройка расширений из плеюсов. Но ты никогда не дождешся, чтобы в ОС экспортировался интерфейс на С++.

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>И как обращаться из глубоко вложенного шаблона к параметру внешнего шаблона?

С этим проблем нет, если через параметры передаются ссылки на объекты.

LCR>А с динамической областью видимости можно обратиться прямо к var из template10 не протаскивая его через всю цепь вызовов. В обычных языках это конечно решается просто созданием глобального относительно template0..template10 бинда, а здесь такого нет. Или как?

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

Здравствуйте, eao197, Вы писали:

VD>>"мягкого реального времени" — это по русски будет называться система не реального времени

.

E>...Как авторитетно заявил видный специалист в области систем реального времени VladD2.

Ты сам то кроме как обсуждать других что-то еще сам можешь сказать?
Если, нет, то просто молчи.

Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.

Здравствуйте, Erop, Вы писали:

E>Просто в твоём "кратком и лаконичном" варианте есть два существенных недостатка
E>1) Интерфейс плохо описан формально
E>2) Весь код, использующий интерфейс должен быть шаблонным. Иногда это довольно неприятное требование. А иногда и неприемлемое (например когда ты поставляешь наружу из DLL функцию, в которую надо передавать функтор)

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

Короче, тебе нужно немного почитать о других мирах.

Здравствуйте, VladD2, Вы писали:

ГВ>>>>Кто есть "офисный планктон"?
VD>>>Те кто выбирают инструменты "как все" и пишут код "как у всех" в итоге решая, скажем, задачи офисной автоматизации на С++.
CC>>Тогда по моим наблюдениям это уже С# и Java
VD>Человек выбирающий С# или Java для подобных задач значительно более разумен........
Я про то, что ["как все" и пишут код "как у всех"] — это уже те, кто на шарпе и жабе.

VD>И ведь ты как раз предпочел C# для решения тех самых офисных задач?
Не могу сказать что это было именно мое решение. Но для определенного круга офисных задач шарп ИМХО подходит лучше. Тут спорить я не собираюсь. У нас как раз такой круг: одно огромное приложение с которым юзер работает бОльшую часть времени.

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

VD> Не без маразма конечно, но до маразма С++-ных библиотек им все же долеко. К тому же их отличает внятный и логичный интерфейс.
Не всегда. Впрочем каки для других языков. Библиотеки пишут люди.

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

VD>>>А новые ОС пишутся но новых языках.
CC>>Windows 7 на чем пишут? Вроде ж новая...
VD>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
Это был подкол, если ты не заметил.
PS. В висте ядро 2003й

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

VD>ИИ на С++ — это вообще для человека в этом немного понимающего должно звучать как Чубайс на нанотехнологиях

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

Откуда такая информация? Анализ результатов трейдерских соревнований говорит, что сейчас рулят стохастические нейросети.

VD>Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.

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

VD>"мягкого реального времени" — это по русски будет называться система не реального времени

.

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

Здравствуйте, VladD2, Вы писали:

VD>Хоби меня не интересует. Главное, что ты пока что один (ОДИН) откликнулся и сказал, что твои задачи действительно соответствуют выбранному инструменту. А наши главные крикуны ставящие мне минусы на любое не лестное слово в адрес С++ тихо молчат в тряпочку. Подозреваю, что они как раз из тех, кто пишет софт для офисов и обосновывают это тем, что им дико не хватает производительности.

Ну у меня на данный момент задачи вполне соответствуют C++, притом быстродействие в общем не нужно, да и какое быстродействие у С++ builder, зато очень много и глубоко приходится копатся в WinAPI и COM в общем системные утилиты.

Здравствуйте, VladD2, Вы писали:

VD>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.

Есть подозрения что написана она на все-таки на си

Здравствуйте, VladD2, Вы писали:

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

.

Угу но не для всех задач подходит.

VD>Да и достали вы уже с этими графическими алгоритмами возмите готовую библиотеку (того же McКакЕгоТам) и пишите логику, а не утыкайтесь в частности обработки графики.

Здравствуйте, VladD2, Вы писали:

FR>>А этот факт всегда игнорируется языкодвинутыми товарищами.

VD>Это ты о питонистах?

Не знаю, я теперь плюсист

Здравствуйте, Erop, Вы писали:

E>IMHO, ты не там интеллект ищешь...
E>Есть куча задач, в которых кодирование не представляет вообще никакой проблемы. Проблему представляет разработка и настройка алгоритмов. И тогда годится любой процедурный язык, без существенного встроенного оверхеда и поддерживаемый промышленными трансляторами и средами разработки...
E>И тогда, зачастую, конкурируют как раз С++ и C... Следующий кандидат (уже сильно хуже) -- что-то ООП из наследников PASCAL...

Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, VladD2, Вы писали:

VD>>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.

FR>Есть подозрения что написана она на все-таки на си

Вот что лежит в папке src мнезии (770 килобайт из R12B-3):

mnesia.erl
mnesia.hrl
mnesia_backup.erl
mnesia_bup.erl
mnesia_checkpoint.erl
mnesia_checkpoint_sup.erl
mnesia_controller.erl
mnesia_dumper.erl
mnesia_event.erl
mnesia_frag.erl
mnesia_frag_hash.erl
mnesia_frag_old_hash.erl
mnesia_index.erl
mnesia_kernel_sup.erl
mnesia_late_loader.erl
mnesia_lib.erl
mnesia_loader.erl
mnesia_locker.erl
mnesia_log.erl
mnesia_monitor.erl
mnesia_recover.erl
mnesia_registry.erl
mnesia_schema.erl
mnesia_snmp_hook.erl
mnesia_snmp_sup.erl
mnesia_sp.erl
mnesia_subscr.erl
mnesia_sup.erl
mnesia_text.erl
mnesia_tm.erl

Здравствуйте, Nuzhny, Вы писали:

N>Откуда такая информация? Анализ результатов трейдерских соревнований говорит, что сейчас рулят стохастические нейросети.

И где твои миллионы?

Тут все очень просто. Как работают реальные нейроны головного мозга науке практически неизвестно. Но ясно одно, каждый нейрон — это отдельная вычислительная еденица. Что не соответствует их компьютерной эмуляции.

Теоретические ратобы в области нейронных вычислений показывают точность предсказаний порядка 50%. Это все равно что кидать монетку или использовать генератор случайных чисел.

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

VD>>Ваши замечательные программы-предсказатели не более чем мошенничество. Программа может помочь проанализировать большие объемы данных и выявить закономерности в прошлых операциях. Но рынок — это живой организм и никто (кроме инсайдеров) не может предсказать его поведения. А ваши замечательные программы просто подгоняются под старые данные, чтобы продать их по лучше. В любой игре нужно что-то большее чем алгоритм. Там нужно чутье и везение. Так что не надо про эти бредни здесь рассказывать.

N>Так ведь и в алгоритмы постоянно меняются. Ни один разумный трейдер не будет 10 лет подряд доверять одному неизменному алгоритму. Мошенников, продающих советников, хватает. Но есть и серьёзные конторы, которые вместе с программой продают абонемент на регулярную корректировку параметров торговой системы в соответствии с коньюктурой рынка.

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

N>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.

Ты еще про гебролайф почитай или еще что-то в этом дуже.

VD>>"мягкого реального времени" — это по русски будет называться система не реального времени

.

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

К тому, что есть реальное время и все остальное. Софт-реалтайм == не реал-тайм. Это замечательный маркетинговый термин.

Здравствуйте, Nuzhny, Вы писали:

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

Кстати, реалтайм-задачи можно решать хоть на скриптах. Это просто распространенное заблуждение, что риалтайм == очень быстро. Риалтайм значит — выполнение за гарантированное время. Скажем любые задачи по кодированию или декодированию видео не реалтайм задачи, так как пропуск одного двух кадров или задержка в работе на несколько миллисекунд не проблема для конечного результата. Главное чтобы картинка была приемлемой. А вот какой-нибудь софт отвечающий за инициацию некого процесса в ответ на поступающие сигналы, может допускать реакцию с задержкой до секунд, но при этом быть реалтайм, так как при превышении этих секунд управляемый им агрегат может просто сдохнуть.

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

В общем, ситуация просто смешная. 99% пишут на С++ черт знает что, но как только у них просят обосновать их выбор они сразу начинаю петь черт знает про что в том числе про риалтайм и каким-то боком причисленным к ниму кодированием видео.

Здравствуйте, FR, Вы писали:

VD>>Это ты о питонистах?

FR>Не знаю, я теперь плюсист

Это тебя жизнь то прижала.

А что делаешь?

Здравствуйте, VladD2, Вы писали:

VD>>>"мягкого реального времени" — это по русски будет называться система не реального времени

.

E>>...Как авторитетно заявил видный специалист в области систем реального времени VladD2.

VD>Ты сам то кроме как обсуждать других что-то еще сам можешь сказать?

Если по теме топика (C++0x vs D), то я уже неоднократно на эту тему высказывался, но могу повторить:
— D, по-моему мнению, не выйдет в мейнстрим. Поскольку его разработчик не заинтересован в том, чтобы язык использовался более-менее прагматичными программистами. Был бы заинтересован, то давно бы озаботился бы стабилизацией языка. В общем, как был он долгостроем, так и останется. Хотя и жалко.
— С++ будет вытеснен из многих сфер, в которых он оказался в 90-х, когда ни C# не было, ни Java не могла с ним конкурировать. Тем не менее, он уже давно достиг стадии бессмертности за счет огромного объема кода, который никто за раз не перепишет, а будут сопровождать и развивать. А выход C++0x сделает жизнь C++ников гораздо лучше.

Так же по теме топика я не согласен ни с теми, кто пропагандирует "modern C++ design", ни с теми, кто от C++ отказывается в пользу C. C++ как C with classes + разумное использование шаблонов -- вот то, чем я пользуюсь сам и требую от подчиненных.

Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.

VD>Если, нет, то просто молчи.

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

VD>Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.

Различие между hard- и soft-real-time заключается в том, что:
— в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
— в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.

Здравствуйте, CreatorCray, Вы писали:

CC>Я про то, что ["как все" и пишут код "как у всех"] — это уже те, кто на шарпе и жабе.

Как не странно — нет. С++ тут как минимум ничем не выделяется.

VD>>И ведь ты как раз предпочел C# для решения тех самых офисных задач?
CC>Не могу сказать что это было именно мое решение. Но для определенного круга офисных задач шарп ИМХО подходит лучше. Тут спорить я не собираюсь. У нас как раз такой круг: одно огромное приложение с которым юзер работает бОльшую часть времени.

Ну, вот видишь? Ты же не стал спорить или увольняться? Значит разделяешь это решение.

Интересно было бы узнать об офисных задачах для которых С++ был бы лучшим выбором. Поделись...

VD>> Не без маразма конечно, но до маразма С++-ных библиотек им все же долеко. К тому же их отличает внятный и логичный интерфейс.
CC>Не всегда. Впрочем каки для других языков. Библиотеки пишут люди.

Не всегда конечно. И именно потому что люди. Но я говорю о закономерности. Даже тот же МС создававшего просто таки чудовищно извращенные АПИ в стиле С и КОМ-а в дотнете таки отошли от "доброй традиции" и стали делать АПИ в которых в большинстве случаев можно разобраться без документации. Хотя дурь и тут бывает. Меня, например, дико "радует" System.IO.* в части перечисления файлов и каталогов. Это же надо было сделать их не итераторами, а массивами? В результате если тебе нужно вывести первые 100 файлов из огромного каталога, то ты вынужден ждать пока ОС не прочтет весь каталог. Но при этом все же АПИ получился понятны, в отличие от того же АПИ Винды.

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

Конечно не все. Но все что видел сразу поднимали у меня этот вопрос. Странно, правда?

VD>>>>А новые ОС пишутся но новых языках.
CC>>>Windows 7 на чем пишут? Вроде ж новая...
VD>>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
CC>Это был подкол, если ты не заметил.
CC>PS. В висте ядро 2003й

Если ты не заметил, то разжовываю. Windows 7 не новая ОС. Там 90% старого кода.

Здравствуйте, VladD2, Вы писали:

VD>Это тебя жизнь то прижала.

Угу, ладно бы еще нормальные плюсы с бустом и вкусными шаблонами, а у меня
C++ Builder

VD>А что делаешь?

Утилиты системные.

Здравствуйте, eao197, Вы писали:

E>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.

Ну, то есть вопрос в инфраструктуре? Причем для С++ ее создали, а вот для другого не получится?

А мне кажется вопрос в головах. Прямые клоны МЛ и Лиспа слишком плохо влезают в голову тех кто способен освоить "С++ с классами"

.

VD>>Если, нет, то просто молчи.

E>Молчал до тех пор, пока маразм не начал переходить все границы.

А маразм — это те случаи когда чужое мнение не совпадает с твоим?

VD>>Лучше иди почитай определение понятия реальное время. Реальное время — это гарантированные задержки. А так называемый софтриалтайм — это фактически их отсутствие. Под софтриалтам обычно понимают не реалтайм софт кторый большую часть времени выдает требуемую производительность.

E>Различие между hard- и soft-real-time заключается в том, что:
E>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.

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

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

E>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.

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

Все разумное о С++ заканчивается на том, что для него таки появились компиляторы с качественной оптимизацией. На этом все. Остальные домыслы про реалтайм и т.п. — это чушь.

Здравствуйте, FR, Вы писали:

VD>>А что делаешь?

FR>Утилиты системные.

Как-то не определенно. А можно более развернутый ответ дать? И зачем для утилит Билдер?

Здравствуйте, eao197, Вы писали:

E>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?)

http://www.sbcl.org/
http://www.cons.org/cmucl/
http://www.cormanlisp.com/

Здравствуйте, VladD2, Вы писали:

VD>Как-то не определенно. А можно более развернутый ответ дать? И зачем для утилит Билдер?

Утилиты разные, всякого рода чистильщики реестра, работа с файловой
системой, дефрагментаторы и тому подобное.
Потому что GUI довольно много и у работодателя есть GUI программисты на этом самом билдере,
и куча унаследованного (часто просто кошмарного) кода на нем.
Я же GUI не пишу, копаюсь в ядре там C++ очень даже на своем месте.

Здравствуйте, VladD2, Вы писали:

VD>Вот этот вопрос главный! И "офисный планктон" тут как раз и рулит как хвост собаков. Дело в том, что большая часть работников гигантов — это тот самый узколобый офисный планктон. Плюс планктон — это основной потребитель. Его проще убить чем переучить на что-то стоящее.
VD>По сему система самораскручивает бездарность и поддерживает экстенсивные средства разработки.

Ну нагородил...

ГВ>>Кроме Singularity, про какие ОС ты ещё можешь рассказать, которые пишутся не на C? Желательно, про те, которые уже продаются или имеют приличные шансы на это. Поскольку иначе ОС есть и на Lisp.
VD>Оберон ОС. Да их куча если покапаться.

И много продано?

VD>Просто в фаворе сейчас Вынь и Линл. И хрен ты что с этим сделаешь все по тем же причинам.

По одной причине: количество накопленного софта. Остальное в таких масштабах не считается.

VD>В общем, все варится в рынке где игроки имеют слишком не равные возможности. Это тормозит прогресс.

Ну не скажи, не скажи. Чарльз Бэббидж создал компьютер, а язык C сделал все компьютеры равными. Не так уж плохо, если разобраться.

Здравствуйте, VladD2, Вы писали:

E>>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?) являются конкурентами C++. В теории -- очень возможно, а вот на практике, с учетом кроссплатформенности, наличия оптимизирующих компиляторов, инструментов разработки/отладки/профилирования, библиотек, обученных профессионалов и пр. -- фигушки.

VD>Ну, то есть вопрос в инфраструктуре?

В очень большой степени -- да.

VD>Причем для С++ ее создали, а вот для другого не получится?

На данный исторический момент меня мало интересует что может быть или почему чего-то не случилось. Проблемы инфраструктуры OCaml или Lisp-ов это проблемы тех, кому эти языки нравятся. Мне, например, OCaml не нравится. В моих условиях (проекты очень приближенные к телекому) реальный выбор можно делать разве что из Java, C++, Eiffel и Ada.

VD>А мне кажется вопрос в головах. Прямые клоны МЛ и Лиспа слишком плохо влезают в голову тех кто способен освоить "С++ с классами"

.

Я боюсь, что "C++ с классами" оказался слишком сложным для тех, кто кичится знаниями ML и Lisp-а.

VD>А маразм — это те случаи когда чужое мнение не совпадает с твоим?

Маразм -- это когда люди говорят, что за использование C++ нужно отрывать руки. Или что soft-real-time не является real-time.

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

Оксюмороны это для тех, кто о реальном времени знает из Wikipedia.

Потоковая трансляция аудио/видео -- это всего лишь одно из применений soft-real-time. В промышленности очень большое количество информационно-измерительных систем, построенных на основе различных SCADA -- это все примеры мягкого реального времени.

VD>Да и реалтайм-софт может с успехом обеспечивать нужные характеристики даже будучи написанным на ВбСкрипте.

Скорее это попытка выдать online обработку за какое-то подобие real-time. В real-time обычным GC в принципе делать нечего, поэтому для JavaRT очень долго пилили специфический GC. А в нормальном real-time динамическая память вообще не используется.

VD>Посему меня по прежнему удивляет зачем сюда притыкают С++.

Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.

VD>И чем он тут может помочь.

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

VD>Остальные домыслы про реалтайм и т.п. — это чушь.

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

Здравствуйте, eao197, Вы писали:

E>Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.

У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.

Здравствуйте, Nuzhny, Вы писали:

N>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.

Видимо до этого он был мультимиллиардер.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Nuzhny, Вы писали:

N>>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.

VD>Видимо до этого он был мультимиллиардер.

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

Здравствуйте, FR, Вы писали:

E>>Поскольку C++ и Ada -- это, пожалуй, единственные высокоуровневые языки, которые позволяют программисту контролировать все издержки. Есть еще C, Oberon, Modula-2 и, вроде как, специальные адаптации Eiffel-я, но они либо ниже уровнем C++ и Ada, либо совсем экзотика. Не могу судить про Forth -- про его использование во встраиваемом ПО я слышал, но не уверен на счет RT.

FR>У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.

Может быть. Никогда не попадались мне статьи о разработке встроенного ПО или RT систем на Форте. Про остальные вышеупомянутые языки читал неоднократно и видел открытые вакансии на разных сайтах (C++, Ada, Modula-2).

О Форте точно знаю со слов одного знакомого, который в московском Sparc-центре писал на Форте BIOS-ы для Sparc-ов. Так что я по поводу Форта не копенгаген, скорее осло

Здравствуйте, VladD2, Вы писали:

VD>И где твои миллионы?

Надо понимать, что игра на Форексе — это мелкие спекуляции, попытка угадать движение "китов" рынка: финансовых воротил, центробанков крупнейших держав, международных корпораций. Т.е. при игре крупными суммами начинается влияние на рынок. Поэтому знания, данные нужны абсолютно другие. Мелкие спекулянты (к которым я и отношусь) и миллионы несовместимы.

VD>Тут все очень просто. Как работают реальные нейроны головного мозга науке практически неизвестно. Но ясно одно, каждый нейрон — это отдельная вычислительная еденица. Что не соответствует их компьютерной эмуляции.

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

VD>Теоретические ратобы в области нейронных вычислений показывают точность предсказаний порядка 50%. Это все равно что кидать монетку или использовать генератор случайных чисел.

Можно пару ссылок на такие работы? Уж больно сенсационно звучит.

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

Гм. Но ведь к тому и идёт. Данные из какого источника тебя бы убедили, что процент автоматических торговых систем постоянно возрастает?

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

Эти два предложения противоречат друг другу. Поэтому мысль твою не уловил.

N>>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.
VD>Ты еще про гебролайф почитай или еще что-то в этом дуже.

М? Ты не веришь информации, выдаваемой поисковиком про этого человека? Информацию из какого источника ты примешь как достоверную?

Здравствуйте, VladD2, Вы писали:

VD>Кстати, реалтайм-задачи можно решать хоть на скриптах. Это просто распространенное заблуждение, что риалтайм == очень быстро. Риалтайм значит — выполнение за гарантированное время.

Тут согласен. Но системы охранного видеонаблюдения всё равно относят к софт-реалтайм. В лаборатории МВД они тестируются на соответствие количеству fps. Редкий пропуск кадров допускается (не помню точно цифры), тут с тобой согласен.
Если интересно, то скажу, что логика верхнего уровня в нашей системе задаётся на скриптовом языке (доступном и для конечных пользователей). Работает быстро, гибко и удобно. Например, по сработке детектора движения надо повернуть камеру, включить прожектор, звуковое оповещение и т.п. Можно и гораздо более сложную логику написать, работать с интерфейсом. Но это не касается критических участков: обработки видео, звука, работы с приёмно-контрольными приборами. И пока все довольны.

Здравствуйте, Erop, Вы писали:

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

Мир не замкнулся на шаблонах, это один из инструментов. Но вот со вторым овладением и появляются некоторые проблемы в некоторых компаниях.

Здравствуйте, VladD2, Вы писали:

VD>Да любой клон МЛ-я или даже компилируемый Лисп.
А зачем? Кодирование в этих задачах не проблема будет. В чём будет выгода от функциональщины?

VD>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.
Ну-ну... Популярная и мощная СУБД, наверное?

Здравствуйте, VladD2, Вы писали:

VD>У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?
VD>Если, нет, то чем занимаешся?

Другими задачами ИИ...
Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего

)

Здравствуйте, alexeiz, Вы писали:

A>В майкрософте не используют не только особо продвинутые инструменты, но и сколько-либо мало-мальски продвинутые инструменты.
Используют, просто не везде.

Поинт 1:

The latter book engendered the Loki library, used in a variety of products, including Windows Vista (see attribution) and some Adobe products (see attribution)…

Пишут фактически на C с классами. Разумеется, наследуются от COM-интерфейсов, кроме них есть несколько базовых классов BaseEncoder, BaseDecoder, BaseBitmap да и все. Иерархии больше двух предков фактически нет.

Из темплейтов есть только один суровый джедайский контейнер DynArray, аналог std::vector, и все. Он настолько суров, что наверное следует сказать о нем пару слов. Он принципиально не зовет никаких конструкторов и никаких деструкторов, хочешь иницалироваться — зови inplace new или делай Init. Копирует, разумеется, тупо память, без всякой пидарасни с copy constructor. Большая часть реализации DynArray — не темплейтная, сам DynArray — ее темплейтный потомок, который только подставляет sizeof(T) базовому классу, практически все инлайнится. Есть вариант темплейта с начальным размером массива, он тогда выделится на стеке. Отличный контейнер, ничего лишнего.
Никаких смартпойнтеров (по мне, кстати, стоило бы).

Нет exceptions, вся обработка ошибок через return и HRESULT.

Здравствуйте, VladD2, Вы писали:

VD>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?

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

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

Здравствуйте, VladD2, Вы писали:

VD>Ты думаешь в терминах С++. Потому и выводы у тебя однобокие.
Вроде обсуждались С++ные функторы...

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

VD>Короче, тебе нужно немного почитать о других мирах.
Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?

Здравствуйте, Erop, Вы писали:

E>Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?

Для C# тоже связка есть.

Здравствуйте, kaa.python, Вы писали:

KP>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).
Кстати, в этом вопросе интересен Adobe. Посмотреть на ASL (Adobe Source Libraries) — высокоуровневый С++: концепты, свойства, gil (generic image library), вошедшая в буст. И линейка продуктов. Работающая. Без крайностей вида HRESULT UIntMult(x,y,&z).

Здравствуйте, byleas, Вы писали:

B>Мир не замкнулся на шаблонах, это один из инструментов. Но вот со вторым овладением и появляются некоторые проблемы в некоторых компаниях.

И так бывает. Но при чём тут тогда функторы?

Здравствуйте, byleas, Вы писали:

E>>Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?

B>Для C# тоже связка есть.

А что? Кто-то смог на "куде" реализовать ГЦ?

Здравствуйте, CreatorCray, Вы писали:

CC>У меня по тестам разница между VC 7.1 и ICC 10.1

Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, VladD2, Вы писали:

VD>Интересно было бы узнать об офисных задачах для которых С++ был бы лучшим выбором. Поделись...
А что такое офисные задачи?
Я думаю твои страхи по поводу C++ сильно преувеличены.
Я вот на C# пишу, рядом люди на C++ пишут, причём то, что было бы уместнее на C# писать
и так большинство их проблем с C++ вообще никак не связано.
Хотя некоторые болезни присущие ему безусловно людям кровь портят.

now playing: SCSI-9 — Waterglide

Здравствуйте, eao197, Вы писали:

FR>>У форта с этим все в порядке он к аппаратуре поближе чем C++ будет.

E>Может быть. Никогда не попадались мне статьи о разработке встроенного ПО или RT систем на Форте. Про остальные вышеупомянутые языки читал неоднократно и видел открытые вакансии на разных сайтах (C++, Ada, Modula-2).

Ну он вообще-то даже создавался для решения именно такой задачи, система управления телескопом.

E>О Форте точно знаю со слов одного знакомого, который в московском Sparc-центре писал на Форте BIOS-ы для Sparc-ов. Так что я по поводу Форта не копенгаген, скорее осло

Я на нем немало пописал, но очень давно, сейчас остались только теплые воспоминания

Здравствуйте, eao197, Вы писали:

E>Скорее это попытка выдать online обработку за какое-то подобие real-time. В real-time обычным GC в принципе делать нечего, поэтому для JavaRT очень долго пилили специфический GC. А в нормальном real-time динамическая память вообще не используется.
На всякий случай намекну, что никакой обязанности выполнять сборку мусора наличие GC не накладывает.
Вполне нормальной практикой, к примеру, является вполне статическое выделение памяти под буфера на этапе инициализации; остатняя часть алгоритма, которая и шарашит в RT, выделениями вообще не занимается. В этом случае GC будет спать, пока его не позовут явно.
Невыделение памяти невовремя можно даже контролировать аналитическими тулзами типа FxCop.

И это — реально применяемая практика. GC, точнее его ограничения, вызывает проблемы не только в RT-системах. Даже в просто высоконагруженных системах с частыми обращениями в натив запиненые буфера вызывают преждевременную фрагментацию памяти; обходится это теми же мерами, что приведены выше.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, eao197, Вы писали:

E>Если по теме топика (C++0x vs D), то я уже неоднократно на эту тему высказывался, но могу повторить:
E>- D, по-моему мнению, не выйдет в мейнстрим. Поскольку его разработчик не заинтересован в том, чтобы язык использовался более-менее прагматичными программистами. Был бы заинтересован, то давно бы озаботился бы стабилизацией языка. В общем, как был он долгостроем, так и останется. Хотя и жалко.
А разве ветка 1.xx не является стабильной ? Там заметных изменений и не появляется. Одно время доверчивых программеров стращали грядущей веткой 3.хх — якобы Брайт при подстрекательстве одиозного Александреску сделает из Д что-то совсем непредставимое.

E>Различие между hard- и soft-real-time заключается в том, что:
E>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
E>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.
Я бы поправил это таким образом : Софт-реалтайм означает, что заданный процент вычислений должен укладываться в заданный квант времени.

Здравствуйте, gandalfgrey, Вы писали:

G>А разве ветка 1.xx не является стабильной ?

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

Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.

G>Одно время доверчивых программеров стращали грядущей веткой 3.хх — якобы Брайт при подстрекательстве одиозного Александреску сделает из Д что-то совсем непредставимое.

Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.

Александреску уже сделал для D2 что-то вроде адаптации C++ного STL (http://www.digitalmars.com/d/2.0/phobos/std_algorithm.html , http://www.digitalmars.com/d/2.0/phobos/std_functional.html). И вообще, после подключения Александреску к разработке D появился очень серьезный крен в сторону поддержки ФП в языке (как раз константность, иммутабельность и pure-функции).

E>>Различие между hard- и soft-real-time заключается в том, что:
E>>- в hard-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны и, что самое важное, неизбежно приходит маленький пушной зверек;
E>>- в soft-RT не попадание в отведенный квант означает, что результаты вычислений нафиг никому уже не нужны, но, что самое важное, маленький пушной зверек не приходит.
E>>Однако, требований по укладыванию вычислений в отведенные кванты никто с soft-RT не снимал. И отсутствие маленького пушного зверька вовсе не означает, что разработка soft-RT гораздо проще hard-RT.
G>Я бы поправил это таким образом : Софт-реалтайм означает, что заданный процент вычислений должен укладываться в заданный квант времени.

Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.

Здравствуйте, VladD2, Вы писали:

VD>>>И ведь ты как раз предпочел C# для решения тех самых офисных задач?
CC>>Не могу сказать что это было именно мое решение.
VD>Ну, вот видишь? Ты же не стал спорить или увольняться? Значит разделяешь это решение.

Я ж не фанатик

VD>Но при этом все же АПИ получился понятны, в отличие от того же АПИ Винды.
По мне так WinAPI достаточно понятен и прост.

Впрочем кому как.

VD>Если ты не заметил, то разжовываю. Windows 7 не новая ОС. Там 90% старого кода.
Новых, чтоб совсем с нуля я в жизни вне тепличных условий вообще не встречал.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, AndrewVK, Вы писали:

CC>>У меня по тестам разница между VC 7.1 и ICC 10.1
AVK>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
7.1 == VC2003.
В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.
Я когда то сравнивал с 2005-й — соотношение было такое же.
Ставить монстра 2008 со всем его .NET-oriented говном чтоб писать на С++ — нафиг нафиг. У меня на работе весь зоопарк стоит, только пишу я тут под С#.
Чисто по работе с кодом 2003я из них самая шустрая.

ICC 10.1 уже относительно старенький
ICC 11.0 — свежий, но из за одного бага в оптимизаторе он VC7.1 на моих тестах как раз на криптухе слил

Но на остальных тестах выиграл даже у 10.1, хотя и немного.
Жду вот, когда они пофиксят багу, чтоб по нормальному уже протестировать.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, eao197, Вы писали:

E>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).
Да, но сам язык уже не меняется.

E>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.
Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

E>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.
Читал на форумах, что собираются паттерн-матчинг присобачить. И сделать, наконец, нормальные тупли !
Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию ( правда, для статически типизированного языка слабо представляю саму возможность этого ) 8))))

E>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.
Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?

VD>>Можно вспомнить СУБД Мнезию (так что ли) написанную на интерпретируемом Эрланге.
E>Ну-ну... Популярная и мощная СУБД, наверное?

Define: популярная
Define: мощная

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

Здравствуйте, CreatorCray, Вы писали:

AVK>>Т.е. сравниваем VC 2002 года выпуска и свежайший еще пару недель назад компилер от Интеля?
CC>7.1 == VC2003.

Я в курсе. RTM был в конце 2002 года.

CC>В общем это не важно. Просто ICC у меня установлен под 2003-ю. Под ней и вся работа идет.

И чего? От этого он оптимизирует на уровне ICC 7.0?

CC>Ставить монстра 2008 со всем его .NET-oriented говном

В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.

CC>ICC 10.1 уже относительно старенький
CC>ICC 11.0 — свежий

Ну понятно, все как я и ожидал — icc возрастом в год старенький, а vc возрастом 6 леи — новье. Больше вопросов нет.

CC>Жду вот, когда они пофиксят багу

Долго ждать будешь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Sinclair, Вы писали:

S> Даже в просто высоконагруженных системах с частыми обращениями в натив запиненые буфера вызывают преждевременную фрагментацию памяти; обходится это теми же мерами, что приведены выше.

В последнем СП предложено решение поинтереснее — можно получить нотификацию о пришествии GC. Это позволяет оповестить load balancer чтобы он не использовал в кластере узел, погруженный в GC.
Ну а в 4.0 обещают GC, который работает парналлельно и практически не использует локов.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Mamut, Вы писали:

M>Define: популярная
В % каких-нибудь не затруднит выразить популярность?

M>Define: мощная
Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...

M>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху
Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...

Скажем мне не нужна зажигалка, на использование которой мне не хватает ума. И прога такая тоже не нужна...

Здравствуйте, AndrewVK, Вы писали:

AVK>Я в курсе. RTM был в конце 2002 года.
AVK>И чего? От этого он оптимизирует на уровне ICC 7.0?
С 2005-й тоже сравнивал, если ты не заметил.

CC>>Ставить монстра 2008 со всем его .NET-oriented говном
AVK>В этом плане 2008 ничем от 2003 не отличается, shell и базовые сервисы те же самые с мелкими багфиксами, ".NET-oriented говно" тебя ставить никто не заставляет. Ситуация немножко изменится только в 2010.
Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

CC>>Жду вот, когда они пофиксят багу
AVK>Долго ждать будешь.
Не думаю. Прошлую (с делением float на 10^х пофиксили довольно быстро)

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>С 2005-й тоже сравнивал, если ты не заметил.

2004 год.

CC>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?

А, религия. Ну тогда ладно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, FR, Вы писали:

FR>Затем что оба в одинаковой ж...

А как в D обстоят дела с интеропом с C++?
Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.
Это довольно странно, ведь D позиционируется как замена C++.
Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Здравствуйте, AndrewVK, Вы писали:

CC>>С 2005-й тоже сравнивал, если ты не заметил.
AVK>2004 год.
2010 еще не вышла.

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.
Т.е. нормальным считается понаставить кучу совершенно ненужного говна?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, AndrewVK, Вы писали:

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.
Вдогон. Ты кстати видел что именно входит в список обязательно устанавливаемого?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, gandalfgrey, Вы писали:

E>>Как раз не соглашусь: hard- отличается от soft- как раз тяжестью последствий. Допустимый процент непопаданий для soft-а -- это уже критерии качества конкретной soft-RT системы при ее приемке.
G>Насчет тяжести последствий : сбор данных о расходе энергии / жидкости / газа — это жесткий или мягкий реалтайм ?

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

По поводу сбора данных -- it depends. Насколько я помню, бывают счетчики с ограниченным диапазоном значений -- не успел вовремя вычитать, он уходит в ноль. Получается, что работа с таким оборудованием -- уже hard RT. Если сбор данных будет сопровождаться каким-то управлением (типа открывания/закрывания задвижек), то опять может быть hard RT (слишком позднее срабатывание задвижки черевато аварией). Если система строится на основе ОС, не предоставляющей hard RT гарантии, то все равно лучше soft RT может ничего не получится. И т.д.

Здравствуйте, gandalfgrey, Вы писали:

E>>Ну типа является (багов в ней еще достаточно осталось, судя по тому, сколько их при каждом минорном релизе фиксится).
G>Да, но сам язык уже не меняется.

E>>Но смысла связываться с 1.* лично я не вижу, т.к. развиваться она уже не будет -- все новое добавляют в 2.*, которая не совместима с 1.*. Т.е. нет смысла что-то делать на 1.* зная, что после выхода 2.* придется переделывать, причем серьезно, т.к. в 2.* есть константность и иммутабельность.
G>Дык ить, кто-то заставляет переходить 1.хх на 2.хх ? Выбор прост : нужно что-то новое — вперед, к ветке 2.хх и дальше. Не надо ничего нового — все устраивает — дык никто ветку 1.хх не закрывал

Ситуация несколько сложнее. Язык версии 1.* вроде как есть и поддерживается пока только одним компилятором DMD на платформах x86 Windows и Linux. Под него существуют некоторые библиотеки. И все. Совершенствованием 1.* больше никто не занимается. Новые библиотеки создаются уже для 2.*. Даже у Tango появилась ветка для D 2.0, хотя сама Tango так до 1.0 пока и не дошла.

Т.е. если сейчас заложиться на диалект 1.* для долгосрочных проектов, то это означает, что в скором времени эти проекты окажутся привязанными к умершей ветке языка с ограниченным количеством инструментов и библиотек. Поскольку я не слышал о том, что кто-то хочет дальше заниматься D 1.0.

E>>Последнее, что я слышал про планы по поводу D -- это выход 2.0 с константностью, иммутабельностью, nothrow и, возможно, pure-функциями осенью этого года. Но пока не слышно. А в D 3.0 собирались добавить синтаксические макросы.
G>Читал на форумах, что собираются паттерн-матчинг присобачить.

Я читаю только news.digitalmars.announce, про паттерн-матчинг не слышал.

G> И сделать, наконец, нормальные тупли !

Тупли там на основе шаблонов. Имхо, более простые в освоении и использовании, чем в C++0x.

G>Я лично еще хочу легковесные изолированные процессы и обмен сообщениями ! А ! Чуть не забыл ! Еще встроенную сериализацию

У вас же есть Erlang, зачем вам что-то еще?

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

К статически-типизированным языкам типа C++/D даже невстроенная сериализация с продвинутыми возможностями приделывается на раз.

Здравствуйте, AndrewVK, Вы писали:

CC>>Он "пререквизиты" все равно пытается ставить в обязательном порядке. Вот нахрена они мне?
AVK>А, религия. Ну тогда ладно.

Вот нафига мне при установке ТОЛЬКО C++ без MSDN.

Document Explorer
Web Authoring
SQL Server Compact + SQL Server Design tools
SDK for .Net framework tools
SDK reference assemblies
SQL publishing Wizard

А оно ставится всегда и без спросу.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Klapaucius, Вы писали:

K>А как в D обстоят дела с интеропом с C++?
K>Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.

Появилась ограниченная подержка C++ http://www.digitalmars.com/d/2.0/cpp_interface.html
Всегда была подержка COM http://www.digitalmars.com/d/2.0/COM.html

K>Это довольно странно, ведь D позиционируется как замена C++.

Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

Учитывая прозрачную связь с си http://www.digitalmars.com/d/2.0/interfaceToC.html и вышенаписанное у D в этом отношении все вполне нормально.
Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.

Здравствуйте, Erop, Вы писали:

VD>>У меня встречный вопрос. Ты сам то хоть одну из этих задач решаешь на работе?
VD>>Если, нет, то чем занимаешся?

E>Другими задачами ИИ...

А, можно подробнее?

E>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего

)

Ага. 640 Кбайт хватит всем (с) Бил Гейтс

Здравствуйте, Klapaucius, Вы писали:

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

Кстати Java библиотеки легко транслируются на D http://www.dsource.org/projects/dwt

Здравствуйте, Erop, Вы писали:

VD>>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?

E>Я разрабатываю настолько сложные алгоритмы, что такие мелкие подробности, на чём же они выражены, являются несущественными подробностями.
E>Недавно мы с двумя подчинёнными писали статью, описывающую один из наших алгоритмов. Написание статьи заняло почти две недели, она содержит доказательства кучи теорем, описание многих экспериментов и т. д. и т. п...

Я правильно понял, что ответ на мой вопрос — "нет"?

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

Как ты можешь судить об удобстве чего-то не попробовав альтернативы?

E>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится

Алгоритмы бывают весьма сложными. Например, алгоритм вывода типов в современном ЯП или алгоритм сжатия данных. Реализовывать их лопатой вроде С++, то реализация будет в десятки (а то и в сотни) раз сложнее спецификации. За тем и нужны более высокоуровневые и удобные языки, чтобы уменьшить разницу между спецификацией и реализацией. Кроме того обычно алгоритмы выражаются не четко и при их реализация почти всегда становится процессом творческим, что опять таки значительно проще осуществить используя удобный, мощный, высокоуровневый язык, нежели ассемблер с классами. Так что твои слова выглядят как хвастовства и бравада. Но понять ты это не сможешь если сам не освоишь хотя бы один более высокоуровневый язык.

Здравствуйте, CreatorCray, Вы писали:

CC>>>С 2005-й тоже сравнивал, если ты не заметил.
AVK>>2004 год.
CC>2010 еще не вышла.

Зато вышла 2008. Примерно в то же время, что и icc 10.1.

AVK>>А, религия. Ну тогда ладно.
CC>Т.е. нормальным считается понаставить кучу совершенно ненужного говна?

Нормальным считается сравнение инструментов одного возраста. А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, CreatorCray, Вы писали:

CC>Вдогон. Ты кстати видел что именно входит в список обязательно устанавливаемого?

Не поверишь — мне пофик.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, CreatorCray, Вы писали:

CC>Document Explorer

MSDN Library и внутренняя справка VS.

CC>Web Authoring

Team Suite ставил?

CC>SQL Server Compact + SQL Server Design tools

А разве его нельзя отменить?

CC>SDK for .Net framework tools

Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.

CC>SQL publishing Wizard

Функционал самой студии.

CC>А оно ставится всегда и без спросу.

Ужос просто.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, VladD2, Вы писали:

E>>Другими задачами ИИ...
VD>А, можно подробнее?
Зачем тебе?

E>>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего

)
VD>Ага. 640 Кбайт хватит всем (с) Бил Гейтс

Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
А они, сюрприз-сюрприз -- обычно на С/С++ написанны...

Здравствуйте, AndrewVK, Вы писали:

CC>>Document Explorer
AVK>MSDN Library и внутренняя справка VS.
при установке ТОЛЬКО C++ без MSDN.

CC>>Web Authoring
AVK>Team Suite ставил?
Нет

CC>>SQL Server Compact + SQL Server Design tools
AVK>А разве его нельзя отменить?
Нет

CC>>SDK for .Net framework tools
AVK>Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.
И тем не менее в процессе инсталляции 2008й нечто под таким названием пытается ставиться

CC>>SQL publishing Wizard
AVK>Функционал самой студии.
Зачем он при установке только С++

CC>>А оно ставится всегда и без спросу.
AVK>Ужос просто.
И не говори

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, AndrewVK, Вы писали:

AVK>А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.
Ты читаешь вообще что я пишу?

в 2003-ю у меня поставлен ICC
Что это означает?

Теперь касательно С#
На работе установлены 2003,2005 и 2008
Из них быстрее всех работает 2003я
На ее фоне 2008 — обнять и плакать.
Отладчик в ней чутка поудобнее, да.
Dual Core, 2Gb ram...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

VD>Я правильно понял, что ответ на мой вопрос — "нет"?
Нет, неправильно. Ответ на твой вопрос -- "не важно".

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

VD>Как ты можешь судить об удобстве чего-то не попробовав альтернативы?
Я пробовал разные альтернативы в разных экспериментах. IMHO выигрыш несущественен. Возможно потому, что С++ я знаю очень-очень-очень хорошо, а альтернативы просто знаю. Но я много разных средств разработки использую при проведении экспериментов. Мало того, я использую для некоторых задач языки и средства собственной разработки

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

E>>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится

VD>Алгоритмы бывают весьма сложными. Например, алгоритм вывода типов в современном ЯП или алгоритм сжатия данных. Реализовывать их лопатой вроде С++, то реализация будет в десятки (а то и в сотни) раз сложнее спецификации. За тем и нужны более высокоуровневые и удобные языки, чтобы уменьшить разницу между спецификацией и реализацией. Кроме того обычно алгоритмы выражаются не четко и при их реализация почти всегда становится процессом творческим, что опять таки значительно проще осуществить используя удобный, мощный, высокоуровневый язык, нежели ассемблер с классами. Так что твои слова выглядят как хвастовства и бравада. Но понять ты это не сможешь если сам не освоишь хотя бы один более высокоуровневый язык.

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

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

Здравствуйте, CreatorCray, Вы писали:

AVK>>MSDN Library и внутренняя справка VS.
CC>при установке ТОЛЬКО C++ без MSDN.

Я болдом выделил.

AVK>>Как такового, отдельного .NET SDK в 2008 студии уже нет, есть Windows SDK 6.0A.
CC>И тем не менее в процессе инсталляции 2008й нечто под таким названием пытается ставиться

Это просто часть инсталляции WIndows SDK.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, CreatorCray, Вы писали:

CC>Вот нафига мне при установке ТОЛЬКО C++ без MSDN.
Всё это безболезненно удаляется после установки студии. А вообще, MS Open Tools (распространение чисто компилятора с либами, как в WDK) никто не отменял, тем более, что новые компиляторы без особых проблем подключаются к "старым" студиям. Или нужна именно свежая студия?

Здравствуйте, CreatorCray, Вы писали:

CC>Из них быстрее всех работает 2003я
Не показатель: vc6 работает ещё быстрее

Но, в принципе, наилучшее соотношение легковесность/функционал в 2к5 с компилятором vc10.

Здравствуйте, VladD2, Вы писали:

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

Дык, дело бывает не в прикладных областях, а технических подробностях реализации неких требований. Кому нафик нужно абстрактная "красота" решения? На выходе коммерческого продукта интересует лишь его качество, которое суть — удовлетворение кошмарному списку требований. Ну не в состоянии платформы типа .Net и Java на сегодня охватить все эти требования (хотя они и охватывают приличную их часть).

Например, сделать макет серверной стороны какого-нить сервиса на TCP — дело нескольких минут на .Net, а заставить адекватно работать затем — просто невозможно из-за нынешней реализации тех же сокетов в .Net, вот народ и пишет прилично кода на С/С++. И дело тут не просто в прослойке, вынужденная ориентация на "обычную память" в таком решении тянет за собой в бездну этой неуправляемой памяти всё приложение. (Тут есть куча тонкостей, могу более технически конкретно указать, почему не прокатывает связь managed/unmanaged наподобии pinned-arrays, и еще о быстрорастущей стоимости пина и падении производительности GC, когда запинненых хаотично в памяти GC объектов под десятки тысяч)

Про обработку массивов данных уже говорил — тут .Net сливает совершенно непотребно, хотя, казалось бы, не требуется оперировать понятиями типа "память" и "процессор". Не хочет никак .Net эффективно обрабатывать массивы информации, ибо не умеет достаточно оптимизировать обращение к массивам (кроме одного практически неиспользуемого простейшего сценария в цикле for).

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

Здравствуйте, VladD2, Вы писали:

VD>Человек выбирающий С# или Java для подобных задач значительно более разумен. А высшие существа и отличается от планктона тем, что могут думать и принимать разумные решения. Другое дело, что есть разные стадии развития. То что человек может понять, что С++ не лучшее средство для офисной автоматизации — еще не означает, что он дальше не выключит мозг и не начнет закидывать задачи буденновками.

Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.

Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java. Можно было бы переиначить фразу: "то, что C# не лучшее вр-во для офисной автоматизации ..." и далее по тексту.

Всего пару раз видел на С++ простейшие обращения к задачам оффиса. Но опять же, ты хоть представляешь, как это делается на С++? Думаешь, там кто-то дёргает COM-интерфейсы или проверяет HRESULT или пишет AddRef/Release? Напиши #pragma import и посмотри на результат.

Я уже молчу о том, что некоторые COM-структуры (не только оффисные) просто не в состоянии лечь на доступную маршаллизацию .Net, и тут без С/С++ просто никак, хотя бы даже в качестве реализаций доступных из .Net обёрток.

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

Интересное утверждение... Пример можно, кроме MFC/ATL?

VD>В Windows 7 ядро Висты, в Висте ядро, ХРюши, в ХРюше ядро 2000-ных, ...
VD>Намек ясен? Ядро как было на С, так и остается. Ну, иногда пара, тройка расширений из плеюсов. Но ты никогда не дождешся, чтобы в ОС экспортировался интерфейс на С++.

Валялся... и бинарное устройство COM-интерфейсов вовсе не из С++ сложилось, и все новые API виндов вовсе не в COM-виде идут... Ты, Влад, малость оторвался от реальности.

Здравствуйте, eao197, Вы писали:

E>По поводу сбора данных -- it depends. Насколько я помню, бывают счетчики с ограниченным диапазоном значений -- не успел вовремя вычитать, он уходит в ноль. Получается, что работа с таким оборудованием -- уже hard RT. Если сбор данных будет сопровождаться каким-то управлением (типа открывания/закрывания задвижек), то опять может быть hard RT (слишком позднее срабатывание задвижки черевато аварией). Если система строится на основе ОС, не предоставляющей hard RT гарантии, то все равно лучше soft RT может ничего не получится. И т.д.
Скажу даже более того — если есть хоть какая-то коммутация ( свитчи там, маршрутизаторы ) то о жестком Реалтайме можно и не заморачиваться. Ну, кроме более других железных решений по совершенно другим ценам.
А управление железом по телемеханике — это мягкий РТ, кроме систем ПАЗ — так там софт вообще не ставят

Здравствуйте, vdimas, Вы писали:

V>Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.

V>Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java.

Каждый читает именно то, что ему хочется. Под офисом здесь понимается именно офис, а не программа МС Офис.

P.S. Офис по русски пишется с одной ф.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, VladD2, Вы писали:

VD>>>Речь шла о преобразовании финансовых данных на биржах, как я понял. Поверить в то, что скажем на Лиспе это было бы сделать в разы проще программист не захотел.

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

бред поскипан.

Никто крутую программу-предсказатель не будет продавать.
Реальные хорошие предсказатели разрабатываются не для продажи, а исключительно для внутреннего использования, чтобы (сюрприз!) зарабатывать деньги.
Причем под жестким NDA.
Это также к вопросу о том, что Nuzhny только один откликнулся.

Здравствуйте, AndrewVK, Вы писали:

AVK>Каждый читает именно то, что ему хочется. Под офисом здесь понимается именно офис, а не программа МС Офис.

Тогда тем более не понимаю. Я ту самую офисную автоматизацию (которая не программа), обычно делал именно с помощью офисных Outlook/Word/Excel/Access+VBA + DCOM/COM+ либы на VB (очччень редко на С++ отдельные компоненты, которые и сейчас бы не стал на C# делать).

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

А если еще взять Exchange/Sharepoint/LDAP/TAPI + новое клиентское SIP-решение в последних офисах + IM + конференции, аппшаринг и пр. (всё c полной COM-автоматицией, + экзотика навроде InfoPath/EDI/HIPPA), то придумать невписываемую в этот круг офисную задачку, претендующую на автоматизацию (не COM-автоматизации, а той, про которую твоя поправка

) — то это палец долго сосать надо, или небо им тыкать... тем более, что упомянута здесь лишь малость из доступного.

Что-то делать на C# — это разве что intranet какой-нить (который никто никогда на С++ и не делал, если вернуться к сути обсуждения), и то, большой еще вопрос, какова должна быть доля browser-based приложений, ибо юзабилити ни в красную армию, да и печатные формы как ни старайся, а такого кач-ва как в MSAccess Report или Word не получишь. Я бы оставил intranet для веб-вервисов и высокоуровневой навигации (тем более, что HTML-страницы ембеддятся в MS Access как родные в привязке к данным из SQL Server, начиная с 2000-о офиса как раз таких сценариев).

AVK>P.S. Офис по русски пишется с одной ф.

С этим согласен.

... << RSDN@Home 1.2.0 alpha rev. 786>>

Здравствуйте, VladD2, Вы писали:

VD>Ну, пусть откликнутся те кто его пишут. Ау... Где вы...

Отказоустойчивая InMemory DBMS пойдет ?

Здравствуйте, FR, Вы писали:

FR>Появилась ограниченная подержка C++ http://www.digitalmars.com/d/2.0/cpp_interface.html

На первый взгляд это выглядит хуже, чем интероп C++ с .NET.

FR>Всегда была подержка COM http://www.digitalmars.com/d/2.0/COM.html

С COM в .NET все достаточно неплохо.

K>>Это довольно странно, ведь D позиционируется как замена C++.
FR>Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

Да я понимаю, что корень проблем не столько в D, сколько в C++ — но проблемы-то это для D.

K>>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.
FR>Учитывая прозрачную связь с си http://www.digitalmars.com/d/2.0/interfaceToC.html и вышенаписанное у D в этом отношении все вполне нормально.
FR>Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Здравствуйте, VladD2, Вы писали:

VD>Не достаточно. Надо чтобы они везде валялись. К тому же по Лиспу нет ни одного хорошего учебника на русском. Это факт.

SICP ?

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>SICP ?

В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, Erop, Вы писали:

VD>>Короче, тебе нужно немного почитать о других мирах.
E>Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?

Давать полезные советы по расширению кругозора?

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

Здравствуйте, Erop, Вы писали:

E>>>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего

)
VD>>Ага. 640 Кбайт хватит всем (с) Бил Гейтс

E>Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
E>А они, сюрприз-сюрприз -- обычно на С/С++ написанны...

Мда, из того что я знаю, db4o (Java), Mnesia (Erlang), CouchDB (Erlang) и даже тут на форуме орел какой-то бегал, на дотнете OODB написал с каким-то хитрым движком на нейросетях внутри.

Здравствуйте, Erop, Вы писали:

VD>>Ты думаешь в терминах С++. Потому и выводы у тебя однобокие.
E>Вроде обсуждались С++ные функторы...

Тема была "C++0X vs D programming lang". Ты бы хоть его изучил. Там нового не много, но по сравнению с С++ и там есть на что посмотреть. Причем еще и мозг рвать не будет.

VD>>Короче, тебе нужно немного почитать о других мирах.
E>Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?

На это тебе товарищь yumi хорошо ответил.

Здравствуйте, Erop, Вы писали:

E>А что? Кто-то смог на "куде" реализовать ГЦ?

А надо?

Здравствуйте, CreatorCray, Вы писали:

CC>в 2003-ю у меня поставлен ICC
CC>Что это означает?

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

CC>Теперь касательно С#
CC>На работе установлены 2003,2005 и 2008
CC>Из них быстрее всех работает 2003я
CC>На ее фоне 2008 — обнять и плакать.
CC>Отладчик в ней чутка поудобнее, да.
CC>Dual Core, 2Gb ram...

Ты С#, что в рамках С# 1.1 используешь?

Здравствуйте, konsoletyper, Вы писали:

K>В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.

Здрасте, Scheme — это диалект Лиспа. Если ты про Common Lisp, то хотя бы Practical Common Lisp (это wiki перевод) загляни. Одно правда, SICP не учебник по Scheme, достаточно за пару вечеров почитать спеку по R5RS, благо всего 50 стр

Здравствуйте, yumi, Вы писали:

Y>Давать полезные советы по расширению кругозора?

Влад почему-то считает, что если я ещё что-то прочитаю, то взгляну на обсуждаемый вопрос как-то иначе. IMHO, таки врядли...

Здравствуйте, VladD2, Вы писали:

VD>Тема была "C++0X vs D programming lang". Ты бы хоть его изучил. Там нового не много, но по сравнению с С++ и там есть на что посмотреть. Причем еще и мозг рвать не будет.

А зачем? И какую именно версию посоветуешь?
Я точно знаю, что D в работе использовать пока не буду, потому, что он непромышленный, во-вервых, и не даёт каких-то принципиальных преимуществ, по сравнению с тем подмножеством С++, которое, IMHO, стоит использовать...
Да, кое-что про D я смотрел. Решил, что мне этот язык не нужен.

E>>Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?

VD>На это тебе товарищь yumi хорошо ответил.

А ты попробуй желать менее назидательным тоном и более конструктивно.
Для справки, я использовал в экспериментах и LISP и PROLOG. (Если не понятно, то "эксперименты" -- это кие-то модельные программы, которые не входят в конечный продукт непосредственно, а используются для проведения каких-то расчётов, или какой-то обработки каких-то данных. Скажем построение максимально запакованного представления всех встречающихся в китайском языке идущих подряд троек (четвёрок и т. д.) иероглифов -- хороший вполне эксперимент. Построенное представление потом, возможно, будет использоваться в коммерческом продукте, а вот код самого "экспиремента" -- нет)
Мало того, у нас используются свои специализированные функциональные языки, которые позволяют декларативно описывать довольно сложные объекты, и потом эти описания компилируются в код, который работает в коммерческих продуктах.
И если коротко подвести под всем этим черту, то самый хороший, понятный и ориентированный на быстрое и удобное решение своего круга задач функциональный язык -- это язык выражений, которые можно писатьв клетках MS Excel. Правда там практически нет возможностей для метапрограммирования, зато многое просто и понятно.

И что? Я же тебе не советую учебник по ёкселю читать, чтобы "быть проще"?
Постарайся вести обсуждение корректно и сожержательно. А так это всё даже не смешно

Здравствуйте, VladD2, Вы писали:

E>>А что? Кто-то смог на "куде" реализовать ГЦ?

VD>А надо?

А как без ГЦ пользоваться С# на КУДЕ?
Или имеется в виду, что код, исполняемый на КУДЕ он С-шный, но может зваться из С#?

Здравствуйте, yumi, Вы писали:

E>>Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
E>>А они, сюрприз-сюрприз -- обычно на С/С++ написанны...

Y>Мда, из того что я знаю, db4o (Java), Mnesia (Erlang), CouchDB (Erlang) и даже тут на форуме орел какой-то бегал, на дотнете OODB написал с каким-то хитрым движком на нейросетях внутри.

А развивать таки лучше что-то типа оракла...

Здравствуйте, Klapaucius, Вы писали:

K>На первый взгляд это выглядит хуже, чем интероп C++ с .NET.

Конечно хуже чем C++/CLI

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

FR>>Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

K>Да я понимаю, что корень проблем не столько в D, сколько в C++ — но проблемы-то это для D.

Это по моему проблема некритичная.

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

Угу, еще и слуха о D 3.0 тоже

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

Здравствуйте, Erop, Вы писали:

E>А как без ГЦ пользоваться С# на КУДЕ?

Оттранслировать ET в команды куды вполне реально. GC внутри видеокарты для этого не нужен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Оттранслировать ET в команды куды вполне реально. GC внутри видеокарты для этого не нужен.

А работать-то как это всё будет? Кто и как освободит ресурсы? И когда?

Здравствуйте, Erop, Вы писали:

E>А зачем? И какую именно версию посоветуешь?

Ну затем чтобы хотя бы увидеть как должны выглядеть шаблоны и compile time вычисления сделанные по человечески

Плюс сейчас D очень шустро двигается в сторону хорошей подержки паралелизма (неизменяемые структуры, чистые функции с гарантиями компилятора и т. п.)
Смотреть конечно же 2.xx

E>Я точно знаю, что D в работе использовать пока не буду, потому, что он непромышленный, во-вервых, и не даёт каких-то принципиальных преимуществ, по сравнению с тем подмножеством С++, которое, IMHO, стоит использовать...
E>Да, кое-что про D я смотрел. Решил, что мне этот язык не нужен.

Для плюсиста по моему смотреть D очень полезно.

Здравствуйте, yumi, Вы писали:

Y>Здравствуйте, Erop, Вы писали:

E>>>>Думаю, при нужде, мог бы порешать и эти (кроме СУБД. Там решать уже нечего

)
VD>>>Ага. 640 Кбайт хватит всем (с) Бил Гейтс

E>>Ну, сейчас, если и развивать СУБД, то лучше из уже имеющейся, работающей системы...
E>>А они, сюрприз-сюрприз -- обычно на С/С++ написанны...

Y>Мда, из того что я знаю, db4o (Java), Mnesia (Erlang), CouchDB (Erlang) и даже тут на форуме орел какой-то бегал, на дотнете OODB написал с каким-то хитрым движком на нейросетях внутри.

Ой не надо поминать шуклина в суе. Если бы ты его поделие увидел тебе было бы смешно

Здравствуйте, konsoletyper, Вы писали:

K>Здравствуйте, Gluk_Kazan, Вы писали:

G_K>>SICP ?

K>В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.

Ага конечно

CL — Лисп на сто пудофф, а схема рылом не вышла

Здравствуйте, Erop, Вы писали:
E>А что? Кто-то смог на "куде" реализовать ГЦ?

GC здесь совершенно ни при чем. Единственное, где в C# играет хоть какой-то GC, это new к референс-типам.
Если мы говорим, к примеру, о методе, который работает только с value-types, то никакого мусора в нём не будет, равно как и сборки мусора.

... << RSDN@Home 1.2.0 alpha rev. 677>>

Здравствуйте, FR, Вы писали:

FR>Ну затем чтобы хотя бы увидеть как должны выглядеть шаблоны и compile time вычисления сделанные по человечески

Так я
1) Много раз видел и то и то.
2) То, что в С++ это сделано неудачно я в курсе. Поэтому и использую ОЧЕНЬ ОГРАНИЧЕНО.
3) На D всё равно коммерческий код писать не буду, по понятным причинам. А всяких велосипедных реализаций CT и продвинутых шаблонов у нас и своих вагон. (Просто пишешь на чём угодно программу, которая исхожник CPP генерит, и в проект включаешь её выполнение

)

FR>Плюс сейчас D очень шустро двигается в сторону хорошей подержки паралелизма (неизменяемые структуры, чистые функции с гарантиями компилятора и т. п.)
FR>Смотреть конечно же 2.xx
Что-то я не верю в "параллелизм за бесплато". IMHO, всё равно корень проблем обычно сидит не в средствах языка, а в архитектуре программы. Так что всё равно надо специально проектировать хорошую параллельную программу. Ну а если ты её удачно запроектировал, то уже и С++ не так уж плох.
Ну придвинется D — почитаем. По мне, так можно уже сейчас "КУДУ" изучить на эту тему, если так уж припекло.

E>>Я точно знаю, что D в работе использовать пока не буду, потому, что он непромышленный, во-вервых, и не даёт каких-то принципиальных преимуществ, по сравнению с тем подмножеством С++, которое, IMHO, стоит использовать...
E>>Да, кое-что про D я смотрел. Решил, что мне этот язык не нужен.

FR>Для плюсиста по моему смотреть D очень полезно.
Ну посмотреть вообще на многое бывает полезно. Я, например, Loki с интересом читал. Но это не значит, что я это буду использовать, хоть бы даже и в экспериментах...

Здравствуйте, Erop, Вы писали:

FR>>Ну затем чтобы хотя бы увидеть как должны выглядеть шаблоны и compile time вычисления сделанные по человечески

E>Так я
E>1) Много раз видел и то и то.

Где?

E>2) То, что в С++ это сделано неудачно я в курсе. Поэтому и использую ОЧЕНЬ ОГРАНИЧЕНО.
E>3) На D всё равно коммерческий код писать не буду, по понятным причинам. А всяких велосипедных реализаций CT и продвинутых шаблонов у нас и своих вагон. (Просто пишешь на чём угодно программу, которая исхожник CPP генерит, и в проект включаешь её выполнение

)

Кодогенератор это совсем другая тема.

FR>>Плюс сейчас D очень шустро двигается в сторону хорошей подержки паралелизма (неизменяемые структуры, чистые функции с гарантиями компилятора и т. п.)
FR>>Смотреть конечно же 2.xx
E>Что-то я не верю в "параллелизм за бесплато". IMHO, всё равно корень проблем обычно сидит не в средствах языка, а в архитектуре программы. Так что всё равно надо специально проектировать хорошую параллельную программу. Ну а если ты её удачно запроектировал, то уже и С++ не так уж плох.

Так никто ни говорит бесплатно.
Но подержка компилятора для этого очень полезна. Кстати в gcc даже есть атрибут pure жаль его в новый стандарт не берут.

Здравствуйте, VladD2, Вы писали:

CC>>в 2003-ю у меня поставлен ICC
CC>>Что это означает?
VD>Что ты рассказами о своих потребностях пытаешся уйти от разговора о сравнении компиляторов разных поколений.
Читай ветку внимательнее.

CC>>Теперь касательно С#
VD>Ты С#, что в рамках С# 1.1 используешь?
А какой смысл грузить старый проект на 1.1 в 2008ю чтобы подредактировать там чуть чуть и пересобрать?
Новые в 2008. Старые — в той, в которой разрабатывались.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

M>>Define: популярная
E>В % каких-нибудь не затруднит выразить популярность?

В процентах от чего?

M>>Define: мощная
E>Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...

Как их сравнивать, если mnesia — не реляционная база данных?

M>>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху
E>Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...

http://gaperton.livejournal.com/7702.html

E>Скажем мне не нужна зажигалка, на использование которой мне не хватает ума. И прога такая тоже не нужна...

Это не значит, что такая зажигалка или прога априори не нжна, не популярна и маломощна

Здравствуйте, Erop, Вы писали:

E>А работать-то как это всё будет?

Так же, как сейчас работает Linq2sql без наличия GC в базе данных.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Mamut, Вы писали:

M>>>Define: популярная
E>>В % каких-нибудь не затруднит выразить популярность?

M>В процентах от чего?

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

M>Как их сравнивать, если mnesia — не реляционная база данных?
Ну тогда она вообще не при делах.

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

M>Это не значит, что такая зажигалка или прога априори не нжна, не популярна и маломощна

Ну это не значит и обратного... А если ей сложно воспользоваться, это веский аргумент и против "нужна" и против "популярна"...

Здравствуйте, FR, Вы писали:

FR>Это по моему проблема некритичная.

Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.

K>>Ну, ломающие изменения и внезапное разделение на две ветки, одна из которых с точки зрения потенциального пользователя выглядит мертвой, а вторая обещает разнообразные переживания из-за своей волнующей нестабильности, популярности не добовляет.
FR>Угу, еще и слуха о D 3.0 тоже

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

Имеется в виду письмо Скальски, в котором он говорит, что у него и Москаля нет времени для работы над компилятором, а сейчас, когда большую часть работы выполняют другие люди — то и мотивации нет?
Но ведь разница-то есть. С одной стороны, развитие, в отличие от D 1, продолжается, а с другой стороны ломающих изменений, в отличие от D 2, практически нет. Немаловажно, что это следствие того, что компилятор написан на разрабатываемом языке, так что с ломающими изменениями особо не развернуться, а не добрая воля разработчиков, которая может и измениться.

Вообще эта, как вы говорите, "политическая ж.." для этих языков имеет совсем разную природу. Проблемы у этих языков разные.
D, как мне кажется, несоизмеримо известнее, но что толку? C++ — программист может подписаться на рассылку и даже обсуждать ломающее изменение месяца на форуме, но будет ли он его использовать?

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Здравствуйте, CreatorCray, Вы писали:

VD>>Что ты рассказами о своих потребностях пытаешся уйти от разговора о сравнении компиляторов разных поколений.
CC>Читай ветку внимательнее.

Очень внимательно читал. Вывод — сравнение не корректно.

CC>>>Теперь касательно С#
VD>>Ты С#, что в рамках С# 1.1 используешь?
CC>А какой смысл грузить старый проект на 1.1 в 2008ю чтобы подредактировать там чуть чуть и пересобрать?
CC>Новые в 2008. Старые — в той, в которой разрабатывались.

А перевести старыне на 3.5-ый фрэймворк SP1 религия не позволяет? Они даже без изменений работать раза в полтора быстрее начали бы. А уж если заменить все ArrayList на List<T>, то можно и в разы выигрыш получить. Плюс надежность увеличить.

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Отказоустойчивая InMemory DBMS пойдет ?

Нет. Так как эта задача с успехом решается даже на интерпритируемом Эрлаге.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gluk_Kazan, Вы писали:

G_K>>Отказоустойчивая InMemory DBMS пойдет ?

VD>Нет. Так как эта задача с успехом решается даже на интерпритируемом Эрлаге.

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

Здравствуйте, achmed, Вы писали:

A>Меня интересуют проекты на python, не могли бы Вы привести ссылку на продукт.
A>Можно по почте.

К сожалению нет в этой отрасли (казуальные игры) большинство продуктов короткоживущие,
могу лишь дать ссылку на http://www.intenium.de/ они во всяком случае в 2006 году делали игры
на питоне, как сейчас не знаю, давно не общался.

Здравствуйте, Klapaucius, Вы писали:

K>Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.

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

K>Имеется в виду письмо Скальски, в котором он говорит, что у него и Москаля нет времени для работы над компилятором, а сейчас, когда большую часть работы выполняют другие люди — то и мотивации нет?
K>Но ведь разница-то есть. С одной стороны, развитие, в отличие от D 1, продолжается, а с другой стороны ломающих изменений, в отличие от D 2, практически нет. Немаловажно, что это следствие того, что компилятор написан на разрабатываемом языке, так что с ломающими изменениями особо не развернуться, а не добрая воля разработчиков, которая может и измениться.

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

K>Вообще эта, как вы говорите, "политическая ж.." для этих языков имеет совсем разную природу. Проблемы у этих языков разные.
K>D, как мне кажется, несоизмеримо известнее, но что толку? C++ — программист может подписаться на рассылку и даже обсуждать ломающее изменение месяца на форуме, но будет ли он его использовать?

Так с Немерле тоже самое, шарпист может зайти на rsdn и обсуждать сколько хочет Немерле, но за очень редким исключением (так же как и почитатель D) использовать для работы язык не станет.

Здравствуйте, VladD2, Вы писали:

VD>А перевести старыне на 3.5-ый фрэймворк SP1 религия не позволяет? Они даже без изменений работать раза в полтора быстрее начали бы. А уж если заменить все ArrayList на List<T>, то можно и в разы выигрыш получить. Плюс надежность увеличить.
Угу, и заодно пофиксить в здоровом (к тому же не нашего авторства) проекте все, что сломается после перехода с 1.1 — уже были случаи.
Там надо было всего то пересобрать его. Какой смысл возиться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

CC>Угу, и заодно пофиксить в здоровом (к тому же не нашего авторства) проекте все, что сломается после перехода с 1.1 — уже были случаи.

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

CC>Там надо было всего то пересобрать его. Какой смысл возиться?

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>

Здравствуйте, Nuzhny, Вы писали:

N>Тут согласен. Но системы охранного видеонаблюдения всё равно относят к софт-реалтайм. В лаборатории МВД они тестируются на соответствие количеству fps. Редкий пропуск кадров допускается (не помню точно цифры), тут с тобой согласен.

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

И писать подобные системы можно хоять на ЯваСкрипте. Высокая производительность требуется только от кода производящего сжатие видио, то есть кодеков. А они уже сто раз написаны и свободно доступны.

N>Если интересно, то скажу, что логика верхнего уровня в нашей системе задаётся на скриптовом языке (доступном и для конечных пользователей). Работает быстро, гибко и удобно. Например, по сработке детектора движения надо повернуть камеру, включить прожектор, звуковое оповещение и т.п. Можно и гораздо более сложную логику написать, работать с интерфейсом. Но это не касается критических участков: обработки видео, звука, работы с приёмно-контрольными приборами. И пока все довольны.

Все что ты описал кроме сжатия без проблем пишется на целом спектре языков в том числе и на Яве с дотнетом. Если вы используете там С++, то вы не более чем занимаетесь усложнением своей задачи. Риалтайма в ваших задачах по любому — 0. Это потоковые задачи и проблемы задержек в них спокойно решаются банальным кэшированием и использованием мощьных современных процессоров. Скажем на 486 машинах подобные задачи вообще решать было нельзя (если конечно не было аппаратного ускорения сжатия).

Здравствуйте, Gluk_Kazan, Вы писали:

G_K>Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?

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

G_K>Влад, за что Вы их так не любите ???

С имеет права на жизнь, так как является высокоуровневым ассемблером. С++ же просто урод. И его использование за пределами мест жизненно требующих низкоуровневых оптимизаций является, на мой взгляд, не оправданным. Конечно если ты Майкрософт и у тебя безбрежные бюджеты на разработку софта, то можно создавать софт самым экстенсивным образом и нанимать тучи обезьян на его тестирование (в прочем не помогает, тот же Ворд уже 12 лет проходится по памяти). Если же задача сложная, а ресурсы ограничены выбор С++ — это идиотизм.

V>Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java. Можно было бы переиначить фразу: "то, что C# не лучшее вр-во для офисной автоматизации ..." и далее по тексту.

Блин, еще один. Влез в разговор не спрося о чем он...

Офис — это не MS Office x.x.x, а здание такое где люди сидят и чем-то заниматся. А его автоматизация — это не написание скриптов к Экселю или Ворду, а разработка софта обеспечивающего автоматизацию деятельности работающего в нем народа.

Вопросы есть?

V>Валялся... и бинарное устройство COM-интерфейсов вовсе не из С++ сложилось, и все новые API виндов вовсе не в COM-виде идут... Ты, Влад, малость оторвался от реальности.

Да кого трогает что у кого там сложилось. Валяйся дальше...

Здравствуйте, yumi, Вы писали:

Y>Здрасте, Scheme — это диалект Лиспа. Если ты про Common Lisp, то хотя бы Practical Common Lisp (это wiki перевод) загляни. Одно правда, SICP не учебник по Scheme, достаточно за пару вечеров почитать спеку по R5RS, благо всего 50 стр

Хорошая ссылка. Но!!!

1. Когда она появилась (на Русском языке)?
2. Где можно купить это произведение в бумажном виде?
3. Почему в списке описания книг (даже у нас, а мы один из самых либеральных сайтов в Рунете) практически нет описаний подобных книг?

В общем, существование информации и реальная ее доступность — это разные вещи. Люди изучают то, что лежит у них перед глазами. А перед глазами лежат учебники по С++, а со всех стороны им говорят, что "С++ — это круто!!!". Собственно сам именно так освоил С++.

Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.

Ну, а как же иначе? Ведь самая передовая контора в области софтостроения для PC — Microsoft в основном писала на С и С++.

Здравствуйте, skeptik_, Вы писали:

_>У меня на руках статистика фрилансерской биржи за все эти годы, и я могу абсолютно уверенно сказать, что Бейсика там никогда и близко не было, и что шарп хотя и начал догонять С++ начиная с 2005 года, но ещё далеко не догнал.

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

_>ЗЫ На немерле там до сих пор нет ни одного проекта.

А, ну — это конечно доказывает, что Неперле нет в природе.

Здравствуйте, VladD2, Вы писали:

VD>Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.

Когда я учился (конец 80 начало 90) были свободно доступны книги по лиспу, прологу и форту, я их изучал и даже сдавал лабораторки.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Gluk_Kazan, Вы писали:

G_K>>Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?

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

Абсолютно идиотская постановка вопроса. Правильнее будет какой класс задая выгодно решать на C++.
И окажется что такой класс задач очень широк и он кстати сильно пересекается например с классом задач которые выгодно решать например на шарпе.
Про деньги и время вы традиционно преувеличиваете преимущества управляемых сред.

G_K>>Влад, за что Вы их так не любите ???

VD>С имеет права на жизнь, так как является высокоуровневым ассемблером. С++ же просто урод. И его использование за пределами мест жизненно требующих низкоуровневых оптимизаций является, на мой взгляд, не оправданным. Конечно если ты Майкрософт и у тебя безбрежные бюджеты на разработку софта, то можно создавать софт самым экстенсивным образом и нанимать тучи обезьян на его тестирование (в прочем не помогает, тот же Ворд уже 12 лет проходится по памяти). Если же задача сложная, а ресурсы ограничены выбор С++ — это идиотизм.

У С++ есть сильное премущество перед си, он позволяет использовать уровни абстракции на си малодоступные.
Полно задач где Си/C++ на своем месте без всякой оптимизации, например как уже писал везде где требуется интенсивное "общение" с ОС.

Здравствуйте, VladD2, Вы писали:

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

VD>И писать подобные системы можно хоять на ЯваСкрипте. Высокая производительность требуется только от кода производящего сжатие видио, то есть кодеков. А они уже сто раз написаны и свободно доступны.

Ты уверен? А как ты на ЯваСкрипте будешь общаться с драйвером устройства захвата (например, PCI и PCI-E платы), писать эти самые драйвера, если их нет? Как будешь делать вывод видео + рисовать на кадрах различные примитивы? Передача видео по сети тоже на скрипте? Поиск видео в сотнях гига/тера байт архива? Детектирование движения, распознавание движущихся объектов, анализ траекторий их движения, поиск и распознавание лиц, работа с кучей внешнего железа по RS232, RS485, USB, ... Продолжать? Скрипты этого не выдержат.

VD>Все что ты описал кроме сжатия без проблем пишется на целом спектре языков в том числе и на Яве с дотнетом. Если вы используете там С++, то вы не более чем занимаетесь усложнением своей задачи. Риалтайма в ваших задачах по любому — 0. Это потоковые задачи и проблемы задержек в них спокойно решаются банальным кэшированием и использованием мощьных современных процессоров. Скажем на 486 машинах подобные задачи вообще решать было нельзя (если конечно не было аппаратного ускорения сжатия).

А если нам надо одновременно обрабатывать 16 видеопотоков с 25 fps разрешением 768х576 (современные PCI-E платы могут выдавать)? Это 500 Мбайт несжатого видео в секунду. Кешировать?

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

Здравствуйте, Nuzhny, Вы писали:

N>Ты уверен? А как ты на ЯваСкрипте будешь общаться с драйвером устройства захвата (например, PCI и PCI-E платы), писать эти самые драйвера, если их нет?

Вот писать драйверы для Виндовс или Линукс — это работа для С с ассемблером. Тут никто спорить не будет.

N>Как будешь делать вывод видео + рисовать на кадрах различные примитивы? Передача видео по сети тоже на скрипте? Поиск видео в сотнях гига/тера байт архива? Детектирование движения, распознавание движущихся объектов, анализ траекторий их движения, поиск и распознавание лиц, работа с кучей внешнего железа по RS232, RS485, USB, ... Продолжать? Скрипты этого не выдержат.

Дык не не все же языки скрипты? Уж С++ тут точно лишний.

N>А если нам надо одновременно обрабатывать 16 видеопотоков с 25 fps разрешением 768х576 (современные PCI-E платы могут выдавать)? Это 500 Мбайт несжатого видео в секунду. Кешировать?

А конкретные цифры тут ничего не значат. Кэш снимает требование к задержкам. А уж размер кэша определяется количеством и продолжительностью задержек. Скацем если мы имеем систему построенную на GC (хреновеньком) который делает раз в 10 секунд сборку мусора продолжительностью 0.005 секунды. То имея кэш всего в несколько мегабайт можно предотвратить потерю кадров.

Я вот почему-то уверен, что ваш софт работает на Виндовс или Линукс (первое более правдоподобно). Обе ОС не дают никаких гарантий реального времени. Потенциально любая из этих ОС может "задуматься" на неопределенное время. Но ваш софт таки (с большой вероятностью) рассчитан именно на эти ОС, а не на Qnx, к примеру. Спрашивается, почему? Да потому, что ваша задача — это не раеалтайм.

Так что ты как и 99% окружающих путаешь быстродействие и реалтайм. За красивым термином "софт-реалтайм" скрывается просто вычислительная задача.

Здравствуйте, FR, Вы писали:

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

FR>Абсолютно идиотская постановка вопроса.

Даже не хочу это обсуждать. Есть постановка, есть ответы.

FR>Правильнее будет какой класс задая выгодно решать на C++.

Если применение С++ не сводится к использованию его в качестве продвинутого С, т.е. переносимого ассемблера, то — никакой.

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

Это чушь.

FR>Про деньги и время вы традиционно преувеличиваете преимущества управляемых сред.

Не они единственные являются альтернативой.

FR>У С++ есть сильное премущество перед си, он позволяет использовать уровни абстракции на си малодоступные.
FR>Полно задач где Си/C++ на своем месте без всякой оптимизации, например как уже писал везде где требуется интенсивное "общение" с ОС.

Как только нужда в абстракциях начинает превалировать над потребностью возиться с битами и указателями, так сразу С++ становится плохим выбором. В общем-то, я согласен, что С++ можно использовать как неплохое расширение С. Только есть две проблемы. 1. Сразу страдает переносимость (но это можно пережить). 2. Мало кто останавливается на этом. Большинство пытается решать высокоуровневые задачи средствами этого низкоуровневого и крайне ограниченного языка.

Здравствуйте, Erop, Вы писали:

VD>>Я правильно понял, что ответ на мой вопрос — "нет"?
E>Нет, неправильно. Ответ на твой вопрос -- "не важно".

На этом можно прекратить обсуждение.

Здравствуйте, FR, Вы писали:

FR>Когда я учился (конец 80 начало 90) были свободно доступны книги по лиспу, прологу и форту, я их изучал и даже сдавал лабораторки.

На русском? Ссылки в студию.

Здравствуйте, VladD2, Вы писали:

FR>>Абсолютно идиотская постановка вопроса.

VD>Даже не хочу это обсуждать. Есть постановка, есть ответы.

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

FR>>Правильнее будет какой класс задая выгодно решать на C++.

VD>Если применение С++ не сводится к использованию его в качестве продвинутого С, т.е. переносимого ассемблера, то — никакой.

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

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

VD>Это чушь.

Это твое ничем ни обоснованное мнение.
Например реально для небольших (с которыми я сейчас имею дело) объемом 50 — 200 тысяч строк приложений, разницы точно нет. Вот если делать их на чистом си, то да трудозатраты будут в пару раз больше.

FR>>Про деньги и время вы традиционно преувеличиваете преимущества управляемых сред.

VD>Не они единственные являются альтернативой.

Угу, но всему свое место и свои задачи.

FR>>У С++ есть сильное премущество перед си, он позволяет использовать уровни абстракции на си малодоступные.
FR>>Полно задач где Си/C++ на своем месте без всякой оптимизации, например как уже писал везде где требуется интенсивное "общение" с ОС.

VD>Как только нужда в абстракциях начинает превалировать над потребностью возиться с битами и указателями, так сразу С++ становится плохим выбором. В общем-то, я согласен, что С++ можно использовать как неплохое расширение С. Только есть две проблемы. 1. Сразу страдает переносимость (но это можно пережить). 2. Мало кто останавливается на этом. Большинство пытается решать высокоуровневые задачи средствами этого низкоуровневого и крайне ограниченного языка.

C++ вполне высокоуровневый язык, например первому шарпу или яве он ничем ни уступает. У него проблема не в уровне а в том что язык слишком переусложнен и слишком неоднозначен.

Здравствуйте, VladD2, Вы писали:

FR>>Когда я учился (конец 80 начало 90) были свободно доступны книги по лиспу, прологу и форту, я их изучал и даже сдавал лабораторки.

VD>На русском? Ссылки в студию.

Я выше выделил, тогда ссылок не было

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

Здравствуйте, AndrewVK, Вы писали:

CC>>Там надо было всего то пересобрать его. Какой смысл возиться?
AVK>Чтобы получить выше производительность и значительно более удобный язык.
Объясняю еще более на пальцах: проект не наш, нам его вообще менять фактически нельзя было. Это серверная часть, к которой надо было написать новую клиентскую. Которая писалась уже под 3.5

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, VladD2, Вы писали:

VD>>>Я правильно понял, что ответ на мой вопрос — "нет"?
E>>Нет, неправильно. Ответ на твой вопрос -- "не важно".

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

Здравствуйте, CreatorCray, Вы писали:

CC>Объясняю еще более на пальцах: проект не наш, нам его вообще менять фактически нельзя было. Это серверная часть, к которой надо было написать новую клиентскую. Которая писалась уже под 3.5

То есть 2008 студия у тебя таки установлена?

... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>

Здравствуйте, AndrewVK, Вы писали:

CC>>Объясняю еще более на пальцах: проект не наш, нам его вообще менять фактически нельзя было. Это серверная часть, к которой надо было написать новую клиентскую. Которая писалась уже под 3.5

AVK>То есть 2008 студия у тебя таки установлена?
Камрад! Ну внимательнее надо быть!

На работе установлены 2003,2005 и 2008

Но на работе я пишу на C#

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, CreatorCray, Вы писали:

AVK>>То есть 2008 студия у тебя таки установлена?
CC>Камрад! Ну внимательнее надо быть!
CC>

CC>На работе установлены 2003,2005 и 2008

Я внимателен. Осталось пояснить, как это сочетается с твоими рассказами, что 2008 студию ты ставить не собираешься, потому что она слишком много лишнего ставит? Напоминаю, все началось с того, что ты обосновал сравнение свежего компилятора интела со страрым компилятором МС отсутствие у себя последнего более свежей версии. Потом оказалось, что ты на 2005 вроде бы пробовал, теперь заявляешь, что 2008 стоже установлена. Ты уж определись в показаниях.

... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>

Здравствуйте, AndrewVK, Вы писали:

AVK>Осталось пояснить, как это сочетается с твоими рассказами, что 2008 студию ты ставить не собираешься, потому что она слишком много лишнего ставит? Напоминаю, все началось с того, что ты обосновал сравнение свежего компилятора интела со страрым компилятором МС отсутствие у себя последнего более свежей версии. Потом оказалось, что ты на 2005 вроде бы пробовал, теперь заявляешь, что 2008 стоже установлена. Ты уж определись в показаниях.

На работе: C# only: 2003,2005,2008. В 2008 установлен только С#.
Не на работе: С++ (ICC): 2003. Ставить 2008 только чтобы сравнить компиляторы — не собираюсь. Для разработки под ICC вообще пофигу какая студия.
ICC vs VC2005 сравнивал еще на старом месте работы. Да и нет никаких проблем скинуть код другу, у которого установлена в данный момент VC2005 и попросить откомпилить.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Егор, ты так бурно реагируешь на мои слова. Я прямо опасаюсь не любовь ли это

Здравствуйте, VladD2, Вы писали:

VD>Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.

Возможно мне повезло больше, но в бытность студентом, как сейчас помню, самостоятельно осваивал финский "Мир Лиспа"
IMHO не лучший учебник, но учебник БЫЛ. Кстати именно в то время была неимоверная моде на Prolog

Здравствуйте, VladD2, Вы писали:

VD>Офис — это не MS Office x.x.x, а здание такое где люди сидят и чем-то заниматся. А его автоматизация — это не написание скриптов к Экселю или Ворду, а разработка софта обеспечивающего автоматизацию деятельности работающего в нем народа.

VD>Вопросы есть?

Угу: Re[12]: C++0X vs D programming lang

V>>Валялся... и бинарное устройство COM-интерфейсов вовсе не из С++ сложилось, и все новые API виндов вовсе не в COM-виде идут... Ты, Влад, малость оторвался от реальности.

VD>Да кого трогает что у кого там сложилось. Валяйся дальше...

Судя по эмоциальным вставкам в тексте, кое-кого трогает

Но ты никогда не дождешся, чтобы в ОС экспортировался интерфейс на С++.

Так вот сейчас практически все новые WinAPI идут именно в виде COM, чья технология опирается на "родные" vtables из С++, а не какого-нить другого инструмента. Даже "типизированные вызовы" методов COM-объектов в VB и в Дельфи были добавлены относительно поздно (относительно возраста COM, разумеется).

... << RSDN@Home 1.2.0 alpha rev. 786>>

Здравствуйте, FR, Вы писали:

FR>Давай другой вопрос зададим:...

Зачем?

Здравствуйте, FR, Вы писали:

FR>Названия книг точно не скажу, но по лиспу был перевод финских авторов, и какие то методички, по прологу книга Братко + еще одна типа "Пролог для микрокомпьютеров" + методичка по турбо прологу, по форту Ноздрунов и еще пара книг авторов уже не помню.

Где все это было, то? Ты в магазины то книжные ходил? Там и сейчас ничего приличного по Лиспу нет. В купе с нечеловеческим синтаксисом выражений — это практически приговор популярности.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Давай другой вопрос зададим:...

VD>Зачем?

Затем чтобы показать что исходный вопрос точно такой же бесмысленный и бестолковый.

Здравствуйте, VladD2, Вы писали:

VD>Егор, ты так бурно реагируешь на мои слова. Я прямо опасаюсь не любовь ли это

.

Ты же вроде как прекратил общение?
Чито же никак не остановишься и пишешь?
А если тебе странна моя реакция, то я тебя разочарую.
Я согласен, что общаться с тобой на тему выбора языка для какой-нибудь задачи бесперспективно.
Ты всё равно всё уже знаешь всё понял и решил все задачи на всех языках и являешься ультимативным спецом в вопросе почему и что и на чём надо писать. Наверное ты уже устроился советником по этому вопросу во все ведущие софтверные корпорации и не мне тебя учить.
Ну а смешно мне потому, что, IMHO, писать что-то вроде: "Ну всё! Я с тобой больше не разговариваю! Даже и не пытайся!" довольно смешно. Особенно если ты мужчина, (хотя тут

, я тебя не видал) так скажем...

Здравствуйте, VladD2, Вы писали:

FR>>Названия книг точно не скажу, но по лиспу был перевод финских авторов, и какие то методички, по прологу книга Братко + еще одна типа "Пролог для микрокомпьютеров" + методичка по турбо прологу, по форту Ноздрунов и еще пара книг авторов уже не помню.

VD>Где все это было, то? Ты в магазины то книжные ходил? Там и сейчас ничего приличного по Лиспу нет. В купе с нечеловеческим синтаксисом выражений — это практически приговор популярности.

Это было в одном большом и другом поменьше сибирском городе, больше 15 лет назад

В том же небольшом городе я купил книгу Братко по прологу и книжки по форту.
Книги по лиспу я брал в библиотеке, лисп меня тогда гораздо меньше интересовал чем форт
и даже чем пролог.
Сейчас же в связи с появлением интернета вообще проблем никаких с литературой нет.

Здравствуйте, VladD2, Вы писали:

VD>Поглядел на ссылку. Перевод не полный и не всегда качественный. Так что это очередная попытка выдать желаемое за действительное.

Блин. Куча народу читала в 80-х — 90-х книжки и по PROLOG и про LISP, а у тебя были какие-то проблемы с искалкой книжек. Я конечно понимаю, что это повод на всю жизнь обидется, но теперь, во времена интеренет-магазинов, это совсем как-то странно выглядит...

Здравствуйте, FR, Вы писали:

FR>Это было в одном большом и другом поменьше сибирском городе, больше 15 лет назад

Кстати, я тоже в большом сибирском городе легко и непринуждённо в "Академ Книге" покупал всю эту литературу в конце 80-х, или самом начале 90-х. Короче "ещё до революции"...

Здравствуйте, Erop, Вы писали:

E>Кстати, я тоже в большом сибирском городе легко и непринуждённо в "Академ Книге" покупал всю эту литературу в конце 80-х, или самом начале 90-х. Короче "ещё до революции"...

Я тоже в это время и там же затаривался

Тогда кстати и в библиотеках даже небольших городков было полно литературы.

Многие жалуются на то, что они вовремя не услышали про языки относящиеся к принципиально другим парадигмам(уж простите за пафосные слова) программирования. Это Лисп, Пролог, Форт и тд. Просто им не повезло и они не там учились и не у тех. Представление о парадигмах это самые азы или база на которой должно быть построено высшее, по крайней мере, образование в области компьютерных наук. Да, я не программирую на Прологе(с которым когда то плотно возился во времена учёбы в ВУЗе, правда был и личный интерес), но эти знания всё время со мной и позволяют глядеть на некоторые задачи принципиально по другому. Например, между императивными языками, типа С++ и языками запросов к базам данных(БД)- пропасть. Для Пролога- это выглядит органично, хотя Пролог не разрабатывался как язык запросов к БД. Даже есть попытки создать на базе Пролога язык запросов к БД- Datalog. И это свойство вытекает не из синтаксиса языка а из парадигмы. Поэтому, когда говорят о новом языке, я всегда смотрю, а есть в нём что-то новое. Все эти споры про С++ и С# в данном контексте просто смешны. Усовершенствования не имеют к "мощности" этих языков никакого отношения. Все эти сборки, CLI и тд- это всё не про то. Вот введение концепции шаблонов в С++ было серьёзным усилением языковых возможностей. Известно, что это- метапрограммирование. Посмотрите как можно ДУМАТЬ с помощью шаблонов у Александреску(http://lib.mexmat.ru/books/8845). И то, я полагаю, что в С++ шаблоны как концепция введены в урезанном виде, потому при их использовании чувствуется некоторая неполнота и досадные ограничения. Всё равно, как это расширило горизонты. Это позволяет думать по другому. Так что, посмотрите вокруг, не зацикливайтесь на императивных языках. Все они одинаковы. if for goto вот их основа.

Кстати, Лисп- один из старейших языков программирования.
интересно почитать
http://chernykh.net/content/view/214/227/1/1/

Здравствуйте, FR, Вы писали:

K>>Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.
FR>Нет, более критично то, что язык никак ни устаканится. Если бы он стабилизировался у него было бы достаточно много пользователей даже если бы интероп с С++ (сишного бы хватило) полностью отсутствовал.

Не уверен. Когда выделили стабильную первую версию, люди, которые жаловались на нестабильность, стали говорить уже о том, что у D 1.0 нет никакого будущего и начинать на нем проект нет смысла, ведь развивается только D 2.0. Например разговоров вроде "У Питона 2.5 нет будущего. Ведь скоро появится Питон 3.0 — пока начинать проект на Питоне рано." мне слышать не приходилось. Питон просто используют для разработки приложений и все.

FR>Конечно разница есть, только популярность от обоих случаев падает.

Важен не результат, а причины, которые приводят к этому результату. Результат один. Причины — различны.
Популярность, кстати, не падает. Ее просто нет.

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

У того, от чьих решений зависит будут ли в языке X ломающие изменения, есть достаточно большой проект на языке X. Если это не сдерживающий фактор — я просто не знаю, что может послужить сдерживающим фактором.

FR>Так с Немерле тоже самое, шарпист может зайти на rsdn и обсуждать сколько хочет Немерле, но за очень редким исключением (так же как и почитатель D) использовать для работы язык не станет.

Непонятно только, почему о существовании D знают, наверное, порядка на два (десятичных) больше программистов, чем о существовании Nemerle, и развивается он на порядок (двоичный) дольше, а исключения как были очень редки — так и остались.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

K>Например разговоров вроде "У Питона 2.5 нет будущего. Ведь скоро появится Питон 3.0 — пока начинать проект на Питоне рано." мне слышать не приходилось. Питон просто используют для разработки приложений и все.

Впрочем, долго ждать заявления "Питон 2.x развиваться не будет, а 3 не нравится, поэтому Питон использовать не будем вообще" не пришлось. Всего-то полчаса.

... << RSDN@Home 1.2.0 alpha 4 rev. 1110>>

Здравствуйте, Erop, Вы писали:

VD>>Поглядел на ссылку. Перевод не полный и не всегда качественный. Так что это очередная попытка выдать желаемое за действительное.

E>Блин. Куча народу читала в 80-х — 90-х книжки и по PROLOG и про LISP, а у тебя были какие-то проблемы с искалкой книжек. Я конечно понимаю, что это повод на всю жизнь обидется, но теперь, во времена интеренет-магазинов, это совсем как-то странно выглядит...

Ты не согласен с моими словами? Обоснуй.

Что до кучи народу, то по тебе лично видно какие (или как) ты книги по Лиспу читал. Книг подобной той что приведена по ссылке на Русский так и не было переведено. Данная попытка до сих пор не закончена. Издать ее в таком виде нельзя.

Здравствуйте, Klapaucius, Вы писали:

K>Не уверен. Когда выделили стабильную первую версию, люди, которые жаловались на нестабильность, стали говорить уже о том, что у D 1.0 нет никакого будущего и начинать на нем проект нет смысла, ведь развивается только D 2.0. Например разговоров вроде "У Питона 2.5 нет будущего. Ведь скоро появится Питон 3.0 — пока начинать проект на Питоне рано." мне слышать не приходилось. Питон просто используют для разработки приложений и все.

Ситуации совсем разные. Когда был анонсирован D 2.0 для D 1.0 практически ничего не было. Да и сейчас проектов для D 1, которые бы прошли версию 1.0 с гулькин нос. Причем многие участники обсуждений D 2 (я имею в виду обсуждения в news-группах digitalmars.d) заявили, что будут делать свои проекты на D 2. Т.е. существующей кодовой базы еще нет, а половина из формирующейся ориентируется сразу на D 2.

У Питона 2.5 уже такой объем существующей кодовой базы и инструментария, что он может существовать совершенно независимо от 3.0.

Здравствуйте, Klapaucius, Вы писали:

K>Не уверен. Когда выделили стабильную первую версию, люди, которые жаловались на нестабильность, стали говорить уже о том, что у D 1.0 нет никакого будущего и начинать на нем проект нет смысла, ведь развивается только D 2.0. Например разговоров вроде "У Питона 2.5 нет будущего. Ведь скоро появится Питон 3.0 — пока начинать проект на Питоне рано." мне слышать не приходилось. Питон просто используют для разработки приложений и все.

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

Python 3.0 (December 3, 2008)
Python 2.6.1 (December 4, 2008)
Python 2.5.2 (February 22, 2008)
Python 2.5.1 (April 18, 2007)
Python 2.4.5 (March 11, 2008)
Python 2.3.7 (March 11, 2008)
Python 2.2.3 (May 30, 2003)
Python 2.1.3 (April 8, 2002)
Python 2.0.1 (June 2001)
Python 1.6.1 (September 2000)
Python 1.5.2 (April 1999)

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

FR>>Конечно разница есть, только популярность от обоих случаев падает.

K>Важен не результат, а причины, которые приводят к этому результату. Результат один. Причины — различны.
K>Популярность, кстати, не падает. Ее просто нет.

Угу, но она могла бы быть

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

K>У того, от чьих решений зависит будут ли в языке X ломающие изменения, есть достаточно большой проект на языке X. Если это не сдерживающий фактор — я просто не знаю, что может послужить сдерживающим фактором.

Просто будут переписаны куски которые ломаются. Так что это может и фактор но точно не гарантия.

FR>>Так с Немерле тоже самое, шарпист может зайти на rsdn и обсуждать сколько хочет Немерле, но за очень редким исключением (так же как и почитатель D) использовать для работы язык не станет.

K>Непонятно только, почему о существовании D знают, наверное, порядка на два (десятичных) больше программистов, чем о существовании Nemerle, и развивается он на порядок (двоичный) дольше, а исключения как были очень редки — так и остались.

Думаешь если о немерле узнает на порядок больше людей что-то изменится?
Я совершенно уверен ничего.

	От:	Аноним
	Дата:	16.11.08 11:22
	Оценка:

	От:	alexeiz
	Дата:	16.11.08 11:25
	Оценка:	+8

	От:	anonim_44ax
	Дата:	16.11.08 11:38
	Оценка:

	От:	Roman Odaisky
	Дата:	16.11.08 11:39
	Оценка:	1 (1) +8 -1

	От:	Mr.Cat
	Дата:	16.11.08 11:41
	Оценка:

От:	kaa.python	РСДН профессионально мёртв и завален ватой.
Дата:	17.11.08 07:06
Оценка:	+2 -2

От:	Didro	home~pages
Дата:	17.11.08 15:42
Оценка:	+1 -3

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	17.11.08 16:25
Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	17.11.08 16:28
Оценка:	+3

	От:	MescalitoPeyot
	Дата:	17.11.08 20:09
	Оценка:	+1 -1

От:	VladD2	www.nemerle.org
Дата:	17.11.08 22:20
Оценка:	-2

От:	Pzz	https://github.com/alexpevzner
Дата:	18.11.08 02:35
Оценка:	-2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	18.11.08 02:55
Оценка:

	От:	CreatorCray
	Дата:	18.11.08 10:19
	Оценка:	+1 -1

От:	nikov	http://www.linkedin.com/in/nikov
Дата:	18.11.08 18:24
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	18.11.08 19:49
Оценка:

От:	cadet354	my twitter
Дата:	19.11.08 15:01
Оценка:

От:	Nuzhny	https://github.com/Nuzhny007
Дата:	19.11.08 20:06
Оценка:	42 (3) +9

От:	eao197	http://eao197.blogspot.com
Дата:	20.11.08 13:54
Оценка:	+3

От:	Курилка	http://kirya.narod.ru/
Дата:	20.11.08 15:50
Оценка:	6 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	21.11.08 04:44
Оценка:

От:	Mamut	http://dmitriid.com
Дата:	21.11.08 10:04
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	25.11.08 04:15
Оценка:

От:	konsoletyper	https://github.com/konsoletyper
Дата:	25.11.08 14:49
Оценка:	+1

От:	achmed	https://www.linkedin.com/in/nail-achmedzhanov-9907188/
Дата:	01.12.08 21:19
Оценка:

От:	thesz	http://thesz.livejournal.com
Дата:	11.12.08 17:20
Оценка: