JS WTF

Néha egyszerűen nem fogom fel, hogy miféle logika szerint működik a JS...

Adott a következő függvény:

function blacklisted(hostname)
{
	var spl, ret, hn;

	spl = hostname.split(".");
	if (spl.length >= 2)
	{
		hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
		ret =
			(hn == "x.com") ||
			(hn == "y.com") ||
			(hn == "z.com")
		;
		return ret;
	}
	else
	{
		return false;
	}
}

Ez így tökéletesen működik. Ha viszont kiveszem a ret változót:

function blacklisted(hostname)
{
	var spl, hn;

	spl = hostname.split(".");
	if (spl.length >= 2)
	{
		hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
		return
			(hn == "x.com") ||
			(hn == "y.com") ||
			(hn == "z.com")
		;
	}
	else
	{
		return false;
	}
}

Akkor undefined-et ad vissza! Úgy, hogy ha belül kialertelem azt amit vissza kell adnia, akkor az stimmel! Tehát belül még jó, de mire visszatér, nem jó! Több, mint egy órám ráment erre, mire rájöttem, de csak arra jöttem rá, hogy így működik, arra nem, hogy miért, hiszen működnie kellene külön visszatérési változó nélkül is...

Rated: WTF?!

Természetesen a gugliban csak olyan esetet lehet találni, hogy lehagyta a delikvens a return-t a függvényből; hát úgy persze, hogy undefined, de itt nem volt lehagyva...

Röhögni fogsz: miután elhúztam aludni, az álmatlan fetrengés közepette beugrott, hogy oké, zárójel az volt, de lehet, hogy az a baja, hogy nem ugyanabban a sorban nyitottam meg, mint ahol a return van? És tényleg... :)))
Köszi a linket; erre nem hiszem, hogy rájöttem volna, mert ez kb. a logika teljes hiánya, hogy egy nyelv önhatalmúlag szúrkodjon be utasításlezárásokat oda, ahova épp akar és hogy a helyes végrehajtás egy semleges területen lévő - elméletileg szabadon mozgatható - zárójel függőleges pozíciójától függjön. (De már az is fail, hogy egyáltalán zárójelbe kell rakni.) Plusz egy érv, amikor majd kérdezik tőlem, hogy miért utálom a JS-t...

Oldschool Computer - http://oscomp.hu

Sok furcsaság van a JS-ben, de ez a viselkedés azért még a könnyebben indokolhatóak között van. Megjegyzem azért, hogy a kedvenc nyelvem a Python, ahol ugye szignifikáns az indentálás és nincs sorvégi pontosvessző. Szóval szerintem a problémádat is az okozta, hogy a JS-ben opcionális a sorvégi pontosvessző és a JS közösség mai napig nem tudott megállapodni abban, hogy ki illik-e rakni, vagy sem. Te még a hagyományos stílust követed; becsülettel kiraktad mindenhova a pontosvesszőt. Régen én is kiraktam mindenhova, aztán idővel lustaságból elhagytam (illetve megszoktam, hogy Pythonban se rakok). Pontosvessző nélküli stílusnál egyből feltűnt volna, hogy hopp, itt egy speciális 'return' kifejezés, ami gyakorlatban 'return;'-t jelent az értelmező számára, mivel egy önmagában is megálló szintaktikai elem. A 'ret =' sornál ott az egyenlőségjel, amivel jelzed, hogy nincs lezárva még a sor.

Pythonban egyébként gyakran használom hasonló célra a zárójeleket, hogy több soros kifejezéseket írjak [pl. több soros hosszú from ... import (valami1, valami2)], mert jobb szeretem, mint a \ jeles szintaktikát.

Jó, csak a Pythonnak saját szintaxisa van, a JS meg a C/C++-tól örökölte a sajátját, a vezérlőszerkezetektől elkezdve az alap szemantikáig mindent, többek között a multi-line utasításokat és az egyes utasításokat lezáró pontosvesszőt is (azaz: milyen "sorvégekről" is beszélünk, ha az utasítások többsorosak lehetnek és külön jelezni kell a végüket?) és arra pakolta rá a maga vackait, tehát egy ilyen szerkezet esetén az embernek eszébe se jut, hogy a nyelv majd magától odaképzel (jajj...) egy vezérlő írásjelet. És ha odaképzeli, akkor tulajdonképpen le is szögezhetjük, hogy tkp. kötelező az, hisz a nyelv maga rakja oda, ha nincs ott, csak még ezt is bénán - értsd: inkonzisztensen - csinálja.
Miért? Mert a return után az interpreter ugyanúgy kifejezést vár, ahogy a zárójel és az egyenlőségjel után is, ennek megfelelően az egyetlen hely, ahová józan paraszti ésszel "beinjektálhatna" egy pontosvesszőt, az a legközelebbi nyitópár nélküli blokkterminátor pozíciója. És ha zárójelbe teszem, vagy ha az egészet értékadással csinálom, akkor kb. ez is történik, csak nélkülük nem. (De egyébként oda se szúrogasson be: dobjon hibát, az korrekt és logikus.) Egyszer így, egyszer úgy. Holott logikailag a három között zéró különbség van. És ezen még csak súlyosbít az, hogy az sem mindegy, hogy hol - melyik sorban - nyitom a zárójelet egy többsoros utasításban, hiszen a vezérlő és a kifejezés belseje között a nyitó zárójel pozíciójának logikailag teljesen irrelevánsnak kéne lennie, de a JS szerint nem az.
Magyarán az interpreter idevágó logikájában van egy masszív logikai inkonzisztencia. És mindez azért, mert ez az inkonzisztencia magában a koncepcióban van: egyszerre van lehetőség a multi-line utasításra és igény a sorvégi pontosvesszőre, ami aztán összeakad, a programozó meg felváltva - rosszabb esetben egyszerre - őszül és kopaszodik...

Oldschool Computer - http://oscomp.hu

 Nem akartam ennyire trollba átmenni, tényleg az hittem lehet értelmesen átbeszélni a témát. De ám legyen:

a JS meg a C/C++-tól örökölte a sajátját

Nem, a JS max közvetetten örökölte a C egyes nyelvi szabályait. Közvetlenül a JAVA-tól örökölt szintén nem mindent. Idézek a Wikipediából: "Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax". Kiemelés tőlem.

tehát egy ilyen szerkezet esetén az embernek eszébe se jut, hogy a nyelv majd magától odaképzel

Ez igaz, de csak azért, mert egy másik nyelv szabályai alapján próbálod használni a JS-t csak azért, mert hasonlít rá. 

 És ha odaképzeli, akkor tulajdonképpen le is szögezhetjük, hogy tkp. kötelező az, hisz a nyelv maga rakja oda

Nem, pont fordítva. Pont azért nem kötelező, mert a nyelv "odaképzeli" helyetted. Ha nem tenné akkor lenne kötelező.

 Mert a return után az interpreter ugyanúgy kifejezést vár

Nem. A return után lehet kifejezés, de nem várja, hiszen nem kötelező az. Lehet return önmagában, indikálva azt, hogy undefined-dal akarsz visszatérni.

A további "így-úgy kellene lennie" részre azt tudom mondani: Szerinted, a te elvárásaid és más nyelvek által épített igényeid alapján.

Ismétlem magam, hogy nem tökéletes ahogy most van, lehetne szigorúbb, vagy könnyebben megérthető a működés. A problémám továbbra is az, hogy a megértést nem sikerült meglépned.

> Nem akartam ennyire trollba átmenni, tényleg az hittem lehet értelmesen átbeszélni a témát.

A személyeskedést te kezdted, tehát te mentél át trollba magadtól. Az értelmes beszéd meg kb. ott ért véget, amikor kiköpted, hogy ez nem ésszerű, csak logikus. Bocs.

> Nem, a JS max közvetetten örökölte a C egyes nyelvi szabályait. Közvetlenül a JAVA-tól örökölt szintén nem mindent. Idézek a Wikipediából: "Netscape Communications then decided that the scripting language they wanted to create would complement Java and should have a similar syntax". Kiemelés tőlem.

És? Szintén Wikipédia a Java szintaxisáról: "The syntax is mostly derived from C and C++" A syntax layout (vezérlőszerkezetek, ciklusszervezés, blokkezelés, stb.) pl. szinte érintetlenül ment át a JS-be. És ez vonatkozik a többsoros utasításokra is.

> Ez igaz, de csak azért, mert egy másik nyelv szabályai alapján próbálod használni a JS-t csak azért, mert hasonlít rá.

Téves. Én a saját szabályai alapján használtam. Megengedi a többsoros utasítást? Meg. Akkor miről beszélsz?

> Nem, pont fordítva. Pont azért nem kötelező, mert a nyelv "odaképzeli" helyetted. Ha nem tenné akkor lenne kötelező.

Nem, pont fordítva (ülsz a lovon). A programozónak nem kötelező kiraknia, de az interpreternek kötelezően kell, ezért "képzeli oda". Ha nem tenné, akkor nem lenne kötelező.

> Nem. A return után lehet kifejezés, de nem várja, hiszen nem kötelező az. Lehet return önmagában, indikálva azt, hogy undefined-dal akarsz visszatérni.

Az rendben van, hogy a return állhat önnmagában, de itt nem ez volt a helyzet. Volt utána egy kifejezés, csak épp baszott megkeresni, mert ahelyett, hogy abból indult volna ki, hogy itt biza állhat kifejezés és nincs a sor végén semmi, akkor menjünk tovább, jé, itt egy kifejezés, parsing-parsing-parsing és jé, itt az utasításterminátor, inkább bebaszott egy pontosvesszőt a végére. Nem ésszerűen, de logikusan. :)

> A további "így-úgy kellene lennie" részre azt tudom mondani: Szerinted, a te elvárásaid és más nyelvek által épített igényeid alapján.

Nem, ez nem "az én elvárásaim", hanem a logika ésszerűség alapján kéne így lennie.

> Ismétlem magam, hogy nem tökéletes ahogy most van, lehetne szigorúbb, vagy könnyebben megérthető a működés. A problémám továbbra is az, hogy a megértést nem sikerült meglépned.

Mit nem értettem meg? Hogy így működik? De, képzeld én ezt megértettem. Már akkor, amikor blr belinkelte azt a cikket. (Pontosabban: utána éjszaka esett le.) Napokkal azelőtt, hogy idejöttél.
Te viszont nem érted meg, hogy ahogy működik az egy önellentmondó baromság. Vagy mégis? Hiszen azt már beismerted, hogy ésszerűtlen. De azt tagadod, hogy önellentmondó. Ésszerűtlen, de nem önellentmondó? Akkor most...hogy is van ez? Ha nem önellentmondó, akkor mitől ésszerűtlen? Ráadásul erre a posztra direkt azért irányítottalak, hogy azt a bizonyos önellentmondást cáfold. Nos, nemhogy nem cáfoltad, de meg sem próbáltad cáfolni; teljesen más részeket ragadtál ki a posztból, pl. hogy most honnan is örökölte a szintaxist a nyelv, ami ebből a szempontból kb. annyira volt releváns, mint egy grillcsirke a hegesztésnél...

Oldschool Computer - http://oscomp.hu

[GN]Dűlőre jutni, vagy napirendre térni; itt most az előbbi esedékes.[/GN]

A kérdés igazából már blr linkjével dűlőre jutott. A mi vitánk meg zátonyra futott, amikor ezt a logika != ésszerűség képletet felírtad. Onnantól már képtelen voltam komolyan venni.

Oldschool Computer - http://oscomp.hu

Volt utána egy kifejezés

Szerinted. Csak épp semmivel nem jelezted a fordítónak, hogy a következő sorban lévő kifejezés a return sorában lévő kifejezéshez tartozik. Ha nem így lenne, hogyan kellene tudnia, hogy a masikkifejezes() már nem a returnhoz tartozik? Értem én, hogy szokatlan a ;-ző nyelvek után, de ez van.
 

if (false) 
    return

masikkifejezes()

> Téves. Én a saját szabályai alapján használtam. Megengedi a többsoros utasítást? Meg. Akkor miről beszélsz?

Szerintem ebbe az is beletartozna, hogy tudsz rola, hogy az interpreter/fordito megprobal mindenhova pontosvesszoket biggyeszteni.
https://github.com/getify/You-Dont-Know-JS/blob/2nd-ed/types-grammar/ch…

Hiaba no, a JS az egyik legnehezebb programnyelv amit valaha tanultam. Csak a legtobb fejleszto ezt nem sejti.

Nem a nagyképűsködés volt a cél, akkor átfogalmazom: megengedte, hogy ezt csináljam, tehát a szabályai szerint játszottam. Az más kérdés, hogy amit szerettem volna, azt a saját szabályai szerint nem így kellett volna. Ha tudom, nem csinálom így. Nem a forgalommal szembemenés volt a cél.
Footnote: Egyébként 16 évnyi JS után szerintem igazán nem a magabiztosságon múlik, ha valaki hulladéknak titulálja a JS-t, mint nyelvet és a böngészőkben futó JS implementációkat, hanem keserű tapasztalatokon. :(

Oldschool Computer - http://oscomp.hu

megengedte, hogy ezt csináljam, tehát a szabályai szerint játszottam

Ez egy helytelen következtetés. Egy dolog, hogy mit enged meg és mit nem, egy tök más, hogy amit megenged milyen eredményt produkál. A szabályok pedig mindkettőt meghatározzák, te pedig csak az elsőt hajtogatod :)

Nem. Ötször leírtam már neked, vagy többször, hogy nem. Már a legelején tudomásul vettem, hogy ez így működik, csak nem tudtam róla és így elbasztam a kódot. Ettől még ez a konkrét szabály a másik - a többsoros utasítások megengedésének szabálya - mellé téve egy baromság, a nyelv pedig egy hulladék marad. Ez az, amit én hajtogatok, csak te nem akarod megérteni. Biztos, mert ez is csak ésszerű, de nem logikus.

Oldschool Computer - http://oscomp.hu

Nem baj, hogy almát hasonlítasz a döglött lóhoz? Egy szándékosan destruktív parancs végeredményét mosod össze azzal, hogy nem jó helyen volt az írásjel! Majd, ha a shell rm -rf kecske helyett rm -rf kecske / parancsot hajt végre, mert nincs a végén pontosvessző és ő önkényesen odavarázsol egy perjelet, majd akkor lesz hülye úgy, ahogy most hülye volt a JS. Jó (fals) kis érv csúsztatás volt, kis burkolt hülyézéssel megfejelve. Elfogytak az érvek, hogy már csak személyeskedésre futja?

Sz*rk: Egyébként nem tudom mit erőlködsz még két nap után is; nem tudom feltűnt-e, de ha másról nem is, arról közmegegyezés volt, hogy a JS-nek ezen húzása bizony jókora marhaság. Még te is azt mondtad, hogy nem ésszerű. Ha nem ésszerű a szabály, akkor én vagyok a hülye, mert nem tudtam róla, hogy van egy ésszerűtlen szabály és ésszerűséget feltételeztem?

Oldschool Computer - http://oscomp.hu

( blr v | 2020. 01. 03., p – 23:23 )

function blacklisted(hostname)
{
    var spl, hn;

    spl = hostname.split(".");
    if (spl.length >= 2)
    {
        hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
        return
        (
            (hn == "x.com") ||
            (hn == "y.com") ||
            (hn == "z.com")
        )
        ;
    }
    else
    {
        return false;
    }
}

undefined

console.log(blacklisted("x.com"));

function blacklisted(hostname)
{
    var spl, hn;

    spl = hostname.split(".");
    if (spl.length >= 2)
    {
        hn = spl[spl.length - 2] + "." + spl[spl.length - 1];
        return (
            (hn == "x.com") ||
            (hn == "y.com") ||
            (hn == "z.com")
        )
        ;
    }
    else
    {
        return false;
    }
}

true

( Gyuszk v | 2020. 01. 04., szo – 10:56 )

Szerkesztve: 2020. 01. 04., szo – 10:58

Szerintem a Javascript a lelke mélyéig el van qrva. https://9gag.com/gag/awom154

Szégyenletes hogy micsoda ellenmondások és érthetetlen konstrukciók vannak benne egymás hegyére hátára b.szkodva. All time kedvenc: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Globa… Ugye értjük? Beteszek egy string literált ami istibizti JS kód, majd végrehajtom. Tesztelhetőség rulz.

100%-ig egyetértek. (Itt egy részletesebb tábla az anomáliákról, meg egy a typejuggling gyönyöreiről.)

Az eval() az egy dolog, mert az csak egy lehetőség, amivel lehet élni, meg visszaélni, de az milyen már, hogy egy bad OOP move utáni állapottal lehet aritmetikai műveletet végezni? És az milyen, hogy az egyes műveletek a VM-implementációja szerint más-más eredményt adnak vissza? A JS kb. egyesíti az imperatív, az OOP és a funckionális nyelvek összes hátrányát. Ez a nyelv egy nagy inkonzisztens katyvasz.

Oldschool Computer - http://oscomp.hu

Egy normális programnyelvet lehet verziózni, a hibás funkciókat lehet deprekálni majd kivenni a nyelvből egy későbbi verzióban. Sajnos a JS nincs abban a helyzetben, hogy ezt megtehesse, csak olyan félmegoldások vannak mint a strict mode. Ami megoldás lehet az a fejlesztői eszközök használata mint a linterek és transpilerek, illetve transpileolt nyelvek (pl. TS), cserébe sokkal bonyolultabb összerakni egy JS projectet 0-ról.

> Erre az a triviális megoldás hogy nem használunk ==-t soha.

Na ja. Magyarán úgy csinálunk, mintha lennének típusaink, ahelyett, hogy lennének típusaink. :)
Azonfelül a === nem véd meg mindentől:

alert(null === null); // true
alert(Math.sqrt(-1) === Math.sqrt(-1)); // false

A kettőbe külön-külön is bele lehet kötni, bár meg is lehet magyarázni őket (elég erőltetetten), viszont együtt nézve a kettőt értelmezhetetlen a logika; a null vagy undefined állapotokat lehet értékként használni, míg a NaN értéket meg nem?

> Mondjuk a PHP-hoz képest a kanyarban sincs.

Azt nem vitatom, hogy a PHP is egy überkókány nyelv, de a JS-sel azért messze többet lehet szívni. A PHP legalább egységesen ugyanúgy szar mindenütt, viszont a JS minden implementációban máshogy. :(

Oldschool Computer - http://oscomp.hu

Mondtam, hogy külön még csak meg lehet magyarázni őket; együtt verik ki a biztosítékot. (Bár mondjuk az, hogy a null és a undefined az külön típus, az külön is kiveri a biztosítékot, lévén tkp. minden sikertelen objectekre hivatkozás ezeket eredményezi, tehát akkor egy objektummal végzett művelet három típust is eredményezhet.)

Oldschool Computer - http://oscomp.hu

A kettő teljesen mást reprezentál. Az undefined a unit típus JS megfelelője, a null a null referenciáé. Az egyik azt jelenti hogy nincs érték, a másik azt hogy van érték de más információ nem érhető el. Arról lehet vitatkozni, hogy a különböző APIk mikor melyiket kellene, hogy használják, de a nyelv konzisztensen használja a kettőt (kivéve a typeof operátor, de annak több hibája is van).

> Az egyik azt jelenti hogy nincs érték

Erről beszélek, hogy adott egy típus, aminek az értéke, hogy nincs érték. Úgy, hogy ennek nem értéknek kéne lennie, hanem állapotnak.

> de a nyelv konzisztensen használja a kettőt

De rosszul.

Azonfelül, mint mondtam a === nem véd meg mindentől:

alert(Math.pow(Math.random(), document.getElementById("no_such_element"))); // <= will alert 1

Oldschool Computer - http://oscomp.hu

Mi az, hogy félig-meddig opcionális? :))) Hogy lehet egy nyelvben bármi félig-meddig opcionális? Vagy az, vagy nem az. Olyan nincs, hogy is-is. Ja de, JS-ben. :P
Ezt írtam le a fentebbi posztban, hogy ez nettó agyhalál, hogy egyszerre van lehetőség a multi-line utasításra és igény a sorvégi pontosvesszőre, mert ez két egymásnak ellentmondó dolog.

Oldschool Computer - http://oscomp.hu

Tudsz olyan js programot írni, ami ugyan úgy működik, ha van és ha nincs benne ";", akkor is. Tudsz olyan programot írni, ami teljesen különbözően működik, nem dob hibát a parser, és ezért félrevezető. Erre jó megfogalmazásnak találtam a "félig-meddig". A másik szó tényleg az agyrém :).

Ha nem válaszolnék kommentben, hát küldj privátot!

> Tudsz olyan js programot írni, ami ugyan úgy működik, ha van és ha nincs benne ";", akkor is. Tudsz olyan programot írni, ami teljesen különbözően működik, nem dob hibát a parser, és ezért félrevezető.

Na jó, de erre írtam, hogy ha az interpreter "belehamisítja" a kódba a pontosvesszőt, akkor mégis csak kéne bele, tehát nem opcionális.

Oldschool Computer - http://oscomp.hu

Nem belehamisítja. Egyszerűen egy utasítás akkor számít lezártnak, ha benne a zárójelek, idézőjelek lezártak, és vagy pontosvessző következik, vagy pedig sortörés néhány esetet leszámítva, pl a köv sor plusszal vagy mínusszal kezdődik.

Ez tényleg nem annyira triviális, de azért nem is ördögtől való :) Valahogy meg meg kell oldani, ha az a cél, hogy ne kelljen pontosvesszőt írni. Mi volna a te javaslatod?

Jogos az idézőjel :)

Én örülök, hogy nem kötelező, legalább is nyelvi szinten. Te preferálod, én pedig nagyon szeretem a pontosvesszőket teljesen nélkülöző kódot, jó ránézni. Így, hogy opcionális, megfelelő linter beállítással lehet bolondbiztos és szép egységes kódot írni mindkettőnk számára.

Ha két ellentétes dolgot akarunk, akkor hogy írsz mindkettőnknek megfelelő kódot? Első dolgom az lenne, hogy mindenhova beteszem a pontosvesszőket...aztán ha a pontosvesszők hiánya miatt rosszul értelmezem a kódodat, akkor még el is cseszem vele. :P

Oldschool Computer - http://oscomp.hu

> Arra gondoltam, hogy írhatsz pontosvesszőt a sorok végére.

Többsoros utasításban minek tennék a sorok végére pontosvesszőt? Én nem erről beszéltem.

> De mégis mit szeretnél? Szembepisilni a nyelv szintaxisát, és elvárni, hogy úgy működjön, ahogy te képzeled?

Jó reggelt kívánok, szintaktikailag helyes volt, különben errort dobott volna. Én nem képzelek semmit, ez lett volna a logikus.

Oldschool Computer - http://oscomp.hu

Igazad van mindkét esetben, pontatlanul fogalmaztam:

  • Az utasítás végére tehetsz pontosvesszőt
  • Szintaktikailag helyes, viszont a kódod hibás. Ez is helyes szintaktikailag 2/5. Más nyelveken viszont más eredményt ad. Ismerned kell a nyelvet, a típuskonverziós szabályait hogy tudd, hogy mi lesz az. Pont erről beszélek.

> Amúgy de, a kódodat megette és értelmezte a nyelv szabályai szerint. Egyszerűen a kódod volt hibás.

GOTO10, nem érted, hogy két egymásnak ellentmondó dologról beszélünk (többsoros utasítás vs. sorvégi utasításlezárás)? A kód hibás volt, az tény, de nem azért, mert a gondolatmenet hibás, hanem mert a JS "logikája" az.

Oldschool Computer - http://oscomp.hu

két egymásnak ellentmondó dologról beszélünk (többsoros utasítás vs. sorvégi utasításlezárás)

Tökéletesen értem. Mire alapozod a kijelentésedet, miszerint ez egymásnak ellent mond?

És miért idézőjeles a nyelv logikája? Valami nem attól lesz logikátlan, hogy nem értesz vele egyet. Van logikája, más kérdés, hogy szimpatikus-e vagy sem, illetve jó dolog-e vagy sem.

> Tökéletesen értem. Mire alapozod a kijelentésedet, miszerint ez egymásnak ellent mond?

Jó ég... Ha egy utasítás lehet többsoros, akkor hogy lehet, hogy a nyelv önhatalmúlag utasításlezárást injektál a sorok végére? Még mindig nem érted, hogy két egymásnak ellentmondó mechanizmus működik itt párhuzamosan?

> És miért idézőjeles a nyelv logikája? Valami nem attól lesz logikátlan, hogy nem értesz vele egyet. Van logikája, más kérdés, hogy szimpatikus-e vagy sem, illetve jó dolog-e vagy sem.

A logika nem szimpátia kérdése, könyörgöm... Olvasd már el ezt a posztot és próbáld meg megérteni, hol van a JS értelmezésében a logikai bukfenc.

Oldschool Computer - http://oscomp.hu

Ha egy utasítás lehet többsoros, akkor hogy lehet, hogy a nyelv önhatalmúlag utasításlezárást injektál a sorok végére?

Miért következne egyikből a másik? A nyelv nem minden sor végén végez önhatalmú utasításlezárást, hanem bizonyos feltételek mellett. Amikor ezek a feltételek nem teljesülnek akkor az utasítás folytatódik a következő sorban. 

A logika nem szimpátia kérdése, könyörgöm

Én is ezt mondom. Btw a köznyelv keveri a logikus és az ésszerű szavakat. Pl mondhatod, hogy nem ésszerű ahogy a JS működik, és ezzel tudok akár egyet is érteni. De ettől még logikus, hiszen egy logikai rendszer határozza meg a működését.

 Olvasd már el ezt a posztot

Elolvastam. Kommenteljem is? Több ponton tévedésekkel van tele.

> Miért következne egyikből a másik? A nyelv nem minden sor végén végez önhatalmú utasításlezárást, hanem bizonyos feltételek mellett. Amikor ezek a feltételek nem teljesülnek akkor az utasítás folytatódik a következő sorban.

És ezeket a feltételeket sikerült a legostobább módon, a logika teljes mellőzésével összerakni. Komolyan egy zárójel pozícióján múlik, hogy jó-e vagy sem? Ráadásul nem is errort dob, hanem error nélkül kiszáll hibás működéssel?

> Én is ezt mondom. Btw a köznyelv keveri a logikus és az ésszerű szavakat. Pl mondhatod, hogy nem ésszerű ahogy a JS működik, és ezzel tudok akár egyet is érteni. De ettől még logikus, hiszen egy logikai rendszer határozza meg a működését.

Kész, én már beszarok rajtad, komolyan. :))) Nem ésszerű, de logikus? Hát...logikus, hogy ez nem ésszerű...de attól még logikus, mert egy ésszerűtlen logikai rendszer határozza meg! Kész... :)

> Elolvastam. Kommenteljem is? Több ponton tévedésekkel van tele.

Go ahead. Make my evening. :)

Oldschool Computer - http://oscomp.hu

És ezeket a feltételeket sikerült a legostobább módon, a logika teljes mellőzésével összerakni.

Lehet. De ettől még léteznek, meg vannak határozva, és be is vannak az implementáció által tartva. Ettől lesz logikus, nem attól, hogy számodra nem ésszerű vagy neked nem tetszik. 

hanem error nélkül kiszáll hibás működéssel

Welcome to the JS world :)

 Nem ésszerű, de logikus?

Leírtam miért. 

> Lehet. De ettől még léteznek, meg vannak határozva, és be is vannak az implementáció által tartva. Ettől lesz logikus, nem attól, hogy számodra nem ésszerű vagy neked nem tetszik.

Értem... :) Tehát te egy ésszerűtlen "logikát" próbálsz meg mindenáron körmödszakadtáig védeni.

> Welcome to the JS world :)

I don't feel so welcomed. Surely 'cause JS is Just Shit.

> Leírtam miért.

Ja. Le. Be kéne keretezni. :)

Oldschool Computer - http://oscomp.hu

Ebben az értelmezésben rossz használat. De ettől még a nyelv idevágó szabályai logikátlanok ésszerűtlenek. Vagyis rossz használat, vagy sem; a nyelvvel van a baj. Illetve nem is a nyelvvel van a baj, ez a nyelv maga a baj.

Oldschool Computer - http://oscomp.hu

> Azért bukfenc neked, mert úgy gondoltad, hogy azért, mert úgy indentáltad a kódot, hogy úgy nézzen ki, mintha a return után lenne akkor az ott is van, pedig nem.

Nem, nem nekem bukfenc, olvasd el a fentebbi posztot és értelmezd. Lehet cáfolni a levezetést.

> Épeszű embernek eszébe sem jutna így írni a kódot!

Tényleg? Szerintem meg ez egy teljesen valid indentálás, hogy ne egy baromi hosszú sor legyen; szerintem ez egy épeszű megközelítés. Azonfelül egy többsoros utasításokat engedő nyelvben a zárójel pozíciójának irrelevánsak kéne lennie, szerintem ez egy épeszű vélemény.
Ezek után miért nem vagyok én épeszű? Mi okod van a személyeskedésre, áruld már el...

Oldschool Computer - http://oscomp.hu

Nem ismerem a Pythont. Ezt is leírtam már. Többsoros utasítást engedő nyelvnek az számít, ahol az utasítást leírhatod több sorban. Nem tudom mi nem egyértelmű ezen. Pl.:

int
	i
		=
	1
;

Csakhogy az nem megy, hogy egyszerre lehet többsoros az utasítás, az utasítást terminálni meg nem kötelező, majd megteszi az ember helyett a nyelv. De ezt is leírtam már.

Oldschool Computer - http://oscomp.hu

> Látod, hogy van, és működik.

ROFL... Az egész topic abból indult ki, hogy nem működik.

> Nem biztos, hogy ez jó dizájn, de az alapvető probléma, hogy néhány logikus szabályt kell csak megérteni és megtanulni.

A probléma nem az, hogy szabályokat kell megtanulni, hanem, hogy ezek a szabályok éppenhogy nem logikusak, hanem önellentmondóak. Valamint nem néhány ilyenről beszélünk, hanem egy hadseregnyiről. Azonfelül most akkor nem jó a dizájn, vagy igen?

> Ez elvárható valakitől, aki egy adott nyelv szakemberének képzeli magát, nem?

Aki csak képzeli egy adott nyelv szakemberének magát, attól semmi sem várható el. Baromságok megtanulása és megértése pedig senkitől nem várható el.

Oldschool Computer - http://oscomp.hu

Az egész topic abból indult ki, hogy rosszul használod a JS-t, nem ismered azt a pár szabályt, ami meghatározza mit tart a JS motor egy statementnek. Magyarul rosszul használod, és nem megérteni akarod, hanem fikázni.

 hanem, hogy ezek a szabályok éppenhogy nem logikusak, hanem önellentmondóak

Fejtsd ki kérlek, miben valósul meg az önellentmondás.

Baromságot nem kell megtanulnod, van több választásod: Nem használod a nyelvet, transpileren keresztül használod, vagy beállítasz egy lintert, ami fogja a kezed, hogy ne tudd elrontani. Mi mást akarsz? A nyelv alkalmazkodjon hozzád? Sokkal több opció nincs.

> Az egész topic abból indult ki, hogy rosszul használod a JS-t, nem ismered azt a pár szabályt, ami meghatározza mit tart a JS motor egy statementnek. Magyarul rosszul használod, és nem megérteni akarod, hanem fikázni.

Mintha leírták volna többen is, hogy nincs megegyezés abban, hogy kötelező legyen-e, vagy sem. Akkor milyen szabályról beszélsz? A szabály hiányáról beszélhetsz, maximum. Ami pedig a fikázást illeti, csak azt tudom neked mondani, amit kb. egy éve is.

> Fejtsd ki kérlek, miben valósul meg az önellentmondás.

RTFT, ötvenszer leírtam már.

> Nem használod a nyelvet, transpileren keresztül használod, vagy beállítasz egy lintert, ami fogja a kezed, hogy ne tudd elrontani. Mi mást akarsz? A nyelv alkalmazkodjon hozzád?

Ezek közül a linter opció egyedül, azon meg már két napja túl vagyunk; kösszép. Senki nem kérte, hogy a nyelv alkalmazkodjon hozzám, csak felróttam egy baromságot. Mi fáj?

Oldschool Computer - http://oscomp.hu

Nagyon kevered a dolgokat.

Abban nincs általános megegyezés, hogy te mint programozó leírd-e a pontosvesszőt, vagy sem. A szabály amiről beszélek az ECMAScript Language Specification pedig pontosan meghatározza hogy kell a sortöréseket értelmezni.

csak azt tudom neked mondani, amit kb. egy éve is.

Képes voltál egy éves kommenteket visszakeresni hogy legyen muníció a személyeskedéshez? Más okod mi lehetett rá?

RTFT, ötvenszer leírtam már.

Amit leírtál az nem bizonyít ellentmondást.

 Mi fáj?

Semmi sem, beszélgetünk egy témáról amiről eltérő véleményeink vannak. Bár kezd fájni az, hogy nem látod be hol sántít az érvelésed. Fentebb pl összemostad a kódolási szabályokat a nyelvi szabályokkal. De nyilván elmondod miért tévedek mindjárt.  

> A szabály amiről beszélek az ECMAScript Language Specification pedig pontosan meghatározza hogy kell a sortöréseket értelmezni.

Az ECMAScript egy papíron lévő dolog, a JS meg a böngészőben lévő. Az N féle JS implementáció M féleképpen szarja le az ECMAScriptet.

> Képes voltál egy éves kommenteket visszakeresni hogy legyen muníció a személyeskedéshez? Más okod mi lehetett rá?

Nem kerestem vissza, emlékeztem rá. Amúgy személyeskedni akkor is és most is te kezdtél el, ld. még "szakembernek képzeli magát", "csak fikázni akarod", stb.

> Amit leírtál az nem bizonyít ellentmondást.

De igen. Csak te nem akarod belátni.

> Semmi sem, beszélgetünk egy témáról amiről eltérő véleményeink vannak. Bár kezd fájni az, hogy nem látod be hol sántít az érvelésed. Fentebb pl összemostad a kódolási szabályokat a nyelvi szabályokkal. De nyilván elmondod miért tévedek mindjárt.

Nem, nem írom le többször. Elég volt. Az előbb belinkeltem, hogy hol volt részletesen kifejtve. Próbáld meg megérteni.

Oldschool Computer - http://oscomp.hu

Az N féle JS implementáció M féleképpen szarja le az ECMAScriptet

Ez igaz, de ez nem a nyelv hibája. A nyelv az, amit a specifikációban látsz. A böngészők implementációja pedig meglepően sok dologban tartja ezt, amit írsz pedig eléggé a múlté. 

 d. még "szakembernek képzeli magát", "csak fikázni akarod", stb.

Az első nem neked szólt, a második pedig egy feltételezés. Ha téves szólj, de feltételezem mások is hasonló konzekvenciát vonnának le ebből.

 Csak te nem akarod belátni.

Nem akarat kérdése. Lehet hogy csak buta vagyok, és nem sikerül megértenem :)

 Próbáld meg megérteni.

Na, akkor itt van a kutya elásva: Nem a megértés a probléma, hanem az, hogy amit írsz az nem jó. 

> Jaja, mar majdnem python-szintu :)

A Pythont mint nyelvet elég felületesen ismerem, nem tudom mik a buktatói, mert a "whitespace matters" filozófia elég volt arra, hogy inkább kihagyjam...

> Bar ott az elemi muveletekkel meg a sztringekkel is gondok vannak.

Azzal JS alatt is. :)

Oldschool Computer - http://oscomp.hu

apal@laptop:~$ python
Python 2.7.13 (default, Sep 26 2018, 18:42:22) 
[GCC 6.3.0 20170516] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print(5/2)
2
>>> 
apal@laptop:~$ python3
Python 3.5.3 (default, Sep 27 2018, 17:25:39) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(5/2)
2.5
>>>

Biztos rendkivul izgalmas lesz amikor a python2 mar nem lesz becsomagolva :) 

Most lecsekkoltam és az 5.0/2.0 az 2.5-öt eredményez Python2-ben, ahogy az ember várná. Ezt tényleg kár volt lecserélni; az is egy logika, hogy egészek közti művelet egészet fog eredményezni, ott meg nincs tizedes.
Ami a szóköz/tabot illeti nem tudom és nem is akarom tudni; nem nekem találták ki a whitespace-sensitive nyelveket. :/ (De az már tényleg agyhalál lenne, ha még a tab meg a space közt is különbséget tennének.)

Oldschool Computer - http://oscomp.hu

Van valamilyen standard, ami legalább ezeket a quirk-nek tűnő jelenségeket leírja, hogy hogy kéne lennie? Amíg le nem írtad, hogy egészek közti művelet, addig nem jutott eszembe így megfogalmazni (maximum egész számokon végzett műveletként, de őszintén nem tudom milyen nyelvben van szabályozási lehetőség erre), a fentebb linkelt előadásban is elhangzik, hogy van amire a typerror és egy másik végkifejlet is jó megoldás, jó lenne egy irányelv erre :).

Ha nem válaszolnék kommentben, hát küldj privátot!

Van valamilyen standard, ami legalább ezeket a quirk-nek tűnő jelenségeket leírja, hogy hogy kéne lennie?

Persze van, de pont az a lenyeg hogy a python mint programozasi nyelv valtozik meg ilyen szinten (i.e. elemi muveletek szintjen) ha ezeket menetkozben valtoztatod. Az 5.0 float, az 5 egy egesz, az 5e0 megint float, a 0x5 megint egesz. Kicsit kesobb meg mar az 5 is egy float lesz. Kiveve ha //-rel osztod.  Mert akkor egesz. Sot, a 5.0 is egy egesz, ha //-vel osztod, de akkor az 5.//2 eredmenye 2.0 lesz! 

Dehat ilyen ez a popszakma ha gyengen tipusos nyelvvel dolgozik az ember... 

> tessék lintert használni

Shellből nodejs-t meghívva validáltattam a kódot, az nem reklamált ilyenért. (cat x.js | nodejs -c) De kösz a tippet.

> Sőt, még a Firefox konzolja is.

Az meg nem szúrt ki az ég egy adta világon semmit sem. Lefutott és nem reklamált, csak épp undefined-et adott vissza.

Oldschool Computer - http://oscomp.hu

> A node.js nem linter, ha a browser nem szól érte akkor az se fog.

Ack. Nekem CLI-s kellett, de akkor majd keresek tovább.

> A Firefox-os példához hozzátartozik hogy a konzolba másoltam be a kódot, lehet hogy azért szólt.

Nope. Most én is becopyztam és nem szólt egy szót sem.

Oldschool Computer - http://oscomp.hu

( ktkt | 2020. 01. 04., szo – 19:30 )

Meghagyva a logikádat ez kb így néz ki 2020-ban írva:

const blacklisted = (hostname) => {
    const spl = hostname.split('.');

    if (spl.length >= 2) {
        const hn = `${spl[spl.length - 2]}.${spl[spl.length - 1]}`;

        return (hn === 'x.com') || (hn === 'y.com') || (hn === 'z.com');
    }
    return false;
};

Ugye hogy mennyivel olvashatóbb? Persze ezen lehetne javítani, pl dobjuk a logikád. :D

A példában 3 feltétel volt, de mi van, ha 30 van? Azt is egy sorba írod? 2020 meg le van szarva, engem az érdekel mi fut a böngészőben és ez nem fog mindegyikben lefutni. (Nézd meg milyen szépen kiszínezte a Firefox: http://oscomp.hu/depot/js2020.png) A hn értékadó sora pedig minden, csak nem olvasható.
Úgyhogy nem az én logikámat kell eldobni. (Inkább a JS-t kéne, ha lehetne.)

Oldschool Computer - http://oscomp.hu

nem fog mindegyikben lefutni - de minden modernben, netán ie-re fejlesztesz? (ha igen -> babel)

Linterem nem színezi ki a tied ne tudom hol veszett el. :P

Gondoltam, hogy leírom de elmaradt. így szokás:

return (hn === 'x.com')
        || (hn === 'y.com')
        || (hn === 'z.com');

Viszont mivel ez egy dinamikus lista lenne célszerűbbnek tűnik így:

return blacklistedDomains.includes(hn);

> de minden modernben, netán ie-re fejlesztesz?

Nem konkrétan IE-re, de úgy, hogy minél több böngészőben menjen. Mert nem mindenütt van modern böngésző. Főleg cégeknél van olyan, hogy valami régebbi cucc van. Volt rá precedens, hogy egy beágyazott rendszer webes felületét csináltam, amire kellett AJAX, meg pár egyéb funkció. ES3 compliant módon csináltam meg, hogy a legtöbb helyen menjen. Ment. Még Netscape-ben is. (Na jó, IE6-ban nem mertem megpróbálni. :P )

> Gondoltam, hogy leírom de elmaradt. így szokás:

Bocs, de ezt így kategorikusan kijelenteni, hogy ez így szokás, az azért kicsit fals. Én általában a BSD-k által favorizált Allman style-t követem, az pedig új sorba és indentálva rakja a blokknak az első sorát (is). Tehát ahány ház, annyi szokás.
De amúgy az megvan, hogy most megint kódstílusból akarjuk megkerülni a nyelv agyhalottságát? Azt kéne végre megérteni, hogy egy többsoros utasításokat támogató nyelvben a kifejezés részei sorfüggetlenül "lebegnek" és vezérlőtől utasításlezáróig terjednek! A JS pedig összekeveri az egysoros és a többsoros megközelítést, amiből ilyenek születnek. Az a nyelv, amit egy másfajta kódstílussal fel lehet borítani, az nem ér egy vödör vizet sem... És ez nem "2020" kérdés.

Oldschool Computer - http://oscomp.hu

ktkt által javasolt módszer IE9-kompatibilis változata:

return blacklistedDomains.indexOf(hn) !== -1

Ha IE6-ra kéne fejleszteni, akkor egyrészt az a véleményem, hogy sóval be kéne hinteni a helyet (miután hidrogénbomba találat érte), illetve csak megfizetnek annyira, hogy a JS okozta bántalmaidat egy tengerparton kipihenhesd. :)

De mondom, hogy nem IE. :) Mondjuk az indexOf-nak működnie kéne majd' mindenütt, de az a baj, hogy ez nem ilyen egyszerű, mert nem sima lista, lehet, hogy komplexebb kapcsolatok is lesznek, mint az, hogy valamelyik az N-ből.
Az IE összes verzióját le kéne bombázni, majd plutóniummal behinteni, ebben egyetértünk. De attól, hogy az IE is trágya, attól még a JS is az marad.

Oldschool Computer - http://oscomp.hu

Az IE6/jQuery időkben egyébként én is eléggé utáltam a JS-t, pl. a sok function(function(){}){} féle kódok, meg a 48 emeletes callback-hell miatt. Mára azonban sokat fejlődött, olvashatóbbá vált a szintaktikája az ES6 elemekkel, meg hamarosan jön még pár újabb is, pl. a pipeline-operátor (|>), meg az optional-chaining: obj.first?.second; Illetve a mai modern frameworkökkel (pl. Vue), már egész kényelmes dolgozni.

Hát ha a modernebb szintaktika alatt azt kell érteni, amit ktkt mutatott (const hn = `${spl[spl.length - 2]}.${spl[spl.length - 1]}`;) ez éppenhogy nehezebben olvasható. Mintha a JS eddigi katyvaszát nyakonöntötték volna még egy kis shellscriptinggel is és ránézvén az általad említett pipeline operátorra, még inkább ez a véleményem. Eddig csak a procedurális, funkcionális és OOP nyelvekből volt összevasvillázva mindenféle, de most még a shellscriptingből is lesz? Nem elég karácsonyfa még ez a nyelv? Csak mert így most már N féle szintaktikája és M féle szemantikája lesz a nyelvnek, ami aztán végképp nem azt fogja eredményezni, hogy ez könnyen olvasható, értelmezhető és debuggolható lesz...
A Vue-t nem ismerem. De az eddigi JS frameworkök után valahogy ehhez sincs bizodalmam.

Oldschool Computer - http://oscomp.hu

A pipe operátor több funkcionális nyelvben is van, pl. F#, nem csak shellben létezik.

A template stringek jók, a probléma itt inkább az hogy nincs is szükség erre a te függvényedben. Használhatnál pl. regexpet a megfelelő substring kiválasztásához:

const blacklistedDomains = new Set([
	'x.com',
	'y.com',
	'z.com'
]);

function blacklisted(hostname)
{
	const [ domain ] = hostname.match(/[^.]+\.[^.]+$/) || [];
	return blacklistedDomains.has(domain);
}

Nyilván a Set lecserélhető sima tömbre vagy objektumra (ahol az objektum kulcsai az értékek), az array destructuring helyett lehet indexelni, stb.

> A pipe operátor több funkcionális nyelvben is van, pl. F#, nem csak shellben létezik.

Oké, de itt nem magával a pipe operátorral volt a baj, hanem azzal, hogy a JS egyre többféle megközelítést lapátol össze. Most akkor ez egy OOP nyelv, procedurális, vagy funkcionális? Egyszerre mind. És rosszul. (Amúgy amit ktkt mutatott értékadást, az kiköpött shellscript volt.)

> Használhatnál pl. regexpet a megfelelő substring kiválasztásához:

És az mennyivel lesz lassabb, mint a sima logikai kapcsolatok halmaza? Ja és még egyszer: nem biztos, hogy ez sima lista marad, lehet, hogy komplexebb összeüggés is lesz az egyes domainok között.

Oldschool Computer - http://oscomp.hu

Akkor úgy tűnik, csak más az ízlésünk a szintaktika terén. A JS template string-ek számomra olvashatóak, mivel Python 3.6-ból is az f-string elem lett a kedvencem, ami nagyon hason ehhez, kompakt kifejezéseket lehet vele írni: f"Helló {nev}!". Nagyobb kedvvel írok JS-ben ilyet, mintsem a régi változatot: 'valami ' + egy_valtozo + ' valami más'. Az már a szerkesztő feladata, hogy megfelelően kiszínezze a változókat, a kifejezésben.

Azt én nem tartom feltétlenül hátránynak egy programnyelvnél, ha többféle paradigmát is támogat. Ki kell választani a neked tetsző stílust és azt használni. Szvsz nem baj ha egy nyelv fejlődik, lesznek benne új elemek, még úgy is, hogy emiatt egy adott feladatra két módszer is lesz (pl. Python-ban az f-sztringek előtt már volt két másik módszer is sztring-interpolációra). Majd kialakul, hogy melyiket használják a gyakorlatban. JS-ben ilyen volt pl. az async-await, ami a callback-hellre adott egy sokkal áttekinthetőbb alternatívát.

Hát eléggé más; én az oldworld procedural nyelvektől jövök, meg az ASM-től, így én pont a régi, egyértelmű változatot preferálom.

Na ja, ha rend van tartva és egyféle paradigma szerint kódolnak az emberek, akkor működhet a dolog, de ha mindenki kiválasztja a saját kedvencét, akkor abból akkora katyvasz lesz...senki nem tudja majd a másik kódját rendesen értelmezni.
Az nem baj, ha egy nyelv fejlődik, de kérdés, hogy hova és kérdés, hogy egyáltalán fejlődésnek lehet-e ezt nevezni. Nézzük a pipe operátort. Ez arra való, hogy - nomen est omen - csöveket kössünk össze vele. Namármost egy változó, vagy egy függvény minden csak nem cső. Eddiglen volt a nyelvnek egy logikája, hogy a függvényeknek paramétert adunk át és most ezt rúgjuk fel, hogy ad-hoc rá lehet irányítani valamit. (Tényleg, mit csinál ez egy több bemenetes fügvénynél? Errort dob? Vagy mit csinál, ha objektumot irányítok egy függvényre? Vagy egy változót egy objektumra? Függvényt egy objektumra?) Hovatovább, az adott példa

let url = "%21" |> decodeURI;

még unintuitív is, amennyiben "csövesen" gondolkodunk, hiszen a cső egyfelé megy, azaz itt az ember úgy gondolná, hogy a decodeURI cél és nincs tovább. Hiába van előtte egy értékadás; nem egyértelmű, hogy ez most mit akar csinálni; az url egyenlő lesz "%21"-el és ez megy tovább a decodeURI felé, vagy pedig a "%21" elmegy a decodeURI felé és utána megy vissza. Persze lehet mondani, hogy RTFM, mert leírják, hogy az utóbbi...de ha valakinek - aki ezzel még nem találkozott - szembejön egy ilyen kód, akkor nem biztos, hogy hirtelen érteni fogja és nem is csoda, mert itt egy shell-like pipe-operationt látunk, nem shell-like viselkedéssel. Ugyanez a felállás shell-ben ugyanis elküldi a célnak a cső bemenetére aggatott adatot, a változóba nem kerül semmi; ha ezt akarjuk, akkor azt jelezni kell: subshellbe kell rakni a kifejezést. Persze itt is be lehet zárójelezni és akkor rögtön egyértelmű lesz, de most zárójelezzük szénné az összes értékadást?
Én azt látom, hogy a JS folyton össze-nem-illő nyelvi elemeket és paradigmákat hány össze, aminek már számtalanszor megittuk a levét.

Oldschool Computer - http://oscomp.hu

Én PHP4-gyel kezdtem (sikerült kiheverni), aztán kis JS, C, C++, majd alapkutatói karrierem alatt Python+OpenCL a GPU programozáshoz, illetve C++ CUDA.

A pipeline operátor több, egymás utáni függvényhívásnál lehet majd hasznos (megjegyzem, fentebb rosszul írtam, még csak stage-1 proposal állapotban van, szóval változhat és el is vethetik.) Nekem a pipeline-os szintaktika átláthatóbb az alábbi példán:

let uj_ertek = otodik_fv(negyedik_fv(harmadik_fv(masodik_fv(elso_fv(ertek)))));

let uj_ertek = ertek
  |> elso_fv
  |> masodik_fv
  |> harmadik_fv
  |> negyedik_fv
  |> otodik_fv

Számomra logikus, hogy a sor végén a változó aktuális értéke nem a /dev/null-ba megy, hanem az uj_ertek változóba kerül.

Több paraméteres függvénynél meg kell adni, hogy melyik argumentuma legyen a pipeline-ból származó változó:

let person = { score: 25 };

let newScore = person.score
  |> double
  |> (_ => add(7, _))
  |> (_ => boundScore(0, 100, _));

Bármilyen típusú változót használhatsz a pipeline-nál, amit normál esetben is használnál.

De egyébként teljesen megértem a szkepticizmusodat az újdonságokkal szemben, nemrég a Python közösségben is nagy port kavart az új értékadási operátor bevezetése, amellyel időnként kvázi egy sort lehet megspórolni, de sokak szerint az átláthatóságot csökkenti, meglátjuk.

Azt áruld el nekem, hogy ha a függvényes verziót egy sorban írod fel, akkor a csövest miért nem úgy?

let uj_ertek = ertek  |> elso_fv  |> masodik_fv  |> harmadik_fv  |> negyedik_fv  |> otodik_fv

Vagy ha a csövest több sorba írod, akkor a függvényest miért nem úgy?

let uj_ertek =
	otodik_fv(
		negyedik_fv(
			harmadik_fv(
				masodik_fv(
					elso_fv(ertek)
				)
			)
		)
	)
;

Mert így persze, hogy átláthatóbb lesz a csöves szintaktika.

> Számomra logikus, hogy a sor végén a változó aktuális értéke nem a /dev/null-ba megy, hanem az uj_ertek változóba kerül.

Ez attól függ, hogy ki mit látott előbb: funkcionális nyelvet, vagy shellscriptet. (Egyébként shellscript esetén sem a /dev/null-ba megy, hanem a stdout-ra.)

> Több paraméteres függvénynél meg kell adni, hogy melyik argumentuma legyen a pipeline-ból származó változó:

Ezt a kódot még értelmezni sem bírom rendesen. Ez most ez akar lenni?

let person = { score: 25 };

let newScore =
	boundScore(
		0,
		100,
		add(
			7,
			double(person.score)
		)
	)
;

Mert, ha igen, akkor ez aztán jól meg lett csavarva; ez minden csak nem könnyen értelmezhető. Arról nem is beszélve, hogy nem csak gépelni kell hozzá többet, de zárójelezni is. (6:8) Nem tudom mi forog ilyenkor a JS újításaiért felelős emberek fejében; cél, hogy minél átláthatatlanabb legyen a nyelv?

Oldschool Computer - http://oscomp.hu

A lényeg nem azon van, hogy hány karakter kell hozzá, hanem hogy milyen sorrendben van leírva a kódban. Az egyik esetben ugyanaz a sorrend ahogyan a végrehajtás is történik, a másikban fordított. Egyébként ez a partial applicationnel lesz teljes, akkor (a fenti példában legalábbis) lambdákra sem lesz szükség.

> A lényeg nem azon van, hogy hány karakter kell hozzá, hanem hogy milyen sorrendben van leírva a kódban.

A lényeg tényleg nem a karaktereken van (bár nem mindegy, mennyit kell gépelni), hanem az olvashatóságon.

> Az egyik esetben ugyanaz a sorrend ahogyan a végrehajtás is történik, a másikban fordított.

Kivéve, hogy a legelőször felírt művelet (változó értékadása) hajtódik végre legutoljára. Azaz a sorrend 2->N, 1. Igen, az a függvényesben is, de ott legalább a sorrend konzisztens: N->1.

> Egyébként ez a partial applicationnel lesz teljes, akkor (a fenti példában legalábbis) lambdákra sem lesz szükség.

Mi a cél? Az önobfuszkálás? Csak mert affelé halad...

Oldschool Computer - http://oscomp.hu

Tévedés, az értékadás egy utasítás, az értékadás jobb oldala egy kifejezés. Megint csak két eltérő dologról van szó.

Javaslom, hogy ismerkedj meg egy tisztán funkcionális nyelvvel, akkor gyorsan helyére fognak kerülni ezek a fogalmak (function composition, partial application, currying, pattern matching / destructuring, stb.). Sajnos a JS nem a legjobb funkcionális nyelv, pláne hogy multi paradigm, de 2020-ban megkerülhetetlen a funkcionális programozás ismerete ha JS-ben akarsz programozni.

> Tévedés, az értékadás egy utasítás, az értékadás jobb oldala egy kifejezés. Megint csak két eltérő dologról van szó.

var kecske = (x = y = do_something(65, 02)) | (z = do_something_else(kecske));

Az értékadás maga is egy kifejezés. Ezt a kódot hogy írod át csövesbe? Úgy, hogy egy utasítás maradjon.

> Javaslom, hogy ismerkedj meg egy tisztán funkcionális nyelvvel, akkor gyorsan helyére fognak kerülni ezek a fogalmak (function composition, partial application, currying, pattern matching / destructuring, stb.).

Egyszer lehet, hogy sor kerül rá, de most nem prioritás.

> Sajnos a JS nem a legjobb funkcionális nyelv, pláne hogy multi paradigm, de 2020-ban megkerülhetetlen a funkcionális programozás ismerete ha JS-ben akarsz programozni.

Na, pont ezért egy raklap alsógatya a JS. Mint mondtam, összehányt különféle paradigmákból egy raklap önkényesen kiválogatott nyelvi elemet és megközelítést, a programozó meg ihatja a levét. A JS nem a legjobb funkcionális nyelv, nem a legjobb OOP, nem a legjobb procedurális...kb. mindegyikből a hátrányokat sikerült összelapátolni. (Majdnemhogy.) Amúgy ez a 2020-azás nem korai még egy kicsit? 5 napja van még csak 2020, a pszeudoprogresszív mindenit neki.

Oldschool Computer - http://oscomp.hu

Nem! Én nem ezt mondtam, hogy fasság az egész! Ne adj szavakat a számba! Én azt mondtam, hogy a műveleti sorrend, mint a pipeline-s megoldás mellett szóló érv a procedurálissal szemben, az invalid. Ennyit és nem többet. A többit te láttad bele, mert már megint könnyebb arra reagálni, amit hinni akarsz, hogy mondtam, mint arra, amit mondtam. No comment.

Oldschool Computer - http://oscomp.hu

Hogy mi van...? Az eredeti példakódot nem is én írtam és ez arra is vonatkozott... Az értékadás maga is lehet kifejezés (ezen mit bizonyítsak?), a pipeline-os megközelítésnél meg az értékadás marad utoljára, holott az van legelől (és ezen?).

Oldschool Computer - http://oscomp.hu

Ez attól függ, hogy ki mit látott előbb: funkcionális nyelvet, vagy shellscriptet

Javíts ki, ha tévedek, de funkcionális nyelvekben azért szokott lenni pipe operátor, vagy annak híján valami függvény, amivel megteheted ugyanazt. A pipe objektven jobb, hiszen végrehajtás sorrendjében írod le az elvégzendő műveleteket, és függetlenül attól, hogy egy vagy több sorba írod, áttekinthetőbb lesz.

Kész... :))) Hallod, itt van egy poszttal feljebb kivesézve, hogy ez nem igaz, mert az értékadás fut le a legvégén, holott az van a legelején, így aztán a valós sorrend 2->N,1, míg a procedurális megközelítésnél a nestingből logikusan következő - és nem fragmentált - N->1. Tényleg nem olvasod el, amit írok?

Oldschool Computer - http://oscomp.hu

De olvastam, és értem mit mondasz, sőt, igazad is van bizonyos szempontból. De két dolgot mosol össze, az értékadást, és a pipe-olást, utóbbi egy önálló műveletlánc, aminek az értékadás nem a része. Még ha az is lenne, nem számít, mert apróság főleg egy hosszabb lánchoz képest, aminek az áttekinthetőségén nem ront. 

Ennyi erővel minden egyes függvényhívás egy önálló műveletlánc. Egyébként nem én mosom össze, hanem az emberi agy. Az egyiknél elindul jobbról balra (bentről kifele) és végigmegy, a másiknál meg balról jobbra, majd ugorhat vissza.

Oldschool Computer - http://oscomp.hu

Azért formáztam így, hogy minél inkább "valódi" kódból kivett példának tűnjön. A pipeline operátornál több (mondjuk >= 3) elem esetén már külön sorba raknám őket, úgy áttekinthetőbb számomra.

A pipeline-nál el tudnék képzelni olyan szintaktikát is, hogy a sor végére lehetne rakni a változót, ahova a végeredmény kerüljön. De gondolom nem akarták ennyire megkavarni a szintaktikát.

Ok, de be lehet tördelni a procedurálisat is, akkor az is áttekinthetőbb.

Lehetne úgy is, mindenesetre egy non-shell nyelvben egyértelműbb lenne; ha függvénybe lehet pipe-olni, akkor változóba is. Annak legalább garantáltan egy "bemenete" van. Szerintem csak nem igazán tudják a JS háza táján, hogy mit csinálnak.

Oldschool Computer - http://oscomp.hu

Ezért jók a transpilerek. Alapvetően nem szeretem őket ezért sima (+modern ;)) node-nál nem is használnám de böngészőben megértem a használatát.

Igazad van de JavaScript kontextusban vagyunk, erre vonatkozóan írtam... és persze igazad van, biztos találsz olyan szabályt JS világban ahol nem így van, de próbálok nem árral szemben úszni és követem a nagyokat (airbnb, google, stb). Azért is jók ezek a szabályok mert szól ha ilyen hibát követsz el (most kiírna hogy nem fog lefutni - unreachable code).

 

A te bajod hogy nem adaptálódsz a használt technológiához, azt erőlteted bele amit már ismersz (meg persze a nyelvtervezés vagy nem tervezés) - az informatika nem így működik. Jogos hogy nem tökéletes a JS (nagyon nem az), de minden nyelvben találsz hülyeségeket.

> Ezért jók a transpilerek. Alapvetően nem szeretem őket ezért sima (+modern ;)) node-nál nem is használnám de böngészőben megértem a használatát.

Nem mertem kipróbálni; csak abban a kódban bízok, aminek a működését értem és tudom hol lehet benne a hiba, ha valami megborul. Ezért kerülöm a JS keretrendszereket is. Egy transpiler által generált kódot kidebuggolni biztos nagyon vicces lehet.

> de próbálok nem árral szemben úszni és követem a nagyokat (airbnb, google, stb)

Én sem direkt úsztam szemben az árral; csak eszembe se jutott, hogy egy többsoros utasításnál ő lezárja helyettem az utasítást az első sorban. :/

> Azért is jók ezek a szabályok mert szól ha ilyen hibát követsz el (most kiírna hogy nem fog lefutni - unreachable code).

A BaT által citált lintert leszámítva eddig semmi nem reklamált érte.

> A te bajod hogy nem adaptálódsz a használt technológiához, azt erőlteted bele amit már ismersz (meg persze a nyelvtervezés vagy nem tervezés) - az informatika nem így működik.

Nem én...a böngészők! Nem csak a latest Chrome van, az informatika nem így működik. :P Szerinted miért szívnak ezer helyen legacy dolgokkal? (Másik ezer helyen meg a nagyon modern dolgokkal, mert manapság sajnos sokszor az innováció után rosszabb lesz, mint előtte. :( )

> Jogos hogy nem tökéletes a JS (nagyon nem az), de minden nyelvben találsz hülyeségeket.

Na de ennyit? :)
Több, mint 30 éve ülök gép előtt, majd ugyanennyi éve kezdtem a programozást is, sok nyelvet láttam, de ennyi szamárságot, inkonzisztenciát és logikai bukfencet egyetlen nyelvben sem láttam, mint a JS-ben. Nem még PHP-ban sem, pedig az nagy szó.

Oldschool Computer - http://oscomp.hu

Egy transpiler által generált kódot kidebuggolni biztos nagyon vicces lehet - Ezért generálnak egy mapot is debug módban vagy amikor bekapcsolod, de ettől meg lehet szívás (pl nem tudod rávenni Chrome-ot hogy figyelembe vegye).

ő lezárja helyettem az utasítást az első sorban - ilyen ez a pop szakma, hogy a jövőben ne forduljon elő, MDN. :D

Szívok legacy dolgokkal is, de szerencsére van akarás a javítására (persze van akinek ez se tetszik :/). Elég szomorú olyan JS kódot nézni ami úgy néz ki mint egy 20 éves java/c# borzadály...

Na de ennyit? - ezért utáltam a JS-t úgy hogy sose láttam, eleget hallottam róla. De azzal, hogy van egy elég modern JS (es6+) és ebben kezdtem el fejleszteni megszerettem. 5-10 évvel korábban lehet örökre megutáltam volna.

 

Rakj fel egy VSCode-ot és az ESLint plugint (lehet nem is kell?). Nekem szabály nélküli projektben aláhúzza az ilyet. - szerk: oké, BaT is ezt írta. :D

> Ezért generálnak egy mapot is debug módban vagy amikor bekapcsolod, de ettől meg lehet szívás (pl nem tudod rávenni Chrome-ot hogy figyelembe vegye).

Majd, ha nagyon nincs mivel szívni, lehet kipróbálok egy ilyet. :P

> ilyen ez a pop szakma, hogy a jövőben ne forduljon elő, MDN. :D

Ez már eső után köpönyeg... :P Az összes ilyen baromságát meg nem ismerheti az ember a nyelvnek, biztos lesz még itt bazmeg. :/

> Szívok legacy dolgokkal is, de szerencsére van akarás a javítására (persze van akinek ez se tetszik :/). Elég szomorú olyan JS kódot nézni ami úgy néz ki mint egy 20 éves java/c# borzadály...

Java-t/C#-ot még manapság is borzadály nézni. :) Előbbinek a végeredményét futtatni is...

> ezért utáltam a JS-t úgy hogy sose láttam, eleget hallottam róla. De azzal, hogy van egy elég modern JS (es6+) és ebben kezdtem el fejleszteni megszerettem. 5-10 évvel korábban lehet örökre megutáltam volna.

Én 16 éve kínlódok vele...képzelheted én hogy utálom. :D

Sz*rk: VSCode...NO WAY. Nem tudom van-e egyáltalán UNIX-ra, de ha van se kell.

Oldschool Computer - http://oscomp.hu

> VS Code megy több platformon is, de ott van a https://github.com/VSCodium/vscodium is, amiből kiszedték az MS telemetriáját.

Még szerencse. Akkor most már csak át kell írni valami normális nyelvre, hogy ne falja fel a gépet. :P Thx no, maradok a saját editoromnál.

> Illetve Sublime Text-hez is van ESLint plugin, meg még számos szerkesztőhöz.

A Sublime már inkább érdekel, de azért még megnézem, hátha van az én szerkesztőmhöz is; thx.

Oldschool Computer - http://oscomp.hu

Ne szívd fel magad ennyire, tényleg leírtad, elsiklottam felette.

Ettől függetlenül tartom magam ahhoz amire ki akartam lyukadni: Jó elszeparálni az adatot és a kódot ami azt kezeli. Mert így az adatok mint konfiguráció könnyebben kezelhető a függvényed mint kód jobban unit tesztelhető. És ez úgy se nehéz, ha komlpex feltételeid vannak, egyszerűen nem string egyezőséget vizsgálsz a tömb elemein, hanem mást. Mondjuk regexet (is) és / vagy lamdbákat hívsz. Nem ördögtől való, így működik az array filter is.  

És persze mondhatod, hogy ez felesleges bonyolítás, de miért is? Egy URL listát, vagy feltétel listát előbb találsz meg egy config fájlban, mint egy script közepén. Így az a lista jobban kezelhető, a kódod pedig unit tesztelhető. Nyilván erre semmi szükség ha csak egy röpke scriptet dobsz össze magadnak. 

A felvetett teljesítménybeli aggályok pedig feleslegesek amíg nem keletkezik ebből tényleges bottleneck, főleg úgy, hogy feláldoznád vele a karbantarthatóságot és tesztelhetőséget.

> Ne szívd fel magad ennyire, tényleg leírtad, elsiklottam felette.

Na jó, de ötször? :)

> Ettől függetlenül tartom magam ahhoz amire ki akartam lyukadni: Jó elszeparálni az adatot és a kódot ami azt kezeli. Mert így az adatok mint konfiguráció könnyebben kezelhető a függvényed mint kód jobban unit tesztelhető. És ez úgy se nehéz, ha komlpex feltételeid vannak, egyszerűen nem string egyezőséget vizsgálsz a tömb elemein, hanem mást. Mondjuk regexet (is) és / vagy lamdbákat hívsz. Nem ördögtől való, így működik az array filter is.

Ez is volt már. :P

> És persze mondhatod, hogy ez felesleges bonyolítás, de miért is? Egy URL listát, vagy feltétel listát előbb találsz meg egy config fájlban, mint egy script közepén. Így az a lista jobban kezelhető, a kódod pedig unit tesztelhető. Nyilván erre semmi szükség ha csak egy röpke scriptet dobsz össze magadnak.

Aha és a konfigfájlban található adatsémákhoz hoz mindjárt találjak ki codebuildert is, ha komolyabb kapcsolatokat akarok felépíteni, ugye? Itt egy célfeladatról beszélünk. Nem építünk hozzá általános eszközt.

> A felvetett teljesítménybeli aggályok pedig feleslegesek amíg nem keletkezik ebből tényleges bottleneck, főleg úgy, hogy feláldoznád vele a karbantarthatóságot és tesztelhetőséget.

Ha nem túl sebességkritikus, akkor még csak-csak le lehet írni a regex okozta overheadet, de ami azt illeti nekem egy regex sokkal kevésbé átláthatóbb, mint egy logikai kapcsolatrendszer.

Oldschool Computer - http://oscomp.hu

Ööö...láttad te a nyitó kódot? A logikai szerkezet tkp. el van szeparálva. Annyi van előtte, hogy a beérkező stringből csak a domainnév marad meg, ami kb. 3 sor volt. Most ezt a 3 sort hagyjam meg itt és az egy darab returnt meg tegyem külön függvénybe? El szoktam szeparálni amit el kell, de ebben az esetben ez már overengineering.

Oldschool Computer - http://oscomp.hu

Mondom, kis scriptnél nyilván nem feltétlenül játszik ez.

De gondoljuk tovább: Nem tudod elképzelni, hogy a scripted egyszer csak bővül mondjuk úgy, hogy a domainből nem fixen az utolsó két szegmenst hagyod meg, hanem végződéstől függően potenciálisan többet (mondjuk támogatandó az xxx.co.uk és hasonló címeket)? Rögtön nem három sor lesz az :)

Nem feltétlen. Ipari környezetben sokszor vannak baromi régi böngészők; fentebbi válaszomban mondtam egy (saját tapasztalati) példát.

Sz*rk: Ez kissé félreérthető lett; nem konkrétan az InDesignre gondoltam, hanem bármilyen JS programmable szoftverre, ami régi szabványokat követ.

Oldschool Computer - http://oscomp.hu