Miért nem értik meg az emberek, hogy vége az IT "aranykorának"?

> Azt akarom mondani, hogy a malloc vagy egy opre szintű függvény, vagy fordító (pl. C compiler) szintű, szóval a malloc-ot csak meghívja a (másik) fordító fejlesztője.

Azt akarod mondani, hogy itt a C nyelv elfedi azt, ami valójában történik? Hogy a fordító és az oprendszer írójának az asztalára tartozik az, hogy hogyan éri el – és hogyan címzi meg – a memóriát? Hogy tulajdonképpen nem is kell tudni már egy C nyelvű program esetén sem, hogy hogy történik a memória címzése? Hát nem erről beszéltem én is?

Tegyük fel írok valami programot C nyelven. Ez lefoglal a működése során x bájtnyi memóriát. A fordító aztán lefordítja ezt mondjuk egy exe fájllá. Vagy ha úgy van, akkor Linux alatt egy ELF fájllá. De ha valaki ír Commodore 64-re egy C fordítót, akkor lefordítható arra is. A fordító felelőssége, hogy az adott függvényt megvalósítsa, és ha ehhez az kell, akkor az operációs rendszer megfelelő függvényeit meghívja. Az operációs rendszer felelőssége meg az, hogy a megfelelő módon megvalósítsa azokat a függvényeket, amit aztán meg lehet hívni.

Nekem annyit kell csak tudnom, hogy C-ben a malloc függvény paramétere a lefoglalandó bájtok száma, a visszatérési érték meg egy mutató, ami egy logikailag egybefüggő memóriaterületre mutat. Hogy most egy x86-os architektúra esetén valós módban ez fizikailag is egybefüggő terület, és a mutató valós. fizikai memóriacímet hordoz? Vagy védett módban ez csak logikailag egybefüggő terület, ami fizikailag lehet össze nem függő blokkokban is? Nem fontos. Nemhogy nem fontos, hanem nem *szabad* fontosnak lennie, az oprendszer és a fordító pont azért fedi el ezt, mert a C nyelvű kód számára mindennek indifferensnek kell lennie, a memória címzési módtól függetlenül kell ugyanúgy működnie annak a C nyelven írt programnak.

Ugyanez a helyzet fölfele is. A fordítók, értelmezők egy csomó technikai dolgot elrejtenek, hogy egy absztraktabb, magasabb szintű logika mentén lehessen szoftvert írni, ami lehet, hogy rövidebb, lehet, hogy érthetőbb. Az, hogy két adattáblát pontosan hogyan kapcsol össze az adatbáziskezelő, mit mi után csinál, milyen adatokat hogyan tárol közben, azt nem kell tudnom és értenem. Jóval bonyolultabb is lenne ennek a taglalása, mint az a 3 soros SQL, amit leírtam. Ha esetleg akarom, fel tudom mérni az adott lekérdezésnek a memóriahasználatát, futásidejét, és ez alapján tudok optimalizálni, vagy akár az SQL-en kívüli alternatív megoldást keresni az adott problémára.

Van,aki keni-vágja az SQL-t, de fogalma sincs a memóriacímzés módjáról.

Van, aki keni-vágja az x86-as architektúra memóriakezelésének ügyes-bajod dolgait, de nem ért ahhoz, hogy SQL-ben hogy lehet két táblát összekapcsolva részösszegeket lekérni.

Van, aki meg mindkettőt keni-vágja, nyilván ez a legjobb.

De a memóriacímzés tudásából nem következik az, hogy valaki SQL-ben is otthon van, a memóriacímzés tudásának hiányából meg nem következik az, hogy valaki ne lehetne SQL-ben profi.

Amit a #10-es válaszban felsoroltál az mind ilyen. A tudásukból nem következik az, hogy valaki mondjuk jó frontend fejlesztő lesz, de a nemtudásukból nem következik, hogy ne lehetne profi frontend fejlesztő. A frontend fejlesztő meg ha elmúlt 40 éves, akkor nem az egyetemen tanulta ezt, és az egyetemi tudásának zöme nem releváns abba, hogy elsajátította-e, el tudta-e sajátítani, jól tudta-e elsajátítani a frontend fejlesztés csínját-bínját. Az egyetemen szerzett tudása teheti szélesebb látókörűvé, segíthet is a frontend szakma gyorsabb elsajátításában, de azt, hogy valaki jó frontend fejlesztő-e azt az erről számot adott tudása alapján lehet csak megítélni, önmagában az egyetemi diploma meglétéből sem, és az egyetemi diploma meg nem létéből sem.

32,

"Nemhogy nem fontos, hanem nem *szabad* fontosnak lennie, az oprendszer és a fordító pont azért fedi el ezt, mert a C nyelvű kód számára mindennek indifferensnek kell lennie, a memória címzési módtól függetlenül kell ugyanúgy működnie annak a C nyelven írt programnak."

Ez tömény hülyeség. Sem az oprendszer, sem a fordító nem fed el semmit. A memóriakezelést kontrollálja az opre, mert többek között ez a feladata.

Hogy nézne ki az, ha a multitaszk környezetben maguk a programok foglalnának maguknak memóriát?

A valós módban fordított program meg nem fog futni védett módú környezetben, ahogy a védett módban fordított program sem indul el valós módban, mert eleve, más védett módban a memóriakezelés.

Látod, itt vannak nálatok azok a hiányosságok, amiről beszélek. Nálatok nem csak az a baj, hogy nem sokat tudtok, hanem az is, hogy bizonyos dolgokat eleve rosszul tudtok. A saját butaságaitokkal tömitek be a tudáshiány okán meglévő réseket. Ahogy tetted most te is.

Idézlek:

"Azt akarod mondani, hogy itt a C nyelv elfedi azt, ami valójában történik? Hogy a fordító és az oprendszer írójának az asztalára tartozik az, hogy hogyan éri el – és hogyan címzi meg – a memóriát? Hogy tulajdonképpen nem is kell tudni már egy C nyelvű program esetén sem, hogy hogy történik a memória címzése?"

Erről szó sincs. A feladatok bizonyos esetekben el vannak szeparálva. Ehhez a metodika gyakran már ki van dolgozva, ahogy például a játékfejlesztés esetében is. A memóriakezelés az opre dolga most is és az opre dolga volt még az ősidőkben, a DOS idejében is. Ez teljesen természetes dolog. A DOS is lefoglalja az elérhető teljes memóriatartományt és ha egy programnak szüksége van memóriára, akkor kérnie kell. Védett módban meg pláne, hiszen ott nem egy, hanem adott esetben több száz program fut egyszerre, egymástól elkülönülve. Honnan is tudnák, hogy melyik memória lap foglalt és melyik nem az?

Idézlek:

" A tudásukból nem következik az, hogy valaki mondjuk jó frontend fejlesztő lesz, de a nemtudásukból nem következik, hogy ne lehetne profi frontend fejlesztő. A frontend fejlesztő meg ha elmúlt 40 éves, akkor nem az egyetemen tanulta ezt,"

Nincs olyan, hogy frontend fejlesztő. Olyan van, hogy a diplomás beleáll és az életideje bizonyos részében éppen frontendet fejleszt, vagy olyan van, hogy a szakirányú végztettség nélküli mókamikit felveszik a hiányos tudásával olyan munka elvégzésére, amihez elég még az ő képessége is. Na, tipikusan ilyen a frontend. De ettől még az a mókamiki nem válik szakemberré. Marad ami volt, segédmunkás, vagy mondjuk azt, betanított munkás. És ez még akkor is igaz marad, ha idővel ő rittyenti a legszuperebb frontendet az országban.

A diplomás meg, ha feláll mert megunja a frontendet, akor elmehet fejleszteni bármi mást, mert ő szakember, mert megvan más területhez is a tudása, az ismeretalapja. Ezért koptatta a seggét évekig az egyetemen. Ezért tanult olyan dolgokat is, amit ti rendre fölöslegesnek tartotok. Ő megszerezte azt a tudást, ami őt szakemberré teszi. Neki megvan az, ami belőletek hiányzik.

"A diplomás meg, ha feláll mert megunja a frontendet, akkor elmehet fejleszteni bármi mást, mert ő szakember, mert megvan más területhez is a tudása, az ismeretalapja."

Azért nem egészen pár év után már elévülnek/elkopnak a diplomázás óta tanult dolgok és újra kell tanulnia őket, hogy legyen reális esélye...

Ami lemaradt, pedig fontos:

Vannak un. bare metal fejlesztések, tehát, amikor nincs operációs rendszer, a program magában fut a vason. Ilyenkor a fejlesztő közvetlenül kezeli a hardver erőforrásait (memóriát, I/O portokat), és minden vezérlést maga a program biztosít saját magának. Ezekben az esetekben a kód közvetlenül fut a fizikai hardveren, és a programozónak kell gondoskodnia az összes olyan alapvető feladatról, amelyeket más esetben az operációs rendszer intéz.

Ekkor mit is csinálna egy olyan mókamiki, aki csak frontend fejlesztő, ahogy te titulálod az effélét?

Hát, kb. semmit.

Gondolom már számodra is körvonalazódik, hogy mekkora oltári nagy hülyeség az, amit ti előszeretettel szajkóztok, hogy jaj ezt sem szokták sokan, meg azt sem szokták sokan, úgy, hogy meg sem kell tanulni.

Hát, igaz ami igaz, nektek tényleg nem kell, nem kényszerít benneteket se vizsga, se semmi, na de, ez meg is látszik az értéketeken. A keresettségeteken meg a jövőben még jobban meg is fog.

"Azért nem egészen pár év után már elévülnek/elkopnak a diplomázás óta tanult dolgok és újra kell tanulnia őket, hogy legyen reális esélye..."

Nem kopnak el azok olyan hamar. Be is baxna. Nekem volt olyan esetem, amikor egy módfelett primitív illesztési módot igényelt a megrendelő, annak okán, hogy olcsó. Én ezt az módot már el is felejtettem, mert tanultam ugyan, de a gyakorlatban soha nem használtam. Elmentem a Műszaki könyvesboltba, ott találtam egy kis A/5-ös formátumú, talán 70 oldalas könyvecskét, ami ezt az illesztési módot is tárgyalta. Megvettem a könyvet, felszálltam a körúton a villamosra, beleolvastam a könyvbe és mire a Skálához érem, már képben is voltam.

"A valós módban fordított program meg nem fog futni védett módú környezetben, ahogy a védett módban fordított program sem indul el valós módban, mert eleve, más védett módban a memóriakezelés." -> Továbbra is látszik, hogy a haszontalan válaszok nagy mestere leragadt valamikor az 1990-es évek szintjén. És nem képes tovább látni a már akkor elavult i386 világon. És azt sem látja, hogy ma már a fjelesztések nagyon nagy része nem intel procira hanem a mobil eszközökben lévő ARM architektúrára történik és mantrázza a teljesen értelmetlen i386 valós módot. Áruld el,hogy hogyan lehet agy ARM processzoron valós módot kiválasztani?

Hogyan képes ember ennyi zöldséget összehordani?

"felszálltam a körúton a villamosra, beleolvastam a könyvbe és mire a Skálához érem, már képben is voltam." -> most sem vagy képben semmivel. Szerintem kicsit lassan jár az a villamos amin utazol.

34 (2024.11.11 08:08): "Ez tömény hülyeség. Sem az oprendszer, sem a fordító nem fed el semmit. A memóriakezelést kontrollálja az opre, mert többek között ez a feladata." (előzményt nem másolom ide, visszakereshető).

Az a tömény hülyeség amit te írsz. Azért látod hülyeségnek, mert leragadtál az 1960-as évek közepén. Már az IBM360-nál elkezdődött, de a későbbi gépeknél az 1960-as évek vége felé, és különöse a PDP11-nél (ez azért izgalmas, mert PDP11-re készült az első igazán használható unix, és erre fejlesztették az első C fordítót, sok minden a C mélységeiből úgy érthető meg, ha a PDP11-et tanulmányozza az ember) megjelent a virtuális memória kezelés. És pontosan ezen okból jelent meg a C-ben a pointer, meg jelentek meg azok módszerek amiket ma használunk. Ugyanis a hardver (igen a hardver is, töltsd le a netről a PDP11 memória vezérlő áramkör teljes dokumentációját és ott megérted még azt is, hogy mit jelent a linuxban a mai napig benne levő: "segmentation fault, core dumped" üzenet, ott van benne a PDP11 memóriavezérlőjében ennek minden darabja), az operációs rendszerrel és a fordítóval gondoskodik arról, hogy amikor virtuális memóriát használ az ember akkor ne kelljen arról tudnia (ahogy 2*Sü nagyon helyesen leírta), hogy akár maga a program, akár az adat hol is van a fizikai memóriában (esetleg a virtuális memória miatt ki van lapozva vagy swapelve a háttértárra), ezt el kell(!) rejteni a felhasználói program elől. Nem kell ma már ezzel a felhasználói programnak és azt azt készítő programozónak tudnia. Ez egy alapvető elvárás minden "modern" hardvertől, operációs rendszertől és fordító/fejlesztő rendszertől legkésőbb 1970-71 óta (több, mint 50 éve; az, hogy Te ezt nem vagy képes már befogadni az a Te szellemi képességeidnek a korlátait mutatja). A VM/370 esetén ennél még tovább mentek, de abba már végleg ne menjünk bele, mert azt te már sose fogod felfogni agyilag.

Aztán jött és fénysebbességgel elterjedt az OOP szemlélet és az ennek megfelelő nyelvek (alapjai szintén az 1960-as évek végén megszülettek, de csak valamikor az 1990-es évek végén lett elegendő memória és CPU teljesítmény, hogy valóban kihasználható legyen ennek minden előnye, mert való igaz, hogy kicsit nagyobb a memória és a CPU igénye egy OOP fejlesztésenek de máshol visszajön bőven), ahol már a "változó" fogalma is megváltozik és még kevésbé kell a programozónak foglalkoznia azzal, hogy az egész hogyan fog az adott hardveren lefutni, mit csinál a fordító, mit az operációs rendszer és mit ad hozzá a hardver.

Amikor meg még távolabb vagyunk az egésztől és pl. egy böngészőben "fut" a cuccunk mert egy web appról beszélünk akkor meg már azt se kell tudjuk, hogy egyáltalán milyen processzor, milyen operációs rendszer vagy egyáltalán milyen hardver van a felhasználó alatt. Ezeket az egymsára "rakodó rétegek" elfedik. Mert eért találtattak ki, hogy a programozónak ne kelljen egyáltalán foglalkozni ezekkel. Igen ma itt tart a "tudomány". Az, hogy Te leragadtál legkésőbb 1965-ben az téged minősít, mert a válaszaid alapján kb. egy akkor gépet programoztál utoljára. Vagy azokat a módszereket használod amit akkor megtanultál.

38,

ezzel a meséddel csak egy gond van, azon túl, hogy több sebből vérzik. Még pedig az, hogy nem igaz.

Én a hatvanas években még nem éltem, de azt tudom, hogy amit te összehordtál, az azért hülyeség, mert a C és az UNIX fejlesztése egy használaton kívüli PDP-11-esen történt. Ráadásul, egy korai példányon, amelyben még nem volt MMU (Memory management unit) és a gép teljes címtere mindössze 64 KB volt. Tehát a te meséd a virtuális memóriáról kb. itt véget is ér.

Éppen ez a memória deficit szülte a C-t olyanra, amilyen. Kevés kulcsszó, sok operátor. A pointereknek meg végképp nincs semmi közük ahhoz, amiről vakolsz, hiszen éppen a C-ben életre hívott pointerezés lehetősége rugott alá a legjobban az oprendszerek memória védelmének. A vírusok legtöbbjét is magának a C nyelvnek köszönheti a számítógépes társadalom.

A pointerek szintén a krónikus memória-hiány okán kerültek képbe, hiszen így például egy tömb valamely elemét sokkal gyorsabb volt elérni, a UNIX meg véletlenül pont tömbökbe szervezetten kezeli a memó-laptáblázatokat.

A többi butaságra nem reagálok (ARM, i386, IBM360 (mi a faxom az?) stb.) mert nem látom értelmét a válaszadásnak.

Annyit még leírok, hogy az iparban a mai napig rengeteg helyen használnak mikro PC-ket, akár ROM DOS-sal és csak azért, mert van újabb, nem fogják lecserélni a műlödőképes rendszereiket, de fejlesztési igény azért ezen a körön belül is van. Ezt az igényt is ki kell valakinek szolgálni és az nyilván nem a frontendet fabrikáló mókus örs tagjainak egyike lesz. Ezt gondolom még te is képes vagy belátni.

Arra meg, hogy ma már nem csak routerben, de még egy riherongy kenyérsütő gépben is ott a számítógépes logika, oprendszer nélkül, nem is illene kitérnem.