@Rastan: gdzie i kiedy ich bronił?

@Rastan: a wina Michnika polega na pokrewieństwie?

atari_classic: pokazywali i to dość dokładnie. Tak samo jak wybryki drugiej strony. Każdy ciągnie w swoją i manipuluje.

Już od dawna możemy: http://dhs.nu/files.php?t=partydl&p … ure%202011

Można równać w górę :)

To się pewnie da zrobić, ale w kontekście jednej, zamkniętej platformy, tak jak to robił/robi IBM.

Mamy zasadniczo jeden dominujący paradygmat programowania (strukturalne/proceduralne/obiektowe) (+jego odmiany i bliscy koledzy). Wydaje mi się że można stworzyć VM który będzie wydajny i dobry do większości języków opartych na tym paradygmacie (a i pewnie języki funkcyjne da się podciągnąć), przynajmniej te o statycznym typowaniu. Boję się jednak że taki projekt 'uniwersalnego' VM stworzyłby po prostu kolejne, używane przez małą grupę ;)

Dzięki za naprawdę super imprezę. Ze swojej strony deklaruję dokładnie to samo - pomogę ile będę mógł. Mam nadzieję że spodobała się organizacja ST Compo, następnym razem będzie lepiej :)

Doświadczenia mam. Używam i działa. Używam serwera Rygel i Telewizora Sony.

Problem bywa z kodekami akceptowanymi przez TV. Teoretycznie powinien to sobie wynegocjować z serwerem, a serwer (o ile ma taką funkcję) konwertować w locie do tego co może obsłużyć TV (o ile TV nie obsługuje formatu oryginalnego). De facto zazwyczaj się to kończy kiepsko i nie działa jak trzeba. Dlatego ja wszystko konwertuje na format który TV obsługuje bezproblemowo (w wypadku video to u mnie jest MPEG4) i wtedy faktycznie to śmiga. Nawet sobie napisałem skrypt w bashu do tego i podpiąłem do programów którymi ściągam.

Samego SAPa zapewne żaden TV nie odtworzy. Musisz przekonwertować na jakiś bardzie popularny format, najlpepiej pewnie MP3.

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 :)

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

Te pieniądze których 'ludzie nie chcę wydawać' w ogromnej większości i tak leżą na kontach bankowych i banki nimi obracają. Niestety/stety żyjemy w czasach gospodarki światowej gdzie np. dewaluacja waluty RPA wpływa na notowania polskiej giełdy. Wszystko jest ze wszystkim połączone i prostych odpowiedzi dlaczego coś się dzieje nie ma.

Moja teoria jest taka: funkcją każdego przedsiębiorstwa jest maksymalizacja zysku. Są w stanie to robić w tylko w pewnym okresie czasowym, gdyż nikt nie potrafi przewidywać przyszłości, a konkretniej im dalej z przewidywaniami tym są one gorszej jakości. Do tego świat cały czas się zmienia i wdrażane są nowe technologie, np. na rynku finansowym nikt dwadzieścia lat temu nie słyszał o derywatach - to jest zupełnie nowa technologia na którą rzuciły się rynki finansowe i co doprowadziło do krachu. Dopiero w tym momencie można było w pełni zrozumieć wady i zalety tej technologii finansowej. Rynek dokona z czasem regulacji (sam lub wymuszonej) i będziemy mieli następny cykl koniunkturalny. To jest naturalne i nie ma z tym co walczyć. Przewidzieć tego się też za bardzo nie da: Ci którzy twierdzą że im się udało, to zwykły szum statystyczny (tj. prawdziwość przepowiedni stwierdza się po fakcie :)).

Za życia czeka nas jeszcze kilka takich cykli i kryzysów wywołanych zmianami technologicznymi. Z tego co widać to na horyzoncie mamy: wyczerpanie się paliw kopalnych (a raczej tzw. peak oil), nanotechnologię, augmented reality oraz upowszechnienie się protez cybernetycznych.

Taki rodzaj poczucia humoru. Zresztą, wydaje mnie się, że Linus mocno zapracował na prawo bycia egocentrykiem. Wszystko ma swoje zady i walety i tyle :)

Jak wiadomo, najlepsza jest konkurencja. Czasem jednak tak jest że pokazuje się jakaś nowa technologia i sporo ludzi chwyta się za głowę "Jak myśmy dotychczas pracowali? Przecież to nowe jest o tyle i tyle lepsze", zaś kombatanci olewają to ciepłym moczem bo są mastachami od dawna używanych rozwiązań i nie chcą poznawać nowych. Tak jest właśnie z VCSami - kiedys wszyscy używali CVSa względnie SVNa, ale od momentu rozpowszechnienia się VCSów rozproszonych jakoś nie wydaję mi się aby nadal był wielki sens używać scentralizowanych. Zauważcie też pewien skok - rozproszone VCSy dały nam dodatkowe (bardzo użyteczne) narzędzia które były jak najbardziej możliwe do realizacji w scentralizowanych, tylko jakoś nikt o nich nie pomyślał (pisze tu o bisect'ach i blame'ach).

Konkludując: to że bawimy się maszynami sprzed 20 lat, nie oznacza że musimy używać tak samo przestarzałych narzędzi :)