Python będzie językiem numer jeden po 2020?

Ostatnio tak przeglądam youtube i we wszystkich tych rankingach Python od 2020 roku prowadzi i jest numer jeden. O co tu chodzi?

Jeszcze niedawno Python to była nisza, a JavaScript był język, którego nikt nie brał na poważnie.

A teraz Python króluje, a JavaScript rządzi (chociaż dalej nikt nie bierze JSa na poważnie, to taki Trump języków programowania).

Pytanie więc, co będzie numer jeden w 2030 roku?

Pewnie język programowania, który już istnieje, ale który obecnie jest niszą i którego nikt nie bierze na poważnie. I tego języka X pewnie trzeba się uczyć już dzisiaj, żeby za 5-10 lat być królem programowania (tylko jaki to język?).

O co tu chodzi?

obstawiam, że o boom związany z machine learning, do którego często się używa Pythona

Python dominuje skryptologię i glue code. Bardzo duża część programistów (w tym ja) coś tam klepie w Pythonie (bo lepsze to niż klepanie logiki w shellu). Jednocześnie coraz więcej nieprogramistów klepie w Pythonie, np analitycy, naukowcy, pseudo-cośtam, itd
https://www.enterprisetimes.co.uk/2018/10/10/jpmorgan-wants-its-financial-analysts-to-be-able-to-code/

Reddit czasem nie powstał w Pythonie i frameworku Pyramid, potem przepisali go do Pylon, a obecnie jest tam Flask? Przypomina mi się historia tego programisty Pythona i hakera Aarona Swartza, który przyciśnięty przez korporację popełnił samobójstwo. Z tego filmu dokumentalnego o nim, wynika tylko tyle, że stworzył backend tej stronki reddit w Pythonie i zarobił na tym kupę kasy.
Od czego to w gruncie rzeczy zależy, że dana strona zdobywa popularność? Takim klonem reddita jest nasz polski wykop i z tego co tam piszą na nim, jego twórcy potrafią zarobić kilkaset tysięcy miesięcznie. Natomiast takim stronom przypominającym wykop jak digg, strimi, trendpeaks jakoś nie udało się wybić.

Dokładnie tak jak @Wibowit napisał - wolę skrypty w Pythonie niż w shellu / powershellu. Wiele aplikacji pozwala na własne rozszerzenia w Pythonie np. Blender.
A co do tych analityków - po to mają numPy czy Pandas, by nie sięgać po np. R.

Python też jest dość przyjemny do apek webowych (o ile Flask a nie Django) i niektórzy w nim gry piszą (osobiście wolałbym do gier Lua).
Jaka będzie przyszłość trudno jednak wróżyć... Niektórzy w pehapie widzieli język do wstawiania między tagi HTMLa, a tu niedługo JIT ma być ;)

Ostatnie lata to eksplozja powszechnego stosowania machine-learning, która trafiły pod strzechy wraz z wejściem bibliotek takich jak Keras i TensorFlow i wzrostem mocy obliczeniowej, AI to teraz popularny buzzword na równi z blockchainami i każdy sklep z bananami musi implementować jakiś system rekomendacji. A Python jest tutaj dominującym językiem.

Python powinien upaść, i to zrobi, pozdrawiam cieplutko

Język gorszy wypiera język lepszy.

Choć tak po prawdzie to jesli chodzi o najbardziej popularne języki to i tak nie ma tam dobrych. Więc i nie ma nad czym płakać - lepiej Python niż JS, Perl czy PHP.

Python pozwala na takie coś:

lista=1;//typ->integer
lista="TEKST";//typ->string
lista=[];//typ->lista

Mogli by to poprawić tak, żeby zmienna lista miała na stałe przypisany typ z pierwszej definicji czyli integer.

@pie - dziwne myślałem że python jest silnie typowany

scibi92 napisał(a):

@pie - dziwne myślałem że python jest silnie typowany

Gdyby tak było to były o wiele szybszy.

ple napisał(a):

scibi92 napisał(a):

@pie - dziwne myślałem że python jest silnie typowany

Gdyby tak było to były o wiele szybszy.

Nie odróżniasz silnego typowania od dynamicznego?

Python is strongly, dynamically typed.

A kto odróżnia?

https://en.wikipedia.org/wiki/Strong_and_weak_typing

History
In 1974, Liskov and Zilles defined a strongly-typed language as one in which "whenever an object is passed from a calling function to a called function, its type must be compatible with the type declared in the called function."[2] In 1977, Jackson wrote, "In a strongly typed language each data area will have a distinct type and each process will state its communication requirements in terms of these types."[3]

Python nie spełnia żadnego z tych kryteriów. Funkcje nie deklarują żadnych typów, więc definicja Liskov i Zilles odpada. Definicja Jascksona też bo do jednego i tego samego pola można wrzucić wartości różnych typów, np najpierw liczbę, potem napis, potem tablicę i Python nie zaprotestuje (@ple pokazał to wyżej).

Variation across programming languages
Note that some of these definitions are contradictory, others are merely conceptually independent, and still others are special cases (with additional constraints) of other, more "liberal" (less strong) definitions. Because of the wide divergence among these definitions, it is possible to defend claims about most programming languages that they are either strongly or weakly typed.

I tu się zgadzam z Wiki. Można sobie tak ponaginać definicje, że wyjdzie dowolny wynik. Co niby sprawia, że Python jest stronk? To, że operator + działa tylko na stringach? Operatory and i or działają już na wszystkich typach wartości (a więc po drodze musi przynajmniej chwilowo następować konwersja implicit z dowolnego typu na booleana, a ta konwersja przynajmniej dla mnie jest nieintuicyjna, wiele razy się na tym naciąłem i teraz z automatu daję np x is not None zamiast samego x). Java ma operator + który dokonuje konwersji implicit na stringi, ale nie jest to problemem, bo Java (nadal) nie ma przeciążania operatorów. Stąd jedyne co można nieopatrznie zrobić to wyprodukować stringa, ale potem i tak statyczne typowanie wyłapie, że ktoś próbuje użyć stringa jako np typu liczbowego. Innymi słowy w obecnej sytuacji w Javie operator + w praktyce nie powoduje żadnych problemów z typowaniem (kodząc w Javie przez wiele lat nie natknąłem się na taką sytuację).

No dodali w końcu gradual typing po tylu latach, istny sukces. Ale i tak to jest opt-in. Kaczo typowany Python dalej praktycznie nic nie sprawdza.

Spine napisał(a):

Wibowit napisał(a):

Funkcje nie deklarują żadnych typów, więc definicja Liskov i Zilles odpada. Definicja Jascksona też bo do jednego i tego samego pola można wrzucić wartości różnych typów, np najpierw liczbę, potem napis, potem tablicę i Python nie zaprotestuje (@ple pokazał to wyżej).

Python zaprotestuje, tylko trzeba umieć napisać odpowiedni kod... ( https://docs.python.org/3/library/typing.html )

Kopiuj

from typing import List

ListaInt = List[int]

def IncrementIntList(lista: ListaInt):
	for i in range(len(lista)):
		lista[i] += 1

lista = [2, 3]
IncrementIntList(lista) # OK
print (lista)

lista = [5, "6"]
IncrementIntList(lista) # błąd
print (lista)

Ale z tego dostaniesz runtime error, z powodu próby dodania int do str (przynajmniej w 3.8), linia lista[i] += 1, równie dobrze mogłeś to jednolinijkowcem pokazać :-)

Type hinting, to jest tylko "hint", nie ma on wpływu na to, co zrobisz w kodzie, od sprawdzania typu masz isinstance i dopiero jak tego użyjesz, to możesz być "jakotako" pewny, że to co podałes np. do funkcji, ma właściwy typ.

Z tego co widzę to wszystkie zalinkowane filmiki przez OP traktują o najbardziej POPULARNYM języku programowania. W Polsce najbardziej popularna jest obecna partia rządząca, sami sobie odpowiedzcie o czym świadczy popularność...

Trochę śmieszny jest ten ból d**y hardkorowych Javowców czy C-sharpowców o tę dynamiczną typowalność. To celowy element designu języka, nastawionego przede wszystkim na ekspresywność, czytelnośc i szybkość pisania kodu. Type hinty tak naprawdę zaciemniają raczej kod niż mu pomagają i generalnie powinny mieć ograniczone zastosowanie, np. do implementowania walidacji danych, gdzie nie ma się faktycznie kontroli nad tym, co jest wprowadzane. Ale widać, niektórzy żyć nie mogą bez dostawania butem w twarz od rozgniewanego kompilatora na każdym kroku: daj im trochę swobody i już się gubią.

Jeszcze śmieszniejszy jest zarzut nieczytelności w związku z brakiem klamerek. Przecież każdy dobry styl programowania zaleca kolejne wcięcie po otwarciu każdego bloku dla ich ładniejszej wizualnej separacji. Wielka mi różnica między tym

if(a==5) {
    foo();
} else {
    bar()
}

a tym

if a ==5:
    foo():
else:
    bar()

No faktycznie, migrena i ból głowy.

Spearhead napisał(a):

nastawionego przede wszystkim na ekspresywność, czytelnośc i szybkość pisania kodu

To cos zajedwabiscie poszlo nie tak w tym designie ;) bo zdaje sie byc wrecz odwrotnie. Szczegolnie jesli czas debuggowania doliczyc do czasu pisania kodu.

I skoro zmienna ma reprezentowac jakis obiekt to nie wiem jakim cudem obiekt klasy foo moze sie nagle stac obiektem klasy bar gdzie foo i bar nie sa w zaden sposob polaczone hierachia.

Edit: pomijam jakies stringi liczbowe ("42") albo JSONy bo to, ze input musi byc najpierw sparsowany nie usprawiedliwia dynamicznego typowania.

To cos zajedwabiscie poszlo nie tak w tym designie ;) bo zdaje sie byc wrecz odwrotnie. Szczegolnie jesli czas debuggowania doliczyc do czasu pisania kodu.

Tak bardzo bez konkretów. Może po prostu kiepski kod w tym Pythonie wytwarzasz, że tak źle ci się go debuguje?

I skoro zmienna ma reprezentowac jakis obiekt to nie wiem jakim cudem obiekt klasy foo moze sie nagle stac obiektem klasy bar gdzie foo i bar nie sa w zaden sposob polaczone hierachia.

Hierarchia nie ma nic do rzeczy, liczy się to, co można z nim zrobić (duck typing). Ale ogólnie te całe narzekania brzmią jakby się używało w całym programie jednej zmiennej i, przypisując do niej co popadnie, od liczb przez stringi do obiekty, "ponieważ można, a język nie protestuje". No można, ale nikt normalny tak nie robi, a jak robi to i co mu się dziwić, że ma błędy i problemy z kodem. Takie trochę smutne, że najwyraźniej potrzebny jest kompilator stojący z batem nad głową, by nie przypisywać napisu do zmiennej "count"...

Kiedy przestaniesz przypisywac obiekty roznych typow do jednej zmiennej to przestaniesz potrzebowac dynamicznego typowania. Problem jest taki, ze programista sobie moze tak bez problemu zadecydowac ale "kompilator" czy IDE i tak nie ma prawa pewnych rzeczy zakladac majac do czynienia z dynamicznym kodem przez co mniej jest w stanie pomoc. Kompilator to nie wrog z ktorym sie klocisz bo Ci bledem sypnal tylko przyjaciel, ktory mowi "ej stary, chyba nie to miales na mysli..."

PS. Nie wiem jakim cudem "value: Double" jest mniej ekspresywne (i mniej czytelne) od takiego nieotypowanego "value" ;)

Spearhead napisał(a):

Type hinty tak naprawdę zaciemniają raczej kod niż mu pomagają i generalnie powinny mieć ograniczone zastosowanie, np. do implementowania walidacji danych, gdzie nie ma się faktycznie kontroli nad tym, co jest wprowadzane.

Tylko type hinty pozwalają na normalny refactoring. IDE nie będzie się bawić w zgadywanie czy metoda, której nazwę zmieniamy, należy do argumentów/pól nieznanego typu...

Spearhead napisał(a):

No można, ale nikt normalny tak nie robi, a jak robi to i co mu się dziwić, że ma błędy i problemy z kodem.

To samo można napisać o Twoim podejściu do type hintów.
Właśnie trzeba je konsekwentnie stosować, żeby potem się nie dziwić, że są problemy z kodem...
A skoro są konieczne, to już lepiej zastosować tego C#, czy Javę...

Spearhead napisał(a):

Takie trochę smutne, że najwyraźniej potrzebny jest kompilator stojący z batem nad głową, by nie przypisywać napisu do zmiennej "count"...

Jak usiądziesz do kodu jakiegoś większego systemu, to będziesz wdzięczny za każdy bat, który stoi nad programistami...

Tak bardzo bez konkretów. Może po prostu kiepski kod w tym Pythonie wytwarzasz, że tak źle ci się go debuguje?

To jest koronny argument Pytoniarzy na jakąkolwiek krytykę Pytona. Rzeczywistość jest taka, że 100% kodu w Pytonie to kiepski kod. I co teraz?

Problem jest taki, ze programista sobie moze tak bez problemu zadecydowac ale "kompilator" czy IDE i tak nie ma prawa pewnych rzeczy zakladac majac do czynienia z dynamicznym kodem przez co mniej jest w stanie pomoc. Kompilator to nie wrog z ktorym sie klocisz bo Ci bledem sypnal tylko przyjaciel, ktory mowi "ej stary, chyba nie to miales na mysli..."

Kompilator po prostu pilnuje porządku w ramach ustalonych reguł. Kwestia tego, ile tych reguł potrzebujesz, by napisać coś ponad elementarny Hello World.

Poza tym, to "co ja mam namyśli", to również pojęcie względne. Napiszę sobie funkcję, która gdzieś w środku robi coś z argumentem i wywołuję ją z argumentem, dla którego danej operacji nie ma. Język statycznie typowany na dzień dobry to zablokuje. Python rzuci wyjątek. I to jest ciągle zdefiniowane działanie, może mam serię danych, na której chcę wykonać operację, ignorując te, dla których się nie udało. Obsługuję to wyżej zwykłym try-catchem.

W ogóle to może być źródłem problemów w tych przejściach od Javy do Pythona. Przyzwyczajenie, że wyjątków powinno się unikać, że są drogie, że zwijanie stosu, etc. A tymczasem Python jawnie zachęca do tego podejścia, promując to podejście "Ask forgiveness not permission".

To samo można napisać o Twoim podejściu do type hintów.
Właśnie trzeba je konsekwentnie stosować, żeby potem się nie dziwić, że są problemy z kodem...
A skoro są konieczne, to już lepiej zastosować tego C#, czy Javę...

Ale Java i C# też mogą nie wystarczyć, bo źle będziesz zarządzał posiadaniem obiektów, więc tak w ogóle to nie powinno się nigdy pisać w niczym poza Rustem! Bezpieczeństwo nade wszystko, im więcej dupochronów tym lepiej! Znaleźliźmy w końcu jeden język by wszystkie w ciemności spętać, pytania się skończyły. Piszmy wszystko w Ruście i będzie pokój.

Reductio-ad-rustum. Kiedyś zamiast tego było reductio-ad-lisp, bo lispiarze się wiecznie spinali, że wszystko poza ich językiem to żałosne podróby i zbrodnia na honorze i godności człowieka.

Jak usiądziesz do kodu jakiegoś większego systemu, to będziesz wdzięczny za każdy bat, który stoi nad programistami...

W Javie też newbie będą tworzyć straszną kaszę, mimo wszystkich blokad.

Poza tym, głównym batem jaki powinien siedzieć nad każdym projektem, to nie język i jego reguły, a pokrycie testami.

Rzeczywistość jest taka, że 100% kodu w Pytonie to kiepski kod. I co teraz?

Rzeczywistość jest taka, że nie masz racji.

Jeśli ktoś twierdzi, że Java i Python to dwa bieguny typowania to jest głęboko w błędzie. Żaden z nich nie jest ekstremum. Za bardziej dynamiczny od Pytona uważam Lispa, który ma wbudowane makra i trakuje kod jak dane https://en.wikipedia.org/wiki/S-expression . Są też języki z dynamiczną składnią, ale nie pamiętam już jakie. Bardziej rozbudowany system typów niż w Javie / C# jest np w Scali czy Haskellu gdzie można zawrzeć reguły dotyczące zawartości danych w samym systemie typów, np https://blog.softwaremill.com/a-simple-trick-to-improve-type-safety-of-your-scala-code-ba80559ca092 czy https://www.servant.dev/ Jeszcze wyżej są języki typu Coq, Agda, Idris, etc. Java i C# to takie w miarę rozsądne kompromisy stworzone pod przeciętnego klepacza dużych systemów o niekrytycznej randze (bo np oprogramowanie do rakiet czy tomografów to raczej wymaga lepszych dowodów poprawności niż parę testów automatycznych).

@Spine: co ciekawe odróżniam, myślałem tylko że skoro Python jest dynamicznie i silnie typowany to zmienna ma raz zainicjowany typ (w runtime) a później nie zmienia swojego typu. Teraz po prostu nie wiem czym się rózni dynamicznie silnie typowany jezyk od dynamicznie słabo typowanego języka :D

EDIT:
chociaz w sumie chyba już wiem, chodzi o to że nie są obiekty automatycznie konwertowane np. 1 + "2" nie zadziała w pytongu

Dobrze napisany kod w Pythonie będzie równie niezawodny, co np. dobrze napisany kod w Rust (nie licząc jakiś fuckupów w samym CPythonie typu edge case na GC). Mam napisane scrapery dla klientów w Pythonie, od co najmniej 5 lat działają, bez testów (!) i nigdy nie zaliczyły najmniejszego fuckupu (pod tym pojęciem rozumiem: nieustalony crash scrapera, szerokorozumiane zepsucie danych lub "pociągnięcie" niepożądanych danych), a strony, które scrapowały zwracały na przestrzeni tego czasu wszystkie możliwe kody HTTP chyba, czasem jsony, czasem xmle, a raz kod php nawet się wyświetlił, bo ktoś źle zapiął PHP.

Różnica w stosunku do np. Rust jest taka, że np w Pythonie trzeba dodać dodatkowego ifa lub dwa (jednym z tym ifów jest isinstance()) i trzymać się ściśle odpowiedniego stylu kodowania - bo tu kompilator nie przypilnuje. Oczywiście Python niczego nie wymusza i to może być gwóźdź do trumny, ale stawiam sporo, że ogarnięty developer pythona (czyli nie żaden klepacz, a ktoś, kto zna wady i zalety tego języka w odpowiednich sytuacjach) napisze równie niezawodny program co ogarnięty programista Rust.

TurkucPodjadek napisał(a):

Dobrze napisany kod w Pythonie będzie równie niezawodny, co np. dobrze napisany kod w Rust (nie licząc jakiś fuckupów w samym CPythonie typu edge case na GC). Mam napisane scrapery dla klientów w Pythonie, od co najmniej 5 lat działają, bez testów (!) i nigdy nie zaliczyły najmniejszego fuckupu (pod tym pojęciem rozumiem: nieustalony crash scrapera, szerokorozumiane zepsucie danych lub "pociągnięcie" niepożądanych danych), a strony, które scrapowały zwracały na przestrzeni tego czasu wszystkie możliwe kody HTTP chyba, czasem jsony, czasem xmle, a raz kod php nawet się wyświetlił, bo ktoś źle zapiął PHP.

Różnica w stosunku do np. Rust jest taka, że np w Pythonie trzeba dodać dodatkowego ifa lub dwa (jednym z tym ifów jest isinstance()) i trzymać się ściśle odpowiedniego stylu kodowania - bo tu kompilator nie przypilnuje. Oczywiście Python niczego nie wymusza i to może być gwóźdź do trumny, ale stawiam sporo, że ogarnięty developer pythona (czyli nie żaden klepacz, a ktoś, kto zna wady i zalety tego języka w odpowiednich sytuacjach) napisze równie niezawodny program co ogarnięty programista Rust.

Coz. To samo mozna powiedziec (z pewna hiperbola) o asemblerze. I o czym to swiadczy?

stivens napisał(a):

TurkucPodjadek napisał(a):

Coz. To samo mozna powiedziec (z pewna hiperbola) o asemblerze. I o czym to swiadczy?

Może i można. Ale chętnie poznam jakieś odpowiedniki z asm libów typu requests i BeautifulSoup z Pythona, skoro już mnie odpowiadasz.