Server programozás: Python?

Szerverüzemeltetés során sokszor érdemes kis szkipteket használni, az adott feladattól függő nyelven. Nálam ez leggyakrabban a bash és a perl, nagy ritkán meg lua. Azonban, ha úgy alakul, hogy egy feladat elkezdi kinőni magát, akkor bajban vagyok.

Eddig a komplexebb feladatokat Perlben oldottam meg, mivel ott gyorsan és hatékonyan lehetett ronda, de valamelyest objektum orientált kódot írni (package). Ez azonban erősen korlátos és tényleg nagyon ronda, tele hibalehetőséggel kódolás közben.

Most ismét egy várhatóan összetettebbre növő alkalmazást kellene készítenem, és még mindig nagyon nehézkesnek érzem ehhez a Perl-t.

Arra gondoltam, hogy bármennyire is rühellem a Python szintaxisát, talán mégiscsak rá kellene szánnom magam, hogy kitanuljam, és azt használjam. De a hideg ráz tőle, ezért érdekelne, hogy érdemes-e energiát ölnöm bele, vagy van valamilyen jobb, hatékonyabb programozási nyelv szerver környezetbe. Cél, hogy lehetőleg környezetfüggetlen legyen - a linux szerű környezeteken belül. A Perl és a Python minden alaptelepítés része, így ezzel nem lenne gond.

Ha jól tudom, mikrokontrollekere is van Python, bár, hogy a microPython mennyire Python tényleg, azt nem tudom. De ha már tanulok, szeretnék minél több helyen használható tudást begyűjteni. Amúgyis olyan sok helyen használják, hogy biztos van valami oka.

Tehát tényleg a Python az Isten? Van érdemi előnye - ami ellensúlyozza a szintaxisát - azon kívül, hogy talán objektum orientáltabb, mint a Perl? Vagy szerver oldalon már csak C++-ban érdemes gondolkozni? (Attól is a hideg ráz.)

Vagy van valami, amire nem is gondolok?

Hozzászólások

Klasszikust idézve, mindent meg lehet irni fortranban ... :D

Fedora 38, Thinkpad x280

Igen is meg nem is. Szerintem a legtöbb elektronikával foglakozó ember így van ezzel. Hiszen sima erősítő is szorzó/osztó áramkör, de ha visszacsatolt akkor már összeadó/kivonó is. Az már nézőpont kérdése, hogy ezt tekinthetjük e célszámítógépnek.

Volt tervem, hogy valamilyen titkosítási algoritmust revers-ét megcsinálom analóg módon, de soha nem jutott rá idő. Bár a mai napig kíváncsi vagyok rá, hogy jelgenerátor vagy state-machine lenne belőle.   

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

átírni

Unix portálon nagybetűről kisbetűre átírni? Mire való a shell?
$ echo "A JÖVŐ SZÁMÍTÓGÉPEI NEM DIGITÁLISAK, HANEM ANALÓGOK LEHETNEK" | awk '{print tolower($0)}'

De ha már Python a téma, ott interaktív módban ennyi:
$ python3
>>> "A JÖVŐ SZÁMÍTÓGÉPEI NEM DIGITÁLISAK, HANEM ANALÓGOK LEHETNEK".lower()

Ezeknél egyszerűbb lett volna az éppen nyitva lévő TextMate-ben nyomni rá egy 'shift-ctrl-u'-t. De már ez is sokszoros energia befektetés egy sima 'cmd-v'-hez képest. Mint mondottam: lusta voltam.

„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)

Amikor kisgyerek voltam, megpróbáltam. Nagyon fellelkesedtem, amikor megtudtam, hogy hogyan működik a tranzisztor, és rögtön összecsavartam két diódát, hogy kipróbáljam ... persze nem ment ... talán ez is egyike volt azon élményeimnek, ami miatt végül is nem lettem villamosmérnök. :O

1) Honnan tudná a záróirányban előfeszített dióda, hogy a másikon épp nyitóirányú áram folyik? Egy félvezető chipen belül, vékony bázissal tudhatja a fizikájából adódóan.

2) Szerencsére nem lehet megcsinálni diódákból. Ha meg lehetne, a Graetz-híd állandóan rövidre zárná a táplálást, mert amikor a nyitóirányú áram folyik az egyik diódán, a másik épp záróirányban van előfeszítve, s ha ezen mégis áram indulna el, az baj volna.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Előnye a fejlesztési sebesség és az, hogy tényleg gyakorlatilag mindenhez van benne valami modul/könyvtár.

Hátránya a sebesség, ebben a C++ jellemzően min. 20-30x gyorsabb általában, ezt lenne érdemes mérlegelned.

Nagyon röviden összefoglalva. :) Én egyébként azt szoktam csinálni, hogy kipróbálni összedobok egy működő python-programot, ha jól teszi a dolgát, átírom C++-ba (ha fontos a sebesség).

Zárójel: persze, van cpython, meg pypy, de kezdésnek nem kapásból ezeket javasolnám, mint ismerkedés.

Előnye a fejlesztési sebesség...

Hátránya a sebesség, ebben a C++ jellemzően min. 20-30x gyorsabb általában, ezt lenne érdemes mérlegelned.

És ebből jön, hogy érdemes megírni az egészet Pythonban gyorsan, aztán tesztelni, és ha lassú, akkor a profilerezés után kiderülhet, hogy van egy nyúlfarknyi rész, amit érdemes azt a pici részt átírni mondjuk C++-ba.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Elvben akár a Python is kihagyható, ha mondjuk shell scriptet ír valaki Python szkript helyett. Előnye, hogy olyan környezetben is használható, ahol nincs pl. Python... A jelzett sebességkritikus részek más programnyelvre átírása (pl. C-re vagy C++-ra) szintén megvalósítható ebben az esetben is.

"Share what you know. Learn what you don't."

Én annyiban próbáltam árnyalni, hogy nem az egész programot írnám át C++-ba, csak a sebesség szempontjából kritikus keveset.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

+1 ... legutóbb Rust-ban írtam .so -t, amit "import sajat" módon berántottam Pythonból és már hívtam is a gyorsan futó adathalmaz feldolgozó függvényeit.
Tempó: gyakran valójában csak összetett logikát kell végrehajtani de nincs eszeveszett sok adat ami tempót igényel. Továbbá amit nem a Python nyelvi elemei "őrölnek meg" valami ciklusban, hanem C-ben írt háttere (stringműveletek, numpy, stb.) dolgozza meg, az ugyanúgy gyors.

Perl vs Python: mindkettőben programoztam. Utóbbi szerintem kezesbárányabb, átlátható módon könnyebb egy összetett projektet is kézbentartani.
Python vs. Rust: ha kell valahova egy gyors, végleges bináris. Szépen átírható a legtöbb kifejezés. Python adatszerkezetei Rust-ban is rendelkezésre állnak.

" így nyilván nem tudok ahhoz hasonlítani." - Az "előnye..." kezdetű kijelentés pont egy hasonlítás - jelen esetben a szövegkörnyezet alapján a Perl az, amihez hasonlítod. Legalábbis elolvasva a szálat nekem ez jött le belőle.
Ha csak a pájtonos marketingrizsát idézted, akkor én értettem félre - minden esetre a "mindenhez _is_ van eljáráskönyvtár" az néhány eltoszott nyelvtől eltekintve nem előny/különbség a többi hasonlóan nem eltoszott nyelvhez képest, mert részben attól is lesz jól használható (nem eltoszott) egy programnyelv, hogy rengeteg dolog elérhető hozzá eljáráskönyvtárakon keresztül.

 

Legalábbis elolvasva a szálat nekem ez jött le belőle

Akkor nagyon rosszul jött le, semmi közöm nem volt soha a Perlhöz, egy sor kódot nem írtam benne (tulajdonképpen fiatal is vagyok hozzá, ha úgy vesszük), ha akarnám sem tudnám ahhoz hasonlítani.

Ha csak a pájtonos marketingrizsát idézted, akkor én értettem félre

Valóban félreértetted, de nem amiatt, mert a "pájtonos marketingrizsát" idéztem volna (ugyanis arról nem tudom milyen). A Pythont használom, sok mindenre nagyon jó és hasznosnak gondolom a quirk-jei ellenére is, és nagyon kényelmesnek gondolom, hogy gyak. mindenhez van könyvtár - ha már valamihez, a C++-hoz hasonlítottam, mivel az a másik, amiben még időnként kódolok, és azon esetekben, amik nálam fordulnak elő, bizony több reszelést igényel/nincs mindenre kész, megírt könyvtár, amit csak be kell emelni.

Értem, hogy nálad a Perl is egy becsípődés, de csak te hoztad ide, még csak meg sem említettem.

Nincs gond :) A Python-hoz _is_ és a Perl-höz _is_ van szinte mindenhez könyvtár - én meg az a korosztály vagyok, aki még anno Perl-ben írta az egyik első hazai céges webszerveren a cgi-s programokat (még valamikor a múlt században...), és nekem a Perl áll jobban kézre :) és igen, mindenre van legalább két megoldás benne, de ha az ember megtanul rendesen, olvashatóan kódot írni, akkor a Perl sem lesz "sorminta".

"Értem, hogy nálad a Perl is egy becsípődés, de csak te hoztad ide, még csak meg sem említettem" - A topicindító hozta ide a Perl-t, nem én...

Így van. A Python nem isten, de ez az egy előnye van, hogy rohadt sokféle modul, lib van hozzá, Dunát lehet velük rekeszteni. Attól is függ, hogy mit akar programozni, milyen témában, adatbánya, matek, web, vagy akármi. Önmagában viszont mint nyelvet nézve nem jobb a Python, mint egy Lua, Bash, Perl, PHP, Lisp. Más. Még az is mindegy, hogy szerver, azon is futhat akármilyen scriptinterpreter. Ha valaki nagyon állat, akkor akár awk, calc, node.JS stb. scripttel is nyomhatja, ízlés kérdése, hogy mit kíván meg a projekt, milyen libek kellenek, adott fejlesztő épp milyen nyelvet ismer.

Én személy szerint nem szeretem a Pythont, már a szintaxisától feláll a szőr a hátamon, meg istentelen lassúnak is tartom, de elkezdtem matekozásra használni, mivel számításokhoz sztenderd lett, mindenki ezzel nyomul már Matlab, Julia, Octave, stb. helyett, talán az R hasonló még népszerűségében. Lényegében nem is tud az ember olyan problémát, feladatot kitalálni, amihez ne lenne már készen valami használható Python lib, csak győzzük megtalálni.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Python az "eldobható kódok" császára. Gyakran elemzek nagy mennyiségű letárolt telemetria adatokat változatos szempontok szerint. Pypy3 erre a barátom. Egyszer kell kibányásznom a feladathoz szükséges adatokat és megy a kukába ez a kód is. Tényleg nem érdemes ilyen "eldobható kódért" Rust-ban programot írni. Ellenben az utóbbi sokunk véleménye szerint a tartós szoftverek császára.

Ha viszont C-ben/bármiben írt szoftvernél nem elég a statikus konfig, akkor fordíts bele egy apró LUA értelmezőt. Igen könnyű beleilleszteni a C kódodba, adja magát. Kicsi a mérete és szkriptnyelvek között relatív fürge. Minap a Nginx-ben kellett nekem egy spéci redirektáláshoz a LUA. Egyébként az OpenWRT teljes webes konfigfelülete (luci) szintén LUA-ban van megírva. Okai, hogy szkriptnyelven akarták és 8 MB flash-be a kernel mellé mégsem tolhatsz be 30 MB-nyi Python interpretert. :)

Tényleg igaz, hogy mindenhez a megfelelő szerszámot érdemes választani. 19-es villáskulccsal is beverhetsz egy kisebb szöget, de a kalapács praktikusabb választás ehhez.
És akkor a shell szkriptekről meg a gawk-ról nem is beszéltünk. Gawk-ban tesztként egy float-os FFT-it is megírtam külső tool-ok nélkül. Futásidőben is jól teljesített a szkriptnyelvek között.

micropython befer meg egy esp8266 -ba is.

Lasd: https://docs.micropython.org/en/latest/esp8266/tutorial/intro.html

 

The minimum requirement for flash size is 1Mbyte. There is also a special build for boards with 512KB, but it is highly limited comparing to the normal build: there is no support for filesystem, and thus features which depend on it won’t work (WebREPL, upip, etc.). As such, 512KB build will be more interesting for users who build from source and fine-tune parameters for their particular application.

Jupiter-notebook alatt pedig nagyon gyorsan lehet tesztelni, és reszelgetni a kódot. Nekem legalábbis nagyon bejött, amikor nulla tudással kezdem el db kapcsolatokat kezelni. Igazából mindig a python+panda kódok jöttek szembe, amikor mások scriptjeit néztem, így nekem is adta magát ez a páros.

"ez az egy előnye van, hogy rohadt sokféle modul, lib van hozzá, Dunát lehet velük rekeszteni." - Mint említettem, ez nem a pájton sajátja - ez minden értelmes, általános programozási nyelvre igaz. Az, hogy pájtonos szemüvegben nem látszanak, az más kérdés.

"csak győzzük megtalálni" - na igen... Nem ismerve a pájtonos ökoszisztámát megkérdezem: van-e olyan hozzá, mint a CPAN?

Python nagyon jó ha a tab-os sokkon túllendülsz. Nagyon kifejező tud lenni a nyelv, tulképp mindenhez van integráció.
Home automationtől kezdve AWS-hez kapcsolódó dolgokig egy csomót lekódoltam már.

Gábriel Ákos

Python nagyon jó ha a tab-os sokkon túllendülsz.

Mondjuk ezt sosem értettem. BASIC  és assembly volt az utolsó két nyelv, amiben nem használtam indentálást. 88-ban a középsuliban a Pascal-t már indentálva írtuk. Kb. 92-ben programoztam utoljára Assemblyben, azóta minden programot, minden programnyelven indentáltam. Ahogy az összes kollégám is, szintén.

Amikor elkezdtem Pythont használni, ugyanazt az indentálást használtam, mint addig, a programjaim pont ugyanúgy néztek ki, mint mondjuk a C++ programjaim.

Aki a Python indentálást sokként éri meg, az más nyelven se indentál? De ha nem, miért nem? És a kollégákat ez nem zavarja vagy csak mindent újraindentálnak valami programmal így nem derül ki?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

tökéletesen egyetértek!

nálunk addig piros a pull request státusza, amíg nem felel meg a coding standardnak és az egyéni rule-oknak. ebben olyanok is benne vannak pl., hogy if után blokkot kell nyitni, akkor is ha csak egy utasítás van.

egy kollega miatt még diff-et is ad az eredmény, hogy könnyebben patchelje a kódját

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

C-ben en nem nagyon szoktam... meg beirok 5 sornyi kodot 1 sorba. if(x){ a;b;} else {c;d;} ez masnal min 5 de lehet 10 sor is... az elvetemultebbek meg a {-okat is kulon sorokba irjak...

pythonba zavar is, hogy 3 oldalon fer el ami c-ben 10 sor...  pedig py-ben is csinalok olyat hogy "if feltetel: akarmi"  (igy 1 sorban)

Aki a Python indentálást sokként éri meg, az más nyelven se indentál? 

De. Ellenben mas nyelven irt programot atlatod ha kilog a blokk az ablakmeretbol, el tudod kuldeni emailben a szovegbe szurva a kodtoredekeket, tudod copypaste-zni mashonnan, hasznalhatsz mas editorokat mint amit a program szerzoje hasznalt, noplane mas tab-beallitasokkal, esatobbi. 

Ha nem egyedül fejlesztesz, akkor azért szokott előírás lenni arra is, hogy ne legyen a sor végtelen. Mondjuk azt sosem értettem, hogy miért szeretnek olyan elképesztően rövid sorokat előírni (pl. 132 karaktert). Fortranék is belátták már, hogy kevés a 72, de az a 132 is.

Az az "elképesztően rövid" az arra -is- szolgál, hogy áttekinthető legyen, megjeleníthető legyen egyben (nem, a bolha...nyi betű a 4k-s monitoron sasszemmel párosítva nem jó válasz rá).
Próbálj meg egy 1234 karakter hosszú sort megérteni, átlátni úgy, hogy egyszerre csak 234 karaktert látsz belőle.

Ez nem csak szovegszerkeszto-beallitas kerdese?

Amit a legtobbet hasznalok (kate), nem tul okos, de be tudtam ugy allitani, hogy a sor fennmarado reszet a kovetkezo sorba tegye (es behuzza addig, amig az adott sor van), es jelezze, hogy az ott az elozohoz tartozik. Szerintem nem egy urtechnika. Szoval ha 1234 karakter van egy sorban, akkor az 13 sort fog elfoglalni nalam (kb. 100 fer ki, de attol is fugg, melyik monitoron van).

Persze ha meg VT-100-at hasznalsz ed-del, akkor szivas.

A strange game. The only winning move is not to play. How about a nice game of chess?

Aztán döntsd el, hogy a megjelenítés tördeli/húzza be a sort, vagy az valóban n darab sorba van írva és úgy behúzva...
Szerintem fontos, hogy ne a megjelenítőtől függjön az, hogy mennyire olvasható, hogyan van -látszólag vagy valójában- tördelve a kód.

A saját tapasztalatom az, hogy 90-100 karakter még elviselhető hossz, de nagyon határeset - sokkal áttekinthetőbb  - akár egymásba ágyazott, akár n+1 paraméterrel megvert eljárásokat kell leírni - ha élből értelmes darabokra van tördelve.

Kedvencem, amikor ugyanazt a kódot más editor beállításokkal szerkesztenek többen, hol szóközökkel indentálva, hol tab-bal, de a tab sem mindig modulo 8 karaktert jelent, aztán megnyitod valamivel, és olvashatatlanul szétesik az indentálás, össze-vissza vannak a záró kapcsos zárójelek, meg minden más is.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Mondjuk erre legalább a vi már fel volt készülve, :se ts=2 ha jól rémlik az első 5 (?) sorban, és máris 2 helyköz egy tabstop. Emlékeim szerint ilyet az emacs is tud. A többi editor meg úgy se jó semmire ;-)

"Aki a Python indentálást sokként éri meg, az más nyelven se indentál? " - Nem ez a gond, hanem az, hogy kvázi a sorok elejént található whitespace-ek száma határozza meg a kód működését. Az, hogy "must have", az nem probléma, az viszont igen, hogy egy elbökött identálás, vagy épp egy véletlenül elkövetett tab/space mixelés -mondjuk úgy- képes meglepetéseket okozni. És vagy látszik, vagy sem...

Én Perl-ben is úgy írom a kódot, hogy a perltidy nem igazán sokat piszkál bele, tehát lehet Perl-ben is "szép" kódot írni, csak igényesség kérdése.

Az elrontott zárójelezésnél még a vim is mutatja, hogy hol a kezdete/vége a blokknak, egy tab/space mixet meg nem fogsz látni.

Normálisabb editoroknál meg elkezded a blokkot, már rakja a végét is, aztán "kitöltöd" a kezdő/zárő blokkhatároló között. (Én egyébként kézzel is párban rakom a határolókat, egyből identálva ha kell, és utána töltöm ki az adott blokkot kóddal. (a blokkzáró karakter után megy a komment, ami a blokk elejére utal.)

Mivel az általam használt szövegszerkesztők úgy vannak beállítva, hogy .py kiterjesztés esetén automatikusan cserélik a tabot szpészekre, nincsenek space/tab mix problémáim. Az olvashatóságot viszont ez a kényszer drasztikusan növeli. És ez bőven megéri még akkor is, ha kezdőknek az indentálás problémás lehet.

egy tab/space mixet meg nem fogsz látni.

De

Amikor utoljára nagyobb lélegzetű python programozást követtem el, akkor valami python-hoz való IDE-t használtam (talán Eric?), és kiválóan látszott, hogy mi tab és mi space. A space egy kis maszat volt, a tab meg valami más jel. Simán láthatóvá lehet tenni.

Plusz a sima szövegszerkesztők között is van sok, ami boldogan kicseréli az összes tabot beállítható darab space-re.

Olyan helyen, ahol csapatmunka van, ott meg simán be lehet állítani scripteket, amik tab-ot tartalmazó forrás fájlt nem engednek be a source controlba, így nem másoknak kell találgatni, hogy egy tab az vajon 8, 4, 3, 2, esetleg 1 space-re fordítandó-e, hanem aki tabot nyomott, az a saját beállítása alapján konvertálja (scripttel) szóközzé.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Az elrontott zárójelezésnél még a vim is mutatja, hogy hol a kezdete/vége a blokknak,

Kivéve, ha többszáz sor hosszú a blokk, mert akkor szegény vim is képes elveszíteni a fonalat.

Valamint amikor rommá kell zárójelezni egy kódot, az nekem időnként kevésbé átlátható, mint egy indented kód.

 

A zárójeles kódra elrettentő példa pl egy jenkins parallel pipeline.

https://www.jenkins.io/blog/2017/09/25/declarative-1/

Amit most nagyon csípek az a matekos-datascience-s problémák megoldására a jupyterlab.

Nagyon nem sysadmin téma de zseniális cucc.

Ja és a codingame-en 1-2 nap alatt meg lehet tanulni jól a python alapokat (annak aki már tud programozni amúgy)

Gábriel Ákos

Szerkesztve: 2021. 12. 01., sze – 10:09

Érdemes, a python egy egészen jól használható nyelv, gyorsan lehet benne haladni, és lehet benne viszonylag kultúráltan karbantartható kódot írni. (Az, hogy nem statikus, azért okoz némi fájdalmat). Továbbá tényleg elég sok elfogadható minőségű kész megoldás van. (A CPAN ahhoz képest egy kurva nagy, igénytelenséggel megtöltött szemétdomb) A syntax nyilván egyéni ízlés kérdése, nem hiszem, hogy egy akármilyen normális IDE mellett valóban fájni fog.

Alternatívaként esetleg go, de az ugye nem ojjektum orientált. (Illetve hát azt állítják, hogy lehet, de azért amikor el van magyarázva, hogy valami objektum orientált, mert a structok tök jók, nem kell a nyelvbe class, akkor azért érződik a tini fiúk öltözőjének penetráns izzadságszaga a monitor másik oldaláról).

És hát nagyon függ attól, hogy mit értesz szerver környezeten. :)

+1 a Go-ra. 

Engem speciel nem zavar, hogy nem támogatja az OOP-t. 

Nagyon-nagyon régi Pascal/Delphi múlttal és némi bash tapasztalattal 3 óra alatt összeraktam benne egy kis programot (mint első programomat, ami több mint a hello world vagy copy-paste): több alkalmazásszervert figyel egyszerre (PHP-FPM phpstatus?json&full"), parsolja a JSON-t (benne egy embedded tömbös struktúrával), kiszedeget belőle hasznos infókat, vizuálisan megjeleníti a PHP processzeket kivezérlésmérő-jellegűen, leválogatja a lassú futású scriptvégrehajtásokat, mutatja az aktuálisan futó scripteket, szóval minden ami kell egy valósidejű monitorozáshoz.

Ami egészen elképesztő, az a párhuzamos végrehajtás támogatása, és a köztük lévő kommunikáció.

Nem vagyok programozó, de a Go teljesen lenyűgözött.

Egy pillanatra bennem is felmerult, hogy ajanljam-e a Go-t. En is nagyom szeretem, de azert lassuk be, hogy szerver uzemeltetesnel hasznos, ha bele tudsz nezni es/vagy tudsz modositani a programon helyben, anelkul hogy Go fordito kornyezetre lenne szukseged vagy binarisokat kelljen masolgani.

Nyilvan kozeg fuggo ez, mert ha minden lokalis modositas tiltott es mindent pipeline telepit, akkor vegulis mindegy hogy interpretalt vagy forditott nyelvrol van szo.

A java record nem egy record (mint egy C record), csak a neve az, valójában a DDD-ben használt value object fogalom lett felhúzva nyelvi szintre.

A java megmaradt objektum orientált, de van lehetőség funkcionális paradigmát is használni. Szerintem pont elég jól eltalálták a kettő megfelelő arányát.

A mindenki feladta már érdekelne :)

Mármint az OOP-t?

 - DDD?? EventSourcing, mikroszervízek????eléggé OOP szagú amikor a tervezésről, a hogyan állj neki témakör, vagy épp a bounded context, mondhatnám úgy is hogy encapsulation van szóban...

Mármint a Java?

 - Továbbra is úgy látom még mindig a JAVAban megszokott OOPt másolja mindenki... a saját programnyelvébe....még egy golang is beadta a derekát...lásd 2.0 tervezett fejlesztései...JAVA szaga van...

Nem azt mondom hogy ez jó vagy rossz...csak ahol valóban számít, ott még mindig OOP van meg JAVA.

Nem vagyok JAVA dev, mielőtt megkapnám....

Nem vagyok JAVA dev

Atjott, ne felj.

Tomoren osszefoglalva, az OOP encapsulation otlete a gyakorlatban iszonyu nehezkesse es bonyolultta teszi a kodot, mert osszemosodik, hogy egy adott logika hova is valo pontosan, ha tobb kulonbozo objektummal kell dolgoznia. Nagyon gyorsan nagyon el tud bonyolodni, egy halom kodot eredmenyezve, aminek egyetlen funkcioja az adat egyik helyrol masikra lapatolasa (=hulladek).

A megoldas pont az, hogy az adatot es a kodot/logikat kulon kezeled, immutable objektumokkal, pl. Es itt a funkcionalis programozas/lambda is sokkal folyekonyabban simul a kodba, jocskan egyszerubb es kevesbe absztrakt kodot eredmenyezve.

Szerintem azert a bash scriptelest se kell rogton kidobni, sok uzemeltetessel kapcsolatos feladatra boven eleg a shell scripteles. Azzal is lehet jol strukturalt kodot irni.

En ugy erzem, hogy onnantol erdemes mar Pythonnal dolgozni, ha komplex adatstrukturakat kell kezelni (mondjuk JSON/YAML formatumban jon az adat). Es/vagy allandoan futo service-rol van szo, ami halozaton figyel (mondjuk REST server).

Ha rühelled a szintaxisát, akkor ne, válassz olyan nyelvet, amit szeretsz is használni.

Egyébként a Python kiválóan alkalmas a feladatra, én az összes ilyesmi szkriptemhez használom. Csak hogy egy előnyét említsem, amivel szerverüzemeltetésnél naponta fogsz találkozni: a pathlib. Az ezzel kezelt elérési utaknál az osztás operátora (/) van úgy felülírva, hogy ha "osztasz" egy pathlib-es útvonalat egy sztringgel, akkor az operandus bekerül az adott útvonal végébe, pl. root_dir / 'file.txt' -> /path/to/root/dir/file.txt. Apróság, de pont ilyenekért kedvelik a Pythont.

Ha nincs olyan becsípődésed hogy utálsz mindent ami MS, akkor ajánlom a C# + .NET (5/6 | Core) kombót. Remekül megy már Linux alatt is. Nekem elég pozitív tapasztalataim vannak vele.

Én elsősorban azért használok Pythont, mert: 

- könnyen tanulható nyelv, gyorsan trudtam benne vlaós feladatokat megoldani

- amire én használom, igen jó libjei vannak (csv, json,excel táblák generálása, automatizáció paramikoval, unittest, ip címek kezelése, stb)

- az eszközök egy része csak ezt tudja futtatni (cisco hálózati motyók)

- Ansible alapú automatiziós feladataim vannak és a modulfejelsztéshez bárki bármit is mond, a legjobb a Python

Hátránya a sebesség, azonban ez engem nem érint, mert nem sebességkritikusak a feladataim. 
Emelett az OOP támogatása elég karcsú, bár ez sokakat nem zavar.

 

Szerkesztve: 2021. 12. 01., sze – 11:28

python nem jobb mint a perl.

python -t tobb ember ismer, tehat valoszinuleg tobb ember tudja kijavatani a hibaidat.

autopep8 --max-line-length 948
Ez segit hogy ne neked kelljen formazni,
aztan majdnem olyan gyorsan lehet halladni mint perl -el.

A technikai elony hatrany lista  hasonlo a ket cumonal, az ember tomeg ter el.

 

Ha python-tol valamelyeset gyorsabb cuccot szeretnel ami meg mindig viszonyalg egyszeru akkor golang van ott.
rust is szoba johet.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Önmagában az a tény, hogy kivitelezhetlen benne egy normális kivételkezelés, a nyelvet a hobbi/ egyszemélyes quick&dirty szkriptelés kategóriába zárja. A paraméterkezelés tervezési gyengeségből adódóan problémás, a munkaváltozó puszta léte is veszélyes, a CPAN pedig egy szemétdomb. A zavaros szintaxis, az emberi nyelvekből átvett ötletek már csak hab a tortán. 
Minden stat azt mutatja, kihalófélben lévő nyelv, persze olyan szinten megmarad, mint az ObjectPascal  vagy a COBOL.

Lehet, hogy a Perl6 majd felhozza a nyelvet  - ugye ott méár azt ígérték, a nyelvet próbálják meg feljavítani és nem a felhasználókat. Készül már vagy 20 éve, úgyhogy azt nem mondhatjuk, nem adták meg a projektnek a kiforrásához szükséges időt. 

Én elhiszem neked, hogy olvasható, jó minőségű kódokat írsz benne gyorsan. Csak ezt a Perl nem hogy kényszeríti ki, még csak nem is segíti. 

CPAN modulok majdnem mindent lefednek.
Valoban gyakran irnak nagyon tomoren CPAN modulokat, amit nehez dekodolni elsore,
de ha jobban megnezed az olvashatobb valtozat akkar 10x tobb kod sor lenne es lassabb is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Boncoljuk meg a dolgot. Adjunk át két adatvektort Perl szubrutinnak, például az alábbi Python példát nézzük meg, hogyan néz ki Perlben:

#!/usr/bin/python3

def teszt(arr1, arr2):
    print ("Első:", arr1)
    print ("Második:", arr2)

a1 = [1, 2, 3]
a2 = [10, 20, 30]

teszt(a1, a2)

Backslash-bűvészkedések nélkül megoldható?

sub foo{
        my ($p1, $p2) = @_;
        my $elso = join(',', @$p1);
        my $masodik = join(',', @$p2);
        print "Első: [$elso]";
        print chr(10);
        print "Masodik: [$masodik]";
        print chr(10);
}

foo([1,2,3], [10,20,30])

Mi a baj a '\n' -el ? Miert nem kell blackslash ?

sub foo{
        my ($p1, $p2) = @_;
        print "Első: @$p1\n";
        print "Masodik: @$p2\n";
}

foo([1,2,3], [10,20,30])

~                           

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a \n-re gondoltam. :)
Régebben emlékeimben van egy olyan hiba, hogy ha átadtam két vektort vagy $scalar és @vektort argumentumként, akkor összefolyt a Perl-ben ha nem \@-ként kezeltem.

Ezek szerint ezt a hibát már javították benne. Bosszantó volt, mert minden lefutott csak az eredmény volt hibás.

A Python messze jobb, mint a Perl. Nem véletlenül terjedt el az a mondás, hogy The only language that looks the same before and after RSA encryption

Amikor már bejönnek a rekordok, objektumok és társai, baromi hamar olvashatatlan lesz a kód. Azt szoktam mondani, hogy Perlben nagyon nehéz olvasható kódot írni, Pythonban pedig nehéz olvashatatlant. Ez persze némileg túlzás, de csak némileg. Régen, még vagy 15-20 éve én is Perlben írtam sok mindent, de amikor találkoztam mások által elkövetett Perl scriptekkel, elszörnyedtem, mennyire érthetetlen kódot lehet írni (tudom, magas labda). Pythonban sokkal ritkábban van ilyen érzésem.

Egy kódot pedig általában egyszer kell megírni, viszont rengetegszer módosítani (feltéve, hogy amúgy a program működik), így az olvashatóság nagyon sokat számít. ("semmi sem ismeretlenebb, mint az általunk fél évvel ezelőtt írt program")

Meg pl az otrs, vagy mondjuk a mojo.

Ettől még nagyságrendileg több hányadék szokott szembejönni az emberrel, ami valószínűleg abból is adódik, hogy egész sok féle képpen lehet írni, aztán mindenki hozza magával a hátterét. Utána még beleteszi a saját kis hülyeségeit, meg használja a perl "írni jó, nem olvasni" featurejit (ami az ő fejében nyilván olvasható lesz, meg handy, mert megvan a pattern a fejében, mindenki másnak meg keresztbe áll tőle az agya, és lesz így még több saját kis hülyeség) és kész is a tragédia.

OTOH: némelyik "pythonikus" megoldás is olyan, hogy bleh.

Egyrészt igen :) Másrészt azért nem feltétlen, ha valaki kvázi rögzít valami syntax sugar patternt, akkor fogja érteni, mert az mindig úgy csinálja. Mint tudom is én, pythonban tipikusan a lambda ilyen. Ha tudod, mert megszoktad, akkor elolvasod, ha nem szoktad, akkor görcsbe rándul az agyad. Csak a perlben több ilyen basz van, és obskúrusabbak :)

Ez a lambda megnevezés is mennyire rossz. 
Nagyjából mindenhol a "small anonymous function" de aztán ahány nyelv valójában annyiféle...

Pythonban mondjuk eléggé erőteljes bár én még nem találkoztam problémával ahol mindenképpen ezt akartam volna használni.

Gábriel Ákos

Pythonban mondjuk eléggé erőteljes bár én még nem találkoztam problémával ahol mindenképpen ezt akartam volna használni.

Épp ezért gondoltam analóg példának arra, hogy perlben mindenféle irányból tudod hozni a máshonnan jövő megszokásaid. Ha valami funkcionális nyelv irányából jöttél volna pythonozni, akkor te is mindenhova istenverte lambdákat írnál.

Több éve nem nyúltam adott Perl kódomhoz, a multkorában valamiért elő kellett venni (az a webes (pájtonban elkövetett...) alkalmzás, ami elé egy előtétként lett odarakva, változtatott a kiköpködött/elfogadott json tartalmán). Semmi gond nem folt az olvashatósággal/érhetőséggel. Igaz, bőven van kommentezve, szét van szedve modulokra, és nem átallottam beszédes neveket adni mindennek, egységes nevezéktant/formátumot használva a neveknél...

Az a tapasztalatom, hogy az általam használt/piszkálgatott nyelvek mindegyikében lehet olvashatatlan kódot írni, ahogy olvasható, könnyen értelmezhetőt is.

Saját kódot továbbírni, módosítani - főleg ha nem csak össze volt hányva, mert határidő! - nem nagy kunszt. Ha tudom, hogy nem eldobható kódot írok, és várható hogy még hozzá kell nyúlnom, akkor bőven kommentezem, esetleg használom az irodalmi programozás (https://en.wikipedia.org/wiki/Literate_programming) eszközeit.

Más szemetében turkálni az már más. Az a kérdés, hogy mennyire tudnak a többiek olvashatatlan kódokat készíteni az adott nyelven, s a független review mennyire céges előírás - hogy tegyen ellene. Egyes nyelvek is próbálnak az olvashatatlanság ellen tenni, a Go pl. saját maga formázza a forráskódot, más nyelveknél meg előírás a formázás. Igaz egy csak egy lépcsőfok, de szerintem ennyivel is előbbre vagyunk. 

AL

"Az a kérdés, hogy mennyire tudnak a többiek olvashatatlan kódokat készíteni az adott nyelven" - Pont ezt írtam, hogy mennyire tudnak, és mennyire _akarnak_. Akár Perl-ben, akár Python-ban, akár n+1 általam eddig valamilyen mértékben használt programnyelven lehet szép és tiszta kódot írni, ugyanúgy, ahogy igénytelenül összehányt szemetet is. Ez _nem_ attól függ, hogy kötelező-e, és a nyelv része-e az identálás vagy sem.
Aki igénytelen, az Python-ban sem lesz igényes...

10k sor az sok? Cobol-t láttál-e már? Egyébként ha korrekten megírt Perl kódról/alkalmazásról van szó, akkor a 10k sor nem sok - ha "csak" összelapátolt scripthalmaz, akkor valóban megfeküdheti az ember gyomrát... A kérdés az, hogy mi volt az ok, amiért a teljes átírás mellett döntöttetek?

Nem tudom, hogy sok-e 10k sor arra a feladatra, amire használtuk, ennyiben írták meg, egyébként szakmájukhoz magas szinten értő emberek.  Az átírás fő oka a piaci nyomás, a vendorok nagyon pusholják a Pythont - valahol egyszerűen muszáj Pythont használni, másrészt a Perlben dolgozó munkatársak hamarosan nyugdíjba mennek, és Pythonhoz értő szakemberből nagyobb a kínálat.

"és Pythonhoz értő szakemberből nagyobb a kínálat."

Mondjuk tapasztalataim szerint (szoktam interjúztatni) a pythonhoz értő szakemberek jelentős része sajnos csak két dologhoz nem szokott érteni: a programozáshoz, meg a pythonhoz. Meglepően sokan vannak, akik analógok a perlben összegányol valamit rendszeradmin szakikra 20 évvel ezelőttről. Azok is, akik programozónak képzelik magukat, mert a cégüknél dolgoztak valamin, ami pythonban volt, és a végén már majdnem 300 sor hosszú lett. Patterneket, programtervezést, clean codeot max könyvből, a nyelv quirkejit nem látják át, a featureök meglepően nagy részét nem ismerik.

És akkor vannak még a mindenféle adattudósok, akik egyébként tök okosak, meg kenik vágják a matekot és a numpyt, csak programozni... szóval azt szeretném mondani, hogy openssl szindróma.

Ez biztosan így van - de nekem olyanok kellenek, akik erősek hálózatos témákban, és  meg tudnak írni egy automatikus report generálást vagy valami specifikus feladatot o hálózati eszköz   on box python shelljén futtatva, ha kell,. A reportolást Felőlem írhatná akár ASM-ben is, de ha van már egy infrastruktúra specifikus, az évek alatt lecsiszolt és bizonyított keret Python alapon, akkor kifejezetten előny, ha Pythonhoz ért, bizonyos helyeken meg nincs is más alternatíva, ha egyszer a gyártó Pythont rakott az eszközére. 

A jelenség, amiről beszélsz, általános, hálózati mérnöknek képzelik magukat, mert végigcsináltak pár tutorialt Packet tracerben, el tudom képzelni, mi mehet egy web programozói felvételi folyamaton, satöbbi, satöbbi. 

ÉS ez még csak nem is Magyarország specifikus, már régóta Németországban élő és dolgozó fejvadász ismerősöm horror sztorikat mesél. 

 

Ez megmagyarazza miert nez ki ugy a software manapsag ahogy ..

Regen mindnki aki irt 100 sor PHP -t programozonak kepzelte magat, manapsag s/PHP/Python/

En gondolozom azon, hogy devops pozicioinkra C ismertet kene beirni kovetelmenynek, talan kevesebb olyan jelentkezne,
aki nem tudja hogy megy a szamitogep.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egyvalami tuti biztos:

kevesebb jelentkezne

Azaz még nagyobb lenne a hiány. Tényleg rengeteg apró feladat van, ahova ha minimális kódot képes lenne összehányni a kolléga, akkor azzal a feladat nem maradna megoldatlanul.
A probléma inkább azzal van, hogy gyakran az apró kódot összetákolni képes szinten átsiklik a személyzetis és az alulképzettet dobja be valami nagyobb projektbe, aztán lesz ami lesz.

Egyébként mélyebbre nyúlik a probléma. Régen a 4..5 éves szakképzés után papírral igazolt embereket tekintettek szakembernek. Én is egy 5 éves technikumban kezdtem szakmai tanulmányaimat, igen alapos volt ott a szakképzés.
Ma viszont divat lett, hogy például egy gimnázium elvégzése után maximum egy felsőoktatás jön, ahol sok egyebet megtanulsz. Aztán a szakmát némi internetes olvasgatás, netán néhány hetes gyorstalpaló alapján próbálod részben elsajátítani és már szakembernek próbáljuk tekinteni ezt a szintű embert. Pedig belátható, hogy tuti köszönőviszonyban sincs a képzettsége egy ilyen irányú 4..5 éves szakképzésen átesettel.
A programozás teljesen ilyen. Szisztematikus 4..5 éves programozó szakképzés helyett mindegyikünk elvégzett gimnáziumot és esetleg valami egyetemet és azután autodidakta módon tanulja meg a programozást olyan szintig  ameddig eljut. És programozónak tekintjük.

Szakképzés:
   - programozó: https://szakkepzes.ikk.hu/szakmakartyak/szakmak/szoftverfejleszto-es-te…
   - üzemeltető: https://szakkepzes.ikk.hu/szakmakartyak/szakmak/informatikai-rendszer-e…
   - hálózatos: https://szakkepzes.ikk.hu/szakmakartyak/szakmak/infokommunikacios-haloz…

Ezt próbáljuk pótolni nettó néhány emberhónapnyi képződéssel. Egyúttal a cégek HR-je összemossa a gyorstalpalós "szakembert" a fenti, sok-sok éves alaposan képzettel. Így alakul ki az, hogy a fenti szakképzés a pályaválasztók szemében leértékelődik, hiszen gyorstalpalóval is ugyanabba a bérezésbe fognak kerülni egy cégnél.

Régebben én is perleztem, de tényleg egy hányás a kód, ha objektumorientált szintig jutsz vele.

Az utóbbi években parancssoros PHP-t használtam ilyen célra a C jellegű szintaxis miatt. Az égvilágon mindenhez vannak hozzá modulok.

Egy időben Rubyval szemeztem, de PHP jobban előfordul mindenhol.

Mostanában azon agyalok, áttérek inkább node.js-re. Javascript nagyon jól használható nyelv lett újabban.

Konnyen tanulhato, es jol hasznalhato nyelv. Gyorsan lehet benne haladni, rengeteg lib van hozza. Eddig egyeduli hatranyakent a sebesseget talaltam, bar azon is lehet segiteni.

Amit a Perlben sokan szeretnek (regexp tamogatast), azt a regexp (re) modullal tudod elerni, nem nyelvi elemkent.

Mikrokontrollerre mondjuk nem ezt hasznalnam, arra ott a c vagy c++, de arra, hogy a mikrokontrolleren futo koddal a PC/RPi oldalarol kommunikaljon, mar igen. Tobb olyan feladatom volt eddig, amit igy oldottam meg.

A strange game. The only winning move is not to play. How about a nice game of chess?

A hátrányokhoz szerintem fel lehet még írni, hogy a függvények szignatúrájából és a dokumentációból nehezen/ritkán derül ki, hogy mi történik hiba esetén, mikor dob valami. Ha csak a happy path érdekel, akkor persze ez nem lényeg, csak majd pár héttel/hónappal/évvel később lepődsz meg :) A go explicit hibakezelése ebben például sokkal jobb, már fejlesztés alatt át kell gondolnod a hiba lehetőségek nagyobb részét és kezelned őket.

Kifejted kicsit bővebben a szerver üzemeltetést?

Nekem nagyon rossz tapasztalataim vannak Kerberossal Python alatt.

Miért nem valami idempotens IaC megoldás, mondjuk Ansible? :)

Tehát tényleg a Python az Isten?

Igen.

Ha a szerverüzemeltetésbe belevesszük a Kubernetes-t is, akkor egyértelműen nyitni kell a GO felé is. 

Ha komolyan is akarsz programozni, akkor statikusan típusos nyelvet tanulj meg! A dinamikus típusozás csak bohóckodni jó.

Ha megnézzük a problémákat, a problémák számát tekintve legalább 95%-a csak apró tool-ok írása. Gyakran itt megakad a cég, mert senki nem tudja megoldani a 20..50 soros nyúlfarknyi feladatot.
Aztán van a néhány százaléknyi probléma, ami közepes programocska és van egy csekélyke százalék, amely valami nagy lélegzetvételű program írását jelenti.

Ebből kifolyólag valójában mindegyik tudás hasznosabb a "nem tudok semmilyen programot megírni" szintnél.

ezzel nagyon egyet tudok erteni. a dinamikusnal nem tudod te se biztosan milyen tipust kapsz majd vissza a fv-tol, a parser/compiler sem tudja ellenorizni (csak runtime), es amikor fel akarod hasznalni ugyis konvertalni kell valamerre...  lehet teleszopni a kodot exception kezelessel meg az esetek tobbsegeben folosleges konverziokkal...

Hát, ha csak a happy path érdekel, akkor de* :) Hibázni könnyű, a hibák runtime fognak kiesni, szóval ha védeni akarod a popódat, akkor írsz egy vödör unittestet a fordító helyett, meg runtime ellenőrzöl egy csomó mindent.

*Kivéve, amikor valamibe bele kell hívni, és hosszan kell kódot olvasni, hogy na, abban a paraméterben vajon mit is vár a kód.

Gondolom erre is van valami forráskód-analizátor, ami felhívja a figyelmet a tipikus hibákra, ezzel szűkítve a kört.

Na meg hiába erősen típusos egy nyelv, ott is futásidőben fognak előjönni a hibák: a felhasználónál a szoftver nem úgy működik ahogy kéne. Erre vannak az 'alpha' meg 'beta' kiadások, utána meg az x.y.1 javítgatások, mert runtime fognak kijönni a hibák. Ebben nem látok semmi különbséget a dinamikus nyelvekhez képest -- gyakorlati oldalról.

Gondolom erre is van valami forráskód-analizátor, ami felhívja a figyelmet a tipikus hibákra, ezzel szűkítve a kört.

Ami azt csinálja, mint egy statikus fordító? :D Van, van, de messze nem olyan. Főleg, ha építesz is a dinamizmusra, márpedig építesz.

Na meg hiába erősen típusos egy nyelv, ott is futásidőben fognak előjönni a hibák: a felhasználónál a szoftver nem úgy működik ahogy kéne. Erre vannak az 'alpha' meg 'beta' kiadások, utána meg az x.y.1 javítgatások, mert runtime fognak kijönni a hibák. Ebben nem látok semmi különbséget a dinamikus nyelvekhez képest -- gyakorlati oldalról.

Nagyon nem mindegy, hogy mennyi, meg hogy mennyi plusz effort kell, hogy kb egy szinten légy a kódod jó működésének a bizonyosságában. Ettől még nyilván lehet jó programot írni dinamikus nyelven is, (meg szart statikusban), még az is lehet, hogy kevesebb effortal, de ettől még igen, a dinamizmusnak ára van.

Hát, az, hogy az önmagában nem csinál semmit, az pontosan azt jelenti, hogy attól, hogy type annotálsz, még az égvilágon semmi nem fog változni a futó programodban, az interpreter ezt egész magas ívben szarja le. Kellenek hozzá külső eszközök, hogy valami haszna is legyen (tehát nem önmagában). Szóval de, azt jelenti. Azt aláírom, hogy sokkal kevésbé expliciten. :)

Ha nincsenek statikus típusok, akkor is tudni kell, hogy mi van egy változóban... Érted, semmi értelme műveleteket végezni valamin, amiről nem tudjuk, hogy az mi... Valójában a dinamikus nyelvekben is számolnak a programozók a típusokkal, csak mindazt fejben csinálják, amit egy statikus nyelvben a fordító megcsinál "ingyen".

Amint 1-2 képernyőnél több a kód, és ugrálni is kellene benne, pláne 1000x jobb ami statikusan típusos, mert ezken az IDE olyan segítséget ad, hogy mint egy hálózatot látod a programodat, tudod minek mivel van dolga. Ezt a dinamikus nyelven nem tudják, csak maximum a felszínt kapirgálni.

pontosan... olyan, mintha C-ben minden void* lenne vagy javaban Object. aztan lehet mogotte barmi, de ugyis tudnod kell mi az, mikor hozzanyulsz... akkor meg minek?

nem azt mondom, hogy nincs neha olyan amikor kenyelmes a tipus nelkuliseg, de ritka, es megvan az ara, sokszorosan.

raadasul tul sok haszna sincs, mivel nemigen csinal automatikus konverziot a python, pl:

>>> x=7
>>> y="hello"
>>> print(x+y)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

Amugy van annak is elonye, hogy megirsz valamilyen algoritmust, es utana barmilyen tipus bemehet, azt felhasznalhatod ugyanugy. C++-ban emiatt van template, meg Javaban generics, mert ha megirtal mondjuk egy ujfajta B-tree implementaciot, kenyelmes, ha barmilyen tipusu adatokat tudsz benne tarolni.

Csak egy egyszeru peldakent itt egy negyzetreemelo fuggveny (nyilvan ott az x**2, nem ez a lenyeg), es az, ahogy egy vegyesfelvagottat tartalmazo listara lefut: (itt ugye nem a valtozoknak, hanem az ertekeknek van tipusa)

>>> def square(x):
...   return x*x
... 
>>> l=[2,2.5,1j,np.array([[1,2],[3,4]])]
>>> for i in l:
...   print(square(i))
... 
4
6.25
(-1+0j)
[[ 1  4]
 [ 9 16]]

A strange game. The only winning move is not to play. How about a nice game of chess?

Azert, mert a numpy tomboket elemenkent szorozza. Matrixszorzatkent is tudja ertelmezni, a numpy.dot-tal, de gondolom eleg sokszor tobbdimenzios tombot, es nem matrixot tarolnak benne, igy az a default.

>>> a=np.array([[1,2],[3,4]])
>>> a**2
array([[ 1,  4],
       [ 9, 16]])
>>> np.dot(a,a)
array([[ 7, 10],
       [15, 22]])

Roviden ezert.

A strange game. The only winning move is not to play. How about a nice game of chess?

Ez a dinamikusan típusos nyelvek ámítása, hogy azt mondja nem kell típus mert azt majd kitaláljuk és így lehet olyan kódot írni ami beveszi az adatot mindenféle formában és működik.

Gakorlatilag meg nem, vagy nehézkesen. Az esetek 99.99%-ban 1 féle formátumú adatot küldöl be.

 

Kedvenc példám, azt hiszem a Pecan nevű webapp libből való. Bármilyen pecanos osztálynak ami hhtp headereket is fogad a headert egy map/dict (kinek melyik név tetszik) formában kell megadni kivé a Response osztálynak mert az 2 elemű tupleok listáját várja. Agyrém!

// Hocus Pocus, grab the focus
winSetFocus(...)

http://c2.com/cgi/wiki?FunnyThingsSeenInSourceCodeAndDocumentation

Gakorlatilag meg nem, vagy nehézkesen. Az esetek 99.99%-ban 1 féle formátumú adatot küldöl be.

Azért a duck typing gyakorlatilag implicit interfaceket jelent. Értem én, hogy nehéz biztosra menni, de sokszor baromi kényelmes tud lenni.

Kedvenc példám, azt hiszem a Pecan nevű webapp libből való. Bármilyen pecanos osztálynak ami hhtp headereket is fogad a headert egy map/dict (kinek melyik név tetszik) formában kell megadni kivé a Response osztálynak mert az 2 elemű tupleok listáját várja. Agyrém!

Az ám. Mármint elég borzasztó, hogy egy webapp lib egyetlen helyen képes megfelelően kezelni a headereket, mindenhol máshol szar :D 

Divat lett pájtonozni, mert az igénytelenül, kódot formázni nem tudó/nem akaró "fejlesztőkre" (én inkább kódgányolónak nevezném) rákényszeríti, hogy "szép, olvasható" kódot írjanak. Szép meg olvasható lesz, de tartalmilag marad trágyadomb, mert programozni nem tanulnak meg igazán, csak pájtonul tudnak valamennyire...

A formázáson többek között az múlik, hogy mennyire lesz nehéz, amikor legközelebb hozzá kell nyúlni, meg hol bakizol bele véletlen (mondjuk vicces módon ennek egyik legjobb példája a baljobb cicis nyelveknél szokott megesni, amikor egy utasításnál ki lehet hagyni a őket, aztán ütsz egy entert, és szépen indentelve fog hülyeséget csinálni... bezzeg a randa python :D )

Tudom, hogy ez neked becsípődésed, és ezért teljesen felesleges mellette érvelni, de

- akkor ugyanilyen tervezési hiba, hogy van blokk nélküli egyszeri utasítás

- egy darab space rohadtul nem csúszik keresztbe, büdös nagy indent errort fog adni. (Igen, runtime, de az nem a space miatt van, hanem az interpertáltság miatt. És egyébként is unittesztelünk ugye).

- Természetesen a linter is fog sipákolni, meg alá fogja húzni az editorban, hogy ez mi a fasz.

- pythonban pont ugyanúgy írunk kódot, mint bármi másban. A következő utasítás előtt ütünk egy entert, ha új blokk kezdődik, akkor még egy tabot is, bár az általam használt editorok -- pont ugyanúgy, mint blokkhatárólós nyelveknél -- felismerik, hogy ez most az lesz, és eleve behúzzák, csak nem teszik ki a blokk jelet, mert az itt épp nincs, ha vége a blokknak, akkor meg egy backspacet. És pont ugyanúgy látszik, hogy benne van-e a blokkban az indenttől. Idejét nem tudom, mikor nyomtam meg a spacet amiatt, hogy indenteljek.

 - és végül, azon természetesen lehet vitatkozni, hogy ez most jó vagy nem, meg ez egyéni ízlés kérdése is, de ez egy minor issue, őszintén szólva az, hogy te ezt ennyire dealbreakernek állítod be, elég nevetséges. Különösen annak fényében, hogy nagy mellénnyel érvelsz, hogy pont ugyanúgy van perlhez is minden, miközben még csak a pypi létezéséről sem tudtál.

"akkor ugyanilyen tervezési hiba, hogy van blokk nélküli egyszeri utasítás"

A lehet ilyet csinálni, amivel el...hatod a kódot, meg a whitespace-eket a kód részévé tenni azért eléggé nem ugyanaz.

"Különösen annak fényében, hogy nagy mellénnyel érvelsz, hogy pont ugyanúgy van perlhez is minden, miközben még csak a pypi létezéséről sem tudtál." - Attól, hogy nem tudtam a pipiről, még bőven igaz az, hogy Perl esetében is mindenhez lehet eszközt találni, ergó a pipi és a "mindenhez van eszköz" baromira nem egyedi, és nem előnye a pájtonnak a többi nyelvhez képest. 
 

A lehet ilyet csinálni, amivel el...hatod a kódot, meg a whitespace-eket a kód részévé tenni azért eléggé nem ugyanaz.

ja, valóban, ezt csak policyből kell írtani.

tól, hogy nem tudtam a pipiről, még bőven igaz az, hogy Perl esetében is mindenhez lehet eszközt találni, ergó a pipi és a "mindenhez van eszköz" baromira nem egyedi, és nem előnye a pájtonnak a többi nyelvhez képest. 

Hát, leszámítva, hogy valójában fingod sincs, mit hasonlítasz mivel. Én perleztem is elég sokáig, szeretem is, de szerintem a perlhez elérhető "mindenhez van eszköz" baromira sokkal kevésbé igaz, mint pythonban, a minőségük meg főleg nem. (pl nézz rá ebben a perlre: https://openapi.tools/, csak random példa) Persze jó pár éve nem írtam újat, lehet, hogy azóta a cpan javult, de őszintén szólva kétlem, épp azért, mert a perl nem popular mostanában.

De mégis használod mert igazából nem számít.

Lol. A kedvencem amikor az istenbarma az O(1) memoriaigenyu algoritmust vegtelen elegans modon palytonban implementalja ugy hogy az univerzum ossszes memoriaja sem eleg neki. Es amikor uzemeltetokent-feleloskent nezem a dmesg-ben az oom-killer amokfutasat, akkor... akkor arra keresek vegtelen elegans megoldast hogy hogy mozgatom at az osszes palytonos formedvenyt a geprol a helyere (i.e. a picsaba).

Mert nyilván ha perl-ben írta volna, akkor nem lenne ugyanolyan gáz? Oh, wait, dehogynem. De akkor itt felteszem a kérdést: mint üzemeltető, adtatok visszajelzést a fejlesztőknek? Adtatok korlátokat, illetve kértétek tőlük, hogy milyen paraméterekkel, milyen memória foglalással fog az alkalmazás futni?

Minden nyelvben lehet vacak programokat irni, minden nyelvben lehet olyan programokat irni ami felzabalja a mindenkori rendelkezesre allo memoria tobbszoroset. De a palytonban megcsak nem is az a szurrealis hogy mindezt a ket dolgot ugy tamogatja alapbol hanem meg az hogy fel is magasztaljak az egekig mindezek tudtaban, pozitiv tulajdonsagkent hangsulyozva. 

Mondjuk amig egy egyszeru kis verziofrissites utan mar elobb osszesfossa magat egy ehhez hasonlo varazsprogram, megmielott felzabalna rezidenskent az osszes memoriat is, addig talan nincs akkora gond. 

Persze hogy kapnak visszajelzest. Pl hogy tanuljanak meg programozni :) 

Az egekig magasztalás szerintem inkább a könnyű belépési küszöbjéből fakad, amely egyenes következménye hogy sok cégnél ezáltal tudnak (emberi tényezők miatt) elvarródni az egyszerű feladatok.
Ellenben teljesen igaz, hogy mindenre használjunk megfelelő szerszámot. A fúrókalapácsom tud vésni, hasznát vettem már néhányszor. De vannak komolyabb munkák, amikor bontókalapács a célszerű, sőt van amikor ennek a markológépre szerelt nagytesója a praktikus. A baj az, hogy ha nem megfelelő szerszámmal állunk neki az adott feladatnak, mert mondjuk csak annak a kezeléséhez értünk.
Mindez fordítva is igaz: néhány tégla kibontásért nem célszerű nagy bontókalapácsot odacipelni.

Minden programozási nyelvnek megvan valójában, hogy mire optimális és gyakran látjuk azt is, hogy mire van csak azért használva, mert csak annak a "kezeléséhez" ért a munkaerő/főnök/stb.

Nézd meg Python oktató könyveket.
   - játékos módon tanítják meg az alapokat, szinte minden lépését teljes kipróbálható példákkal bemutatva.
   - jól használható alapfogásokat, szinte kész kalapból előrántható alapfogásokat próbál a legtöbbje oktatni. Sikerélményre mennek.

Végy elő ezután egy-két Rust könyvet:
   - kis demó ("Hello World"-ön picit tovább menve)
   - aztán irány a mélyvíz, bele a nyelv lehetőségeibe. Ha nem vagy kitartó, lepattansz.

Érezhetően más a hangvétel, más célközönségnek szól.

Úgy tűnik minden problémára van megfelelő eszközöd már most is. Gondolom a szerver programozás alatt automatizálást értesz. Nem vagyok rendszergazda, de CI miatt sokat automatizálok, ennek kapcsán az alábbi pythonos tapasztalataim osztanám meg:
- c/c++ build kimenetet konvertálok filterrel JSON -re. Kb. egy csomó regexp, majd egy JSON dump. Perl -ben iszonyat gyors, pyhton -ban halál lassú. Az is kérdéses érdemes e JSON -re konvertálni, mert az utólagos szűrés halál lassú. Pl. egy CSV -t grep -pel millioszor gyorsabb szűrni, mint JSON -on pyhton -nal iterálgatni. Az mondjuk szexi, hogy a CI kimenet értelmesen megjelenik böngészőben külön trükkök nélkül.
- az egyik srác python objektum hierarchiát írt a tesztek párhuzamos futtatására. JSON -ból olvassa mit kel tenni, aztán futtat. A végére kb. újraírta amit a parralells vagy az xargs már tud. Csomó fejlesztési idő, tesztelés, kevesebbet is tud, karbantartani is nekünk kell, stb... Azaz könnyű elcsábulni, mert ugye ott egy full-blown programozási nyelv. Persze windows -on nem futott, mert a felhasznált szálkezelés nem volt cross-platform. Végül újraírtam, jinja -val töltök ki egy bash template -et. A generálást makefile vezényli. Mindenki azt csinálj amiben jó. Struktúrált konfig JOSN -ben, Python feldolgozza, bash hajtja az OS -t, make ad az egész fölé CLI -t. Hibát keresi is egyszerű, hiszen a kimenő bash szkript olvasható, debuggolható. Pyhton -nal ugyanez halál, hacsak nem vagy tapasztalt python programozó.

Egy szó mint száz, nem kell hasra esni attól, hogy a Python nagyon divatos. Használd azt ami kiforrott (shell), ha nem elég, kombináld azzal amit a csapatban a legtöbben tudnak, és ami neked kézre áll. A perl nagy erénye számomra, hogy a git-bash része, ergo minden platformon ahol fejlesztünk ott van alapból. (És mégis Python -ozunk, mert a fiatalok azt szeretik.)

Ja, és mikrokontrollerre felejtsd el a Python -t. Kb. akkor lehet jó, ha a felhasználónak akarsz egyszerű bővítési lehetőséget adni (pl. programozható adatrögíztő, vagy teszt eszköz).

Mi a bajod a szintaxisaval? Szepen olvashato, logikus a kod. Az elejen fura, hogy nem kell blokkokat csinalni, de igazabol eleg hamar raall a kezed.

Nagyon hasznos tud lenni bármilyen nyelvnél az, ha a blokk végén van "visszautalás" arra, hogy az adott blokk mivel kezdődött. lett légyen Pascal, C, vagy mondjuk Perl. Tudod anno a Fortran 77 volt az a nyelv, amit használtam is, és amiben a sor első hat, illetve a 73-80 karakterének speciális jelentése/feladata volt - azaz nem volt mindegy, hogy hol (és mivel) kezded a sort (mondjuk a kód elég jelentős része hat szóközzel indult...).

Clean code. Erre a részre a TL;DR az, hogy a kód legyen magától olvasható, öndokumentáló, illetve hogy ne legyenek side effektes dolgaid. Ebből eléggé következik, hogy nem kell kommentet írni, mert az annak a beismerése, hogy a kód nem dokumentálja jól önmagát. (És kommentet karbantartani szar, mert simán elfelejted. Ha ott helyben nem is, a file tetejéről már lehet, a valahol tök máshol beírt (ezzel itt nem foglalkozunk, mert hat fileal arrébb csinálja valami típusúakat meg szinte biztos, és nem segít a linter)

Ha valahova blokkzáró kommentet kell írni, akkor az a blokk túl hosszú, vagy túl sok minden van nestelve, kéne lássam ránézésre, hogy mi van egyben. Másik ilyen tipikus példa a "this does" jellegű kommentek, amikről szaglik, hogy na ezt ki kéne szervezni külön, és nevén nevezni.

"És kommentet karbantartani szar, mert simán elfelejted. " - Ez nálam ugyanolyan, mint valahol lefelejteni egy utasítást... A forráskódot nem csak a gépnek, hanem embernek is írjuk, és igen, a kommenteket is karban kell tartani.
És inkább legyen kétféle "nyelven" leírva valami, minthogy az, aki később olvassa/írja a forrást, félreértsen bármit is.

Ez csak annyit jelent, hogy fiatal vagy :-) Meg nem volt szerencséd hosszas vonatozáshoz, vagy épp olyan hét végi "pihenéshez" ahol "természetesen" nem volt net, nem volt PC/notebook - Ezek az offline idők pont alkalmasak (voltak) arra, hogy az ember átnézze, átgondolja a kódot, nem 123456 próbálgatással, hanem agyalással. Csak agyalással.

Nekem az egyik osztálytásam anyja Turbo Einstein assembly kódját kinyomtatta leporellóra, mert érdekelt hogyan kódolja le a szalagra a turbó az információt.
Praktikus volt színes ceruzával nyilazgatni a BNE, BCS, JMP hogy hova ugrik és sok kommentet odarögzíteni, órajel időzítéseket számolni a papírra.

Ha nyilazni kellett, akkor az nem forráskód volt - bár ezt valóban nem írtad -, hanem egy disassemblált lista, ami sokkal borzalmasabb, mint egy érthető assembly forrás. Ugye, nem mindegy, ha a változó neve utal a funkciójára, vagy csak egy memória cím.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Disassemblált lista volt. Az 1990 előtti időkben nem volt szokás a GitHub-ról letölteni a forráskódot.
De ennek is örültem, hogy papíron elemezhettem ki és nem a képernyőről jegyzeteltem.

Érdekes egyébként, a BBS korszakból teljesen kimaradtam. Mondjuk az is igaz, hogy bár be volt fizetve, csak befizetés után 4 évvel később ért oda hozzánk a telefon.
Így hamarabb volt 1200 baud-os csomagrádión keresztüli kommunikációra lehetőségem, de ott szintén nem röpködtek forráskódok.
Egyébként a csomagrádió már C64 korszakában is javában ment, csak nem értek el hozzánk a szoftverek. Mennyire más volt az internet előtti világ.

Vírus elemzésénél én is nyomtattam a disassemblált kódot. Az első a Stoned boot virus egy változata volt.

[Szentimentális visszaemlékezés következik]

A középsuli számtek termét lehetett használni délutánonként, mindenki hozta a saját flopiját és bootolt egy dost, majd a játékot. Az egyik havernál láttam a "You are stoned" feliratot, de ő különösebben nem foglalkozott vele. Egymás után dugdosták a diákok be a lemezeket a gépekbe, körbefertőzve mindent.

Nekem meg felkeltette az érdeklődésemet. Akkor kicsit utána néztem és a debug programmal kiszedtem egy fertőzött lemez boot szektorából. Utána évekig gyűjtöttem  a vírusokat. Már nem emlékszem, de meg volt az összes "klasszikus" és korszak alkotó (pl. kukac, Yankee Doodle, Dark Avenger, Fish, Whale).

A módszer mondjuk addig működött, amig meg nem jelentek a titkosított, polimorf, debuger detektáló szörnyetegek - ott már nagyon nehéz volt a helyes dissessemblyt kinyerni.

Ráadásul szemetet is raktak a rutinjaik közé, amin elcsúszott a debug primkó dissessemblie, meg hát 1k felett már kezelhetetlen lett a sok leporelló. :)

A kolis pénzem nagy részét peter norton, meg hasonló könyvekre költöttem, hogy értelmezni tudjam a rendszerhívásokat (int 13, 21, 2f), amit csináltak.

Szerintem embedded lelkület kell hozzá. Assembly ismeret, hardware ismeret, mert akkor van esély valami jót csinálni, ha nagyon alulra, hardware közelébe csinálod az egészet.

Ugyan nem vírus, de teszem azt, egy embedded környezetbe bootloader írásához már kell ismerni a CPU-t, a linkernek meg kell tudni mondani, milyen kódrészt milyen címre tegyen, nem elég csak úgy megírni C-ben a kódot, a többit meg oldja meg a fordító meg a linker.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azokhoz a (kiber)fegyverekhez, amelyek az úttörők vagy korszakalkotók, azokhoz nyilván kell nem kevés "kreativitás" - ha úgy tetszik intelligencia és rosszindulat - a legmélyebb rendszerismeret mellett. A szükséges ismeretek elsajátításához, kutatáshoz egy hétköznapi kódernél komolyabb elhivatottság, kitartás és érdeklődés kell szerintem.

Az elsők után a többi már másolja, adaptálja a bevált megoldásokat.

Meg szándékos backdoor is a hardware-ben. Minden valamirevaló CPU az USA-ból származik. És akkor még ott van a microcode. Te tudod, hogy amikor Linuxon frissül a microcode_ctl csomag, valójában mi javul ki a CPU-ban, vagy milyen hátsókapu nyílik ki?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az 1990-es evekben meg en is nyomtattam kodot. Volt egy egyedetileg valoszinuleg netrol letoltott (hozzam mar winyon/floppyn erkezett) csomag, amiben benne volt egy csomo virus neha kommentezett, visszafejtett forraskodja. Azokbol meg lehetett tanulni az assembly-t, es volt bennuk egy csomo erdekes trukk. Suliban szunetekben ott volt velem, es azokat olvasgattam. (az Ontario pl. emlekszem, hogy nagyon ugyes volt)

De az utobbi 15 evben eszembe nem jutott volna kinyomtatni kodot, inkabb ramasoltam a PDA-mra, vagy a telefonomra, hogy mindig velem legyen. Keresni is egyszerubb benne.

A strange game. The only winning move is not to play. How about a nice game of chess?

Z80-ra komolyabb programokat, például egy Z80 assemblert papíron, négyzetrácsos spirálfüzetbe írtam. A kimaradt sorokat képregényekben megszokott buborékokba írtam. Amikor elkészültem, akkor gépeltem be néhány ezer kódsort a papírról. Mivel nem volt alatta oprendszer, hibánál döglött az egész, így erősen javallott volt mindent alaposan végiggondolni, elsőre hibátlan programot írni lehetőleg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Amennyiben a fordítóban nincs bug. Épp ma szívtam meg azt, hogy regiszterbe foglaltam 8 bites unsigned változót, mire a szentem 32 biten foglalta ezt le, ami mondjuk rendben is van 32 bites architektúránál, de nem fordította bele a 0xff-fel való maszkolást, hanem simán túlnyúlt 8 biten, ahogy inkrementáltam a változómat, miközben épp annak túlcsordulására játszottam. Amikor ezt hozzáadtam egy pointerhez, már az üveghegyen is túlra címzett. Mindegy, watcdog reset lett belőle, én meg néztem bamba képpel, hogy ezt mégis hogy.

Jó, ez C, futásidőben kritikus, DMA-zott mérési adatok előfeldolgozása IT rutinban, valós időben.

Ja, és annyiban igazad van, én sem kommenteltem, csak odabiggyesztettem, hogy & 0xff. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ekkor egy kivonás adja, hogy a bufferből honnan kell olvasni. Vagy egy másik regiszterben tárolod,hogy a buffer hanyadik elemét kell kiolvasni, és azt növeled, a buffer méretével feltöltött regisztert meg csökkented, és visszaugrassz a buffer olvasására, ha ez még nem nulla. Igen, több utasítás/órajelciklus, cserébe nem probléma a regiszter bitjeinek a száma.
 

Ennyit én is ki tudok találni, de sejtheted, hogy mennyire kihegyezett az egész, ha már a register kulcsszót használom a deklarációban. Éppen azért használom a *p++ alak helyett a *(buffer + i) majd a végén i++ alakot, mert az index túlcsordul, a pointerre viszint kellene egy vizsgálat. Az adat meg csak ömlik befelé, de közben USB-n is kommunikálni kell, meg soros buszon is, meg a másikon is, stb.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem lehet, hogy a fordító jól működött? Ha műveletet végzel két 8 bites változóval, akkor a fordító kiterjeszti "int" típusra - azaz arra, ami az adott platformon az int típus. Ez a C specifikáció szerinti működés. Ezért folyton vissza kell kasztolni az értékeket sajnos. A MISRA szabványban le van írva egy olyan szabálykészlet, amit ha betartasz, akkor sosem romlik el, minden platformon pontosan ugyanúgy fog működni a kódod.

Ezért nagyon meg kéne verni valakit! Sokat programoztam assembly-ben, s ha kitaláltam, hogy valamit adott szélességen ábrázolok, annak mindig oka volt. Most kihúztam repóból, amit csináltam. Lehetett ilyen baj, de szerintem pointer túlcímzés nem okozott volna watchdog resetet.

Amúgy majdnem bedőltem neked! Hiába lesz int16_t egy uint8_t és egy int8_t összege, ha az a változó, amelybe az eredményt írjuk, uint8_t.

Sőt, amíg az eredmény register uint_fast8_t típusban keletkezett, addig elrontotta, ha sima uint8_t-t használtam, működött. Most maszkolom 0xff-fel, aztán felőlem megpukkadhat, csak legyen nagyon gyors, mert jön hárommillió mérési eredményem másodpercenként, s ezzel csinálnom kell valamit. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az uint8_t nem segít? A "gcc -Wall" warningol, hogy ha belső aritmetika nagyobb számértékkel akarna dolgozni.
Megjegyzem, ilyen szempontból szintén a Rust szigora nyerőbb nálam. Explicit módon követeli a típusegyezést az aritmetikában.
Tehát ott nem tudsz összeadni egy uint8_t -t egy uint16_t-vel, csak ha explicit azonos típusra hozod az "as" kulcsszóval. Sőt a float + double sem megy explicit azonos típusra hozás nélkül.

Azér a szigor nem mindig jó, mert szándékosan kihasznál az ember dolgokat. Ha már szóba került, elmesélem egy másik szívásomat. Van egy char c típusú változóm, amelyet jobbra shifteltem. Csak ugye a char az signed, a jobbra shift pedig nem logikai, hanem aritmetikai volt, így például a 0x80 egyszer jobbra shiftelve 0xc0 lett, miközben én 0x40-et szerettem volna. Mondjuk párszor hasra kellett esnie a kódomnak, amíg eljutottam oda, hogy kb. öt sornyit debugoltam. :) Nyilván unsigned char c lett a megoldás.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Köszi. Ha vannak még ilyen iskolapéldáid, jöhetnek. Kettő célom van vele: volt már hogy oktattam C-t és szerintem lesz is. Ezek pont jók figyelemfelhívásra.
Másrészt azt keresem, hogy mi az, ami Rust nyelv esetén is átverhet és mi az amit a Rust segít elkerülni. Például ezt így védi ki. Konstansként nem veszi be. Csak oly módon juthat be, ha valahol explicit rácastolod.

Nézd, az, hogy ez az alapvetés, az nem jelenti az, hogy nincs olyan eset, amikor nem lehet odatenni kommentet, hogy valamire felhívja a figyelmet, hogy adott esetben megmagyarázza, hogy miért ez volt a választás, stb. Egy fordító bug simán belefér. Bár simán meg lehet zealotolni egyébként, hogy ez szépen megy egy fix_bug_gcc_reserves_32bits_instead_of_8() vagy valami egyéb magyarázó függvénybe.

Ezzel együtt, amit csináltál, az kód olvashatóság szempontjából bizony szar. Odabiggyeszteni magyarázat nélkül egy maszkolást, ami egy fordító bugot kerül ki, ráadásul egy olyan részen, ami eleve misuenak hangzik ("épp annak túlcsordulására játszottam") nem szép.

És igen, azt is értem, hogy van, amikor muszáj, de ez azért nem általános, hogy egy program minden részére így kell legyen, jellemzően egy-egy pont van, ahol ilyenre kell játszani, és igen, ott ér kommentelni, hogy na, ez a pacsmag most miért ilyen.

Egyszer a gcc-s csapatnak bekuldtem egy hasonlo, tulcsordulasos bugot (vegtelen ciklusra fordult). A valaszuk nagyjabol annyi volt, hogy "undefined behaviour", es kapjam be. Azota nem kuldok be nekik bug reportot, es figyelek erre. Ok ezt komolyan veszik, es a definialatlan mukodeskor tenyleg barmit kepes is megtenni.

A strange game. The only winning move is not to play. How about a nice game of chess?

Meg fogsz lepődni, de lehet. Igényes programozó kell hozzá. Mint írtam már többször, tetszőleges "értelmes" nyelven lehet jól olvasható, érthető és átlátható kódot írni, beszédes elnevezésekkel, ahogy nehezen olvasható, nehezen érthető, átláthatatlan, strukturálatlan elnevezéseket alkalmazó kódot elkövetni. Igényesség kérdése. Én láttam pájtonban is olyan kódot, amire maximum az elrettentő példa minősített esete jelzőt tudtam volna ráakasztani - és ebben olyan ex kolléga is megerősített, aki egyébként pájtonnal kel/fekszik, és mindent is pájtonban csinál. 

Szerintem lehet. Az olvasható kód nagy része a struktúra és a nevezéktan, az hogy helyenként kerülgetni kell valami nyelvi hülyeséget, az kevésbé fáj. Legyen ugyanúgy kerülgetve mindenhol, aztán ha ismered a nyelvet, akkor érteni fogod, hogy mi történik. Ha meg nem ismered, akkor azért egyébként is erősen hendikepes lesz az ügy.

Tipikus saját példa, hogy ha ritkábban kell c-t olvasni, akkor mindig eltart egy darabig, amíg visszakerül a parserembe, hogy az strcpyxyz(*foo,"bar") az igazából olvasható nyelven csak annyit jelent, hogy foo = "bar". Olvashatatlan lesz ettől a c? Aligha.

Igen, blokkzáró megjegyzés.

Ha mondjuk C/C++/Java/C# kódban előfordul egy "}" (záró kapcsos zárójel), az akkor minek is a lezárása? Senki sem töri le az ilyen nyelven programozókat, ha a kódjuk másnak is érthető, és esetleg karbantartható lesz, vagy tévednék?

Ha kommentben ott lenne az, hogy minek a lezárása a jel, akkor talán később a kód működésének megértése is könnyebben menne. Érdemes még azt is figyelembe venni, hogy a komment nem kér enni, az nem fordul le, vagy az interpreter nem értelmezi annak tartalmát.

Igaz persze, hogy a nyelv nem teszi kötelezővé az ilyen jellegű lehetőségek használatát, de azért még lehet azt alkalmazni is.

Azon a -- széles körben elterjedt -- nézeten kellene túllépni, hogy a kódot csak egy ember írja, és csak ő módosítja. Ha a kódon többen dolgoznak, netalántán öröklött a kód, akkor talán ilyen megoldások könnyebbé tehetik a kód hosszútávú karbantartását is.

"Share what you know. Learn what you don't."

Érdemes még azt is figyelembe venni, hogy a komment nem kér enni

Mármint azt leszámítva, hogy kézzel kell szerkesztgetni a blokkzáró megjegyzést minden változtatásnál. Ne adj' Isten egy automatikus refaktorálásnál mondjuk száz helyen.

Azon a -- széles körben elterjedt -- nézeten kellene túllépni, hogy a kódot csak egy ember írja, és csak ő módosítja.

Szerintem éppen ezért kellene minél kevesebb eyecandy-t tartani a kódban. Írja ki szépen az IDE a blokk végére, hogy mi volt az elején, ha erre van igény. Standardizálni kell, minél többen dolgoznak ugyanazon a kódon, annál jobban.

sok +1

,,Mármint azt leszámítva, hogy kézzel kell szerkesztgetni a blokkzáró megjegyzést minden változtatásnál. Ne adj' Isten egy automatikus refaktorálásnál mondjuk száz helyen.''

,,Szerintem éppen ezért kellene minél kevesebb eyecandy-t tartani a kódban. Írja ki szépen az IDE a blokk végére, hogy mi volt az elején, ha erre van igény. Standardizálni kell, minél többen dolgoznak ugyanazon a kódon, annál jobban.''

Természetesen, ha minél több IDE támogatná az ilyen jellegű dolgokat, az lenne csak az igazán jó.

A legjobb az lenne talán, ha ezek a feature-ok nyelvi szinten is támogatva lennének, nem csak az IDE-k szintjén.

"Share what you know. Learn what you don't."

Ha mondjuk C/C++/Java/C# kódban előfordul egy "}" (záró kapcsos zárójel), az akkor minek is a lezárása? Senki sem töri le az ilyen nyelven programozókat, ha a kódjuk másnak is érthető, és esetleg karbantartható lesz, vagy tévednék?

Lásd fentebb. Ma a viszonylag széles körben elfogadott konszezus az, hogy ezt azért kellett odaírni, mert nem érthető a kódjuk másnak, 

Szerkesztve: 2021. 12. 06., h – 18:54

Nem értem, mi ez a szintaxis miatti picsogás. 1st world problem. Mit tetszik kérni még? 3D GUI-t? Vagy Lego kockákkal kéne kódot összerakni, mert a billentyűzet olyan undi? Ha az ember így áll hozzá, akkor fölösleges bármit elkezdeni.

Szerintem az a szintaxis része, hogy a = a+1, vagy a := a + 1, INC(a) netán a++ formában kell / lehet leírni az a változó növelésének lehetőségét, sőt az is, hogy az INC(a) és az INC(A) ugyanazt jelenti-e. Hasonlóan ahhoz, hogy { } vagy BEGIN END írandó. Ellenben a Python szintaxisa engedi a szóközt és a tabulátort is, az más kérdés, hogy melyik cég / fejlesztőgárda, *javaslat* mit ír arról, hogy melyiket és hányat kell ebből használni ott, ahol épp írom a saját kódomat. Szóval nem értem a hivatkozást.

Igen, ezek jo peldak, bar persze ilyenekbe is bele lehetne menni hogy az a++ meg a ++a mit jelent. De a palytonos hasonlat az kb az lenne hogy az a ++ es az a++ az mast csinalna. Miert ne csinalhatna mast, hiszen pl C-ben is vannak olyan elemek, ahova be kell tenned egy whitespace-t, nem uszod meg anelkul :) 

Nem, a Lolcode a kedvencem. Komolyan, olyan ez az egész, mint amikor az új Ubuntu kiadások után megírta néhány troll, hogy nem tetszik a default lila háttér, úgyhogy disztrót vált. A Brainf*ck és a Whitespace nem igazán a Python és C++ kategória, de nyilván te is érzed a különbséget.

Perl után álltam át én is pont az említett problémák miatt a pythonra. Csak javasolni tudom.

Igen, elsőre az indentálás wtf, de megszoktam meglepően hamar, és elképesztően imádom ma már.

Olvastam most a hozzászólások között a CPAN-hoz hasonló pypi-t én pip-et használok.

Csak biztatni tudlak, kerüld el a begyepesedett hozzászólókat, hogy ez meg ez mennyivel gyorsab... ez csak 1 szempont. Ha nem microcontrollert vagy embeded rendszer programozol, hanem azt amit említettel, igen is jó nagyon a python. 

Csak azért, mert "divat" nem kell/nem érdemes Python-t tanulni, pláne úgy, hogy a meglévő Perl tudást kidobja valaki.
Volt olyan eset, ahol Python-ban kellett/lehetett adott rendszer "tudását" bővíteni/finomhangolni - ott Pythonoztam, de volt olyan webes alkalmazás is, amit Python-ban írtak, és Python.ban lehetett volna bővíteni a funkcionalitását, illetve szőkített funkciójú felületet összerakni hozzá - mégis megmaradtam a Perl mellett, és a webes felületét hívogattam Perl-ből (json oda-vissza...), mert az állt kézre.

Hadd kérdezzelek meg, ha már a Perlt képviseled... mégha egy kicsit off is leszek..

Felraktam a Kephra-t egy frissen telepített gépre (Debian11 Xfce). Munkahelyen mceditet haszálom perl-re, ez csak itthoni játszós-felfedezős szórakozás lenne.

Miért nem látok az alkalmazásoknál "Fejlesztés" menüpontot és benne a Kephra-t? Pl. Netbeans szépen beleszövi magát a főmenübe, pedig azt nem is csomagból szoktam telepíteni?!

Az emcéedit sok mindenre jó - például azt hinni, hogy van egy használható texteditorod, pedig nincs :-P Én megnéztem ezt a Kephra-t, és nekem nagyon úgy tűnik, hogy khm. elég régóta nem lett hozzányúlva, és vélhetően nem az volt a legfontosabb dolga az eredet alkotónak, hogy az n+1 ablakkezelőhöz/környezethez a menübe bemászós részt kalapáljon a cucchoz.

Mi a baj az mcedittel? Mi az, ami jobb lenne annál egy egyszerű szöveg/kód bevitelre?! Átmegy mindenféle távoli elérést biztosító protokollon, színekkel segít a szintaktikai hibák elkerülésében. Mi más kell még?! Na jó, debugolást nem támogatja, de hát mégiscsak egy texteditor, ne hasonlítsuk már a netbeans-hez vagy az sts-hez!

Például az, hogy képes szemetet hagyni maga után, hogy nulla automatizálhatósággal bír... Szóval hogy buta, mint a tök... Nagyjából olyan, mint Windows-on azt mondani, hogy a notepad az jó texteditor... És nem a netbeans vagy hasonló böszme böhöncökhöz hasonlítom, hanem mondjuk a vi család tetszőleges tagjához...

Elkezdtem keresgélni, mert tudom, hogy vim rommá pluginelhető, és tele lehet pakolni custom cuccokkal, munkatársam abban fejleszt, és git merge-t is abban oldja fel, gyakorlatilag közel VSCode szintre hozta fel a cuccot.

Közben belefutottam ebbe :) :

https://stackoverflow.com/questions/18296192/vim-compile-and-run-shortc…

vs.

https://newbedev.com/vim-compile-and-run-shortcut

 

FS panel: https://github.com/preservim/nerdtree

Side panel: https://github.com/mihaifm/vimpanel

Git "browser": http://vimcasts.org/episodes/fugitive-vim-exploring-the-history-of-a-gi…

Code completion: http://eclim.org/vim/code_completion.html

Vagy gcc makró helyett 2 megoldás:
  a.) terminál 2 füllel - egyikben vim, másikban <felnyíl> + <enter> (bash history-ban ott a gcc/make/cargo build/...)
  b.) screen (ctrl-a c új ablak) és innentől ctrl-aa ... ahol előzőhöz hasonlóan <felnyíl> + <enter>. Visszatérés: ctrl-aa
 

Itt se Debian, se Kephra - de az ilyesmit az szokta okozni, hogy a csomagban amit felteszel, nincs akármi.desktop fájl, vagy rossz esetben nem a megfelelő könyvtárba kerül (ami _jellemzően_ /usr/share/applications/  vagy  /usr/local/share/applications/ )

Saját szervereimre PHP scripteket írok, és azokkal oldok meg sokmindent. Miért PHP? Mert ahhoz értek, azt használom szinte napi/heti szinten webes projekthez. Bár van perl és python tapasztalatom is, készítettem és módosítottam ezen nyelveken készült kisebb/nagyobb kódokat, de ugyanazt a feladatot sokkal gyorsabban oldom meg PHP nyelven, ami azért nem egy utolsó dolog. Én szerintem csak akkor érdemes belevágni egy új nyelv megtanulásába, ha azt használni is fogod rendszeresen, mert ha nem akkor elkopik, és csak elvesztegetted az idődet. Legalább is nekem ez a véleményem.

Szerkesztve: 2021. 12. 16., cs – 18:05

Use case függő nagyon a felállás.

Nálam ezek vannak linux üzemeltetésnél:

- ha sok file/könyvtár művelet kell, vagy valami más rendszerkomponenssel kell együttműködni (systemd, stb.), akkor általában bash

- ha ritkábban futtatott, de számításokat/adatmanipulációt igénylő feladat (listák, tömbök, json parse, hasonlók), akkor python, mert ehhez értek, és linuxon alapból van python, ha csak nem valami nagyon kiherélt rendszer.

szerencsére az utóbbi időben nem nagyon volt igény olyan program megírására, ami teljesítménykritikus, így nem kellett ezeken kívül mást használnom, de ha oda kerülne a dolog, akkor valószínűleg Rust felé mozdulnék, egészen szimpatikus a Safe Rust elgondolás, főleg, hogy nem vagyok egy túl profi programozó.