On 17/01/2012 21:11, Maciej Sobczak wrote:
> On Jan 17, 7:48 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> dowolny
>> błąd typu literówka w nazwie procedury lub zmiennej, zła ilość
>> argumentów, niedopasowane cudzysłowy itd. mogły być wykryte dopiero przy
>> próbie wykonania danej linijki kodu.
>
> Przecież to jest język interpretowany. Masz pretensje do deszczu, że
> pada?

W większości używanych przeze mnie języków skryptowych możliwa jest
jakakolwiek analiza statyczna np. składni skryptu przed jego wykonaniem.
Groovy tak robi, perl tak robi, nawet głupi vbscript tak robi. A tcl
fizycznie nie może.

> Pisałeś wcześniej, że Tcl jest be a Python się sprawdził - trochę
> niekonsekwentny jesteś.

Nic o Pythonie nie pisałem.

> Taka jest uroda języków skryptowych. Dlatego nie używam ich do
> niczego, co nazwałbym "systemem produkcyjnym".

Czasem jest to wygodne i sensowne, np. my korzystaliśmy z różnych
produktów czy komponentów i w ogóle całej infrastruktury, gdzie sporo
dodatkowej 'customizowalności' było dostarczone przez fakt, że można
było wszystko oskryptować. Nie było przy tym szczególnych merytorycznych
powodów do używania tcl-a - ktoś tak kiedyś zadecydował, i zostało.

>> For extra fun: zakomentowane linie
>> zawierające niesparowane znaki { i }.
>
> To jest akurat jedna z zalet Tcla (względem Pythona). Jakakolwiek
> niezgodność nawiasów, wynikająca np. z pomyłkowego wycięcia kodu, od
> razu powoduje wywalenie się interpretera i to bez żadnych negocjacji.

Powiedzmy że jako programista przyzwyczajony do innych języków z
nawiasami, byłem nieco zaskoczony, że poniższe kwalifikowało się jako
niezgodność nawiasów, i podwójnie zaskoczony, kiedy dotarło do mnie
dlaczego:
{
[...]
# return [bla bla bla]
# }
jakiś kod debugujący
return $x
}

> Jeszcze bardziej wolę zakończenia bloków w Adzie - bo tam ta pomoc
> jest jeszcze większa.

Ada też ignoruje zakomentowanie zakończenia bloku?

> Tak BTW - w książce "The Art of Unix Programming" (polecam) autor
> cytuje autora programu make, który to autor programu make stwierdza,
> że z perspektywy czasu jego najbardziej debilnym pomysłem było oparcie
> gramatyki plików Makefile o wcięcia z białych znaków. I że przeprasza.

Ale w tym przypadku niewątpliwie ma rację, że przeprasza. Przecież w
makefile te wcięcia to muszą być konkretnie taby!