Python az istencsászár

Arra írtam, hogy 2014-ben már fizikusok is használták a Pythont, pedig mi nem arról vagyunk ismertek, hogy könnyen váltanánk a jól bevált Fortranról, azaz, hogy nem 2016 óta tart a hype.

Én tudok C nyelven programozni. És nem ám kezdő szinten hanem annál sokkal jobban. __Sokkal__ jobban, igen.

Azt nem érdemes belekeverni hogy milyen a tördelésem. Ezt leszarom, és megtehetem hogy leszarom, mert nem team-ben dolgozom. Ettől még a kód amit írok, nyilvánvalóan lehet jó. Nálam különben kábé minden warning be van kapcsolva fordításkor, de nem szoktam warning üzeneteket kapni amikor lefordul a kódom... Ha mégis kapok, nem hagyom annyiban hanem megnézem, mi a rákja, és kijavítom. Igen, még a „pedantic” csoportba esőeket is...

Természetesen én is voltam kezdő programozó, amikor még nem értettem ennyire a C nyelvhez, sőt amikor még egyáltalán semennyire se értettem hozzá. A lényeg azonban az, hogy van a programozói tudásnak egy szintje, ami alatt nem lenne szabad az emberkét elismerni programozónak, azaz komoly munkát végeztetni vele. Na és ha annak az emberkének az a véleménye hogy „fúj, a C túl nehéz” - nos, akkor neki nem való e szakma, mert még ha megtanulja is e „nehéz” C nyelvet majd valamennyire, de nem azon a szinten, hogy a kódja eléggé hatékony legyen. És hatékonyság alatt megintcsak nem a tördelést értem, ezt kiemelem, amire tök felesleges rácuppannod mert egy automatikus kódformázó adott esetben hip-hopp helyrerakja.

A gond nem a tördeléssel van tehát, hanem például azzal, mennyire képes átlátni, nagyjából mire fordul le az amit ő a forráskódba ír. Mikor érdemes pointereket használnia hogy ezzel sebességet növeljen. (vagy memóriát spóroljon...). Hogyan képes megtervezni az egyes függvények (vagy netán objektumok - ezek is megoldhatóak C-ben ha szépen megkérjük rá a nyelvet...) felelősségi körét. Miként ismeri ki magát a memóriaallokációs kérdéskörökben, tudja-e ügyesen használni a branchpredictiont, és még soká lehetne sorolni...

Igen, ez mind olyasmi amit egy a C-nél „magasabb” absztrakciós szinten álló programnyelv ügyesen elrejt a programozó elől, megkönnyítve ezzel a munkáját, de épp emiatt az a programozó aki azt a magasabb szintű nyelvet használja, pláne ha azt tanulja meg elsőként, az a programozó nem is fogja soha megtanulni ezen dolgokat, nem tud majd a „mélyrétegek szintjén” gondolkodni, így állandóan gányolni fog csak, legyintve hogy „majd a compiler úgyis kioptimalizálja”. Ami persze igaz is lehet egy darabig, de ha mégsem... És amikor megteszi akkor se biztos hogy tényleg a legjobban.

És aztán ebből születnek ugye az olyan programok, hogy:

—Hát nem működik.

—De nálam igen. Hány giga RAM van a gépedben?

—16.

—Ja, akkor ez a baj. Az én fejlesztői gépemben 64 giga van. Vegyél nagyobb gépet, ha használni akarod...

Ismerős sztori? Meg amikor beránt a progi magának egy fél gigás libet, azért, hogy annak egyetlenegy funkcióját használja, egy olyan apró kis valamit amit a lusta programozó megoldhatott volna 3 rövid kódsorral, ha GONDOLKODOTT VOLNA?!

De nem számít ugye, csak legyen készen hamar, akárhogy, mindegy, és teljék már le a munkaidő mert utálom az egész szakmát, a francba is, focizni akarok délután az öregdiákokkal a parkban...

Na az ilyen nem programozónak való. Szerintem. Az ilyeneket én úgy nevezem, hogy „kóder-tróger”.

Iskolákban mindenkinek C nyelvet taníttatnék mint kezdő nyelvet. Aki abból nem tud levizsgázni megfelelőképp (hogy mi lenne a vizsgakövetelmény azon lehetne vitatkozni de egyelőre szerintem felesleges) az egyszerűen nem kaphatna programozói diplomát, soha, sehol, semmiképp! Tehát nem is űzhetne programozói szakmát. Olyan nyelven se ami nem C.

Otthon, a szabad idejében, természetesen olyan programnyelven gányolhatna amilyen csak tetszik neki.

Nos, az UNIX parancssoros eszközkészlet-világ... hát az erős túlzás hogy kedvemre való lenne. Nyilván messze jobban szeretem mint a Windowst meg a DOS-t, hiszen nem az utóbbiakat használom... De hogy kedvemre való lenne? Úgy igazán? Azért ezzel még várjunk...

Amúgy különben valóban nem rossz, de a bash (meg zsh meg stb) olyan idiótaságokkal terhelt amit nehezen nyelek le. Végülis azonban nem kéne okvetlenül „kiherélni”, mert értelmes ember úgyse bash-ban rak össze kicsit is bonyolultabb alkalmazást. Nálam körülbelül az a szabály, hogy ha valamire kéne egy progi, és zsigeri érzésem azt súgja hogy ez bonyolultabb lenne bash-ban mint 5 sor és egyetlen for ciklus, akkor már automatikusan azt kezdem gépelni a szövegszerkesztőbe, hogy:

#include

mert tuti hogy C progi lesz belőle, és legalábbis az stdlib kelleni fog nekije...

Most persze mondhatod erre hogy én vagyok a bolond, semmi baj. Ahogy öregszem és látom merre tart egyre inkább az állítólag normálisokból álló többségi társadalom, az egész világ, bevallom, nincs is semmi kedvem közéjük tartozni és „normálisnak” lenni vagy akárcsak látszani...

Számos dolog amit felhánytorgatsz a C nyelvnek, a szememben inkább előny.

Különben meg ha gyengeség is lenne, akkor is előny, olyan értelemben hogy épp ez késztet rá hogy megtanulj GONDOLKODNI a „gép eszével”! Ha neked kell egypárszor a malloc()-al memóriafoglalást megtrvezned, megírnod, stb, s elgondolkodni mondjuk olyan dolgokon hogy ha egy töömbre mutató pointert adsz át egy függvénynek, akkor ugye logikus hogy a tömbnek a memóriát a hívó függvény foglalja le hiszen ő is tölti fel adatokkal; azonban ezután a memória felszabadítása kinek a felelősségi köre legyen: a hívó függvényé vagy a meghívotté?! És így tovább... szóval ekkor később már egészen más szemmel nézed azon automatizmusokat amiket a magasabb szintű nyelvek művelnek, s amik egy kezdő számára teljesen természetesnek tűnnek.

És például tudod, hogy nem minden esetben kell végrehajtani bizonyos ellenőrzéseket amiket a hülye compiler biztonsági okokból automatikusan belerak...

Rengeteg példát lehetne sorolni ilyesmikre.

Igen, a C esetén a programozó teljesen magára van hagyva, nincs biztonsági öv! De épp ezért a legpompásabb tanulónyelv. Még ha el is fogadnám hogy valami másik nyelv jobb mert hatékonyabban lehet vele dolgozni, de TANULÓNYELVNEK akkor sincs jobb mint a C nyelv! (esetleg talán valamelyik assembly...?)

Szerintem itt befejezhetjük a vitát mert e ponton nyilvánvalóvá vált hogy teljesen eltérő a szemléletünk.

A nyelv ugyanis a szememben semmi esetre sem azonos a hozzá készült libekkel, de még csak e libek nem is részei a nyelvnek a szememben. Amikor tehát a nyelv előnyeiről vagy hátrányairól beszélek, én olyasmiket értek alatta hogy például kell-e benne sorszámozni a sorokat mint egyes régi BASIC implementációkban; hogy milyen mondjuk a "for" ciklus szintaktikája; létezik-e benne 3 ágú elágazás; van-e benne egyáltalán "goto"; a függványek egyetlen visszatérési értéket adhatnak-e vissza vagy többet is; lehet-e függvény is visszatérési érték; van-e benne kivételkezelés; kell-e előre deklarálni a változókat; milyen egyszerű típusokat ismer a nyelv; lehet-e benne OOP programokat írni; és még sok mást.

Az azonban hogy EDDIG MENNYI programot írtak már azon a nyelven (a lib is egy program ugye!) az a szememben abszolúte a nyelven kívüli kérdés, ezért nem része a szememben annak a kérdéskörnek ami az előnye/hátránya kategória alatt értendő.

Ha te ezt mégis bele akarod keverni, abban én nem leszek a számodra partner, mert a tárgytól való nagyon durva eltérésnek érzem. És kívül is esik az érdeklődési körömön.

Ezt nem haragból írom azonban. Ám én tényleg így elméleti oldalról közelítek a témához, te azonban - megengedem - gyakorlatiasan. Oké, megteheted, de ez nem az az út ami engem érdekel.

" Egy hosszabb, nyomtatott kódon pont a behúzással tudsz eligazodni más programnyelvekben is."  Meg azzal,hogy látom, hol az eleje meg a vége akkor is, ha nem csak whitespace-ek mutatják.

"Ha ideiglenesen beljebb kell raknod egy kódrészt, akkor a formázás miatt más nyelvekben is beljebb fog kerülni, amit mindkét esetben az editor fog elvégezni és nem te. " - Ha olyan editort használsz, ami... Perl/C/C++/satöbbi nyelvekre van formatter, beledobod a szerkezet módosítását, rányomod a formattert, és megoldva - szépre. Akár egy fordítás/build erjéig is. Ha akarod. Ha nem, akkor buildeled/futtatod ronda alakban, és ennyi. Ja, és ha átviszed a kódodat oylan helyre,a hol más formázási elvárások vannak (behúzások mélysége, és hasonlók), akkor python esetében vagy meg tudod reszeltetni az editorral, vagy sem. Egy szabadon formázható forráskódot meg szépen áttolsz a megfelelő formatteren, és máris az új igényeknek megfelelőne néz ki.

És azt se felejtsük el, hogy egy véletlen elütés már megváltoztatja a program szerkezetét. Ott, ahol a szerkezet szintjeit nyitó és záró karakterrel kell jelezni,ott egy iylen karakter önmagában hibás forráskódot eredményez, azaz egy struktúramódosításhoz két, megfelelő karaktert kell bebökni a kódba. Ez utóbbi szerintem hibatűrőbb megoldás.

Saját sztori: agyonkommentezett yaml fájl, ami dettó whitespace-eket használ az egyes szintek közötti váltásra. A sok komment között n+sokadikra sikerült csak kiszúrni, hogy a kolléga a kikommentezett név-érték párost rossz szintre (nem megfelelő sámú szóközzel a sor elején...) rakta vissza. Ugye közel s távol nem volt nem komment sor, úgyhogy viszonyítani nem nagyon volt mihez...