Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Bałagan » Systemy kontroli wersji
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Nie wiem, nie używałem. Tyle mogę powiedzieć że jak przeczytałem kiedyś artykuł jak w MS wygląda tworzenie windowsa to nie polecałbym.
Adamie: piszac o pythonie jako o "jezyku wywodzacym sie z basica" robisz z siebie specjaliste pokroju tedeca...
sie narobilo vm - pod parrota ktos cos pisze? mono niby tam ma jakis swoj kacik, ale bez przesady.
wiecej vm to jest w swiecie ruby ;)
jak juz zaczniesz cos pisac pod pythonem - zainteresuj sie pypy, tj. implementacja napisana w... pythonie - ktora (dzieki tracing jit) w pewnych sytuacjach produkuje kod, szybszy niz najnowsza wersja gcc z najlepszymi optymalizacjami pod dany procesor (moge in priv wytlumaczyc dlaczego, w uproszczeniu - tracing i rekompilacja celem wybrania optymalniejszej sciezki w trakcie dzialania kodu, czego pod c/c++ z automatu nie dostaniesz - tj. musisz sam o tym pomyslec i odpowiednio to zakodowac, co kosztuje kupe czasu).
ps. tobie wydaje sie ze dotnet clr jest lepszy od javowego - to miast gdybac poczytaj w tym temacie - sa bardzo podobne i uzywaja dosc starych koncepcji ;) w obu przypadkach masz kompilacje aot. ale juz teoretyczna przenosnosc clr jakos w praktyce slabo zostala zweryfikowana (w przeciwienstwie do jvm ex-sunowskiego).
pod skrzydlami google? to nie wiesz ze juz dawno sie poddali? przecenili swoje sily przy unladenie :>
"wydawalo im sie" to prostym zadaniem, podobnie jak parrotowcy przekonywali ze w rok zrobia i vm i wlasna implementacje pythona, szybsza od cpythona :D
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).
Grzybsonowi piorą mózgownicę na tych studiach.
(Się dorzucam do offtopa:)).
Cóż, mam lekką awersję do języków które wywodzą się z basica, w których dodatkowo whitespace ma znaczenie.
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.
Marzy mi się aby to wszystko chodziło pod jednym vmem - szybko łatwo i przyjemnie. Myślę że najlepszym kandydatem na to jest .netowy CLR (bo wydaje mi się być lepiej pomyślany od javy, cóż chłopaki piszący założenia CLRa mogli uczyć się na błędach javy i wygląda na to że nieźle im to wyszło.
CLR powstał po JVM. Wiedzieli już jak projektować. Jeśli o mnie chodzi - nadal zbyt duży bloatware.
Pythonowy vm wydaje mi się na razie nie spełniać jednego bardzo istotnego założenia - brak wielowątkowości (mówię tu o podstawowym cpythonie). No ale zobaczymy jak się rozwinie pod skrzydłami Googla.
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.
Jak zwykle M$ musi robić to samo ale po swojemu.... dotnet to w idei po prostu java.
A wszystko i tak wraca do wcześniejszych wersji...java to współczesna realizacja środowiska UCSD p-code
VMware itp. to wcielenie środowiska IBM VM/CMS.. nie odkrywamy niczego nowego.
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.
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.
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 ;)
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. :-)
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.
Nieprzenośność zawsze będzie wadą. Tak samo jak CS. W przypadku Mono - sami musieli pisać wszystko od zera.
Ojtam ojtam, wiadomo że pionierzy byli długo przed nami, ale dopiero my mamy szansę skorzystać z tego szeroko. IBM to umożliwiałna mainframie który miał wielkość dwóch szaf gdańskich i chodziło to średnio szybko ;). Dziś więcej/szybciej masz w telefonie :)
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/
google nie porzucilo pythona (nadal to glowny jezyk z ktorego korzystaja, w tym glownie w celach administracyjnych).
rakiem za to wycofuja sie z unladena.
ruby wolne? obecnie ruby jest znacznie szybszy od cpythona, choc w swiecie jit i tak lua króluje, bo developera luajit2 nie da sie po prostu zastapic :D
go, choc ma calkiem przyjemna skladnie i fajne koncepcje to nie dosc ze jest jezykiem statycznie typowalnym, to jest statycznie kompilowalnym (jak c) co obecnie juz wiemy ze jest wada (wymaga fpyte pracy na opytamlizacje). w przeciwienstwie do c ma za to strasznie przechujowe kompilatory, ktore latami beda musialy dochodzic do generowania kodu przynajmniej w czesci zblizonego wydajnosciowo do visualstudio, llvm czy gcc.
skomplikowaliscie moj prosty swiat
ja tydzien temu odkrylem svn
jezeli vcs ma sluzyc tylko i wylacznie jednej osobie kodujacej sobie popoludniami costam to naprawde nic ponad cvs nie potrzeba :) wtedy nawet svn to za duzo :)
Statyczne typowanie jest wadą... i wie o tym obecnie już więcej niż jedna osoba... fascynujące ;)
Statyczne/Dynamiczne typowanie jak wszystko ma swoje zady i walety ;)
jezeli vcs ma sluzyc tylko i wylacznie jednej osobie kodujacej sobie popoludniami costam to naprawde nic ponad cvs nie potrzeba :)
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
nie czaje waszego narzekania
nie czaje o czym Wy tu wogóle piszecie... :-)
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.
Czy brakuje Wam sukcesów zawodowych, czy coś w tym stylu, że musicie sobie tutaj udowadniać, kto jest najlepszym programistą i architektem kompilatorów? Tak się zastanawiam skąd to się bierze.
Kryzys wieku średniego ?
Przypominam, że wątek nie jest o tym jaki VCS jest najlepszy.
A o czym?
Tak sobie flejmuje, ale głównie bierze się to stąd że ostatnio sporo się narobiło różnych VMów, widać to szczególnie pod Linuxem. Jest jvm, .net (mono), python, parrot, różne enginy javascriptu itp. że wspomnę o tych najpopularniejszych (w podstawowej instalce aktualnego Ubuntu na starcie odpalany jest conajmniej javascriptowy vm no i python). Wszystko ma swój narzut i zabiera pamięć i procka. Marzy mi się aby to wszystko chodziło pod jednym vmem - szybko łatwo i przyjemnie. Myślę że najlepszym kandydatem na to jest .netowy CLR (bo wydaje mi się być lepiej pomyślany od javy, cóż chłopaki piszący założenia CLRa mogli uczyć się na błędach javy i wygląda na to że nieźle im to wyszło. Nie wiem jak parrot - teoretycznie jest pod to sporo języków ale czy to ma faktycznie ręce i nogi to chyba jeszcze nikt specjalnie nie sprawdzał. Pythonowy vm wydaje mi się na razie nie spełniać jednego bardzo istotnego założenia - brak wielowątkowości (mówię tu o podstawowym cpythonie). No ale zobaczymy jak się rozwinie pod skrzydłami Googla.
Ć mnie się podoba, ale mi chodzi o działanie w drugą stronę -> wszystkie języki wykonwywane przez jeden VM.
jezeli vcs ma sluzyc tylko i wylacznie jednej osobie kodujacej sobie popoludniami costam to naprawde nic ponad cvs nie potrzeba :) wtedy nawet svn to za duzo :)
W takim przypadku nic innego niż git nie potrzeba. Zakładasz lokalne repozytorium w 0,5 sekundy.
In Polish "ci" is pronounced identically to "ć".
To twierdzenie chyba nie da się obronić ;)
Fox: początkowo ten wątek to był offtopic w jednym z moich tematów.
Ć mnie się podoba, ale mi chodzi o działanie w drugą stronę -> wszystkie języki wykonwywane przez jeden VM.
takim vm bedzie np. bochs.
hint - to, co wydajnie dziala pod vm javy, nie koniecznie bedzie wydajnie dzialac pod vm perla. zapominasz ze jezyki roznia sie nie tylko semantyka...
fox: ten silverlight nawet ladnie mi dziala pod chromium pod linuksem ;)
Strony Poprzednia 1 2 3 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Bałagan » Systemy kontroli wersji
Wygenerowano w 0.080 sekund, wykonano 31 zapytań