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
Egy jó programozó bármilyen programnyelven képes Fortran programot írni! :)
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox
Viszont:
,,Amit nem lehet megcsinálni FORTRAN-ban, azt meg lehet csinálni assemblyben. Amit nem lehet megcsinálni assemblyben az nem lehet megcsinálni.''
(Forrás: http://www.caesar.elte.hu/progmat/kultura/humor/igazi.html )
"Share what you know. Learn what you don't."
.. azt meg lehet csinálni Verilog-ban. :D :D :D
(és még mehetünk lejjebb.)
Amit nem lehet megcsinálni assembly-ben, azt nem lehet megcsinálni ...
Ne legyél maradi, kvantumszámítógépen nincs assembly és tuti tud olyat amit egy x86 nem 🤪
A kvantumszámítógép itt a HUP-on olyan mint Columbo felesége. Mindegyikünk hallott a róla, de még egyikünk sem látta azt a csodás, mindennapokat megédesítő számítási jóságát.
Én már láttam... vagy nem... De a doboza megvan. :)
"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"
Rakjuk össze a programot tranzisztorokból. :-)
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
Jut eszembe, építettél már analóg célszámítógépet?
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)
A JÖVŐ SZÁMÍTÓGÉPEI NEM DIGITÁLISAK, HANEM ANALÓGOK LEHETNEK
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
Oké, de miért kiabálsz?
Mert nem találtam az idézett címet normálisan leírva, átírni meg nem esett jó. Egyébként meg néha nekem is lehet kiabálni. :-)
„Az összeomlás elkerülhetetlen, a katasztrófa valószínű, a kihalás lehetséges.” (Jem Bendell)
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)
Esetleg a félvezetőkben (tranzisztorokban) levő p-n átmeneteket alakítsuk ki magunk... ;-)
"Share what you know. Learn what you don't."
Nosza rajta. Bemutathatod nekünk.
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
Komolyan, most ezt tényleg nem lehet, vagy csak Neked nem sikerült?! Elnézést, én csak most jutottam el odáig, hogy felmerült bennem ez a kísérlet.
Mivel a lényeg az, hogy a két dióda egyik rétege közös legyen, nem. De nekem ez elsőre mellékes gondolatnak tűnt. Így fogtam, és dróttal összekötötten a két azonos réteget, mondván, jó lesz az is.
Nem lett. :)
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.
É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.
Maximálisan egyetértek, olyannyira, hogy ugyanebben a kommentemben ezt is írtam:
:)
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."
pypy es tsai szep gyorsak am.
É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.
Ja, értelek..háát, én nem vagyok fejlesztő, nálam gyakorlatilag minden program "egy nyúlfarknyi rész", így jellemzően egy az egyben éri meg azt a legfeljebb néhánytíz sort átírni. :D
+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.
"Előnye a fejlesztési sebesség és az, hogy tényleg gyakorlatilag mindenhez van benne valami modul/könyvtár." - Perl-ben dettó.
Örülök, hogy ismét megtaláltál. Amit írtam, ezt nem cáfolja, nem is mondtam effélét, cserében a Perl-hez semennyire sem értek, így nyilván nem tudok ahhoz hasonlítani.
" í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.
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.
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
Na most elgondolkoztattál. Vajon az OpenWRT miért a LUA mellett döntött micropython helyett?
Pl. mert sokkal korábban volt Luci, mint uPython. Vagy mert az előbbi még kisebb, ráadásul a lucihoz nem kell a Python sokoldalúsága. De az is lehet, hogy mert csak.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
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?
https://pypi.org/
https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
Köszönöm - ezzel is okosabb lettem.
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
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)
Ez egy pár soros megoldásnál ok, főleg, ha egyedül dolgozol. Minden más esetben:
Readability counts.
Még akkor is, ha az ára, hogy nem fér el 10 sorban.
Pedig pythonban nagyon tomor kodokat lehet irni, ha kihasznalod a python nyujtotta nyelvi adottsagokat.
tudom, ki is hasznalom... ahogy C-ben is. hianyzik is py-ben a ++x meg x++ es tarsaik. C-ben eleg jol ki lehet hasznalni...
Az csodás! Hogy lehet ilyen kódot debuggolni?
Az első dolgom az lenne, hogy szétszedném külön sorokra. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
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.
Olyan elavult és ásatag fogalom, mint az ún. refaktorálás nem segítene a ,,széles'' kódon, esetleg?!...
"Share what you know. Learn what you don't."
Előbb van a nagy monitor és a kicsi betű :)
Gábriel Ákos
Ha a blokk kilóg az ablakméretből, annak a kódnak az a legkisebb baja, hogy scrollozni kell, hogy végigolvasd.
Én remekül szoktam tudni copypastálni máshonnan is.
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.
Legfeljebb, ha van egy rakás paramétere pl. egy függvénynek, akkor külön sorba érdemes tördelni minden egyes paramétert.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
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
Perl-ben ez még elmegy - perltidy szépen helyrerakja az ilyen el...rontásokat, de a bezzegpájtonban csak nézhetsz ki a fejedből, hogy wtf... :-)
A C-beautifier (gy.k: cb parancs), majd később a nagytestvére az indent azért használható ilyenkor is, csak fel kell rendesen paraméterezni.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Rust esetén pedig
$ cargo fmt
ahogy go esetén is go fmt.
autopep8
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
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 ;-)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
https://editorconfig.org/
mcedit nem tamogatja :)
Sor elején színes bizbasszal jelzi az editor.
Magyarul a megjelenítéstől/szerkesztőtől függ, hogy mi hogyan látszik belőle. (Mondjak olyan szerkesztőt ami nem jelzi színes bizbasszal (sem)?)
Azért itt felmerül így 2021ben, hogy ilyenkor a nyelvel van baj, vagy a szerkesztővel....
Igen, és ez az előnye a dolognak. Ha többen dolgoznak a kódon, mindenki beállíthatja az editorát, aztán úgy látja, ahogy neki áttekinthető, nem pedig úgy, ahogy valaki másnak.
"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.
Ez nem nagyobb probléma, mint egy elrontott zárójelezés. Az identálás, a tab/space mixelés, mint probléma a zöldfülű kezdők jellemzője.
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.)
Ide kapcsolódik egy hasznosság: vim <fájl>
:set expandtab
:retab
:wq
Nyomtass ki proporcionális betűkkel egy pájton kódot meg egy Perl kódot. Aztán lehet gondokodni, hogy melyik olvashatóbb... :-P
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.
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.
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/
A rommá zárójelezés vagy rosszul/kevéssé átgondolt kódot takar, vagy Lisp :-D
erre (is) való a folding a vimben, nagyon hasznos és hatékony tud lenni :)
https://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer
Inkább az lehet a gond (magamra visszagondolva), hogy az identálás nem szépészeti beavatkozás, hanem maga a működés alapja.
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
É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. :)
Pedig Ken Thompson és Rob Pike sem tűnik annyira fiatalnak :P
Hát na. :D
+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.
Feltétlen engem se, de a nyitónak kifejezett felvetése volt, hogy olyat akar.
ÉN jobbára vimben dolgozok, ami aztért messze van egy IDE-től ott se egy nagy mágia beállítani a tab-ot space-ek kicserélésére.
manapsag mar java sem objektum orientalt. meg ugy igazabol mindenki feladta mar (mar mindenki, aki szamit).
kotlin data class, java record pontosan egy es ugyanafele mutat: szivas osszemosni az adatot a logikaval.
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.
Hiányérzet azért van bőven. A "megfelelő arány" helyett én azt írtam volna, hogy ennyire és ilyenre van/volt lehetőség a fordító, jvm (és a nyelv) szétbombázása nélkül. ;)
Mindenesetre lehet szep tiszta kodot irni java-ban is most mar, kotlinban meg ugye meg inkabb.
A jvm nyilvan maradt, ami volt, mert senki se mer a C2-hoz nyulni, meg a 20 evnyi backwards compatibility-t eldobni.
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....
"mindenki, aki számít"
:D
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.
-1
Nyilvanvaloan overkill egy _server uzemelteteshez_.
Mivel ezt írta:
Most ismét egy várhatóan összetettebbre növő alkalmazást kellene készítenem
Valamint mivel felvetődött a C++ mint reális alternatíva részéről is, ezért nem értem miért lenne overkill.
#define szerverüzemeltetés
É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.
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.
Már hogyne lenne jobb, mint a Perl. A Perlben olyan hülyeségek vannak a mai napig, ami miatt 20 éve sem lett volna szabad vele dolgozni sehol éles környezetben.
"A Perlben olyan hülyeségek vannak a mai napig, ami miatt 20 éve sem lett volna szabad vele dolgozni sehol éles környezetben."
Jöhet a felsorolás...
Ö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.
Én akkor kaptam agyf.szt, mikor a business critical project során kiderült, hogy nincs a nyelvben switch-case... iletve van a CPAN-on 17 féle implementáció.
Na elmegy ám Larry a búsba...
Mondjak még nyelveket, amikben nincs...? Egyébként meg:
pythonban sincs :)
majd talan hamarosan: https://towardsdatascience.com/switch-case-statements-are-coming-to-pyt…
Már megjött a 3.10-ben.
https://www.python.org/dev/peps/pep-0636/
eutlantis
akkor majd 5-10 ev mulva mar lehet is hasznalni, amire kikopik mindenhonnan a <3.10 verzio... egyelore meg 2.7-et is tamogatni kell sok mindennel.
Ha 2.7-et igénylő kódbázist kell karbantartani, ott valószínűleg nem az a legnagyobb probléma, hogy switch helyett egy if-elif-else blokk van. :)
2.7 már hivatalosan EOL régen, nem?
Ez a python projektet egyáltalán nem kell érdekelje, sorry.
Gábriel Ákos
Vajon C-szerű lesz sok évtized késéssel, vagy olyan, ami közvetlenül változókat is fel tud tölteni?
Ez már a camel könyvben is le volt írva, pedig az még 4.x-ről szólt valamikor a pattintott kőkorszakban.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Ohhh azok a régi szép idők... a Kossuth kiadó által "gondozott" - félreértett és félremagyarított - kiadással. :)
Mi a gond vele...? :-) Azon kívül, hogy az idézőjelekkel eléggé nagyvonalúan bántak a kódrészletekben is, meg néhány magyarítás kifejezetten fájdalmasra sikeredett... :-) Jó, a külső parancsként meghívott "levélküld" az tényleg durva volt :-D
Meg is válaszoltad magadnak.
Meg voltak benne olyanok is, hogy a kódban és a kódmagyarázatban nem igazán volt összhang köszönhetően a "néha lefordított néha nem" dolgok miatt.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Tudom - anno én is megvettem... Egyébként a "minden jó valamire - ha másra nem, elrettentő példának" elvet tökéletesen alátámasztja az a könyv :-)
A || és az or különböző precedenciája egyszer eléggé meglepett.
ú, azon egyszer én is kaptam agyvérzést.
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:
Backslash-bűvészkedések nélkül megoldható?
Mi a baj a '\n' -el ? Miert nem kell blackslash ?
~
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")
Én egy Perlben írt hálózati automatizációs szkripthalmazt írtam át Pythonra, összesen olyan 10 000 sort. Akkor alakult ki a véleményem: Perlben soha semmit.
Ahogy egy kollégám szokta mondani: perlben is lehet szép kódot írni, csak nem szokás.
bugzilla kodja pl olvashato.
perl ben sok mindent lehet, bele ertve nehezen olvashato kodot is,
de kozel sem lehetetlen olvashato kodot irni.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
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.
ami az ő fejében nyilván olvasható lesz... ezen a héten ... :)
Gábriel Ákos
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
É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.
Igen, ilyeneket könnyebb találni, csak azt mondtam, hogy ahhoz képest, hogy mekkora a hype, elég nehéz valójában programozót találni.
Jó programozóból úgy általában kevés van. A jó programozó általában válogathat a jó feladatok között és ezt meg is teszi. Az átlagos cég meg lehet jobban jár ha kidolgoz egy módszert amivel átlagos programozókkal elérheti a céljait.
Gábriel Ákos
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.
Ja, azoknak meg a CI meg a hálózat és környékéről nem lesz semmi fogalmuk, nyugi :D
De ja, a devopsra tipik jelentkezik az összes olyan, aki rendkívül sok témához nem ért... :)
Egyvalami tuti biztos:
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.
Akkor nagyon nagy betűkkel írd bele h miért kéred ezt, különben nem lesz egy jelentkeződ se :)
Gábriel Ákos
Röviden: érdemes ld. https://hup.hu/node/175857
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.
Igazából a Perlben már egy normális függvény deklarációt nem tudsz elvégezni. A @_ "megoldás" már egy 30 soros programban is kínos.
Mert mi is a gond vele?
1. Nekem kell elvégezni a paraméterkezelés azt a részét, amit más nyelveknél nem.
2. Nem tudok default paraméter értéket adni az egyes paramétereknek, csak mindenféle trükkökkel.
3. Feleslegesen növeli a kódhosszt és rontja az olvashatóságot.
Azért a 2. pont mintha jó néhány nyelvnek sajátja lenne.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
"tényleg egy hányás a kód, ha objektumorientált szintig jutsz vele" - Feladathoz az eszközt - a Perl OOP nem szép, valóban, de alapvetően nem is erre lett tervezve.
A CPAN tartalmának 99%-a lájkolja ezt ;)
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? :)
elixir?
NIM
nodejs, php
Igen.
Csak, hogy zeller örüljön, nem.
Na igen... Ez sem mai csirke... Anno AutoLISP-ként jött szembe :-)
Ha a szerverüzemeltetésbe belevesszük a Kubernetes-t is, akkor egyértelműen nyitni kell a GO felé is.
Golang
Ha komolyan is akarsz programozni, akkor statikusan típusos nyelvet tanulj meg! A dinamikus típusozás csak bohóckodni jó.
Vagy egy olyat ahol választhatsz...
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.
De lehet ugy is gondolkodni, hogy ha mar csinalunk valamit, akkor csinaljuk rendesen! Es akkor abbol hosszutavon kinohet komolyabb tudas is.
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...
Laikusként kérdezem:
Mindezeket nem ellensúlyozza a kódírás közbeni rugalmasság? Hogy az adatot így is és úgy is értelmezni lehet könnyű, de a programozó által kért adat-konverzióval? Nem lesz gyorsabb így implementálni valamit mint tisztán statikusan?
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.
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.
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.
Ilyen is van: https://docs.python.org/3/library/typing.html
“Any book worth banning is a book worth reading.”
csak önmagában semmit nem csinál :)
https://docs.python.org/3/library/typing.html
igen, pontosan ezt mondtam.
Nem pontosan ezt mondtad. (Nem vagyok biztos abban, hogy az "önmagában .. csinál" ebben a kontextusban jelent bármit, de biztosan nem azt, amit én beidéztem.)
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. :)
A tárgy, a type annotation egy programnyelv szabványának a része. Erről állítod, hogy önmagában nem csinál semmit.
Ez nem jelenti pontosan azt, hogy az interpreter leszarja.
Értem, kérlek, neked van igazad :)
igen, emiatt nincs is kb semmi ertelme hasznalni...
amugy se a szintaxis miatt lenne erdekes, hanem hogy a JIT compiler tudja figyelembe venni optimalizalasnal
Szerintem nem tiltja semmi hogy a fordítók figyelembe vegyék.
Illetve... ha megengedi hogy ellentmondj a típusaidnak, akkor fordító nem veheti figyelembe, mert az hibás/nem szabványos működés lenne..
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)
A strange game. The only winning move is not to play. How about a nice game of chess?
A [[1,2],[3,4]]-nek miert [[1,4],[9,16]] a negyzete? Miert nem [[7,10],[15,22]]?
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.
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
Azért a duck typing gyakorlatilag implicit interfaceket jelent. Értem én, hogy nehéz biztosra menni, de sokszor baromi kényelmes tud lenni.
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
Nézd meg ezt:
https://mojolicious.org/
segít modernizálni a perl-t
Lehetni lehet, de minek? Mindenki megindult a python irányba, a perl-t ahol lehet, csak vezetik ki. Mint IT-ben dolgozó semmi értelme olyan dolgokat tákolgatni,
amikhez lassan már bottal sem akar senki sem nyúlni, inkább újraírja az egészet.
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...
Amióta vannak IDE-k azóta általában 1 gombnyomással lehet kódot formázni.
A "szépen megírt" Python kódon is szokott tudni faragni.
Gábriel Ákos
Amig a formazason mulik az hogy mit csinal a program, addig... ooo.... ize... :)
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 )
"a baljobb cicis nyelveknél szokott megesni, amikor egy utasításnál ki lehet hagyni a őket," - egyszerű: nem kell kihagyni őket. A "lehet sz@rul/trehányul csinálni" nem jelenti azt, hogy sz@rul/trehányul kell csinálni.
Akkor már csak azt nem értem, hogy ha valaki a pythonban csinál valamit szarul, akkor az miért a nyelv hibája.
Egy elütött tab/space képes keresztbe tenni a működésnek, ez a gáz. Aki szóköz/tab fétisben szenved, az használjon Whitespace-t :)
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.
ja, valóban, ezt csak policyből kell írtani.
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.
A formázáson az múlik hogy fordul-e vagy sem. Ha jól gondolom.
Én azt nem szeretem, hogy :
- mondjuk ki akarok hagyni egy ciklust (mert csak egyszer kell) akkor az egész ciklusmagot húzhatom eggyel balra
- IDE-ben nem tudok a blokk elejére-végére ugrani
Gábriel Ákos
Pájtonul jól programozni amúgy nem kicsit mást jelent mint C-ül, szerintem.
Pájtonban van egy csomószor végtelen elegáns megoldás amit amúgy tudod hogy belül iszonyú pazarló.
De mégis használod mert igazából nem számít.
Gábriel Ákos
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.
"a könnyű belépési küszöbjéből fakad" - Na ja. Nem kell megtanulni "szépen" kódolni, mert úgyis muß úgy írni a kódot... :)
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.
Nézd meg a Lama Book-ot, a McMillan Perl 1. - 2. -t... (Előbbiből _ne_ a magyar verziót, mert az katasztrófa...). Szóval Perl esetén is van _jó_ és tanulható szakirodalom.
Ú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.
A "{}"-re is rááll az ember keze, illetve a normális editor a komplett blokk template-et is be fogja szúrni, attól függően, hogy milyen blokkot kezdtem írni (ciklus, elágazás, satöbbi - a blokkzáró megjegyzéssel együtt).
Blokkzaro megjegyzés. 2021ben. Nyugodtan maradj a perl-nel.
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...).
Miért, mi a most követendő pattern?
Gábriel Ákos
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.
Jogos. Én főleg "end of for" jellegű záró kommentet szoktam, csak hogy látható legyen ki kivel van (ha nincs ehhez amúgy IDE support). Mondjuk mióta a VSC elég jó lett és van erre support, el lehet hagyni.
Gábriel Ákos
"É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.
Ja. ezért írunk olyan kódot, amit egyféleképpen jól meg lehet érteni, nem magyarázzuk a bizonyítványt szabadversben :)
Nyelvtől függetlenül olyan kódot kell írni, ami jól olvasható, megérthető, és akár nyomtatva is értelmes marad :-P
ez a nyomtatás furcsa mániád neked....
Sokkal kényelmesebb tud lenni papíron "firkálgatni" a kódot, gondolkodva azon, hogy hogyan kéne javítani/módosítani netán újraírni egyik vagy másik részét, mint monitort bámulva.
Hát, te tudod...
Van rá valami szkripted, ami ilyenkor a forráskód releváns részeit összegyűjti úgy, hogy pl. A4-es lapokba tördelve átlátható legyen, vagy csak ctrl+c, ctrl+v kombóval bemásolsz egy oldalnyi kódot a kedvenc szövegszerkesztődbe, majd nyomtatás?
Ismertek olyan IDE-t, amiben van nyomtatás gomb? Vagy IDÉtlenül lehet csak megoldani a problémát? És színezett kimenet jön, vagy fekete-fehér?
Jellemzően ami nagyon "agyalós", az néhány oldal, normális texteditorból szépen ki lehet küldeni nyomtatóra. Sima fekete-fehér nyomatot szoktam használni - nekem az olvasható a legjobban fehér alapon, de ez megint csak ízlés kérdése.
Megnéztem kíváncsiságból a KDE-s Kate-tel: PDF-t létrehozva megmaradt a színezés. Ha még jobb eredményt akarsz, biztos van valami LaTeX csomag, amit direkt e problémakörre találtak ki.
Életemben nem nyomtattam még ki forráskódot, de majd kipróbálom.
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.
Egy commodore64-en írtam először programokat, nyomtatóról álmodni sem mertem akkoriban.
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.
A ZX Spectrum kommentelt forráskódját én is nyomtatott könyv formájában vásároltam meg. :) Volt, ahol a komment tévedett, s a kód volt jó.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nekem ez a kiadvány volt a Z80 "bibliám": https://www.antikvarium.hu/konyv/sztrokay-kalman-a-z80-assembler-ht-108…
Első assembly kódjaimat én is HT-1080Z-re írtam, de a könyv nem volt meg. Volt egy kis füzetem, benne az utasításokkal, és az állított flagekkel.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ez a könyv nagyon hasznos volt - plusz a teljes rom-lista ott volt nyomtatva a végén :-)
A jó öreg JNOS/TNOS 70cm-en... Régi szép idők.
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.
Mindig is érdekelt az, hogy egy jobbfajta vírus kitalálásához és lekódolásához mekkora szakértelem szükségeltetik?
Tehát igaz-e hogy vírust csak "nagy agyak" csinálnak, nem pedig mezei kóderek?
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
Köszönöm, érdekes volt innen nézni.
A magam részéről némely ügyesebb vírust a maga nemében zseniálisnak tartok. A mély szakismeret és kreatív gondolkodás egy csúcspontjának, függetlenül attól, hogy a célját (haszonszerzés, károkozás) elítélem.
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
"simán túlnyúlt 8 biten, ahogy inkrementáltam a változómat, miközben épp annak túlcsordulására játszottam" - tanulság: dekrementálás és zéró flagre vizsgálat :-) Anno Z80-on erre volt a DJNZ :-)
Azért a bufferemen időben előre szeretnék végigmenni, mert az idő sem telik hátra. Vagy akkor megfiatalodom? :)
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
Ja kérem, cében ez valóbabn copás... Én assembly-ben gondolkodtam, "jobb helyen" van zero flag, amire lehet feltételes ugrást akasztani...
Kis RISC MCU-kat én is örömmel programozok assembly-ben, de egy 32 bites ARM architektúrától sikítva menekülök, ott marad a C.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
De még jobb a Python! ;-)
Pedig jo is az az ARM assembly :)
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
Ezek az aknák érdekelnek. Be tudnál mutatni néhányat például ezen az oldalon?
Parancsolj. Nézd az asr és lsr utasításokat!
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?
Érzésre te inkább a programozási nyelv specifikációjával vitatkoztál, nem a fordító készítőivel. :)
Na azt próbálj meg Perlben írni - öndukumentáló kódot.
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."
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.
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."
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,
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.
Ezzel a hozzáállással remélem kedvenc programozási nyelved a brainfuck, de pláne a whitespace.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
https://hu.wikipedia.org/wiki/Szintaxis_(programozási_nyelvek)
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.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
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 :)
.
Hát igen, a szintaxis. Vegyünk egy egzotikus nyelvet, amiben rakéták vezérlőszoftverei is íródtak.
\ szerintem :-)
I RPN Like !
:-)
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...
Na, ez nekem új :)
Egy gyakorlati példát kérnék, hadd tanuljak belőle!
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/ )
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Köszönöm, ez alapján le tudtam gyártani. Még ikont is készítettem :)
FYI: a pypi az a pip*
*kissé pongyolán, mert pippel lehet saját repókból is dolgozni, de pip install alapból a pypiról dolgozik,
https://www.facebook.com/TheInsaneApp/photos/a.111462577009971/44409815… :-D
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.
vps4you.hu kupon VPS szolgáltatásra: HUP2023
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ó.