Я считаю, что такие языки программирования, как C++ и Delphi - свое отживают, причина их широкого использования - инерция и большое количество унаследованного кода. Конечно, для системных приложений можно и нужно использовать что-то близкое к железу. Но вот для большинства задач это overkill, сейчас никто не пишет GUI приложения на asm-е, а ведь раньше писали. Ну вот лет через 5, никто не будет писать GUI приложения на таких ЯП, как Си, С++, Delphi. Вместо этого, будущие mainstream приложения будут компилироваться в байт-код какой-нибудь VM. Вот так-то!  
заметьте, я не говорю о таких областях как численные методы, системный софт и тд, тоесть о тех областях, где нужен минимальный memory footprint, либо очень высокая производительность
Но в ответ на это, я всегда слышу одно и то-же, мол все будет тормозить, а С++ это "крута", "патамушта" работает быстро. Хахаха!!! 
BITCHES DON'T KNOW BOUT MY OPTIMIZATION SKILLS
Конечно, компилятор С++ создает более эффективный, нативный код, но тут есть один момент - средний программист просто не умеет писать эффективный код, не понимает как работает железо и тд. Что-бы начать писать приличный плюсовый код, нужно два-три года практики. Что-бы понимать как ваш код работает, нужно намного больше чем просто знание языка. Далеко не все читали What Every Programmer Should Know About Memory. Иногда складывается впечатление, что многие разработчики вообще живут в начале 90х годов и пишут программы, которые должны работать на Pentium PRO с 64х RAM. Я вообще считаю, что делать какие-либо предположения о скорости работы того или иного участка кода до его запуска под профайлером - гадание на кофейной гуще.  
С другой стороны, современные ВМ не требуют от разработчика понимания того, как работает железо, позволяя при этом создавать приложения, имеющие приличную производительность. Код на таких языках как java, c#, scala, etc, намного проще, следовательно в нем проще разобраться, следовательно, в нем проще найти узкие места и оптимизировать.

В общем, я предлагаю такой challenge - выбираем задачу, но только не синтетическую, а достаточно близкую к жизни, вы пишете реализацию на своем "быстром" %favorite language%, а потом я пишу то-же самое на "тормзном" C# или Java, или еще чем-нибудь. Моя реализация отстает по скорости не более чем на 25%, а скорее всего рвет вашу как тузик тряпку xD. Ну и естественно, приложение должно полностью утилизировать современные многоядерные процессоры, а куда без этого?

итак, кто в деле? 

Lazin, 
+1
идеальный вариант - С + что-то высокоуровневое типа Python

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

Lazin,  


Считаю, что серьезным минусом компилируемых в прцессорный код ЯП является их зависимость от конкретного набора инструкций. Что сильно тормозит развитие процессорной индустрии (облом с переходом на IA64, куча костылей для поддержки х86 в AMD64).

Будущее за платформами типа .net и Java.

А на счет скорости, слышал про такие вещи (не знаю насколько правда - не проверял    ):

Реализация интерпретатора Ruby  реализованная на Java ( JRuby ) быстрее родного интерпретатора на Си.
Интерпретатор php реализованный на Java в 4 раза быстрее mod_php (по заверениям производителей   http://caucho.com/resin/doc/quercus.xtp )
 


Это сообщение отредактировал(а) Vasay - 14.12.2009, 13:44

Vasay, лично для меня важнее даже не это, а модульность, настоящая, а не на уровне языка. К примеру, в компилируемой в нативный код программе можно использовать различные библиотеки, компоненты, каждый из которых может испортить стек или кучу. При этом упадет все приложение и не всегда бывает понятно, что и где сломалось на самом деле. Другая сторона медали - ты пишешь библиотеку, которая используется многими клиентами. И в один "прекрасный" момент получаешь crash dump приложения, с ошибкой доступа внутри твоего кода, который просто не может поломаться. И после нескольких часов/дней отладки и многих попыток воспроизвести ситуацию, оказывается что приложение просто портило память, используемую твоей библиотекой.





ну так совсем не интересно, а где-же оппоненты? с кем холиварить????

С моей невысокой колокольни вообще не видно предмета спора    Демагогия о доминировании одного языка над другим присущ в основном делфятникам    Если честно, то серьёзных споров о том, "что лучше" я уже давно не видел. С другой стороны встаёт немного другой вопрос - "зачем мне ява, если те же задачи я могу решить на С++?". Есть ещё и третья - "компилируемые языки скоро вымрут, бугага!". С этим тоже не стоит спорить, ибо если и вымрут, то не во всех областях:



В общем кто как хочет, тот сами знаете что   

LLVM? Что ТС думает по этому поводу? 


Не, не. Низкоуровневый язык - всё что угодно, только не С (в мечтах Oberon, в суровой реальности тот же Go подойдёт). Выше - всё, что угодно только не Python.  Шлак.


И где ты эту модульность увидел?  


Ага, ещё Сталин писал...


В каком месте?  

А вообще, да, как перейдём на новый движок, надо всеми силами плюсистов отдельно оставить на старом.  

По-моему Lazin сегодня исполняет обязанности Капитана. А с Капитаном не поспоришь:).

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

>Не, не. Низкоуровневый язык - всё что угодно, только не С (в мечтах Oberon, в суровой реальности тот же Go подойдёт).

C не нравится в качестве низкоуровнего? Go низкоуровневый? Черт, куда же катится этот мир.

В этом, например

у меня спортивный интерес 

п.с. 

трудно ... может потом придумаю   

Думаю, что раньше люди спорили о месте на жёстком диске, теперь о каких-то долях секунд (http://www.csharphelp.com/archives2/archive458.html) лучше бы думать о возможностях писать "лёгкий" код, ведь я на 100% знаю, что мой нормальный проект в 6000 строк в главном файле может работать быстрее. Создать проект, который будет тормозить на среднестатистическом компьютере не так просто сейчас, если конечно не делать вон тот код сверху тысячу раз.

Это сообщение отредактировал(а) A5uKa - 14.12.2009, 22:29

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


LLVM


все что угодно, только не Oberon 

это был крик души 

  


Это сообщение отредактировал(а) Oxy - 15.12.2009, 00:10

  

всё же число ты как-то узнал.
Думаю время на это затратил не меньше.
А код можно было вообще не писать.

мы же не пишем программы чтобы запускать их один раз  

если на коком-то языке можно написать достаточно быстрые программы, это ещё ничего не означает  

Это сообщение отредактировал(а) Oxy - 15.12.2009, 00:51

Право же вам, батенька, не угодишь.


В суровой реальности Go разве что для серверных приложений подойдёт. Есть твёрдая уверенность, что его низкоуровневые C-like плюшки будут масштабироваться не хуже джавских/питоновских и давать в выхлопе заметное преимущество?
А в моей "комфортной" embedded реальности заявленная производительность в 5-10% от сишной не оставляет Go никаких шансов.

Какое преимущество?

Дык этим и интересуюсь. Например, по 1) скорости работы, 2) потребляемой памяти, 3) вышеупомянутой масштабируемости, 4) простоте и скорости создания приложения.

Напомню, что в язык зашита сборка мусора, инфраструктура на данный момент отсутствует at all, а сам язык ещё развивается, что не способствует созданию на нём промышленного кода.

У тебя её нет.   

зато у меня есть ЧЮ, а у тебя его как видно нет  

Что ж поделать, тот кто начал программировать на C++ лишается души и ЧЮ. Остаётся лишь всепоглощающее сумасшествие.  

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

Это сообщение отредактировал(а) djamshud - 15.12.2009, 10:52

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

Добавлено через 3 минуты и 30 секунд

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

Решение есть. Надо попросить админов сделать зеркало в дельфяцком разделе, тут же прибегут подростки и все тебе объяснят.


На днях осилил кошерный труд Девида Сеппы "Программирование на ADO.NET" в котором он разделяет эффективный и быстрый код. Под быстрым понимается собственно быстрый, под эффективным - удобный для программиста. Понятно - эффективный в данном контексте не есть быстрый, однако код может быть и быстрым, и эффективным. Под .NET тоже надо программировать - а не орать - "ааа тормоза - зачем же я учил C#!!! Две недели под хвост коту!!!". Последнее не плод моей гламурной фантазии, а вполне реальный факт. Недавно вот был такой кстати   

Неси !

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

мне вот нравится структура ASP.NET ... ну а там уже ведь не за бейсик браться >_<

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

>блин, даже не знаю какое слово подобрать

Вы хотели сказать "ненужность"?

после чтения доков boost.python мне показалось что связкой С+Python пользуются только те, кто не знает о boost.python

Добавлено @ 12:17
по теме:

PS: тут в коде где-то ошибка, верхняя частота почему-то получается 1400 =\


Это сообщение отредактировал(а) GoldFinch - 16.12.2009, 12:25

Объясните.

а он того, живет в 91-м 

Больше вопросов нет!    

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

в чем "современность" языка?
язык - это синтаксис+семантика, сделай для С++ компилятор в байт-код, он сразу станет современным?
может несовременность С++ в том что в нем нет сбора мусора?
так есть например D, тоже компилится в нативный код (и .NET и LLVM), и там есть сбор мусора, D современный язык?

может на C# или на Java писать удобнее? Да ниразу. Синтаксис от С недалеко ушел.
вот python например можно в чем-то назвать современным языком, в нем попробовали уйти от операторных скобок и произвольного форматирования кода. Да только это всего лишь небольшой шаг вперед.

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

>Объясните

Всего лишь шутка, игра слов. Наверное стоило смайлик поставить).

Добавлено через 4 минуты и 14 секунд
>а он того, живет в 91-м

Почему же? Ява не нужна на всем протяжении истории:D.

Бедный я..   
Если честно, не понятно, в каком контекста. Да и язык уже далеко не новенький, хотя развивается..

неа

ага


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

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

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

-------

Это сообщение отредактировал(а) Abyx - 16.12.2009, 20:00

http://codepad.org/XoipjOMa
итератор - он и в С++ итератор

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

Добавлено через 13 минут и 56 секунд
наличие в Python нескольких полезных вещей еще не делает его хорошим языком. Взять например JavaScript - в нем много вещей которые сложно реализовать на питоне, и уж тем более на С++. Однако иногда, когда я кодю на js мне хочется некоторые вещи писать на C++
Сейчас есть много языков, и все они в той или иной мере - плохие. Есть много новых языков - но ни один из них не хочется назвать "современным".

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

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

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



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


в конечном итоге - да, но вот сам процесс, есть задачи, которые С++(и не только ему) просто не по зубам, к примеру, ты когда-нибудь видел С++ библиотеку, которая бы позволяла один и тот-же код, выполнять либо на CPU, либо на GPU, либо на CPU используя SIMD расширения? Вот я то-же не видел, а для .NET оно есть, для python - тоже есть.  

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

Это сообщение отредактировал(а) Lazin - 16.12.2009, 21:28

итератор - это итератор. нечто, что позволяет итеративно обойти элементы некоторого составного объекта, 
смотри например паттерн "итератор" у четырех бандитов.
В данном случае, объект - это последовательность Коллатца, математический объект, состоящий из упорядоченных чисел. И итератор этот объект обходит. Так что с абстракцией все в порядке.

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


Библиотека - это исходный код, скомпили ее компилятором который умеет "выполнять либо на CPU, либо на GPU, либо на CPU используя SIMD расширения" - и задача решена. Ничто не мешает компилить С++ в байт код, и потом выполнять его где угодно. В стандарте С++ ничего не сказано про нативную компиляцию, в спецификации С# - про JIT-компиляцию только 1 абзац, никаких требований во что компилить исходник и как его потом выполнять - нет, это языки.

Метапрограммирование - нужно, никакие функции высшего порядка и JIT-компилятор не добавят тебе в язык новую функциональность, тот же yield, если бы его небыло. В С++ же например добавили for each через кучу макросов и шаблонов (boost.foreach).

Это сообщение отредактировал(а) GoldFinch - 16.12.2009, 21:59

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

в некоторых языках программирования, этот самый yield добавлен именно с помощью ФВП, та же последовательность Коллатца, но на F# - 

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

где ты видел компилятор С++, который умеет создавать data parallel код сам, я уже молчу про GPU =) 
проблема в том, что компиляция в С++ - статическая, а многие вещи становятся возможны только в том случае, если компиляция - динамическая
есть плюсовые библиотеки, которые позволяют создавать expression trees (я знаю только boost proto), по идее, на основе expression tree можно сгенирировать код для GPU, но почему-то никто еще это не реализовал  

смысла в этом нет, так-как никаких преимуществ из компиляции в байт код CLR или JVM, язык извлечь не позволит

Добавлено через 6 минут и 44 секунды
у меня есть идея задачи - можно написать программу, которая будет искать в каком-либо каталоге файлы с изображениями, а затем обрабатывать из, к примеру, простым blur-ом на основе матрицы свертки
с одной стороны задача не совсем синтетическая, здесь есть и I/O и вычисления, с другой - здесь нужно обрабатывать достаточно большие массивы данных, поэтому код должен быть достаточно эффективен 

я имел ввиду связку язык+компилятор+средства разработки+библиотеки+документация на все это

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

Чем можно пользоваться? 

всем

Ну что Lazin, ты уже победил C++, положил на обе лопатки?  

Lazin, и что мы возьмём за эталонный набор данных? Нужен достаточно большой объём, чтобы потестить нормально. 

Плюс я предлагаю немного усложнить задачу и добавить scaling изображений и расчёт средних по каналам. 

Это сообщение отредактировал(а) W4FhLF - 18.12.2009, 17:14

IrfanView, пакетная обработка же

так или иначе, в этой задаче победит С++ , т.к. есть boost.GIL

Добавлено через 2 минуты и 44 секунды
алсо что насчет этого поста? 
http://forum.vingrad.ru/index.php?showtopi...t&p=2048366

тут больше тест не на производительность вычислений, а на буферизацию вывода данных

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

Добавлено через 15 секунд
Пункт 2 наверное лишний.

вот только чрезмерно усложнять не стоит, нужно чтобы приложение было не I/O bounded, может лучше взять одно изображение, но достаточно большое?

Ну можно взять штук 5-10 10-14 мегапиксельных снимков. Думаю нормально будет. 

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

Lazin, угу, забили на GPU )

Добавлено через 9 минут и 13 секунд
Хотя идея с GPU мне всё-таки нравится.  

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

http://www.nvidia.ru/object/cuda_learn_products_ru.html

Добавлено через 5 минут и 19 секунд
Единственное, что мы сравнивать будем? Ну напишу я на С модуль для CUDA, вызову его из С++. Ты вызовешь из через PInvoke какой-нибудь. И что дальше?) 

убедил, давай без CUDA  

и? результат какой? где?

Lazin, придумай тест где питон будет сравним по производительности с С++, причем именно питон, а не функции ОС, и не модули расширения на других ЯП

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

О чеm спор? С/С++ будет использоваться в системных компонентах. Кернел на Джаве не напишут. Другое дело использовать С/С++ для всегo остального - пережиток прошлого. Те, кому проще i быстрее писать на С++ просто не знают достаточно хорошо С#/джава. Это скорее их незнание, а не преимущество С++. С++ быстрее? Чушь. Сегодня это реально нe так. А то, что футпринт больше - вообще смех. На наших машинах по 3-4 Гб все бежит нормалек. Зато удобство разработки просто аццкое.
O чеm спорим? Конечно С++ будеt отмирать. Но для системногo программирования оn все еще будет использован. Ну i реалтайм. И т.п.

лол
вообще я думал писать не на питоне, а на java или c#, но на питоне  тоже можно писать быстрый код, к примеру код, моделирующий что-нибудь и использующий для этого NumPy будет довольно сложно побить  

neutrino, речь идет о том, что сложные системы писать на С++ уже не вариант, пока ты напишешь отладишь и протестируешь все на на С++/Си/Pascal - твои конкуренты будут далеко впереди. С другой стороны, никто не спорит, что на С++ можно писать расширения для питона или COM компоненты, которые потом будут дергаться из управляемого кода.

Было. Простая обработка текстового файла. Итог: питон наравне с C++.
90% времени этот тест будет проводить в ядре интерпретатора: операции со строками и словарями.

ты в курсе что NumPy написан на С? 
я же написал, что тест должен сравнивать С++ с питоном, а не С++ с С

вариант "такой-то модуль расширения языка на С\С++\Фортране\еще-каком-то-не-питоне догонит код на С++" - не катит.

Добавлено через 11 минут и 28 секунд

там тема на 6 страниц - все читать лень, 
не нашел там обоснования что основное время работы программ зависит от скорости обработки данных кодом программы, а не скорости чтения\записи файлов ОС.

Что же делать, если и сам интерпретатор пистона написан на "С\С++\Фортране\еще-каком-то-не-питоне"? Тогда вообще сравнивать нечего?

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

Сравни размер обрабатываемого файла и получившееся время. На флопике он лежал, что ли?

Тогда спор лишён смысла.

Void, почему лишен смысла? 
нормальное сравнение ЯП, это когда один и тот же алгоритм реализуется на одном (С++) и на другом языке (питон),
а не на одном языке (С++), и на 99% на третьем (С) - там мы сравниваем другую пару языков

Добавлено через 5 минут и 43 секунды

http://forum.vingrad.ru/index.php?showtopi...t&p=1403408
там нету единиц измерения времени, я хз, был там флопик или нет. 
в любом случае, если мерять какой-то алгоритм - то не надо мерять время чтения\записи файла.

Это сообщение отредактировал(а) GoldFinch - 7.1.2010, 16:33

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

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

Юпитерианские сутки, что же ещё?

А если ввод-вывод идёт вперемежку с вычислениями? А если весь ввод-вывод заключается в печати одной строки? Если ты минимально вчитывался в условие задачи, ты прекрасно себе представляешь соотношение ввода-вывода и прочих затрат при её исполнении, и что time $command — это адекватный способ замера.

Т.е. я правильно делаю, что пытаюсь изучать джаву?

Пока ты тут в очередной раз хоронишь Delphi и С++ (а некоторые утверждают, что это "похороны" длятся уже лет 10), на sql.ru уже на полном серьезе обсудили тему перспективы Java. До конца я не дочитал, но где-то в середине джаву на полном серьезе кто-то пытался хоронить   


Вот тебе практическая задача: перепиши Open Office Calc (он же на java написан?), чтобы он не отставал по производительности от Excel (он же на С написан?) намного более, чем на 25%. Куча благодарных потомков тебе обеспечена. Ну а пока в плане скорости и юзабилити OO - полное УГ.

Нет. На ++. Тут список того, что в OpenOffice.org написано на Java. Не веришь - скачай сорцы.


Вот уж не думаю. Тоже на ++, стоит думать.


Тупой пример. Ты тогда должен написать тулзу по скорости сравнимую с MS Office.

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

Хочешь померяться - ради бога (только Lazin'а найди). А ребят из MS не приплетай. Не о них речь.

Верю. Я в историю вопроса не влезал, просто такое впечатление сложилось, что OO написан на java.

Это не важно, С++ Lazin тоже хоронит.

Я - ни в коем случае не хочу ничем ни с кем меряться. Просто Lazin утверждал, что может писать эффективный код, и просил пример задачи из жизни. Ну вот пусть и уделает M$ на самой что ни на есть жизненной задаче, раз уж ему известны секреты эффективного написания алгоритмов.