On 19 Sty, 21:32, Maciej Sobczak <s...@g...com> wrote:
> Może to nie jest dobry pomysł, żeby robić w tym GUI na tysiące
> elementów w listach?
> Wcale się nie nabijam - jak najbardziej uważam, że narzędzia powinny
> być dobierane odpowiednio do problemu.

Aplikacja ma już kilkanaście lat i była pisana na długo przed tym jak
zacząłem pracę. Wtedy wybór Tcla wydawał się sensowny.

> A tak przy okazji - masz tu jakieś porównanie z Pythonem? Tzn. GUI w
> Pythonie z drzewkami/listami na tysiące elementów? Bo skoro zauważasz,
> że format wskaźnika wpływa na wydajność, to pewnie z czymś ją
> porównałeś.

A gdzie ja pisałem coś o Pythonie w tym kontekście? Ja pisałem, że
jawny format wskaźnika nie jest jakimś wielkim udogodnieniem,
zwłaszcza, że id typu jest też podane jako wskaźnik. Chodzi właśnie o
to, aby tych danych między Tcl i C++ przepychać jak najmniej i by ich
jak najmniej pamiętać.
Panie, ja to bym zamienił całego Tcla nie na Pythona, ale (uwaga!) C+
+. W przypadku większych programów, lepszy jest język ze statycznym
systemem typów. Jakiś czas temu wywaliliśmy spory kawałek w Tcl,
ponieważ nie wytrzymywał już zmian, i przepisali na C++. Efekt jest
świetny, nie ma problemu z dodawaniem nowych elementów, zmianami w
bieżącym kodzie, itd.

> > Tak i przy okazji dodałeś coś o gniotach.
> Nie ma w tym żadnego konfliktu. Mogę nawet powtórzyć: Python to gniot,
> który dzięki swojej popularności ma wiele bibliotek, dzięki którym
> jest popularny. :-)

Po dyskusji to już nie wiem czy uważasz język za gniota, czy
implementację jego interpretera?

> O Javie pisałem dokładnie to samo. :-D

Tutaj się zgodzę, Java rzeczywiście jest do dupy :).

> Czyli jeśli szukasz bibliotek, Python je ma. Jeśli szukasz języka,
> szukaj gdzie indziej.
> Gdybym dzisiaj miał coś robić w tych okolicach, spróbowałbym z
> językiem Racket.

Z ciekawości, co Cię skłoniło to tego języka?

Pozdrawiam
KK

do góry

A.L. <l...@a...com> wrote:
> On Thu, 19 Jan 2012 12:24:17 +0000 (UTC), Adam Przybyla
> <a...@r...pl> wrote:
>
>>Andrzej Jarzabek <a...@g...com> wrote:
>>> On Wednesday, 18 January 2012 12:33:57 UTC, A. L. wrote:
>>>> >
>>>> >Nie można mieć automatu, który w skończonym czasie potrafi stwierdzić,
>>>> >czy się nie wywali.
>>>>
>>>> Ze co?... Prosze o objasnienie. Co to znaczy "czy sie nie wywali"
>>>
>>> Czy nie przerwie wykonywania programu z błędem typu wywołanie niezdefiniowanej
procedury, rozwinięcie nieistniejącej zmiennej, niewłaściwa ilość parametrów,
niesparowany cudzysłów itd. Czy kolega w ogóle czytał poprzednie postingi w wątku?
>> ... mozesz sprawdzic wszystkie pliki pythona czy sa poprawnymi programami
>>w py, to da sie zrobic w skonczonym czasie;-) Z powazaniem
>> Adam Przybyla
>
> A co to jest "poprawny program?...
... syntaktycznie poprawny w tym przypadku. Niesparowany cudzyslow bylby tutaj
wykrywany.
Z powazaniem
Adam Przybyla

do góry

On Jan 19, 11:18 pm, Krzysiek Kowaliczek
<k...@g...com> wrote:

> > A tak przy okazji - masz tu jakieś porównanie z Pythonem? Tzn. GUI w
> > Pythonie z drzewkami/listami na tysiące elementów? Bo skoro zauważasz,
> > że format wskaźnika wpływa na wydajność, to pewnie z czymś ją
> > porównałeś.
>
> A gdzie ja pisałem coś o Pythonie w tym kontekście?

W takim razie się nie kłócę.
Przecież nigdzie nie pisałem, że wskaźnik w formie stringa jest super-
wydajny. Nie jest.
On jest po prostu wygodny przy wypisywaniu na ekran.

> Chodzi właśnie o
> to, aby tych danych między  Tcl i C++ przepychać jak najmniej

Można to robić na dwa sposoby - albo przez zmniejszenie tych danych,
albo przez zmniejszenie częstości tej wymiany. Ja preferuję to drugie,
jeśli można tak ukierunkować projekt. Nie przeszkadza mi to, że
przepycham przez granicę kilkadziesiąt bajtów; przeszkadzało by mi,
gdybym to miał robić milion razy na sekundę, bo to by znaczyło, że źle
podzieliłem zadania pomiędzy różne języki.
Jeśli coś ma się dziać często, to nie się dzieje po jednej stronie.

> Panie, ja to bym zamienił całego Tcla nie na Pythona, ale (uwaga!) C+
> +.

Dlaczego "uwaga"? Jeśli GUI ma mieć drzewka/listy na tysiące
elementów, to jest to naturalny wybór.

> W przypadku większych programów, lepszy jest język ze statycznym
> systemem typów.

Oczywiście.

> Po dyskusji to już nie wiem czy uważasz język za gniota, czy
> implementację jego interpretera?

Jedno i drugie. Język to gniot, który wraz ze swoim rozwojem stał się
bardzo skomplikowany będąc jednocześnie monolitycznym i
nierozszerzalnym, natomiast jego interpreter jest zaprojektowany i
napisany po dziadowsku.

Niemniej, doceniam jego biblioteki, nawet jeśli czasem muszę
instalować N wersji Pythona i szukać, w której wersji jakaś potrzebna
mi biblioteka nadaje się do użytku. "Release early, release often" ma
swoje efekty w postaci bugów od lewej do prawej a to wcale nie pomaga
w efektywnym użytkowaniu.

> > Gdybym dzisiaj miał coś robić w tych okolicach, spróbowałbym z
> > językiem Racket.
>
> Z ciekawości, co Cię skłoniło to tego języka?

Nawet nie pamiętam. Chyba chciałem się trochę odświeżyć i (po raz
kolejny) rzucić okiem na Scheme. Doklikałem się do Racket i spodobała
mi się jego dokumentacja, więc ją przeczytałem. Poklikałem,
poeksperymentowałem, spróbowałem też włączyć moduł ładowalny w C++ -
wszystko jest na swoim miejscu. Są wątki i wyjątki, trochę koślawe
klasy[*] i nawet rozbudowany system modułów[**] i różne fajne rzeczy
out-of-the-box typu wyrażenia regularne i takie tam podręczne zabawki,
nawet ładnie zrobione strumienie (ogólnie obsługa I/O). Miło się tego
używa, jeśli przymkniemy oko na nawiasy[***]. Przede wszystkim jest to
język prawdziwie funkcjonalny (a nie "posiada elementy"), więc
faktycznie dobrze działają takie rzeczy jak upward closure.

[*] Nie szkodzie, że są koślawe, bo ustaliliśmy już, że duże systemy
piszemy w statykach. [**] W sumie niepotrzebnie, z tych samych
powodów.
[***] W tym pomaga przyzwoity edytor.

Ogólnie - ładny język, według mnie warty co najmniej rzucenia okiem.
Piątka za staranną i bardzo czytelną dokumentację.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On Jan 19, 9:53 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> > Mógłbyś podać przykład, którego nie da się wykryć automatem?
>
> Zły kwantyfikator. Takiego przykładu, dla którego nie istnieje automat
> oczywiście nie ma. Natomiast nie ma też automatu, który by działał dla
> dowolnego przykładu.

I, jak rozumiem, w Pythonie jest zupełnie inaczej?

Jeśli chodzi o wykrycie źle dopasowanych nawiasów, co w Tclu jest
upierdliwe ze względu na nawiasy w komentarzach, to nie ma z tym
najmniejszego problemu.
Nie da się natomiast wykryć problemów ze skryptem tworzonym w locie,
ale to jest prawdą w każdym języku dynamicznym.

> > Poprawność składniową można zawsze sprawdzić a w Tclu chyba
> > najłatwiej, bo ma bardzo prostą gramatykę. Dużo prostszą, niż Python.
>
> Tylko w najbardziej trywialnym sensie, tzn. możesz sprawdzić, że skrypt
> się składa z n poleceń i każde polecenie ma poprawnie składniowo podane
> parametry. Sprawdzenie poprawności tego, co w innym języku byłoby
> blokami kodu jest niemożliwe, bo w tcl-u są to po prostu stringi i w
> ogólnym przypadku nie które z nich powinny być poprawnymi skryptami w tcl.

Można taką analizę spokojnie określić dla "oczywistych" przypadków:
if, for, itd.
Resztą bym się nie przejmował, bo tu analiza 100% nie jest potrzebna
(jeśli komuś jest potrzebna, to odsyłam do SPARKa).

> Chodziło mi o sprawdzenie, czy odwołania do symboli odwołują się do
> symboli rzeczywiście zdefiniowanych, np. nazw procedur czy zmiennych.

I w Pythonie też nie da się tego zrobić, wystarczy podzielić program
na pliki i po ptokach - w Pythonie nie ma fazy linkowania, więc nie ma
mechanizmu, który by zapewnił spójność całości[*].
Ponownie - jeśli komuś taka analiza jest potrzebna, to polecam języki
statyczne. One do tego zostały stworzone.

[*] Ale w Javie też nie ma a to ponoć język statyczny...

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

On 2012-01-20, Maciej Sobczak <s...@g...com> wrote:
> I w Pythonie też nie da się tego zrobić, wystarczy podzielić program
> na pliki i po ptokach - w Pythonie nie ma fazy linkowania, więc nie ma
> mechanizmu, który by zapewnił spójność całości[*].
[...]
> [*] Ale w Javie też nie ma a to ponoć język statyczny...

Java: język typowany statycznie, ale dynamicznie. Co widać zresztą po
kontenerach.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Jan 20, 9:15 am, Maciej Sobczak <s...@g...com> wrote:
> On Jan 19, 9:53 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > Zły kwantyfikator. Takiego przykładu, dla którego nie istnieje automat
> > oczywiście nie ma. Natomiast nie ma też automatu, który by działał dla
> > dowolnego przykładu.
>
> I, jak rozumiem, w Pythonie jest zupełnie inaczej?

Napisałem kilka razy, ale może za mało wyraźnie: nie wypowiadam się o
Pythonie.

> Jeśli chodzi o wykrycie źle dopasowanych nawiasów, co w Tclu jest
> upierdliwe ze względu na nawiasy w komentarzach, to nie ma z tym
> najmniejszego problemu.

Ale piszesz tu tylko o nawiaskach klamrowych, a co z [], z
cudzysłowami, i w ogóle co ze składnią wyrażeń.

> Nie da się natomiast wykryć problemów ze skryptem tworzonym w locie,
> ale to jest prawdą w każdym języku dynamicznym.

Nawet jak nie tworzysz skryptów w locie, to raczej ciężko wnioskować
który ze stringów nawet tych zdefiniowanych verbatim będzie używany
jako skrypt lub wyrażenie.

> > Tylko w najbardziej trywialnym sensie, tzn. możesz sprawdzić, że skrypt
> > się składa z n poleceń i każde polecenie ma poprawnie składniowo podane
> > parametry. Sprawdzenie poprawności tego, co w innym języku byłoby
> > blokami kodu jest niemożliwe, bo w tcl-u są to po prostu stringi i w
> > ogólnym przypadku nie które z nich powinny być poprawnymi skryptami w tcl.
>
> Można taką analizę spokojnie określić dla "oczywistych" przypadków:
> if, for, itd.

Niby można, ale należałoby w tym celu napisać własny walidator z
własnym parserem tcl-a, co nie jest może jakoś super skomplikowane,
ale też nie takie znowu trywialne.

> Resztą bym się nie przejmował, bo tu analiza 100% nie jest potrzebna
> (jeśli komuś jest potrzebna, to odsyłam do SPARKa).

Jest to tym mniej potrzebne, im mniej używasz konstrukcji typu
procedura dostaje kod w parametrze i go wykonuje. Tylko że tworzenie
takich konstrukcji miało być wielką zaletą tcl-a.

A w innych językach można mieć takie możliwości dzięki closures, które
są dla odmiany normalnym kodem i normalnie mogą być sprawdzone pod
kątem składni przed wykonaniem skryptu.

> > Chodziło mi o sprawdzenie, czy odwołania do symboli odwołują się do
> > symboli rzeczywiście zdefiniowanych, np. nazw procedur czy zmiennych.
>
> I w Pythonie też nie da się tego zrobić, wystarczy podzielić program
> na pliki i po ptokach - w Pythonie nie ma fazy linkowania, więc nie ma
> mechanizmu, który by zapewnił spójność całości[*].
> Ponownie - jeśli komuś taka analiza jest potrzebna, to polecam języki
> statyczne. One do tego zostały stworzone.

Nie wypowiadam się o Pythonie. Natomiast w wielu językach dynamicznych
przynajmniej częściowo jest to do zrobienia - np.w Groovym.

do góry

On Jan 19, 4:57 pm, Roman W <b...@g...pl> wrote:
> On Thursday, January 19, 2012 3:38:41 PM UTC, Andrzej Jarzabek wrote:
> > Moje doświadczenie z robieniem czegoś konkretnego jest takie, że
> > regularnie zdarzały się sytuacje, że w produkcji skrypt tcl-wy, który
> > miał coś zrobić w nocy konkretnie wywalał się w połowie z powodu błędu
> > składniwego albo literówki w nazwie procedury, np. na próbie
> > zalogowania jakiegoś nietypowego przypadku. Rano ludzie przychodzili
> > do pracy i musieli gasić pożar przed otwarciem giełdy.
>
> Kiedys rozmawialem z kolega ktory pracuje jako deweloper w Goldman Sachs,
> i on opisal ich podejscie do IT jako "biora kiepski/przypadkowy design i
> zatrudniaja bardzo dobrych ludzi do wiecznego gaszenia pozarow". Widac tak
> tez mozna zarabiac pieniadze.

Rzecz jasna. Ta forma, którą opisywałem, też zarabiała pieniądze.
Nawet nie musiała zatrudniać tylko bardzo dobrych ludzi, ale za to
płaciła im chyba znacznie mniej niż Goldman Sachs i gaszenie pożarów
nie było też wieczne, więc jakoś tam się bilansowało.

Tylko że sam fakt zarabiania lub niezarabiania pieniędzy jest luźno
związany z tym, czy jakaś technologia, której się używa, jest dobra
czy niedobra (nawet jeśli "dobra" rozumiemy jako "sprzyjająca
zarabianiu pieniędzy").

do góry

On Friday, January 20, 2012 12:32:36 PM UTC, Andrzej Jarzabek wrote:

> Tylko że sam fakt zarabiania lub niezarabiania pieniędzy jest luźno
> związany z tym, czy jakaś technologia, której się używa, jest dobra
> czy niedobra (nawet jeśli "dobra" rozumiemy jako "sprzyjająca
> zarabianiu pieniędzy").

Technologia moze byc dobra nawet jezeli wymaga ciaglego dopieszczania, jezeli oferuje
cos w zamian, np. elastycznosc. Moze dlatego uzywali w Twojej firmie tego Tcl-a?

RW

do góry

On Friday, January 20, 2012 12:02:30 PM UTC, Andrzej Jarzabek wrote:

> Jest to tym mniej potrzebne, im mniej używasz konstrukcji typu
> procedura dostaje kod w parametrze i go wykonuje. Tylko że tworzenie
> takich konstrukcji miało być wielką zaletą tcl-a.

To jest zaleta ktora robi sie wielka wada, kiedy zaczyna sie myslec o
bezpieczenstwie.

RW

do góry

On 2012-01-20, Roman W <b...@g...pl> wrote:
> On Friday, January 20, 2012 12:02:30 PM UTC, Andrzej Jarzabek wrote:
>
>> Jest to tym mniej potrzebne, im mniej używasz konstrukcji typu
>> procedura dostaje kod w parametrze i go wykonuje. Tylko że tworzenie
>> takich konstrukcji miało być wielką zaletą tcl-a.
>
> To jest zaleta ktora robi sie wielka wada, kiedy zaczyna sie myslec o
bezpieczenstwie.

Straszne. Języki funkcyjne, gdzie się to robi nagminnie, są
niebezpieczne! Podobnie jak jakiekolwiek funkcyjne konstrukcje w Perlu,
Rubym i Pythonie!

--
Secunia non olet.
Stanislaw Klekot

do góry