Компания TIOBE Software опубликовала (https://www.tiobe.com/tiobe-index/) очередной рейтинг популярности языков программирования. Наиболее заметными изменениями по сравнению с редакцией рейтинга, опубликованной год назад, является перемещение с 5 на 4 место языка Python и с 7 на 6 место языка JavaScript. Язык PHP поднялся с 10 на 9 место, а Ruby с 12 на 11. Большой всплеск популярности наблюдается для языка R, который поднялся с 16 на 8 место рейтинга. Заметный рост интереса также отмечается для языков: Swift (с 14 на 12 место), Erlang (c 44 на 23) и Kotlin (с 89 на 39).
По уровню роста популярности лидирует язык Си, который за год повысил свои показатели на 1.69%. Далее следуют Python (+1.21%) и Erlang (+0.98%). Наиболее сильно теряют свои позиции Java (-3.06%), Go (-0.76%) и C++ (-0.70%). Из языков, которые сместились по рейтингу вниз можно отметить Perl, который сдвинулся с 8 на 10 место, Go (спустился с 13 на 19 место), C# (с 4 на 5 место), Visual Basic .NET (с 6 на 7 место), Delphi/Object Pascal (с 11 на 13), Assembler (с 9 на 15). Язык Rust пока занимает только 46 место.
Индекс популярности TIOBE не пытается найти самый лучший язык программирования по самому большому количеству написанных строк кода, а строит свои доводы по изменению интереса к языкам, на основе анализа статистики поисковых запросов в таких системах, как Google, Google Blogs, Yahoo!, Wikipedia, MSN, YouTube, Bing, Amazon и Baidu.Для сравнения в январском обновлении рейтинга PYPL (http://pypl.github.io/PYPL.html), в котором используется Google Trends, по сравнению с январём 2017 года наблюдается перемещение Javascript с 5 на 4 место, C++ с 7 на 6, R c 9 на 8. Также улучшили свои позиции VBA, TypeScript, Scala, Kotlin (17 место) и Rust (21 место). Сместились вниз C#, C (с 6 на 7 место), Objective-C, Visual Basic, Perl (18 место), Lua, Haskell и Delphi.
URL: https://www.tiobe.com/tiobe-index/
Новость: http://www.opennet.ru/opennews/art.shtml?num=47869
Сишарпы приходят и уходят, а Java™ остается.
модостроители майнкрафт постарались
Андроидт-разработчики вот кто постарался, там это основной язык
К сожалению да.
Слышал, что вроде бы с 9-ой версии попробуют впилить Go как основной язык для Android.
Kotlin хотят. Уже начали официально поддерживать. От сюда кстати он и скакнул.
Нужно чтоб окончательно отвязаться от Oracle.
> Сишарпы приходят и уходят, а Java™ остается.Java, по моему, бессмертный язык
Очень жаль что эта хрень с форматно-несвободным синтаксисом под названием питон имеет прирост больше всех.
> форматно-несвободным синтаксисомЛет зе cpач бегинс. Приведу абсолютно новый аргумент против питоновского синтаксиса.
Вы, уважаемые питонолюбители, считаете, что ваши глаза вам будут служить вечно. Если вы, не дай Бог, ослепнете, то на питоне вы писать уже не сможете. Зато сможете на любом другом норм си-подобном языке. Прямо сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому ифу. На си-подобном языке начало и конец ифа явным образом обозначаются фигурными скобками, и нет нужды запоминать, сколько же там пробелов должно быть в текущем блоке.
А нефиг блоки по несколько страниц делать
Ага. Лучше вообще писать код в одну строчку длиной 100к символов, а лучше в машинных кодах!
Скорее всего кто-то просто не понимает дзена красоты оформления кода на любом языке.
> Ага. Лучше вообще писать код в одну строчку длиной 100к символов, а лучше в машинных кодах!Нет, лучше пользоваться автоматическим выравниванием, которое подгоняет Ваш код под корпоротивный стандарт. И никакой отсебятины. Это нужно для того, чтобы было меньше конфликтов в СКВ.
> Скорее всего кто-то просто не понимает дзена красоты оформления кода
> на любом языке.Скажите, а дзен -- это про навязчивость? Оформляй или умри, причём оформляй именно вот так и оставь свои эстетические предпочтения за порогом этого лагеря?..
Дзен тут в отсутствии необходимости дискутировать про отступы
А разве слепые программисты пользуются не терминалами Брайля? То, как вы описали, они ни на каком языке не смогут. Скобки, ведь, тоже считать надо.
> "пробел пробел пробел пробел"Ну да, "закрывающая фигурная скобка закрывающая фигурная скобка закрывающая фигурная скобка закрывающая фигурная скобка" гораздо лучше.
if ( <условие> ) {
<оператор1>
<оператор2>
...
<операторn>
}
Достаточно будет один раз скобку прочитать вслух. В Python'е на каждый оператор придется читать еще и табуляцию / пробел.
Не все ли ранво, сказать "скобка" (как начало уровня вложенности) или просто "отступ" и не повторяться на каждой строке "отступ, отступ,..." в случае с питоном?
> Не все ли ранво, сказать "скобка" (как начало уровня вложенности) или просто
> "отступ" и не повторяться на каждой строке "отступ, отступ,..." в случае
> с питоном?Нет не все равно. Потому что тогда Вам нужен специализированный "питоноориентированный" (учитывающий синтаксис питона) синтезатор речи. Типа как в текстовых редакторах плагинами поддерживаются синтаксисы разных языков программирования. А для си-подобных языков можно попытаться обойтись каким-то более простым синтезатором, он даже "пробел, пробел, табуляция..." может не проговаривать (и, соотвественно, их не надо для каждой строки считать в уме), в этом случае проблемы могут возникнуть только для каких-то строковых литералов, в которых кол-во пробелов/табуляций и т.п. важно (какие-нибудь маски/регэкспы в строках-константах ).
А если так:if(cond1){
if(cond2){
if (cond3){
op1
}else{
if (cond4){
op2
}else{
op3
}
}
}
}Такое, что на питоне, что на любом "скобочном" языке читать голосом тяжело
вот только на питоне есть возможность многие подобные вещи сокращать в однострочники
но с другой стороны, я не уверен, что сложный генератор списков с фильтрацией и пред-обработкой значений вообще возможно воспринять на слух.... есть у меня пара таких в "загашнике", так я их визуально по пол часа воспринять пытаюсь, несмотря на то, что сам их когда-то написал...
>> форматно-несвободным синтаксисом
> Лет зе cpач бегинс. Приведу абсолютно новый аргумент против питоновского синтаксиса.
> Вы, уважаемые питонолюбители, считаете, что ваши глаза вам будут служить вечно. Если
> вы, не дай Бог, ослепнете, то на питоне вы писать уже
> не сможете. Зато сможете на любом другом норм си-подобном языке. Прямо
> сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти
> "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому
> ифу. На си-подобном языке начало и конец ифа явным образом обозначаются
> фигурными скобками, и нет нужды запоминать, сколько же там пробелов должно
> быть в текущем блоке.Плюс добавить не могу (javascript отключен), но согласен, "фигурная скобка" и "пробел" это один символ!
if (0 != x) puts("and where the fuck { and } here?")
> if (0 != x) puts("and where the fuck { and } here?")Т.е. по Вашему мнению в данной ситуации слепой программист считает только (и исключительно) фигурные скобки? Круглые скобки, кавычки, точки-с-запятой и т.п. он игнорирует? Ваш пример на многие порядки проще ситуации, когда для каждой последующей строки надо подсчитывать кол-во пробелов чтобы отследить конец блока. Строковый литерал начался? Окей, замечательно! Ждем закрывающей кавычки или последовательности, экранирующей кавычку (чтобы ее не посчитать закрывающей) и на скобки/семиколоны/арифметическиеоперации/т.п. внимания не обращаем. И приведенный пример будет встречаться в коде значительно реже, чем монотонная необходимость считать пробелы КАЖДОЙ строки.
> Вы, уважаемые питонолюбители, считаете, что ваши глаза вам будут служить вечно. Если вы, не дай Бог, ослепнете, то на питоне вы писать уже не сможете. Зато сможете на любом другом норм си-подобном языке. Прямо сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому ифу. На си-подобном языке начало и конец ифа явным образом обозначаются фигурными скобками, и нет нужды запоминать, сколько же там пробелов должно быть в текущем блоке.from __future__ import braces
Теперь проваливайте.
> Прямо сейчас слепым питоно-программистам приходится выслушивать на синтезаторе речи все эти "пробел пробел пробел пробел", чтобы понять, относится ли стейтмент к прошлому ифу.Кто-то вместо "пробел" слышит "табуляция" :D
Ну а так да ответ с треда выше вам подходит:
from __future__ import bracesНо выглядит использование пробелов и табов более пристойно(структуру видно) чем использование только скобок для указания границ функции.
Бидон уже опустился и до такого, чтобы сишникам понравиться. Прости, яваскрипт, но медаль в этот раз ты не выиграл.
> Бидон уже опустился и до такого, чтобы сишникам понравиться.Мне и ассемблера(AT&T-Syntax и Intel-Syntax) для X86 хватает, и C-like синтаксис мне нравится, и питоновский синтаксис тоже.
Одними словами мне плевать на чем писать, но прототипы писать на Python проще в разы.
Там где нужны указатели то мне хватит и C без плюсов.
Другими словами мне без разницы какой синтаксис, главное чтобы я его понял и смог с ним работать.
Если вам надо читать программы вслух, то Ада без вариантов. "end if", "end loop", "end MyFunction". Скобки считать не надо. Ещё PL/I можно, но на этом месте вы можете решить, что я тролль. А Ада вроде ещё имеет какую-то нишу, когда нужен промышленный софт с верификацией.
> Очень жаль что эта хрень с форматно-несвободным синтаксисом под названием питон имеет прирост
> больше всех."низкий порог вхождения". увы.
Всех интересует не синтаксис, а огромные зарплаты специалистов по machine learning.
ML - это R, Java, Matlab, Julia (на ближайшую перспективу). Питону тут места нет
И там хоть иероглифами, т.к. самого кода мало ( а библиотеки таки не на питоне )
Проблема питона не в синтаксисе, амв непомерной лагучести. Приложения на питоне обычно невероятно медлительны, в отличие от таковых на джаве и ноде.
Сколько можно повторять эту сказку? На джаве все прямо летает ахаха
Ну да, по сравнению с питоном - вполне себе летает. Это для вас новость? Среди этой троицы питон - единственный интерпретируемый, JS в ноде и джава - JIT-компилируемые, что, естественно, даёт прирост
Все такие экшперты. Гугл же утверждает обратное: https://habrahabr.ru/post/209812/
Да понятно, что есть куча реализаций. Но то, что используется на абсолютном большинстве машин и на чеём тестируется весь питоновский софт - это CPython. То есть для джавы/js наиболее дешёвый, простой и известный путь является самым быстрым, а для питона - самым медленным, а ускорения означают дополнительное тестирование и борьбу с граблями.
> Среди этой троицы питон - единственный интерпретируемый, JS в ноде и джава - JIT-компилируемые, что, естественно, даёт приростКак JS, так в ноде, а не в рино или джеррискрипт.
Как питон, так почему-то не в PyPy.
Потому что это стандарты де-факто. Когда под "установлен питон" будет подразумеваться PyPy - будет другой разговор.
> На джаве все прямо летает ахахаМы же с питоном сравниваем? https://benchmarksgame.alioth.debian.org/u64q/python.html
А вообще, единственное, что тормозит в Java™ — это графическая библиотека. Безгуйные Java™-приложения выполняются со скоростью, сопоставимой с плюсами: проседание в производительности всего в полтора раза. Добавим к этому также и то, что Java™-приложения всегда есть куда оптимизировать в плане распараллеливания сложных задач. Питоно-разработчикам этот путь закрыт by design: есть всего лишь примитивная кооперативная многозадачность как в MS DOS.
И тем не менее, к слову о гуе, даже если взять самый тормозной Java™-тулкит — JavaFX — то по моим субъективным впечатлениям, он все равно работает быстрее, чем питоно-приложения, использующие вполне себе быстрые Qt или GTK+.
А какой смысл сравнивать между собой двух тормозов?
> А какой смысл сравнивать между собой двух тормозов?Спецсоревнования.
>самый тормозной Java™-тулкит — JavaFXЕсли JavaFX у Java тормозной - то какой тулкит в ней не тормозной? Он же хронологически крайний вроде.
Более чем летает. Жрет память, да, но летает.
> Более чем летает. Жрет память, да, но летает.А еще (неожиданно)падает, если переест.
Не натыкался, подозреваю ошибку в коде, особенно кого-нибудь фреймворка.
Жердяи не летают, только катиться по наклонной
> ЖердяиОт слова "жердь"?
Ещё забыли отсутствие нормальной многопоточности
> Проблема питона не в синтаксисе, амв непомерной лагучести. Приложения на питоне обычно
> невероятно медлительны, в отличие от таковых на джаве и ноде.я использую питон в основном для обработки данных. и там скорость языка особой роли не играет - гораздо больше времени тратится на i/o, чем на какую-то логику. на питоне написать такой обработчик мне гораздо проще, чем на "родной" Java, а скорость работы будет сопоставима.
Если же нужна максимально быстрая числодробилка, то пилить ее на питоне настолько же глупо, как и на Java или NodeJS
Завидуйте молча!))
У них бейсик в топ10, дальше можно не читать, это же дичь
Си это тоже бейсик, но с указателями.
Уууу, школота, даже бейсика настоящего не знают, того что с номерами строк и войной между теми, у которых присваивание только с LET и без него...
если в первой десятке комментов встретился вижуал бейсик о комменты тоже можно дальше не читать?
Название отчёта некорректно. Корректно: "Рейтинг языков, которым либо учатся, либо ищут описания функций из-за отсутствия документации, либо чаще всего копипастят или чаще не могут самостоятельно решить проблему".
То есть тех языков, которыми пользуются. Что и написано в заглавии.
Мне одному кажется, что график как-то не очень соответствует % ?)
это TIOBE если хотите релевантных данных то вам не сюда.
Как только в MS Excel и LO Calc имплементируют Python - он и VBA возглавят подобные чарты. Количество в мире пользователей, которым нужна небольшая самописная программа по работе - в десятки раз больше числа программистов. Счёт идёт на ссотни млн. человек.А лично мне ненависть к Питону понятна - слишком он хорош во всем, даже не верится порой. Обидно бывает переписывать за час то, что на других языках создавалось неделю.
> А лично мне ненависть к Питону понятна - слишком он хорош во
> всем, даже не верится порой. Обидно бывает переписывать за час то,
> что на других языках создавалось неделю.извините а на каких других языках вы что то неделю создаете а потом переписываете это на питон?
Ну, во-первых, python в либреофисе всегда был и до сих пор никуда не делся, это для справки. А, во-вторых, недостаток питона в том, что он хорош для простых задач, но многие относительно сложные вещи, которые даже на голом С делаются достаточно тривиально, на питоне либо ЧРЕЗВЫЧАЙНО сложны, либо вовсе невозможны. У питона очень плохо с параллелизмом, например - или ты остаешься совсем без параллелизма, или смиряешься с чудовищными накладными расходами на обмен данными между процессами. В итоге такая простая задача, скажем, как умножение двух больших матриц, на сях и ко параллелится чуть ли не пропорционально числу вычислителей, а в питоне - плак-плак.
Если что я другой аноним. По поводу параллелизма я с вами не соглашусь. Питон вполне себе c параллелизмом на уровне процессов, и если у вас бутылочно горлышко io то тут уж async/await в помощь. А по поводу чудовещьных накладных расходов, ну может вам не питон нужен? Я сам не фанат питона, мне вообще пофигу питон, руби, пхп, ява, котлин или го. Просто инструменты для определенного круга задач, где то они подходят, где то нет.
> чудовещьныхОт слова "чудо-вещь"?
> Питон вполне себе c параллелизмом на уровне процессовТак в том и дело. Там, где на C можно обойтись потоками и общим адресным пространством, на python спаунится несколько процессов, которые должны между собой коммуницировать. В итоге обмен данными между процессами сводит на нет весь возможный выигрыш от параллелизма и делает даже хуже. Мы получаем забавную ситуацию: конструктивно параллелизм в питоне организуется очень просто, удобно и понятно, но он не работает.
> между собой коммуницировать. В итоге обмен данными между процессами сводит на
> нет весь возможный выигрыш от параллелизма и делает даже хуже. Мы
> получаем забавную ситуацию: конструктивно параллелизм в питоне организуется очень просто,
> удобно и понятно, но он не работает.Мы получаем нормальную ситуацию коммента от тролля без опыта многопоточного программирования. Процессы, потоки и нити - все в одну кучу свалил.
Отечественная практика сильно пострадала от когда-то введённого (изд-вом Мир в 70-е?) перевода thread как поток. Смыслы затуманились.
> Отечественная практика сильно пострадала от когда-то введённого (изд-вом Мир в 70-е?) перевода
> thread как поток. Смыслы затуманились.Чем плох-то перевод?
Process - процесс
Thread - поток
Fiber - нить
Что не устраивает?
>> Отечественная практика сильно пострадала от когда-то введённого (изд-вом Мир в 70-е?) перевода
>> thread как поток. Смыслы затуманились.
> Чем плох-то перевод?
> Process - процесс
> Thread - поток
> Fiber - нить
> Что не устраивает?А я только что сказал, _что_ не устраивает. Перевод, омонимичный с переводом stream и "преувеличивающий" смысл описываемой сущности.
Каждый, кто имел дело с учебным материалом по параллельным вычислениям, меня поймёт.
А употребление fibers мне и вовсе лишь смутно помнится.
> А я только что сказал, _что_ не устраивает. Перевод, омонимичный с переводом
> stream и "преувеличивающий" смысл описываемой сущности.
> Каждый, кто имел дело с учебным материалом по параллельным вычислениям, меня поймёт.
> А употребление fibers мне и вовсе лишь смутно помнится.Ну когда делали перевод thread, stream еще на было. Сейчас и fiber / corutines/ thread путают. ИМХО лучше по английски и оставлять.
fibers - это вроде как в windows 7 появилось. К 2020 году приедет и в ядро linux, к очередной дате windowsкапец.
>> А я только что сказал, _что_ не устраивает. Перевод, омонимичный с переводом
>> stream и "преувеличивающий" смысл описываемой сущности.
>> Каждый, кто имел дело с учебным материалом по параллельным вычислениям, меня поймёт.
>> А употребление fibers мне и вовсе лишь смутно помнится.
> Ну когда делали перевод thread, stream еще на было. Сейчас и fiber
> / corutines/ thread путают. ИМХО лучше по английски и оставлять.Именно. Тред и тред (и он, же, кстати, ещё и поток, - но поток команд).
Поправка: именно "stream" был не то что когда мировский перевод, а когда ещё фон Нейман (конец 40-х), и уж точно когда Флинн (72).> fibers - это вроде как в windows 7 появилось. К 2020 году
> приедет и в ядро linux, к очередной дате windowsкапец.Кстати, англоязычный поймёт сразу - нить (thread, на катушках которая) крутят из волокна (fibers, которые волосинки). Надо бы "нитки" и "ниточки" (но редакторы не осмелятся).
Fiber - волокно. Но тоже могут не осмелиться.
> fibers - это вроде как в windows 7 появилосьНет. В NT4 уже точно было.
MSDN с тобой не согласен - WindowsXP/ Server 2003
Stream - поток и он был раньше.Профессиональные термины должны быть тезаурусом, поэтому "Thread - поток" и не устраивает.
> Stream - поток и он был раньше.
> Профессиональные термины должны быть тезаурусом, поэтому "Thread - поток" и не устраивает....должны НЕ быть тезаурусом :)) даты в #87 :)
> Мы получаем нормальную ситуацию коммента от тролля без опыта многопоточного программирования.
> Процессы, потоки и нити - все в одну кучу свалил.Ну давай, разъясни-ка, как эту кучу развалить. А то поди я всю жизнь софт для расчетов на кластерах неправильно писал. Умничать может каждый, а по делу говорить - так все сразу Львы Простые.
>> А то поди я всю жизнь софт для расчетов на кластерах неправильно писал.Еще какие умные слова знаешь? Сначала у нас одно адресное пространство в процессах, теперь кластеры пошли, у них то-же пошло одно адресное пространство для всех нод на Си? Дальше сейчас еще нейросети в облаках приплетешь?
Те кто занимается машинным обучением (Python) видать лохи полные :)
> Те кто занимается машинным обучением (Python) видать лохи полные :)Да почему же сразу лохи? Большинство этих "специалистов" используют готовые биндинги к питону для грамотно написанных библиотек, в которых все уже сделано за них. Но писать высокопроизводительные алгоритмы на самом питоне, увы, нельзя.
> В итоге такая простая задача, скажем, как умножение двух больших матриц, на сяхДля серьёзных мат расчётов си непригоден бу-дизигн. "Безумные учёные(tm)" множат свои матрицы фортраном, им этот ваш пердолинг с указателями и вечно переполняющимися буферами нафиг не упёрся.
Ошмёток, все библиотеки MatLab, Maple, Mathematica на C.
тем неменее до сих пор "C" мало пригоден для параллельного прог. в отличии от фортрана, т.к. синтаксис предполагает слишком много побочных результатов. Правильно пишут дальше про интерфейсы MPI. Хотя попытки создать powerC были, но прижилось.
"Безумные учёные(tm)" не работают с такой попсятиной, это всё для офисного матпланктона.Всё равно что сказать:
Linux ошмёток, все Windows уже почти полностью на C#.
>> В итоге такая простая задача, скажем, как умножение двух больших матриц, на сях"Простая задача" умножения двух матриц "прекрасно параллелится" не Сями, а средой с передачей сообщений (в качестве таковой в наши дни в 99,9% случаев выступает та или иная реализация MPI). К среде доступ из Сей в первую очередь, да. Но и из фортрана (да? ещё не выбросили?).
> Для серьёзных мат расчётов си непригоден бу-дизигн. "Безумные учёные(tm)" множат свои матрицы
> фортраном, им этот ваш пердолинг с указателями и вечно переполняющимися буферами
> нафиг не упёрся.Когда-то -- да. Сейчас все классические реализации научных библиотек непременно имеют интерфейс к Си, если сами не переделаны на Си.
>>Сейчас все классические реализации научных библиотек непременно имеют интерфейс к СиА чем cdecl/stdcall/safecall так сильно отличаются?
Fortran просто вылизан насмерть за свои 50 с лишним лет и хорошо себе чувствует на 100500 ядрах без лишнего геморроя.
>>>Сейчас все классические реализации научных библиотек непременно имеют интерфейс к Си
> А чем cdecl/stdcall/safecall так сильно отличаются?Вообще-то, я имел в виду то же самое. Различие между Си и Фортраном в наши дни более в восприятии, нет *качественных* различий для научных расчётов, сравнимых с обстановкой 40-летней давности :)))
> Fortran просто вылизан насмерть за свои 50 с лишним лет и хорошо
> себе чувствует на 100500 ядрах без лишнего геморроя.Но 90-чный синтаксис какой-то настораживающий :)))
>>Но 90-чный синтаксис какой-то настораживающий :)))Он давно не 90-строчный. Но хорошо параллелиться.
>>>Но 90-чный синтаксис какой-то настораживающий :)))
> Он давно не 90-строчный. Но хорошо параллелиться.Он даже 95-чный давно. )) И параллелится он точно в том же смысле, что и Си.
> если сами не переделаны на Си.Более того, например в Maple c версии 6 и дальше в библиотеке LiearSolve туева хуча
алгоритмов на ассемблере, заточены под SSE2/3, AMD/Intel SSE
>> если сами не переделаны на Си.
> Более того, например в Maple c версии 6 и дальше в библиотеке
> LiearSolve туева хуча
> алгоритмов на ассемблере, заточены под SSE2/3, AMD/Intel SSEЭто не специфично для Maple. Вообще вычислительные пакеты типа Octave (и SciLab?) и SAGE имеют возможность сборки с подключением скоростных модулей, собираемых под исполнительное устройство (те же atlas или blas). Maxima мне в этом смысле непонятна, не разбираюсь я в лиспах )))
Для справки: Python (2.7 в OO, 3.4 в LO) - пока что взаимодействует с OpenOffice|LibreOffice через pyuno и саму UNO, что крайне неудобно. Настолько, что никем (почти) не используется. Под Windows даже через COM из Питона удобнее работать, чем через этот долбанный UNO.Имплементация языка - это поддержка всей объектной модели приложения (того же Calc). А также возможность писать UDF, обращаться к именованным диапазонам вида [ИМЯ] итп.
Перемножая матрицы в numpy/scipy я знаю что это делают сишные библиотеки и делают быстро. Про asyncio уже написали.
Насчёт количества программистов - да, насчёт величия питона - это какая-то бредовая байка...
> Как только в MS Excel и LO Calc имплементируют Python - он
> и VBA возглавят подобные чарты. Количество в мире пользователей, которым нужна
> небольшая самописная программа по работе - в десятки раз больше числа
> программистов. Счёт идёт на ссотни млн. человек.
> А лично мне ненависть к Питону понятна - слишком он хорош во
> всем, даже не верится порой. Обидно бывает переписывать за час то,
> что на других языках создавалось неделю.Вы там осторожней, а то Поттеринг!
> Как только в MS Excel и LO Calc имплементируют Python - он и VBA возглавят подобные чарты.Мне просто любопытно, как ты объясняешь такой неудобный для твоей теории факт, что VBA не возглавляет подобные чарты прямо сейчас? Ведь от добавления питона как конкурирующего языка доля VBA может только снизиться.
VBA не возглавляет подобные чарты потому что:1) VBA работает только внутри MS Excel, CorelDraw и AutoCAD - то есть их используют профессиональные пользователи (экономисты, аналитики, дизайнеры, проектировщики, конструкторы итд). Этим людям некогда сраться на форумах, с английским в этой среде туговато, а о том как встречают в рунете российских "прикладников" - хорошо известно, где пользователей бейсика считают недолюдьми. А вопрошать на StackOverFlow по объектной модели Excel в VBA - не принято.
2) Весь стек VB (включая даже .Net) нужно считать VBA-совместимым.
Добавление Питона в VBA - добавит популярности обоим языкам, синергия...
> Этим людям некогда сраться на форумах, с английским в этой среде туговато, а о том как встречают в рунете российских "прикладников" - хорошо известно, где пользователей бейсика считают недолюдьми.А, теперь всё понятно, о распространенности и потребности в ЯП во всем мире ты судишь по своим трем с половиной знакомым. С таким образом мышления ничего удивительного, что вместо падения доли у тебя получается какая-то синергия.
Тем не менее тут плюс-минус проценты. Но общий график падает, разработчиков становится меньше? Т.е. можно учесть демографические данные, тогда индусов-китайцев становится больше, а других - меньше.
> Но общий график падает, разработчиков становится меньше?Ага, сильно меньше 100% стало. ☹
Иди математику учи, каникулы скоро закончатся.
Оговорка по фрейду: не учёл выползней снизу. Нормальных разработчиков таки меньше.
А матику я учил последний раз 10 лет назад.
Что-то не понятно кому достались проценты при провале Java и C в конце графика.
Прям как на выборах.
Размазались тонким слоем. Даже эрланг подрос, что для меня сюрприз.
> Тем не менее тут плюс-минус проценты. Но общий график падает, разработчиков становится
> меньше? Т.е. можно учесть демографические данные, тогда индусов-китайцев становится больше,
> а других - меньше.Возможно, меньше становится интереса и гуглежа. Да и то – нужно смотреть все данные целиком, а не только графику топ-10. Вполне возможно банальное улучшение, "оптимизация" или еще что-то выдаваемых результатов поисковиками. Они ведь там банально считают количество результатов по запросу:
https://www.tiobe.com/tiobe-index/programming-languages-defi.../
> The ratings are calculated by counting hits of the most popular search engines. The search query that is used is+"<language> programming"
> The number of hits determines the ratings of a language.
>
Интересно кто и что пишет на Visual Basic .NET, крайне редко сталкивался с кодом на этом языке. Про Go тоже странно, что он так упал, казалось всё более хорошее про него пишут и начинают принимать всерьёз... А R-да, мог бы быть гораздо получше, но лучше ничего нет.
Visual Basic .NET - госструктуры
> Visual Basic .NET - госструктурыСмотря какие госструктуры. В ВГТРК например сплошной C#.
С Go - хайп ушёл более-менее, вот и стало меньше упоминаний. Своё место он уже явно нашёл.
Ну так документацию все в ссылки забили, книжки купили - вот и нет запросов больше.
Ну, или похелловордили и решили: "А, ну его нафиг!"
> Ну, или похелловордили и решили: "А, ну его нафиг!"Ну я консоль для управления кластером 1С написал. Криво конечно вышло, прям node.js - но быстро.
Почему в тексте новости умалчивают о небывалом росте позиций языка Scratch? Все на Scratch!
Ну а что общество имеет сказать на счёт рейтинга СУБД? :)
А что там говорить - результаты предсказуемы
> Ну а что общество имеет сказать на счёт рейтинга СУБД? :)То, что memcached - не СУБД
Если забить в гугл «How to drop Oracle», то по мнению TIOBE рейтинг СУБД Oracle вырастет. Вот и всё, что нужно знать об этом методе оценки популярности.
А чем он плох? Запрос How to drop Oracle как раз и говорит о том, что прямо сейчас у тебя продукция Oracle.
> А чем он плох? Запрос How to drop Oracle как раз и
> говорит о том, что прямо сейчас у тебя продукция Oracle.потому что это никак не связано с популярностью. а только с количеством проблем.
Вы как-то узко и близоруко мыслите. Если будет много запросов «How to drop Oracle», то будет и НА ПОРЯДКИ меньше запросов (обобщенно) «How to work with Oracle» и соответственно Оракл не будет популярным по этой методике.
User: g "why <your favorite language> is shit?"
Google: ok, <your favorite language> +1
TIOBE: yay, <your favorite language> +1!!!... /0
И это правильно. Про то, что полный shit, даже не гуглят и название забыли.
Так ведь и говорят о популярности, а не о "хорошести". Вы самостоятельно, в своей черепной коробке, подменяете понятия и переделываете "Рейтинг популярности" в "Рейтинг самых замечательных языков", а потом обвиняете составителей в ху..вой методике. Популярность бывает разной.
Извините, сэр.
Не хочу ни на что намекать, сэр.
Но мухи не ошибаются, сэр.
> Извините, сэр.
> Не хочу ни на что намекать, сэр.
> Но мухи не ошибаются, сэр.Это вы жабку и сишку с питоном с этим самым ... с мёдом сравнили?
В чем смысл?
Т.е. если язык не требует гуглить каждую функцию, а все делается с помощью нормального IDE, то у него низкая популрность?
с точки зрения вот этого топа - да.
Топ глупый, но он есть.
> Т.е. если язык не требует гуглить каждую функцию, а все делается с
> помощью нормального IDE, то у него низкая популрность?А отдельные функции многих из этих языков мало кто гуглит. Чего вы все прицепились именно к документированности языка? Все они более-менее нормально документированы. Гуглят обычно уже готовые (не библиотечные) КУСКИ гoвнoкода для всяких там обращений к веб-сервисам и базам данных и находят их на всяких Stackoverflow
Надо полагать, MySQL теряет баллы потому, что её выпилили из Debian в пользу MariaDB. По идее, на уровне SQL эти обе БД должны быть практически идентичными. Было бы круто, если бы они ещё в SQL умелиЛюбопытна ситуация с PostgreSQL. Я его тыкал мало, но впечатления пока исключительно приятные.
Видимо, Oracle теряет баллы в связи с ценовой политикой. Ещё мне дико не нравится процесс установки ораклиного клиента: меня удивляет ситуация, что в 2018 году клиент ставится сложнее, чем apt-get install. Для тех, кто не в теме: регаемся на сайте oracle, логинимся, выкачиваем zip-архивы с бинарниками и заголовочниками, отдельно гуглим инструкцию, куда что распаковывать, какие конфиги править. Но deb-пакет можно собрать один раз и более не заморачиваться, так я и сделал. Под Windows то же самое. Ребята повёрнуты к клиенту (_нуж|ным_) местом.
Но в SQL они умеют, работать Oracle исключительно приятноПо поводу MSSQL ситуация двойственная. Дело в том, что к самому серверу претензий нет. А вот freetds ущербен. Как думаете, только на какой платформе работает родной драйвер?
С удивлением отметил, что Firebird очень даже торт. Да, он хоть и тупенький, но в SQL умеет, в отличие от MySQL. В 3.0 оконные функции завезли: теперь заживём :)
> меня удивляет ситуация, что в
> 2018 году клиент ставится сложнее, чем apt-get install. Для тех, кто
> не в теме: регаемся на сайте oracle, логинимся, выкачиваем zip-архивы с
> бинарниками и заголовочниками, отдельно гуглим инструкцию, куда что распаковывать, какие
> конфиги править.Нет ничего удивительного что в 2018 году люди как не читали инструкции по установке так и не читают.
Делают нечто, что кажется им умным и правильным.. удивляются... потом пишут о своих открытиях на форумах..Для 12-й базы вам сюда: https://docs.oracle.com/database/121/LADBN/#CJABJBAI
Найдите в списке debian.
Для сертифицированных же систем- все ставится элементарно.
Элементарно это "yum install oracle-server" или "apt install oracle-server". Многостраничная же инструкция с кучей предварительных действий для _сертифицированных_ линуксов, последующим ручным скачиванием и запуском инсталлятора это ни разу не элементарно. А при желании использовать БД из скриптов на любимом ЯП на всё том же сертифицированном линуксе вас ждет еще одна порция секса, отдельная для каждого ЯП.
обычно после того как вы сделали "yum install oracle-server" - вы его покупаете. если он вам конечно нужен.
а для продукта за который вы платите несколько миллионов ежегодно подобные претензии- ну..знаете..как говаривал Жеглов - "у нищих слуг нет"
Интересная картина. Бесплатный продукт удобен в установке и использовании. А продукт стоящий миллионы(чего именно?) в год почему-то крайне неудобен в установке и использовании. Геморрой за деньги это очень оригинальный подход. В большинстве подобных случаев картина обратная, люди платят деньги за удобство, а не его отсутствие.
> Элементарно это "yum install oracle-server" или "apt install oracle-server". Многостраничная
> же инструкция с кучей предварительных действий для _сертифицированных_ линуксов, последующим
> ручным скачиванием и запуском инсталлятора это ни разу не элементарно. А
> при желании использовать БД из скриптов на любимом ЯП на всё
> том же сертифицированном линуксе вас ждет еще одна порция секса,
> отдельная для каждого ЯП.А еще знаете, обычно когда человек жалуется на _подобные_ сложности - ему советуют нанять специалиста :)
Осталось узнать, что же делать самому специалисту.
Срубать бабло, потом с умным видом отвечать что "система так не работает" и уходить гордо виляя задом. Оракл жы.
Мне, кстати, интересно, зачем они в следующей версии MySQL выпиливают кэш запросов. Неужели познали дзен и решили что перфоманс не имеет значения
В мире любителей халявы- это возможно и так. а в отношении Оракл - где и как оно работает известно заранее. Читайте документацию до начала использования а не собственные выдумки :)
>> тупенький, но в SQL умеетЗвучит как про FoxPro (ака dBase). Поясните, что для вас SQL
Скратч господа! Именно то, что вам нужно в XXI-ом веке.
А где же Tcl ?http://tclstudy.narod.ru/articles/doubletea.html
А теперь давайте прислушаемся к обоснованному мнению настоящего программиста, первого лауреата премии АСМ Брайана Кернигана (В. W. Kernighan, далее - BWK), автора знаменитого языка программирования С: "Tcl/Tk придает работе магическую продуктивность, за несколько часов можно достигнуть тех же результатов, что за дни или недели при разработке на C или C++ ... . Tk весьма эффективен для большинства приложений, многие элементы интерфейса (виджеты) реализованы настолько хорошо, что остается только удивляться, как подобная работа могла быть выполнена так качественно... Удачным кажется и то, что разделение задач между Тсl и С/С++ осуществляется достаточно легко, надо только знать, какой инструмент лучше справляется с задачей... Расширение системы дополнительным Tcl-кодом, загружаемым напрямую в Tcl-библиотеку приложения, в полном согласии с оригинальной идеей Остирхоута, повышает эффективность программы в целом, упрощает ее структуру и улучшает мобильность... Я не уверен, что Тсl мог бы выжить, как самостоятельный продукт - у него слишком много конкурентов. Но у сочетания Tcl/Tk в Unix-мире нет конкурентов... Система исключительно надежна, очень хорошо документирована... свободно доступна... безукоризненно высокого качества".
Адепты на #tcl во FreeNode сказали, что это из-за методологии TIOBE - он считает поисковые запросы "<language> programming", а для Tcl обычно ищут scripting, а не.
А чойта мемкэш,эластиксёч и другие инструменты стали СУБД?