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

• #11588 Aethelstone addikt btraven #11585

  Új Válasz 2021-06-21 07:31:48 #11588

  Ú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

  Privát üzenet küldése

  

  Aethelstone

  addikt

  válasz btraven #11585 üzenetére

  Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt.
  
  Nah jah, de akkortájt még nem is kellett annyi minden És hidd el, hogy akkoriban vért kellett hugyozni annak a megírásával, amit most pár, jól irányzott annotációval százszázalékos biztonsággal meg tudsz oldani. Ilyen fejlesztői napidíjak mellett nem rentábilis egy problémát napokig reszelgetni, amikor triviális megoldás is van

• #11587 floatr veterán btraven #11585

  Új Válasz 2021-06-20 14:39:03 #11587

  Ú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

  Privát üzenet küldése

  

  floatr

  veterán

  válasz btraven #11585 üzenetére

  A funkcionális elemek, ha jól használják őket, leginkább azért jók, mert elemi alkotóegységek. Egy ilyen elem könnyen cserélhető, karbantartható és tesztelhető

• #11586 Drizzt nagyúr btraven #11585

  Új Válasz 2021-06-20 12:43:59 #11586

  Ú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

  Privát üzenet küldése

  

  Drizzt

  nagyúr

  válasz btraven #11585 üzenetére

  "Nem lett bonyolult a helyzet ezzel a lambda meg stream-ekkel?"
  Nem, sokkal egyszerűbb lett. Egyébként lambdát nem kötelező használni, ahol tudok inkább method reference-et használok. A streamnek meg fontos képessége a lazy eval, meg a concurrency support. Bizonyos problémákat tök egyszerűen, szépen, elegánsan és hatékonyan meg lehet oldani funkcionális eszköztárral, amit amúgy bonyolultan/csúnyán lehet megoldani nélküle.
  "Annak idején egy fejlesztőnyelv/eszköz-ben csak az volt ami nagyon kellett. Minden le volt dokumentálva és minden úgy működött ahogy a doksiban volt."
  Ez ma is így van. Maximum 1-2 szinte már sosem használt nyelvi elem léte lenne megkérdőjelezhető, de azok meg maradnak némi backward compatibility miatt. Az meg ha esetleg azért kérded ezt, mert szerinted a Stream felesleges, akkor egyszerűen még nem éreztél rá. Nélküle nagyon szar lenne az élet, ezt pár évi gyakori Stream használóként mondom. Nézz végig valamilyen alap fukncionális progamozást traininget, után egyértelműnek kellene lennie miért ilyen fontos dolog.
  "Most már nehéz a programozó élete. A sok nyílt forráskódú, ingyenes cuccban az egyik fele nincs dokumentálva a másik fele meg hibásan működik vagy éppen sehogy. Ugye azért nyílt, mert majd kijavítod magad ha nagyon kell. Csak nem képzeled hogy ingyen még hibátlan is legyen?"
  Ez megint nincs így. A lefontosabb, legnépszerűbb framework/libek leggyakrabban használt funkciói eléggé stabilak, ritkán kell körbebástyázni őket. A probléma az esetek 95%-ban abból adódik, hogy valaki megspórolja az alapjaik megismerését és anélkül kezdi őket használni valami olyan célra, amire nem feltétlenül alkalmasak. Még ha elő is fordulnak bugok, sokkal előrébb jársz, ha valami libet használsz rájuk, mintha 0-ról kezdenéd megírni. Sokkal tovább tartana, s a minősége is szinte borítékolhatóan rosszabb lenne.
  Az utóbbi évekből pár dolog, aminek én nem voltam elégedett a dokumentációjával: annotation processor, Spring boot property source használat belsőségei. De az is lehet csak nem a megfelelő dokumentációt olvastam. Ráadásul Java-ban az se megy ritkaságszámba, hogy korábbi open source lib a nyelv részévé válik, pl.: Joda-time.

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