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

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

>дайте пожалуйста определение надёжности языка программирования и методики для численной оценки этой велечины... а теперь по существу дела :)

А не заняться ли тебе ликбезом?

>А не заняться ли тебе ликбезом?

как только наркомом просвещения сделают, так сразу

p.s. можно гуглить по теме надёжность программного обеспечения, там даже есть формулы

>"Overall, most projects used more than one language."

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

> Ха-ха. А кто, интересно, будет разрабатывать компиляторы и интерпретаторы байткода этих "безопасных языков"? Или байткод интерпретатора будет исполнять байткод приложения?

ну вобщем-то не долго до этого осталось см. http://jikesrvm.org/

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

ну только идиоты на ЛОРе могут думать, что копилятор Sun написан не на Java

> http://qdtechnology.com/ C++. Boost MetaProgramming Library (Boost.MPL), Boost.Fusion, Boost.Thread, Boost.FileSystem, Boost.StateMachine, Boost.Interprocess, Boost.MPI. Концепты Александреску и ФЯП'а. Мемоизированные санки. Паттерн-матчинг зависимых типов. И всё на С++. Вся СУБД. Гуйня на жабе (<1% проекта, как легко догадаться). Рвёт MSSQL/Oracle, поддерживает синтаксисы обоих.

ну только ЛОРовец может увидеть здесь крутые преимущества в использовании С++ и не увидеть фразу "absence of any interaction with a server", которая делает абсудным сравнение ЭТОГО с Ораклом

Надо же... Как мило. Быдлокодерство всё-таки не захватило мир! Это почти счастье.

ЗЫ: перлпитонгавно

Настолько не любите питон, что пробелами совсем-совсем не пользуетесь?

>ЗЫ: перлпитонгавно
Это вы их с жопы нюхаете, что какбы намекает...

как-бы на Си писать гуйню - глупо.

> но вот макросы лиспа - это другое дело)

ты еще с макросами ворда сравни

> Ну а это совсем унылый троллинг...

это отсутствие чувства юмора, или вам только петросян понятен?

>ты еще с макросами ворда сравни

И что ж ты этим хотел сказать?.. Это как-бы не отменяет того факта, что макросы С бесполезны. Именно поэтому их убрали в D.

>это отсутствие чувства юмора, или вам только петросян понятен?

Это троллинг... Как ты его не называй, но это - троллинг.

> "защита от дурака" - такое годится? Чтобы без указателей (а то программер не туда ещё запишет), с сборкой мусора (а то забудет память освободить), и как меньше возможностей писать в разных стилях (это уже про C++).

Ага. Понял. 'Безопасные' языки предназначены для .. дураков! Напоминаю, сделай систему для дураков, и только дурак и будет ей пользоваться.

> Ну и лучше всего, чтобы не было работы с файлами в произвольной директории (а то поудаляют ещё системные файлы), сокетами (DOS атаки etc)...

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

> Вобщем, JavaScript в браузере выглядит более-менее безопасным - если отключить ещё ряд вещей в браузере (всплывающие окна etc).

А какое отношение имеет безопасность браузера к языкам программирования?

Автор, пиши еще!

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

Вот именно это и есть красноглазый подход. Взгляд с Олимпа, так сказать. Поэтому и пишутся программы на безопасных языках (ибо круто), которые не выдерживают никакого сравнения ни по производительности, ни по системным требованиям с нормальными C/C++ программами.

Сравните, к примеру, Azureus и ktorrent. KTorrent работает быстрее, меньше занимает процессор, а уж по обьему занятой памяти - разница раз в 5-6. Поэтому-то прекрасно написанный Azureus и не задержался у меня на десктопе. С какой радости я буду мириться с постоянной потерей 300Mb памяти?

> ну только ЛОРовец может увидеть здесь крутые преимущества в использовании С++ и не увидеть фразу "absence of any interaction with a server", которая делает абсудным сравнение ЭТОГО с Ораклом

Осиль сначала зачем нужна эта СУБД, а потом поговорим =)

> которые не выдерживают никакого сравнения ни по производительности, ни по системным требованиям с нормальными C/C++ программами.

Зато C/C++ программы далеко впереди по переполнениям буфера и утечкам памяти.

>Вот именно это и есть красноглазый подход. Взгляд с Олимпа, так сказать. Поэтому и пишутся программы на безопасных языках (ибо круто), которые не выдерживают никакого сравнения ни по производительности, ни по системным требованиям с нормальными C/C++ программами.

Это есть нормальный подход. Если ты - пользоваьель, не учи программиста, на чем ему писать. Для тебя один критерий - результат. А как он был получен не твое дело. И то что твой скудный умишко связал плохо написаный софт с ЯП, на котором он был написан, ничего не значит. Ты вообще лезешь не туда, куда надо.

>Сравните, к примеру, Azureus и ktorrent. KTorrent работает быстрее, меньше занимает процессор, а уж по обьему занятой памяти - разница раз в 5-6. Поэтому-то прекрасно написанный Azureus и не задержался у меня на десктопе. С какой радости я буду мириться с постоянной потерей 300Mb памяти?

А можно взять MLDonkey, который написан на OCaml(да.. со сборщиком мусора) и работает не медленнее ktorrent.

ЗЫ... и то, что каждая третья прога на С сложнее хеллоу ворлд имеет утечки памяти тебя не волнует?

>> которые не выдерживают никакого сравнения ни по производительности, ни по системным требованиям с нормальными C/C++ программами.

> Зато C/C++ программы далеко впереди по переполнениям буфера и утечкам памяти.

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

А вот ускорить программу на Java или C# до скорости C++ намного труднее.

Фактически, одна проблема подменяется другой. Мне тут в прошлом году надо было сделать обмен с .Net системой в другой компании. Они хотели делать запросы к нашей базе данных. Результат запроса (вместе с необходимым конвертом) - где-то 1Kb. Время запроса в исходной системе, написанной на C#, было 210ms. Я написал то же самое на C++, и время запроса стало 65ms. Догадайся, что сейчас там работает?

>>Сравните, к примеру, Azureus и ktorrent. KTorrent работает быстрее, меньше занимает процессор, а уж по обьему занятой памяти - разница раз в 5-6. Поэтому-то прекрасно написанный Azureus и не задержался у меня на десктопе. С какой радости я буду мириться с постоянной потерей 300Mb памяти?

> Это есть нормальный подход. Если ты - пользоваьель, не учи программиста, на чем ему писать. Для тебя один критерий - результат. А как он был получен не твое дело. И то что твой скудный умишко связал плохо написаный софт с ЯП, на котором он был написан, ничего не значит. Ты вообще лезешь не туда, куда надо.

Мой скудный умишко посмотрел на крутую Java программу, и на такую же на C++, и выбрал ту, которая быстрее работает. А заодно и сделал вывод (в 99й раз), что программы на Java работают медленнее и жрут больше памяти.

Насчет плохо или хорошо написанного софта - это просто демагогия. Хорошо написанный софт на Java или C# работает медленнее и требует больше, чем написанный на C++.

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

> Найти и убрать переполнения буфера и утечки можно valgrind и еще десятком инструментов. Избежать обоих можно, если писать сколь-нибудь правильно.

Почему же до сих пор не убрали даже в крупнейших проектах, таких как Mozilla и Windows? Почему каждую неделю находят новые ошибки переполнения буфера?

>Я написал то же самое на C++, и время запроса стало 65ms. Догадайся, что сейчас там работает?
>HappySquirrel (*) (26.01.2009 5:43:31)

Да к бабке не ходи - что нибудь на Java+JDBC !
И не звизди тут звиздунишка :)

>А не заняться ли тебе ликбезом? >seiken *** (*) (25.01.2009 18:33:15)

Пожалста! В переводе с старо-японского seiken - означает клоун, ну "недомужик" чтоли :)

>Хорошо написанный софт на Java или C# работает медленнее и требует больше, чем написанный на C++.

Eclipse и NetBeans перепиши на C++. Тебе даю я год на эту работу. Быстрее-быстрее.

> Eclipse и NetBeans перепиши на C++. Тебе даю я год на эту работу. Быстрее-быстрее.

Так это, ты уже перечислил на счет оплату за работу?

>Eclipse и NetBeans перепиши на C++.

Нафига это г..но если есть SlickEdit.

180 тыщ велосипедов!!... Увидел бы в реале - упал в обморок! :) гыгы

А серьёзно, статистика просто подтверждает то, что никакие похвалы и понты Сипиписников не уведут нас от простоты и "всевозможности" Си.
Хотя Сям определённо нехватает высокоуровневых идей, тут надо думать в сторону Objective-C и Perl.

С конечно рулит но исследование явно мутное ...

>Так это, ты уже перечислил на счет оплату за работу?

Никаких перечислений! Код открыт. ТоварищЪ будет работать за идею.

> Никаких перечислений! Код открыт. ТоварищЪ будет работать за идею.

О да, программисты сана и айбиэма работали за идею :)

Из исследования вытекло

что оперсорц проекты никакого глобального hi-end (office-killer, super-mega-CRM) не пишут. Утилитки и прочие перделки/полесики/велосибиблиопедики/прочую cmdline хуиту.

Да. На С пишутся крутейшие ядра ОС и СУБД. Все остальное должно писаться на более приспособленных для того языках. Сборка мусора/simple GUI apps - на С++. hi-eng (GUI/Web/Data mining) apps - на Java/Mono/скриптовых ЯП.

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

PS Не хочу сказат что процедурный стиль - говно. Так судят лишь аналитикм ЛОРа :)

> что никакие похвалы и понты Сипиписников

Сипиписник - это звучит гордо !

> у любого DSL проблема в прозрачной интеграции с целевым языком.

и у eDSL тоже?

> А вот ускорить программу на Java или C# до скорости C++ намного труднее.

man gcj, man XDS Ecselsior JET, man Mono AOT -- компиляция как компиляция. То что GC там может проснуться в ответственный момент, правда и действительно не спасает.

> Я написал то же самое на C++, и время запроса стало 65ms.

а сделал бы не "конверт" с XML или что-у-тебя-там -- ещё лучше стало бы.

> это не с TIOBE ли взято? http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

как приложения на ABAP'е вверх ломанулись-то, просто жуть, чем не кони.. это опенсорс такой пошёл?

> и у eDSL тоже?

Тоже, как ни странно

Да что там ABAP!

На рост Logo посмотрите!

А вы - Си да Си..

>> Найти и убрать переполнения буфера и утечки можно valgrind и еще десятком инструментов. Избежать обоих можно, если писать сколь-нибудь правильно.

> Почему же до сих пор не убрали даже в крупнейших проектах, таких как Mozilla и Windows? Почему каждую неделю находят новые ошибки переполнения буфера?

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

>> Eclipse и NetBeans перепиши на C++. Тебе даю я год на эту работу. Быстрее-быстрее.

> Так это, ты уже перечислил на счет оплату за работу?

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

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

>Ха-ха. А кто, интересно, будет разрабатывать компиляторы и интерпретаторы байткода этих "безопасных языков"? Или байткод интерпретатора будет исполнять байткод приложения? :) Или, может быть, эти языки станут настолько юзабельны, что на них можно будет реализовать собственный компилятор?

не знаю на чем написан компилятор C#, но javac написан на java. и вся JVM + JDK могут быть переписаны полностью на java. Только это время и деньги - потому никто заниматься не будет.

Потому же ядро Linux не переписывают на другие языки. А отнють не потому, что С - самый кошерный.

>А вот ускорить программу на Java до скорости C++ намного труднее.

Уже мерялись... java по скорости операций проигрывает только на массивах ибо проверяет вылет за его границы. В большинстве задачь скорость определяется логикой работы приложения, а не набором массивов и общением с ними.

>Фактически, одна проблема подменяется другой. Мне тут в прошлом году надо было сделать обмен с .Net системой в другой компании. Они хотели делать запросы к нашей базе данных. Результат запроса (вместе с необходимым конвертом) - где-то 1Kb. Время запроса в исходной системе, написанной на C#, было 210ms. Я написал то же самое на C++, и время запроса стало 65ms. Догадайся, что сейчас там работает?

Хорошая история. Значит С++ подходил для этой задачи лучше чем .Net / C#. Есть также много историй где java подходит лучше С++ ;)

>Да. На С пишутся крутейшие ядра ОС и СУБД. Все остальное должно писаться на более приспособленных для того языках. Сборка мусора/simple GUI apps - на С++. hi-eng (GUI/Web/Data mining) apps - на Java/Mono/скриптовых ЯП.

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

+1024

>> А вот ускорить программу на Java или C# до скорости C++ намного труднее.

> man gcj, man XDS Ecselsior JET, man Mono AOT -- компиляция как компиляция. То что GC там может проснуться в ответственный момент, правда и действительно не спасает.

использовать GC параллельный с приложением - спасает от остановки приложения очищая память одновременно с приложением + нужно тюнить GC для приложения.

> Ха-ха. А кто, интересно, будет разрабатывать компиляторы и интерпретаторы байткода этих "безопасных языков"? Или байткод интерпретатора будет исполнять байткод приложения? :) Или, может быть, эти языки станут настолько юзабельны, что на них можно будет реализовать собственный компилятор?

VBNC (компилятор MONO Visual Basic) сам на себе и написан и сам себя компилирует.

сходили бы по ссылке, там англиским по белому написано:
С - 47
Java - 28
JS - 20
Perl - 18
PHP - 11

следом Python - 10% и Ruby - 6%

Хотя эта "статистика" полная ерунда

Бывает ложь, наглая ложь, и статистика.