Я считаю, что такие языки программирования, как 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