>> czy jest podobne do pythona,
>
>Ani trochę i to jest jego główna zaleta. Dzięki temu można go
>swobodnie rozszerzać zgodnie z potrzebami programisty.

no wlasnie, wychodzi na to ze to jeden z jakos bardzo
nielicznych co bardziej oryginalnych jezykow programowania
(w odroznieniu od raczej nieoryginalnych typu javascript itp
- choc javascripta tez nie znam )
(z tego co przynajmniej wyglada: wyglada na to jakby
roznica byla taka ze python jest 'skryptowy i daynamiczny'
ale udostepnia predefiniowane komendy a tcl byl w jakis
sposob rozszezalny o samo definiowanie tych komend - i to
by byla bardzo znaczna roznica na korzysc tcla' z tym ze nie
wiadomo mi jak to z tym samodefiniowaniem jest czy daje
to jakies (w stosunku do pythona) nowe realne mozliwosci
czy w praktyce wychodzi ze nie za bardzo -
(ktos moze podac moze przyklad takiej ew nowej mozliwosci?)









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

do góry

> u nas w Tclu, jestem krytycznie nastawiony do tego jezyka. Koncepcja
> samego jezyka jest pogieta. Zasadniczo wszystko jest stringiem.

to akurat mz jest co do podstaw bardzo sprytne, jesli chodzi
o tak bardzo 'wysokopoziomowe' jezyki to program jest tekstem,
mozna wykonywac tekst, przekazywac tekst czyli kod itd

na tym poziomie, o ile udostepnic tylko te mechanizmy do
definiowania, mozna pisac programy ktore pisalyby same
siebie - podobnie jak SMC za dawnych czasow tylko inaczej

inzczej tez niz predefiniowane bytekode taki tekstowy bytekode
daje wiecej mozliwosci




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

do góry

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

> > u nas w Tclu, jestem krytycznie nastawiony do tego jezyka. Koncepcja
> > samego jezyka jest pogieta. Zasadniczo wszystko jest stringiem.
>
> to akurat mz jest co do podstaw bardzo sprytne, jesli chodzi
> o tak bardzo 'wysokopoziomowe' jezyki to program jest tekstem,
> mozna wykonywac tekst, przekazywac tekst czyli kod itd
>
> na tym poziomie, o ile udostepnic tylko te mechanizmy do
> definiowania, mozna pisac programy ktore pisalyby same
> siebie - podobnie jak SMC za dawnych czasow tylko inaczej
>
> inzczej tez niz predefiniowane bytekode taki tekstowy bytekode
> daje wiecej mozliwosci
>
>

w sumie jest to (czyli okolice czegos co zdaje sie
wczesniej nazywalem jako IL) jakotako ciekawe,

otwiera nieco inna perspektywe bo o ile programy
w c pisze sie od dolu do gory (i to raczej nie
podlega kwestii) to tu mozna by pokusic sie o cos
zgola innego, np zbudowac takie definicje aby
kod (np gry arkanoida) byl jak najmniejszy,

samych bindingsow do wywolan w c mogloby byc
tylko kilka setpixel() readKey() waitSync() czy
cos takiego(o ile ew tez samego control flowa nie
robiloby sie przy pomocy wywolan w c)

aczkolwiek troche ciezko sie o tym mysli, ale
mozna pomyslec, z biegiem czasu jak sie przyloze
to pewnie opracuje temat 'na raty'

--

Standing outside the glass on the sidewalk - These people talk about
impossible things







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

do góry

On Jan 16, 3:16 pm, Krzysiek Kowaliczek
<k...@g...com> wrote:

> Przesadzasz. I ile zwykle się z Tobą zgadzam, to w tej kwestii mam
> odmienne zdanie.

> Zasadniczo wszystko jest stringiem.

No właśnie. Czyż to nie ciekawe? Język skryptowy ze *statycznym*
systemem typów? ;-)

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

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

Bo Python to robi automatycznie...

> Chcesz, aby zaalokowanymi obiektami C++ zajmował się GC.
> Zapomnij.
> Obsługa błędów wygląda jak za króla Popiela,

To prawda.

> Przepraszam za złośliwość, ale YAMI4 ma wsparcie dla Pythona, a nie ma
> dla Tcla.

No właśnie. Tu złośliwość się sprawdzi.
Otóż YAMI4 jest projektem komercyjnym. Pewien muzyk mi powiedział, że
generalnie preferuje jazz, ale um-cyk-um-cyk na weselu też czasem
trzeba zagrać... ;-)

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

Dzięki temu YAMI4 *nie działało* z Pythonem na platformie 64-bitowej.
Zajęło mi to trochę długich wieczorów i trochę publicznego wstydu
zanim się sprawa na grupie dyskusyjnej wyjaśniła, bo jakiś pythonista
robił szum, że ma segfaulty z YAMI4.
Piszę "nie działało" w czasie przeszłym, bo zainwestowałem dodatkowy
czas, żeby *przepisać* warstwę interfejsu i ominąć pythonowego gniota.

Czyli faktycznie, YAMI4 wspiera Pythona. Od wersji 1.4.0 wspiera go
nawet pomimo fatalnych bugów w Pythonie.
To tyle jeśli chodzi o złośliwość.

> Z tym, że Tcl wygląda jak ubogi krewny LISPa.

Tak miało być, więc nic dziwnego, że tak wygląda...

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.

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

do góry

On Mon, 16 Jan 2012 13:56:10 -0800 (PST), Maciej Sobczak
<s...@g...com> wrote:

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

Podobnie jak AWK jest dla ludzi ktory lubia AWK :)

A.L.

do góry

Krzysiek Kowaliczek <k...@g...com> wrote:
> On 15 Sty, 07:55, Maciej Sobczak <s...@g...com> wrote:
>> To bardzo dobry język, świetnie zaprojektowany i bardzo ładnie
>> wykonany na poziomie struktury interpretera, który niestety jednak
>> "wypadł" z obiegu i stracił popularność na rzecz takich gniotów jak
>> np. Python.
>
> Przesadzasz. I ile zwykle się z Tobą zgadzam, to w tej kwestii mam
> odmienne zdanie. Może temu, że z Tclem mam styczność na co dzień
> ( 100kloc w Tcl, głównie gui ). W odróżnieniu od ludzi, którzy piszą w
> u nas w Tclu, jestem krytycznie nastawiony do tego języka. Koncepcja
> samego języka jest pogięta. Zasadniczo wszystko jest stringiem. Chcesz
> przesłać wskaźniki do obiektów z C++ to od strony Tcla jest to string.
> Jak chcesz kontrolę typów na tym wskaźnikami, to trzeba to zakodować w
> stringu. Chcesz, aby zaalokowanymi obiektami C++ zajmował się GC.
> Zapomnij. Obsługa błędów wygląda jak za króla Popiela, ileś tam
> systemów obiektowych. Zasadniczo jedyną zaletą tego języka jest DSL.
> Ale też z bólem, ponieważ i tak musimy się wpasować w ramy języka.
> Jakiś czas temu napisałem kawałek skryptu w Tclu do uruchamiania
> testów modułowych dla jednego komponentu. Męczarnie jakie przeżyłem
> ( pomimo, że obok siedzą programiści w Tcla ), spowodowała, że
> następne narzędzia do testów modułowych pisałem w C++. Ostatnio
> napisałem bibliotekę do generowania testów w ... Pythonie. Pisanie w
> tym języku to czysta przyjemność, pisanie w Tclu to ból w wiadomej
> części ciała. Sorry, ale ja nie rozumiem entuzjazmu dla Tcla.
>
>> Dzisiaj sytuacja "Tcl vs. Python" wygląda niestety tak, że Python,
>> dzięki swojej popularności, ma znacznie większą bibliotekę, dzięki
>> której jest bardziej popularny.
>
> Przepraszam za złośliwość, ale YAMI4 ma wsparcie dla Pythona, a nie ma
> dla Tcla.
>
>> Jeżeli zainteresowałbyś się Tclem pod kątem jego walorów językowych,
>> to w podobne tony gra też język o nazwie Racket (dawniej DrScheme).
>> Oba czerpią z tradycji LISPowych, ale Racket robi to znacznie bardziej
>> i przy znacznie większych możliwościach jest też znacznie bardziej
>> wymagający dla programisty. Jest też od Tcla jeszcze mniej popularny
>> na rzecz wspomnianych już gniotów.
>
> Z tym, że Tcl wygląda jak ubogi krewny LISPa. Zresztą swoją przygodę z
> LISPem miałem jakiś czas temu i dziękuję, las nawiasów to nie dla
> mnie. Python się sprawdził w moim przypadku i daleki jestem od
> nazywanie go gniotem ( zwłaszcza w konkurencji z Tclem ).
... z mojej praktywiki wynika, ze tcl mozna znalezc w wielu aplikacjach
jako wbudowany jezyk, ale jest to coraz zadsze. na szczescie zastepuje
go tu python. Z powazaniem
Adam Przybyla

do góry

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

> natomiast Tcl moze sie przydac do tworzenia wlasnych jezykow
> specyficznych dla jakiegos zastosowania, bo mozna w nim tworzyc nowe
> konstrukcje jezykowe, ktore dzieki jego bardzo prostej i konsekwentnej
> skladni nie sa odroznialne od procedur.

Zabrzmialo bardzo interesujaco. Kompletnie nie znam tcl, nigdy nic nie
czytalem o nim. Rozumiem ze skoro o tym wspominasz, to chodzi o zupelnie
inne i lepsze dla niektorych zastosowan rozszerzenie, niz rozszerzenia
typowe dla innych jezykow, jak np.: pisanie nowych procedur i definiowanie
nowych typow czy klas?


Pozdrawiam



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

do góry

On 2012-01-16, Maciej Sobczak <s...@g...com> wrote:
> On Jan 16, 3:16 pm, Krzysiek Kowaliczek
><k...@g...com> wrote:
>
>> Przesadzasz. I ile zwykle się z Tobą zgadzam, to w tej kwestii mam
>> odmienne zdanie.
>
>> Zasadniczo wszystko jest stringiem.
>
> No właśnie. Czyż to nie ciekawe? Język skryptowy ze *statycznym*
> systemem typów? ;-)

Been there, done that, got a t-shirt. Bourne shell też ma tylko stringi.

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

Niezbyt mnie zachwyca pomysł kontroli formatu wskaźnika. Wskaźnik dla
mnie zawsze był prymitywem.

> Świetnie się to sprawdza przy debugowaniu!

W jaki sposób?

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

Podobnie jak Perl czy Ruby. Argument przedpiścy nietrafiony, bo dotyczy
dynamicznego systemu typów.

>> Przepraszam za złośliwość, ale YAMI4 ma wsparcie dla Pythona, a nie ma
>> dla Tcla.
>
> No właśnie. Tu złośliwość się sprawdzi.
> Otóż YAMI4 jest projektem komercyjnym. Pewien muzyk mi powiedział, że
> generalnie preferuje jazz, ale um-cyk-um-cyk na weselu też czasem
> trzeba zagrać... ;-)
>
> 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

Well, ci sami geniusze w Pythonie 3 uznali, że wszystko, co przychodzi
z wiersza poleceń, jest UTF-em, przez co możesz tak spreparować
argumenty do programu, że nie dość że się nie uruchomi, to jeszcze nie
będziesz miał szansy na przechwycenie wyjątku.

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

Bardzo ciekawą. Ma moim zdaniem najładniejsze API do integracji z C (w
obie strony).

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2012-01-17, M.M. <m...@N...gazeta.pl> wrote:
>
> Maciej Sobczak <s...@g...com> napisał(a):
>
>> natomiast Tcl moze sie przydac do tworzenia wlasnych jezykow
>> specyficznych dla jakiegos zastosowania, bo mozna w nim tworzyc nowe
>> konstrukcje jezykowe, ktore dzieki jego bardzo prostej i konsekwentnej
>> skladni nie sa odroznialne od procedur.
>
> Zabrzmialo bardzo interesujaco. Kompletnie nie znam tcl, nigdy nic nie
> czytalem o nim. Rozumiem ze skoro o tym wspominasz, to chodzi o zupelnie
> inne i lepsze dla niektorych zastosowan rozszerzenie, niz rozszerzenia
> typowe dla innych jezykow, jak np.: pisanie nowych procedur i definiowanie
> nowych typow czy klas?

W typowym języku imperatywnym instrukcja if-else jest jedynie blokiem
instrukcji, wykonywanych warunkowo. Nie ma sensu przypisywanie takiej
instrukcji do zmiennej.
#v+
a = if (b == c) 15 elsif (b == d) 20 else 30 end;
#v-
W Tclu jesteś w stanie zdefiniować coś takiego bez większego trudu.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Monday, January 16, 2012 11:03:13 PM UTC, A. L. wrote:
> >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.
>
> Podobnie jak AWK jest dla ludzi ktory lubia AWK :)

Sa tacy? ;-)

RW

do góry