enpassant blogja

OOP Polimorfizmus vs FP Monomorfizmus

Kérés-válasz (request-response) stílusú actor kommunikációnál a tell alapú (Response Collector) kommunikációt javasolják az ask mintájú helyett. Ez leegyszerűsíti az actor kommunikációt úgy, hogy a legtöbb válasz kezelési feladatot egy kitüntetett actor alá helyezi.
Ahelyett, hogy a timeout és hibakezelési logikát több helyre kellene felvennünk az actor rendszerben, az actor-ok egyszerű válaszokat adnak a kérésekre a tell mechanizmus segítségével, mialatt a Response Collector actor a beérkezett elegendő válasz alapján válaszol a kérést feltevőnek illetve kezeli a timeout-ot és az egyéb hibákat.

tl;dr
Egyik korábbi blogomhoz érkezett egy ilyen hozzászólás:

Idézet:
"Eddig bármikor is vettem vmit automatából, sose lett új pénztárcám, és sose termett előttem egy másik automata."

Sokan vallják a fentieket, vagyis, hogy a valóságban nem képződnek új objektumok, hanem egy létező objektum állapota változik csak meg.
Ez a hagyományos OO szemlélet.
A másik szemlélet az FP szerinti, ami ellen a fenti idézet is irányul, vagyis, hogy ha változik egy objektum, akkor azt új objektumnak tekintem.

Sokan OO vs FP ellentétként élik meg, magyarázzák, de a fő gond nem az OO-val van, hanem a mutabilitással. Az OO-t lehet immutable-ként is használni, úgy sokkal kevesebb gond van vele(, illetve mutable-ként is, ha üzenetváltással kommunikálunk).
Ha már itt tartunk, akkor megjegyezném, hogy szerintem a következő programozási paradigmákat érdemes használni (csökkenő fontossági sorrendben), ha egyszerű, könnyen érthető, de hatékony programot szeretnénk készíteni:

1. FP
2. immutable OOP
3. mutable (OOP) üzenetekkel (pl. akka, smalltalk)
4. egyéb mutable

Ha valakit érdekel a clean és simple code, akkor itt olvashat róla:
OKTV-s informatika versenyfeladat átalakítása tiszta és egyszerű kóddá

A történet folytatódik a 2. és egyben befejező résszel.

A napokban találtam a témában egy nagyon jó videót Ken Scambler-től.

A videóban szépen sorra veszi, hogy milyen tervezési hibák miatt használunk Mock-ot és Stub-ot, valójában ezek mit szeretnének kiváltani; és milyen módon tervezhetjük át a kódot, hogy ne legyen szükség rájuk, aminek hatására:

• modulárisabb,
• jobban újrafelhasználható,
• egyszerűbb,
• kevesebb kód,
• kevesebb változó rész,
• Mock eltűnik,
• Stub eltűnik

Az implicit konverziónak két fontos előnye van:
1. Látszólag kiegészíthetjük egy osztályunkat új metódusokkal
2. Szép DSL-ek készíthetők vele

A mostani megvalósításra szép leírást találunk itt: Add Your Own Methods to the String Class

Nekem ez az implicit konverzió nem igazán tetszik. Feleslegesnek érzem, hogy egy plusz osztályt származtassunk a meglevőből. Illetve csak az OO részt lehet DSL-ként használni, a "funkcionális" részt nem. A DSL kinézetet akkor kapjuk, ha egy osztály egy metódusát egy paraméterrel (vagy paraméter nélkül) hívjuk, akkor elhagyható a pont és zárójel, tehát az OSZTÁLY.metódus(PARAMÉTER) használható így is: OSZTÁLY metódus PARAMÉTER.

Keeping Scala Simple, gondolatok Noel Welsh-től.

Simplicity In Scala Design, egy remek videó a témában Bill Venners-től.

Az egyszerűség művészetéről (The Art of Simplicity) Venkat Subramaniam-tól egy kicsit hosszú, de nagyon szuper videó, amit szerintem minden programozónak látnia kellene. Sajnos hiányoznak a képernyőképek, de így is nagyszerű!

Szerk.: The Art of Simplicity, ezen néha látszanak a képernyőképek.

A napokban vásároltam egy Canon MG5350-es multifunkciós nyomtatót.
Utánanéztem a Linux-os támogatásnak és úgy találtam, hogy van hozzá (félhivatalos). A Canon ad hozzá driver-t, de hivatalosan csak Windows-hoz és Mac-hez van. A magyarországi oldalon el sem érhetők ezek a driver-ek.
Az ázsiai honlajpukon elérhetőek a Linux-os driverek.

A következő leírásban Ubuntu 11.10 alatti telepítést írom le, de más Linux rendszereken is hasonlóan történhet.

Olvastam trey régebbi cikkét, amely nagyon hasznos volt számomra.
A leírás alapján fel is tettem a kedvenc csatornáimat. De aztán egy kicsit változtattam volna a kinézeten is. Ami lehetséges is volt, de egy pár, nekem nem tetsző problémába futottam:

• A deskletek letakarják a desktopomat, ami olyan, mint az igazi asztalom :-) Teli van mindenféle fontos és kevésbé fontos dologgal.
• Nem nagyon egyszerű egy jól kinéző, témázható deskletet írni (legalábbis nekem :-)
• Csoportba rendeztem volna őket. De a csoport létrehozása után a deskletjeim egy részét automatikusan az új csoportba rakta, egy részét pedig a régiben hagyta. :-( Probáltam volna visszatenni őket, de nincs GUI támogatás. Sebaj, a konfigjait átírom. Sajnos azok nem valami könnyen érthető formában vannak tárolva.