Lambda szerkezetek, kifejezések, függvények
2017-07-02T21:50:27+02:00
2017-07-04T09:30:59+02:00
2022-07-21T12:26:54+02:00
  • Hali!

    A JavaScript meg a mai napig nem, úgyhogy nem csak a syntaxisa volt elmaradva, hanem a anon func viselkedése is a mai napig is használhatatlan, ha nem workaroundolunk helper függvénnyel.

    Biztosan?

    for(var i = 0; i < 10; i++) {let j = i; setTimeout(function() { console.log(j); }, 0); }
    Mutasd a teljes hozzászólást!
  • De. Te írtad tegnap 8:51-kor

    Tehát nem azt írtam, amit te két hozzászólással korábban állítottál, hogy írtam. Te nyilvánvalóan nem tudsz különbséget tenni az elégséges és a szükséges feltételek között.

    Nem kevertem össze semmit, csak nincs sok értelme egy olyan definíciónak, ami csak egyetlen nyelv XY feature-ére vonatkozik.

    Pontosan ezért nincs értelme a Java "() ->" és a JavaScript "() =>" operátorán/szerkezetén rugóznod, figyelmen kívül hagyva, hogy ezekkel összehasonlítható, illetve ezeket meghaladó funkcionalitást a JavaScript már előtte is kínált, csak más formában.

    Nem a fordító fordítja le a Java 8-as lambdákat anonymous classra, hanem a runtime.

    Egyrészt a kijelentésed értelmetlen, hiszen a runtime maga is egy fordító. Másrészt meg a syntacic sugar nem attól syntactic sugar, hogy ki vagy mi fordítja le, hanem attól, hogy (csak) amúgy más módon is leírható szerkezet, kifejezés vagy algoritmus ábrázolását teszi egyszerűbbé, de valódi új funkcionalitással és képességekkel nem vértezi fel a nyelvet.

    Egy nyelv fejlettsége nem csak a funkciógazdagságától függ.

    Rajtad kívül senki fel sem vetette ezt.

    22 éve meg tudjuk csinálni ugyanazt, csak különböző módon.

    Nem, Java-ban nem tudjuk. Egy osztály és objektum létrehozása és adatként/paraméterként történő átadása, felhasználása ugyanis nem "ugyanaz", mint egy függvény/metódus létrehozása és adatként/paraméterként történő átadása.

    Az ősidőkben külön új toplevel osztállyal, 1.2 óta anonymous classal, 8 óta lambda exprerssionnel. Ezért semmi elméleti jelentősége az egész lambdának

    A te "logikád" alapján pl. az Assembly is támogatja a lambda kifejezéseket, hiszen abban is lehet olyan kódot írni, ami pontosan azt csinálja, mint tetszőleges, Java-ban vagy JS-ben írt lambda kód. Nyilván ez a dolog nem így működik, illetve rajtad kívül senki nem ezt érti a nyelv képességein.

    Valamint a Java 19 éve támogatja a normális capturinget. A JavaScript meg a mai napig nem

    Egyrészt ezt nem capturingnek hívják, hanem elkerítésnek (enclosure), illetve a változók hatókörének (scope). Másrészt ennek semmi köze nincs a lambdákhoz - így érthetetlen miért rángatod ide. Harmadrészt nem igaz, hogy JavaScript-ben ne lehetne ezt úgy megvalósítani, ahogy te szeretnéd - csak te nyilvánvalóan nem ismered a nyelvet eléggé. Mert hogy még ES5-ben is meglehet:

    for(var i = 0;i<10;i++){setTimeout(function(i){console.log(i)}.bind(this,i), 0)}

    Nem mintha ne lenne eleve teljesen értelmetlen és dilettáns azt mondani, hogy egyik nyelv fejlettebb, mint a másik, mert egy, specifikus, általad kipécézett szerkezetet nem vagy nem úgy támogat, vagy az nem úgy viselkedik, mint ahogy te várnád vagy szeretnéd. Csak mondom.

    És akkor nézzük ekvivalens Java kódot, ami persze teljesen jól működik:

    Azt csak egy véramatőr gondolja, hogy egy nyelv működése attól lesz jó vagy rossz, hogy úgy működik, ahogy ő várja. Egy normális szakember meg tudja, hogy a nyelv jó vagy rosszságának ebben az értelemben egyetlen objektív mérőfoka az, hogy a specifikációinak megfelelően működik -e vagy sem.

    Nem mintha ennek megint _bármi_ köze lenne a lamdákhoz. Csak mondom.
    Mutasd a teljes hozzászólást!
  • Nem.

    De. Te írtad tegnap 8:51-kor: "A lambda meg kifejezetten a függvények/kifejezések adatként, paraméterként történő kezelését jelenti". Majd kifejtetted, hogy ezért nem számítanak szerinted az anonymous classok "lambdának".

     A két dolog csak a te fejedben keveredett össze, cserélődött ki.

    Nem kevertem össze semmit, csak nincs sok értelme egy olyan definíciónak, ami csak egyetlen nyelv XY feature-ére vonatkozik. 

    "syntactic sugar"

    Nem a fordító fordítja le a Java 8-as lambdákat anonymous classra, hanem a runtime. Pont ezért küldtem a linket arról az osztályról tegnap, ami egy lambda első használatakor legenerálja az anonymous classt. 

    nem jelöl ki funkcionalitást és képességeket, hanem csak egy jelsorozat. A lambda képességek nélküle is jelen lehetnek és lehetnek gazdagok egy nyelvben

    Egy nyelv fejlettsége nem csak a funkciógazdagságától függ. Ha így lenne, nem raknának újabban egyre több statikus nyelvbe type inference-t. 

    De nem azt mondtad, hogy a Java kódtömörség területén előzte meg a JavaScriptet, hanem azt, hogy a lambdák terén.

    22 éve meg tudjuk csinálni ugyanazt, csak különböző módon. Az ősidőkben külön új toplevel osztállyal, 1.2 óta anonymous classal, 8 óta lambda exprerssionnel. Ezért semmi elméleti jelentősége az egész lambdának, csak a produktivitást növeli. 

    Valamint a Java 19 éve támogatja a normális capturinget. A JavaScript meg a mai napig nem, úgyhogy nem csak a syntaxisa volt elmaradva, hanem a anon func viselkedése is a mai napig is használhatatlan, ha nem workaroundolunk helper függvénnyel. 

    for(var i = 0;i<10;i++){var j=i;setTimeout(function(){console.log(j)}, 0)}
    Ez ugye 10-szer kiírja, hogy 9. Aminek az ég világon semmi értelme, hogy miért az utolsó értékét nézi a variable-nek, miért nem a capturing-kori értékét. 

    És akkor nézzük ekvivalens Java kódot, ami persze teljesen jól működik: 

    jshell> import java.awt.EventQueue; jshell> for(int i=0;i<10;i++){int j=i; EventQueue.invokeLater(()-> ...> System.out.println(j));} 0 1 2 3 4 5 6 7 8 9
    Mutasd a teljes hozzászólást!
  • Tehát azt állítod, hogy attól számít valami "lambdának", hogy függvényként lehet hívni az azt tartalmazó változót/kifejezést.

    Nem.

    Csak éppen a Java 8-as lambdákat sem lehet függvényként hívni.

    De én nem is a Java 8 lambdákról, hanem a JavaScript függvényekről beszéltem. A két dolog csak a te fejedben keveredett össze, cserélődött ki.

    Azok ugyanúgy egy interface-t implementáló osztállyá fordítódnak le

    Ezért ún. "syntactic sugar" ez a szerkezet, nem pedig a lambda koncepció fejlettségét jelentő valami. És ezért mondom, hogy ezen operátor/token/szerkezet jelenléte egy nyelvben nem a fejlettségének meghatározója a lambdák vonatkozásában.

    Úgyhogy a te logikád alapján nem hívhatnánk lambdának azt

    Nem, ez a te "logikádból" következik. Nem abból, amit én mondtam.

    A címben nem szerepel, de rögtön a cikk 1. sorában ott van a cím ismétlése után zárojelben a szinonimáknál, hogy "lambda".

    Igen. És benne van az is, mindjárt harmadik szóként, hogy "computer". Ennek ellenére nem a számítógép definícióját adja. Éppen úgy, ahogy azért, mert benne van, hogy "lambda", nem annak a definícióját adja. De ha azt adná, az se jelentené azt, hogy a te értelmezésedet erősítené meg. Ezek a te tévedéseid. Ezt mondtam el az előbb is.

    Nem is mondta ezt senki sem.

    Nem is mondta senki, hogy bárki ezt mondta volna.

    Miért ne jelentene?

    Mert a "=>" vagy a "->" nem jelöl ki funkcionalitást és képességeket, hanem csak egy jelsorozat. A lambda képességek nélküle is jelen lehetnek és lehetnek gazdagok egy nyelvben, és a szóban forgó operátorok megléte mellett sem kell, hogy jelen legyenek, vagy ha jelen is vannak, lehetnek szegényesek és korlátozottak.

    Sokkal tömörebb lesz a kód

    De nem azt mondtad, hogy a Java kódtömörség területén előzte meg a JavaScriptet, hanem azt, hogy a lambdák terén. Nem mintha a "() -> { }" érdemileg rövidebb lenne a "function() { }"-nél, és nem mintha a két dolog - a korábban már írtak miatt - direktbe összevethető lenne. Csak mondom.
    Mutasd a teljes hozzászólást!
  • ezeket a referenciákat függvényként is hívhatod, használhatod, Java-ban viszont nem

    Tehát azt állítod, hogy attól számít valami "lambdának", hogy függvényként lehet hívni az azt tartalmazó változót/kifejezést. Csak éppen a Java 8-as lambdákat sem lehet függvényként hívni. Azok ugyanúgy egy interface-t implementáló osztállyá fordítódnak le.  Úgyhogy a te logikád alapján nem hívhatnánk lambdának azt, amit több százezer fejlesztő nevez Lambdának. 

    a Wikipedia szócikknek nem is lambda, hanem "anonymous functions" a címe

    A címben nem szerepel, de rögtön a cikk 1. sorában ott van a cím ismétlése után zárojelben a szinonimáknál, hogy "lambda". 

    Mert hogy ti. a "nyílszintaxis" jelenléte nem szükséges feltétele a "lambdák" támogatásának

    Nem is mondta ezt senki sem. 

    nem jelent semmiféle fejlettségi fokot ezen a téren

    Miért ne jelentene? Sokkal tömörebb lesz a kód, nem véletlenül rakták bele C#-be, Javába, ES6-ba is.
    Mutasd a teljes hozzászólást!
  • Ahogy a JS névtelen függvényei is objektumreferenciák:

    Nem objektumreferenciák, hanem objektumreferenciák _is_. Nagy különbség. JS-ben ezeket a referenciákat függvényként is hívhatod, használhatod, Java-ban viszont nem.

    Ezek alapján már szerinted nem számítanak lambdának a JS anonymous functionjei.

    Szerinted.

    Szóval akkor a Wikipédia és a StackOverflow top válasza is téved

    Nem, itt csak te tévedsz, sorozatosan. Pl. most is. Hiszen a Wikipedia szócikknek nem is lambda, hanem "anonymous functions" a címe, és - veled szemben - nem tesz egyenlőségjelet a két fogalom közé. A StackOverflow pedig egyszerűen a megfelelő szócikket linkeli, ami szintén nem tesz egyenlőségjelet a kettő közé.

    Annyit írtam, hogy a Java "megelőzte a JavaScriptet lambdák terén". Mert előbb jelent meg a nyílszintakszis Javában

    Éppen ezért nem igaz, amit írtál. Mert hogy ti. a "nyílszintaxis" jelenléte nem szükséges feltétele a "lambdák" támogatásának, és nem jelent semmiféle fejlettségi fokot ezen a téren. Így a nyílszintaxis megjelenése (vagy puszta jelenléte) sem jelent semmiféle elsőbbséget, fejlettebbséget.

    A Java és a JavaScript általad itt valamiféleképpen párba állítani gondolt szerkezete sem alakilag, sem koncepcionálisan, sem sehogy másként nem azonos - ezért is értelmetlen párba állítani őket. A helyzet tehát az, hogy a Java még mindig nem tudja azt, amit a JavaScript - és a JavaScript még mindig nem tudja azt, amit a Java. Viszont a JavaScript-ben egyértelműbben előbb lehetett a lambda koncepciót (és anonim függvényeket) használni, mint Java-ban.
    Mutasd a teljes hozzászólást!
  •  a Java anonim osztályai esetében szó sincs, hiszen ott az adat/paraméter módjára kezelt dolog az objektumreferencia

    Ahogy a JS névtelen függvényei is objektumreferenciák:

    (function(){} instanceof Object) == true
    Ezek alapján már szerinted nem számítanak lambdának a JS anonymous functionjei.  

    Egyrészt de, pontosan az adatként kezelhetőség a lambda jelleg definíciója

    Szóval akkor a Wikipédia és a StackOverflow top válasza is téved, neked viszont nyilván igazad van.

    Ezt úgy írod, mint ha nem azt mondtad volna, hogy a Java 8 előbb tudta volna a lambda-t, mint a JavaScript.

    Annyit írtam, hogy a Java "megelőzte a JavaScriptet lambdák terén". Mert előbb jelent meg a nyílszintakszis Javában, mint JavaScriptben. Nem írtam olyat, hogy előbb volt "lambda" Java-ban, mint JS-ben.
    Mutasd a teljes hozzászólást!
  • Valaki ezt úgy jelzi, hogy "offtopik", én meg úgy jeleztem, hogy "amúgy". Mi ezzel a baj?
    Mutasd a teljes hozzászólást!
  • Ahogy a Javában is mindig volt "anonymous class" az elmúlt 19 évben.

    Ami senkit nem érdekel, mert nem az anonim/belső osztályokról, hanem a "lambdák"-ról beszéltél. A lambda meg kifejezetten a függvények/kifejezések adatként, paraméterként történő kezelését jelenti - amiről a Java anonim osztályai esetében szó sincs, hiszen ott az adat/paraméter módjára kezelt dolog az objektumreferencia.

    Nem egészen ez a definíció: Anonymous function - Wikipedia

    Egyrészt de, pontosan az adatként kezelhetőség a lambda jelleg definíciója; az anonimság csak egy tipikus és praktikus velejárója, de nem szükségszerű jellemzője neki.  Másrészt ha nem így lenne, akkor is igaz lenne, hogy a JavaScript - állításoddal szemben - nem, hogy előbb, de évtizedekkel előbb tudta "lambda"-t, illetve az anonim függvényeknek a Wikipedia-ban leírt definícióját (is), mint a Java.

    Ezt úgy írod, mintha a Java 8-as lambda support nem ugyanezért lenne.

    Ezt úgy írod, mint ha nem azt mondtad volna, hogy a Java 8 előbb tudta volna a lambda-t, mint a JavaScript.


    Ennek már megint mi köze van a témához és mennyiben cáfolja akár azt, hogy a JavaScript előbb tudta a lamda-t, mint a Java, akár azt, hogy nem arról beszéltél, amiről LC írt?
    Mutasd a teljes hozzászólást!
  • Hali!


    Ezzel „amúgy” mit szerettél volna megmagyarázni? Mert azt nem sikerült, hogy egy „nem-javascript vs java” hozzászólásra „javascript vs java” posztot sikerült nyomatnod (ráadásul, a témához sem kapcsolódik, a JS-vonalat te hoztad be). Persze, a görögdinnye nagyobb, mint a sárgadinnye, ám a körte mennyivel finomabb. 

    Mutasd a teljes hozzászólást!
  • A "lambda" - [...] - függvényeket a JavaScript mindig is tudta.

    Ahogy a Javában is mindig volt "anonymous class" az elmúlt 19 évben. 

    tehát adatként kezelhető

    Nem egészen ez a definíció: Anonymous function - Wikipedia

    az nem a lambda függvények koncepcióját vezeti be a JavaScript-be, hanem csak egy szintaktikailag egyszerűbb és rövidebb deklarálási lehetőségét biztosítja azoknak, ráadásul bizonyos korlátokkal.

    Ezt úgy írod, mintha a Java 8-as lambda support nem ugyanezért lenne.

    Nem mintha LC arról beszélt volna, hogy a Java hol tart a JavaScript-hez képest, hanem arról, hogy a Java hol tart a C#-hoz képest. 

    Lásd 4. pont itt: A magyar nyelv értelmező szótára
    Mutasd a teljes hozzászólást!
  • 2014 márciusában jelent meg a Java 8. Amivel amúgy több, mint egy évvel megelőzték az agyonhájpolt JavaScriptet lambdák terén.

    Eléggé el vagy tévedve. A "lambda" - tehát adatként kezelhető - függvényeket a JavaScript mindig is tudta. Sőt, ezt igazából funkcionális szempontból minden olyan nyelv tudja, ami támogat valamiféle eval()-szerű függvényt. Bár a JavaScript deklaratív szinten is már régóta tudta, tudja.

    Te talán az "arrow function"-ökre gondolhatsz, de az nem a lambda függvények koncepcióját vezeti be a JavaScript-be, hanem csak egy szintaktikailag egyszerűbb és rövidebb deklarálási lehetőségét biztosítja azoknak, ráadásul bizonyos korlátokkal.

    Nem mintha LC arról beszélt volna, hogy a Java hol tart a JavaScript-hez képest, hanem arról, hogy a Java hol tart a C#-hoz képest. Csak mondom.
    Mutasd a teljes hozzászólást!
  • lambdát már csak valamikor 1015 magasságába

    2014 márciusában jelent meg a Java 8. Amivel amúgy több, mint egy évvel megelőzték az agyonhájpolt JavaScriptet lambdák terén.

    Ez a hozzászólás és a rá adott válaszok a moderátor által lett átmozgatva a(z) "Gyorsabb kódot generál majd a következő .NET Framework és .NET Core" témából.
    Mutasd a teljes hozzászólást!
abcd