Tento argument naprosto nechápu.
Jeste jednou. Jde o to, ze dany vzor vysvetlime lidem, ale uz ne pocitacum. V pocitacovych jazycich takovy pristup nedava smysl.
Vezmi si abstrakce (vzory) ve funkcionalnim programovani, treba monadu. Kdyz pouziji v Haskellu monadu, jasne to pocitaci rikam, mam tam na to prislusnou abstrakci (v tomto pripade typovou tridu). A clovek, ktery to cte, nemusi badat, zda jsem pouzil monadu - proste to z toho kodu vidi. Mohl bych ten kod napsat i tak, ze by se pouzila monada (tedy by vypadal monadicky), ale pocitaci bych to nerekl (proste vyhnul se explicitnimu pouziti typove tridy Monad, a napsal bych si to co dela monada na kolene). Ale to by bylo mene citelne, a vice nachylne k chybam.
Ta druha situace nastava s GoF navrhovymi vzory. Neni to tak, ze by nesly formalne definovat (i kdyz vetsinou je vysledek trivialni) - viz ta prednaska o vzorech v Haskellu, kterou jsem postoval par prispevku zpet. Problem je v tom, ze si jejich zastanci odmitaji pripustit, ze nejenze to formalne definovat (a tedy abstrahovat v programovacim jazyce) lze, ale je to i vyhodnejsi (zlepsuje to citelnost kodu).
Pokud vím, Java nemá LISP makra z daleko prostšího důvodu: nepatří do "mainstream" imperativního jazyka s celkem konzervativní koncepcí.
To, ze nema makra, ovsem neznamena, ze nemusi resit problemy, kvuli kterym se makra pouzivaji, napriklad generovani kodu. To se pak v Jave resi zbytecne komplikovane (generovani v IDE, XML, atd.). Zase, jde o to, aby programatori nemuseli ad hoc resit problemy, na ktere by mohly v jazyce existovat vhodne abstrakce (nemusi to byt nutne makra).
Chapu, ze pro nekoho, kdo ty koncepty treba dobre nezna, to muze byt tezke prijmout, ze se daji veci delat lepe. Ja se take v minulosti dopoustel teto chyby.