fir kenobi <f...@N...gazeta.pl> napisał(a):

>
> > w c slow kluczowych jest piec na krzyz
>
> przy czym tak naprawde kluczowe sa dwa if i for,
> przy czym moje namysly wykazaly ze oba mozna zastapic
> operatorami, np
>
> //if
> contition : body;
>
> // loop
> condition :: body
>
> a<0 : a=-a;
>
> int i=0;
> i<100 :: tab[i++]=0;
>
> nieco ryzykowne, ale jako dodatkowy trick dla skrocenia zapisow
> kto wie
>
>

to pierwsze raczej ok, dla mnie

postac[i].enabled : move_postac(i);

jest wyraznie czytelniejsze (szybsze) niz

if(postac[i].enabled)
move_postac(i);

z petla jest jednak gorzej


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

do góry

w sumie okazuje sie to (wywalanie slow kluczowych)
jakies przygnebiajace :-/


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

do góry

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?
Pisałeś wcześniej, że Tcl jest be a Python się sprawdził - trochę
niekonsekwentny jesteś.

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

> 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.
Tymczasem w uniwersalnie uwielbianym Pythonie można sobie dość
dowolnie wycinać przez pomyłkę kawałki kodu a interpreter zadowolony
wszystko łyknie.
Dlaczego? Bo przecież po co komu nawiasy, skoro są redundantne i tyle
się trzeba napisać a jeszcze zajmują miejsce?

Wolę nawiasy w Tclu, niż ich brak w Pythonie. Właśnie ze względu na
pomoc, jaką one dają przy utrzymaniu kodu.
Jeszcze bardziej wolę zakończenia bloków w Adzie - bo tam ta pomoc
jest jeszcze większa.

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.
A na swoje usprawiedliwienie ma tylko tyle, że robił to szybciej, niż
myślał.
Oczywiście dzisiaj wszyscy powtarzają, że Python jest dobry, bo ma
wcięcia. Dzięki którym nie musi mieć nawiasów.

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

do góry

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!

do góry

On Jan 18, 6:44 am, Andrzej Jarzabek <a...@g...com>
wrote:

> 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.

???

Gdzie jest niby źródło tej niemożliwości?
Skoro automat zwany interpreterem się potrafi na tym wywalić, to
znaczy, że istnieje automat, który się na tym wywala. I już masz
rozwiązanie. Czego tu fizycznie nie można?

> > Pisałeś wcześniej, że Tcl jest be a Python się sprawdził - trochę
> > niekonsekwentny jesteś.
>
> Nic o Pythonie nie pisałem.

Przepraszam - to Krzysiek napisał.

> Powiedzmy że jako programista przyzwyczajony do innych języków z
> nawiasami, byłem nieco zaskoczony,

Ja też. Zgadzam się, że jest to jedna z upierdliwości Tcla.
Ciąglę jednak wolę ją od braku nawiasów.

> > 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!

A gdyby to były spacje, to by nie przepraszał? Przecież to by było tak
samo głupie.

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

do góry

Maciej Sobczak <s...@g...com> napisał(a):

> On Jan 17, 7:48=A0pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > dowolny
> > b=B3=B1d typu liter=F3wka w nazwie procedury lub zmiennej, z=B3a ilo=B6=
> =E6
> > argument=F3w, niedopasowane cudzys=B3owy itd. mog=B3y by=E6 wykryte dopie=
> ro przy
> > pr=F3bie wykonania danej linijki kodu.
>
> Przecie=BF to jest j=EAzyk interpretowany. Masz pretensje do deszczu, =BFe
> pada?
> Pisa=B3e=B6 wcze=B6niej, =BFe Tcl jest be a Python si=EA sprawdzi=B3 - troc=
> h=EA
> niekonsekwentny jeste=B6.
>
> Taka jest uroda jezykow skryptowych. Dlatego nie uzywam ich do
> niczego, co nazwalbym "systemem produkcyjnym".
Coraz czesciej mnie kusi, zeby zrezygnowac z PHP. Pamietam jak wiele lat
temu pisalem strony WWW w CGI i C++. Do wszystkiego mialem niezbedne
biblioteki. Praca nie szla jakos wyraznie wolniej niz w PHP.
Pozdrawiam








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

do góry

In the darkest hour on Tue, 17 Jan 2012 13:11:33 -0800 (PST),
Maciej Sobczak <s...@g...com> screamed:
>> 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?
> Pisałeś wcześniej, że Tcl jest be a Python się sprawdził - trochę
> niekonsekwentny jesteś.
>

Co jak co, ale Python niedopasowanie cudzysłowów sprawdzi od razu,
nie przy interpretowaniu danej linii kodu.
Jeśli do TCL nie ma narzędzy typu pylint/pychecker to i pozostałe
argumenty się bronią.

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

Kwestia ich pisania.

>> 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.
> Tymczasem w uniwersalnie uwielbianym Pythonie można sobie dość
> dowolnie wycinać przez pomyłkę kawałki kodu a interpreter zadowolony
> wszystko łyknie.

Nie.

x = 0

# if x == 1:
print x

> Dlaczego? Bo przecież po co komu nawiasy, skoro są redundantne i tyle
> się trzeba napisać a jeszcze zajmują miejsce?
> Wolę nawiasy w Tclu, niż ich brak w Pythonie. Właśnie ze względu na
> pomoc, jaką one dają przy utrzymaniu kodu.

Ja wolę ich brak w Pythonie. Ich brak (i generalnie składnia) właśnie
przekłada się na czytelność i utrzymanie kodu.

> 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.
> A na swoje usprawiedliwienie ma tylko tyle, że robił to szybciej, niż
> myślał.

Tu się nie dziwię. Dasz "\t" jest dobrze, dasz " " jest błąd.

> Oczywiście dzisiaj wszyscy powtarzają, że Python jest dobry, bo ma
> wcięcia. Dzięki którym nie musi mieć nawiasów.

Tru.dat.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:222B ]
[ 08:44:52 user up 13051 days, 20:39, 1 user, load average: 0.69, 0.81, 0.54 ]

MS-DOS: Maybe SomeDay an Operating System.

do góry

In the darkest hour on Tue, 17 Jan 2012 22:52:46 -0800 (PST),
Maciej Sobczak <s...@g...com> screamed:
>> > 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!
>
> A gdyby to były spacje, to by nie przepraszał? Przecież to by było tak
> samo głupie.
>

Gdyby to były taby _lub_ spacje to by nie przepraszał. Nie, nie byłoby.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:234B ]
[ 08:52:23 user up 13051 days, 20:47, 1 user, load average: 0.69, 0.81, 0.54 ]

The best cure for an active sex life is several years of marriage.

do góry

On 18/01/2012 06:52, Maciej Sobczak wrote:
> On Jan 18, 6:44 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>> 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.
>
> ???
>
> Gdzie jest niby źródło tej niemożliwości?
> Skoro automat zwany interpreterem się potrafi na tym wywalić, to
> znaczy, że istnieje automat, który się na tym wywala. I już masz
> rozwiązanie. Czego tu fizycznie nie można?

Nie można mieć automatu, który w skończonym czasie potrafi stwierdzić,
czy się nie wywali.

Inne języki mają gramatykę i taki skrypt można po prostu sparsować w
całości.

>> Powiedzmy że jako programista przyzwyczajony do innych języków z
>> nawiasami, byłem nieco zaskoczony,
>
> Ja też. Zgadzam się, że jest to jedna z upierdliwości Tcla.
> Ciąglę jednak wolę ją od braku nawiasów.

Jest wiele języków z nawiasami.

>> Ale w tym przypadku niewątpliwie ma rację, że przeprasza. Przecież w
>> makefile te wcięcia to muszą być konkretnie taby!
>
> A gdyby to były spacje, to by nie przepraszał? Przecież to by było tak
> samo głupie.

Byłoby mniej głupiee, gdyby było "wcięcie składające się z jednego lub
więcej białego znaku".

do góry

On 16 Sty, 22:56, Maciej Sobczak <s...@g...com> wrote:
> > Chcesz
> > przesłać wskaźniki do obiektów z C++ to od strony Tcla jest to string.
>
> No i super. Przynajmniej mam pełną kontrolę nad tym, jak ten string
> wygląda. Świetnie się to sprawdza przy debugowaniu!
> Python tak nie pomaga.

Jako, że mam z tym styczność na co dzień, taka pomoc jest raczej
mizerna. Mogę sobie wyobrazić dodatkową funkcję CHandleToString. I w
czym to jest gorsze od jawnej postaci?. BTW. u nas wskaźniki C++
kodowane są w postaci adres obiektu + adres na id typu, a nie wskaźnik
+ najczęściej długa nazwa typu, ponieważ tak jest wydajniej. Więc i
tak wymusza to dodatkową funkcję informacji o obiekcie.

> > Jak chcesz kontrolę typów na tym wskaźnikami, to trzeba to zakodować w
> > stringu.
>
> Bo Python to robi automatycznie...

Zagalopowałem się trochę. Chodziło mi o to, że dzięki osobnemu
traktowaniu typów, można przekazać więcej informacji, np. można
zaalokować nowy obiekt, który oprócz wskaźnika ma dodatkowo
informacje. W Tclu nie ma takiej możliwości ponieważ zaalokowany
obiekt musi być jawnie zwolniony ( co jest upierdliwe ).

> Wracając do prawdziwej złośliwości: okazało się, że Pythona napisali
> geniusze, którzy myśleli, że wskaźniki są zawsze 32-bitowe:
>
> https://www.google.com/search?q=Python+ctypes+64+bug

Ale co mnie to interesuje jako użytkownika docelowego? Ja zacząłem
używać Pythona między innymi ze względu na dużą ilość bibliotek, co
jest jego największą zaletą.

> Niemniej, zgodzę się, że Tcl to język dla ludzi, który lubią Tcla.
> Dlatego nie będę się upierał, że jest on uniwersalny i że może być
> uniwersalnie lubiany. Ale żaden język taki nie jest, więc traktuję go
> jako ciekawą część ekosystemu.

Tak, to jest język typu kochaj albo rzuć. Nie istnieją stany
pośrednie :).

Pozdrawiam
KK

do góry