Akkor ezt most megnyitom...

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

Good Job!

A tudást mástól kapjuk, a siker a mi tehetségünk - Remember: Your life – Your choices!

Olyan gyors, hogy kétszer 180-at is fordul. Kösz, javítottam.

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

Ilyen betekintést nyerni egy zseni észjárásába.

[ Szerkesztve ]

Szép teljesítmény volt! Egyben jó szoktatás éles határidőkhöz, vagy valódi biztonsági incidenshez.

Jövőre esetleg a csapattársakat a vicc alapján lehetne instruálni: "Gombokhoz nem nyúlni, malacokat etetni!"

A tej élet, erő, egészség.

Gratulálok, és le a kalappal a teljesítményed előtt!

Szeretném, ha csak feleakkora tudásom lenne programozás terén, mint amiről te azt mondod, hogy kevés

Mindig öröm olvasni az írásaid, de ez különösen tetszett, mert pár éve mi is elmentünk hárman haverokkal egy programozó versenyre. (Úgy, hogy egyébként én közgazdász vagyok, és csak az Excel-ezgetés meg BI-ozás révén ragadt rám pár dolog, egyébként csak csúfolom a programozás szakmát. Na meg egy ideje OMV szerver meg Home Assistant itthon)
Sikerrel bejutottunk az elődöntők során, és a döntőben 12 csapattal kellett egy LEGO robotot irányítani egy pályán.
A döntő is két részes volt, az első részben nyilvános volt a pálya, és lehetett rajta háromszor tesztelni is, hogy tud-e rajta menni a robot - színérzékelő meg távolságérzékelő szenzorokat kellett főként használni.
A második részben viszont le volt takarva a pálya, tehát látatlanban kellett tovább fejleszteni a robotot, és lehetőleg minden eshetőségre gondolni. Itt tesztelési lehetőség sem volt.
Aztán mikor leleplezték a pályát, mindenki nagy megkönnyebbülésére ugyanaz volt a második pálya is, mint az első
Végig tök jó hangulatban programoztunk, felosztottuk egymás között a feladatokat, és jól is haladtunk. Jött az utolsó próba, az éles döntő. Letettük a LEGO robotot a startra, és vártuk, hogy körbemenjen a pályán, kerülje ki az akadályokat, stb... És a robotunk az indulás után csak egyhelyben pörgött.
Utólag hamar megtaláltuk a hibát - az egyik fordulási ágban elfelejtettük a forgásszenzor mértékegységét fokra állítani. Már nem is emlékszem, mi volt a default, talán cm, de mindegy is Ezen az amatőr bug-on buktuk el az egész döntőt.
Rossz érzés volt, de az eredményt leszámítva a verseny élménye pozitív volt számunkra - egy egész napos baráti csapatépítő program
Mivel alapból nem volt egy nehéz feladvány - 6 óra alatt sztem bárki megoldotta volna, aki minimális affinitással rendelkezik az IT felé - inkább az volt a nehezítő körülmény, hogy limitált volt a tesztelés lehetősége.

Hát, én is jót szórakoztam. Nem gondoltam volna, hogy ilyesmi le tud kötni, mert sosem érdekeltek a játékok. De amikor algoritmust kell a mozgásra írni, az tényleg nagy sikerélménnyel tud eltölteni.

LEGO robotnál gondolom azért limitáltabb a számolási kapacítás. Ott milyen módon írtatok AI-t? Felmappeltétek, hogy hol járt már, aztán arra nem ment többet és próbálkozott?

Meg írod, hogy egész napos volt. Hány óra volt rá?

Mondjuk nem tudom mit csinálnék, ha még szenzorokra is kellene figyelnem...

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

Ha jól emlékszem - mert ennek már jó 5 éve - az algoritmus annyi volt, hogy figyelje az útpálya színét.
Ugyanis a pálya egy nagy fehér papír volt, amire rajzoltak egy színes pályát.
Kék volt a normál út, piros volt az akadály, és sárga körök voltak a pályán két helyen, ezeken a körvonalakon ha végigment a robot, akkor az pluszpontot ért.
Amíg kék pályát látott maga alatt a színszenzor, addig menjen egyenesen.
Ha letér jobbra vagy balra, akkor a kék ugye átmegy lassan fehérbe (a pálya alapszíne), ekkor korrigáljon vissza 3 fokot.
Ha pedig elért a más színekhez, akkor az akadályt kerülje ki egyik oldalról. A sárgán menjen végig, amíg újra kéket nem talál.
Tehát az egész szabály a színekre épült.
Volt még távolságszenzor is, mert a pálya szélén volt egy fal emelve. Ha ezt megközelíti, akkor a távszenzor jelez, és visszaküldjük ellenkező irányba - 180 fok fordulás.

Nagy vonalakban ennyire emlékszem, de tényleg nagyon ötletes és jó kis verseny volt
Azt hiszem az OTP rendezte az EcoSim-mel közösen, és a győztes csapat állásinterjúra is mehetett a bankhoz.

Azt hiszem 3 óra volt az első részre, és 3 a másodikra is. Közben volt ebédszünet is - nagyon jól voltunk tartva

Olyan nézőpontból állsz a problémákhoz, amire nagyon kevesen képesek. Nagyon-nagyon kevesen. Az pedig a ráadás, hogy olyan hozzáállásod van a feladathoz, ami szintén keveseknek van. Ha magadévá tudnád tenni a harmadik területet is, hogy hogyan menedzseld magad, akkor évi 100k+ EUR-s helyekre pályázhatnál. És tipikusan, akik az első kettőben jók, ők a harmadikban nem szoktak azok lenni.

10+ éve vagyok a programozói szakmában, mint villamosmérnök (nem is tartom magam programozónak). Sok interjún vagyok túl és sok embert interjúztattam már, illetve sok kollegám is volt már. Úgy gondolom, hogy jó emberismerő vagyok és ki tudom szúrni a tehetségeket, akikkel öröm együtt dolgozni. És itt nem arra gondolok, hogy majd ő megcsinál mindent más helyett, hanem arra, hogy valakivel együtt lehet előre menni.

Egyébként pedig abszolút áttudom érezni, amin keresztül mentél. Voltam a középiskolában szervezett Németországról szóló versenyen, ahol 4 fős csapatok indultak, én pedig egyedül. Második lettem. Egyetem alatt a menedzsment c. tárgyra készült beadandóra 4 fős csapatok álltak össze, egyedül csináltam meg. A munkahelyeken is jellemzően egyedül maradtam a problémákra. Az egyik munkahelyemen beneveztek a Software Architect képzésre, ahol csapatban kellett a munkánk mellett egy saját projekten dolgozni. Gyakorlatilag ott is egyedül maradtam . Oké, azt nem én találtam ki, hanem egy srác a csapatból, hogy a pythonos game engine-t használjuk és bár az elméleti alkalmazást sem tudtam, amikor elmagyarázta, akkor csak én dolgoztam rajta és az jól működött. Amikor a pathfindigos részt olvastam, nekem rögtön a Dijkstra jutott az eszembe. Volt egy jó időszak, amikor összekerültem egy igazi programozóval, aki nagyon penge volt és ketten kiegészítettük egymást. Amit akkor csináltunk közösen az baromi jó volt.

Továbbra is tartom magam a korábbi kijelentésemhez: [link]

------------

Személy szerint, nagyon-nagyon nem szeretem a python-t, de úgy általában az interpretált nyelveket sem. A szükséges minimumra törekszem a munkám során. Értem, hogy miért lehet jó a python, de engem sokkal inkább aggaszt az, hogy túl sokat kellene tanulni ahhoz, hogy valamennyire biztonságos kódot írhassak. Ez a gondolatom jellemzően igaz a többi nyelvre is. A C++-ra is kifejezetten haragszom. A C++20 standard kiadás előtt itt volt Magyarországon Bjarne és elmondta, hogy mi lesz a standardben. Nekem igazából csak egy kérdés volt a végén, amit nem mertem megkérdezni, hogy "maradt még olyan speciális karakter a billentyűzeten, amit nem használ már a nyelv?". Egyébként kb 10 évig C-ztem és utána váltottam go-ra. Nekem nagyon tetszik a go, valószínűleg azért, mert a Google-nél mérnökök dolgoznak és csináltak maguknak egy olyan nyelvet, amit mérnöki szemlélettel dolgoztak ki.

hogy pl több szálon akarnék egy map-be egyszerre írni

[sync.Map] ha nem akarod wrappelni a sima map-t, mert mondjuk nincs idő ilyenekkel foglalkozni.

a kész bináris simán lehet 10+ MB, mivel semmi optimalizációt nem csinál a fordító

Igen, a go binárisok nagyok, de nem a fordító miatt, hanem azért ahogy a go oldotta meg a library kezelést. A go bináris csak annyi shared libraryre dependál, ami a minimum ahhoz, hogy futni tudjon. Linux az ldd mutatja be ezt jól. E helyett minden statikus lib, amit a linker fog egy binárisba szerkeszteni. Emiatt nagyok a binárisok, illetve amiatt is, mert a linkerek nem nyúlnak bele a fordított kódba (a linker igazából nem más mint egy symbol matcher) és így ha csak egy symbol is használva van a statikus libből, akkor húzza az egészet. Ezzel a szemlélettel a go teljesen szembe megy a C/C++-os világgal, ahol a shared library-s megoldás a preferált. Viszont így lehet az is, hogy a Linuxra fordított bináris standalone az összes disztrón fut.

Az alábbi kód maximum a szerencsének köszönhetően menti el a fájlt. Ez egy wait groupért kiált, de szerintem nem érdemes goroutinesítani a mentést.
func main() {
...
go SaveImage(response.MapImagePng)
}

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Jah, igen és a vscode. Nagyon-nagyon jó IDE, de a fenéért kell felzabálnia a gép erőforrásait?! Erősen javaslom a váltást emacs-ra vagy vim-re. Ezek a kávédarálón is elfutnak és nagyon jó feature paritást lehet elérni.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

Húú, na pontosan ezekért az elképesztő hasznos szakmai kommentekért, illetve pl. a lajosdani2 féle élménybeszámolók miatt éri meg vezetni ezt a blogot. Köszönöm a meglátásokat!

Én nem szeretem a Go-t, hogy őszinte legyek, bár piszok kényelmes. De lehet azért, mert rustról váltottam vissza, ami elég erősen kikényszeríti a programozótól, hogy szép kódot írjon. Nem rossz amúgy, de kb az a kód le is fog fordulni, amire nem panaszkodik az IDE. Találkoztam egyszer egy érdekes problémával, hogy adott volt egy Go backend. Ez egy websocketet nyitott a kliensek felé és eventeket küldött, majd kapott válaszokat a kliensektől. Ha sok kliens volt, egyszer csak pánikolt. Pedig látszólag mindenhol rendesen figyeltem a lock-ra. Később rájöttem, hogy maga a library volt a hibás, mivel a pingek küldésnél elfelejtettek lockolni és ha pont akkor olvastam a streamről, mint amikor ezek pingeltek, akkor meghalt a processz. Újraírtam rustban, ami le se engedte fordítani úgy a kódot, hogy nem lockoltam valamit. És még ki is oktatott informatívan, hogy ez meg ez nem jó és nesze, old meg így. Az lehet, hogy több effort volt a végén a kód és sokkal hosszabb lett, mint a Go megoldás, de a nem létező mérnöki szememmel sokkal precízebb lett a végeredmény.

Lehet ez egy senior Go devnek nem hátrány, hiszen ő már eleve gondol mindenre is, de én ettől sajnos messze vagyok.

sync.Map-et meg ismerem és használtam is máskor. Csak ez is egy extra faktor, amire figyelni kell.

A C++t én sem szeretem, de úgy általában az OOP nyelveket sem igazán. Egy két valid use-case-t tudok elképzelni, amúgy szerintem a funkcionális nyelveknél nincs gyorsabb. Az lehet, hogy áttekinthetőbb, meg a polimorfizmusnak köszönhetően könnyebb kiegészíteni, így pikk-pakk lehet vele haladni, de nem feltétlen lesz az optimális. Meg sokszor jár vele a tömény absztrakció is, ami szerintem egy szint után már felesleges overhead. Egyetemen nálunk nagyon nyomják a C#-ot, de C és társai sosem voltak terítéken. Az OOP-ra esküsznek. De ezzel most egy háborút fogok elindítani. Nem akarok persze senkinek a lelkébe gázolni.

Az alábbi kód maximum a szerencsének köszönhetően menti el a fájlt.

Köszönöm az észrevételt, teljesen jogos! Bevallom, a kész kódból másoltam ki részleteket és a saveImage alatt bőven van blocking call, ami miatt nem fog kilépni a program, csak a copy-pastenél azt pont nem írtam át. A példa kedvéért most kiszedtem a go kulcsszót.

A linkelésről pedig. Úgy néz ki én tudtam rosszul, vagy azóta változtak a dolgok. Lefordítottam az alábbi kódot:

package main

import "fmt"

func main() {
fmt.Println("Hello, World!")
}

Az volt az elvárásom, hogy az fmt egyetlen függvénye miatt bekerül a binárisba az fmt összes szimbóluma. A szemléltetés kedvéért nem strippeltem a kész binárist. Ghidrában megtekintve az eredményt, jól látható, hogy rosszul tudtam:

Általában mindennek utánanézek, amikor állítok valamit, de úgy néz ki, itt hibáztam. A cikket majd frissítem egy update formájában, hogy I stand corrected és nem is olyan vészes a helyzet. Köszönöm!

A linker meg... Az világos, hogy statikus ELF fájl lesz például linuxon. De itt most a Hello World kedvéért simán elegendőnek kéne legyen egy libc linking. Rusttal megcsinálod ugyanezt egy musl toolchainnel buildelve és kapsz egy pár száz KiB-os optimalizált, teljesen static binary-t. Macerásabb, mint Go-t buildelni, de ég és föld a végeredménybeli különbség.

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

Hogy őszinte legyek, egész jól bánik már az erőforrásokkal, persze sosem fog labdába rúgni az említett szerkesztők mellett memory footprint szempontjából. Egyébként én a VsCode-ot a neovim kiegészítővel használom. Két dologért szeretem nagyon ezt a setupot. Az egyik az a Markdown preview extension, amivel le tudom osztani a képernyőt egyrészt a szerkesztett nyers fájlra, illetve a másik oldalt kapok egy előnézetet, ami szinkronizálva van a szerkesztői oldallal.

A másik meg a container integráció. Baromi hasznos C# fejlesztésnél a Containers extensionjük, mivel ilyenkor felhúz automatikusan egy dev containert nekem, majd valami HTTP API-n keresztül kommunikál a Code-dal és rendesen lehet breakpointokat berakni, látni, hogy éppen mi volt a változók értéke stb. Nyilván vimmel is meg lehetne csinálni azt, hogy konténerben fejlesztek, de ez így nekem nagyon kényelmes. C# ugyanis hajlamos a szemetelésre és jó érzés egy-egy projekt után kitörölni mindent (a kódot kivéve) egy paranccsal.

emacs egy ideje bakancslistás, ha oda jutok nagyon szeretném jobban megtanulni.

Szerintem bold claim a részedről, hogy nem tartod magad programozónak. A megnyilvánulásaid alapján nekem az jön le, hogy mélyebben tisztában vagy a dolgok mikéntjével és a 10 év sem a tegnap kezdtem kategória.

Ja meg én elvagyok a Pythonnal is. Ha HTTP kérést kell manipulálni, vagy kell valami párszor használatos dirty szkript, arra teljesen jó. Prod. szoftvert nem szeretnék benne már írni.

[ Szerkesztve ]

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

A Rust eddig teljesen kimaradt az életemből. Azon kívül, hogy gyorsaságban a C-vel veteszik, tudtommal a Linux is nyitott rá és hogy jól kezeli a memory leak veszélyes helyzeteket, nem tudok semmit. Se szintaktika, se principle, semmit se.

Azt nyugodtan ki lehet jelenti, hogy az OOP elavult lett (a Java-val együtt, csak hogy borzoljam a kedélyeket). Pontosan én is így gondolom: [The Flaws of Inheritance]. A go nem is támogatja az OOP-t.

Az volt az elvárásom, hogy az fmt egyetlen függvénye miatt bekerül a binárisba az fmt összes szimbóluma. A szemléltetés kedvéért nem strippeltem a kész binárist. Ghidrában megtekintve az eredményt, jól látható, hogy rosszul tudtam:

Most már erősen a tudásom határán mozgok, de szerintem a Decompile ablak csak annyit mond, hogy az egyes sor milyen symbolt használ. A bal oldali ablak meg "csak" annyit, hogy az fmt-ben milyen symbolok vannak. Az hogy a linker mit fog a binárisba tenni az egy harmadik kérdés. Szerintem egyébként a teljes static libet. Közben megnéztem és a symbolokat a go tool nm-al lehet kilistázni. A binárisban benne van az összes fmt symbol vagyis a teljes static lib bekerül. A lényegen egyébként nem változtat, hogy a go binárisok nagyok.

Még egy picit a Rust vs Go-nál maradva. Amennyire tudom a Rust a zászlajára tűzte a performanciát és e köré épített fel mindent: a principle, memória menedzsment, build, stb. És ez így van jól, mert sok helyen nem engedhető meg, hogy pl. garbage collector fusson a háttérben. Addig a go más megközelítést alkalmazott: [Miért és mikor érdemes Go-ban programozni? - Szabó Dávid (LeanNet)] abszolút egyetértek a meglátásaival. Ez persze nem jelenti, hogy a go-ban ne figyeltek volna a performanciára, mert a goroutine önmagában megtestesíti ezt. És a garbage collector is elég penge lett: [Go versus Rust fastest performance]. De pl. a bináris mérete már nem erről árulkodik. Egyébként a _teljes_ footprintet nézve ide a rozsdás bökőt, hogy a go még ígyis odaver a Java, C#, Python és társaiknak. Az pedig a non plusz ultra, hogy a dockerimage készítés álom egyszerű a go-val. A cross compiling is egyszerű. A legutóbbi nagy go-s feature az volt, hogy most már a binárisok az utolsó bitig reprodukálhatóak. Szóval egy adott kódra a go 10 év múlva, sok verzió után is bitre ugyanazt a binárist fogja generálni. Most fejezem be a go "dicsőítést", mert itt ragadok még egy darabig. Még annyit (reflektálva a buildre), hogy a rengeteg makefile és CMake (több millió soros C/C++ projektet írtam át Makefileról CMakere, de úgy hogy a projektnek több féle Linux disztrón, többféle CPU archictectúrán (armle/be/64, ppc, x86) kellett futnia. Külön production és unit teszt kód. Kellett binárisokat, shared és static libeket, sima 3pp-ket, framework 3pp-ket, kernel modulokat, illetve magát a kernelt is fordítani) után álom az, hogy a go-ban a build annyi, hogy go build.

Volt kollégám aki C++ phd hallgató volt és olyan csuda kódot írt, hogy a csapatból senki nem értette, hogyan működik, amit írt. Ez pedig szerintem abszolút a nyelvhibája, hogy ilyet megenged. A csuda kód alatt nem valami alattomosan kesze-kuszán írt kódot kell érteni, hanem olyat, ami kihasználja a nyelv featureit. Talán egy jó példa, hogy a C++ template magicre külön kb 1000 oldalas könyvet írtak. WTF?! Ki az aki ezt elolvassa és végül használja?! És a template magic csak egy a sok C++ featurei közül.

Humor ON:
A Rust-ról ennyit tudok: [Interview with Senior Rust Developer in 2023]
Ez pedig jól mutatja be az emacs-t: [Interview with an Emacs Enthusiast in 2023 [Colorized]] (btw, nagy emacs fan vagyok)

(#14) Mr Dini: a vscode tényleg jó. Amikor vacilláltam, hogy milyen toolt használjak és akkoriban lett volna vscode, akkor könnyen lehet, hogy ott kötök ki én is.

Úgy gondolom, hogy a vim és az emacs egy kutya csak más a megközelítést használtak. Teljesen mást: [Editor war].

Szerintem bold claim a részedről, hogy nem tartod magad programozónak. A megnyilvánulásaid alapján nekem az jön le, hogy mélyebben tisztában vagy a dolgok mikéntjével

Szerintem ez egy fontos önismeret, hogy valaki tudja magáról, hogy kicsoda. Persze azt fontos leszögezni, hogy ez nem mérvadója a tudásnak, hanem inkább a gondolkodást írja le, hogy hogyan áll hozzá a problémához.

[ Szerkesztve ]

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

szerintem a Decompile ablak csak annyit mond, hogy az egyes sor milyen symbolt használ. A bal oldali ablak meg "csak" annyit, hogy az fmt-ben milyen symbolok vannak.

Igen. Itt arra voltam kíváncsi, hogy van az fmt csomag. Annak van ugye Println, Print stb metódusa. Mivel én csak a Println-t használom, felesleges lenne a fordítónak a Printet is a binárisba rakni, hiszen ezt a metódust nem hívom meg. Abban a tévhitben éltem eddig, hogy ilyen esetben is belekerül a teljes fmt csomag a binárisba. De a screenshoton az látszik bal oldalt, hogy a végleges bináris az fmt-ről annyit tud, amennyi szükséges neki. Nincs pl. Print benne. A jobb oldal lényegtelen, az csak kontextusként szerepel, hogy demonstráljam, mi történik a main()-ben. Megerősítés, hogy tényleg ez a helyzet.

Szóval a nagy méret inkább tényleg linkelésnél jöhet be a nagy méret, meg azért a runtime sem kicsi.

De ez pozitív a Go oldalról, nem tudtam.

A videót meg köszi. Jó áttekintés volt.

emacs vs vim: Én is azért kezdtem vimet használni, mert erről hallottam korábban és be is vált. Egész megszoktam a szkriptelését is. Illetve a kiosztása is kézre áll. Ettől függetlenül nem zárkózom el az új dolgoktól, szóval adok neki majd mindenképp egy esélyt, csak ehhez kell egy kis szabadidő.

[ Szerkesztve ]

Hogy hívják az éhes horgászt? Gyere Pista, kész a kaja!

A Python vs Go (stb) egy hibás kérdésfelvetés ebben a formában Az eszközt a feladathoz érdemes választani, éppen ezért a Python még a "minimumra törekvés" kategóriában is versenyképes, mert ma nincs Linux Python nélkül. Vagyis egy bizonyos kód méret alatt egy scripting nyelv egyértelmű előnyben van azzal az erőfeszítéssel, amit egy extra compiler + libek megkívánnak.

A vim pedig ... hát lehet, hogy kisebb erőforrás, de nagyobb mazochizmus Mondom ezt úgy, hogy nálam terminálos szerkesztés esetén mindig ez a default, de a kényelmes nem egyenlő a megszokással.

És persze gratulálok a 24 órás versenyhez - nekem hasonló tapasztalat csak 24 órás munkahelyi prod upgrade esetén jutott

Ismerd meg a go-t . A go végtelenül egyszerűvé tette a build és az a körüli dolgokat. Egy kis dolgokra abszolút rendben van, de amikor új és nagy terméket indítanak pythonban, azt maximum csak úgy tudom megérteni, ha ML-es projektről van szó, vagy az ott dolgozó emberek python only világképűek.

Egyetértek, a vim szerintem is az ördög műve . Emacs rlz.

tely, baly, fojó, mennyél, mingyárt, telyföl, tolyás, malyd, kapú, egyenlőre, ejsd, jáccani, ahoz, fúj, hüje, muszály, alat, álok, lasan, fojtatás, ál, fontós, költsön, eggyüt, lyob (jobb?), mek, mongyak, milyért - !!! Tanúlyunk már meghejjessen irni... !!!

"...(több millió soros C/C++ projektet ...".
A jelenlegi Linux kernel kb. 300-400e. sor C kód. Csak kíváncsiságból, milyen jellegű projekt volt az említett? 10 Linux kernel?
Mainframe az alapterületem (meg Java); egy 20.000 soros PL/I-COBOL modul már kb. a kezelhetőség felső határa szerintem (stílustól függően).

Köszönöm a kiváló bejegyzést, és gratulálok az eredményhez!
Büszke vagyok Rád, és arra, hogy az ismerőseim között tudhatlak. Ha ügyesen menedzseled magad, nagyon messze eljuthatsz karrierben. Sok sikert!

A konfigomat lásd az adatlapomon.