Új hozzászólás Aktív témák

• floatr veterán

  #6473

  #6464 emvy

  2014-11-16 16:29:10

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #6464 emvy

  #6464 emvy

  Szamomra egeszen elkepzelhetetlen, hogy valaki nem kedveli a lambdakat A list comprehension meg a lambdak tenyleg olyan alapfogalmak a programozasban, mint az 'osztaly', csak aki epp a Java-ba no bele, es massal nem annyira talalkozik, annak fura.

  Az a vicces, hogy a lamdbak hianya miatt, kenyszerusegbol letrehozott patternek annyira beivodtak egy csomo (Java-)programozo fejebe, hogy mostmar az tunik furanak, amit helyettesiteni akartak vele Kicsit olyan, mintha azt mondanad, hogy az "1+2" kod az fura, mert valojaban az kene, hogy Adder a = new Adder(1,2); a.doAdd(); mert az elso az olvashatatlan, es fogalmad sincs, mi tortenik

  List<Integer> ints = new ArrayList<Integer>();
  for (String s : list) {
  ints.add(Integer.parseInt(s));
  }
  
  val ints = list.map(s => s.toInt)

  A masodik (Scala pelda) az azt mondja, amit valojaban akarok csinalni: egy sztringeket tartalmazo lista minden elemebol intet csinalni. Ennyi. A felso peldaban rengeteg a 'zaj', amit mar persze megszokott a Java-s szem, de konkretan nem tartozik az uzleti logikahoz az, hogy pl. deklaralok egy ciklusvaltozot.

  Nekem hiányzik az operátor overloading, ha arra próbáltál célozni. Sőt a friend mechanizmus, és a valódi template-ek is. De ez a funkcionális bohóckodás -- mert ebben a formában az -- nem annyira. A javascript-féle closure is arra jó, hogy elkavard magad a scope-okkal. Nagyon észnél kell lenned, hogy nem rontsd el, és a supportja pedig sokkal drágább, mint a "hagyományos" megoldásoké. Egy épeszű PM nem szereti az ilyen kockázatokat.

Új hozzászólás Aktív témák