Fórumok
Kicsit le vagyok maradva, epp egy honapos ez a cikk itt:
TechRepublic.com: "Python ends C and Java's 20-year reign atop the TIOBE index"
Lehet persze vitatkozni, hogy van-e ennek jelentosege, az viszont ketsegtelen, hogy az elmult evekben nagyon jott fel a python.
Hozzászólások
Sok dologra tényleg nagyon jó, meg hát ha egy pár multi - mondjuk a Cisco, a Google és mások de factó hivsatlos nyelvvé tették a termékeiken, az meg fog látszani a részesedésen.
Sajnos. nekem valahogy nagyon nem tetszik.
Van az a feladat, amire a Python jó, itt is igen sok mindent meg lehet oldani kevés LOC-ot használva. (Főként már kész eszközök összekapcsolására.)
Na meg vannak azok a feladatok, amire egyáltalán nem jó.
Akinek csak kalapácsa van (csak egy programnyelvet ismer), az mindent szegnek néz. Mások meg tudnak válogatni a szerszámok (programnyelvek) között a feladat alapján.
AL
Itt arrol van szo, hogy akinek eleg sok szerszam van a ladajaban, az eleg sok esetben ehhez a szerszamhoz nyul, mert eleg sok feladatra teljesen jo.
Nekem is eleg sokszor jon elo, mert ha nem CPU intenziv a feladat, akkor alkalmas ra, es konnyu vele haladni. Meg akkor is jo, ha valami kutyuhoz irom a PC oldalt: valamilyen Arduino a kutyu oldalon (Nano (328P) vagy Mikro (32U4)) C++-ban kodolva (ha a HW oldal is az enyem), a PC oldalon meg Python3 + Qt5.
A strange game. The only winning move is not to play. How about a nice game of chess?
Látszik, hogy apró tool-okra borzasztóan nagy az igény. Arra pedig kiváló, tehát népszerű.
Hasonló mint a szeg meg a kalapács. Nem azzal készítenek milliószámra autót, se a napi kenyérgyártásnak nem fontos eleme, mégis az a legnépszerűbb eszköz.
A Python azért nyomul ennyire, mert alacsony a küszöb, minimális tanulással lehet használni, általában rosszul, de mivel van hardver bőségesen, ezért lehet alátenni bőségesen. Jönnek a friss diplomások és gyakorlatilag Python az, amihez egyedül ért, nyilván bármit is abban fog megoldani, mert nem ismer más eszközöket, sőt, adott esetben le is néz más platformokat.
Vannak területek, ahol nagyon jó a Python, a matematikusok imádják, végtelen mennyiségű library van hozzá mindenféle matematikai és egyéb dolgokhoz, mint a MI és a szimulációk, pezseg a K+F, aztán általában kiderül, hogy a világ összes pénze nem elég arra a hardverre, ami majd éles üzemben meg tudna mozdulni, így jön az, hogy akkor valamire átírjuk, ami nem igényel annyi CPU-t és memóriát... és biztonságos.
Architect feladatok kapcsán az a problémám, hogy kurvára nehéz a Python programozókkal dolgozni, mert alapvető ismereteik hiányoznak, mert neki azt nem kell tudni. Tudnak például stateless Python microservice-t készíteni és ennyi, bármi felmerül, akkor azt át kell lapátolni másik rétegekbe, mert vagy a Python nem tudja, vagy a Python fejlesztő nem tudja. És akkor ott állunk és nézünk egymásra.
https://iotguru.cloud
Jó lenne látni, hogy pontosan mitől került az első helyre. Én az AI-ra tippelek, ahol a Python lényegében az egyetlen út. Egyébként meg a 3-as verzió óta tényleg mindent meg lehet benne csinálni, brutális az ökoszisztéma, MS fizeti Guidot, hogy még gyorsabb legyen, a GIL-t lassan nyugdíjba küldik, van asyncio, az Nvidiánál meg éppen multi-node, multi-gpu űber-HPC numpy-t hegesztenek. Ez már rég nem apró tool-okról szól.
Kicsi a belépési küszöb, hamar megvan az egyetlen sorból álló print ("Hello World") sikerélménye és utána sem bonyolult, ha mögéd tolják a feladathoz szükséges háttér lib-et, ahol csak szakácskönyv-módszerrel kell LEGÓznod.
A Python egy tipikus kötöző-nyelv. Ha bármit benne akarnál kiszámolni és nem a mögöttes, például C-ben írt lib behívásával, metódusainak összekötözésével, akkor nagyon lassú.
Lásd még: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/pyt…
Amire itt a benchmark példákban volt C-ben írt háttér lib, ott csekély a tempó különbség. Ahol maga a Python kód kezd számolni, ott hamar meglesz az 50-szeres vagy nagyobb sebesség eltérés.
Ha kell a tempó, akkor ne akarj Pythonban algoritmus írni. Viszont az algoritmusok könnyen variálható összekötözgetésére kellemes, alacsony programozási tudást igénylő választás.
Használj Pypy-t, az nem olyan lassú.
+1 a tempóra, ezt én is szeretem. Bár még ez is töredék tempót ad a C-hez vagy Rust-hoz képest.
Viszont ezzel meg a LEGÓ-elvet bukod, legalábbis ha a standard lib-en kívül is kell modul.
Ez utóbbiak ugyanis csak cPython-ra állnak alapból rendelkezésre, így a C-ben gyorsra megírt vagy videókártyán futtatott kész rutinok, háttérmodulok java része csak cPythonból érhető el.
Alább arpi_esp alább írja, hogy "meg cuda-t is lehet pythonbol programozni mar".
Ezt annyival pontosítanám, hogy nem a CUDA-t programozod Python-ban, hanem a CUDA-ra megírt, kész rutinokat tudod meghívni Pythonból, átlökve oda a komplett adatvektort. Tehát ismét a "kötözőnyelv-jelleg" kerül Python esetén előtérbe. Viszont erre mint előbb írtam, tényleg kellemes.
"GIL-t lassan nyugdíjba küldik"
Van erről esetleg vmi link? Érdekelne
https://www.infoworld.com/article/3637073/python-stands-to-lose-its-gil…
en aki megrogzott asm/c coder voltam mar annyira csak pythont hasznalok evek ota, hogy mikor nemreg kellett valamit c-ben alkotni alig jutott eszembe a szintaxis :) (nyilvan nem a nyelv alapjai, hanem a runtime, pl. posix fuggvenyek parameterezese)
kicsit olyan ez, mint ahogy a C levaltotta az asm-et, mivel az egyre bonyibb cpu-kra a vegen mar a compiler jobban optimalizalta akodot mint en kezzel. most a python ilyen, minden feladatra van szejjeloptimalt library, jobb mint amit en irnek akar asm-ben hirtelen. meg amugy is ahol szamolni kell azt mar reg a gpu teszi. btw meg cuda-t is lehet pythonbol programozni mar, meg ott vannak a magasabb szintu math libek, numpy/tensorflow/keras ki mennyire akar belenyulni.
regen eszembe se jutott volna c-n kivul barmi egyebben irni lowlevel halozatos protokollokat/kommunikaciot, de mar py3-ban is eleg jo az asyncio erre. hasonlitsd ossze egy c-ben megirt select()-es szarakodassal (csinaltam olyat is).
ÉN pythonban automatizácós feladatokat oldok meg, előtte Perlben szivattam magam. Alkalmazást biztos nem fejlesztenék benne, az OOP-je elég gyengus.
Ezt az OOP elég gyenugst kifejted?
gondolom a C++-fele operator overloading es hasonlo marhasagokat hianyolja :)
A Python szereti magát full OOP nyelvnek nevezni, de ott, ahol minden public, sok dolognak nevezhető , csak nem komolyan vehető OOP-nek. A duck typing is rendesen szembe megy az OOP-nek, az interface hiánya is fájó.
Ki lehet izzadni persze valamit absztrakt metódusokkal, meg aláhúzással kezdődő változónevekkel, meg van egy alap inheritance is, szóval össze lehet gányolni valamit, ha nagyon szeretnél, csak hát az OOP pont nem erről szólna.
Ah. Szerintem a duck typing -- minden előnyével és hátrányával -- viszonylag ortogonális a az OOPra. Lehet nagyon nem szeretni (személy szerint én is örülnék valami kevésbé ilyennek, komplex nagy fosokban tényleg vakarózásra ad okot), de ez szerintem az OOPtól független probléma.
Az interfacek szerintem kb egyáltalán nem hiányoznak, de ha erre van igényed, akkor csinálsz egy szignatúrás osztályt az interfacenek, és beteszed az ősök közé. A (kevés) syntax sugaron túl nem nagyon látom, hogy ez mivel kevesebb mint egy interface.
A privát memberek valóban fájóak, bár in practice az underscore is private by convention meglepően jól működik, ha nem vagy ordas fasz. Ha meg igen, akkor a világ összes OOPja se segít rajtad.
Persze, lehet helyettesítő dolgokkal is csinálni, de én biztosan c#, Java, vagy akár c++ alapon esnék neki valami komolynak.
Egyébként nagyon szeretem a pythont, rengeteg hálózatos automatizációt írtam benne, meg jópár egyéb célfeladatot ellátó szkriptet. De már egy GNS3 méretű alkalmazást biztos nem abban írtam volna, ha én írtam volna.
Én ezt a problémát inkább tooling-gal oldanám meg, akár az IDE-be akár a CI-ba bele lehet tekerni valami lintert ami szigorúbb mint a nyelv lenne. És akkor ezt a lintert a projekt a saját igénye szerint beállíthatja, nyilván nagy projekt -> szigorú linter.
Gábriel Ákos
ezek szerintem nem linting problémák.
Egy ideje már van type annotation, amivel maga a nyelv nyilván nem csinál semmit, na azon lehet vakarózni CIban.
Főleg adatfeldolgozásra használja sok cég, excel++ jelleggel, valahol ide tartozik az AI is. BigData-nak nem hívnám, az Magyarországon nincs, mondjuk úgy, PretendingToBeBig data feldolgozásra, ahol még az SQL is elég lenne, de akkor be kéne vallani, hogy egymillió sor az lóf@sz, meg csúnya a szintaxis.
Aztán a sok ilyen megvadult BI report sok kicsi sokra megy alapon feltolja a statisztikát.
Szerintem meg BigData az a feladat, amit BigData módszerekkel oldasz meg, tökmindegy hogy 10e sor vagy 10millió.
Az nyilván megmutatja hogy jó-e az elgondolás ha nekieresztesz 10millió sort akkor betojik-e vagy sem.
1millió sor az SQL-nek sem sok, ha "jól van csinálva". Láttam már SQL-es projektet elbukni 10e soron is, meg működni 200millió soron is.
Gondolom BigData-val is ugyanez a helyzet.
Gábriel Ákos