Új hozzászólás Aktív témák

• #4 ddekany veterán .mf #2

  Új Válasz 2023-03-14 17:35:39 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz .mf #2 üzenetére

  Ez adódik a piaci mechanizmusokból, hogy a szoftver belenő a rendelkezésre álló hardver erőforrásokba. Ez persze egyre nehezebb, de mi fejlesztők kreatívak vagyunk. Pl. hogy a frászba lehetne egy nem túl komplex chat programra elherdálni 500 MB RAM-ot (szó szerint - tudjuk miről van szó). Hm... Csomagoljunk bele egy egész böngésző motort (az eleve iszonyat komplexitást hordoz magában, ami jelentős részben csak történelmi hordalék amúgy, de lényeg, hogy semmi köze a valódi célhoz, ami a chat-es funkcionalitás). OK. Aztán, annak a tetején használjuk valamelyik m*szturbálós webes keretrendszert. Az most cool dolognak számít amúg is, szóval lesz munkaerő. Hoppáka, ott repül az 500 MB, ééés régi gépen érezhetően lassú is az egész! Solved.

  Megoldás a gondra? Nem tudom. Törvényt kell hozni, hogy jövőre max 30W-ot ehet egy polgári PC, és max 4 GB RAM lehet benne, aztán rá két évre ezeket felezni, stb. Idővel töredékére zsugorodna egy PC, valami kis passziv dobozka lenne, és hogy hogy-hogynem irodai területen ugyan azt meg tudná csinálni, mint most... (Na most C++ projektet nem fordítanák szívesen olyanon, vagy IC-t se szimulálnék rajta... Ugye ez a mási csavar, hogy valaminek viszont tényleg kell a kraft.)

  [ Szerkesztve ]

• #13 ddekany veterán opr #10

  Új Válasz 2023-03-15 14:03:04 #13

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz opr #10 üzenetére

  Natív kódot max assembly-ben kell írni, a C++ csak arra fordul (vagy akár WASM-ra). A C++-al a gond, hogy komikusan túlkomplikálódott, és részben elavult design, nem az, hogy "natív". A Rust-al az egyik, hogy nincs GC, ami szándékos feature ott, de projektek többségének csak felesleges nehezítés, és Rust-ot az általa nyújtott garanciák miatt erősen meg is komplikálja. Go-val ez egyik, hogy nem hogy nincsenek exception-ok (Rust-bem sincsenek), de a hibakezelés olyan fapados, hogy az borzalom... Zig leveri benne a f*szba, holott az egy sokkal alacsonyabb szintű és jóval egyszerűbb nyelv. (Generics már végre van... hurrá.) Persze tudom, exception-okat divat utálni, de azok az emberek vagy életében nem dolgozott olyan nyelvel, ahol az nem afterthought volt, vagy kb. kernelt/drivert írnak, vagy simán pszichók. Ja, és OOP is eléggé át van variálva ezekben, és hát jelenleg én nem merném kijelenteni, hogy ezek jó változtatások összességében, ellenben azzal, hogy csak így tudják implementálni hirtelen (vagy ilyen agymenése volt valamelyik atyának), aztán utólag megideologizálják, hogy ez így sokkal jobb (és akinek nem teszik, az csak nem érti, hülye).

• #14 ddekany veterán opr #12

  Új Válasz 2023-03-15 14:07:39 #14

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz opr #12 üzenetére

  Ez kb olyan, mint az egész civilizáció. Ami rövid távon olcsó/hatékony, azt kell csinálni, különben eltapos a konkurencia. A többit majd állják az unokák...

• #17 ddekany veterán fatpingvin #16

  Új Válasz 2023-03-15 15:31:01 #17

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz fatpingvin #16 üzenetére

  De, ha azok a projektek nyernek a versenyben, ahol a middle manager gyorsan kipréselt akármilyen szart a csapatból, és a többi projekt meg tönkremegy, akkor ez ellen nem reális tenni, mert a matek (itt kb. játékelmélet) mindig győz. Valahogyan, nem tudom miképpen, de úgy kellene módosítani a rendszert, hogy ne ez legyen a nyerő stratégia.

  [ Szerkesztve ]

• #18 ddekany veterán opr #15

  Új Válasz 2023-03-15 15:35:44 #18

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz opr #15 üzenetére

  Mellékesen, ezek sokszor nem is a nyelvről szólnak (bár persze az is szab technikai korlátokat), hanem szubkultúráról, amihez az tartozik. JS, az webes gyors gányolás szubkultúra, mert a böngészőkből jött.

  A Rust meg, nem is próbál praktikus lenni általános üzleti alkalmazás fejlesztésre. Egyszerűen nem arról szól, hanem ilyen "engine" fejlesztésről. Szóval nem az, hogy "nincs tökéletes nyelv", hanem nem is akar jó lenni arra, amit a többségünk fejleszt.

  [ Szerkesztve ]

• #22 ddekany veterán fatpingvin #20

  Új Válasz 2023-03-15 16:23:08 #22

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz fatpingvin #20 üzenetére

  Mindenkinek korlátos a szellemi kapacitása. Ha nem szükséges adott területen, akkor senki nem szeretné pl. a GC kiváltásra költeni azt, valami hasznosabb dolog helyett.

• #24 ddekany veterán dabadab #23

  Új Válasz 2023-03-16 08:35:48 #24

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz dabadab #23 üzenetére

  Túl olcsó a hardver.

• #39 ddekany veterán buherton #27

  Új Válasz 2023-03-19 19:14:11 #39

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz buherton #27 üzenetére

  A legtöbb régi nyelv egyszerűen ostobán lett megtervezve, és azóta bölcsebbek lettünk. Soha nem volt jó, hogy nem lehet tudni fordítás időben egy erősen típusos nyelvben, hogy valami lehet-e null. Soha nem volt jó, hogy trágya a hibakezelés. Stb. Nem kellenek ehhez az új körülmények. Meg persze, hatalmas hátránya a régi nyelveknek, hogy utólag hozzájuk lett toldva rakás feature, ami nem működik túl jól a régiekkel... Nyilván ezt a komplexitás robbanást is jobban bírják a jobb programozók, de azért nekik is csak rossz.

• #41 ddekany veterán Reggie0 #40

  Új Válasz 2023-03-20 08:28:17 #41

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz Reggie0 #40 üzenetére

  A memória kezelés probléma minden megoldása egy kompromisszum. A GC sok alkalmazásban messze a legjobb kompromisszum.

• #56 ddekany veterán buherton #50

  Új Válasz 2023-03-20 20:31:23 #56

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  veterán

  válasz buherton #50 üzenetére

  Ez vicces, hogy mindig a Java van felhozva, mint lassú nyelv, holott a leggyorsabbak közt van a széles körben használtak közt (és a hozzá képest irgalmatlan lassú Python meg fel se merül). Azzal a feltétellel, hogy nem valami pár pillanatig futó dologról van szó, szóval a indulási overhead nem dominál. Az más kérdés, hogy csillagromboló frameworkok-et szokás használni (entöprájz...), ami nyilván dominálni fog a valódi feladattal szemben, ha valami egyszerűt alkalmazást raknak a tetejére.

  A Java memória használatot meg nehéz mérni, mert ott a fő gond, hogy a legtöbb GC antiszociális, és nem nagyon töri magát, hogy visszaadja a szabad memóriát az OS-nek. Neki szabad az a hely a heap-ben, de másnak nem adja. Úgy lenne ideális a hely kihasznlás, ha OS szinten lenne egy nagy közös heap, de persze ennek számos akadálya van (pl. biztonsági parák). (De állítólag újabb GC-kel már eléggé szociális is tud lenni... nem próbáltam.)

  [ Szerkesztve ]

Új hozzászólás Aktív témák