Coffeescript

Találtam egy új feature-t: 


c = 5
a = b ? c

"a" értéke 5 lesz az alábbi Javascriptre forduló kód miatt: 


var a, c;
c = 5;
a = typeof b !== "undefined" && b !== null ? b : c;

( numen v | 2018. 01. 20., szo – 11:36 )

Általában kiváltja a 

b||c

.

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Annyiban hasznos, hogy a Coffeescriptből transzpilált változat a „undefineddy” értékekre fókuszál, míg a binary az összes falsy értéknél a másodikat adja vissza.
Ja meg az „existential operator” elnevezésért már érdemes volt implementálni. 

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Az „általában” szcenarióba nálam beletartozik, hogy a változóinkat használat előtt deklaráljuk – de erre a linter is figyelmeztet (… általában ☺).

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Nekem pont CS megoldása tetszik, mert nekem sokszor kell úgy vizsgálnom, hogy nem tudom definiált-e a változó, és nem is akarom definiálni a működésért.

Ugyanez tetszik Ruby-nál is, hogy ha nem definiált, attól még lehet vizsgálni az if-fel. Igaz kicsit más a működés, mert CS esetében külön dolgot vizsgál if? és if. Ilyen szempontból Ruby-é a legjobb szerintem. Ha nem definiált vagy logikai NEM az értéke, akkor az if adjon vissza false-ot.

"Nem csak objektumoknál van undefined érték amit vizsgálni akarok,"

Hanem hol? Mutass egy példát légyszi te is.

"Az object spread-re írnál példát "

let {success = false, data = null} = res;

Itt a res objektumból a success és data mezőket fogja ugyanazon nevű változókba rakni, vagy ha nincs definiálva, akkor ott a default érték. A || operátorral szemben itt előnyös, hogy a falsy értékeket is átveszi.

Nyilván a res-nek objektumnak kell lennie, azt vagy előtte ellenőrizni kell, vagy ha valamire, akkor erre jó a || operátor így:

let {success = false, data = null} = res || {};

Na jó, de te egy olyan problémára használod aminek nem szabadna létezni :) Ideális esetben nem a globális névtérbe raksz flageket, hanem valami objektumba, vagy modul paramétereként deklarálod. Nem hivatkozol globális változókra közetvlenül, hanem a window-t használod, hogy egyértelmű legyen a kódod, és ne legyen gond az esetleges variable shadowing.

Célhoz megoldást. Ahogy írtam, apró web app-oknál melyek relatíve kevés sorból állnak, nem foglalkozok konvenciókkal. Azt teszem ami nekem hatékonyabb. Ha egy eseménynél vizsgálok első futást, akkor ez hatékonyabb. Rövidebb kód, áttekinthetőbb, karbantarthatóbb, kevesebb idő és munka.

Ettől független javaslom a globális változók kerülését.

Ahogy gondolod. Én személy szerint nem látom hol lenne fáradtságosabb, áttekinthetetlenebb akár egy kis, pár soros script attól, hogy ha azt is megpróbálod jó gyakorlatok alkalmazásával készíteni.

Illetve az nem jó, ha a jó gyakorlatokat nem követjük rögtön, amint csak pár soros a kód, vagy csak magadnak fejlesztesz. Ilyen esetekben is lehet élni velük, és az aktuális példánál nem látom hol ronthat a hatékonyságon, vagy épp az áttekinthetőségen szépen megcsinálni azt.

Például egy web app-nál az események kezelésénél jelző flag-nek használom a változót olyan kódrészhez, amelynek csak 1x kell lefutni. Ehhez nem akarom a másik ágban a betöltésnél telerakni ezer deklarációval. Minél kevesebb kód legyen.

Példa (nyilván érdemes a változót sokkal jobb leíró névvel ellátni): 


if not flag?
    flag = 1
    # run this code once

Viszont ebben az ágban nem érdemes definiálni. Legfeljebb így (nem szeretem a false / true-t, inkább null / 1-et szoktam használni, de ez preferencia kérdése): 


flag = null  if not flag?

Vagy a fő ágban "flag = null". Részemről nem érdekel mert megtehetem és mivel jobban tetszik így és a karbantarthatóságomat növeli számomra, ezért így használom.

Nyilván saját kód stílusnál tudom hogy a flag nevű változók ilyenek. Nagyobb fejlesztő csapatnál lehet más az elvárás, amiben nem látok problémát.

JS-ben is :) És hogy a fenti kérdésedre akkor válaszoljak, a window egy objektum, amin ugyanúgy tudod használni a spread operátort, ha úgy alakul.

Szerk, például

const { flag = 0} = window;
És akkor lesz egy helyi változód flag néven, ami vagy nulla, vagy ami épp volt a window objektumban. De őszintén nem tartom túl szerencsés gyakorlatnak ezt.

( ironcat | 2018. 01. 22., h – 09:37 )

A lua-ban is így van: 


c = 5
a = b or c

Ott előszeretettel használják az 

a = a or c

formában. Például így lehet default értéket adni egy függvény paraméterének.

Nem tudom ki hogy van vele, de JS-nél zavar hogy nem lehet csuklóból hatékony rövid kódot kiadni. Szerintem sokban le van maradva JS ha kód olvashatóságot és produktivitást nézünk. Nem tudsz csinálni egy hasonlót, hogy a sok példa közül egyet idedobjunk: 


func()   while n--  when n % 3 == 0

Meg ilyenek, több szintű kapcsos zárójelek meg pontos vesszőzések nélkül. Persze mindenki kódoljon amiben akar.

Az alábbi JS-re fordul: 


  var n, print;
  print = function(text) {
    return document.body.innerHTML += text + "<br>";
  };
  n = 10;
  while (n--) {
    if (n % 3 === 0) {
      print(n);
    }
  }

Meghívja func() nevű függvényt, mindezt a while cikluson belül. Ugye a while ciklus visszaszámol amíg n nagyobb mint 0, viszont van még egy csavar. A when kulcsszó csak akkor engedi a ciklus magját lefutni, ha teljesül az ő feltétele is.

Bár a fenti példámnál a while feltételéhez is beírható lenne a when feltétele, ezért adok egy még jobb példát ahol nehéz kiküszöbölni: 

print n   for n in [1..10]   when n%3 == 0

Ez az alábbi JS-re fordul: 


  var i, n, print;
  print = function(text) {
    return document.body.innerHTML += text + "<br>";
  };
  for (n = i = 1; i <= 10; n = ++i) {
    if (n % 3 === 0) {
      print(n);
    }
  }

Kellett egy kis idő, mire felfogtam, hogy mi van :) Kicsit kuszán magyarázol. A fenti egysorosban, amivel kapcsolatban kérdeztem, hogy ez mégis mit csinál szó sincs se print függvényről, se annak az implementációjáról, mégis a magyarázatod, hogy az mire fordul ezeket tartalmazza.

De megnéztem a kódodat egy coffeescript compilerrel, és ez az egy sor: 

func() while n-- when n % 3 == 0

js-ben megfogalmazható így: 

while (n--) if (n % 3) func()

Még rövidebb is :)

A másik példád: 

print n for n in [1..10] when n%3 == 0

Na ezt már egy kicsivel hosszabban tudom megfogalmazni, de nehogy azon a pár karakteren múljon a nyelv hatékonysága. 

for (let n = 1; n < 10; n++) if (n % 3) print(n);

Igazából a fenti coffeescriptes példáiddal az a bajom, hogy tényleg tömör kódot írsz, csak épp nem túl könnyen értelmezhető egy a nyelvet kevésbé ismerő számára. Szóval a hatékonyságot nagyrészt elveszíted. Előnye pedig annyi, hogy lehet vele villogni, de ha áttekinthető kódot kell írni, akkor én biza beírom két vagy három sorba, rendesen zárójelek közé szedve azt az egy-egy while és if blokkot :)

Először is miért fordított sorrendben írod a blokkokat mikor nem úgy logikus kiolvasni? :)

Nincs sok időm, de bedobok ide még pár példát ami tetszik (számomra fontos hogy ne kelljen zárójelezni és sokszor jobb az egysoros, mert vízszintesen mindig több helyem van általában, ezért tömörebb de mégis olvashatóbb): 


func()  if func?

print "ok"  if a < b < c < d

print n  for n in [1..20]  by 3

"Először is miért fordított sorrendben írod a blokkokat mikor nem úgy logikus kiolvasni? :)"

Kinek mi a logikus. Neked ez, mert ismered. Viszont annak, aki nem ismeri, de más programnyelvekben jártas, az az ott megszerzett ismeretek alapján fogja megpróbálni értelmezni a látottakat.

Én kb. a hajat tépem amikor azt látom, hogy előbb van az utasítás, aztán a feltétel.
Ez a logika már ott megbukott, hogy a processzor is előbb az összehasonlítást végzi el, majd annak függvényében ugrik.
Tehát a gép kód mindenképp feltétel=>utasítás lesz. Nem is értem miért akarja ezt bárki fordítva látni :O

Azért mert a humánt kell támogatni, nem a gépet. Éppen ezért kényelmetlenebb bizonyos nyelveket használni, mert a nyelvet fejlesztőknek kényelmesebb a géphez igazodva programozni. Ez egy csúszka amit ide oda tol az ipar. Mindenki a másikra akarja tolni a problémát.

Ruby kitalálójával értek egyet, Matz ezt mondja:

He stresses that systems design needs to emphasize human, rather than computer needs:

Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run fast. By doing this, the machine will run more effectively. By doing this, the machine will something something something." They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.

https: //en.wikipedia.org/wiki/Ruby_(programming_language)

Bármeddig lehet fokozni, de a végén akkor is az a kérdés hogy mennyi erőforrásba (energia, idő, tudás) kerül megcsinálni valamit.

Én angolul gondolkodok. Szerinted az alábbi objektum metódusok közül melyik következetesebb: 


(Ruby)
obj.to_i       (to integer)
obj.to_s       (to string)
obj.to_a       (to array)
obj.to_json    (to JSON)

(JS)
parseInt(obj)
obj.toString()
JSON.parse("[" + obj + "]")
JSON.stringify(obj)

Vagy ciklusnál Ruby: 


5.times {  p "hello" }

Stb, és ilyenből még több van. Magamban angolul mondom és a gondolataimra nagy mértékkel jobban illeszkedik Ruby.

Nem propagálni szeretném a nyelvet (mert úgyis mindenki azt használ amit akar), hanem megmutatni hogy az én szempontomból mennyivel és miért hatékonyabb.

> JSON.parse("[" + obj + "]")

Ilyen mintát hol (és miért) láttál?

Egyébként nem mondom, hogy amit a ruby csinál nem kényelmes, de tök másról beszéltünk eddig, még jó, hogy az álláspontod alátámasztására idehozol valami tök mást :)

Ráadásul a parseInt egyértelmű(bb). A to_i-ről a nyelvet nem ismerve el tudod mondani egyértelműen, hogy mit csinál? Jó eséllyel megtippeled, de nem attól lesz valami kényelmes, hogy pár betűvel kevesebbet ütsz le. Konkrétan ezek a rövidítések annak, aki tanulja a rendszert, vagy nem ismeri, annak pont nehézséget jelentenek.

Van JS-ben btoa nevű függvény. Akkor az most mi? az a tömb lenne? Mert nem az :) Ennyit arról, hogy rövidítgetünk, meg mindent megpróbálunk agyonegyszerűsíteni.

A szintaktika és a szemantika együtt számít természetesen. Kérdés hogy a nyelv megtanulásának könnyítését célozzuk-e, vagy a nyelv megtanulás utáni használhatóságát. Első eset 1 idő egységig tart míg a mások sok egység. Ezért érdemesebb szerintem az utóbbi könnyítését célozni.

Valón eltérünk közben a témától. Onnét jött hogy kifejeztem, mit szeretek CS-ben, hogy mit céloz.

JS-ben is vannak jó dolgok, meg más nyelvekben is.