Python — мова програмування 2024 року за версією TIOBE

💡 Усі статті, обговорення, новини про Java — в одному місці. Приєднуйтесь до Java спільноти!

Python виявився мовою 2024 року за індексом ТІОВЕ. Ця нагорода видається мові, які отримала найбільший приріст популярності протягом року.

Цьогорічне зростання популярності склало пристойні +9.32%, залишивши далеко позаду Java (+2.3%), JavaScript (+1.4%) і Go (+1.2%).

В свою ж чергу місця з 2 по 5 зайняли С++, Java, C та C# відповідно.

Цікаво, що мова C, яка колись була на піку популярності, поступилася молодшому братові C++, котрий, у свою чергу, відчуває дихання в спину від Java, адже їх розділяють лише 0.14%.

Помітною зміною стало і те, що PHP остаточно вилетів із ТОП-10, поступившись місцем Go. Невже РНР вмер? (знову).

На 2024 рік покладали великі надії на Rust і Kotlin. Хоча програми на Rust демонструють значну швидкість виконання, складність мови не дозволила їй здобути широку аудиторію. Тим часом Kotlin став справжнім розчаруванням року, втративши позиції навіть у ТОП-20.

Якщо зазирнути ще нижче, на 61 та 68 місця, то можна побачити дві нові перспективні мови: Zig та Mojo, які піднялися з 149 та 194 місця відповідно. Чи вдасться їм потрапити до ТОП-20 у найближчому майбутньому? Побачимо згодом.

А яка мова програмування імпонує вам більше? Python дійсно заслужив свій статус чи це лише прояв хайпу?

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Idris, Agda, але їх немає у списку взагалі.

Якщо хтось планує йти на співбесіду або проводить співбесіди по Python — welcome
dou.ua/forums/topic/51528

А Haskell вище за TypeScript. Просто є регіональні особливості, наприклад, програмістів MATLAB більше набирають в США, бо там більше людей з потрібними дипломами.

але все-таки
1/ MATLAB все-таки заточений під специфічні задачі, яких мало б бути меше, ніж тих, для яких можна використати Ruby
2/ Ruby безкоштовний — скачав і працюй, а ціни на MATLAB дуже високі — $95 за домашню ліцензію це ж абсолютно непідйомно
3/ Безплатних курсів і тренінгів дуже мало, в основному introduction і fundamentals, більш просунуті знову ж таки за окрему плату

1/ MATLAB все-таки заточений під специфічні задачі, яких мало б бути меше, ніж тих, для яких можна використати Ruby

Це так, саме тому популярність MATLAB менше, ніж Java. Але є ніша, де він використовується, конкуренти можливо Python та R, тобто їх теж не дуже багато.

2/ Ruby безкоштовний — скачав і працюй, а ціни на MATLAB дуже високі — $95 за домашню ліцензію це ж абсолютно непідйомно

$95 це непідйомно? Навпаки, є університети, які платять за ліцензії, що створює постійний попит. Якщо ти платиш за MATLAB, то скоріше за усе тобі буде досить важко його замінити.

3/ Безплатних курсів і тренінгів дуже мало, в основному introduction і fundamentals, більш просунуті знову ж таки за окрему плату

Це показує що існує попит. Користь від курсів сумлінна. А так документація у відкритому доступі, коли я працював з MATLAB, то щоб освоїти його мені її вистачило з головою.

Проблема Ruby у тому, що він програє конкуренцію іншим мовам (не MATLAB) у своїй ніші. Тому ж Python, який теж безкоштовний. А MATLAB більш менш утримує позиції у своїй ніші, де безкоштовних конкурентів не так щоб й забагато.

$95 це непідйомно? Навпаки, є університети, які платять за ліцензії, що створює постійний попит. Якщо ти платиш за MATLAB, то скоріше за усе тобі буде досить важко його замінити.

Ну там не 95, там 95 + 30 за кожен тулбокс, сам голий матлаб нафіг нікому не треба, весь сенс в тулбоксах, і кожен тулбокс коштує 30 доларів, і комплектація програми під якісь нейромережі вийде в доларів 300. Але Матлаб він як вінда, коштує дорого, але крякається за 10 секунд і ти отримуєш повноцінну робочу програму.

На університетські ліцензії купа обмежень щодо кількості юзерів, випуску продукту і т.д.
Ціна як для просто для себе, спробувати в прииципі чи в вільний час якісь там пет-проекти пописати — ну так, а навіть якщо і підйомна при відповідних великих доходах, то це все одно на $95 більше, ніж у випадку будь-якої іншої мови з рейтингу
Скоріше це показує, що MathWorks в принципі не переймається за звичайних користувачів і популяризацію мови серед них. Є кілька великих корпорацій + університети для навчання і науковці для досліджень, які і ліцензії куплять, і просунуті тренінги — цього більш ніж достатньо.

Скоріше це показує, що MathWorks в принципі не переймається за звичайних користувачів і популяризацію мови серед них.

А навіщо вона звичайним користувачам? Це як казати, що виробники електронних мікроскопів не переймаються за дітей. Вони пропонують складний унікальний контент, якщо ти в ньому зацікавлений — купляєш. Якщо ні — ну пиши на Ruby розв’язання диференційних рівнянь. Не кажучи про те, що досить просто знайти на торентах усе що треба безкоштовно.

Скоріше це показує, що MathWorks в принципі не переймається за звичайних користувачів і популяризацію мови серед них.

Як це не переймаються, якщо майже всі інженерні спеціальності пов’язані з електронікою вивчають матлаб в університетах. Матлаб розповсюджується класичним для такого софта способом, просто підсаджують студентоту на свій продукт, а студент потім приходить на підприємство і вимагає робоче місце з матлабом.

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

Це не відповідає дійсності. Нові Статті які мають відношення до Deep Learning-у це за замовчанням Python, ніхто особливо не переймається Matlab-ом в контексті DL, хоча інтерфейси для Matlab-у існуючи. До речі в часи до Deep Learning-у статей пов’язаних з Computer Vision було помітна кількість з публічним кодом на Matlab—і. Так що успіхи Matlab-у мають іншу причину.

Ну основний успіх, що там модельно-орієнтований підхід проектування. Там же можна зробити все що завгодно в тому матлабі, хоть картинки опрацювати, хоть систему літака змоделювати. Там один з найпопулярніших екзамплів, це система наведення ракет. Ще можна генерувати код для плісок, і ще багато чого, гігантський інженерний комплекс.

Python — найгірша мова з того з чим доводилось мати справу, js стандарту ecma script 3 і то далеко попереду. Кому прийшло в голову використовувати строго динамічно типізовану мову для дата саєнс задач, мову з компайлер локом в основній імплементації без підтримки нативно асинхронної моделі програмування для бекенду.., страшний менеджмент залежностей, що падає в рантаймі і сумісність версій пакетів все це додавання івент лупів запізніле, анотацій типів, кострубатої інкапсуляції, тулінгу для менеджменту версій пакетів типу conda, і побудова бібліотек для роботи з складними багатомірними структурами данних типу tensorflow це ганьба для сучасної індустрії розробки.

Цікаво, чим ес3 попереду пайтона? Тільки в ес5 добавили методи для роботи з джейсоном, а до того джаваскріпт взагалі нікому не був потрібен. А так то джаваскріпт таке саме лайно, як і пайтон, з абсолютно такими ж самими болячками.

Ніби почав тренд Алекс Крежинскі з університету в Торонто. В дійсності для потреб AI/ML, вчені математики не вважають Python поганим, а навпаки кращім, навідміну від професійних програмістів які більше до C++.
Справа в тому, що плата за абстракції їх влаштовує і компроміс із MATLAB на видалений фреймверк з банальним інтерфейсом до С++/[CUDA/OpenCL] і т.д. Якщо би були інструменти де взагалі не треба програмувати, їх би це ще більше влаштовувало, програмування для прикладної математики це другорядне. А Python із його абстракціями, які не дозволяють типові базові помилки кодування, дозволяє дуже швидко міняти щось під екскременти і т.д. виявилась чудовим вибором. Купа особливостей які роблять Python, скажімо не дуже добрим скажімо для Backend або mobile, для Data Since AI/ML не є проблемою. Там проблема в занадто складних програмах та коду, за яким втрачається ясність абстракцій — операцій на тензорами наприклад. Складність програмування, було проблемою скажімо для Caffe, доки до нього не було створено frontend на Python. Це дозволяє прикладним математикам, концентруватися на своїй безпосередній задачі із обробки данних — а не на програмуванні.
Так само JavaScript — це чудова скріптова мова, для того для чого вона задумувалася — сценарії для web сторінок. Та для низки задач — мова повністю не підходить.

Ну так і є, пітон як і жабаскріпт ідеальна мова, щоб щось швидко наговнякати в рандомному стилі і воно буде працювати, інші мейнстрім мови так не вміють, ліспи ще вміють, але більшіть про ті ліспи й знать не знає. Чисто дві сокири, можна і дрова нарубати, і тушонку відкрити, і в якості зброї застосувати. Універсальні солдати.

Ну там якраз навпаки, і на JS і на Python при мінімальному вмінні виходить дуже красивий для своїх, задач код. Простий лаконічний і одночасно, скріптовий. Тобто це інтерфейс до нативних функцій базового фреймверку. Так коли на цьому пишуть, наприклад движок 3D гри — то вже не то пальто (багато движків мають середені так само скріптові мови, де дуже популярна Lua Script). А особливої різниці по перформансу, коли базову функцію викликає скріпт чи компільвана программа немає, перформанс в функції яка перемножує матриці. А от в підготовці — гігантська різниця. Ті кому не подобаються, pip чи npm/yarn — спробуйте написати кросплатформену програму на С++ яка має компілюватись одразу GCC, Ms Visual C++, GCC Mingw64, та Clang для Windows, Linux та Mac. От ви дізнаєтесь про танці з бубном, складнючі Cmake, складнючі CI yaml-ли і одразу зоопарк пакетних менеджерів на вибір.

Кому прийшло в голову використовувати строго динамічно типізовану мову для дата саєнс задач

Яке відношення типізація має до задачі, що вирішується?

Ну у цілому динамічна типізація характерний признак скріптової інтерпретаційної мови. LISP, Python, PHP, Perl, Ruby та JavaScript , мають саме динамічну типізацію. Вона надає можливість саме інтерактивної взаємодії, не треба нічого компілювати. Просто водиш текст десь, натискаєш ввод в і інтерпретатор сам створює структури данних в пам’яті. Так це одночасно для розвинутих програм, які мають ознаки закінченого продукту із тисячами а то і мільйонами строк коду, навпаки погано — бо нема можливості робити тонку і сквозну оптимізацію, робити перевірки сумісності типів видаючи помилки компілятора та вонрнінги і т.д. Крім того динамічна типізація — це одразу плата за абстракції, тобто і пам’ять і CPU. Це і фаза трансляції безпосередньо під час роботи програми і або GIL як в CPython, або клонування контексту в кожний потік, різні JIT, збірка сміття, додаткові структури в пам’яті задля збірки цього самого сміття і т.д. Тобто програмувати звісно легше, та программа програє в ефективності. На практиці усе залежить більше від програміста, бо від не ефективного програмування не захищає навіть ассемблер. В Python у вас скажімо з коробки ефективний Tim Sort, і програміст просто викликає функцію sort. А в ассемблері можна зробити що завгодно — а коли треба на позавчора і прикладним математиком, ну в кращому випадку наївна реалізація Qsort там і буде, на який втрачено тиждень роботи.

Вона надає можливість саме інтерактивної взаємодії, не треба нічого компілювати.

Для вчених це плюс. Натиснув — отримав результат. (Див. Jupyter Notebook).

программа програє в ефективності

Там де треба швидкість, там пакети Python працюють як обгортка до Сі-бібліотек. (Див. NumPy, SciPy, OpenCV).

Яке відношення типізація має до задачі, що вирішується?

додає зручності інструменту для вирішення задачі?

типові приклади data scientist:
1. Прочитати данні, зробити очистку дата сету і фіча інженерінг на pandas. (зазвичай передбачає на етапі экспериментів роботу з різного типу константами(строки, числа) і різних сорців часто(текст, апі, бази і т.д.).

Python experience (dynamic, strong):
мова не конвертує типи при порівнянні зі строками 1 == «1» (false), що це значить — у випадку відсутності анотацій код відпрацює, інтерпритатор все зробить, але віповідь на векторизованих операціях з датафреймами буде пустота — доволі часта історія.

JS experience (dynamic, weak)
мова конвертує безпечні операції 1 == «1» (true), це покриє більшість кейсів роботи з категорійними данними чого зазвичай доволі багато. назважаючи на відсутність compile check в цілому треба буде менше часу витрачати на пошук очевидних проблем які логічно могли бі працювати з коробки.

Java experience (static strong)
завалідує на етапі компіляції всі типи і попросить виправити помилки і отримати потрібний результат.

2. Відправити датасет для тренування моделі, або передачі данних між слоями нейромережі. Частіше за все передбачає зміну типів або навіть частіше розмірностей наприклад тензорів.

Python experience (dynamic, strong):
мова не буде в дефолтній поведінці нічого валідувати що стосується розмірності і типів — запуск такого тренування призводить в кращему випадку до незрозумілої помилки в глибині коду бібліотек десь на зовсім іншому етапі ніж місце винекнення помилки, гіршому буде видавати невірний результат по статистичним показникам моделі. Завзичай вирішення таких проблем зводится до годин витраченого часу на спрошення коду, відладку, розбір тензорів розмірність котрих когнітивно людині опрацювати доволі складно.

JS experience (dynamic, weak)
в цьому випадку проблеми будуть подібними до python, але з причин у попередньому пункті є шанс що очевидних проблем незручного\логічного дизайну мову буде менше.

Java experience (static strong).
всі розмірності і типи завалідує компілятор.

Java experience (static strong)
завалідує на етапі компіляції всі типи і попросить виправити помилки і отримати потрібний результат.

Ну... якщо у нас є csv, наприклад, то як ти перевіриш на етапі компіляції, що типи стовбців задані коректно? Аналогічно отримаєш помилку в рантаймі.

мова не буде в дефолтній поведінці нічого валідувати що стосується розмірності і типів — запуск такого тренування призводить в кращему випадку до незрозумілої помилки в глибині коду бібліотек

Якби так було, ніхто би не писав на Python. Бо саєнтісти у більшості не дуже добре працюють з пошуком проблем в глибині бібліотек. Зазвичай ти отримуєш помилку, що в тебе дані неправильної розмірності, очікується вектор з 10-ти, а у тебе 11-ть. А чим тут Java краще? У тебе ж довжина масиву не є властивістю типа, там де можна передати масив з 10-ти елементів, там можна і з 11-тю, і ти знову отримаєш помилку в runtime.

то як ти перевіриш на етапі компіляції, що типи стовбців задані коректно?

Ніяк. Тому що ані динамічна, ані статична, ані магічна типізація не звільняють від перевірки даних при введені в памʼять. :)

Ніяк. Тому що ані динамічна, ані статична, ані магічна типізація не звільняють від перевірки даних при введені в памʼять. :)

ви походу нічого не зрозуміли — перечитайте ще раз уважно. Кейси вище не стосується десереалізації і перевірки помилок в данних взагалі — це порівняння строк з константами у коді і на логічних операторах поведінка мови для різних типів.

мова не конвертує типи при порівнянні зі строками 1 == «1» (false), що це значить — у випадку відсутності анотацій код відпрацює, інтерпритатор все зробить, але віповідь на векторизованих операціях з датафреймами буде пустота — доволі часта історія.
import pandas as pd
import numpy as np
df = pd.DataFrame({'ID': [1, 2, 3], 'Age': ['25', '30', '35']})  
df = df[df['Age'] == 30]
print(df.to_json())
-->
{"ID":{},"Age":{}}
у випадку відсутності анотацій код відпрацює

Наявність анотацій ніяк не впливає на виконання інтерпретатором.

>>> a: int = 1
>>> b: str = "1"
>>> a == b
False

Анотації впливають на поведінку IDE та type checkers, наприклад mypy.

Використання анотацій та mypy знайде проблему з int == str

UPD: для перевірки треба увімкнути strict-equality:

 % mypy --strict-equality example.py example.py :4: error: Non-overlapping equality check (left operand type: "int", right operand type: "str")  [comparison-overlap]

само собою(можна ще глянути як виглядають паблік апі більшості повязаних ліб і власне працюють векторизовані операці — їм чхати на ваш лінтер і анотації) — тільки справа в тому, що js це зробить конвертацію автоматом, а java дасть ошибку компіляції в дефолтному варіанті. у випадку з python будет найгірший варіант поведінки у ванільному варіанті — все відпрацює і дасть False для датасаєнтиста це вище приклад де одразу вимагає єкстрачасу на пошуки проблеми, особливо коли цих датафреймів багато і вони збираються в різних місцях із різних сорців.

import pandas as pd
import numpy as np
df = pd.DataFrame({'ID': [1, 2, 3], 'Age': ['25', '30', '35']})  
df = df[df['Age'] == 30]
print(df.to_json())
-->
{"ID":{},"Age":{}}

Динамічно строготипізована мова — це найгірше поєднання яке може бути для багатьох випадків, а для data science це взагалі жах. гіршої мови і рантайму в світі важно буде відшукати.

а java дасть ошибку компіляції в дефолтному варіанті

Ви плутаєте про перевірку на етапі компіляції (або type checking, тому що в Пайтоні немає компіляції) та валідації типів в рантаймі.

Ви плутаєте про перевірку на етапі компіляції (або type checking, тому що в Пайтоні немає компіляції) та валідації типів в рантаймі.

тому я дав ще один приклад — js, теж інтерпитатор і теж набагато логічніший/зручніший.

у випадку з python будет найгірший варіант поведінки у ванільному варіанті — все відпрацює і дасть False

Для цього в Python з версії 3.5 (вже як десять років) зробили анотації типів.

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

'Age': ['25', '30', '35']

Це приклад GIGO: "

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

"

до чого тут введення в память і однакова поведінк мов, коли поведінка незручна на етапі виконання векторизованої операції і порівнення з іншими мовами які б це вирішували б набагато краще.

df = pd.DataFrame({’ID’: [1, 2, 3], ’Age’: [’25′, ’30′, ’35′]})

Це приклад трохи з вакуума. Там взагалі pandas не потрібен, можна написати '30' == 30. На практиці ти будеш читати DataFrame з файлу, подивимося

In [1]: import pandas as pd

In [2]: df = pd.read_csv('test.csv')

In [3]: df
Out[3]: 
   ID  Age
0   1   25
1   2   30
2   3   35

In [4]: df = df[df['Age'] == 30]

In [5]: df
Out[5]: 
   ID  Age
1   2   30

In [6]: !cat test.csv
ID,Age
1,25
2,30
3,35

все прекрасно автоматично задетектилося. А який буде аналог цьому на Java? Тобі треба або ORM на CSV, при цьому їх може бути десятки з різною структурою. Або все буде аналогічно Python, типи визначаться у runtime та ніякої допомоги під час компіляції не буде.

Ну незовсім ніяк, в сенсі, що частково технічно можна зробити, скажімо перевірку до безпосереднього мапінгу на доменні моделі в программі. Для цього і вигадали проміжні структури які описують формати : IDL (MS, CORBA і т.п.), XML Schema, OpenAPI/Swagger, jsonix schema, gRPC і т.д.
Тим не менше программи які перевірятимуть усі данні, як введені користувачем так і скажімо неконсистентні файли, стають надскладними. Тим не мнеше це треба враховувати, скажімо і Blender і Maya можуть екпортувати 3D моделі в COLLADA форматі (XML) — але один і той самий код усеодно не завантажить нормамально модель в 3D рушій, і там треба буде робити трохи різний код, при абсолютно валідному по специфікації XML в обох випадках.

Де добре, коли структура фіксована. На практиці може бути десятки різних csv з різних джерел, і на кожний заводити структуру накладно. Особливо якщо використовуєш його один раз.

Якби так було, ніхто би не писав на Python. Бо саєнтісти у більшості не дуже добре працюють з пошуком проблем в глибині бібліотек. Зазвичай ти отримуєш помилку, що в тебе дані неправильної розмірності, очікується вектор з 10-ти, а у тебе 11-ть. А чим тут Java краще? У тебе ж довжина масиву не є властивістю типа, там де можна передати масив з 10-ти елементів, там можна і з 11-тю, і ти знову отримаєш помилку в runtime.

dimensionality це не array length, це кількість розмірності массиву(як найближчого аналогу), 7 ми мірний тензор буде в java виглядати ось так якось — double[][][][][][][] tensor; і спроба передати 6-ти розмірний тензор це будет compile time error. навідміну від python
для java поняття dimensionality власне так саме працює — дивно трохи це пояснювати людині яка займається прогрумуванням чим розмірність відрізняється від кількості елементів коллекції..

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

Плюс я не кажу, що double[][][][][][][] tensor ніхто на Java скоріше за усе писати не буде, бо у тебе відразу відривається вікно для

double [] [] data = { {1, 2}, {3}}; // Другий масив різної довжини.

Тому виходить, що треба юзати додаткові ліби, і я не впевнений, що там будуть окремі класи для тензорів для будь-якого shape. Скоріше за усе все буде як в Python, бо це зручно. Проблема різної довжини та неправильного shape це 95%. А от проблема, що взагалі не та розмірність майже не виникає.

НЕ кажучи про те, що розрахунки зручніше писати пооператорно, з візуалізацією кожного кроку, і там взагалі неважливо runtime чи compiletime.

double[][][][][][][]

Це буде такий сами blob як і в Caffe, Tensorlow чи PyTorch, як в С/C++ double *, який оброблятиметься відеокартою.
Робиться це через ByteBuffer, тут можна почитати один з варіантів як dou.ua/...​-video-card-capabilities
От колега написав вже вискорівневу частину dou.ua/forums/topic/50426

у випадку відсутності анотацій код відпрацює, інтерпритатор все зробить

Анотації типів в Python ніяк не впливають на виконання інтерпретатором. Тобто одна й та сама програма з анотаціями та без працює однаково.

Прочитати данні, зробити очистку дата сету і фіча інженерінг на pandas. (зазвичай передбачає на етапі экспериментів роботу з різного типу константами(строки, числа) і різних сорців часто(текст, апі, бази і т.д.).

Прочитати дані з файлу (CSV) — це робота з рядками (парсинг), його треба робити в будь якій мові Python, JavaScript, Java, C, ... Яке це має відношення до типізації?

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

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.”
― Bjarne Stroustrup, The C++ Programming Language

Fortran, Delphi, Scratch. Це точно 2024?

Scratch

а с ним что не так? дети учатся, популярная для самых маленьких

Ну так всі дьоргають математичні ліби які написані на фортрані, а їх ще й правити періодично треба.

Мені імпонує Go. Через 5 років буде в топ-3. Скріньте.

5 років тому місцева секта го обіцяла наче щось подібне. Щось не склалось?

Обіцяли топ-10, результат вище.

Go — красунчик. Ще-б гугложмоти вкрутили дженерики, то була-б краса.
Поки придивляюсь, але відчуваю, що тре йти в Go-пники, бо рідна Джавуля, як не крути, а JVM мова, і деякі речі там працюють недосконало в принципі, і це не обійдеш і не перестрибнеш, бо така там робота з пам’яттю.

Ще-б гугложмоти вкрутили дженерики

пан из какого года пишет?

май фолт, все змінюється на краще
go1.18 (released 2022-03-15)

Вони вже є, тільки вони не нада.

TIOBE Index, це по суті не загальний комплексний індекс, а індекс сучасного попиту. Оскільки зараз уся індустрія в тренді AI, оскільки модно в нього пішов увесь бізнес із експертизою і без, то і мода на Python. C++ теж друга мова, яка використовується в AI. Є інші індекси і рейтинги, які рахують якісь інші показники типу загальна кількість написаного коду і т.п.
DOU наприклад міряє пропозицію на Українському аутсорс ринку, вона звісно JavaScript оскільки Україна здебільшого пропонує Frontend та Node. Купу народу з них випускали чисельні курси, через відносно нижчий поріг входу за інші технології Frontend є наймасовішим.

TIOBE Index — це індекс перспективності, а не індекс попиту. Є інші популярні індекси, які міряють попит/популярність, як, наприклад, PYPL, в якому перша 5-ка також не сильно відрізняється від 5-ки перспективності зі статті. А от в 20 PYPL уже є і Котлін, і Раст і тд, бо про них все ще пам’ятають.

Так і в TIOBE і Rust і Kotlin, та навіть Visual Basic та Delphi/Object Pascal в першій 20-ці, разом зі Swift.
Сама мова програмування на справді це як не дивно другорядне, на тому же Swift або на Java, рівно як і С++ чи C# і абсолютно точно Python, можна наприклад писати кросплатформені десктопні аплікації. І що ? Ясно же що зараз Python, тільки тому популярний — що він фротєнд мова для Tensorflow та PyTorch, а Django це для створення Web доступу, чи частіше навіть просто виклики API для ChatGPT або Gemini. Коли на Python писали скажімо Anaconda чи YUM, DNF та APT — це була нішева хакерська мова, не сильно кому цікава з репутацією типу D чи Rust на сьогодні.

Пропустив слово. Малось на увазі, що раст та котлін вище по популярності, ніж по перспективності (це до того, що в статті пишуть, що ці мови розчарували і опустились вниз в рейтингу).

Ну і пайтон, напевно, не стільки популярний із-за пайторча/тензорфлоу, а із-за того, що нода сильно просіла і всі полізли назад в пайтон та рубі.

Дивлячись як сильно Mozilla Foundation та JetBrains і Google, будуть маркетингово вкладатись в мову і засоби розробки. І Rust і Kotlin мають як свої переваги так і недоліки, в порівняні із Modern C++ та Java 21+.
Доки, маркетинг Microsoft та Open AI зробив із безумовно цікавої теми (я цим займався у якості хоббі вже давно) AI/ML відвертий хайп.

Mozilla дуже круто вкладається в розвиток своєї мови. Гугл також не пасе задніх.

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

Ну, ван Россум навряд чи відмовився від того, щоб лобіювати пайтон поки сам працював в Гуглі як мінімум всередині компанії. В СS50 теж вибрали пайтон, а зважаючи, що ’ratings are based on the number of skilled engineers world-wide, courses and third party vendors’, це вже топ-5 гарантоване.

Я вже про це писав в іншому коменті тут на доу, але Гвідо покликали в Гугл тільки для того, щоб в гуглі мали змогу швидко запилювати в пайтон те, що потрібно їм. Але не врахували его Ван Россума і під кінець розісралися. Ну, а в CS50, то основна мова завжди була Сі. Можливо останні роки фокус трохи змістився в сторону пайтона і джаваскріпта, але Сі все ще всьому голова.

він, до речі, зараз в Майкрософті, тепер буде просувати пайтон вже з їх допомогою

Підписатись на коментарі