Názory k článku Domain-Specific Language: programování pro každého
-
Michaelson (neregistrovaný)Ja zvycajne nerad kritizujem, ale tento clanok vazne nie je nic moc... A prave DSL tema by si zasluzila lepsi clanok. Nechapem moc co bolo pointou tohto clanku. Na to aby to oslovilo a prilakalo ludi, ze "aha aj toto existuje", by to muselo byt lepsie vysvetlene, motivacnejsie...
No aspon ze su tam tie odkazy... aj ked chvilkovym googlovanim sa daju najst aj lepsie, teda podla mna...
Ako common lisp programatora ma kvalita tohto clanku zarmucuje o to viac, pretoze pochopenie a pouzitie DSL povazujem za jeden z dolezitych faktorov pri tvorbe softveru... -
anonymníRuzny jazyky me zajimaji, aspon pro prehled jsem jich opravdu par procet, vcetne takovych jako Tcl, Lisp/Scheme, PostScript. Ruby jsem jeste nezkousel a netusim, jestli jsem uz videl nejaky jiny DSL nez tady.
Mozna je clanek opravdu jenom ne-dobre napsanej, protoze mi pripada, ze DSL jsou jenom pseudojazyky s konkretnim zamerenim - Ruby on Rails pro web, Rake pro automatizovanou praci s balikama. Celkove to ale na me pusobi, jako kdyz pomoci low-level jazyka vytvorim parser pro nejakej specificky zamerenej high-level jazyk pro konkretni aplikaci. Neco jako kdyz v assembleru napisu prekladac C nebo pomoci C interpret Perlu. Chapu to spravne?
Chapu teda spravne, ze napr. muzu navrhnout svuj vlastni DSL treba na parsovani HTML stranek s vystupem na tiskarnu nebo do souboru a pomoci Perlu napsat interpret? -
Michaelson (neregistrovaný)Skutocna pointa DSL je, ze namiesto toho, aby ste ohybali hlavu a prisposobovali sa jazyku, tak si prisposobujete jazyk pre seba, resp. pre problem ktory konkretne riesite.
V jednoduchosti povedane (nekamenujte, viem ze to nieje vedecke a presne:): Ide o filozofiu vyvoja softveru, pri ktorom postupujete odspodu hore, a to tak, ze ako postupne chapete lepsie a lepsie dany konkretny (specificky) problem, tak si pre tento specificky problem vytvarate Domain Specific Language, a to taky, aby sa vam co najlepsie v tomto jazyku dany problem podarilo vyriesit. Toto vedie (ked sa to vie) k tvorbe efektivnych (aj co sa tyka vypoctovej, resp. algoritmickej efektovnosti) a "maloriadkovych" programov, lahko modifikovatelnych a skalovatelnych...
Samozrejme to ma aj nevyhody... (aj ked podla mna nie podstatne;)
Medzi relativne casto spominane nevyhody patri napriklad to, ze sa niekto, kto pride po Vas na dany projekt, musi ucit Vami vymysleny DSL a pochopit ho, ako aj kod v nom napisany... toto je vsak podla mna trochu "nefer" vycitka. Pretoze ktokolvek kto pride po Vas na dany projekt, tak bude musiet pochopit Vami vytvoreny kod, nech uz je napisany v assembleri alebo v Lispe. A pokial DSL navrhnete naozaj dobre, tak zaucenie sa noveho programatora do projektu podla mna paradoxne urychli, aj ked bude musiet pochopit Vas DSL... dovod: menej kodu, vystiznejsie a priamociarejsie vystihnute "gro" problemu/programu/algoritmu...
Ak to niekoho zaujima (a neodradil ho tento nie moc podareny clanok), tak nech trosku pogoogli... ja som uz na prvych odkazoch nasiel omnoho zaujimavejsie clanky o tejto oblasti (ang. jazyk samozrejme nutnost). Tiez doporucujem vyhladat terminy ako "glass barriers in languages" a podobne... velmi zaujimave citanie pre kohokolvek, kto sa aspon okrajovo zaujima o computer language science (podobne ako ja;)... -
anonymníJo, takze jsem to pochopil relativne presne. Priklad s assemblerem, Ceckem a Perl byl spis prehnanej, ale je to taky urcity zpusob predvedeni DSL, napr. misto psani nekolika instrukci v assembleru mam jednu funkci printf nebo jeden prikaz for, dale pak misto psani nejaky slozity konstrukce v Cecku (nepocitam nejaky knihovny) mam v Perlu operator "=~" pro regularni vyrazy. A pod "specifickym probleme", ke kterymu potrebuju tyhle DSL jazyky (PERL a C), si muzu predstavit problem "programovani". Pak muzu nad Perlem udelat dalsi DSL, kde budu psat jednoduche prikazy ve stylu SED nebo AWK a to pak predhodim Perlu - ten to zpracuje a bude provadet vlastnimi silami (funkcemi a operatory) cinnost zadanou pomoci meho DSL. Cely PERL ale bude taky jenom DSL nad jazykem C, ktery bude provadet nizsi operace podle zadanych PERL prikazu. No a jazyk C bude zase jenom DSL nad assemblerem a assembler bude provadet zadany C prikazy pomoci strojoveho kodu.
Podle tehle definice jsou DSL jazyky vsechny ty mozne sablonovaci systemy nad PHP a Perlem a Ceckem. Jinak zapis XML by se mi libil asi vic, protoze ten uz ma clovek vetsinou zazity a navic, pokud by byl pro vice projektu, tak se ho clovek uci pouze jednou a pak uz jenom seznam funkci a parametry, ktery by se musel ucit vzdy. Kdezto kdyz kazdy bude delat vlastni DSL, tak se ucit kazdy ruzny DSL s ruznymi vlastnostmi bude docela peklo, ikdyz budou treba dobre navrzene.
Ono, kdyz se to tak vezme, tak prakticky dobre navrzeny API je taky DSL. Ted jsem snad pochopil rozdil v tom priklade API a DSL na zacatku clanku. Je to sice hezkej priklad, nicmene spis chapu ten zapis v API, nez v DSL a to ani neni receno v jakem jazyku je to API zapsane. Kdezto k tomu DSL bych potreboval nejaky manual, abych pochopil, co to vlastne udela. Jinak zapis na jeden radek je pouze veci jazyka, pripadne navrhu trid, napr. v perlu muzu napsat
Coffee::new('size'='Venti', 'fat'=>NON_FAT ....);
a budu to mit stejne jako v DSL na jeden radek a taky prehledne. -
Michaelson (neregistrovaný)Z wikipedie:
"A domain-specific programming language (domain-specific language, DSL) is a programming language designed for, and intended to be useful for, a specific kind of task. This is in contrast to a general-purpose programming language, such as C or general-purpose modeling languages like UML."
Zial musim teraz prec, takze Vam nemozem napisat podrobnejsiu odpoved... ale nechapete to vobec dobre (mozno mojou vinou...) -
petr_p (neregistrovaný)Wikipedie pokračuje těmito příklady:
Examples of DSLs include spreadsheet macros, YACC grammars for creating parsers, regular expressions, Generic Eclipse Modeling System for creating diagramming languages, Csound, a language used to create audio files, and GraphViz, a language used to define and create visual representations for directed graphs.
Podstatné je, že vyšší jazyk (DSL) řeší jen jednu věc a ostatní funkcionalitu z nižšího jazyka ztrácí. Je to daň za lepší srozumitelnost a kratší zápis. Já bych DSL definoval jako jednoúčelový jazyk:DSLs focus on doing one kind of task well. For instance, GraphViz is designed to create images of graphs in a variety of formats, but GraphViz lacks the capability to perform some basic tasks, e.g., accessing a network socket, receiving additional user input, or manipulating strings.
Po pravdě řečeno, úvod na Wikipedii (do obsahu) mi přijde mnohem srozumitelnější než tento článek na Rootu. -
delphym (neregistrovaný)"..... Já bych DSL definoval jako jednoúčelový jazyk:"
Mno, vsak taky jo. Nechapu co tady vsichni porad resi.
Myslim si, ze anglicky nazev DOMAIN SPECIFIC.... jasne rika, ze se jedna o jazyk na specificky problem/ucel/oblast ci ja nevim ja keste by se to dalo prelozit.
zkratka mi cely ten clanek a diskuse k nemu prijde jako noseni drivi do lesa.
mejte se. -
Hm, budu vsetci okolo toho DSL tancovat, aky je uzasny, resp, aky je naprd? Alebo uz niekto KONECNE povie aku to ma syntax, kde zozeniem prekladac, ako nakodim Hello world?? Je to vobec pre programatorov, alebo sa o tom len tak rozprava? Fakt nemam najmensiu sajnu z tohto clanku ani z prispevkov :-( -
sarimak (neregistrovaný)My 2 cents:
Dalsi zpusob vyuziti DSL je ve spojeni s grafickym modelovanim architektury. V soucasne dobe jsou dva svety - IBM a jeho UML 2 v kombinaci s E-R datovymi modely vs. Microsoft a jeho DSL pro .Net a datovy meodel pro SQL Server. K tomu se jeste da pripocist BPMN pro modelovani workflow/procesu.
UML je obecny modelovacy jazyk, ktery ma sirokou semantiku a hodi se teoreticky na vetsi mnozstvi popisovanych problemu - dani za to je nutnost dodavat k modelu upresneni, co kterej element znamena. Dovedeno do extremu, nejobecnejsi modelovaci jazyk je system "krabicka", "cara", kde krabicka je cokoliv od class, pres DB table, stav konecnyho automatu, blok kodu/element vyvojovyho diagramu apod. a cara spojuje krabicky, tedy napr. naznaceni dedicnosti mezi tridama, vazba DB tabulek pres klic, povolenej prechod mezi stavama, souslednost vykonavani bloku apod.
Na druhou stranu DSL jsou jednoucelovy, na miru konkretnimu modelovanymu problemu. Semantika je timpadem implicitni a nemusi se dodatecne vysvetlovat. Na druhou stranu se oak clovek musi ucit miliardu ruznejch jazyku a hlavne musi resit, jak modely/kod v ruznejch jednoucelovejch jazycich vzajemne propojit, aby mu to vubec nejak pomohlo pri praci - to obvykle resi transformace pomoci QVT.
Oba pristupy maji svoje vyhody a nevyhody, tak jako jde psat web v C, ale vetsina lidi sahne spis po PHP. Operacni system v PHP by mozna taky sel napachat, ale C je urcite lepsi volba...
Zajimave zkratky pro googleni: DSL, UML, BPMN, BPEL, BPEL4WS, E-R modeling, QVT, OCL, EMF, GMF, ECore, MDD, MDA, OMG, JET, xPand, XSD, MOF, Domain modeling, XSLT
Celkem zajimave je tohle vsechno skloubeny v Borland Together 2007 (nastroj na vytvareni modelovacich nastroju), ale IMO je tahle zalezitost jen pro hodne velky firmy s dostatkem casu na badani a vrtani se v uchylnejch XML transformacich... -
sarimak (neregistrovaný);-)
Ono kdyz clovek nejakou chvili cte texty plny magickejch formuli jako metametamodel a transformace, tak mu celkem snadno muze sibnout, to souhlasim... ;-)
Proc smichat? DSL se v terminologii pro modelovani v MS Visual Studiu pouziva a jelikoz jde tvorit vlastni DSL i na urovni modelu, prislo mi zajimavy to zminit. Ale souhlasim, ze je to pro vetsinu lidi dost offtopic tema a vysledna produktivita prace pri pouziti tehle technik je diskutabilni...
Jdu si zas slehnout trochu XML, peknej den! ;-) -
Na druhou stranu DSL jsou jednoucelovy, na miru konkretnimu modelovanymu problemu. Semantika je timpadem implicitni a nemusi se dodatecne vysvetlovat. Na druhou stranu se oak clovek musi ucit miliardu ruznejch jazyku a hlavne musi resit, jak modely/kod v ruznejch jednoucelovejch jazycich vzajemne propojit, aby mu to vubec nejak pomohlo pri praci - to obvykle resi transformace pomoci QVT.
Tak tak. XML je mozna ukecany (pak ale nechapu lidi, co nadavaji, ze je to clovekem spatne editovatelna vec), ale i kdyz jsou tuny ruznych XML dialektu, tak porad vim, ze je to XML a ze muzu pouzit XSLT, XPath a dalsi... -
Tor (neregistrovaný)Pokud někdo chce vidět, jak se DSL dělají pořádně namísto psaní furt toho samého jazyka, nechť se podívá třeba sem:
http://www.venge.net/graydon/talks/mkc/html/mgp00001.html -
Tor (neregistrovaný)Dokázal převést Makefile do formy rychlého nativního kompilovaného programu, který lze spouštět samostatně a bez dalších závislostí (šel na to přes generování funkcí v jazyce C pro jednotlivá pravidla z Makefile a možná je ten příklad poněkud zbytečně komplikovaný).
Nešlo mi ale o to, jakými prostředky se dá nebo nedá něčeho docílit. Podstatné bylo, že zvolil určitý jazyk (o optimalitě syntaxe Makefile můžeme vést spory, ale předpokládejme, že jde o nejlepší možný) a pak řešil, jak dosáhnout jeho zpracování. Zatímco tady předložený příklad z RoR ukazuje, jak využít syntaxe Ruby, abychom se mohli tvářit, že jde v zásadě o jiný jazyk a mohli tomu dát vznešené jméno. -
Napsání skromnějšího interního DSL přitom je práce na několik málo hodin. A co vy, zkoušeli jste si již také nějaký DSL napsat?
Ano, zkouseli. Nekolik. Nekolik se dokonce stale pouziva :-) Ale neni to tak snadne, jak autor pise. Vytvorit interpret DSL pro nejaky jednoduchy jazyk, kde si uzivatele mohou psat jednoduche skriptiky je snadne - parser pomoci bisonu/javacc/antlr/smacc, pak interpreter pattern. Problem ale je:- jak zajistit API do aplikace takove, aby bylo bezpecne
- jak takove skripty ladit. Napsat interpret jazyka je snadne, napsat pro nej debugger je horsi.
-
broukoid (neregistrovaný)Mozna se pletu, ale neni DSL nahodou jenom buzzword pro neco co se uz desitky let bezne pouziva? Snad kazdy komplikovanejsi software ma nejaky svuj vnitrni jazyk/makrojazyk a jejich pouzivani zvlast ve svete opensource je vic nez bezny... takze CO je na tom novyho? to ze to nejakej blbecek kterej se vcera naucil ruby nove pojmenoval? To ze se tomu najednou rika zkratkou?
..nehlede na to ze mam dojem (nebo to aspon ja delam) ze treba programovani v common lispu je prave o tom ze vlastne upravuju jazyk tak aby odpovidal resenymu problemu... takze "dsl" je vlastne asi tak 50 let stara vec... -
Tor (neregistrovaný)V zásadě si taky myslím, že to je další buzzword. V zásadě jde o zvýšení úrovně abstrakce a obvykle i o nahrazení imperativního paradigmatu deklarativním. Jinými slovy, imperativní jazyky ze své podstaty omezují úroveň abstrakce tím, že jsou syntakticky poměrně složité a mají snahu uchylovat se k popisu toho "jak něco udělat", namísto toho, aby se omezily na popis "co se má udělat".
Dále tvrdím, že "interní DSL" a "externí DSL" jsou v zásadě hodně odlišné kategorie. Dva příklady, které autor článku, ukazují extrémy, které mají spolu jenom málo společného.
"Venti half-caf, non-fat, extra hot, no foam, no whip latte" je příklad, jak deklarativně vyjádřit určitou věc nejpřirozenějším možným způsobem a s použitím vlastního jazyka. Příklad z RoR (mimochodem s tiskovou chybou v prvním řádku definice třídy) je poměrně typické dělání velblouda z komára. Je pěkné, že tvůrci API umožnili programátorovi použít deklarativní způsob zápisu a že má k dispozici nějaký syntaktický cukr. Ve skutečnosti ale podobné věci jdou udělat v podstatě v kterémkoliv jazyce a je jenom otázka, nakolik bude daný způsob zápisu úsporný a elegantní. Věci jako podpora klíčových parametrů, hashů, lambd apod. je samozřejmě výhodou. Ale pokud nemá jazyk možnost rozšiřovat syntaxi (makra apod.), je směšné mluvit o nějakém DSL. Je to furt ten samý GPL. -
Michaelson (neregistrovaný)..nehlede na to ze mam dojem (nebo to aspon ja delam) ze treba programovani v common lispu je prave o tom ze vlastne upravuju jazyk tak aby odpovidal resenymu problemu... takze "dsl" je vlastne asi tak 50 let stara vec...
Uplny suhlas... ale nove pomenovanie mozno oslovi novu generaciu...
Hadajte odkial je toto? :)
Ordinarily technology changes fast. But programming languages are different: programming languages are not just technology, but what programmers think in. They're half technology and half religion. And so the median language, meaning whatever language the median programmer uses, moves as slow as an iceberg. Garbage collection, introduced by Lisp in about 1960, is now widely considered to be a good thing. Runtime typing, ditto, is growing in popularity. Lexical closures, introduced by Lisp in the early 1970s, are now, just barely, on the radar screen. Macros, introduced by Lisp in the mid 1960s, are still terra incognita. -
Kvakor (neregistrovaný)Ze by http://www.paulgraham.com/avg.html , z "Beating the Averages" od Paula Grahama? Pridam se take se svym polenem do mlyna, tentokrat s od Philipa Greenspuna:
Philip Greenspun's Tenth Rule of Programming:
Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. -
Pavel Tisnovsky (neregistrovaný)Ze zacatku se priznam, ze moc nechapu vyznam terminu DSL, vzdyt neco podobneho existuje uz nekolik desetileti a IMHO nema smysl to pojmenovavat (asi dalsi zkratka kterou je mozne obalamutit managory - http://i.idnes.cz/07/113/maxi/ZRA1f5393_e_dil_26.jpg).
Co napriklad JSON? (http://json.org/) Jestli i toto je DSL, tak je to docela dobry priklad na jazyk, ktery se snazi obchazet mnohdy zbytecne slozitou kosatost XML. Pokud programator veri datum, ktere prichazi, je "nacteni" dat otazkou jednoho evalu. -
anonymníZrovna dnes jsem psal o tom jak je jednoduche napsat vlastni jazyk pro Parrot VM.
ČLÁNKY DO MAILU
