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

MC>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Мэйнстримом будут Java, .NET, Python и т. п.

MC>Nemerle, непременно Nemerle.

Не размахивай красной тряпкой. Сейчас как понабежит стадо розовых слонов!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Какой C? Какой D?

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

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

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

Ответ простой. Мэйн-стримом будет продолжать оставаться подмножество C++, этакий C с классами.

Здравствуйте, Roman Odaisky, Вы писали:
RO>Мэйнстримом будут Java, .NET, Python и т. п.

Nemerle, непременно Nemerle.

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

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

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

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

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

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

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

ЗЫ

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

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

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

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

Realtime audio processing with Lisp

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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.

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

Спили мушку.

Здравствуйте, 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и наше все!

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

B>Viva la C?

Viva проект в срок, с использованием тех ресурсов, которые на данный момент доступны.

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

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

_>>К сожалению, согласен.
E>Почему "к сожалению"?
E>Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.
E>IMHO, майнстрим -- это вообще что-то типа VB было, а теперь дотнет стал
E>Ну да если говорить о приложениях, которые не по месту пишут, то тут майнстрим медленно переползает от чистого С к "С слегка приплюснутому"...
E>Ну так это же от практических нужд идёт-то, так что наверное и хорошо...

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

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

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

G_K>Я так понял, что это автоматом означает, что ее не нужно решать на C или C++ ?

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

G_K>Влад, за что Вы их так не любите ???

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

Здравствуйте, 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 свой собственный есть — бери не хочу. Не берут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А>А может на 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 и привнести в общую среду программирования те самые новые веяния. Другого пути лично я не вижу, а пионерские рассуждения о том, что нужно выкинуть всё и всё переколпакировать лучше оставить пионерам.

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

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

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

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

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

ГВ>У 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 назад.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VD>Я правильно понял, что ответ на мой вопрос — "нет"?
Нет, неправильно. Ответ на твой вопрос -- "не важно".

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

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

E>>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится

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

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

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

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

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

Например, сделать макет серверной стороны какого-нить сервиса на TCP — дело нескольких минут на .Net, а заставить адекватно работать затем — просто невозможно из-за нынешней реализации тех же сокетов в .Net, вот народ и пишет прилично кода на С/С++. И дело тут не просто в прослойке, вынужденная ориентация на "обычную память" в таком решении тянет за собой в бездну этой неуправляемой памяти всё приложение. (Тут есть куча тонкостей, могу более технически конкретно указать, почему не прокатывает связь managed/unmanaged наподобии pinned-arrays, и еще о быстрорастущей стоимости пина и падении производительности GC, когда запинненых хаотично в памяти GC объектов под десятки тысяч)

Про обработку массивов данных уже говорил — тут .Net сливает совершенно непотребно, хотя, казалось бы, не требуется оперировать понятиями типа "память" и "процессор". Не хочет никак .Net эффективно обрабатывать массивы информации, ибо не умеет достаточно оптимизировать обращение к массивам (кроме одного практически неиспользуемого простейшего сценария в цикле for).

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

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

VD>>Короче, тебе нужно немного почитать о других мирах.
E>Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?

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

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

VD>Поглядел на ссылку. Перевод не полный и не всегда качественный. Так что это очередная попытка выдать желаемое за действительное.

Блин. Куча народу читала в 80-х — 90-х книжки и по PROLOG и про LISP, а у тебя были какие-то проблемы с искалкой книжек. Я конечно понимаю, что это повод на всю жизнь обидется, но теперь, во времена интеренет-магазинов, это совсем как-то странно выглядит...

K>Например разговоров вроде "У Питона 2.5 нет будущего. Ведь скоро появится Питон 3.0 — пока начинать проект на Питоне рано." мне слышать не приходилось. Питон просто используют для разработки приложений и все.

Впрочем, долго ждать заявления "Питон 2.x развиваться не будет, а 3 не нравится, поэтому Питон использовать не будем вообще" не пришлось. Всего-то полчаса

Автор: dmz
Дата: 05.12.08

.

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);;

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

Здравствуйте, 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

Здравствуйте, 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>Остальные домыслы про реалтайм и т.п. — это чушь.

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

Здравствуйте, 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. Офис по русски пишется с одной ф.

С этим согласен.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

boost::thread thr(&my_arbitrary_function);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это тебя жизнь то прижала.

А что делаешь?

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

M>Define: популярная
В % каких-нибудь не затруднит выразить популярность?
M>Define: мощная
Тоже интересно бы почитать сранвнение с ораклом, или с MSSQL, хотя бы...

M>

M>Влад правильно заметил, что обычно люди не вижят ничего дальше MSSQL, Orcale и DB2 только потому что они у всех на виду и на слуху
Да ладно. Ты прниводи объективные преимущества, которых люди не видят. Потому, как "прога хорошая, но пользователи слишком тупы, чтобы этим пользоваться" -- это не преимущество, а недостаток... IMHO...

Скажем мне не нужна зажигалка, на использование которой мне не хватает ума. И прога такая тоже не нужна...

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

VD>>Ты представляешь какова разница между проектированием алгоритма на С++ и скажем ОКамле?

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

Я правильно понял, что ответ на мой вопрос — "нет"?

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

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

E>Правда им надо уметь свободно владеть. Для меня сложность кодирования какого-то уже известного алгоритма, представляется чем-то странным. Это же чисто технический вопрос. Он не требует исследований и всегда легко сходится

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

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

CC>>>С 2005-й тоже сравнивал, если ты не заметил.
AVK>>2004 год.
CC>2010 еще не вышла.

Зато вышла 2008. Примерно в то же время, что и icc 10.1.

AVK>>А, религия. Ну тогда ладно.
CC>Т.е. нормальным считается понаставить кучу совершенно ненужного говна?

Нормальным считается сравнение инструментов одного возраста. А уж, учитывая что сейчас ты занимаешься разработкой на C#, твои отмазки про то, что VS 2003 самое оно, выглядят ну очень неубедительно.

Здравствуйте, 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-виде идут... Ты, Влад, малость оторвался от реальности.

Здравствуйте, 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>Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.

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

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

E>А работать-то как это всё будет?

Так же, как сейчас работает Linq2sql без наличия GC в базе данных.

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

VD>Для меня, когда я учился программировать, разных Лиспов практически не существовало. Были С++, хххBase, Паскаль и еще что-то там. Так же все ругали Фортран и Кобол, хотя их я так же видел только на картинках. А вот С++ и С было выше крыши.

Когда я учился (конец 80 начало 90) были свободно доступны книги по лиспу, прологу и форту, я их изучал и даже сдавал лабораторки.

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

N>Ты уверен? А как ты на ЯваСкрипте будешь общаться с драйвером устройства захвата (например, PCI и PCI-E платы), писать эти самые драйвера, если их нет?

Вот писать драйверы для Виндовс или Линукс — это работа для С с ассемблером. Тут никто спорить не будет.

N>Как будешь делать вывод видео + рисовать на кадрах различные примитивы? Передача видео по сети тоже на скрипте? Поиск видео в сотнях гига/тера байт архива? Детектирование движения, распознавание движущихся объектов, анализ траекторий их движения, поиск и распознавание лиц, работа с кучей внешнего железа по RS232, RS485, USB, ... Продолжать? Скрипты этого не выдержат.

Дык не не все же языки скрипты? Уж С++ тут точно лишний.

N>А если нам надо одновременно обрабатывать 16 видеопотоков с 25 fps разрешением 768х576 (современные PCI-E платы могут выдавать)? Это 500 Мбайт несжатого видео в секунду. Кешировать?

А конкретные цифры тут ничего не значат. Кэш снимает требование к задержкам. А уж размер кэша определяется количеством и продолжительностью задержек. Скацем если мы имеем систему построенную на GC (хреновеньком) который делает раз в 10 секунд сборку мусора продолжительностью 0.005 секунды. То имея кэш всего в несколько мегабайт можно предотвратить потерю кадров.

Я вот почему-то уверен, что ваш софт работает на Виндовс или Линукс (первое более правдоподобно). Обе ОС не дают никаких гарантий реального времени. Потенциально любая из этих ОС может "задуматься" на неопределенное время. Но ваш софт таки (с большой вероятностью) рассчитан именно на эти ОС, а не на Qnx, к примеру. Спрашивается, почему? Да потому, что ваша задача — это не раеалтайм.

Так что ты как и 99% окружающих путаешь быстродействие и реалтайм. За красивым термином "софт-реалтайм" скрывается просто вычислительная задача.

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

VD>>Я правильно понял, что ответ на мой вопрос — "нет"?
E>Нет, неправильно. Ответ на твой вопрос -- "не важно".

На этом можно прекратить обсуждение.

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

FR>Названия книг точно не скажу, но по лиспу был перевод финских авторов, и какие то методички, по прологу книга Братко + еще одна типа "Пролог для микрокомпьютеров" + методичка по турбо прологу, по форту Ноздрунов и еще пара книг авторов уже не помню.

Где все это было, то? Ты в магазины то книжные ходил? Там и сейчас ничего приличного по Лиспу нет. В купе с нечеловеческим синтаксисом выражений — это практически приговор популярности.

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

E>Кстати, я тоже в большом сибирском городе легко и непринуждённо в "Академ Книге" покупал всю эту литературу в конце 80-х, или самом начале 90-х. Короче "ещё до революции"...

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

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

E>Так же по теме топика я не согласен, что OCaml (другие компилируемые диалекты ML) или компилируемые варианты Lisp (какие, кстати?)

http://www.sbcl.org/
http://www.cons.org/cmucl/
http://www.cormanlisp.com/

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

VD>Тема была "C++0X vs D programming lang". Ты бы хоть его изучил. Там нового не много, но по сравнению с С++ и там есть на что посмотреть. Причем еще и мозг рвать не будет.

А зачем? И какую именно версию посоветуешь?
Я точно знаю, что D в работе использовать пока не буду, потому, что он непромышленный, во-вервых, и не даёт каких-то принципиальных преимуществ, по сравнению с тем подмножеством С++, которое, IMHO, стоит использовать...
Да, кое-что про D я смотрел. Решил, что мне этот язык не нужен.

E>>Ну это, знаешь что не надо делать, чтобы не узнать куда следует идти?
VD>На это тебе товарищь yumi хорошо ответил

Автор: yumi
Дата: 25.11.08

.

А ты попробуй желать менее назидательным тоном и более конструктивно.
Для справки, я использовал в экспериментах и LISP и PROLOG. (Если не понятно, то "эксперименты" -- это кие-то модельные программы, которые не входят в конечный продукт непосредственно, а используются для проведения каких-то расчётов, или какой-то обработки каких-то данных. Скажем построение максимально запакованного представления всех встречающихся в китайском языке идущих подряд троек (четвёрок и т. д.) иероглифов -- хороший вполне эксперимент. Построенное представление потом, возможно, будет использоваться в коммерческом продукте, а вот код самого "экспиремента" -- нет)
Мало того, у нас используются свои специализированные функциональные языки, которые позволяют декларативно описывать довольно сложные объекты, и потом эти описания компилируются в код, который работает в коммерческих продуктах.
И если коротко подвести под всем этим черту, то самый хороший, понятный и ориентированный на быстрое и удобное решение своего круга задач функциональный язык -- это язык выражений, которые можно писатьв клетках MS Excel. Правда там практически нет возможностей для метапрограммирования, зато многое просто и понятно.
И что? Я же тебе не советую учебник по ёкселю читать, чтобы "быть проще"?
Постарайся вести обсуждение корректно и сожержательно. А так это всё даже не смешно

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

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

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

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

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

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

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

KP>Могут сократить. Могут увеличить. Но, обычно, проект нужен в лучшем случае прямо сейчас. Соответственно как не крути, код должен быть максимально простым, т.к. рассчитывать на то, что все специалисты в компании знают навороченные и сложные инструменты сложно (если конечно не в гугле или майкрософте работаешь).
Кстати, в этом вопросе интересен Adobe. Посмотреть на ASL (Adobe Source Libraries) — высокоуровневый С++: концепты, свойства, gil (generic image library), вошедшая в буст. И линейка продуктов. Работающая. Без крайностей вида HRESULT UIntMult(x,y,&z).

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

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

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

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

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

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

На C# когда на сингулярити пересядем.

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

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

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

Здравствуйте, 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 в этом отношении все вполне нормально.
Ж.. же одинаковая не техническая а политическая, выражающаяся в близкой к нулю популярности обоих инструментов.

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

K>Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем D.

Кстати Java библиотеки легко транслируются на D http://www.dsource.org/projects/dwt

К сожалению, согласен.
На мой взгляд, довольно большое количество компаний зарабатывает свой основной капитал на поддержке существующих и зачастую довольно старых проектов. Часто бывает, что эта поддержка состоит в банальном bug-fixing-е плюс осмотрительное и очень осторожное додавание новых возможностей. В результате проект, либо имеет вид эдакого разношёрстного зверя (там тебе и Си начала 90-х, и MPL с супер-шаблонами), либо превращается в "Си Плюс проект" (это уже не Си, но еще и не С++).

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

_>К сожалению, согласен.
Почему "к сожалению"?
Цель программирования-то не код покруче навернуть, а разработать что-то нужное и полезное.
IMHO, майнстрим -- это вообще что-то типа VB было, а теперь дотнет стал
Ну да если говорить о приложениях, которые не по месту пишут, то тут майнстрим медленно переползает от чистого С к "С слегка приплюснутому"...
Ну так это же от практических нужд идёт-то, так что наверное и хорошо...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pzz>За дело!

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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, про который ты вспомнил, вполне себе пример такой библиотеки.

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

E>>На чём реализовывать будем?
N>Ко всем трем неплохо подходит OCaml.

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

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

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

Здравствуйте, 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>Не надо читать ушибленных лиспом, это трава уровня немерле
Вроде бы в заметке приведены вполне адекватные аргументы (критика) — а уж в лисповом или в немерелевом трансе они явились автору значения не имеет

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

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

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

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

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

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

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

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

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

E>>>На чём реализовывать будем?
N>>Ко всем трем неплохо подходит OCaml.

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

Лет эдак 10.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну нагородил...

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

И много продано?

VD>Просто в фаворе сейчас Вынь и Линл. И хрен ты что с этим сделаешь все по тем же причинам.

По одной причине: количество накопленного софта. Остальное в таких масштабах не считается.

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

Ну не скажи, не скажи. Чарльз Бэббидж создал компьютер, а язык C сделал все компьютеры равными. Не так уж плохо, если разобраться.

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

VD>И где твои миллионы?

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

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

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

VD>Теоретические ратобы в области нейронных вычислений показывают точность предсказаний порядка 50%. Это все равно что кидать монетку или использовать генератор случайных чисел.

Можно пару ссылок на такие работы? Уж больно сенсационно звучит.

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

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

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


Эти два предложения противоречат друг другу. Поэтому мысль твою не уловил.

N>>Если интересно, то почитай про Джеймса Саймонса. Он миллиардер, в его конторе не торгует ни один живой трейдер.
VD>Ты еще про гебролайф почитай или еще что-то в этом дуже.

М? Ты не веришь информации, выдаваемой поисковиком про этого человека? Информацию из какого источника ты примешь как достоверную?

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

E>>Ну и потом, КУДА, она пока что вроде как тока С и С++ поддерживает?
B>Для C# тоже связка есть.

А что? Кто-то смог на "куде" реализовать ГЦ?

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

VD>Интересно было бы узнать об офисных задачах для которых С++ был бы лучшим выбором. Поделись...
А что такое офисные задачи?
Я думаю твои страхи по поводу C++ сильно преувеличены.
Я вот на C# пишу, рядом люди на C++ пишут, причём то, что было бы уместнее на C# писать
и так большинство их проблем с C++ вообще никак не связано.
Хотя некоторые болезни присущие ему безусловно людям кровь портят.

Здравствуйте, 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>Жду вот, когда они пофиксят багу

Долго ждать будешь.

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

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

А как в D обстоят дела с интеропом с C++?
Когда я последний раз интересновался, все было, насколько я помню, не очень радужно — только через C.
Это довольно странно, ведь D позиционируется как замена C++.
Учитывая, что в .NET языках можно использовать библиотеки на C++ благодаря C++/CLI, кое-что написаное на Java, не говоря уже о всех библиотеках для .NET, а .NET библиотеки можно использовать, соотвественно из C++ и худо-бедно из Java, практически любой язык — CLS extender находится в гораздо менее глубокой ж..., как вы выразились, чем 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

А оно ставится всегда и без спросу.

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

V>Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.

V>Влад, её во все времена делали на VB/VBA, и даже сейчас на VB.Net куда как удобней, чем на на C# или тем более на Java.

Каждый читает именно то, что ему хочется. Под офисом здесь понимается именно офис, а не программа МС Офис.

P.S. Офис по русски пишется с одной ф.

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

G_K>SICP ?

В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.

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

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

Мда, из того что я знаю, db4o (Java), Mnesia (Erlang), CouchDB (Erlang) и даже тут на форуме орел какой-то бегал, на дотнете OODB написал с каким-то хитрым движком на нейросетях внутри.

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

K>В SICP — не Lisp а Scheme. На самом деле, хотя идея одна, реализации сильно отличаются (например, Scheme сильнее поощряет ФП). Но это не учебник по Scheme, а учебник по программированию вообще. После его прочтения я много хорошего узнал, но практически не получил реальных знаний для написани чего-то "большого" на Lisp или Scheme.

Здрасте, Scheme — это диалект Лиспа. Если ты про Common Lisp, то хотя бы Practical Common Lisp (это wiki перевод) загляни. Одно правда, SICP не учебник по Scheme, достаточно за пару вечеров почитать спеку по R5RS, благо всего 50 стр

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

K>На первый взгляд это выглядит хуже, чем интероп C++ с .NET.

Конечно хуже чем C++/CLI , но для интеропа во многом вполне достаточно.

FR>>Угу именно как замена, полноценную же подержку C++ можно реализовать только сделав C++ подмножеством D.

K>Да я понимаю, что корень проблем не столько в D, сколько в C++ — но проблемы-то это для D.

Это по моему проблема некритичная.

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

Угу, еще и слуха о D 3.0 тоже
Хотя заявления авторов другого языка о том что они потеряли интерес к своему детищу ничем ни лучше.

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

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

G_K>>Отказоустойчивая InMemory DBMS пойдет ?

VD>Нет. Так как эта задача с успехом решается даже на интерпритируемом Эрлаге.

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

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

K>Хм... А по-моему, для языка Y, позиционирующегося как замена языка X, хороший интероп X с Y и наоборот — это достаточно критично. Но это, конечно, всего лишь мое мнение.

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

K>Имеется в виду письмо Скальски, в котором он говорит, что у него и Москаля нет времени для работы над компилятором, а сейчас, когда большую часть работы выполняют другие люди — то и мотивации нет?
K>Но ведь разница-то есть. С одной стороны, развитие, в отличие от D 1, продолжается, а с другой стороны ломающих изменений, в отличие от D 2, практически нет. Немаловажно, что это следствие того, что компилятор написан на разрабатываемом языке, так что с ломающими изменениями особо не развернуться, а не добрая воля разработчиков, которая может и измениться.

Конечно разница есть, только популярность от обоих случаев падает.
По моему то, что язык пишется на самом себе совершенно не мешает делать ломающие изменения.

K>Вообще эта, как вы говорите, "политическая ж.." для этих языков имеет совсем разную природу. Проблемы у этих языков разные.
K>D, как мне кажется, несоизмеримо известнее, но что толку? C++ — программист может подписаться на рассылку и даже обсуждать ломающее изменение месяца на форуме, но будет ли он его использовать?

Так с Немерле тоже самое, шарпист может зайти на rsdn и обсуждать сколько хочет Немерле, но за очень редким исключением (так же как и почитатель D) использовать для работы язык не станет.

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

V>Не получилось проигнорировать в который раз этот неудачный пример с оффисной автоматизацией.

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 года, но ещё далеко не догнал.

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

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

А, ну — это конечно доказывает, что Неперле нет в природе.

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

Y>Здрасте, Scheme — это диалект Лиспа. Если ты про Common Lisp, то хотя бы Practical Common Lisp (это wiki перевод) загляни. Одно правда, SICP не учебник по Scheme, достаточно за пару вечеров почитать спеку по R5RS, благо всего 50 стр

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