LINUX.ORG.RU
 
NonHuman

"С" преобладает в открытых проектах, начатых в 2008 году


0

0

"С" был значительно популярнее всех остальных языков программирования в 2008 году с 48%.
Следом идут Java(28), Javascript(20), Perl(18).
PHP получила 11%. И это несмотря на огромную популярность PHP среди лоровцев и среди создателей домашних страничек.
Пятое место за Ruby с 6%. Хотя язык и завоевал огромную популярность в новостях и книжных издательствах, но это не помогло в создании новых проектов на этом языке.

Информация получена от 180000 проектов с почти 4000 сайтов.

>>> C dominated 2008's open-source project nursery. PHP and Ruby poor showing


[#]  

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

* ()
seiken

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

*** ()
dimon555

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

***** ()
[#] Ответ на: Re: Мыши плакали, кололись... от anonymous 24.01.2009 17:52:56  

Re: Мыши плакали, кололись...

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

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

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

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

anonymous ()
[#] Ответ на: Re: от anonymous 24.01.2009 23:18:18  

Re:

> 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", которая делает абсудным сравнение ЭТОГО с Ораклом

anonymous ()
[#]  
xawari

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

()
[#]  
Waterlaz

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

** ()

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

anonymous ()
Waterlaz

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

** ()
HappySquirrel

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

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

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

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

* ()
HappySquirrel

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

* ()
[#] Ответ на: Re: от anonymous 25.01.2009 21:41:18  

Re:

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

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

anonymous ()
Nxx

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

***** ()
Waterlaz

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

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

** ()
HappySquirrel

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

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

* ()
HappySquirrel

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

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

* ()
Nxx

Re:

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

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

***** ()

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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


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

anonymous ()

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

anonymous ()
iZEN

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

***** ()
a3

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

* ()
[#]  
matumba

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

**** ()
[#]  
cvv

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

***** ()
a3

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

* ()
[#]  

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

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

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

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

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

anonymous ()
[#]  

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

***** ()
[#] Ответ на: Re: от anonymous 24.01.2009 23:18:18  

Re:

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

и у eDSL тоже?

anonymous ()

Re:

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

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

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

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

anonymous ()
[#] Ответ на: Re: от anonymous 26.01.2009 21:43:49  

Re:

> и у eDSL тоже?

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

anonymous ()
[#] Ответ на: Re: от anonymous 26.01.2009 21:55:01  

Да что там ABAP!

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

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

anonymous ()
[#] Ответ на: Re: от Nxx 26.01.2009 6:05:13  

Re:

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

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

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

* ()

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

* ()
[#] Ответ на: Re: Мыши плакали, кололись... от anonymous 24.01.2009 17:52:56  

Re: Мыши плакали, кололись...

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

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

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

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

** ()

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

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

** ()
[#] Ответ на: Из исследования вытекло от anonymous 26.01.2009 15:56:40  

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

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

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

+1024

** ()
[#] Ответ на: Re: от anonymous 26.01.2009 21:49:14  

Re:

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

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

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

** ()
[#] Ответ на: Re: от VoDA 27.01.2009 23:43:25  
Nxx

Re:

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

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

***** ()
[#]  

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

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

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

* ()
[#]  

Re: "С" преобладает в открытых проектах, начатых в 2008 году

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

()