jelloek: czytałem wywiad w którym twórca Pythona wyraźnie powiedział że punktem wyjścia był dla niego basic i chciał stworzyć język który będzie tak samo prosty, ale nowoczesny (obiekty, itp). Nie twierdzę że Python=Basic, nic z tych rzeczy.

O, zapomniałem o ruby, dobrze że przypomniałeś. Wielkiej przyszłości ruby nie wieszczę, ma ciekawe cechy i swoje nisze, ale jest wolne, dlatego myślę że z czasem wielcy gracze przejmą zalety ruby, a te odejdzie do krainy wiecznych kompilatorów ;)

Ja wiem całkiem sporo o Pythonie. PyPy to ciekawa koncepcja. Zobaczymy.

No wiadomo, jvm jest bardzo przenośny i co drugi toster ma implementację ;) ale to niekoniecznie jest zaleta. CLR w implementacji microsoftowej jest w przenośne tam gdzie microsoft chce (na ten moment i86 i ARM iirc), mono trochę lepiej więc nie jest tak źle. CLR wydaje mi się o tyle lepiej pomyślany że rozszerzenia języków (np. genericsy) są realizowane właśnie na poziomie CLRa, a w Javie na poziomie kompilatora, co wydaje mi sie lepiej świadczy o CLRze i możliwościach jego przyszłego rozwoju.

No i na mamy jeszcze nadchodzące Go Googla (ale to język kompilowany bezpośrednio do kodu maszynowego, więc trochę pza nawiasem tej dyskusji) i to coś czym chcą zastąpić javascript (moim zadaniem bardzo dobry pomysł, ale czy się przyjmie to zobaczymy, a nazwa chwilowo wypadła mi z pamięci)

A że Google porzuciło Pythona to jeszcze nie słyszałem. W sumie szkoda (dla tego języka).

(Się dorzucam do offtopa:)).

Python nie wywodzi się z BASIC-a. Wcięcia pomagają w pisaniu czytelnego kodu. A skoro już są - niepotrzebne są
wszelkie nadmiarowe {}. Zostaje sam syntactic sugar.

CLR powstał po JVM. Wiedzieli już jak projektować. Jeśli o mnie chodzi - nadal zbyt duży bloatware.

Tylko przez założenia projektowe, jest GIL. Bez wielowątkowości da się obejść - zobacz jak działa nginx. Co do samego pythona - jest python-multiprocessing.

Jeśli powiedział, że chciał stworzyć język równie prosty, to nie znaczy to przecież, że jest wzorowany na BASIC-u.
Na Modula i kilku innych... ok.

W większości zastosowań nie ma znaczenia czy coś wykona się w 0,1 sekundy po kliknięciu w przycisk czy w 0,01. :-)

Nieprzenośność zawsze będzie wadą. Tak samo jak CS. W przypadku Mono - sami musieli pisać wszystko od zera.

Może i szafy gdańskie ale tam wszystko było hot-swap i zapewniało poziom niezawodności 99,999% w roku co daje 9 godzin przestoju. A ja kiedyś czytałem, to zmiana linijki kodu w schedulerze to był/jest "act of God" ale dzięki temu systemy napisane dla tych środowisk mają lifetime liczony w dziesiątkach lat a nie do najbliższego fixpaku systemu.
Tu jest więcej o p-Code: http://www.threedee.com/jcm/psystem/

skomplikowaliscie moj prosty swiat
ja tydzien temu odkrylem svn

Statyczne typowanie jest wadą... i wie o tym obecnie już więcej niż jedna osoba... fascynujące ;)

Powodem, dla którego przesiedliśmy się w firmie z cvs na svn, było przenoszenie plików z historią :D:D:D:D

Edit: ech stylistyka

Ostatnio edytowany przez mono (2011-11-18 23:20:57)

laoo: problemy w czytaniu ze zrozumieniem?
chodzilo o statyczne kompilowanie, a nie o statyczne typowanie. to drugie czyni jedynie jezyk mniej elastycznym, wolniejszym w kodowaniu...

statyczne typowanie jest fpyte zaleta przy zwyklej kompilacji, bo bardzo ja upraszcza.

Kryzys wieku średniego ?

Ć mnie się podoba, ale mi chodzi o działanie w drugą stronę -> wszystkie języki wykonwywane przez jeden VM.

To twierdzenie chyba nie da się obronić ;)