Індекс популярності мов програмування: 2008

[sicheslav]

З усім іншим теж приблизно все ясно... Але чого росте дельфі? Що, на ньому щось серйозне хтось ще пише? І де хаскель?=)

Там же написано: 33        Haskell  
А щодо дельфі - То не будем про офффтоп (з яким ввесь час сиджу) багато  говорити - у нас якраз він використовується для НЕвеб проектів ...
окрім того... В CodeGear вже  використовують дотНет технологію...(хоча сам наразі на старій/добрій 6ці пишу, яка про дотНет і не здогадується)))

[Володимир Лісівка]

А якого рівня мови Ява і Сі на процесорах, які вміють виконувати байт-код яви? :-)

Жава, в будь-якому випадку, з таким рівнем абстракції - мова дуже високого рівня.

Ява на тому ж рівні що і Сі++, який не є сильно вищий за голий Сі. GCC використовує один і той же-ж код для компіляції Яви і Сі++, він може навіть вільно змішувати їх - писати частину класу на Яві, частину на Сі++ з асемблерними вставками. Ви навіть можете використати препроцесор для того, щоб всі Сі++ і Яву загнати в один файл і просто вказувати, на якій мові написаний конкретний метод класу.

Ви напевно говорите про стандартну бібліотеку класів, яка має значно вищий рівень абстракції ніж стандартна бібліотека Сі?

Не чув про них. Є проблеми з SMP, але вони не специфічні для Яви.

Читав про суттєве падіння перформансу з синхронізацією тредів. OK, можливо, моя інформація застаріла.

Падіння продуктивності при синхронізації спільної паралельної роботи дійсно має місце, але в усіх мовах програмування. Подивіться тести багатопотокових веб-серверів, наприклад.

В Яві раніше для прикладного програміста був доступний тільки один метод синхронізації - блокування всього об’єкту, який не відрізняється ефективністю але простий в реалізації. Але це все таки значно краще ніж глобальне блокування всього ядра в ядрах лінукса до версії 2.6, хоча він написаний на Сі. ;-)
Зараз прикладному програмісту доступно більше засобів для організації ефективної роботи, такі як атомарні операції, напр. Хоча і тут не все гладко - дуже легко забезпечити атомарність на однопроцесорній машині (витрати фактично нульові), тоді як на більшій кількості процесів ростуть витрати на забезпечення атомарності.

АЛЕ, теперішній підхід рухається взагалі в іншу сторону, в сторону lock-free і wait-free алгоритмів. Для прикладу, ext3 вже не перевіряє всю файлову систему після збою, так як існує журнал, в якому записані останні транзакції, і потрібно перевірити тільки його. Так само lock-free алгоритм спочатку декларує в журналі, що він буде робити, потім робить це (можливо, на копії), потім перевіряє що ж реально вийшло (і, можливо, комітить зміни якщо робота йшла на копії). Інший потік може прибігти, подивитися по журналу що потрібно зробити, зробити це (або відмінити чи взагалі проігнорувати транзакцію, якщо робота йде на копії), поставити відмітку в журналі і далі займатися своєю роботою. Знову ж таки, ця надлишкова може давати виграш тільки на високонавантажених/високонкурентних системах чи системах з особливими вимогами до швидкості операцій читання/запису.

Погодьтеся, що ці алгоритми придатні для багатьох мов програмування, а не тільки для Яви, відповідно і проблеми також не є специфічними для Яви. Наприклад проблема інверсії пріоритету була вирішена в ядрі Лінукса зовсім недавно.

Кому як.

А таки кому?

Тим, кому необхідно мінімізувати затрати часу на одну програму.

На яві (як мові) можна писати програми низького рівня, використовувати ручне керування пам’яттю

Я знаю. Про те і мова.

Взагалі, серйозно осилювати жаву я взявся всього два тижні тому. Решта моєї інформації застаріла років на 5. Суперечку продовжувати не буду, бо не маю достатньо знань для цього. Але тим не менше, залишаюсь при думці, що в жаві нічого видатного нема (я, принаймні, поки не помітив), і всі її звичні задачі як мінімум не менш успішно можна виконати іншими інструментами.

Це правда.

Тому питання про незрозумілість її популярності залишається відкритим. Якщо хтось мені пояснить (без аргументів типу "я на ній пишу") - буду дуже вдячний.

Стабільний результат на багатьох платформах.

[Веприк]

Таблиця очікувана. Жаба з неясних до кінця причин весь час тримає перше місце. Штука непогана, але аж ніяк не настільки. З C все ясно, це всерйоз і надовго. А от C++ - це, на мій погляд, все ж явище тимчасове. Повалиться вниз в нікуди, якщо цепепох вчасно не випустять. Та й якщо випустять, ще невідомо, що буде. C# росте, тому що віста, і взагалі - всі на вінді стали схиблені на managed. Політика в чистому вигляді.

З усім іншим теж приблизно все ясно... Але чого росте дельфі? Що, на ньому щось серйозне хтось ще пише? І де хаскель?=)

Не пам'ятаю хто сказав, але Жаба - це Кобол сучасності. Навіть якщо станеться диво і раптом винайдуть нову "срібну кулю" мову програмування, то процес зіскакування існуючих користувачів, а це мільярди рядків коду в десятках тисячах корпоративних і не тільки аплікацій, з голки Яви затягнеться не менш, ніж на десяток років.
C++ - це мейнстрім 90-х і навіть початку 2000-х, зіскакування з нього довге та важке.
C# - це реальність для будь-якого програміста для платформи Windows. А ваша неприязнь до керованості необгрунтована. Все визначається типом завдань які ви збираєтеся вирішувати. Досвід розробників ОС Singularity підтверджує, що, ніш де керовані мови не можуть бути застосовані насправді є дуже мало.
А Делфі поки коливається в межах  статистичної похибки. Хоча новий власник вклав в його просування певні ресурси і можливо ті хто втратив віру в майбутнє платформи повернулися, але це поки ненадовго.  В тій ніші де зараз знаходиться Делфі (.NET - Майкрософт власник платформи, отож компанія завжди буде в ролі доганяючої, native Win32 - ніша поступово зникає) - це вимираючий продукт.

Видно що ви не завдали собі клопоту пройти за посиланням Хаскель в другій половині звіту 33-є місце з відсотками сумарного використання вдвічі меншими за приріст Делфі.

[Веприк]

Ще спостереження - кількість вільних проектів на жаві порівняно невелика. Ті кілька, що я пробував - низької або дуже низької якості (або смертельно глючать, або дико гальмують).

Чудово, приймається. Ще думки?

Ваші спостереження невірні. На sourceforge з 7351 проектів 1619 написано на Java, а TIOBE індекс значною мірою складається якраз на основі sourceforge , бо для комерційних проектів статистика майже недоступна, а sourceforge є найбільшим в світі репозитарієм вільних проектів.

Я не надто полюбляю Яву, але на мою думку її проблема та сила лежить в іншій площині. Я називаю цю проблему "overcomplicated", коли для вирішення простої проблеми робиться цілий framework, поверх ще кількох, і все це родирається через неймовірну кількість інтерфейсів, в результаті тільки щоб освоїти ОДНУ бібліотеку можуть піти місяці і з'являються вузькі фахівці по JFace чи JSP і все це в межах однієї платформи. До речі ці ж недоліки стосуються значною мірою і .NET. Ну і деякі речі в синтаксисі мене дратують, але на це як кажуть наші північні сусіди "На вкус и цвет все фломастеры разные".

[raven]

Стабільний результат на багатьох платформах

Не маю підстав думати, що кросплатформеність всерйоз когось цікавить. Завжди дизайнять під конкретну.

C++ - це мейнстрім 90-х і навіть початку 2000-х, зіскакування з нього довге та важке.

Три ха-ха. Ви хоч новину прочитали? А C++0x опублікують вже наступного року. Щось воно поки вмирати не збирається.

C# - це реальність для будь-якого програміста для платформи Windows. А ваша неприязнь до керованості необгрунтована. Все визначається типом завдань які ви збираєтеся вирішувати. Досвід розробників ОС Singularity підтверджує, що, ніш де керовані мови не можуть бути застосовані насправді є дуже мало.

Класний підхід - приписати опоненту вислів і героїчно його спростувати. Поздоровляю.

Видно що ви не завдали собі клопоту пройти за посиланням Хаскель в другій половині звіту 33-є місце з відсотками сумарного використання вдвічі меншими за приріст Делфі.

М-дя. Мені вамі пояснити, де хаскель робиться і з якою метою?

Ваші спостереження невірні. На sourceforge з 7351 проектів 1619 написано на Java, а TIOBE індекс значною мірою складається якраз на основі sourceforge , бо для комерційних проектів статистика майже недоступна, а sourceforge є найбільшим в світі репозитарієм вільних проектів.

ШО??? А це і це що таке? Може, все ж варто перевіряти інформацію? Для нелюбителів ходити за лінками - зараз зареєстровано 149237 проекти, з яких 84821 мають більше 0 скачувань. Тег Java мають 37491 зі 149237, але це мало що означає. Той же MinGW містить теги "Programming Language : Ada, C, C++, Fortran, Java, Pascal ".

А от тримати в себе на машині jre зовсім необов’язково. І це факт. Якщо уважно подивитись сюди, то можна помітити, що це здебільшого достатньо специфічні речі.

[raven]

А от тримати в себе на машині jre зовсім необов’язково. І це факт.

Точніше, не так. Я без нього обходжусь без жодних незручностей, в рамках своїх задач.

[raven]

Падіння продуктивності при синхронізації спільної паралельної роботи дійсно має місце, але в усіх мовах програмування. Подивіться тести багатопотокових веб-серверів, наприклад.

В Яві раніше для прикладного програміста був доступний тільки один метод синхронізації - блокування всього об’єкту, який не відрізняється ефективністю але простий в реалізації. Але це все таки значно краще ніж глобальне блокування всього ядра в ядрах лінукса до версії 2.6, хоча він написаний на Сі. ;-)
Зараз прикладному програмісту доступно більше засобів для організації ефективної роботи, такі як атомарні операції, напр. Хоча і тут не все гладко - дуже легко забезпечити атомарність на однопроцесорній машині (витрати фактично нульові), тоді як на більшій кількості процесів ростуть витрати на забезпечення атомарності.

АЛЕ, теперішній підхід рухається взагалі в іншу сторону, в сторону lock-free і wait-free алгоритмів. Для прикладу, ext3 вже не перевіряє всю файлову систему після збою, так як існує журнал, в якому записані останні транзакції, і потрібно перевірити тільки його. Так само lock-free алгоритм спочатку декларує в журналі, що він буде робити, потім робить це (можливо, на копії), потім перевіряє що ж реально вийшло (і, можливо, комітить зміни якщо робота йшла на копії). Інший потік може прибігти, подивитися по журналу що потрібно зробити, зробити це (або відмінити чи взагалі проігнорувати транзакцію, якщо робота йде на копії), поставити відмітку в журналі і далі займатися своєю роботою. Знову ж таки, ця надлишкова може давати виграш тільки на високонавантажених/високонкурентних системах чи системах з особливими вимогами до швидкості операцій читання/запису.

Погодьтеся, що ці алгоритми придатні для багатьох мов програмування, а не тільки для Яви, відповідно і проблеми також не є специфічними для Яви. Наприклад проблема інверсії пріоритету була вирішена в ядрі Лінукса зовсім недавно.

Трохи погуглив. Речі, в цілому, загальновідомі, але дякую за правильний напрямок.

Ще спостереження - кількість вільних проектів на жаві порівняно невелика. Ті кілька, що я пробував - низької або дуже низької якості (або смертельно глючать, або дико гальмують).

до речі це теж не зовсім правда, візміть ті самі відкриті apache-commons, log4j, tomcat, jboss, eclipse, GWT, openCMS, ... які живуть вже не перший рік і використовуються в дуже багатьох комерційних (і вільних) проектах, і судячи з того, що їм віддають перевагу над комерційними аналогами або написанням in-house їх якість доводити зайвий раз не потрібно...

Зараз їх дійсно куди більше, ніж очікував виявити. На цю тему я висловився вище.

[Praporshic]

А от тримати в себе на машині jre зовсім необов’язково. І це факт.

Точніше, не так. Я без нього обходжусь без жодних незручностей, в рамках своїх задач.

Миколо, тобі відверто щастить. Ось я без нього не можу - усі IP-KVM зроблені на жабі. А бігти у разі чого за океан якось того...

[raven]

А от тримати в себе на машині jre зовсім необов’язково. І це факт.

Точніше, не так. Я без нього обходжусь без жодних незручностей, в рамках своїх задач.

Миколо, тобі відверто щастить. Ось я без нього не можу - усі IP-KVM зроблені на жабі. А бігти у разі чого за океан якось того...

Хе. Сам винен. Перекваліфіковуйся в це-девелопери, теж будеш такі дурні питання як от я задавати=)

[Praporshic]

Off-topic:

Хе. Сам винен. Перекваліфіковуйся в це-девелопери, теж будеш такі дурні питання як от я задавати=)

Жодних грубощів з девелоперами. Лише насильство. © Товариш з ISD MIS

[Володимир Лісівка]

Я не надто полюбляю Яву, але на мою думку її проблема та сила лежить в іншій площині. Я називаю цю проблему "overcomplicated", коли для вирішення простої проблеми робиться цілий framework, поверх ще кількох, і все це родирається через неймовірну кількість інтерфейсів, в результаті тільки щоб освоїти ОДНУ бібліотеку можуть піти місяці і з'являються вузькі фахівці по JFace чи JSP і все це в межах однієї платформи.

Угу. Я з вами згоден. А на-Сі-льники взагалі прибалділи  - замість однієї libc попридумували кілька десятків тисяч бібліотек, причому всі з різними інтерфейсами і часто навіть з різними назвами основних типів даних!!!

[Володимир Лісівка]

Стабільний результат на багатьох платформах

Не маю підстав думати, що кросплатформеність всерйоз когось цікавить. Завжди дизайнять під конкретну.

Під конкретну версію Віндовза чи конкретну модель мобілки? Якщо розробники сидять на різних ОС-ках (Win,Lin,MacOS) а кінцева програма крутиться на іншій ОС-ці (напр. UNIX чи Symbian), то існує два популярних рішення: пересадити всіх розробників на цільову ОС-ку (дуже смішно у випадку ОС-ки для вбудованих систем або систем з високою вартістю і/чи складністю) або використовувати систему, яка більш-менш однаково добре працює усюди (Ява, Python, Perl, HTML/JavaScript, etc. ).

PS.

Завжди не любив людей які ігнорують проблеми сумісності з сьогоднішнім і завтрашнім днем.

[raven]

А на-Сі-льники взагалі прибалділи  - замість однієї libc попридумували кілька десятків тисяч бібліотек, причому всі з різними інтерфейсами і часто навіть з різними назвами основних типів даних!!!

Тому й "крослатформенний" код на С - це вінегрет з ifdef-ів.

Під конкретну версію Віндовза чи конкретну модель мобілки? Якщо розробники сидять на різних ОС-ках (Win,Lin,MacOS) а кінцева програма крутиться на іншій ОС-ці (напр. UNIX чи Symbian), то існує два популярних рішення: пересадити всіх розробників на цільову ОС-ку

І це правильне рішення, коли його можна застосувати. А те, що розробники мають сидіти з однаковим environment - це практично аксіома.

Насправді, я стикався з феєричними граблями навіть з оновленнями в рамках однієї платформи, більше того - одного дистрибутиву. Оновили драйвери nvidia - все посипалось. Це, звичайно, фігово. Коли 15 років тому починали писати, треба було головою думати. Але от тільки один маленький нюанс... реалізація на плюсах посипалась, а от на жаві взагалі його не можна було б реалізувати. Деталей викладати не буду, повірте на слово.

або використовувати систему, яка більш-менш однаково добре працює усюди (Ява, Python, Perl, HTML/JavaScript, etc. ).

І це теж правильне рішення. Але. По-перше, "більш-менш". По-друге, не ліпіть "Ява, Python, Perl" в один ряд. По-третє, це просто один з варіантів рішення. По-четверте, чи ж мені вам розказувати про віртуалізацію?

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

дуже смішно у випадку ОС-ки для вбудованих систем

Ню-ню. Тоді поясніть мені астрономічну кількість нативного софта під, скажімо, WinCE. Ах да, всі хто його пише - ідіоти, не знають, що для повного щастя їм треба лише взяти яку-небуть жаву... І Джобс - повний кретин, бо не дозволяє розчудесну жаву ліпити на свої яблофони, а просуває свій SDK. Хоча це вже з іншої опери. Хе-хе...

систем з високою вартістю і/чи складністю

Щодо вартості. Що, для суперкомп'ютерів вартість розробки вища ніж ціна самого обладнання? Круто не знав. Значить, мені так тисяч сто на місяць недоплачують.
Щодо складності. Нагадати історію Томмі і чому він загинув?

Завжди не любив людей які ігнорують проблеми сумісності з сьогоднішнім і завтрашнім днем.

Завжди не любив людей, які десятиліттями тягнуть на собі труп застарілих API, а зворотна сумісність все одно відвалюється. Допоміг цей "гуманізм" M$? Та ні разу. Он, геймери вайн під вінду ставлять... А от трольтехи зробили революцію - розгребли смітник Qt3 і просто викинули на звалище все зайве. Результат - напевне, найкращий з існуючих вільних тулкітів. А їх "конкуренти" gtk поки що тягнуть усе за собою. І все одно ламають сумісність мало не з кожним мінорним релізом. В 2.14 уже утворився добрячий смітник. І його рано чи пізно вичистять. Тим же способом, що і gtk1.

Ще приклад. Гвідо поклав на всяку зворотну сумісність і випустив python-3.0. Він ворог народу? Ні, він розвиває конкретну технологію. Зміни назріли. Особисто я задовбався плутатись в каші deprecation warning-ів і можливістю реалізувати ту ж саму фічу боком, раком і з підскоком. Месидж простий. Поки що - використовуйте 2.6, але майте на увазі, що він застарів вже на момент виходу.

Я зараз читаю різні доки по жаві, JCA в даний момент, і регулярно натикаюсь на фразу "due to historical reasons". Рано чи пізно їх кількість перевалить за критичну позначку. І що тоді буде?

[Володимир Лісівка]

Тому питання про незрозумілість її популярності залишається відкритим. Якщо хтось мені пояснить (без аргументів типу "я на ній пишу") - буду дуже вдячний.

Цікаво-цікаво, а ви якою мовою будете писати програму для мобільних телефонів?=)
P.S. Тільки не пишіть про Сішку, будьмо реалістами=)

У сусідній кімнаті програмісти пишуть софт для мобільного телефона на Objective-C. Хоча, невеличке доповнення: то не мобільний телефон а iPhone

http://www.innaworks.com/alcheMo-for-iPhone.html

В мене на поясі висить пристрій, під який софт на JavaME написати неможливо, а от на C++ - залюбки (Motorola A1200e з QTopia замість "рідного" мотлоху).

На a1200e можна ганяти нормальну яву, а не тільки J2ME.

http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/

[Praporshic]

У сусідній кімнаті програмісти пишуть софт для мобільного телефона на Objective-C. Хоча, невеличке доповнення: то не мобільний телефон а iPhone

http://www.innaworks.com/alcheMo-for-iPhone.html

Добре, додам інформації: вони портують (логіка там не змінюється) програму з Win32 на iPhone. Початкова програма написана на C++.

На a1200e можна ганяти нормальну яву, а не тільки J2ME.

http://rschuster.blogs.evolvis.org/2008/12/21/serving-cross-compiled-openjdk-with-icedtea/

То вже занадто. В мене і так воно ледь добу живе на одній зарядці.