Napi humor: Mi a különbség a Java és a JavaScript között?
2020-07-23T10:30:31+02:00
2020-08-21T16:28:08+02:00
2022-07-20T13:56:54+02:00
  • Pár évvel ezelőtt én is pontosvessző nélkül írtam a JS programokat. Viszont a nagyvállalati környezet ránevelt, hogy ne hagyjam ki, ami nem jelenti, hogy minden esetben kirakom - nem állítok be linter-t rá, hogy ellenőrizze. Ugyanakkor ezzel is jelzem, hogy átgondoltam a sort. Szerencsére nekem sokkal több minden tetszik a js-ben, például az objekt meg a function megvalósítása, az újdonságok közül pedig: arrow, decoupling, generator.
    Mutasd a teljes hozzászólást!
  • Pedig nekem az egyetlen dolog, ami tetszett volna a JavaScriptben, az, hogy nem kell kitenni a pontosvesszőket. Ezek szerint ez csak illúzió volt...
    Mutasd a teljes hozzászólást!
  • JavaScript alatt nekem az volt a legnagyobb fejvakarás, mikor JS engine-t változtattunk a kód alatt (nem böngészőben futott) és működni, működött, de bizonyos esetekben furcsa dolgokat csinált. Hibaüzenet persze nem volt.
    A nagy vizsgálat után az lett a válasz, hogy a kódban nincsenek a pontos vesszők kirakva és az új engine nem ott gondolja az utasításvégeket, mint a régi.
    Mutasd a teljes hozzászólást!
  • Lenti return-os részt elég érdekesen tördelted.

    const Foo = ({data}) => ( <section> <p>{data}</p> </section> );

    az arrow functionnál is ugyanez a helyzet és react / JSX -ben elég gyakori hogy zárójelet használok (itt az arrow után felejthető a return kiírása) hogy utána szépen tördelhessem a JSX részt.

    Ettől még a js eléggé jól kialakult nyelv, persze van benne érdekesség nem is kevés, cserébe viszont például pipeline operátort is használhatsz, ami még csak proposal és nem is része a nyelvnek, ugyanakkor hasznos.
    Mutasd a teljes hozzászólást!
  • Gratulálunk a helyes megfejtőnek. :)

    Biztos van, akinek a js fenti (lenti?) viselkedése tetszik.

    Én elég sokat vakartam a fejem egy hasonló helyzetben, hogy hová lett a visszatérési értékem.
    Mutasd a teljes hozzászólást!
  • A pontosvessző kirakása ugye opcionális JS-ben. A sortörés is jelenthet utasításvéget. A return utáni sortörés (utasításvég) pedig pont értelmes.

    Igazából ezt írtad le:

    function fact(n){ if ( 1 >= n ) { return 1; } else { return undefined; } n*fact(n-1); }
    Ennél ínyencebb dolgok is vannak azért JS-ben.
    Mutasd a teljes hozzászólást!
  • Még egy érdekesség a javascript topikba, ínyenceknek:

    Az alábbi törzsű, (mondjuk fakt nevű) függvény:

    if ( 1 >= n ) return 1 ; else return n*fakt(n-1);
    c-ben, c++-ban, java-ban, pici módosítással php-ben, és valószínűleg még egy tucat c-szerű nyelvben a fakt(5) hívásra 120-at ad eredményül. Vajon mennyit ad javascript-ben?
    Mutasd a teljes hozzászólást!
  • vhúúúúúzsszszszzszs

    Ez a vicc hangja ahogy elszáll a fejed felett
    Mutasd a teljes hozzászólást!
  • tény, hogy ezek léteznek. azt a kérdést kell feltenni, hogy miért léteznek, mi célból vannak? az erre adandó válasz mély következtetésekhez vezethet.
    Mutasd a teljes hozzászólást!
  • Meg kérdezhetem hogy ezt hogy érted?
    Mutasd a teljes hozzászólást!
  • html css javascript
    Mutasd a teljes hozzászólást!
  • Viszont én már várok a microsoftra hogy készítse el a windows-t wasm-ra. Aztán csinálhatunk frontendet winformsban, .Net Framework-el
    Mutasd a teljes hozzászólást!
  • A linux nem menő, mert nem mikrokerneles. Hogy lehet ilyen múlt századi, monolitikus, kicsit sem trendi dolgot szeretni?!
    Mutasd a teljes hozzászólást!
  • Én már várom hogy ki fogja portolni a linuxot webassemblyre
    Mutasd a teljes hozzászólást!
  • csakis!
    Mutasd a teljes hozzászólást!
  • De a szimfonyt is a böngészőbe lerántva, webassembly libként :D
    Mutasd a teljes hozzászólást!
  • szerintem erre minimum angulart vagy szimfony keretrendszert illik használni, így 2020 közepén ,-)
    Mutasd a teljes hozzászólást!
  • Jó, de a webassemly korszakában már annak sincs akadálya, hogy ezeket a hasznos fícsőröket java nyelven implementálják. :D
    Mutasd a teljes hozzászólást!
  • névnapokat is remekül meg lehet vele jeleníteni a weblapunk fejlécében, azért ezt a fontos fícsört se felejtsük el megemlíteni ))
    Mutasd a teljes hozzászólást!
  • Tetszett
    Mutasd a teljes hozzászólást!
  • Nagyon ne foglalkozz vele szerintem. A Java-t is a listába rakta annak ellenére, hogy teljes értékű lefelé kompatibilitással rendelkezik. A 2002-ben írt 1.4-es kód is működött 2 hónapja a legfrissebb Java-val nekem.
    Mutasd a teljes hozzászólást!
  • Javíts ki ha tévedek, de Go éppen arról híres, hogy tartja a visszafele kompatabilitást. Szóval ami lefordult és működött 1.0-ban az 1.14-ben is fog. Ezt ha jól tudom eddig sikerült is betartani.
    Mutasd a teljes hozzászólást!
  • Én kijavítanám erre:



    *the other is a scripting language designed to be able to simulate snowfall on your website.
    Mutasd a teljes hozzászólást!
  • Mintha már olvastam volna korábban :) Meg is találtam: Napi humor: Mi a különbség a Java és a JavaScript között?
    Mutasd a teljes hozzászólást!
  • Én sem.

    De, te konkrétan egy linket küldtél egy olyan issue-ra, melyben a GraalVM mellé adott node.js-implementáció indulási sebességére panaszkodnak. Lehet, hogy az "implementációjukról" szó végén lévő "-juk" toldalékot nem vetted észre, és azt hitted, hogy az "implementációjáról" szót írtam helyette. 

    Tehát még azt se tudod, hogy a Node.js alatt is alapból a V8 tevékenykedik, amiről beszéltél.

    De, tudom. És tudtam sok évvel ezelőtt is. 

    Nem, ez csak egy újabb kísérlet a gólvonal mozgatásra

    Nem, ez csak a reakcióm volt arra, hogy te valahogy szereted kiragadni a startup / warmup sebességet, a peak performance-ról megfeledkezve. 

    nem tudhatod mennyit költött rá

    Igen, erre utaltam én is: "a pontos emberévek számát nem tudjuk."

    még tipped sem lehet rá

    De. A 2 git repó méretének arányából (amiben ugye benne van az eddigi összes commit diffje) becsültem az 5-szörös szorzót.

    Másrészt nyílt forrású szoftverek esetén költésről értelmetlen beszélni

    Attól még, hogy nyílt forrású, a változtatások túlnyomó többségét a Google/Oracle fizetett alkalmazottai végezték az illető projektekben. 

    Rajtad kívül senkinek nem tűntek annak.

    Nekem úgy tűnt, hogy neked annak tűnt.
    Mutasd a teljes hozzászólást!
  • Egyrészt én nem a node.js implementációjukról beszéltem

    Én sem.

    mint amiről ez az issue szól, hanem magáról a JS motorról

    Tehát még azt se tudod, hogy a Node.js alatt is alapból a V8 tevékenykedik, amiről beszéltél.

    másrészt "teljesítmény" alatt ilyen szövegkörnyezetben alapértelmezetten peak performance-t értünk. 

    Nem, ez csak egy újabb kísérlet a gólvonal mozgatásra, meg a nem igazi skótozásra. Ehhez képest az, hogy még módosított formájában sem igaz az állítás, csak ráadás.

    Igen, bár a pontos emberévek számát nem tudjuk. De mennyit költött a Google a V8-ra? Kb. 5-ször annyit.

    Egyrészt ez nyilván egy totális hasszám, hiszen nem tudhatod mennyit költött rá, és még tipped sem lehet rá. Másrészt nyílt forrású szoftverek esetén költésről értelmetlen beszélni, és önmagában semmire sem jó, még akkor sem, ha rendelkezésre áll tényadat róla - mert hogy azoknál a pénz definíció szerint az összes erőfeszítések csak egy, önmagában is ismeretlen részének lehet a fokmérője.

    Harmadszor pedig, és ez a legfontosabb: tök mindegy is, hogy a Google a V8-ra mennyit költött, vagy ez hogyan arányul ahhoz, amire amennyit az Oracle költött a GraalVM-re (amiről én is bármikor mondhatom legalább annyira megalapozottan, mint amennyire te az 5x-ös számot, hogy 50x, 500x vagy 5 milliószor annyit költött rá), mert a lényeg az, hogy már az eredeti alapállításod sem volt igaz a sebességekről sem.

    Amely megállapítás persze megint irreleváns lett volna akkor is ha nem lett volna totálisan hamis, mert akkor se lett volna semmi köze se ahhoz, hogy hány implementációs bug van a Java és a JS fordítókban futtatókörnyezetekben, se ahhoz hogy az implementációs bugoknak semmi közük az implementációk közötti nem bug jellegű eltérésekhez.

    Ezért utaltam rá az előbb, hogy nem olyan szenzációs, egyedülálló, innovatív termékek a böngészőben lévő JS fordítók, mint amilyennek tűnnek elsőre.

    Rajtad kívül senkinek nem tűntek annak. Igaz, rajtad kívül senki nem is keverte össze az implementációs bugokat az implementációk közötti, a specifikációt nem sértő eltérésekkel.

    Persze ott van a startup / warmup teljesítményprobléma, de nem hinném hogy az eddigi összes munkaidejükhöz hasonló mennyiségű munka lenne a startup time megoldása.

    Na, megint egy tök értelmetlen terelési kísérlet valami tök irreleváns témára....
    Mutasd a teljes hozzászólást!
  • "C-s könyvtárak (de C++, Java, C# könyvtárak is ugyanúgy) napjainkban,"
    No de kérlek, ekkora csúsztatást!

    Egy nyelvnek illik kompatibilisnek maradnia a korábbi verziókkal.

    Egyrészt még az általad kiragadott félmondatban sem a nyelvről (hanem könyvtárakról) van szó. Másrészt a mondat nem is állít semmit, lévén úgy vágtad meg, hogy minden állítmányt kihagytál belőle - így értelmetlen, illetve konkrétan hamis azt állítani róla, hogy csúsztat. Már itt totál bukta a közbeszólásod.

    De ha bedobdtad a nyelv és annak kompatibilitisnak maradása témáját pl. a C/C++ kapcsán, akkor hadd mutassalak be téged egy számodra nyilvánvalóan eddig tök ismeretlen dolognak:

    Pragma directives and the __pragma keyword

    hogy csak a legalapvetőbb olyan dolgot említsem, amivel még/már a forrás szintjén is állandóan igazgatni kellett a C/C++ fordítók értelmezéseit egymás, illetve a nyelvi verziók között - mert hogy azok éppen olyan vagy még nagyobb eltéréseket mutattak egymás között, mint a JS értelmezők. Másrészt a pragma egyben egy tökéletes példa egy olyan nyelvi elemre is, amiről saját magáról is elmondható, hogy mind történelmileg, mind fordítók között nem volt egységes, és változott a szintaxisa, működése. Szóval ez a lehető leg-"metább" példa a specifikáció által megengedett (vagy akár attól függetlenül is, pusztán történelmi okoknál fogva kialakult) implementációs eltérések problémájára, ami ugyanakkor nem hogy nem csak a JS-t sújtotta és sújtja, de mint látható gyakorlatilag minden nyelvet, eszközt, platformot, és gyakran még sokkal jobban is, mint előbbit.

    Persze húznak rá újabb rétegeket, újy osztályokat vezetnek be a régi (de kompatibilis!) kód meg deprecated.... 'oszt annyi.

    A "deprecated" szerkezetek is azért lesznek "deprecated"-ek, mert a végső cél a támogatásuk eltávolítása a nyelvből. Ami rendszeresen meg is történik. Lásd pl: gets, gets_s - cppreference.com
    Mutasd a teljes hozzászólást!
  • Egy nyelvnek illik kompatibilisnek maradnia a korábbi verziókkal.

    Akkor a Python, Java, Go, Rust, D stb. kevesbe illedelmes nyelvek... :D
    Mutasd a teljes hozzászólást!
  • C-s könyvtárak (de C++, Java, C# könyvtárak is ugyanúgy) napjainkban,

    No de kérlek, ekkora csúsztatást!

    Egy nyelvnek illik kompatibilisnek maradnia a korábbi verziókkal.
    Mégha azok a korábbi verziók problémásak is voltak.
    Persze húznak rá újabb rétegeket, újy osztályokat vezetnek be a régi (de kompatibilis!) kód meg deprecated.... 'oszt annyi.

    De egy vadi új nyelv (akkori tervben scriptnyelv, szigorúan alapok és korlátok nélkül, kis igénnyel, kevés nyelvi elemmel semmi megkötéssel)... ezt kérem -akárhogy csavarod- eltervezték, összecsapták. Igaz nem is volt nagy cél vele, és ez nagyon is látszik.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd