Szerintetek képes a Python + Cython helyettesíteni a backend fejlesztéshez használt nyelvek nagy részét?

"képes a Python + Cython helyettesíteni a backend fejlesztéshez használt nyelvek _nagy részét?_"

Egyértelmű, hogy egy olyan program esetén, amit sokan, sok helyen fognak újrahasznosítani, ott a futásidőre eléggé fontos optimalizálni. Ez sokszor megoldható Cython segítségével, de a különösen kényes modulok megírhatóak C vagy C++ segítségével. A jól megírt Cython programok általában nem jelentősen lassabbak, mint egy C program. (Hiszen gyakorlatilag C nyelvről van szó, Python köntösben. Pár kibővítés van csak benne, amik viszont szintén elég jól ki vannak találva).

A PHP mint példa pontosan az általad említett érvek miatt merült fel. Azt leginkább az ügyfelek és a meglévő kódbázis miatt nehéz helyettesíteni. Viszont sok esetben mindenképp érdemes, mert a PHP eredetileg egy sciptnyelvnek lett tervezve, ráadásul viszonylag alacsony szintűnek. Ezek a "hibák" mind a mai napig kiütköznek. A Python viszont egy általános célú nyelv, és webes fejlesztésre kitűnően alkalmas.

Tehát ez alapján a Python + Cython képes helyettesíteni a backend nyelvek nagy részét, mert mellette alkalmanként szükség lehet C-re (esetleg C++-ra), illetve PHP-ra, de más nyelvre nem kimondottan. A Java nyelvnek a lassú fejlesztés és a karbantartáshoz szükséges nagyon sok erőforrás a hátránya, továbbá az, hogy biztonsági szempontból továbbra sem megbízható a JVM. A .NET-nek pedig az, hogy elsősorban csak Windows platformra van tervezve. A Mono nem tökéletes, illetve a .NET-es nyelvek között van némi idegesítő inkonzisztencia. E mellett ráadásul nem is kimondottan gyorsabbak, mint egy Cython-os szoftver.

Én alapvetően nem tartom jól megtervezett nyelvnek a PHP-t, a C++-t és a Java-t. A PHP-t nem is kell szerintem magyarázni, az gyakorlatilag nem nyelv... A Java mögött nagy nevek állnak, és az érveik érthetőek is, csak azt nem értem, hogy miért pont a Java mögé sorakoztatják ezeket fel? A C++ pedig egy nagyon jó nyelv, de csak egy nagyon szűk célra. Ha a lehető legoptimálisabb kódot akarom megírni, akkor a C++-t veszem elő. Viszont erre a legtöbb esetben nincs szükség. Túlhasználtnak tartom a C++-t azért, mert a kódolás, kódfenntartás, stb. miatti gyötrelem sokszor pénzkidobás, mivel olyan előnyt értünk el vele, amit hasznosítani nem tudunk. A .NET-el pedig az a gond, hogy vannak ugyan szintaktikailag nagyon jól kitalált nyelvek, és a futásidő is egészen jó, viszont csak .NET környezetben futtatható, illetve hiába jók ezek a nyelvek, ha egyébként van náluk sokkal jobb ;)

"A szkript nyelvek hátránya, hogy ha futtatni akarod, akkor kell hozzá a forrás, így nem lehet eladásra szánt, zárt forrású kódot készíteni belőle. Amellett pedig lassabbak, amely kis otthoni programoknál nem zavaró, de egy millió soros programoknál már igen.

"

A Python nem írja elő, hogy szükséges legyen a forrásfájl a szoftver használatához. Hozzá kell tenni, a hivatalos Python implementáció nem a klasszikus értelemben vett interpreter, tehát ez egy félreértés. Valójában úgy működik, hogy a szintaktikai elemzés után lefordítja a programot, és egy pyc fájlt állít elő, ami már egy bináris állomány. Utána ezt futtatja.

Meg lehet oldani azt is, hogy az eredeti forrásfájl nélkül futtatható legyen. Például a Cython által előállított binárisok használatával. Tehát erre is vannak implementációk.

A másik, hogy ha olyan logikáról van szó, ami védendő business logic, az általában egy összetett probléma, vagyis hotspot a kódban. Ezt eleve érdemes optimalizálni, tehát ide jobb esetben eleve egy különálló C kódot használ az ember.

"millió soros programoknál már igen"

Ha egy program egy millió soros, azt valószínűleg egy rossz program. Vagy pedig valójában több különálló, önállóan hasznosítható program, tehát egy összetett programcsomag. (Mint pl. egy operációs rendszer, vagy egy összetett képszerkesztő, stb.) Hiszen egy jól megírt programban az újrafelhasználhatóság miatt az egy feature implementálásához szükséges kódsorok száma elvileg a fejlesztés során folyamatosan csökken, a több önálló programra bonthatóság esélye pedig folyamatosan nő. Én legalábbis dolgoztam elég nagy szoftverekkel, és refaktorálás közben például mindig sikerült úgy növelnem a metódusok és függvények számát, hogy közben a kódbázis összmérete ne csökkenjen. Hiszen az újrafelhasználható részek segítségével sikerült a kód más részeit is lerövidíteni. És egyébként sok sorból álló programot is úgy kell optimalizálni, mint a kevés sorból állót: a hotspotokat kell kioptimalizálni.

"ez az egész úgy néz ki, mint ha te nem is kérdezni jöttél volna ide, hanem olyan embereket keresni, akiket meggyőzhetsz, hogy a Python mindenre jó"

Vagy inkább szeretném hallani az érveket, hogy milyen nyelv miért jó, és miben jobb mint a Python, mivel szeretném szélesíteni a palettát. :)

Sok Java programozónak nem szimpatikus.

Egyébként az adatelrejtést támogatja természetesen, méghozzá property syntax-al, ami az én véleményem szerint picit átláthatóbb, mint a Java megoldása. Getter-t, setter-t és deleter-t lehet beállítani egy propertyhez. Alacsony szintű megoldás is van privát adattagokhoz egyébként.

Véleményem szerint nem hogy a többszörös öröklődés, hanem a hagyományos öröklődés sem jó ötlet általában.

Az öröklődés addig működik, amíg egy közös őstől származik minden tulajdonság. (Metódus vagy adattag - a Pythonban ezek nincsenek megkülönböztetve)

Tehát pl. ha az Ember osztályból, aminek egy beszél metódusa van, származik mondjuk egy Nő osztály, a Nő osztályból pedig egy Tanárnő osztály. Ez alatt semmi gond nincs a beszél metódussal.

De mi van, ha készítened kell egy HumanoidRobot osztályt is, ami szintén tud beszélni? Ilyenkor persze készíthetsz egy Beszélő absztrakt osztályt, amiből az Ember és a HumanoidRobot származik, viszont ez egyszeres öröklődéssel csak akkor működik, ha nincsenek egymásnak ellentmondó metódusok. Például a Séta, ami a láb nélküli HumanoidRobot subclassekre nem vonatkozik. Ezt már nem lehet pusztán egyszeres öröklődéssel megoldani.

A Java megoldása erre az Interface, vagyis, hogy készítünk bizonyos tulajdonságokból egy csoportot, amit együttesen kényszeríthetünk egy osztályra. (Tehát a tulajdonságok egymásra, és nulla vagy több osztályra is kényszerítve vannak). Ez viszont több problémát vet fel:

- ha például többféle tulajdonságot akarsz egymáshoz kényszeríteni n különböző variációban, akkor n különböző interface-t kell készítened

- az Interface azt nem kényszeríti, hogy hogyan valósítsd meg az adott tulajdonságokat. Ez az adattagok elrejtése szempontjából jó, kód fenntarthatóság szempontjából rossz, mivel kódduplikációra kényszerít.

Ez konkrétan azt eredményezi, hogy a Java programok jellemzően hosszabbak, és több kódismétlést tartalmaznak. Ami szerintem nem tekinthető előnynek.

Szerintem erre sokkal jobb megoldás, ha nem csak arra törekszel, hogy az adattagokat rejtsd el, hanem arra is, hogy a metódusok atomikusak és újrafelhasználhatóak legyenek. Így a különálló képességeket ki lehet emelni absztrakt osztályokba, amik csak magas szintű megvalósításokat tartalmaznak, a nem implementált alacsony szintű megvalósításokra pedig NotImplementedError exception-t dobnak. Tehát pl. Beszélő interface helyett egy beszélő absztrakt osztályt csinálhatsz, ami a magas szintű metódusok megvalósítását tartalmazhatja, a kódismétlést elkerülendő. Ezt pedig mixin classként használhatod fel az öröklődésnél.

pl. egy adatszerkezetnél az, hogy hogyan tárolod az adatot, vagy egyáltalán az, hogy milyen típusú az adatszereket, az nem tartozik a többszörös öröklődéssel megvalósítandó feature-ök közé, hiszen ez bonyolítaná és átláthatatlanná tenné a kódot. Viszont az, hogy pl. az adatszerkezet minden elemét egy függvényen felvett értékre cseréld, azt a képességet mixin classként is nyugodt szívvel meg lehet valósítani, hiszen az, hogy hogyan kell bejárni az adatszerkezeted, az a saját osztályodban van megvalósítva, a mixin class ezt használja egyedül, és semmi máshoz nem nyúl az osztályodban.

Itt egy példakód, ami konkrétan ilyet csinál: [link]

Vagyis kvázi ezzel bizonyos adatszerkezetekre új képességeket tudsz pakolni. Többszörös öröklődés nélkül ezt sokkal nagyobb kín megvalósítani.

És Python-ban a többszörös öröklődés balról-jobbra, fentről-lefelé szabály alapján történik. Vagyis van egy elsődleges osztály, amiből öröklődik az osztályod. Annak az adattagjait, metódusait semmi nem írhatja felül. És a mixin class-ok között is rangsorrend van természetesen, de ilyenkor persze az az ideális, ha nincs is ütközés.