Na co všechno je dobrý LISP?

[blizz]

Dobrý programátor je lepič kódu. Práca kvalitného vývojára je založená na kooperácii a deľbe práce. nebude znovu onbjavovať koleso keď ho už objavil niekto pred ním a vyladil ho k dokonalosti, dobrý programátor sa sústredí len na riešenie problému. Väčšinu času venuje štúdiu, knižníc, frameworkov a návrhových vzorov. Je lacný rýchly a efektívny.

a uvedomujes si, ze podle tve logiky autori tech knihoven, frameworku a navrhovych vzoru jsou prave ti spatni programatori? :-]]

Asi si to nepochopil, zaujímavý článok na túto tému je: http://vbnet.cz/blog-clanek--131-dva_programatorske_pristupy.aspx

[Reklama]

[Mirek Prýmek]

Asi si to nepochopil, zaujímavý článok na túto tému je: http://vbnet.cz/blog-clanek--131-dva_programatorske_pristupy.aspx

Tohle je naprostá pravda:

Na Matfyzu nám říkali, že programování je hlavně o teorii a algoritmech, že jazyk nebo technologii se už naučíme za týden. S tím bych si dovolil polemizovat, základy .NET frameworku se za týden pochytit dají, pokud člověk má obecné programátorské znalosti, ale aby člověk programoval pořádně a elegantně, musí mít s touto technologií alespoň půl roku zkušeností.

Programování je už dávno nejenom o znalosti algoritmů a jazyka, ale především o znalosti dostupných nástrojů. Někdo ale má v dané technologii k dispozici tak zoufale málo nástrojů, že má potřebu ostatní ohromovat tím, že má nástroje k vytváření nástrojů...

[JS]

Asi si to nepochopil, zaujímavý článok na túto tému je: http://vbnet.cz/blog-clanek--131-dva_programatorske_pristupy.aspx

Nic proti, ale nejak v tom clanku nevidim ty dva pristupy. O algoritmech toho vim troufam si tvrdit pomerne dost, a presto pokud v praci predpokladam, ze C# neco umi, hledam to v Google. Me prijde, ze vyuzivat uz napsaneho dava smysl vzdy. O tom ale debata "Lisp vs. to ostatni" vubec neni.

[blizz]

...

presne

[Inkvizitor]

Dobrý programátor je lepič kódu. Práca kvalitného vývojára je založená na kooperácii a deľbe práce. nebude znovu onbjavovať koleso keď ho už objavil niekto pred ním a vyladil ho k dokonalosti, dobrý programátor sa sústredí len na riešenie problému. Väčšinu času venuje štúdiu, knižníc, frameworkov a návrhových vzorov. Je lacný rýchly a efektívny.

a uvedomujes si, ze podle tve logiky autori tech knihoven, frameworku a navrhovych vzoru jsou prave ti spatni programatori? :-]]

To právě záleží na situaci. Pokud už adekvátní knihovna existuje, je psaní nové (uděláme si to po svém, ať to stojí, co to stojí) holý nesmysl. Pokud adekvátní knihovna neexistuje, ale existuje přijatelný základ, je nejlepší udělat další abstrakci. Až jako poslední instanci beru vytvoření celé nové knihovny od začátku do konce.

U jazyků to vidím podobně. Pokud je majoritní jazyk (třeba Java) použitelný a máme k dispozici vyspělou platformu a lidi, kteří jazyk ovládají, zůstaňme u ní. Pokud si můžeme zvolit jiný jazyk nad dobrou platformou a je to oprávněné (velikost projektu, schopní vývojáři, zkušenosti s novým jazykem), použijme ten jiný jazyk. Pokud máme  velký existující projekt v Lispu, nebudeme ho přepisovat do jiného jazyka, ale rozšíříme Lisp podle potřeby o nové konstrukce pomocí maker. Ale pokud ta makra mají pouze vytvářet konstrukce, které novější jazyky dávno mají, nevidím moc důvodů pro nový projekt nepoužít jiný jazyk.

Dosud jsme se bavili vesměs na teoretické rovině. Jediné dva praktické příklady, které jsem tu viděl, bylo opožděné vyhodnocení výrazu (uzávěr s pamětí - protiargumentoval jsem lambdou s dekorátorem), uzamykání vstupu do funkce (protiargument opět dekorátor) a viděl jsem dva odkazy (simulace LINQ pomocí Lispu a parsování binárních souborů). Podle mě vesměs nic, co by nešlo v jiných jazycích udělat také za srovnatelných obtíží. Věřím například, že ta lispovská řešení s makry budou po překladu pomocí SBCL/rychlého Scheme kompilátoru rychlejší než třeba Python (u Scaly nebo haskellovské monády už bych byl k tomu zrychlení skeptičtější). Ale pouze v kontextu většího projektu by se vidělo, jak velká je skutečně výhoda použití maker (obdoba Amdahlova zákona).

[Reklama]

[Mirek Prýmek]

Jediné dva praktické příklady, které jsem tu viděl [...] Podle mě vesměs nic, co by nešlo v jiných jazycích udělat také za srovnatelných obtíží.

No ještě jsem sem dával ten příklad s vypsáním xml, to je hezká hříčka, ale o praktičnosti takového řešení by se dalo diskutovat...

Kromě toho tady zaznělo, že pomocí maker by se daly stručně napsat třeba definice spousty tříd, které mají dostatečný společný základ.

Něco jako (pseudokód)

Kód: [Vybrat]

defmacro MyHandler (name)
{
   class ${name}: XYZHandler {
     ...
   }
}

MyHandler(JabberMessageHandler)
MyHandler(ConsoleMessageHandler)
MyHandler(TcpMessageHandler)

handler = JabberMessageHandler()

Jako jo, no... v hodně divokých snech si dovedu představit, že by se to k něčemu mohlo hodit...

[Inkvizitor]

Kromě toho tady zaznělo, že pomocí maker by se daly stručně napsat třeba definice spousty tříd, které mají dostatečný společný základ.

Něco jako (pseudokód)

Kód: [Vybrat]

defmacro MyHandler (name)
{
   class ${name}: XYZHandler {
     ...
   }
}

MyHandler(JabberMessageHandler)
MyHandler(ConsoleMessageHandler)
MyHandler(TcpMessageHandler)

handler = JabberMessageHandler()

Jako jo, no... v hodně divokých snech si dovedu představit, že by se to k něčemu mohlo hodit...

Mně to přijde jako typická násobná dědičnost, snad dokonce pouhý mixin (trait v terminologii Scaly). Ano, pár znaků se při vytvoření každé nové třídy ušetřit dá, ale...

[Mirek Prýmek]

Mně to přijde jako typická násobná dědičnost, snad dokonce pouhý mixin (trait v terminologii Scaly). Ano, pár znaků se při vytvoření každé nové třídy ušetřit dá, ale...

V tomhle jednoduchym pripade jo, ale samozrejme by se to asi dalo pouzit nejak vychytraleji. Nicmene cim vychytralejsi pouziti, tim tezsi bude precist, co vlastne ten kod dela a tim horsi bude i ladeni... Takze to zas takova bomba neni...

P.S. jen tak ze srandy trochu priblbla implementace v Pythonu

Kód: [Vybrat]

# cat test.py
#!/usr/bin/python

def defmacro(name,code):
   # pomocna funkce
   def macrodef(params,code):
      exec code%params in globals()
   globals()[name]=lambda params: macrodef(params,code)

# ukazeme, ze muzeme v klidu dedit z normalniho kodu
class XYZHandler(object):
   def test(self):
      print "XYZHandler.test()"
      print "    self=%s"%(self,)

# timhle nadefinujeme FUNKCI MyHandler, jejimz spustenim
# nadefinujeme konkretni (parametrizovanou) tridu
defmacro("MyHandler","""
class %(className)s(%(superClass)s):
   def test(self):
      super(%(className)s,self).test()
      print "%(className)s.test()"
      print "    self="+str(self)
""")

# nadefinujeme tridu JabberMessageHandler
MyHandler({'className':'JabberMessageHandler','superClass':'XYZHandler'})

# nadefinujeme tridu SuperJabberMessageHandler, ktera dedi z predchozi
MyHandler({'className':'SuperJabberMessageHandler','superClass':'JabberMessageHandler'})

handler1 = JabberMessageHandler()
print "=====> Testuju handler1"
handler1.test()

handler2 = SuperJabberMessageHandler()
print "\n=====> Testuju handler2"
handler2.test()


Kód: [Vybrat]

# ./test.py
=====> Testuju handler1
XYZHandler.test()
    self=<__main__.JabberMessageHandler object at 0x1004cc890>
JabberMessageHandler.test()
    self=<__main__.JabberMessageHandler object at 0x1004cc890>

=====> Testuju handler2
XYZHandler.test()
    self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>
JabberMessageHandler.test()
    self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>
SuperJabberMessageHandler.test()
    self=<__main__.SuperJabberMessageHandler object at 0x1004cc8d0>



P.P.S. člověk musí mít hodně drzosti, aby tvrdil, že takhle "vlastně vytvořil nový jazyk"...

[deda.jabko]

Schválně, jestli si uděláš představu o přínosnosti ZDRBUGU pro tvoje auto:

jelikoz jsi prohlasoval, ze vis, co jsou makro, tak jsem tak nejak predpokladal, ze vis, ze se pouzivaji k prepisovani kodu. uznavam, byla to ma chyba.

Nebudeš mít potřebu ze mě vytáhnout, v čem je kurnik teda ten ZDRBUG tak dokonalý a jedinečný?

nevim, ale urcite nebudu prohlasovat, ze vim, co to je... a kdyz mi nekdo nabidne materialy k nastudovani, tak si je prectu a nebudu se tvarit povysene, protoze ostatni jsou takovi idioti a neumi mi to vysvetlit

U jazyků to vidím podobně. Pokud je majoritní jazyk (třeba Java) použitelný a máme k dispozici vyspělou platformu a lidi, kteří jazyk ovládají, zůstaňme u ní.

...s takovym pristupem dodnes piseme kod v assembleru :-]]

simulace LINQ pomocí Lispu

LINQ je hezky priklad. Aby sel pridat LINQ do C#, tak bylo potreba udelat zasadni zasahy do specifikace jazyka, kterou navic musel udelat microsoft... a ty to zmeny tam budou trcet navzdy, kvuli zpetne kompatibilite. V LISPu by to byla jen knihovna maker, kterou by pouzivali jen ti co ji chcou/potrebuji a technicky by sis ji mohl napsat ty sam.

[Mirek Prýmek]

@deda.jabko: je to furt dokola, nemám potřebu v tom pokračovat po 101ní

[JS]

@deda.jabko: je to furt dokola, nemám potřebu v tom pokračovat po 101ní

No vidis, a pritom by stacilo, aby jsi uznal, ze s tim LINQ ma deda.jabko uplnou pravdu.

[Mirek Prýmek]

No vidis, a pritom by stacilo, aby jsi uznal, ze s tim LINQ ma deda.jabko uplnou pravdu.

Jasne, vsichni mate pravdu. Kdyz jste osviceni, tak co holt mate delat

Jen tak pro osvezeni znovu citat Pavla Tišnovského (cvičená opice?):

Pridani nove syntakticke kategorie je tedy velmi jednoduche, protoze vlastne samotna syntaxe zustava nezmenena (treba smycky v LISPu neni nic jineho nez specialni forma)

http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/nazory/153290/

(pochopitelne zustalo bez odpovedi...)

[Inkvizitor]

U jazyků to vidím podobně. Pokud je majoritní jazyk (třeba Java) použitelný a máme k dispozici vyspělou platformu a lidi, kteří jazyk ovládají, zůstaňme u ní.

...s takovym pristupem dodnes piseme kod v assembleru :-]]

To právě ne. Domény, které se pomocí výpočetní techniky řeší, přerostly použitelnost assembleru už v době Lispu. Kdyby ne, jazyky vyšší úrovně by nerostly jako houby po dešti.

simulace LINQ pomocí Lispu

LINQ je hezky priklad. Aby sel pridat LINQ do C#, tak bylo potreba udelat zasadni zasahy do specifikace jazyka, kterou navic musel udelat microsoft... a ty to zmeny tam budou trcet navzdy, kvuli zpetne kompatibilite. V LISPu by to byla jen knihovna maker, kterou by pouzivali jen ti co ji chcou/potrebuji a technicky by sis ji mohl napsat ty sam.

Bezesporu. Jenže podobné DSL lze dnes napsat i ve Scale, v Ruby nebo v Pythonu, dokonce i v C++. Akorát syntaxe bude trochu jiná.

[deda.jabko]

Jasne, vsichni mate pravdu. Kdyz jste osviceni, tak co holt mate delat

to je smutne

Pridani nove syntakticke kategorie je tedy velmi jednoduche, protoze vlastne samotna syntaxe zustava nezmenena (treba smycky v LISPu neni nic jineho nez specialni forma)

http://www.root.cz/clanky/lispova-makra-aneb-programovatelny-programovaci-jazyk/nazory/153290/

to s rozsirovanim syntaxe je bezne zkratka, protoze vysvetlovat nekomu, kdo nezna lisp, co je to specialni forma, by nemelo smysl.

jinak syntaxe jako takova v LISPu rozsirit opravdu jde, protoze v LISPu jde preprogramovat i reader, ktery se stara o nacteni jednotlivych vyrazu. imho, by me zajimalo, kolik dalsich jazyku jeste neco takoveho umi. :-]]

[Mirek Prýmek]

jinak syntaxe jako takova v LISPu rozsirit opravdu jde, protoze v LISPu jde preprogramovat i reader, ktery se stara o nacteni jednotlivych vyrazu. imho, by me zajimalo, kolik dalsich jazyku jeste neco takoveho umi. :-]]

Gratuluju.