W dniu wtorek, 14 stycznia 2014 21:05:23 UTC+1 użytkownik Wojciech Muła napisał:
> On Tuesday, January 14, 2014 11:03:36 AM UTC+1, g...@g...com wrote:
>
> > > >Na przyklad ewaluacja kodu "w locie".
> > > A co to jest?
> >
> > To jest to, co na przyklad javascript albo
> > php udostepnia (w dosc posledniej formie)
> > pod postacia funkcji "eval"
>
> To są dziury bezpieczeństwa. Eval is evil.

Eval is evil to dobra mantra dla poczatkujacych.
(I latwo zapamietac, bo wystarczy zmienic jedna
literke :D). Jezeli mamy jezyk, w ktorym jest
dobrze zrobiona obsluga modulow (taki jak np. Scheme ;]),
to mozna bez ryzyka wykonywac kod uzytkownika w danym module,
zachowujac pelna kontrole nad funkcjami systemowymi,
ktore sa dla tego kodu dostepne.
Mozna rowniez odpalic evala w osobnym watku, ktoremu
mozna ograniczyc maksymalny czas wykonania.

> Jak potrzebujesz liczyć coś dynamicznie, to bierzesz
> parser i coś robisz z drzewem rozbioru gramatycznego.

I wlasnie to mam na mysli, mowiac o wynajdowaniu
kola od nowa. Jest takie cos, jak "Greenspun's tenth rule":

"Any sufficiently complicated C or Fortran program
contains an ad hoc, informally-specified, bug-ridden,
slow implementation of half of Common Lisp."

Ale zeby nie byc goloslownym. Jeden z najbardziej szanowanych
przeze mnie programistow, John Carmack, stworzyl kiedys engine
dla gry komputerowej Quake. Przy okazji stworzyl rowniez
jezyk skryptowy, dziedziczacy z C, ktory nosil nieszczegolnie
zaskakujaca nazwe "Quake C". I mimo ze sie przy tym narobil,
na pewno mial parser i robil cos z drzewem rozbioru gramatycznego,
to jezyk okazal sie niewygodny, niewydajny i kaleki. Trudno jest
ad hoc zaprojektowac dobry jezyk programowania, i jezeli jest
taka mozliwosc, to lepiej korzystac z istniejacych i juz dobrze
zaprojektowanych jezykow. Nie dosc, ze to mniej roboty przy
implementacji, to jeszcze mniej nauki dla osob, ktore maja
z tego jezyka korzystac.