Melyiket kezdjem el tanulni?

Az android nyelve is java volt, aztán jött a kotlin, szóval mondhatni az utolsó jó lehetőségből is kiszorult. Nem hiszem, hogy lesz még fénykora.

Még sok évig lesz haszna a java-nak, de ha belegondolsz a microsoft miket vásárolgat fel (övék a C#, a Mono is) így rájöhetsz, hogy a piacról egyre jobban szorítják ki a javat.

Akármelyik nyelvet is választod az elsőt a legnehezebb megtanulni (kivéve assemblyt talán, azt később sem annyira könnyű :D). Ha megtanulod a java-t, akkor elég hamar tudsz váltani C#-ra és fordítva.

#12:

az assemblyt azért mondtam, mert az szintaktikailag nagyon eltér a többi nyelvtől, a C típusú nyelvek azért könnyebben érhetőbbek

az assemblyt úgy olvasni, mint a C#-ot, javascriptet azért jóval több időbe kerül (sok-sok gyakorlat)

igen az assembly ma már csak hardver közeli vagy NAGYON NAGYON erősen optimalizált műveletnél szükséges

az átlag programozó számára ma is mondhatni feleslegesnek a nyelv maga, viszont jó ismerni optimalizálás szempontjából a különböző dolgokat, hogy valójában mi mennyire terhel, hogyan működik a háttérben

pl én láttam egy példát anno, hogy X/5-el helyett érdemes X*0.2-t használni, mai napig nem tudom a pontos miértjét, de gondolom az assemblyben elég hamar kiderülne

persze ezt nem úgy értem, hogy akkor mindenhol ez kell, hanem nagyon kritikus helyzetekben ezzel is lehet nyerni

én mostanság kezdek olyan dolgokkal foglalkozni ahol nagyon nem mind1, hogy hány ms alatt futnak le kódok és szeretnék minél több és jobb megoldást ismerni

"pl én láttam egy példát anno, hogy X/5-el helyett érdemes X*0.2-t használni, mai napig nem tudom a pontos miértjét, de gondolom az assemblyben elég hamar kiderülne." Ez nagyon nyelv és fordító függő, hogy melyiket mire fordítja. A szorzás és osztás lényegében hasonló futást időt produkál, főleg ha float. Fix pontos esetben valamivel lassabb az osztás, de ez a különbség elenyésző (főleg ha van hozzá hardveres szorzás-osztás támogatás a prociban).

Nem szorzással, de hatványozással volt főnököm igen behatóan foglalkozott. És egy átlagos fordító esetén (hangsúlyos, hogy átlagos fordító, mert lesz egy pár g*c*k*g aki ebbe a kijelentésbe beleköt), az x^2 és az x*x egészen másképpen számolódik ki, pl. az x*x pontosabb is lesz, és lényegesen gyorsabb! Léteznek ma már olyan (főleg nagyon új C++) fordítók, amelyek nagyon durván optimalizálnak és ha rájön, hogy x^2-et írtál azt x*x-re fordítja, általában a 4. 5. hatványig. Igen nem árt látni, hogy mi történik a gépen belül. Akik (még vagyunk jónéhányan) akik látjuk, és időnként azt is, hogy mire fordít egy fordító akkor a pokolba kívánjuk azokat akik ezt írták/kitalálták/használják. Ma annyira olcsó lett a hardver, hogy az esetek jelentős részében nem éri meg a programozónak akár csak 1 hangyabokányit is optimalizálni a kódon, mert "vegyél 1-el erősebb procit és még 2GB RAM-ot" még a felhasználónak is olcsóbb lesz mint azt, hogy a programozó még 2 hétig optimalizál. Ennek egyenes következménye az OOP ami a proci oldaláról nézve egy szörnyszülött, de hatákony programfejlesztési eszköz, hogy ezáltal a program CPU és RAM igénye elszáll a búbánatba az a kutyát nem érdekli (ma már), annyire olcsó a CPU és a RAM. (most nem a játékprogramokra gondlok, bár ott is kezd beindulni ez a szemlélet, hanem az üzleti alkalmazásokról, különös képpen a Pythonról).

"én mostanság kezdek olyan dolgokkal foglalkozni ahol nagyon nem mind1, hogy hány ms alatt futnak le kódok és szeretnék minél több és jobb megoldást ismerni" üdv a Klubban :)

Web fejlesztés esetén ezeknek nincs relevanciája. Ott nem ezek a tényezők számítanak. És ne vigyük el OFF irányba a dolgot.

#14:

játékfejlesztés ahol mostanság foglalkozom ezzel a dologgal, mármint a komolyabb optimalizálással

ami vicc, hogy munkahelyen vannak olyan rendszerek (web, PHP) amik 10+ évesen és 12GB RAM körül kell nekik adni 1-1 generálásnál, mert annyira sokat zabálnak

ha ezt ma újraírnák, akkor ennél jóval kevesebbet fogyasztana

a 3-10-18 ezer soros PHP fájlokról, meg 2000 soros SQL querrykről ne is beszéljünk

állítólag amúgy azért lett ennyire gány az a rendszer, mert akkor még így tudták megoldani, elég sok felhasználó használja és eléggé szétszedték a DB-t (bár az indexelés vicc, mert van olyan amit csak tavaly kezdtek indexelni a kollégák)

#16:

mert rengeteg tábla van feleslegesen, rengeteg adatot kér le feleslegesen

nem csak azt amivel számol, hanem egy csomó olyan adatot is amire nincs is szüksége

sok felesleges join is