On 19 Sty, 10:30, Maciej Sobczak <s...@g...com> wrote:
> > kodowane są w postaci adres obiektu + adres na id typu, a nie wskaźnik
> > + najczęściej długa nazwa typu, ponieważ tak jest wydajniej.
>
> Wydajniej? Ale kogo to obchodzi? Cokolwiek byś nie zrobił w Pythonie w
> celu poprawienia wydajności, będzie to przypominać montowanie
> aerodynamicznych osłon na koła w ciągniku rolniczym.
> Python (Tcl, itd.) nie służy do pisania wydajnych programów.
> Może co najwyżej posłużyć do pisania niewydajnych kontrolerów do
> wydajnych komponentów napisanych w odpowiednich do tego językach, ale
> tu zabawy ze wskaźnikami nic nie wnoszą.

Jak już mówiłem, mam to na co dzień i wiem co piszę. W Tclu pisane
jest GUI i format wskaźnika ma zauważalny wpływ na pamięć/wydajność,
jak ilość elementów np. na drzewkach/listach idą w tysiące.

> Przecież temu nie zaprzeczam. Nawet ten fakt sam podkreśliłem na
> początku.
> Jeżeli szukasz bibliotek, to Python je ma.

Tak i przy okazji dodałeś coś o gniotach.

> Natomiast jeśli szukasz języka do zagnieżdżenia i do oskryptowania
> jakiegoś innego programu (np. gry, edytora graficznego, analizatora
> poprawności, itd.), to fakt posiadania miliona bibliotek jest
> nieistotny.

Ja nie pisałem, że Python jest najlepszy jako język to oskryptowania
aplikacji. Uważam, że do pisania programów narzędziowych bije Tcla na
głowę. Dobrze zrobione interpreter Tcla to za mało, abym przekonał się
do tego języka.

> Raczej przeciwnie - będziesz kombinował jak ograniczyć
> zdolność interpretera choćby ze względu na bezpieczeństwo (sandbox) -
> i tu Tcl kładzie Pythona na łopatki ze swoją koncepcją bezpiecznego
> interprera, w który sami decydujemy, jakie polecenia są dostępne a
> jakie nie, oraz z koncepcją łączenia interpreterów w układy master-
> slave:
>
> http://www.tcl.tk/man/tcl8.4/TclLib/CrtSlave.htm
>
> Dla mnie *to* jest właśnie dobrze zrobiony interpreter. Szkoda, że te
> pomysły zniknęły.

Nawet z tego korzystamy Implementacja interpretera to jest największa
zaleta Tcla.

Pozdrawiam
KK