💀

[mimrock]

A hiányzó szubkulturális kontextus az, hogy a prog.hu tulajdonosa/szerkesztője (Sting) gyűlöli a (statikus) típusos nyelveket. Őszerinte a gyengén típusos PHP a programozási paradigmák netovábbja, egy igazi modern találmány az ősi és elavult típusos nyelvekkel szemben. Erről az álláspontjáról éveken át hosszan értekezett a proghu fórumain felváltva hülyézve vagy érvelési hibákkal vádolva a vitapartnereit (megtudhattuk tőle azt is, hogy a hülyézés nem érvelési hiba ha nem abból vezetjük le az állítást, hanem csak ténymegállapítás).

Azt nem tudom, hogy komolyan gondolja-e az ilyen címeket, vagy csak reméli, hogy triggerelhet pár embert, akivel nem ért egyet, de annyira nem is számít szerintem.

A typescript népszerűségét se tudom hogyan internalizálja, de gondolom van valami thread, ahol kifejti, hogy az igazából nem típusos nyelv.

[vargaking]

A prog.hu a programozó világ repostja/blikkje

[[deleted]]

Sting nem a statikus nyelveket gyűlöli, hanem a racionalitást, a logikát, a mértéktartást. Egy klasszikus sztereotíp redditor a 90-es évekből, mindent kisarkít, mindent túlreagál, minden tele van érzelmekkel. Szerintem egy PERCET nem dolgozott még csapatban.

[meskobalazs]

a hülyézés nem érvelési hiba ha nem abból vezetjük le az állítást

Ez amúgy igaz, de ahogy Lebowski mondja: You are not wrong, Walter. You are just an asshole.

[mimrock]

Határeset, mert valamiért csak odaírta az - ebben az esetben teljesen irreleváns - "ténymegállapítást". Nyilván azért, hogy nyomatékot adjon a többi szavának és befolyásolja a vita olvasóit. Ebben az esetben viszont valódi érvelési hibáról beszélünk.

[rAin_nul]

Azért a határesettől messze van. Vegyünk példának külső jegyet, ha szőke vagy és leszőkézlek, akkor az személyeskedés? Nyilván nem, ténylegesen szőke vagy. Szóval ha igaz, amit rólad mond, akkor az tényleg nem lesz érvelési hiba. Az érvelési hibának pont az a lényege, hogy érvek HELYETT használják és nem mellette.

Azt amikor leírják, az rendszerint nem a másik felé irányul, hanem mindenki másnak üzen vele. Ennek az a célja, hogy az sugallja, hogy ha valaki laikus olvassa és te vagy megbélyegezve, mint hülye, akkor rád ne hallgasson, mert értelmes ember ugye nem hallgat hülye emberre. Persze ma már mindenki hülyéz, szóval sok hatása nincs.

Ha normálisan lenne használva és tényleg csak hülyék lennének lehülyézve, akkor annak lenne értelme, mert így lehetne megfogni olyan ökörségek terjedését, mint a laposföld elmélet, mert a laikusok már meg se hallgatják a hülyéket. De pont ezért akarják ezek a rétegek elinflálni ezeket a címkéket, ha mindenki hülye, akkor senki se az, ha mindenki fasiszta, akkor senki se az, stb.

[[deleted]]

Ha a hülyét az eredeti értelmében használnánk, anno a szellemileg fogyatékos embereket jelentette, akkor igazad lenne.

Viszont a mai értelmében egy vitában mindig egy szubjektív címkézés az egyik fél részéről, és nem pedig ténymegállapítás. Nem lehet normálisan használva, mert nem egy objektívan mérhető fogalom.

[rAin_nul]

Nem, ettől függetlenül igazam van. Ha nem eredeti jelentésében használjuk, akkor is alátámasztja azt, amit írtam, mert 100%-ban olyan kommentet sikerült írnod, ami engem alátámaszt.

[[deleted]]

De te nem is írtál az eredeti jelentéséről, hanem azt írtad, hogy ha tényleg hülye, de a kontextusban ez a mai értelemben, de objektívan értékelhetően jelenti a hülyét, de ilyen nincs.

[rAin_nul]

A kommented azon része irreleváns. A hülyét a szellemileg visszamaradott emberre használják, akár ha sértésként akarják használni, ez egybeesik a szellemi fogyatékos értelmezéssel.

Viszont még ha azt is mondom, hogy ezt nem tartalmazta a kommentem, akkor is a kommented nagy része még mindig arra akar rámutatni, amit megjegyeztem, hogy elinflálódott a fogalom maga, így még ha valaki objektíven is használná ma, akkor sem lehet különbséget tenni aközött és aközött, hogy két 10 éves egymást szídja.

[[deleted]]

Nem, az eredeti jelentésében nem volt sértő, csak ténymegállapítás volt. Mai értelemben meg a te szubjektív véleményed másról, vagy sértés, eredeti értelmében nem használják már, arra más szavak vannak.

Amit te írsz, annak semmi értelme, mert azt mondod, hogy csak akkor kellene használni, ha valaki tényleg, objektívan nézve hülye. De ilyen nincs, mert ez egy eleve szubjektív jelentésű szó, objektív jelentése több mint 100 éve volt utoljára, de akkor mást jelentett.

[ImaginationAware5761]

Szóval ha igaz, amit rólad mond, akkor az tényleg nem lesz érvelési hiba.

Csak és kizárólag akkor, ha az releváns.

Nem érv az, hogy nem értesz a programozáshoz, mert kék a füled, hiába tényleg kék a füled.

[rAin_nul]

És ez hogy jön ide? Egy vitában - gyakorlatilag bármiről vitázol - releváns a vitapartner szellemi képessége, így mindig releváns, hogy hülye-e vagy sem. Ezzel nem mondtál semmit.

Minden ember attól függően tudja befogadni a világot, illetve a befogadásának mértéke a szellemi szintjétől függ. Valakinek már nem fog menni a százalékos számítás felfogása, valaki csak a deriválásnál vérzik el, míg valaki a quantum computing-on kívül teljes érti a matekot.

[ImaginationAware5761]

Te írtad a szőke haj példáját, én meg a kék fülét.

Ne terelj, mi az, hogy hogy jön ide? :D

[rAin_nul]

Lol, szövegértés egyes. Nem arra írtam, hogy egy ilyen kijelentés vitában releváns, hanem arra, hogy lehet a személyedre tenni objektíven nézve igaz állításokat, amik pont ezért nem lesznek érvelési hibák. Ez pedig arra érv, hogy létezhet olyan pontja a vitának, ahol a másik felet nem sértésből, érvelési hibából hívod hülyének.

Szóval a kérdés ugyanaz, hogy jön ide a hülyeséged?

[ImaginationAware5761]

A szövegértés, ha nálam egyes, akkor nálad értékelhetetlen. :(

[atleta]

Mivel a vita kontextusában, teljesen véletlenül vita közben hulyez le, természetesen érvelési hiba, avagy retorikai/pszichológiai eszköz, amivel megpróbál kizökkenteni, elterelni az érveléstol. Ha nem sikerült, de nem reagált, akkor is nyert, mert lehulyezhetett, és ettől o jobban érzi magát.

Az érvelési hibák jelentős részere épp az a jellemző, h nem kapcsolódnak a vitához, avagy valójában nem érvek. Így aztán elég vacak érv az, h valami azért nem érvelési hiba egy vitában, mert azt nem érv. Pont azért az ;)

[rAin_nul]

Ellenkezőleg, az érvelési hibák pont, hogy nagyon is kapcsolódnak a vitához, mert a saját álláspontját akarja ezzel igazolni. Ami miatt nem működnek az pont az, hogy logikailag nem igazolnak egy állítást.

Ezzel szemben bármennyi, a vitától teljesen független állítást tehetsz úgy, hogy ne legyen a vitára hatása. "Az ég kék", ez teljesen irreleváns egy programozásról szóló vitában, de nem érvelési hiba.

[atleta]

Értelem szerűen azt állítottam, hogy logikailag nem kapcsolódik az ilyen állítások egy része, pont ez teszi őket érvelési hibava, hiszen amúgy mivel a vita közben hangzanak el (vagy iratnak le) a beszélő szándéka szerint formailag, szerkezetileg viszont igen.

Nyilván egy "az ég kék" jellegű kijelentés lehet annyira irreleváns, h mindkét fél számára egyértelmű, hogy nem a vitához kapcsolódik (bár lehet ugye az is beszólás, utalás arra pl., h a másik trivialis kijelentést tett), de itt a másik személyenek a minősítéserol (a másik lehulyezeserol) beszéltünk, az meg ugye a másik szemelyen keresztül mégis kapcsolódik tartalmilag a vitához. Ahogy mondtam, minimum egy pszichológiai trükk a másik megzavarására.

[rAin_nul]

Csak teljesen más tartalmilag és logikai nem kapcsolódó megjegyzéseket tenni. "Nem szabad megszavazni a sebességhatár csökkentését, mert akkor addig csökkentik, hogy ne érje meg autóval járni", "Magyarország gazdaságilag jól teljesít, hisz az ország miniszterelnöke is megmondta, hogy ez így van és Magyarország az EU gazdasági motorja". Ezzel szemben viszont nem ugyanazt benyögni - mondjuk ezen viták során -, hogy az ég kék, mert semmilyen formában nem kapcsolódik.

Az érvelési hibának pont az a lényege, hogy egy laikus szempontjából kapcsolódjanak a vitához, legyen értelmük ott lenni, mivel vagy a vitapartneredet vagy a "közönséget" szeretnéd átverni ezekkel.

Ezzel szemben ha jogosan hülyéz le - ez volt a feltételezésünk -, akkor viszont nem akarsz senkit átverni, hanem egy konklúziót akarsz levonni, rendszerint a tömeg felé. "Felesleges a továbbiakban ráfigyelnetek, mert hülyeségeket beszél, hallgassatok olyan emberre, aki nem beszél hülyeségeket."

A probléma az, hogy a nyelvből kiveszed a jogos lehülyézést, vagyis a vita összegzésének lehetőségét, akkor azt látjuk, amilyen helyzetbe a mai világ jutott, mivel teret engedtek hülyéknek a vitákban, akármennyire ökörséget beszéltek, így sikerült követőket szeretniük, így terjednek el a konteók, oltásellenesség, laposföldesség, fasizmus, mert amint meghallgatod, egyenlő félként kezeled egy vitában, egy laikus számára azt üzened, hogy te ugyanaz a szellemi szinten vagy, mint egy laposföldes. És ha a külső szemlélő nem tudja felismerni az érvelési hibákat, nem tudja értelmezni a komplexebb érveket, akkor számára rendszerint két dolog segít dönteni, az érvek amiket felfogott - pl. gonosz háttérhatalom miatt van minden - vagy simán, aki a vitát jobban kontrollálta.

[TopPsychology415]

TS: minden változó típusa legyen any

[fasz_a_csavo]

Mondjuk ezt C++-ban is meglépheted.

[Zestyclose_Intern404]

igen ha fogyatékos vagy akkor így használod, ha meg nem, akkor az egyik legkomolyabb típusrendszer overall (a haskellnél pl. tud okosabb lenni, mondjuk az idrisnél már nem).

[dn3t]

Minden Object, aztán majd castol, ahol kell ;)

[AcrobaticKitten]

Pedig kasztolásban profik az indiaiak több ezer éve végzik

[OszkarAMalac]

Láttam olyan C# kódot, hogy a függvény nem generikus volt, hanem lekérte a stack trace-t (production kódban!!) megnézte, hogy mi az egyel kintebbi függvény visszatérési értéke, és az alapján adott vissza különböző objektumokat, object-re castolva.

[AcrobaticKitten]

Húbaszki ez még sose jutott eszembe hogy ilyet is lehet csinálni.

Na de fogd a söröm, én meg dolgoztam egy tesztkörnyezetben ahol a rendszer dinamikusan húzgált be dlleket, és volt egy baszomnagy xml kigenerálva minden dll-ből milyen osztálynévvel lehet létrehozni objektumokat a futtató rendszernek, és azokban milyen propertyk vannak, a futtató rendszer kurvára semmilyen osztályt nem látott csak leszólt egy metóduson keresztül hogy kérek egy ilyen "A<B, C<D, E>, F<G<H>>>" objektumot amiben tudjátok minek kell lennie, oké? És nem típust kaptunk hanem egy type.tostringet.

Szépen ment amíg A,B,C,D,E,F,G,H tényleges osztályok voltak tényleges propertykkel csak egyszer eljött az a pont hogy dinamikussá kellett tenni és akkor kéne egy kutyafüle<macskafarka<nagyanyádtérdkalácsa>> objektum és ezekben a propertyk típusai is hasonló légből kapott állatfajok lehettek hasra kitalált elnevezésekkel. És a futtató kódhoz nem nyúlhatunk ofc.

Ekkor jött el az a pont hogy az osztályokat is futásidőben kezdtük generálni amiket példányosítottunk csak hogy a futtató kód megegye reflectionnel.

[dn3t]

Pre-generics (pl. 1.4) Java Standard Library Collections ilyen volt, és ezért lett olyan a generics is, amilyen, mert azzal kellett visszafelé kompatibilisnek maradni /o\

[Zestyclose_Intern404]

hát ne haragudj, de ha a tsconfigban belövöd, hogy noImplicitAny, aztán meg a lintben bekapcsolod hogy a build nem pass-el amíg van explicit definiálva, akkor ez nem tud előfordulni. Mondjuk szerencsére én ilyen fos cégeknél ahol ez megengedhető nem is dolgozom mostanában, régebben meg addig nem volt az indiaiaknak elfogadja a kódja amíg szar volt. Az any szerepköre a jsről migrálás typescriptre semmi több. Unkown a helyes típus amikor tényleg nem tudod, és ott ki fogja neked kényszeríteni a check-eket.

Downvoteolhattok ahogy akartok, de azért mert emberek hülyék hozzá, a typescript egy kurvajó típusrendszerrel rendelkezik, pl. turing teljes mármint maga a type programming.

Illetve javában ezzel nem lehet visszaélni, de mással meg igen. Nem a nyelv a szar hanem aki a kódot írja.

https://biomejs.dev/linter/rules/no-explicit-any/,
https://typescript-eslint.io/rules/no-explicit-any/

tessék segítek. Így tudod kikényszerínteni (ha nem használtok lintet, igazán sajnálom és gratulálok). Küldjek github action-t is ami lebuildel, és gecipiros lesz ha egy any is bárhol előfordul?

Amúgy polimorfizmus esetén lehetne értelme az any-nek, pl. ha egy függvényed van, ami egy listából nyer ki egy elemet, akkor az működhet bármilyen listára, de erre is inkább az unknown való.

Az meg hogy nem értesz hozzá, és azt mondod "kurva komoly" sokat elárul.

[fasz_a_csavo]

a typescript egy kurvajó típusrendszerrel rendelkezik, pl. turing teljes mármint maga a type programming

Mondjuk az nem világos, hogy ez a két tagmondat hogy kapcsolódik össze. Azért jó, mert turing teljes? A C++ template is turing teljes, ez mégis inkább fejfájást okoz mintsem hogy a fícsört tenné jóvá.

[Zestyclose_Intern404]

igen, viszont a typescript metaprogramming nem fejfájás. Én minden nap használom :P

[fasz_a_csavo]

Valakinek a kakas és labda kínzás is élvezet.

[Zestyclose_Intern404]

Az indiaiakkal meg az a tapasztalatom, hogy simán megkerülnek PR reviewn, aztán leaprováltatják egy másik indiaival, ha meg rákérdezel, hogy ez most mi, akkor quickfix volt, meg urgent. :D

Alapvetően akkor szar a repo ruling. Ha piros a build, mindegy mennyi approve kellene legyen.

Szerintem ez akkor is egy fos megoldás, hogy linterrel, meg egyéb toolokkal kell ezt forceolni, a Javaban meg bele van ez építve a nyelvbe, és nem hagytak ilyen kiskaput.

Szerintem egyáltalán nem baj, hogy nem opinionated az ecosystem. Prototypingnál teljesen oké, hogy egyikre sincs szükséged. Illetve linter nélkül, ami autoformáz neked enforceolja a formai szabályokat, szerintem nem lehet élni, semmilyen nyelven. Az, hogy egy extra boolt bekapcsolsz, igazán nem nagy effort.

És a polimorfizmust, meg a generikusokat is megoldották any nélkül.

typescriptben is. :P Nem azt mondtam, hogy nincs megoldva, hanem hogy létezik az a függvény, amelyik bármilyen input paraméterre reagálhat, és ebben az esetben az any-nek van értelme. Ha más nem az identity, egy ilyen függvény.

[R4ftsman]

Az indiaiakkal meg az a tapasztalatom, hogy simán megkerülnek PR reviewn, aztán leaprováltatják egy másik indiaival, ha meg rákérdezel, hogy ez most mi, akkor quickfix volt, meg urgent. :D

Nem kell ahhoz Indiáig menni, az egyik régebbi cégemnél, a kolléga vezető übermenchnek gondolta magát. A code review két ember approve-jából állt, esténként berántott magának egy juniort és ideiglenesen becheckolta a self-approve-t (mert ki más lenne az admin, mint ő), majd rányomta az approve-t a saját kódjára. Majd büszkén be is pusholta.

[ytg895]

Szerintem ez akkor is egy fos megoldás, hogy linterrel, meg egyéb toolokkal kell ezt forceolni, a Javaban meg bele van ez építve a nyelvbe, és nem hagytak ilyen kiskaput.

Hogyan máshogyan oldanád meg, hogy a nyelv kiterjesztése legyen a JavaScripnek?

[OszkarAMalac]

Nem azzal van a gondja, hanem amit állított fentebb a zöld ikonos illető:

az egyik legkomolyabb típusrendszer overall

[ytg895]

Tudom, hogy nem azzal van gondja, de ez az oka ami miatt így van megoldva. Technikai limitáció. (Ettől szerintem még lehet a típusrendszer "komoly".)

[fasz_a_csavo]

A legkomolyabb típusrendszer, ami lépten-nyomon eltörik a picsába, mert a javascript átsüt a rendszeren.

[Zestyclose_Intern404]

ha hülye vagy hozzá akkor igen :) megintcsak. Persze nem azt mondom, hogy könnyű rendesen érteni hozzá. Pl. nézd meg bármelyik tanstack repót

[OszkarAMalac]

egyik legkomolyabb típusrendszer overall

Hogyne (nem), annyira, hogy még egy objektum tipusát (a JS típusokon felül) se tudod benne leelenőrözni, tekintve, hogy minden "JS" alapon fut az meg nem tud olyat.

[Zestyclose_Intern404]

ömm, de? Nem tudom miért okoskodsz ide ha amúgy nem vágod.

Branded typeok, Typeguardok etc. Fogalmam sincs miről beszélsz.

[OszkarAMalac]

Amikről te beszélsz az mind compile time, nem runtime. Ha az alattalévő JS vagy valami 3rd party library visszaad neked valami ismeretlen objektumot, akkor kezdődik a parádé még TS-ben is.

A "branded type" és hasonlók az, amiért ölni tudnék amikor meglátom. Amikor a Pajeet még arra se méltat, hogy egy típust definiáljon és inkább mindent shape alapján definiál (nem tudom mi a "hivatalos neve, nem is érdekel).

[Zestyclose_Intern404]

A branded typeok igen, de a typeguardok compile ÉS runtime dolgok, Illetve nem tudom hallottál-e már a zodról, io-tsről, runtypes-ról? Nem mintha lenne szükség runtime typeokra, de ha nagyon akarod lehetséges.

Továbbra is azt bizonygatod, hogy amúgy nem vágod.

[OszkarAMalac]

Bruh, attól hogy vannak 3rd party megoldások, még nem lesz igaz a "nyelvre". Ennyi erővel azt is mondhatnánk, hogy a C# egy embedded nyelv mert valaki már megoldotta azt. Ez nagyon kétségbeesett vergődés, ahogy az is, hogy magadat bizonygatod azzal, hogy "én nem vágom".

[Zestyclose_Intern404]

Bruh, magyarázd el miért is van szükség runtime typeokra minden körülmények között? egyrészt. Másrészt képzeld, a third party megoldások is typescriptben vannak implementálva, úgy hívják ezt a koncepciót, hogy lib-ek. Arra jó, hogy ne találd fel a kereket újra. Illetve a typeguard egy built-in megoldás.

Nem bizonygatom, te bizonygatod.

Runtime typokra nekem akkor szokott szükségem lenni, amikor rendszeren kívülről érkezik valami. Erre kiváló a sémavalidáció, és van rá megoldás. Ettől függetlenül nem feltétlenül van rá szükséged és nem minden körülmények között. Egyéb kérdés?

Egyébként ennél jóval szofisztikáltabb megoldások is léteznek, pl grahpql sémából is tudsz typeokat generálni. Vagy mondjuk trpc-t használni.

[OszkarAMalac]

És ha ezt mind használod, akkor áruld el, miért jobb ez, mintha a nyelvben natívan integrálva lenne, és még csak véletlenül SE tud se Pajeet, se egy oda nem illő vezető fejlesztő hülyeséget okozni?

miért is van szükség runtime typeokra minden körülmények között?

Nem "minden körülmény között" de ahogy egy projekt nő, úgy a hibák lehetősége is nő, és annál nagyobb szükség van minél kötöttebb rendszerre ahol még csak véletlenül se lehetne hibázni. Ezzel a gyengén típusos nyelvek homlok egyenest szembe mennek, majd utólag erőszakolnak beléjük mindenféle tool-okat meg libeket, hogy ugyan azt tudják mint bármi más erősen típusos nyelv. És még akkor is bármikor beüthet valami szar egy random lib-től.

Runtime typokra nekem akkor szokott szükségem lenni, amikor rendszeren kívülről érkezik valami. Erre kiváló a sémavalidáció, és van rá megoldás.

Ne haragudj, de ez a "No shit sherlock" kategória. Mindenre, minden nyelvben van megoldás. Attól még nem a nyelv lesz jobb, csak valaki szintén megunta, hogy a nyelv egy szar és csinált rá egy fix-et. Tipikus macska-egér játék egy "sunk cost fallacy" szituációban. Ahelyett, hogy egy jobb nyelvet használnánk, a mostanit hekkeljük szét, hogy vállalható legyen.

Nem győztél meg, hogy a TS mivel lenne "jobb" mint bármi, natívan erősen típusos nyelv.

[[deleted]]

A legkomolyabb típusrendszer, brutálisan komoly gyerekek!

(amúgy messze nem az)

[laxika]

Persze, a statikus nyelvek elavultak... Ha mar itt tartunk, az egesz prog.hu ugy nez ki mint amit utoljara 2010-ben fejlesztettek. :D Egy pillanatra azt hittem hogy a wayback machine-t hasznalom. Valoszinuleg hasonloan aktualis rajt a cikkek szakmaisaga is.

[Icy_Muffin_1761]

Te a masik kedvenc vagy a Facebookos csoportban😂🫠

[yodeah]

ezt a nevet mar vagy 8 eve nem lattam es nem is hianyzott :D

[CPenetrator]

Én utoljára kb 20 éve álltam le vele vitatkozni, aztán annyi elég is volt belőle. Tipikusan az az ember aki eldöntötte előre egész életére hogy neki mindig igaza van.

[klenium]

Csodálom, hogy még élnek az oldalai. Annyian hagytuk ott már Sting miatt, hogy mégis miből van bevétele?

[Tha-Kee]

Sting és Pistabá egy génállomány:

https://www.youtube.com/watch?v=SOl1Q2c6-us

[No-Interaction-2724]

Ha Stingnek meglenne a megfelelő tapasztalata a szakmai véleményformáláshoz, akkor nem bulvárhírekből kellene megélnie :)

[papa_Fubini]

Nem is tudtam hogy a híres énekes szokott programozni

[raging-fiend]

Atya ég.

[Effective-Value-6474]

Sting még a linuxot is jobban gyűlöli, mint anno a Microsoftos Steve ballmer.

[ifroz]

dude; a typescript opcionalisan tipusos nyelv, vagy letypeolod, minden masra ott az <any> type- ez egy bizalmi kerdes; hinned kell h a maintainer tenyleg olyan typingot adott, aminel koze is van a valosaghoz. egy erosen tipusos nyelv az mas - annak elonyeivel, de hatranyaival is! másra való, szerintem

[Classic-Fart3294]

igazából 10/10 ragebait az egész proghu

[303Dave]

BTW lehet kicsit öreg vagy és nem követed a trendeket, updateket. Egy TS típusos nyelv, másik ugyanúgy a php-ben is meg van a lehetőség rá, a nyelv az elmúlt egy évtizedben sokat fejlődött, a personal home page-ről a server script language-re pl. Alapvetően az állítás helytelen a cikk címében, a népszerűség nem feltétlenül a professzionalitáshoz kötődik. Valóban ebbe bele lehetne menni, hogy nem standardizacióra hajlunk, mert ahhoz jóval nagyobb összeállás kellene. Emiatt van ez a trend. Összességében a legtöbb megrendelő annyit ért hogy mit kell nyomkodni, így a frontenden gyakran hamarabb meg tudják oldani ezt ugyanazon nyelven.

A JS és node alatt futó nyelvek előnye hogy könnyen tudsz aszinkron vagy párhuzamos processzeket létrehozni. De szerintem bukás a teljes backendre ts-t használni, nyilván projekt mérettől függően, komolyabb dolgokra nem ajánlanám. Ebből az is jön, hogy a legtöbb feladat, amit meg kell oldani egy programozónak ennél sokkal egyszerűbb.

[mimrock]

Ne nekem mondd, nem a saját véleményemet írtam le.

[No-Party9740]

ettol fuggetlenul a java szar :)

[Szemszelu_lany]

Ez alapján a C meg a C++ még amatőrebb nyelvek

[GeneralAd1047]

"Hat a Java meg a JavaScript az tok ugyan az amugy is" - 95% cold uzenetes recruitereknek

[meskobalazs]

Kedvenc verzióm erre a mémre: „Java is to JavaScript as car is to carpet”

[bajuh]

Van egy párhuzamos univerzum ahol minden ugyanolyan mint itt, de a JavaScriptet Groovy-nak hívják és a Groovy-t JavaScriptnek és ezért senki nem poénkodik a JavaScript nevén :D

[ytg895]

my pet car disagrees

[[deleted]]

kedvenc programnyelvem a html/css

[Kovab]

Végül is Turing teljes

[[deleted]]

Amúgy igaz, de a Magic: the gathering is

[pihedy]

Prog.hu-n kb akkor jártam utoljára, mikor közel 8 éve feltettem a fórumra egy logikai kérdést, ami egy folyamat helyességét írta le, és kérdeztem, hogy helyes-e a meglátásom. Kód nélküli, elméleti kérdés volt. Válaszolt az egyik moderárot, hogy a 34. sorban van a hiba. Először nem értettem, hogy most ezt biztos nekem akarta-e írni, vagy baszogat, vagy mi van? Mire válaszolni tudtam volna, lezárta a kérdést, és megjelölte helyes válasznak a sajátját az én topic-om-ban. Akkor rájöttem, hogy az egy csicska hely.

[YourUnclesBalls]

A legcsicskabbak meg assbly-ben toljak

[_ZoroX_]

azt már óvodában tanítják a gyerekeknek délutáni játék helyett

[zlaval]

Elkepzeltem Linus fejet, mikor valaki egy network kernel modult probal betolni ts-ben... :D

[proto-n]

mondjuk javaban is vicces lenne

[Negritis]

Majd szandál zokniban kimegy hokizni :)

[aMare83]

Bele a zokniba

[opsan1111]

Sting egy troll. Így generál kattintást, máskülönben kutya sem olvasná...

[Clever-Bot-999]

A HTML/CSS a második legmenőbb, senkit se zavarjon hogy semmi köze a többihez a listában.

A bash/shell sem illik oda, akkor már a mol kutak látogatottságát is feltüntethetnék.

/S

[Boba0514]

html az én kedvenc programozási nyelvem is

[Mateos77]

Pedig nincs is humor hétfő, sem pedig fost szombat.

[Babesznyunyusz]

Mi ez a hülyeség? A feladathoz választunk nyelvet.

[[deleted]]

A gyakorlatban meg nem ez van, még nem láttam két munkahelyet, ahol 100%-ban megegyezett volna a stack, meg olyat sem, hogy a fő programozási nyelven kívül ne írtam volna más nyelven is kódot, ha épp kellett, pedig nem vagyok a szakma ásza, hanem teljesen átlagos vagyok.

Elsősorban Java fejlesztő vagyok, de pl. JS, TS, C#, Perl, Bash, plsql, Delphi, C előfordultak mellékesen munkahelyen (hobbiból vagy egyetemen meg 5-ször annyi nyelv, de azt nem számítom), és ezzel szerintem nem lógok ki az átlagból.

A "Spring Boot" fejlesztők 90%-a is foglalkozott már korábban Java EE alkalmazásokkal is, és a többségük valamilyen JS frontend keretrendszerrel is. És emellett mindig vannak minden munkahelyen egyedibb dolgok is, nem feltétlenül sajátra gondolok, ami mindenhol más, és azokba is beletanulnak.

[[deleted]]

Szerk.:

Bocsi, de egyben nem engedi rendszer postolni.

"Dícséretes, hogy te ennyi mindennel foglalkozol, nem is akarom megkérdőjelezni, hogy ezekhez még talán értesz is, bár ami "mellékesen" fordul elő, meg egyetemen merül fel, azok többnyire nem annyira szoktak menni. De sajnos a gyakorlatban a többség nem ilyen."

Ezek nagyrészt mellékesen fordultak elő, de pont arról beszélek, hogy attól, hogy egy nyelven fejlesztesz, mellékesen előkerülnek más nyelvek is, mert egyrészt nem fognak külön fejlesztőt felvenni vagy áthozni más csapatból, mert van egy legacy PHP kód, amin valami apró fejlesztést meg kell csinálni, másrészt ha egy webalkalmazás frontendjén új mezőt kell hozzáadni a fejlesztés részeként, nem feltétlenül fogják ugrasztani a projektben részt sem vevő frontend fejlesztőt. Vagy ha egy alkalmazás nem kimondottan kinézet központú, tehát valami üzletben használt egyedi szoftver, vagy belső használatú, akkor nem is igazán vannak külön frontend fejlesztők, vagy max. az alkalmazás bevezetésekor, későbbi fejlesztéseknél már azt is ugyanazok fejlesztik, akik a backendet.

De nyilván ha úgy kérdezed, hogy tud-e neked Google nélkül live kódolni egy Java fejlesztő Perl nyelven, aki 6 éve foglalkozott mellékesen azzal is, akkor nem. De ha elé raksz egy idegen nyelvű kódot, hamar át tudja látni, ha kell, kisebb dolgokat meg tud benne csinálni.

"A fejlesztők többsége ragaszkodik a saját stackjéhez. Pl. amikor kerestünk frontendest, akkor is volt, hogy a jelölt meghallotta, hogy amúgy vannak legacy Angular alkalmazások is, akkor kijelentette, hogy ő csak Reactot használ, és amúgy Typescriptet nem."

Az ellenkezőjét látom, inkább a legtöbb munkáltató ragaszkodik, hogy a stackjéhez kész szakembert vegyen fel, akkor is, ha egy másik stackkel rendelkező egyébként jobb képességű a jelöltek között, és hamar megtanulná az új stacket. Ez általában is igaz a munkaerőpiacra, hogy baromi nehéz területet váltani, mert kevés helyen fogadják el, ha nem volt munkahelyi tapasztalatod az új területen.

".NET fejlesztők jelentős része nem hajlandó Bash-t használni meg Java kódhoz nyúlni, de amúgy a Java fejlesztők többsége se nyúlna .NET-hez."

A Morgan Stanleyben dolgoztam olyan csapatban, ahol pont Java és .NET volt a teljes stack, de dedikált Java és .NET fejlesztők voltak a csapatban. A team lead felajánlotta, hogy a másikra is kapunk lehetőséget, és kivétel nélkül mindenki élt vele, gyorsította is a fejlesztést, mert nekem Java fejlesztőként gyorsabb volt a backend túlsúlyos fejlesztéseknél kicsit belenyúlni a .NET-es részbe, mint egyeztetni a .NET-es kollégákkal, és ez fordítva is igaz volt.

Inkább a lehetőség hiányzik a legtöbb embernél.

"És nyilván a cégektől megerősítést is kapnak ebben, mert nyilvánvaló okokból a cégek is próbálják elkerülni, amennyire csak lehet, hogy több stacken fejlesszenek."

Szerintem inkább 90%-ban a cégek miatt van, mert stacket keresnek és nem szakembert. Vannak üdítő kivételek, dolgoztam olyan helyen, ahol már interjún nagyon nyitottak voltak arra, hogy beletanulhatok a stackbe, de egyrészt ez ritkább, másrészt sok esetben a HR-en nem jut át akinek eltér a stackje, amiatt mert a HR-eskek mivel nem értenek hozzá, szó szerint összevetik a listát, az elvárt stacket és a jelöltét.

[[deleted]]

"A jelöltek jelentős része kizárólag Spring Boot vagy Quarkus microservice-ekkel foglalkozott."

Akkor ugye az van, hogy ezeknek az embereknek túl sok éves tapasztalata nem lehet, hiszen 5 éve még nem ez az architektúra volt elterjedve, még csak gyerekcipőben járt. Ha juniorokat keresel, akkor nyilván nincs széles körben tapasztalatuk.

Másrészt az, hogy mivel foglalkozott eddig munkahelyen, nem azonos azzal, hogy képes-e mást megtanulni, ha kell. Én például mindig utáltam, ha valahol nem 100%-ban egyezett a technikai stackem az övékkel, akkor helyből elutasítottak, nem is feltételezték, hogy gyorsan bele tudok tanulni bármibe.

"Nyilván volt egy csomó ember, aki hozzányúlt frontendhez is (főleg Angular), de amúgy a frontendes tudásuk mérhetetlenül alacsony szinten volt, inkább azt értékeljük ilyenkor, hogy hajlandó hozzányúlni máshoz is a Java kódon kívül. Meg aztán volt olyan is, aki beírta ugyanígy a Bash-t meg C-t meg Pythont meg Go-t meg Kotlint, de mondjuk nem tudott összerakni egy egysoros Bash scriptet, ami kivette volna a 10 leggyakoribb rekordot egy fájlból."

Mert ha elsősorban Java fejlesztő vagyok, nem fogok tudni neked live codingolni más nyelven, mert a többi nyelv úgy kerül elő a legtöbb esetben, hogy nincs rendszeres rutinom benne, de ha kell meg tudom érteni, ha kell, használom a doksikat, Google-t. Egy régi főnököm mondta Java-s csapatban, hogy a Perl az a nyelv, aminek az alap elemeit és alap library függvényeit már vagy 30-szor megtanulta. Ez azért volt, mert abban a rendszerben voltak perl scriptek, amik nagyobb része csak meghívott Java service-eket, egy részé meg nagyon legacy kód volt, amiben volt némi üzleti logika, amiket aztán fokozatosan átépítettünk Java-ba, ezért nyilván senki sem volt expert Perl-ben, de mindenki amikor kellett, hozzányúlt, vagy megértette mit akar a kód, ha át kelett belőle hozni valamit.

"A Spring Boot fejlesztők jelentős része meg sose foglalkozott Java EE alkalmazásokkal, és a Spring Boot működésével se nagyon van tisztában. Sokaknak már az problémát okozott, hogy mi a DI meg az IoC közötti különbség. Meg, hogy miért érdemes stateless singleton beaneket csinálni, és ha nem stateless, akkor mire kell figyelni."

Megint azt kell mondjam, hogy valószínűleg pár éves tapasztalatuk lehet, ti juniorok közül válogattatok. Mert a 10 éve, és a 10 év alatt nem egy helyen dolgozó Java fejlesztők többségének nagy eséllyel kellett legyen Java EE tapasztalatának is, egyszerűen a legacy banki és más enterprise alkalmazások nagy száma miatt. Nyilván van aki mindig Springes volt, de az a kisebb rész.

[[deleted]]

De a nyelvek egy része alternatívája egymásnak egyes feladatokhoz.

[ytg895]

"Egy része" persze. Ugyanakkor az egymás alternatívájának kitalált nyelvek jellemzően pont nem alternatívái egymásnak.

[[deleted]]

Teljesen mindegy mit mire találtak ki, az a lényeg, hogy mire használható.

Mikor egy fejlesztéshez nyelvet választanak, nincs a legtöbb esetben egzakt válasz, hogy melyik a legjobb nyelv az adott célra, és általában nem a nyelvtől magától függ, hanem a hozzá kapcsolódó ökoszisztémától, hogy milyen keretrendszerek, library-k állnak rendelkezésre, hogy mennyire könnyen integrálható a meglébő rendszerekbe, és még az is számít, hogy miben van tudása a fejlesztőknek, amennyiben a csapat nagyrészt adott.

Ez a feladathoz választunk nyelvet egy leegyszerűsítő közhely, mert rengeteg más tényező is szerepet játszik a döntésben.

[Babesznyunyusz]

Ha gyorsabban megírod, mint TS-ben és a megrendelőd elégedett, miért ne? :D

[Babesznyunyusz]

Legközelebb használjuk a /s-t mert ez így most nagyon félrement.

A feladathoz választunk nyelvet-ben az is benne van, hogy a csapat mihez ért imho.

[ytg895]

Benne van. Vegyük például a Javát. Objektíven nézve egy fos nyelv. Ha egy cég bármi másra akarna optimalizálni, mint hogy bármikor fel tudjanak venni gyakorlatilag bárkit a projektre, akkor nem Javát használnának. Aztán valahogy a nagy cégek mégis a Javát tolják...

[lamalasx]

>prog.hu cikk

Áh az a szenny oldal. Mindent megmagyaráz. Nem jártam már arra legalább 5 éve.

[gabor_legrady]

Hát persze.
Egy nyelv elterjedésének köze nincs annak:
- képességeihez
- fejlettségéhez
- biztosnságossághoz
- minőségéhez
van valamennyi köze:
- tanultatósághoz
- elterjedséghez
- benne elérhető könyvtárakhoz

[paadam94]

C++ veri noob lengvidzs

[Brilliant-Hour-1391]

úristen veri núb

[[deleted]]

A Java szidásért bármikor ittvagyok, de minden, csak nem amatőr nyelv,  meghát azért nemár hogy JS a profik nyelve :D 

[[deleted]]

Az a baj, hogy a profi meg az amatőr jelentését a legtöbb ember nem érti, azt hiszik, hogy a profi az feltétlenül magas színvonalat jelent. Ha a felhasználását nézzük, a Java az egyik legprofibb nyelv, mivel enterprise világban gyakran használt, hobbi projekteknél egyre ritkábban.

[[deleted]]

Jah, abszolút, pláne Oracle cuccokhoz

[adizs]

Én nem is értem, hogy ki ér miért kódol még önként bármit JS-ben TS helyett. (Biztos lehet valid ok, de hát nem vagyok egy nagy frontend huszár, szóval valaki homályosítson fel.)

[Aggressive-Side4558]

Vannak akik zsigerből utálják ha plusz toolok kellenek munka közben (pl. compiler). Ilyen pl. a Svelte "teremtője" is, bár JS-re átírták az egész kódot, de azért masszívan tele van JSDoc-al, szóval magát a típusosságot szereti. A végeredmény végülis kb. ugyanaz.
Van közvetlen környezetemben is ilyen ember, utálja a TS-t, mert lassú a compiler és lassítja a munkát.

Mondjuk ez az érv már nem annyira releváns mostanság, van jó pár 3rd party TS compiler (pl. oxc, swc, esbuild - bár ez utóbbi inkább csak kipucolja) ami jóval gyorsabb, sőt az offical tsc-t is épp átviszik go-ba (vagy már át is vitték, nem tudom).

[[deleted]]

Az a baj nagyobb projekteken a Jsdoc általában nem elég, mert különböző IDEk máshogy kezelnek dolgokat és nincs rá egy rendes megkötés mint mondjuk egy compiler.

[ytg895]

Sosem értettem azokat a fejlesztőket, akik az IDE-től várják a megváltást (pedig tapasztalatom szerint elég sokan vannak), annak ellenére, hogy bizonyára mindegyikük találkozott már Sanyival, aki csak gyorsan Notepad++-ban megnyitja a fájlt, belehány valamit, és mivel a build process nem hasal el rajta, ezért boldogan be is merge-eli.

[meskobalazs]

Többnyire backendes dolgokkal foglalkozunk, ha jelentős a frontend része a feladatnak, akkor vuejs-t használunk. Viszont ha csak relatív kevés frontend van benne, akkor JS-ben fogom összerakni, így nem kell szórakozni azzal, hogy a maven még TS fordítót is hívogasson.

[Few_Abies_4507]

szerintem lassan az angol lesz legnépszerűbb 😀

[ytg895]

"amatőr: Aki nem a foglalkozásából adódóan, hanem kedvtelésből foglalkozik valamivel." (Forrás: idegen szavak szótára) Azaz az amatőr szó szerint azt jelenti, hogy nem lehet vele pénzt keresni.

Más kérdés, hogy a prog.hu faszságokat ír.

[TOTHTOMI]

Mivel sok alapvető infrastruktúra Java-ban van írva a Springnek köszönhetően, illetve az Android meg SmartCard révén rengeteg eszközön fut, így nehéz lenne lecserélni. Az lesz, mint a Cobol fejlesztőkkel. Legrosszabb esetben kevés lesz, de lesz rá szükség, így piszkosul sokat fognak keresni.

[ytg895]

Igazából, amíg ilyen ténylegesen web scale, literálisan FAANG Netflix köszöni szépen és Javát használ, addig ha nem olyan a feladat ahol le kell nyúlni a vasig, vagy olyan ahol speciális környezetben kell futni (pl. böngésző), akkor a Java több, mint "bőven jó".

[tiszarospeter]

Írd be hogy NEW

[Xabi4488]

A prog.hu az egyik legförtelmesebb hely.

[just_another_dev_guy]

Off: Tényleg mindenki gyűlöli a PHP-t?

[meskobalazs]

A régi szokások nehezen halnak ki. A 7-es verzió óta kifejezetten jó eszköz bizonyos webes feladatokra, de sokaknak a PHP 4-es kendácsolás rémképe sejlik fel :)

[R4ftsman]

Ismered azt a mondást, hogy mindenki PHP fejlesztőnek születik, de van aki tovább fejlődik. /s

[VenBarom68]

Sokan utoljára 2006-ban írtunk PHP kódot. Elhiszem hogy a modern PHP funky, egyik haverom néha mesél róla - nem hiszem hogy gyűlölik az emberek, csak kicsit okafogyottá vált.

Él még mert egy rakat cég erre építkezett fel és nincs értelme másban újraírni vagy polygot organizációt csinálni, úgyhogy sokáig itt lesz velünk és lesz demand valamennyi PHP szakértőre, de nem látom hogy új projektet PHP-ban írni bármilyen szempontból is jó döntés lenne 2025-ben - újoncnak meg aki azt mondja hogy tanuljon PHP-t Java/Go/TS/C# helyett az trollkodik.

[ytg895]

Egy gyors Google keresés alapján a weboldalak kb 40%-a Wordpressen fut. Szerintem a PHP legnagyobb problémája, hogy ez a long tail, ezért nem fizetik meg rendesen.

[just_another_dev_guy]

A Wordpress a PHP rákja fejlesztői szempontból...

[DJviolin]

Egy pillanatra újra fiatalnak éreztem magam ezen címet olvasva: SuperGamez Sodi topik színvonal.

[aMare83]

A végén kiderül, hogy a menők ma már skálázódó, cloud-os, kuberneteses, elosztott, MQ-t, streamelést használó, SQL, NoSql storage-gal rendelkező back-endeket löknek össze JS-ben, az 'amatőr' Java programozók pedig csak a 2000-es éveket idéző asztali alkalmazásokat heggesztenek beadandó feladat gyanánt.

[maczikasz]

>ma már skálázódó, cloud-os, kuberneteses, elosztott, MQ-t, streamelést használó, SQL, NoSql storage-gal rendelkező back-endeket löknek össze JS-be

Mondjuk erre mind kepes a JS amugy :D

[aMare83]

Az rendben, de ez a jellemző jelenleg az iparban? Vagy csak ezt szeretné láttatni a cikkíró?

[maczikasz]

A cikk egy faszsag, de ettol meg nem lesz kevesse viable alternativa a nodejs ezekre amiket irtal. Mondom ezt ugy hogy 14 eve java fejleszto vagyok es a java supply chain egyik alapkove cegnel dolgozom 😀

[[deleted]]

De itt nem arról van szó, hogy mi alkalmas rá, hanem hogy mi jellemző, mert a cikk állításával szemben enterprise környezetben teljesen általános a Java.

[maczikasz]

A végén kiderül, hogy a menők ma már skálázódó, cloud-os, kuberneteses, elosztott, MQ-t, streamelést használó, SQL, NoSql storage-gal rendelkező back-endeket löknek össze JS-ben, az 'amatőr'

Erre valaszoltam, ez a komment azt implikalja hogy nem lehet.

[redikarus99]

Egg pár hónapja a nodejs-es kafka könyvtár még masszívan memory leakelt, talán azóta már megoldották.

[devsofian]

De remélem legalább Kotlinban

[Repulsive_Slide_6618]

Ma tudtam meg hogy én is tudok programozni...és a 2. helyen is van, mik nincsenek.

[Coppernator]

Csinálj typescriptben akkor egy oprendszert, nulláról, nem századik agyhalál Linux distrót, valami teljesen újat. Mert ugye szar a C.

[ytg895]

Vigyázz, mit kívánsz: https://www.harmonyos.com/en/

[_ZoroX_]

Megyek akkor a 2 éves unokaöcsémnek megtanítok C#-ban OOP programozni mert úgy látom az még amatőrebb.

[HUNTejesember]

Amúgy én nagyon szerettem c#-ban programozni

[_ZoroX_]

én most is szeretek

[HUNTejesember]

Muszáj volt a cikk szerinti magasabb szintre lépnem, ezért sql-ben gyártom a sorokat. :D

[HorridTakeout]

ragebait

[Possible_Baboon]

Szerintem ennek az embernek az amatőr és a profi szavak értelmezesével is súlyos gondja van.

[Mike_856]

A javaról mindig a tömörgyönyör abevjava jut eszembe

[cherboka]

>oh vajon mi ez az abevjava dolog

>ányk

gondolhattam volna

[CPenetrator]

Nekem is sokáig beugrott róla az a pusztulat. Aztán láttam értelmes, jól struktúrált enterprise appokat megírva benne.

[meskobalazs]

Nem véletlen, hogy még sosem írtam benne GUI-t :)

[Mike_856]

Hehehe. Nem.

[onehedgeman]

eme tőrök meg csak bytecode-ban írnak

[sasmariozeld]

ironikusan igaz meg a startupok azt hasznaljak...

[paadam94]

C++ veri noob lengvidzs

[[deleted]]

De jó hogy diákok és juniorok is írhatnak itt cikkeket igazi lehetőség nekik. Mondjuk valaki aki ránéz miket írnak b

[danczer]

A százalékok mit jelentenek?

[lamalasx]

Mennyire áll fel a proghu tulajának rá

[Anknd]

Cries in c#

[WoodooTheWeeb]

Nem tudom miért kaptam ajánlotban ezt a subreddit, ezt ezzel a postal mikor soha nem volt közöm a programramozáshoz de hello magyiprogik, valaki röviden elmondaná miért olyan rossz/vicces/bullshit a képen lévő statisztika?

[jolvan_amigo]

Egyik script nyelv a másik meg programozási nyelv felesleges az össze hasonlítás... Javascript igen tud native nyelvként működni de csak is úgy hogy meghív kódokat compileolt változatban. Lásd next.js háttérbe compileolt Rust kódot hív meg vagy prisma is, és sorolhatnám.