Mi értelme van a python és a C/C++ nyelveken kívül másnak?

Pont az informatikában találták ki a TCO fogalmát. Total Cost of Ownership (teljes életciklusra vett összes költség). Figyelembe kell venni a hardver árát, a fejlesztés árát, azt, hogy ez a felhasználónak mibe kerül. Amit Te írsz az pont a "kifordított logika" egyedül a fejlesztő szempontjait veszi figyelembe, hogy pythonban gyorsabb fejleszteni. Ezt senki nem vonja kétségbe, hogy pythonban bizonyos típusú feladatok fejlesztése gyorsabb. Aztán vagy létezik olyan számítógép amin elfut a program vagy nem. Vagy megőszül a felhasználó vagy nem. Azt nem szabad elfelejteni, hogy a programozó nem önmagárét való (bár ma ezt világcégek is elfelejtik sokszor), és a programozás az valahol "rabszolga munka", itt a felhasználónak (kéne) diktálnia. Az, hogy még mindig van egy "mítosz" meg "jajj a szegény programozó meg ne haragudjon" stb. atitűd az jelenleg a szakma szégyene. Amikor a programozó az elvi hibás, kegyetlenül bonyolultan használható, programját úgy magyarázza ki, hogy "hát ezt csak így lehetett megírni..." "hát ennyit tud a windows" "vegyél 4x erősebb gépet, 6x ennyi memóriával" hát pont ki nem sz*ja le. Te vagy a programozó oldd meg. Tényleg tök jó a python, C# ha van korlátlan CPU és korlátlan memória (egyik jobban zabálja mint a másik).

De pl. írd meg egy automata mosógép fedélzeti szoftverét pythonba, úgy, hogy beférjen a legkisebb mikrokontrollerbe (azért abba mert több ezer /esetleg tízezer/ db. legyártása esetén a 2-3 USD/darab ár eltérés elég húzós szumma árat fog jelenteni). Ugyanígy nézz meg egy ABS vagy EBS fékrendszer szoftvert (ezeket is tízezresével árulják a modern autókban, itt meg az a pár USD amivel drágább a hardver a gyártónak elég sokat hoz). Vagy pl. egy űrszonda esetén ahol van 2W villamosenergia egy komplex mérés elvégzésére. Na itt jönnek be azok, hogy melyik módszerrel, milyen programnyelven mennyire lesz végül "hatékony" az eredmény.

Szintén nem mindegy ahol van 0,2 usec (mikro secundum) egy beavatkozásra, hogy ebből mennyit "vacakol" a python kód. Tudom, hogy vannak akik kísérleteznek PLC-knél és embed. rendszereknél is a Pythonnal, de még elég gyerekcipőben jár, és még messze van az, hogy az tényleg működő képes legyen. Pl. egy mikrokontroller (ld. pl. fék vezérlő rendszer, mosógép) egy utasítás végrehajtási ideje 125 nsec. Nem mindegy, hogy valamit 50 vagy 100 lépésből, vagy jól kioptimalizáltan pl. a fent már említett assembly esetén 10 lépésből oldunk meg. Pl. amikor megnyomod a féket szeretnéd, hogy az ABS egyből csinálja a dolgát és ne kelljen 0,5 - 1 secet várni arra, hogy észrevegye amit csinálsz. De pl. egy vegyipari automatika esetén pont ugyanez a probléma. Vagy nézzünk pl. egy hétköznapibb példát, ma már egyes sportokban század másodpercekben mérik a versenyző idejét, ez 10 usec. Ez alatt kell a mérést elvégezni, kiértékelni stb. pl. (és elég gyakran) a fent említett mikro kontrollerel oldják meg a feladatot összesen 80 utasításból állhat az egész program, különben lassabban fut le (0,125usec egy utasítás) mint a kiértékelés teljes ideje. Azért 80 utasítás azért nem enged meg egy túl hosszú kódot. (pl. python esetén amikor a stacken pakolja az objektumokat amik néha több 100 byte méretűek, eleve csak az amíg átmásol 100 byteot a stackre legalább 300 utasítás...). Itt van jelentősége más nyelveknek pl.

Szintén jelentősége van ahol irtózatosan sok adatot kell feldolgozni. Pl. egy banki számlavezető rendszer ahol van a banknak néhány millió ügyfele, ügyfelenként 5-6 elkülőnített számlával (egyszerűség kedvéért nézzünk 10 millió számlát). Jogszabályi előírás, hogy minden nap napi zárást és napi mérleget, ellenőrzéseket meg egy pár dolgot el kell végezni az összes számlán. Nagyon nem mindegy, hogy 1 másodpercig tart egy számla feldolgozása (ez a 10 millió számla esetén 2700 óra lenne, 1/3 év), vagy megvan 0,01 másodperc alatt (27 óra, ami még mindig sok, de 2-3 számítógép beállításával és a feladatok párhuzamosításával már "belátható" a feladat hardver és futás ideje).

Bocs igen a C/C++ ez egy érdekes kérdés volt és talán lesz is elég sokáig. A C/C++ össze van nőve masszívan a unix/linux világgal. Ez a mérleg egyik serpenyője. A sebesség igen, tény, hogy gyorsabb a C/C++ (bár ez utóbbi nem minden esetben igaz). Viszont pont itt számít rettenetesen a fordító program. Ezt végig teszteltük nem egy esetben. Illetve nagyon fögg a fordítóprogram beállíásaitól. És itt van ebben egy kis "buktató", mert "nehéz kijelenteni", hogy mindig "gyors" a C/C++ főleg egy gyengébb, vagy rosszul beállított fordító programmal. Az OK, hogy nyelv szinten gyorsnak kéne lennie. A másik probléma a C/C++ világban, hogy "elvileg" OS és CPU független, akkor miért van tele egy csomó C program ilyen direktívákkal, hogy "#if defined (_WIN64)" és hasonlókkal (amik CPU típus, és OS típus függően bizonyos kódrészleteket kihagynak, betesznek stb.).

Ha az ember elolvas több ezzel foglalkozó szakcikket akkor pont az látszik, hogy a "C/C++" család /és van belőlük szép számmal/, illetve a "modern" nyelvek születése pont azért van mert a C hát nem egy könnyen tanulható, egyszerűnek mondható nyelv lenne. A C++ már főleg az OOP képességei miatt már egy csomó esetben tényleg kényelmesebb, de önmagában a C elég nehezen tanulható, és elég bonyolult tud lenni. Nyilván sokat fejlődött az is, és a ma elérhető nagyszámú függvénykönyvtár és fejlesztő/keret rendszer rengeteget segít.

A JAVA és a C# (ez utóbbit a Microsoft nyomja, és valójában egy nagyon hasonló nyelv mint JAVA, vannak olyan leírások amik arról szólnak, hogy valójában JAVA csak licence és jogdíj és egyéb okok miatt dobta a piacra a Microsoft saját jelzéssel saját termékként, és ezért nem 100%-ban azonos a kettő). A JAVA egy érdekes nyelv, egy relatív fiatal nyelv, egy egészen érdekes struktúrát követtek, nem a forráskód OS és CPU függő, hanem van egy JAVAVM és a CPU és OS specifikus dolgokat az intézi, így "elméletileg" a programozó által írt program teljesen platformfüggetlen kéne, hogy legyen (ez nem 100%-ban igaz, de az esetek jelentős részében ez teljesül, eddig 100%-ban platform független nyelvet még nem láttam, mert ha más nem a fájlnevek, és a directory struktúra eltérő lehet a különböző OS-ek esetén, eddig olyat, hogy csak a fájlnevek kezelését kellett módosítani csak a JAVA és a FORTRAN nyelvek esetén tapasztaltam, minden más nyelvnél jobban bele kellett piszkálni OS váltásnál, egyébként a python is ilyen szempontból barátságos, mert ott is alig-alig kell OS váltás esetén módosítani a programon /a fájlneveken kívül/).

Amikor elkezdett terjedni az egész "világ" tele volt azzal, hogy hát ez lesz a jövő és mindent meg fog oldani és soha nem találtak ki jobbat... Sajnos a tapasztalat, hogy a JAVA nagyon kényelmes, nagyon jó, de nem egy szuperszónikus repülő, nem egy túl gyors, és nagyon verzió függő sajnos. A JAVA egy saját ún. bájtkódot használ és a program egy JVM-en fut; a python alapvetően interpreter, egy picit más a működési mód, ez miatt lassú mint egy nyugdíjas csiga. Léteznek python fordítók is (még nem néztem bele, hogy hogyan néz ki egy pythonból fordított EXE, de jelentősen az sem volt gyorsabb amikor teszteltem).

Ami mindig is jellemző volt az első "komolyan vehető" programnyelvek megalkotása óta (ez gyakorlatilag 1950-es évek eleje) midnig voltak "divatok" meg voltak olyan időszakok amikor mindenki esküdött valamelyik nyelvre, meg elhangzottak olyan állíások "ez a nyelv aztán tényleg mindenre jó lesz" aztán eltelt pár év és jött egy újabb nyelv. Valójában minden nyelvnek megvan a maga helye, és a maga erőssége. Pl. a JAVA ott nagyon erős ahol fontos a gyakorlatilag 100%-ban platformfüggetlen megoldás; a C ott ahol nem akar az ember assemblyvel küzdeni, de közel olyan sebességet és hatékonyságot akar elérni (ld. pl. oprendszerek, rendszerközeli programok, mint fent sajnos az eredmény nagyon függ a fordítótól és annak a beállításaitól) és van ideje fejleszteni (és beállítani a fordítót). A C++ egy átmeneti lehetőség, gyors /tud lenni jó fordítóval fejlesztő rendszerrel/, már viszonylag baratságos a fejlesztő számára /a C minden csak nem barátságos/. A python egy nagyon jó választás ott ahol nem számít a futásidő, lehet interpretert használni, gyorsan kell fejleszteni, világos, áttekinthető programra vágyik az ember. A JAVA az akkor célszerű ha nagyon fontos a gyors portolhatóság, platformfüggetlenség.

Nyilván nem véletlenül alakult ki ez a rengeteg nyelv, és születnek ma is programozási nyelvek.

Valaki írta az assemblyt (meg előzőleg én is utaltam rá). Az assembly egy nagyon "erős" nyelv, hátránya, hogy irtónehéz megtanulni (sokan állítják, hogy tudnak assemblyben programozni, aztán mégsem...). Az assembly hibája pont az "erőssége" nagyon nagyon CPU és OS függő. Maga a program kb.annak az egy embernek a számára áttekinthető aki megírta (vagy tesz bele minden sorhoz fél oldal kommentet...) ma már egyre kevésbé használják bárhol is, főleg hogy még beágyazott rendszerekre is léteznek már nagyon hatékony és nagyon jó C fordítók amikkel el lehet érni kb. azt a hatékonyságot amit az ASM-el el lehet érni. Igazán azt beágyazott rendszereken, egyedi célhardvereken kívül igazán csak néhány nagyon speciális esetben használják. Én szeretem, mert érdekes, de kb. mostanra jutott el odáig a hardver ár, hogy már szinte sehol nem lesz kifizetődő az ASM program, mert olcsóbb eggyel nagyobb hardvert betenni és C-ben megírni a programot, mert ASM-ben a fejlesztési idő lényegesen nagyobb lesz mint bármi másban. Igazán a másik jelentősége ott lehet az ASM-nek, hogy ha valaki érti akkor kb. érti azt, hogy hogyan működik a gép. Igaz ugyan, hogy ma már kevésbé a programozó optimalizál (ld. pl. Knuth erre vonatkozó megállapításai), de nem árt tisztában lenni, hogy egy-egy esetben a proci mit is fog végrehajtani amikor valakinek eszébe jut több száz mega byteos objektumokat nem cím, hanem érték szerint átadni, majd csodálkozni, hogy 1. elfogyott a memória, 2. beláthatatlanul lassú a program. (volt szerencsém kezdő programozótól ilyet látni, és még meg is magyarázta, hogy azért így, mert... amiben részben igaza is volt, csak akkor ne várja, hogy kicsi lesz a memória igény és gyors lesz a programja).

Egyik időse tanárom mondta, hogy ha már tudjuk a feladatot, nagyjából megvan az algoritmus és tudjuk, hogy min és hogyan kell futnia a programnak válasszunk az adott gépen/OS-en elérhető programnyelvek közül a legjobb belátásunk szerint. Itt vegyük figyelembe, hogy az adott cégnél mit használnak, mihez értünk a legjobban, melyikkel várható a legjobb össz eredmény. Pl. létezik egy tuti jó nyelv, de még sose írtunk benne még egy "Hello, world!" bonyolultságú programot se és fél év elmegyen azzal, hogy megtanuljuk nem biztos, hogy hatékonyak leszünk. De létezhet olyan feladat amikor ezt az utat kell választani, mert végül ez a félév majd visszjön máshol.