🚀 go-pugleaf

> Przyklady mozna mnozyc.

OK. Ja pisalem raczej o tych projektach, w ktorch chyba wierzono ze jak kod
bedzie sie generowal, ze jak beda modele, bedzie nowoczesnosc itp, to bedzie
dobrze.

> >Czasem tez precyzuje sie, ze jakis "ekspert" bedzie dla konkretnej firmy,
> >konkretnego produktu i konkretnej domeny definiowal ten domain
> >language, ktory potem bedzie z powodzeniem uzywany do tworzenia softu. To co
> >dla mnie wyglada na "haczyk" jest nastepujace: jak ten ekspert bedzie
> >definiowal ow jezyk, co to za magiczne narzedzie bedzie posiadal do
> >definiowana jezykow domenowych? Zagadnienie jest chyba nietrywialne, a kilka
> >prob stworzenia czegos takiego, ktore widzialem, konczyly sie kompletnie
> >nieuzytecznym narzedziem. Vide - http://www.jetbrains.com/mps/
> 
> Ogolnie chodzi o to, jak mniemam, aby miec ogolne narzedzia
> (meta-narzedzia?...) do a) specyfikowania domain specific components,
> b) generowania "glue code" lub generowania generatorow "glue code".
> Nei wydaje  mi sie zeby to bylo niemozliwe/skrajnie trudne.

Stworzenie ogolnego narzedzia moze byc bardzo trudne. To tylko taka moja
intuicja, ale postaram sie ja uzasadnic. W pewnym sensie takie narzedzia juz
istnieja - narzedzia do tworzenia kompilatorow i parserow. Bo to o czym
piszesz imho sprowadza sie do wymyslenia jezyka i stworzenia kompilatora.
Kluczem jest oczywiscie to, ze jezyk powinien dobrze oddawac istote konkretnej
domeny, a kompilator powinien generowac dobry kod. Wg mnie sa istotne dwie
sprawy: a) kiedy mozna uznac, ze projekt powinien sie zaczac od stworzenia
dedykowanego jezyka/kompilatora, a kiedy nalezy to sobie odpuscic? b) ja mam
pewne problemy z wyobrazeniem sobie powszechnej praktyki polegajacej na
tworzeniu jezykow/kompilatorow w trakcie czy przed poczatkiem projektu - moje
obawy dotycza tego, ze w wielu sytuacjach podobny zabieg moze zwielokrotnic
zlozonosc problemu, a nie uproscic. Wydaje mi sie, ze podobne problemy widza
rowniez proponenci DSM, bo mimo, ze narzedzia do parserow/kompilatorow sa
obecne nie od wczoraj, to jednak chyba nie nadaja sie na "meta-narzedzia" o
ktorych piszesz. Zeby DSM bardziej przemowilo do przemyslu, te
"meta-narzedzia" powinny byc prostsze niz narzedzia do parserow/kompilatorow,
a jednoczescie oferowac podobne, albo nawet wieksze, mozliwosci. A to jest
problem.

BTW: Jesli pokazanie probek kodu w ,,"domain language" do supply chain
management'' nie spowoduje wyciek cennych informacji z Twojej firmy albo
innych strat, moglbys pokazac?


A.


-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/