programy pod komórkę
wo3kie
Korzystając z okazji i odrobiny wolnego czasu, chciałem sobie troszkę
pokodowac w okresie świątecznym. Wybór padł na programowanie komórek.
Ma ktoś jakieś doświadczenia, porady How To Start?
Wybór padł na telefon mojej dziewczyny. iPhona. Ale podobno iPhone SDK
jest dostępne tylko pod Mac'a. Zniechęciło mnie to. Nie mniej niż
dziwaczna składnia Objective C. IMHO jest beznadziejna.
To może Symbian? Mój telefon ma QIU które podobno nie jest już
wspierane.
To może BlackBerry? Ale tam jest podobno wszystko w Javie. A ja Javy
nie ten tego.
Ponadto jest strasznie dużo środowisk, platform... troszkę się
pogubiłem.
Jeżeli się nie będę potrafił zdecydować, to coś mi się zdaje, że po
prostu powtórzę sobie wybrane zagadnienia z Algorytmiki. Wiedza
wolniej się starzeje, jest o wiele bardziej przenośna i nie zależy od
platformy ;O)
Lukasz
Paweł
> wspierane.
Od niedawna jest dostepna wersja biblioteki QT pod Symbiana. Nie wiem
jak jest z programowaniem pod komorki, ale pod win pisze mi sie bardzo
przyjemnie w tej bibliotece.
http://developer.symbian.org/wiki/index.php/Qt_Quick_Start
n...@mail.invalid
<snips />
> Wybór padł na telefon mojej dziewczyny. iPhona. Ale podobno iPhone SDK
> jest dostępne tylko pod Mac'a. Zniechęciło mnie to. Nie mniej niż
> dziwaczna składnia Objective C. IMHO jest beznadziejna.
>
> To może Symbian? Mój telefon ma QIU które podobno nie jest już
> wspierane.
>
> To może BlackBerry? Ale tam jest podobno wszystko w Javie. A ja Javy nie
> ten tego.
Dodaj do tego jeszcze platformę Android, która również oparta jest o Javę.
> Ponadto jest strasznie dużo środowisk, platform... troszkę się
> pogubiłem.
Do przenośnych aplikacji mobilnych powstała J2ME. W Windows(CE) jest
m.in. .NET CF, jeśli interesuje cię pisanie w C#, C++/CLI.
Nie mając urządzenia do dyspozycji, możesz użyć SDK+emulatora.
Wydaje się, że najbliższa programistycznie C++ jest platforma Maemo oraz
OpenMoko.
> Jeżeli się nie będę potrafił zdecydować, to coś mi się zdaje, że po
> prostu powtórzę sobie wybrane zagadnienia z Algorytmiki. Wiedza wolniej
> się starzeje, jest o wiele bardziej przenośna i nie zależy od platformy
> ;O)
Bez wątpienia. :-)
--
Pozdrowienia
Artur M. Piwko
wo3kie <wo3...@gmail.com> screamed:
> Korzystając z okazji i odrobiny wolnego czasu, chciałem sobie troszkę
> pokodowac w okresie świątecznym. Wybór padł na programowanie komórek.
>
> Ma ktoś jakieś doświadczenia, porady How To Start?
>
> Wybór padł na telefon mojej dziewczyny. iPhona. Ale podobno iPhone SDK
> jest dostępne tylko pod Mac'a. Zniechęciło mnie to. Nie mniej niż
> dziwaczna składnia Objective C. IMHO jest beznadziejna.
>
Dodaj jeszcze do tego zimowanie projektu w Apple Store. No, chyba,
że chcesz zrobić jailbreak w iCrapie.
> To może Symbian? Mój telefon ma QIU które podobno nie jest już
> wspierane.
>
Carbide jeszcze powinno na nim działać. Jest jeszcze multiplatformowe
Qt, ale nie wiem czy wspiera UIQ czy tylko S60.
> To może BlackBerry? Ale tam jest podobno wszystko w Javie. A ja Javy
> nie ten tego.
>
Skoro Javy nie ten tego, to odpada Ci także i Android.
> Ponadto jest strasznie dużo środowisk, platform... troszkę się
> pogubiłem.
>
Zostaje Ci chyba Windows Mobile...
--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:213B ]
[ 09:43:10 user up 12293 days, 21:38, 1 user, load average: 0.56, 0.61, 0.45 ]
Grain grows best in shit.
wo3kie
> > To może Symbian? Mój telefon ma QIU które podobno nie jest już
>
> Od niedawna jest dostepna wersja biblioteki QT pod Symbiana. Nie wiem
> jak jest z programowaniem pod komorki, ale pod win pisze mi sie bardzo
> przyjemnie w tej bibliotece.http://developer.symbian.org/wiki/index.php/Qt_Quick_Sta
Kiedyś dużo grzebałerm w Qt pod Linuxem. Potem miałem ze dwa lata
przerwy, ale jakieś podstawy zawsze zostały. Chętnie znowu wrócę i
pobawię się Qt+Symbian. Dzięki :O)
Lukasz
mgk
Czy nie umiesz / nie lubisz obiektowosci?
Czy slyszales bez wartosciowe plotki ze Java jest kilka razy mniej
wydajna (jest mniej wydajna, ale jakies 20% a nie kilka razy).
Java na komorki to najbardziej przenosny sposob pisania aplikacji, a z
tego co napisales wnioskuje ze zalezy Ci by dalo sie uruchomic na jak
najwiekszej ilosci telefonow.
Ale i tak sa problemy. Wiekszosc telefonu jest srednio zgodna z Java.
Bugi w implementacji maszyny wirtualnej. Sony Erricsony maja najlepsza
zgodnosc z Java, a zaraz po nich sa Nokie. Najgorzej jest z
Samsungami. Samsungi to shit.
wo3kie
> Czy nie umiesz / nie lubisz obiektowosci?
A co ma obiektywność do Javy? Piszesz tak jakby Java była jedynym
obiektowym językiem. I jakby C++ nie był obiektowy w ogóle.
> Czy slyszales bez wartosciowe plotki ze Java jest kilka razy mniej
> wydajna (jest mniej wydajna, ale jakieś 20% a nie kilka razy).
To jest akurat podyktowane wymaganiami projektu. W pracy w obecnym
projekcie używamy C++, dlatego, że Java nawet by tego nie pociągnęła.
Osobiscie do pisania Utilsów używam Ruby który jest dużo wolniejszy
niz np.: Python, jednak mnie to nie zniechęca do języka bo pisze mi
się w nim łatwo prosto i przyjemnie.
Co mnie tak naprawdę w Javie zniechęca. Czytałem kilka książek o Javie
i każda z nich opisywałą inna bibliotekę IO. Jak to opowiadałem
koledze, powiedział, że nie, żadna z nich nie jest dobra. Polecił mi
czwartą, kolejną bibliotekę.
Jest to moje subiektywne odczucie. Nie bo nie, bez żadnych przyczyn
technicznych. Wiesz, ja lubię pogrzebać w STL, pobawić się szablonami,
wskaźnikami, pogrzebać w pliku CORE. Taki mały fetysz (O:
Lukasz
Maciej Sobczak
> Czy nie umiesz / nie lubisz obiektowosci?
A co jeśli nie lubi Javy właśnie dlatego, że rozumie i lubi
obiektowość?
Hint: skąd niby wiadomo, że obiektowość w Javie jest zrobiona
poprawnie?
> Czy slyszales bez wartosciowe plotki ze Java jest kilka razy mniej
> wydajna (jest mniej wydajna, ale jakies 20% a nie kilka razy).
To zależy od benchmarka. Np. w moim Java jest 3x wolniejsza.
Na każdą "bezwartościową plotkę" można zapisać benchmark, który ją
zmaterializuje.
(o, jest jeszcze szansa na przedświąteczny flejm ;-) )
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
mgk
Pytanie kiedy tego benchmarka pisales. Jak 10 lat temu to jestem
wstanie uwiezyc ze 3 razy.
Tyle ze od tego czasu Java sie bardzo zmienila.
Natomiast ja dysponuje benchmarkami ktore sa rownie wydajne jak wersja
w C++.
A niektore nawet wydajniejsze (to wynika z tego ze aby uzyskac taka
wydajnosc w C++ jak w Javie trzeba by napisac wlasny memory manager).
A tak srednio w dzisiejszych benchmarkach ktore nie sa ukierunkowane
by pokazac slabosc javy (np wywolujac cos co jest wolniejsze w Javie,
tyle ze to cos uzywa sie w realnym programie przez 1% czasu) a jedynie
ukierunkowane na realne problemy to Java wypada srednio 20% wolniej.
Napisz benchmarka w ktoeym jest mnostwo obliczen, pare klas, metody
wirtualne, duzo odwolan do tablic, sporo alokacji pamieci. Ja taki
napisalem. I Java wypadla tylko 20% wolniej.
Krzysiek Kowaliczek
>
> Pytanie kiedy tego benchmarka pisales. Jak 10 lat temu to jestem
> wstanie uwiezyc ze 3 razy.
>
> Tyle ze od tego czasu Java sie bardzo zmienila.
Zmieni�a si� maszyna wirtualna, a nie Java. Szkoda, poniewa�
ma�ym kosztem mo�na by�oby uzyska� wi�ksz� wydajno�� za
pomoc� klas warto�ci.
>
> Natomiast ja dysponuje benchmarkami ktore sa rownie wydajne jak wersja
> w C++.
W sieci jest tego wiadrami. Tylko mnie kilkudziesi�cio/set linijkowe
testy nie interesuj�. Ale zrobi� wyj�tek:
http://shootout.alioth.debian.org/u32/java.php
Mnie najbardziej interesuje zu�ycie pami�ci, a tutaj Java wypada
blado.
> A niektore nawet wydajniejsze (to wynika z tego ze aby uzyskac taka
> wydajnosc w C++ jak w Javie trzeba by napisac wlasny memory manager).
>
Mit, np alokacja na Linuksie + GCC dzia�a bardzo szybko.
Zreszt� widzisz, mam jaki� wyb�r. Jak stan� pod �cian�,
to zostaje jaka� mo�liwo�� optymalizacji np.: pule obiekt�w,
alokator ma�ych obiekt�w, itp.
> A tak srednio w dzisiejszych benchmarkach ktore nie sa ukierunkowane
> by pokazac slabosc javy (np wywolujac cos co jest wolniejsze w Javie,
> tyle ze to cos uzywa sie w realnym programie przez 1% czasu) a jedynie
> ukierunkowane na realne problemy to Java wypada srednio 20% wolniej.
Tendencja jest raczej odwrotna. Na si�� pr�buje udowodni� si�,
�e Java jest szybsza od C++. Cz�sto te "benchmarki" s� napisane
przez ludzi, kt�rzy maj� ma�e do�wiadczenie w C++.
> Napisz benchmarka w ktoeym jest mnostwo obliczen, pare klas, metody
> wirtualne, duzo odwolan do tablic, sporo alokacji pamieci. Ja taki
> napisalem. I Java wypadla tylko 20% wolniej.
>
Sam napisz, zobaczymy o ile uda siďż˝ to przyspieszyďż˝ :).
Pozdrawiam
KK
Maciej Wawrzynczuk
> On 22 Gru, 11:02, mgk <mgki...@wp.pl> wrote:
>> A mozna wiedziec czemu Javy "nie tego"? Czy nie umiesz / nie lubisz
>> obiektowosci?
>
> A co jeśli nie lubi Javy właśnie dlatego, że rozumie i lubi obiektowość?
>
> Hint: skąd niby wiadomo, że obiektowość w Javie jest zrobiona poprawnie?
A co jest niby niepoprawnego w obiektowości Javy? Można w niej robić dużo
fajnych, obiektowych rzeczy. Np. tworzyć obiekty. :)
wo3kie
wrote:
Nie należy zapominać o korzeniach ani się ich wstydzić. C++ wywodzi
się z C, które powstało bo pisania systemów operacyjnych. Java
powstała do programowania mikrofalówek.
A wracając do Qt. Widzę, że bardzo się przez te dwa lata zmieniło.
Nokia wykupiła Trolltecha, rozbudowali QtDesigner, który z prostego
edytora komponentów stał się bardzo ładnym edytorem IDE. Wiecie może,
jakie są tendencje na świecie jeżeli chodzi o Qt? Zdobywa coraz
większą popularność, odchodzi w niszę, warto inwestować czas na
pogłębienie wiedzy...
Chętnie bym wrócił do Qt. Jestem jednak świadom ogromu biblioteki i
masy pracy jaką należy włożyć w jej opanowanie. Z drugiej jednak
strony wcale nie potrzebuje jej w obecnej pracy, więc była by to nauka
czysto hobbistyczna, [p godzinach z prywatnego czasu którego z roku na
rok mam coraz mniej :O(. Nauka która być może przyda mi się w
przyszłości - ale wcale nie musi.
Z drugiej jednak strony jest to chyba najpoważniejsza i najlepsza
biblioteka do budowania interfejsów w C++ - o którym standard języka
nie wspomina, niestety tak jak w Javie, ani słowem.
Regards,
Łukasz
Maciej Sobczak
> Pytanie kiedy tego benchmarka pisales. Jak 10 lat temu to jestem
> wstanie uwiezyc ze 3 razy.
Dwa albo trzy *miesiące* temu. Java 1.6.
Żeby była jasność - ten "benchmark" to nie pętla na integerach (co
zwykle jest tematem klasycznych benchmarków), ale system do
przesyłania komunikatów przez sieć. Mam dwie implementacje, jedną w C+
+ i drugą w Javie. Architektury w sensie układu wątków i struktury
danych są identyczne, protokoły te same, oba systemy używają gniazd
nieblokujących. Wersja w C++ przepycha 45k msg/s między dwoma
maszynami, wersja w Javie wyciąga 15k.
Obie wersje napisałem sam, ale wynik mnie nie zaskakuje, bo podobne
relacje obserwuję przy innych systemach tego typu.
Zachodzi podejrzenie, że w Javie NIO jest do dupy.
I teraz najciekawsze: w systemie rozproszonym interakcje zdalne są
zwykle jego najwolniejszą częścią (hint: w klasycznych enterprajzach
widać to przy bazach danych), więc nie ma znaczenia, jak szybka jest
Java w pętli na integerach. Nawet jeśli dzięki cudownym właściwościom
JIT i GC Java zakręci integerową pętlą szybciej niż C++, to cały
system będzie w Javie i tak wolnieszy.
> Napisz benchmarka w ktoeym jest mnostwo obliczen, pare klas, metody
> wirtualne, duzo odwolan do tablic
Jak już wspomniałem, kręcenie pętlami na integerach nie jest moją
specjalnością.
Maciej Sobczak
> Z drugiej jednak strony jest to chyba najpoważniejsza i najlepsza
> biblioteka do budowania interfejsów w C++ - o którym standard języka
> nie wspomina, niestety tak jak w Javie, ani słowem.
W Javie standard języka też nie wspomina o GUI ani słowem.
I nie chodzi nawet o to, że Java w ogóle nie ma żadnego standardu.
Nawet jeśli przymkniemy mocno oko i będziemy udawać, że spec do Javy
pełni tą samą rolę co standard C++, to tak czy siak nie ma tam ani
słowa o GUI.
Można co najwyżej zauważyć, że pewien producent rozwiązań opartych o
Javę produkuje kompletny pakiet zawierający kompilator oraz bogatą
bibliotekę obsługującą między innymi GUI.
Ale uwaga niespodzianka - dokładnie to samo można powiedzieć o C++.
Reszta to marketing.
Maciej Sobczak
wrote:
> > A co jeśli nie lubi Javy właśnie dlatego, że rozumie i lubi obiektowość?
>
> > Hint: skąd niby wiadomo, że obiektowość w Javie jest zrobiona poprawnie?
>
> A co jest niby niepoprawnego w obiektowości Javy?
Hm... niemal wszystko.
Brak wielodziedziczenia, wielometod, kontrawariancji typów,
schizofreniczny podział typów na trzy kategorie, z czego dwie są
"obiektowe" (klasy i interfejsy) i w niektórych miejscach zachowują
się tak samo a w innych różnie, nieortogonalność mechanizmów kontroli
dostępu względem położenia w hierarchii, ogólnie spieprzony model
obiektu uniemożliwiający nawet odróżnienie tak fundamentalnych pojęć
jak agregacja i kompozycja.
To tak na szybko. :-)
Tak patrząc bliżej, to nawet prostego diagramu UML nie da się w Javie
dokładnie odwzorować. Aż dziw bierze ilu ludzi upiera się, że to jest
w ogóle język obiektowy (niektórzy to go nawet używają w celach
dydaktycznych - łomatko).
Czy język, który nie jest kompatybilny z UML może być obiektowy? :-)
mgk
Musisz wrocic na studia, albo poczytac troche ksiazek. Brakuje Ci
wiedzy np na temat dlaczego w nowoczesnych jezykach odchodzi sie od
wielodziedziczenia. Ani Java ani C# go nie maja. I maja po temu
powody.
Poczytaj czym rozni sie kompozycja od agregacji. Jestes juz druga
osoba ktora widze ktora mysli ze kompozycja od agregacji rozni sie
tym, ze w w jednym mamy wskaznik, a w drugim obiekt wbudowany w drugi
- co jest bzdura.
Mozesz miec i kompozycje i agregacje bez wbudowywania fizycznie
obiektu jeden w drugi na wskaznikach/referencjach. To co wyroznia
kompozycje to to, ze obiekt A sklada sie z B. Czyli praktycznie na B
nie wskazuje nic po za A. Ale wcale to nie znaczy ze nie moga byc
polaczone wskaznikiem czy referencja.
A co do UML to wlanie najwiecej narzedzi jest do Javy. Dziwne ze
mowisz o UML a nie wiesz czym rozni sie kompozycja od agregacji. W UML
to podstawa.
Jędrzej Dudkiewicz
> On 23 Gru, 17:45, wo3kie <wo3...@gmail.com> wrote:
>
>> Z drugiej jednak strony jest to chyba najpoważniejsza i najlepsza
>> biblioteka do budowania interfejsów w C++ - o którym standard języka
>> nie wspomina, niestety tak jak w Javie, ani słowem.
>
> W Javie standard języka też nie wspomina o GUI ani słowem.
> I nie chodzi nawet o to, że Java w ogóle nie ma żadnego standardu.
> Nawet jeśli przymkniemy mocno oko i będziemy udawać, że spec do Javy
> pełni tą samą rolę co standard C++, to tak czy siak nie ma tam ani
> słowa o GUI.
Wiem, że to nic nie wniesie, ale chciałem zauważyć, że wo3kie napisał
dokładnie to samo - że w Javie też nic nie ma o GUI.
JD
Maciej Wawrzynczuk
> On 23 Gru, 12:52, Maciej Wawrzynczuk <mwawrzyn.wy...@to.aster.pl> wrote:
>
>> > A co jeśli nie lubi Javy właśnie dlatego, że rozumie i lubi
>> > obiektowość?
>>
>> > Hint: skąd niby wiadomo, że obiektowość w Javie jest zrobiona
>> > poprawnie?
>>
>> A co jest niby niepoprawnego w obiektowości Javy?
>
> Hm... niemal wszystko.
> Brak wielodziedziczenia, wielometod, kontrawariancji typów,
> schizofreniczny podział typów na trzy kategorie, z czego dwie są
> "obiektowe" (klasy i interfejsy) i w niektórych miejscach zachowują się
> tak samo a w innych różnie, nieortogonalność mechanizmów kontroli
> dostępu względem położenia w hierarchii, ogólnie spieprzony model
> obiektu uniemożliwiający nawet odróżnienie tak fundamentalnych pojęć jak
> agregacja i kompozycja.
>
> To tak na szybko. :-)
No dobra, tylko że ja bym tego wszystkiego nie nazwał kwintesencją
obiektowości. Poza tym sprawa wielodziedziczenia jest kontrowersyjna - w
co bardziej ułomnych językach celowo się z tego rezygnuje. Widać są
powody. Jedyne z czym się można zgodzić to ta nieszczęsna agregacja i
kompozycja. Tylko czy komuś to w praktyce przeszkadza?
> Tak patrząc bliżej, to nawet prostego diagramu UML nie da się w Javie
> dokładnie odwzorować. Aż dziw bierze ilu ludzi upiera się, że to jest w
> ogóle język obiektowy (niektórzy to go nawet używają w celach
> dydaktycznych - łomatko).
> Czy język, który nie jest kompatybilny z UML może być obiektowy? :-)
A od kiedy to UML jest wyznacznikiem obiektowości? To jest spisek
producentów narzędzi graficznych. ;)
Chyba nie chodzi o to, żeby w dowolnum języku idealnie odwzorować każdy
UMLowy bohomaz. Toć na kształt projektu cechy języka zawsze będą miały
wpływ.
PS: Wesołych! :)
wo3kie
wrote:
> >> > Hint: skąd niby wiadomo, że obiektowość w Javie jest zrobiona
> >> > poprawnie?
Jezeli sie porownamy z Rubym lub Smalltalkiem to zarowno C++ jak i
Java wypadaja blado.
Ale za to C++ jest nieprzecietnie elastyczny. Brakuje wielu rzeczy
ktore jednak mozna samemu zaimplementowac.
Tablica ma indeksowanie ktore nie sprawdza zakresow. Szybkie ale
niebezpieczne. Jezeli jednak chcemy zrobic to w sposob bezpieczny
mozemy, metoda at, checked_iterator, napisac samemu... W Javie jest
bezpieczne indeksowanie, ale jednak jezeli jestesmy pewni zakresu i
chcemy przeiterowac sie po nim szybko - nie da rady.
Tak samo z zarzadzaniem pamieci. Jezyk C++ go sam nie wspiera (ew.
automatyczne wolanie destruktorow). Ale mozna skorzystac z puli
obiektow, inteligentnych wskaznikow, alokatorow... wybrac najbardziej
odpowiedni mechanizm dla siebie poparty np.: testami wydajnosciowymi.
W Javie ktos dostarczyl Garbage Collector, ktory mial byc lekarstwem
na wszystko a tak naprawde jest jednym ze slabych punktow jezyka.
Dla mnie powaznym brakiem w Javie jest brak mozliwosci przeladowania
operatorow. Argument, ze mozna bardzo nieintuicyjnie przeciazyc
operator utrudniajac innym czytanie kodu jest niedorzeczny. Jezyk nie
ma bronic sam siebie przed idiotami, ma dostarczac rozne mechanizmy
dla bardziej inteligentnych programistow. Zawsze mozna nazwac funkcje
w niedorzeczny sposob, nawet korzystajac tylko ze zbioru liter i cyfr.
Nie wspominajac o wadach w generykach Javowych. Ale to juz nie jest
cecha obiektowosci. ;O)
Lukasz
mgk
> niebezpieczne. Jezeli jednak chcemy zrobic to w sposob bezpieczny
> mozemy, metoda at, checked_iterator, napisac samemu... W Javie jest
> bezpieczne indeksowanie, ale jednak jezeli jestesmy pewni zakresu i
> chcemy przeiterowac sie po nim szybko - nie da rady.
Nie prawda. Tez kiedys tak myslalem. Okazuje sie ze kompilator /
maszyna Javy umie obczaic ze w danej petli sprawdzanie zakresow jest
zbedne.
Bardzo latwo mozesz sie o tym przekonac piszac program mnazacy bardzo
duze macierze w C++ i Javie. Ostatni taki napisalem i wydajnosc byla
IDENTYCZNA.
mgk
> ma bronic sam siebie przed idiotami, ma dostarczac rozne mechanizmy
> dla bardziej inteligentnych programistow. Zawsze mozna nazwac funkcje
> w niedorzeczny sposob, nawet korzystajac tylko ze zbioru liter i cyfr.
Kiedys tak samo mowili programisci asma o programistach C.
A potem programisci C o programistach C++.
A teraz programisci C++ o programistach Javy.
I tak historia sie powtarza.
A praktyka pokazuje ze programista nie jest Bogiem. Jest omylny. I
tworzac coraz wieksze projekty potrzebujemy coraz bezpieczneijszych
jezykow.
Mase firm woli poswiecic 10-20% wydajnosci kosztem 50% wiekszej
produktywnosci.
DLa ciekawosci. Poszukaj prezentacji:
"The Next Mainstream Programming Language:
A Game Developer’s Perspective"
Tim Sweeney
Epic Games
Tam jest koncept nowego jezyka programowania jeszcze bezpieczniejszego
niz Java. Ktory ma sie dobrze spisac w duzych projekach a glownie w
grach oraz aplikacjach wykonujacych sporo obliczen.
Krzysiek Kowaliczek
> Kiedys tak samo mowili programisci asma o programistach C.
> A potem programisci C o programistach C++.
> A teraz programisci C++ o programistach Javy.
Z tą tylko "drobną" różnicą, że w przypadku C++ mamy
taką samą wydajność co w C. W przypadku C++ i Dżawa
tak nie jest. Więc twoje porównanie jest chybione.
> Mase firm woli poswiecic 10-20% wydajnosci kosztem 50% wiekszej
> produktywnosci.
Nie ma to jak dane z czapki. Ale panie u mnie Dżawa nie ma
szans, przetwarzanie zajmuje nawet kilkanaście gigabajtów.
Więc nawet te 10-20% wolniej ( a raczej 300% ) i tak na nic się
nie zda, skoro braknie pamięci.
Pozdrawiam
KK
mgk
> szans, przetwarzanie zajmuje nawet kilkanaście gigabajtów.
> Więc nawet te 10-20% wolniej ( a raczej 300% ) i tak na nic się
> nie zda, skoro braknie pamięci.
Twoje 300% to sa dane z czapki.
Nawet wszedzie sie ogolnie przyjmuje 10-20%.
Jakikolwiek benchmark tak Ci tez poda.
I nikogo nie obchodzi ze 1 osoba na swiecie zmierzyla jakims dziwnym
trafem 300%.
I to do tego predkosc przesylania danych po sieci... jakby java miala
cos do predkosci twojej karty sieciowej. lol.
Krzysiek Kowaliczek
> Twoje 300% to sa dane z czapki.
> Nawet wszedzie sie ogolnie przyjmuje 10-20%.
>
Skoro uwa�asz takie te�ciki za miarodajne, podam jeszcze raz:
http://shootout.alioth.debian.org/u32/java.php
Jak byk 200-300% dla takich mikrote�cik�w. Dla wi�kszych
program�w mo�e by� jeszcze gorzej jak zacznie "szale�" GC,
jak maszyna wirtualna na bie��co b�dzie musia�a kompilowa�
kod bajtowy, itd.
A jeszcze jedno, czemu nie napiszesz nic o zu�yciu pami�ci?
Jak pisa�em, dla mnie jest to zas�b krytyczny.
> I nikogo nie obchodzi ze 1 osoba na swiecie zmierzyla jakims dziwnym
> trafem 300%.
> I to do tego predkosc przesylania danych po sieci... jakby java miala
> cos do predkosci twojej karty sieciowej. lol.
Problem w tym, �e Maciek pisa� o dw�ch programach robi�cych to *samo*,
tylko ten w D�awie by� *3x wolniejszy*. Wi�c karta sieciowa nie ma tutaj
nic do rzeczy. Jest to tym bardziej ciekawe, poniewa� D�awa od pocz�tku
by�a reklamowana jako j�zyk dla sieci.
Pozdrawiam
KK
Maciej Sobczak
wrote:
> Wiem, że to nic nie wniesie, ale chciałem zauważyć, że wo3kie napisał
> dokładnie to samo - że w Javie też nic nie ma o GUI.
Rzeczywiście - zagubiły mi się kluczowe wyrazy w tym zdaniu.
Nie zmienia to faktu, że jakoś Java potrafiła bardziej niż C++
wypromować się jako narzędzie do takich zastosowań. Nawet nie należy
mieć o to do nikogo pretensji, bo np. WebStart z Qt na dowolnej
maszynie klienckiej nie za bardzo miałby sens, natomiast w Javie nawet
działa.
Maciej Sobczak
> Musisz wrocic na studia, albo poczytac troche ksiazek.
Bardzo chętnie, bo szalenie lubię czytać.
> Brakuje Ci
> wiedzy np na temat dlaczego w nowoczesnych jezykach odchodzi sie od
> wielodziedziczenia.
Hm... niech zgadnę - bo autorzy tych języków są peternalistycznie
nastawieni do swoich użytkowników i gotowi są "uchronić" ich przed
strzelaniem sobie w stopę?
Ponieważ brak mi wiedzy, to poproszę Ciebie o wyjaśnienie mi, jakie
zagrożenie niesie ze sobą wielodziedziczenie, którego nie byłoby
jednocześnie w systemie widoczności nazw w pakietach. I dlaczegóż to w
"nowoczesnych" językach wprowadza się idiotyczną asymetrię, gdzie
chroni się biednego użytkownika przed wielodziedziczeniem a
jednocześnie nie chroni się przed "wieloimportem" (tak to sobie
nazwałem a chodzi o sytuację, gdzie jeden pakiet importuje nazwy z
wielu innych).
Wytłumacz mi czym się te dwa zjawiska różnią.
> Ani Java ani C# go nie maja.
To mają być nowoczesne języki? Pomyliłeś nowe z nowoczesnym.
> Poczytaj czym rozni sie kompozycja od agregacji.
Poleć mi jakąś książkę.
> Jestes juz druga
> osoba ktora widze ktora mysli ze kompozycja od agregacji rozni sie
> tym, ze w w jednym mamy wskaznik, a w drugim obiekt wbudowany w drugi
Nie, nie myślę tak, chociaż te implementacyjne konsekwencje też warto
rozróżniać.
> Mozesz miec i kompozycje i agregacje bez wbudowywania fizycznie
> obiektu jeden w drugi na wskaznikach/referencjach. To co wyroznia
> kompozycje to to, ze obiekt A sklada sie z B.
Właśnie tego nie da się w Javie *deklaratywnie* wyrazić. Pisałem już
tu o tym - poszukaj flejma o mózgach.
> A co do UML to wlanie najwiecej narzedzi jest do Javy.
To jest akurat zjawisko rynkowe. Równie dobrze mógłbyś napisać, że
najwięcej uczelni używa Javy do nauki OO.
> Dziwne ze
> mowisz o UML a nie wiesz czym rozni sie kompozycja od agregacji. W UML
> to podstawa.
No właśnie. Zdumiewające, że nie da się tego deklaratywnie wyrazić w
Javie.
Żeby była jasność - chodzi mi o ten mały diamencik co to czasem jest
czarny a czasem biały. Jak to odróżnić w Javie? Mam sobie *w
komentarzu* napisać, że to jest akurat kompozycja a nie agregacja?
Maciej Sobczak
wrote:
> No dobra, tylko że ja bym tego wszystkiego nie nazwał kwintesencją
> obiektowości. Poza tym sprawa wielodziedziczenia jest kontrowersyjna - w
> co bardziej ułomnych językach celowo się z tego rezygnuje.
Kwintesencja to jest dokładnie to co napisałeś powyżej. :-D
Tak, w *ułomnych* językach się z tego rezygnuje. W ułomnych, bo jest
to ograniczenie projektowo głupie, podobnie jak głupim byłoby
ograniczenie, że np. funkcja może mieć tylko jeden parametr albo
struktura może mieć tylko jedno pole albo tablica może mieć tylko
jeden element.
Ograniczenie wielodziedziczenia nie ma żadnych podstaw teoretycznych
(hint: podstawą teoretyczną jest tu teoria zbiorów), to wynika tylko z
ostrożności implementacyjnej. Sęk w tym, że mnie słabo ta
implementacyjna ostrożność interesuje - jak chcę wyciąć las, to
potrzebna mi piła łańcuchowa a nie jakiś pilniczek.
> Jedyne z czym się można zgodzić to ta nieszczęsna agregacja i
> kompozycja. Tylko czy komuś to w praktyce przeszkadza?
W praktyce? Nie.
Bo jak to mówiono w reklamach tanich proszków do prania - 94% gospodyń
z Bydgoszczy nie widzi różnicy. :-)
> A od kiedy to UML jest wyznacznikiem obiektowości?
Nie jest. Chętnie podyskutuję o innym wyznaczniku, ale sam fakt, że
"można robić obiekty" wydaje mi się niewystarczający.
Sebastian Kaliszewski
> On 23 Gru, 10:54, mgk <mgki...@wp.pl> wrote:
>
>> Pytanie kiedy tego benchmarka pisales. Jak 10 lat temu to jestem
>> wstanie uwiezyc ze 3 razy.
>
> �eby by�a jasno�� - ten "benchmark" to nie p�tla na integerach (co
> zwykle jest tematem klasycznych benchmark�w),
I co nie ma nic wsp�lnego z rzeczywisto�ci� [*]:)
[*] poza rzeczywisto�ci� zabaw w liczenie 30005 pierwszych liczb
pierwszych ;)
> ale system do
> przesy�ania komunikat�w przez sie�. Mam dwie implementacje, jedn� w C+
> + i drug� w Javie. Architektury w sensie uk�adu w�tk�w i struktury
> danych s� identyczne, protoko�y te same, oba systemy u�ywaj� gniazd
> nieblokuj�cych. Wersja w C++ przepycha 45k msg/s mi�dzy dwoma
> maszynami, wersja w Javie wyci�ga 15k.
> Obie wersje napisa�em sam, ale wynik mnie nie zaskakuje, bo podobne
> relacje obserwujďż˝ przy innych systemach tego typu.
> Zachodzi podejrzenie, �e w Javie NIO jest do dupy.
>
> I teraz najciekawsze: w systemie rozproszonym interakcje zdalne sďż˝
> zwykle jego najwolniejsz� cz�ci�
Otďż˝ to :)
Dodam od siebie, �e w wielu systemach je�li w danym punkcie to akurat
nie komunikacja jest w�skim gard�em, to b�dzie nim pami�� (a tu Java te�
kiepsko)
> (hint: w klasycznych enterprajzach
> widaďż˝ to przy bazach danych),
jw :)
> wi�c nie ma znaczenia, jak szybka jest
> Java w p�tli na integerach. Nawet je�li dzi�ki cudownym w�a�ciwo�ciom
> JIT i GC Java zakr�ci integerow� p�tl� szybciej ni� C++, to ca�y
> system b�dzie w Javie i tak wolnieszy.
W j�zyku w kt�rym ka�dy, najdurniejszy obiekt na wsp�czesnej maszynie
musi mie� 20 bajt�w nie ma szans na to by w "real life" (a nie na
sztucznych benchmarkach licz�cych 30005 pierwszych liczb pierwszych) by�
"demonem pr�dko�ci".
>
>> Napisz benchmarka w ktoeym jest mnostwo obliczen, pare klas, metody
>> wirtualne, duzo odwolan do tablic
>
> Jak ju� wspomnia�em, kr�cenie p�tlami na integerach nie jest moj�
> specjalno�ci�.
Je�li za� spojrze� w tym kierunku, to te� jako� nie widz�, by powa�ne
obliczenia w Javie robi�. Ba, cz�ciej je widz� w interpretowanym i
og�lnie wolnym Pythonie (kt�ry cho� sam wolny, to ma biblioteki kt�re
zlecone im kawa�ki licz� ju� szybko).
Bo c�, tego no... powa�ne obliczenia zwykle powa�nie obci��aj�
hierarchi� pami�ci realnego procesora).
pzdr
\SK
--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)
Sebastian Kaliszewski
>> Hm... niemal wszystko.
>> schizofreniczny podzia� typ�w na trzy kategorie, z czego dwie s�
>> "obiektowe" (klasy i interfejsy) i w niekt�rych miejscach zachowuj�
>> si� tak samo a w innych r�nie, nieortogonalno�� mechanizm�w kontroli
>> dost�pu wzgl�dem po�o�enia w hierarchii, og�lnie spieprzony model
>> obiektu uniemo�liwiaj�cy nawet odr�nienie tak fundamentalnych poj��
>> jak agregacja i kompozycja.
>>
>> To tak na szybko. :-)
>>
>> dok�adnie odwzorowa�. A� dziw bierze ilu ludzi upiera si�, �e to jest
>> w og�le j�zyk obiektowy (niekt�rzy to go nawet u�ywaj� w celach
>> dydaktycznych - �omatko).
>> Czy j�zyk, kt�ry nie jest kompatybilny z UML mo�e by� obiektowy? :-)
>>
>> --
>> Maciej Sobczak *www.msobczak.com*www.inspirel.com
>
>
> Musisz wrocic na studia, albo poczytac troche ksiazek.
ROTFL!
> Brakuje Ci
> wiedzy np na temat dlaczego w nowoczesnych jezykach odchodzi sie od
> wielodziedziczenia.
Ale� sk�d. Nie odchodzi si�.
> Ani Java ani C# go nie maja.
Ich nowoczesno�� jest, �e tak powiem, dyskusyjna
> I maja po temu
> powody.
Takie, �e nie umiano tam zaimplemenowa� rzeczy nieco bardziej
skomplikowanej ni� banalna. Javie mo�na wybaczy� bo stara i dobre
rozwi�zania nie by�y jeszcze popularne, ale C# ju� nie mo�na wybaczy�.
Poczytaj sobie jak ten problem rozwi�zuj� a nie omijaj� j�zyki
rzeczywi�cie nowoczesne :)
mgk
Odchodzi sie w firmach od C++. W Polsce jeszcze nie tak bardzo ale na
zachodzie juz bardzo.
Taki super kod z wielodziedziczeniem, szablonami itp potem w
utrzymaniu jest cholernie drogi.
Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Wojciech Jaczewski
> Tak tylko ile jest ogloszen o prace dla Javy, C# a ile dla C++.
> Odchodzi sie w firmach od C++. W Polsce jeszcze nie tak bardzo ale na
> zachodzie juz bardzo.
Jak wida� reklama dzia�a.
�adna du�a korporacja nie ma interesu w promowaniu C++, to i nie jest zbyt
modny. W promowaniu Javy, czy C# du�y interes z pewno�ci� maj� producenci
sprz�tu, bo systemy napisane w tych j�zykach maj� du�e wymagania sprz�towe.
A przy tym tw�rcy tych program�w cz�ciej prezentuj� podej�cie, �e po co
zrobi� co� od razu dobrze, skoro mo�na kupi� lepszy komputer i jako� to
b�dzie dzia�a�.
> Taki super kod z wielodziedziczeniem, szablonami itp potem w
> utrzymaniu jest cholernie drogi.
Standard nie wymusza korzystania z wielodziedziczenia, ani tworzenia
w�asnych szablon�w.
> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Je�li w firmie ma si� ludzi, kt�rzy dok�adniej poznali Jav�, czy C#, bo s�
modne, natomiast C++ znaj� tylko w takim stopniu, w jakim u�ywa si� go na
zaj�ciach na uczelni, to rzeczywi�cie szybciej, taniej i �atwiej w
utrzymaniu b�dzie z Jav�/C#.
Maciej Sobczak
> Tak tylko ile jest ogloszen o prace dla Javy, C# a ile dla C++.
Ciekawy zwrot w dyskusji. W poprzednim poście twierdziłeś, że są
poważne powody dla których odchodzi się od wielodziedziczenia a w tym
powołujesz się na jakieś uproszczone obserwacje ilościowe. Coś typu "a
u Was biją Murzynów".
Obserwacje są uproszczone, bo nie uwzględniają profilu ogłoszeń ani
tym bardziej oczekiwań odbiorców. Tu nikogo nie obchodzi, ile gdzieś
tam jest ogłoszeń. Ważne jest to, ile jest *ciekawych* ogłoszeń - a
ponieważ to jest mocno subiektywne, to też ocena rynku będzie
zróżnicowana.
> Taki super kod z wielodziedziczeniem, szablonami itp potem w
> utrzymaniu jest cholernie drogi.
Nikt Ci nie każe go pisać gdy nie ma takiej potrzeby.
Natomiast nie chciałbym utrzymywać kodu, który został napisany bez
takiej możliwości podczas gdy taka potrzeba była.
> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Skąd to wiadomo? Ktoś to mierzył w jakiś wiarygodny sposób?
Bo widzisz - akurat jestem jednym z bardzo niewielu ludzi, którzy z
racji obsługiwanej działki piszą *dokładnie to samo* w dwóch językach.
Równocześnie. Nie żadne pseudo-porównania typu "pisałem coś na
studiach w C++ a 10 lat później coś zupełnie innego zupełnie gdzie
indziej w Javie" (to są typowe zeznania ludzi, którzy twierdzą, że w
Javie jest lepiej), tylko to samo i równocześnie. I nie widzę twardych
danych na potwierdzenie teorii jakoby cokolwiek było tańsze w Javie -
ani tworzenie [*], ani pielęgnacja. Oczywiście są drobne różnice w
obie strony w różnych aspektach, ale ogólnych i jasnych trendów na
korzyść Javy nie widzę.
Oczywiście w zespole, gdzie ludzie umieją tylko Javę i w ogóle nie
mają pojęcia o C++ faktycznie szybciej będzie coś zrobić w Javie. Tego
jednak nie liczę.
[*] Pod pojęciem "tworzenie" rozumiem nie tylko posklejanie czego
popadnie, ale doprowadzenie projektu do uruchomienia i utrzymanie go w
operacji przez jakiś czas. Zdumiewające, jak bardzo ten drobiazg
podnosi poprzeczkę.
Paweł Kierski
> Tak tylko ile jest ogloszen o prace dla Javy, C# a ile dla C++.
> Odchodzi sie w firmach od C++. W Polsce jeszcze nie tak bardzo ale na
> zachodzie juz bardzo.
Tak samo niczym nie poparta obserwacja, jak twoja: "dostatecznym"[*]
programistą Javy być łatwiej niż "dostatecznym" programistą C++ - wyższy
próg wejścia dla C++ jest naturalnym progiem selekcyjnym. Dzięki temu
programistów Javy jest więcej i są tańsi, czyli na pierwszy rzut oka
tańsze będą projekty w Javie. I to nawet może się sprawdzać dla
prostych projektów. A większość projektów jest prosta.
> Taki super kod z wielodziedziczeniem, szablonami itp potem w
> utrzymaniu jest cholernie drogi.
Każdy bardziej skomplikowany projekt, w którym wielodziedziczenie
zaczyna być koniecznością z natury rzeczy jest droższy. Bo np. wymaga
ludzi, którzy nie pogubią się w przypadku wielodziedziczenia, choć
zastosują je tylko tam, gdzie to konieczne. Czy wybiorą Javę, czy C++
to już marginalna sprawa. "Dostateczny" programista C++ szybciej
zostanie "dostatecznym" programistą Javy niż odwrotnie.
> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Patrz wyżej.
[*] "Dostateczny" to taki, który wystarczy w ocenie pracodawcy do
pociągnięcia danego projektu.
--
Paweł Kierski
ne...@pkierski.net
Seweryn Habdank-Wojewódzki
> Tak tylko ile jest ogloszen o prace dla Javy, C# a ile dla C++.
A co to ma do faktu, ze Java jest slabo spojna z UML?
> Odchodzi sie w firmach od C++.
E to chyba w projektach, ktore nie maja np. certyfikatow
bezbieczenstwa.
> W Polsce jeszcze nie tak bardzo ale na
> zachodzie juz bardzo.
Wiesz, na zachodzie wyprodukowano prezentacje
gdzie jeden facio mowil ze jafka-kawka zastapi 1000 PLC.
Klopot polega na tym, ze rynek PLC od tego
czasu nie zmalal, a PLC programuje sie troche tylko
wygodniej niz skrobanie w ASM. Tak wiec jesli PLC
trzymaja sie dobrze, spodziewam sie, ze C/C++ beda
sie mialy dobrze jeszcze troche.
Poza tym wiele ludzi przekonalo sie, ze olbrzymia
zawartosc "ceny" projektu jest skupiona w bledach
projektowych, skalowania, rozpraszalnosci oraz w
np. "glupkowatym" klopocie ze watki na 1-core dzialaly
inaczej niz na >2 oraz, ze np. karty sieciowe leja na
priorytety watkow itd. W tych problemach ani Java ani C#
nie daja zadnej poprawy wzgledem C++.
Tak wiec chyba, zyjemy w innych swiatach.
> Taki super kod z wielodziedziczeniem, szablonami itp potem w
> utrzymaniu jest cholernie drogi.
Eee... a jaki kod nie jest drogi w utrzymaniu?
> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu.
Co tez ty nie powiesz. Jakies konkrety?
> A takze w samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Tak. GUI i krotkie projekty. Projekty zaawansowane laczace w
sobie wiele interfejsow (w znaczeniu wejsc/wyjsc urzytkownika)
pisze sie tak samo wolno.
Kiedys zrobilem badania i jakos Java nie dawala gwarancji lepszego
time to market - o ile nie uzyto generator kodu, ktore same z siebie
wysoce utrzwniaja *utrzymanie* kodu, np. banalny problem przenoszenia
aplikacji GUI z Netbeans do Eclipse i spowrotem nie jest rozwiazywalne
na poziomie Javy i jesli chcesz kod utzrymywac to uzywajac jednego
generatora jetes do niego przykuty na dlugo.
Pozdrawiam,
--
|\/\/| Seweryn Habdank-Wojewódzki
\/\/
Professionalism in programming - www.accu.org
Seweryn Habdank-Wojewódzki
> A praktyka pokazuje ze programista nie jest Bogiem. Jest omylny. I
> tworzac coraz wieksze projekty potrzebujemy coraz bezpieczneijszych
> jezykow.
Hmm... to czemu Java nie jest uzywana w systemach gdzie oczekuje
sie certyfikatow bezpieczenstwa np. DO-178?
Jest wiele definicji bezpieczenstwa i wiele drog do uzyskania tych
wielu
bezpieczenstw. Wyjezdzanie iteratorem za granice kontenera, to jest
kompletnie przedszkolny problem. Nie przedszkolne problemy NIE
sa rozwiazane w jezykach bezpiecznych, bo nikt by ich nie uzyl
w czystej formie.
> Mase firm woli poswiecic 10-20% wydajnosci kosztem 50% wiekszej
> produktywnosci.
> DLa ciekawosci. Poszukaj prezentacji:
> "The Next Mainstream Programming Language:
> A Game Developer s Perspective"
Tak. Na rynku gier to jest kluczowa sprawa, kiedy gra istnieje rok
moze
2 na rynku. To nie ma zadnego znaczenia wydajnosc. Ale jesli piszesz
soft na 10 lat to co? To 20% (a moze nawet 200%) wydajnosci jest w
cenie w stosunku do 50% produktywnosci. Skrobniecie procedurki
uzywajacej SSE dajacej np. 150% szybkosci, zwroci sie z nawiazka
nawet jesli zaplacisz za nia 1 p*m.
> Tam jest koncept nowego jezyka programowania jeszcze bezpieczniejszego
> niz Java. Ktory ma sie dobrze spisac w duzych projekach a glownie w
> grach oraz aplikacjach wykonujacych sporo obliczen.
He? Gdzie tam jest mowa o bazach danych czy rozproszeniu obliczen?
Jakos dwa pozostale istotne np. w cloud computing aspekty w tej
prezentacji
nie pojawily sie.
Seweryn Habdank-Wojewódzki
> Twoje 300% to sa dane z czapki.
Ty chyba nie wiesz o jakich optymalizacjach
mowa. Mamy tu na grupie kilku specow, ktorzy
po 10-20% przyspieszenia to sie nie schylaja,
bo oni uzywajac dobrego projektu + dedykowanych
procedurek wyciskaja setki procent.
Ciekawe np. jest przyspieszenie kiedy do obrazkow
uzyjesz IPP intela. Tam nie ma nic poza tym, ze
procedurki uzywaja SSE. Przyspieszenia obliczen
sa duze.
> Nawet wszedzie sie ogolnie przyjmuje 10-20%.
Wszedzie to znaczy w produkcji gier?
Jędrzej Dudkiewicz
> Witam,
>
>> Twoje 300% to sa dane z czapki.
>
> Ty chyba nie wiesz o jakich optymalizacjach
> mowa. Mamy tu na grupie kilku specow, ktorzy
> po 10-20% przyspieszenia to sie nie schylaja,
> bo oni uzywajac dobrego projektu + dedykowanych
> procedurek wyciskaja setki procent.
> Ciekawe np. jest przyspieszenie kiedy do obrazkow
> uzyjesz IPP intela. Tam nie ma nic poza tym, ze
> procedurki uzywaja SSE. Przyspieszenia obliczen
> sa duze.
>
>> Nawet wszedzie sie ogolnie przyjmuje 10-20%.
>
> Wszedzie to znaczy w produkcji gier?
O ile wiem, to gry akurat pisze się właśnie w C++, żeby używać tych
wszystkich SSE i pochodnych.
JD
Karol Z.
> Witam,
>
> Korzystaj�c z okazji i odrobiny wolnego czasu, chcia�em sobie troszk�
> pokodowac w okresie �wi�tecznym. Wyb�r pad� na programowanie kom�rek.
>
> Ma kto� jakie� do�wiadczenia, porady How To Start?
>
> Wyb�r pad� na telefon mojej dziewczyny. iPhona. Ale podobno iPhone SDK
> jest dost�pne tylko pod Mac'a. Zniech�ci�o mnie to. Nie mniej ni�
> dziwaczna sk�adnia Objective C. IMHO jest beznadziejna.
>
> To mo�e Symbian? M�j telefon ma QIU kt�re podobno nie jest ju�
> wspierane.
>
> To mo�e BlackBerry? Ale tam jest podobno wszystko w Javie. A ja Javy
> nie ten tego.
>
> Ponadto jest strasznie du�o �rodowisk, platform... troszk� si�
> pogubi�em.
>
> Je�eli si� nie b�d� potrafi� zdecydowa�, to co� mi si� zdaje, �e po
> prostu powt�rz� sobie wybrane zagadnienia z Algorytmiki. Wiedza
> wolniej si� starzeje, jest o wiele bardziej przeno�na i nie zale�y od
> platformy ;O)
>
> Lukasz
Hej,
Si� troch� zapl�ta�e�. :)
Dlaczego nie Java? Wiesz, mo�na wszystko tworzy� od pocz�tku, mo�esz
wykorzysta� co� co ju� dziala by tworzy� wydajne programy. Narz�dzie nie
ma tu nic do rzeczy.
Lubisz czy nie lubisz, liczy si� to, czy potrafisz programowa�. A �e
wi�kszo�� telefon�w korzysta z Javy, mniej tel. korzysta z Symbiana czy
WinMobile... mo�na si� uczy� niszowego j�zyka, tylko po co? Dla samej idei?
K.
mgk
wpiszcie C++ jobs, Java jobs i C# jobs i zobaczycie ze C++ daleko w
tyle.
Nie mam sily gadac z tak upartymi ludzmi.
A co do tego co mowie to nie sa zadne moje wymysly tylko rzeczy ktore
sie czyta w ksiazkach, mowi na konferencjach, uczy w uczelniach, itp.
I wszedzie mowia o koncu C++.
Seweryn Habdank-Wojewódzki
> >> Nawet wszedzie sie ogolnie przyjmuje 10-20%.
>
> > Wszedzie to znaczy w produkcji gier?
>
> O ile wiem, to gry akurat pisze się właśnie w C++, żeby używać tych
> wszystkich SSE i pochodnych.
No wiec dedykowane procedurki uzywajace SSE daja zazwyczaj
wiecej niz 30% przyspieszenia wzgledem jakiegos kawa-kodu.
Seweryn Habdank-Wojewódzki
> Jak nie wierzycie to wejdzcie sobie na portale o prace np w angli i
> wpiszcie C++ jobs, Java jobs i C# jobs i zobaczycie ze C++ daleko w
> tyle.
Anglia nie jest calym swiatem.
Prace na "jobs" nie sa jedynymi - moja aktualna posada nie byla
reklamowana na zadnym "jobs".
Poza tym oferty pracy maja sie nijak do jakosci jezyka i jego cech OO.
Tak na marginesie poslugujac sie Twoja logiko-statystyka nie warto
uczyc sie np. Linuxa, nie warto programowac dla tego systemu,
bo "gazety" mowia, ze caly swiat uzywa Windowsow.
Teraz zrob rozumowanie abstrakcyjne - wyobraz sobie, ze nie ma
zadnego Linuxa - pomysl jaki koszt wygenerowany zostanie,
aby posprzatac balagan po eliminacji Linuxa na rzecz Windowsa.
Tak wiec srednio MASZ racje - Java-rulez. Ale juz wielokrotnie
podkreslalismy, ze C++ zajmuje tyle niszy, ze jeszcze troche
bedzie sie w nim pisalo.
Poczytaj sobie moj i dalsze posty:
http://groups.google.at/group/pl.comp.lang.c/msg/af35955afe983be3
> Nie mam sily gadac z tak upartymi ludzmi.
Jestesmy uparci do bolu, bo wiemy co mowimy.
> A co do tego co mowie to nie sa zadne moje wymysly tylko rzeczy ktore
> sie czyta w ksiazkach, mowi na konferencjach, uczy w uczelniach, itp.
Czego sie uczy na uczelniach? Futurologii? Ze Java wyprze C++?
Na dobrych uczelniach uczy sie tez Lispa, Prologa i innych, wiec
C++ nie jest zadnym kuriozum. Co wiecej wiele uczelni widzi,
ze uczenie Javy jako jezyka wiodacego powoduje produkcje
uposledzonych inzynierow, ktorzy kompletnie nie widza REALNYCH
problemow w prawdziwym programowaniu.
> I wszedzie mowia o koncu C++.
Widzisz to jest tak. Jesli wszyscy w to uwierza, to faktycznie C++
sie skonczy, bo wszyscy padna u stop Jafki.
Ale jesli nikt w to nie uwierzy, to nic sie takiego nie stanie.
Tak jak pisalem Java na kilka cennych cech, ale nie przenosmy jej
walorow na cale programowanie.
Wojciech Jaczewski
W ksi��ce, to ja kiedy� wyczyta�em wywody o tym, jak to m.in. obecne systemy
operacyjne wyjd� z u�ytku, bo oto mamy Jav� i w niej wszystko b�dzie...
Ksi��ka by�a - rzecz jasna - o Javie. Tytu�u nie pami�tam; nie wiem tak�e z
kt�rego by�a roku - raczej przed 2000.
Tomasz Krzos
> I wszedzie mowia o koncu C++.
O smierci C++ mowi sie od dawna i jakos nadal zyje. Odnosze jednak
wrazenie, ze ofert pracy w charakterze programisty C++ jest coraz mniej.
Jestem tez zdania, ze szybciej realizuje sie projekty pisane w jezykach
o wyzszym poziomie abstrakcji(np. w Javie czy C#) - latwiej tez taki
projekt utrzymac.
Nie zmienia to jednak faktu, ze C i C++ sa jezykami, ktore nie odejda z
dnia na dzien. Jest kilka nisz, w ktorych C++ sprawdza sie calkiem
niezle. Poza tym, jest troche starych projektow, ktore zostaly napisane
w C++ i beda dalej rozwijane w tym jezyku bo nie oplaca sie ich przepisywac.
Mozemy wiec mowic o koncu C++, ale ten koniec predko nie nastapi. Moze
jeszcze tak byc, ze C++0x przyczyni sie do wzrostu popularnosci tego
jezyka - troche w to watpie, ale kto wie...
--
Tomasz Krzos
http://tkrzos.com/
Wojciech Jaczewski
> Jestem tez zdania, ze szybciej realizuje sie projekty pisane w jezykach
> o wyzszym poziomie abstrakcji(np. w Javie czy C#)
C# nie znam zupe�nie, ale w czym przejawia si� ten wy�szy poziom abstrakcji
w Javie, bo jakoďż˝ nie mogďż˝ go dostrzec?
Paweł Kierski
Szczerze m�wi�c, to dla mnie bardziej abstrakcyjnym jest c++'owy int
(bez okre�lonego �ci�le rozmiaru, reprezentuje liczb� ca�kowit� ze
znakiem) niďż˝ jego javowy odpowiednik (32 bitowy int z reprezentacjďż˝
U2). Cho� akurat z in�ynierskiego punktu widzenia nie zawsze wi�ksza
abstrakcja jest korzystna 8-)
Powa�niej - mo�liwo�ci wyra�ania C++ wydaje si� mie� nieco wi�ksze
(brak const w Javie jest dla mnie du�ym minusem). Semantyki warto�ci
(C++) i referencji (z wyj�tkiem typ�w prostych w Javie) s� r�wnowa�ne
(da si� wyrazi� jedn� za pomoc� drugiej). Ale abstrakcja w og�lno�ci -
ta sama.
--
Paweďż˝ Kierski
ne...@pkierski.net
mgk
Ja mowie, ze ten sam program szybciej sie napisze w Javie niz w C++.
Duzo ciezej o bledy w Javie, a jak juz sa to latwo sie je znajduje.
W C++ jak byl blad pamieci ktory byl gdzie indziej, a objawial sie
gdzie indziej to sie go szukalo czasem i pare dni. A w Javie takie cos
nie istnieje.
Ciekawe ze mase osob ktorzy fuck-aja na jave pisali w javie nie wiecej
niz parenascie godzin w zyciu:) Tyle ze kazdy kogo znam (lacznie ze
mna) kto pisal ponad 1000 godzin w obu jezykach woli Jave. Na poczatku
w Javie sie pisze wolniej, ale potem sie docenia o ile szybciej
powstaja w niej duze projekty niz w C++. O ile latwiej zapanowac nad
kodem.
narazie.
dla mnie koniec. mam dosc tej dyskusji.
mgk
Oczywiscie ze w obu jezykach mam kilkadziesiat tysiecy godzin
spedzonych i nie tylko w nich. 1000 to byl taki dolny limit po jakim
wogole mozna sie wypowiadac na temat danego jezyka.
Sebastian Kaliszewski
> Tak tylko ile jest ogloszen o prace dla Javy, C# a ile dla C++.
Non sequitor.
> Odchodzi sie w firmach od C++. W Polsce jeszcze nie tak bardzo ale na
> zachodzie juz bardzo.
I co z tego? Zamieniają jeden nienowoczesny język na inny.
> Taki super kod z wielodziedziczeniem, szablonami itp potem w
> utrzymaniu jest cholernie drogi.
> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
Znam parę języków w których się to robi jeszcze szybciej i jeszcze
taniej (jeśli akurat te cechy są pożądane). A te języki jakoś, cholera
mają normalne wielodziedziczenie...
Sebastian Kaliszewski
> Alescie sie uparli na ta abstrakcje. A czy ja o tym mowie?
>
> Ja mowie, ze ten sam program szybciej sie napisze w Javie niz w C++.
> Duzo ciezej o bledy w Javie, a jak juz sa to latwo sie je znajduje.
> W C++ jak byl blad pamieci ktory byl gdzie indziej, a objawial sie
> gdzie indziej to sie go szukalo czasem i pare dni. A w Javie takie cos
> nie istnieje.
>
> Ciekawe ze mase osob ktorzy fuck-aja na jave pisali w javie nie wiecej
> niz parenascie godzin w zyciu:) Tyle ze kazdy kogo znam (lacznie ze
> mna) kto pisal ponad 1000 godzin w obu jezykach woli Jave.
Mamy tu na grupie kontrprzykład :)
BTW, co to jest 1000 godzin? 1000 godzin to jest doświadczenie beginera
po pół roku pracy. Mało warte. Bardzo mało.
> Na poczatku
> w Javie sie pisze wolniej, ale potem sie docenia o ile szybciej
> powstaja w niej duze projekty niz w C++. O ile latwiej zapanowac nad
> kodem.
>
> narazie.
> dla mnie koniec. mam dosc tej dyskusji.
Czyli nie masz kontrargumentów :)
pzdr
Seweryn Habdank-Wojewódzki
> Ja mowie, ze ten sam program szybciej sie napisze w Javie niz w C++.
Bzdura!!!
Wez sobie poczytaj o pisaniu prawdziwych projektow, a nie softu na rok
czy 2. Programy pisze sie niezaleznie od jezyka z predkoscia od
300-2000 linii na osobo miesiac. Zaleznosc nie polega na uzytym
jezyku,
ale na trudnosci projektu + przyspieszenie spowodowane uzyciem
generatorow kodu.
Java daje speed up TYLKO kiedy piszesz prymitywne GUI.
Zaawansowane GUI i tak wymaga przebicia sie przez roznorakie
frameworki + biblioteki.
Soft serwerowy piszesz tak samo wolno.
Soft embedded piszesz rowniez wolno.
Tak na marginesie. Java powoduje ze koderzy chca wszystko klepac
w Javie i w wielu miejscach to jest kula u nogi. Koderzy C/C++ sa
przyzwyczajeni do ciezkiego zycia i uzycie dodatkowego jezyka
nie jest zazwyczaj problemem. Tak wiec wielkie projekty pisze sie
w kilku jezykach. W szczegolnosci Twoje hobby - gry - pisze sie np.
jadro w C/C++ oskryptowywujac w Lua, ktore to polaczenie jest
banalne. W ACCU mielismy publikacyjke i calosc to jeden include
+ klasa (RAII) dla startu i stopu interpretera Lua. I nagle kamienny
C/C++ wykonuje skrypty, ktore moga powstac w czasie rzeczywistym.
Kiedy masz, watki, procesy, security, komumikacje sieciowa,
matematyke, dostep do sprzetu lub wymagania RT. Nie ma
ZADNEGO przyspieszenia w Javie! Natomiast moze byc
opoznienie, kiedzy niedouczeni kawa-koderzy np. leja na model
pamieci, czy synchronizacje na maszynach wielo procesorowych
wielo rdzeniowych - tak to jest wtedy kompletna porazka.
Ale zazwyczaj to nie wina jezyka, tylko idiotycznego przyzwyczajenia
ze JVM wszystko za kodera odwali - nawet myslenie.
> Duzo ciezej o bledy w Javie, a jak juz sa to latwo sie je znajduje.
O tak. To prawda. Szczegolnie latwiej szuka sie race-conditions czy
dead-locks.
> W C++ jak byl blad pamieci ktory byl gdzie indziej
To bylo w C. W C++ w ciagu ostatnich 4 lat nie mialem bledu pamieci
oprocz tych ktore powstawaly na styku C i C++ przy reinterpret_cast,
np. podczas uzywania WinAPI.
>, a objawial sie gdzie indziej to sie go szukalo czasem i pare dni.
Jak sie pisze kiepski kod to tak jest.
> A w Javie takie cos nie istnieje.
Jak zawolasz funkcje WinAPI z Javy?
> Ciekawe ze mase osob ktorzy fuck-aja na jave pisali w javie nie wiecej
> niz parenascie godzin w zyciu:)
Ja pisalem 2 lata i nadal hobbistycznie skrobie male utilki GUI.
Oprogramowanie serwerowe, ktore pisalem ala C++ kladlo sie
na duperelach takich jak dostep do dedykowanych funkcji systemowych
i wielu innych rzeczach, ktore byly albo proste albo tak samo trudne w
C++.
> Tyle ze kazdy kogo znam (lacznie ze
> mna) kto pisal ponad 1000 godzin w obu jezykach woli Jave.
Moje 2 lata to wiecej niz 1000 godzin. Ale masz pecha ja nie jetem
klepaczem GUI. Dla mnie aplikacja musi miec interfejs konsolkowy
i musi miec sensowne API sieciowe. A to pisze sie tak samo wolno
w J jak i w C++.
> Na poczatku
> w Javie sie pisze wolniej, ale potem sie docenia o ile szybciej
> powstaja w niej
srednie i male projekty o krotkim horyzoncie utrzynania.
> duze
Co to jest duzy projekt?
Jaki wplyw na "duzy" ma slowo "skomplikowany".
> projekty niz w C++. O ile latwiej zapanowac nad
> kodem.
Zapanowanie nad kodem, to jest kwestia projektu,
a nie jezyka. Polecam studium WTF i esseje,
jak w Javie rowniez mozna wszystko zepsuc.
> dla mnie koniec. mam dosc tej dyskusji.
Bo jalowo bronisz Javy, wskazujac na swoje waskie
okno.
Pozdrawiam,
Seweryn Habdank-Wojewodzki.
Jędrzej Dudkiewicz
> mgk wrote:
>> Taki super kod z wielodziedziczeniem, szablonami itp potem w
>> utrzymaniu jest cholernie drogi.
>> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
>> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
>
> Znam parę języków w których się to robi jeszcze szybciej i jeszcze
> taniej (jeśli akurat te cechy są pożądane). A te języki jakoś, cholera
> mają normalne wielodziedziczenie...
Mógłbyś te boskie języki nazwać?
JD
mgk
Mam, tyle ze to nie ma sensu, szkoda zycia by dyskutowac wiele godzin
w dyskusji w ktorej i tak strony nie zmienia przekonan.
Zycie nie polega by sie klucic.
Gdyby to jeszcze bylo konstruktywne i uczylo cos obie strony, a to
jest tylko swieta wojna.
Jak wam sprawia to przyjemnosc to sie kluccie dalej. Duzo jest osob na
tej grupie ktorzy uwielbiaja i wrecz zachecaja do flamow (chociazby
cytat z tej dyskusji "jest jeszcze szansa na flame przedswiateczny") -
jak ktos tak podchodzi do dyskusji jako wymiane ognia to zal takiego
tylko...
Seweryn Habdank-Wojewódzki
> Mam, tyle ze to nie ma sensu, szkoda zycia by dyskutowac wiele godzin
> w dyskusji w ktorej i tak strony nie zmienia przekonan.
No wlasnie. Ta relacja jest zwrotna - Ty nie chcesz zmienic
przekonan :-D.
> Zycie nie polega by sie klucic.
Nie. Ale dyskusja w ktorej rozne punkty widzenia sa zestawione jest
cenna.
> Gdyby to jeszcze bylo konstruktywne i uczylo cos obie strony, a to
> jest tylko swieta wojna.
Nie. To jest jawny klopot w Twoim postrzeganiem rzeczywistosci
biznesowej :-).
Przeczytaj np. watek: http://groups.google.at/group/pl.comp.lang.c/msg/c8b15621f7e10807
od tego postu w dol.
Nad takimi rzeczami jak opisany false sharing w Javie masz slaba
kontrole
w C++ nie ma sprawy. A to sa wlasnie realne problemy w wydajnosci
aplikacji
pisanych przez niedouczonych koderow.
> jak ktos tak podchodzi do dyskusji jako wymiane ognia to zal takiego
> tylko...
Nie. To chodzi o walory edukacyjne owego flame. W swiecie Java wszyscy
sie
zgadzaja i zawsze JVM oferuje jedyne sluszne rozwiazanie - nawet jest
jest do bani
to nie ma dyskusji, bo sam nie napizesz JVM. W C++ tak nie jest i
wiele rozwiazan
daje rozne efekty np. w wydajnosci.
Co wiecej w obrebie wielu flame padaly bardzo konkretne rozwiazania i
odpowiedzi
na postawione zarzuty/argumenty.
Moze sie jeszcze czegos nauczysz w zyciu. W kazdym razie proponuje
zdjac
rozowe okulary i popatrzec na wiele realnych problemow w
programowaniu,
a nie na problemy 5 osobowego zespolu piszacego aplikacje w Javie,
ktora bedzie utzymywana przez rok moze 2.
BTW - czy refaktoryzowales kod Java z wersji 1.3 na 5.0 (6.0)?
Nie mowie o uruchamianiu mowie o zmiania uzywanego API.
Sebastian Kaliszewski
Popularne języki skryptowe. W końcu do tego je zrobiono, że jeśli coś
chcemy mieć szybko i tanio napisane (czyli jeśli akurat te cechy są
pożądane) to zrobimy to z ich pomocą. Jeśli dochodzą inne wymagania, np.
że kod ma być dobrze utrzymywalny, długo rozwijany, itd to jest to już
mniej oczywiste -- ale tyczy się to tak samo Javy jak i języków
skryptowych jak wszelkich innych. Tu trzeba się już lepiej zastanowić by
wybrać właściwe narzędzie -- czasem najlepsza będzie faktycznie Java,
czasem któryś konkretny język skryptowy, czasem C#, czasem C++ a czasem
coś zupełnie ale to zupełnie innego (np. Prolog).
pzdr
Jędrzej Dudkiewicz
> Jędrzej Dudkiewicz wrote:
>> Sebastian Kaliszewski pisze:
>>> mgk wrote:
>>>> Taki super kod z wielodziedziczeniem, szablonami itp potem w
>>>> utrzymaniu jest cholernie drogi.
>>>> Kod w Javie czy C# jest tanszy w pielegnacji, utrzymaniu. A takze w
>>>> samym tworzeniu aplikacji - robi sie je szybciej i taniej.
>>>
>>> Znam parę języków w których się to robi jeszcze szybciej i jeszcze
>>> taniej (jeśli akurat te cechy są pożądane). A te języki jakoś,
>>> cholera mają normalne wielodziedziczenie...
>>
>> Mógłbyś te boskie języki nazwać?
>
> Popularne języki skryptowe. W końcu do tego je zrobiono, że jeśli coś
> chcemy mieć szybko i tanio napisane (czyli jeśli akurat te cechy są
> pożądane) to zrobimy to z ich pomocą.
Hm, chyba zadałem w złym miejscu pytanie. Pisałeś w paru innych
miejscach o tym, że są "lepsze nowoczesne" języki - bardziej chodziło mi
o nie :) Znaczy, pisałeś o nich w kontekście "Java, C# i inne nowoczesne
języki odchodzą od wielodziedziczenia".
JD
Sebastian Kaliszewski
To nie ja coś takiego pisałem. Ja pisałem że "nowoczesność" Javy i C#
jest dyskusyjna
Jędrzej Dudkiewicz
> Jędrzej Dudkiewicz wrote:
>> Hm, chyba zadałem w złym miejscu pytanie. Pisałeś w paru innych
>> miejscach o tym, że są "lepsze nowoczesne" języki - bardziej chodziło
>> mi o nie :) Znaczy, pisałeś o nich w kontekście "Java, C# i inne
>> nowoczesne języki odchodzą od wielodziedziczenia".
>
> To nie ja coś takiego pisałem. Ja pisałem że "nowoczesność" Javy i C#
> jest dyskusyjna
Tak, ale napisałeś też, żeby 'mgk' poczytał, jak ten problem
"rozwiązują, a nie omijają języki rzeczywiście nowoczesne" - chodzi mi o
to, które to są te "rzeczywiście nowoczesne" języki i czy zrobiłeś coś w
nich (albo wiesz o czymś dużym, co zostało w nich zrobione), czy tylko
są nowoczesne. Najnowszy język jaki kojarzę to ten od Google'a, a inne
mają po najmarniej 10 lat.
JD
Sebastian Kaliszewski
Akurat "nowoczesność" tego od Googla też jest kontestowana :)
http://monoc.mo.funpic.de/go-rant/
Co do samych języków "rzeczywiście nowoczesnych" to pomijając całą
stajnię deklaratywną o której wszyscy mówią a nikt nie używa, to
rzeczywiście nowoczesne będą choćby Python >2.2, Ruby czy Scala (czyli
zarówno z rodziny dynamicznie jak i statycznie typowanej).
pzdr
Maciej Sobczak
<s.bez_sp...@remove.this.informa.and.that.pl> wrote:
> Co do samych języków "rzeczywiście nowoczesnych" to pomijając całą
> stajnię deklaratywną o której wszyscy mówią a nikt nie używa, to
> rzeczywiście nowoczesne będą choćby Python >2.2, Ruby czy Scala
Na jakiej podstawie twierdzisz, że są "rzeczywiście nowoczesne"?
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
mgk
Ostatnio odpalalem kilka starszych aplikacja.
Jedna nie dziala na 64bit. Inna nie dziala na Viscie. Jeszcze inna nie
wiadomo czemu.
Masakra.
Mysle sobie. Jakby dolicha napisane byly w Javie to by nie bylo
problemu.
Aplikacje ktora jest w Javie odpalam sobie na roznych Windowsach, na
Linuxie, moge odpalic ja na MacOS i wszedzie dziala.
eh...
Maciej Sobczak
> Ostatnio odpalalem kilka starszych aplikacja.
> Jedna nie dziala na 64bit. Inna nie dziala na Viscie. Jeszcze inna nie
> wiadomo czemu.
> Masakra.
>
> Mysle sobie. Jakby dolicha napisane byly w Javie to by nie bylo
> problemu.
A ja mam programik w Javie, który działa na 32-bitowym Linuksie,
natomiast nie działa na 64-bitowej JVM na Mac OS.
Tzn. *jakiś czas* działa (pozdrawiam zwolenników JUnitów i innych
takich).
A potem nie działa.
Koledzy od Javy, gdy im to pokazałem, powiedzieli mi, że... Mac nie
jest platformą produkcyjną.
> eh...
Seweryn Habdank-Wojewódzki
> Ostatnio odpalalem kilka starszych aplikacja.
> Jedna nie dziala na 64bit. Inna nie dziala na Viscie. Jeszcze inna nie
> wiadomo czemu.
> Masakra.
Hmm... a moze byly napisane w C przy zalozeniach o arytmetyce
wskaznikow? Jak w J napiszesz tak samo soft, to zez nie bedzie
dzialal.
> Mysle sobie. Jakby dolicha napisane byly w Javie to by nie bylo
> problemu.
Bylyby inne?
Sebastian Kaliszewski
To ech... niech się jeszcze na mojej komórce uruchomi :) Na pudełu
"pisało" że ma Javę ;)
Albo, bardziej serio, uruchom soft w Javie z jednej komórki na drugiej
mgk
> wskaznikow? Jak w J napiszesz tak samo soft, to zez nie bedzie
> dzialal.
>
>
Przeciez w Javie nie ma arytmetyki wskaznikow.
Dlatego pisalem ze nie ma sensu z wami rozmawiac. Wypowiadaja sie
osoby na temat na ktory nie maja pojecia. Tu wlasnie przyklad kogos
kto nie wie ze w Javie nie ma arytmetyki wskaznikow i sie
wypowiada....
mgk
> "pisało" że ma Javę ;)
>
> Albo, bardziej serio, uruchom soft w Javie z jednej komórki na drugiej
Nie pisalem nic o komorkach. Powyzsza wypowiedz to jedynie prostacka
zaczepka trola.
I to jest kolejny przyklad poziomu tej grupy. A ktos pisal "Moze sie
jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
dyskusja. No i widac kto mial racje.
Krzysiek Kowaliczek
> Taka dygresja.
>
> Ostatnio odpalalem kilka starszych aplikacja.
> Jedna nie dziala na 64bit. Inna nie dziala na Viscie. Jeszcze inna nie
> wiadomo czemu.
> Masakra.
>
> Mysle sobie. Jakby dolicha napisane byly w Javie to by nie bylo
> problemu.
Pod koniec lat 90-tych był huraoptymizm, że wszystko, ale to wszystko
będzie pisane w Dżawie. Dlaczego tak się nie stało? ( ale pewnie i tak
nie odpowiesz na pytanie, które jest niezgodne z twoją wizją
rzeczywistości ).
Pozdrawiam
KK
Krzysiek Kowaliczek
>> Albo, bardziej serio, uruchom soft w Javie z jednej kom�rki na drugiej
>
> Nie pisalem nic o komorkach. Powyzsza wypowiedz to jedynie prostacka
> zaczepka trola.
>
Czyli D�awa jest super, ale nie na kom�rkach?
> I to jest kolejny przyklad poziomu tej grupy. A ktos pisal "Moze sie
> jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
> dyskusja. No i widac kto mial racje.
Ostatnie posty: programowanie wielow�tkowe i realne problemy zwi�zane
z "false sharing", wady i zalety GC. Rzeczywi�cie �a�osny poziom grupy.
Pozdrawiam
KK
Sebastian Kaliszewski
>> To ech... niech si� jeszcze na mojej kom�rce uruchomi :) Na pude�u
>> "pisa�o" �e ma Jav� ;)
>>
>> Albo, bardziej serio, uruchom soft w Javie z jednej kom�rki na drugiej
>
> Nie pisalem nic o komorkach. Powyzsza wypowiedz to jedynie prostacka
> zaczepka trola.
Dorze, �e si� samookre�li�e�.
> I to jest kolejny przyklad poziomu tej grupy.
ROTFL!
> A ktos pisal "Moze sie
> jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
> dyskusja. No i widac kto mial racje.
Je�li nie chcesz si� nauczy� -- a najwyra�niej nie chcesz to si� nie
nauczysz. To ju� tw�j problem, nie nasz.
Sebastian Kaliszewski
>> Hmm... a moze byly napisane w C przy zalozeniach o arytmetyce
>> wskaznikow? Jak w J napiszesz tak samo soft, to zez nie bedzie
>> dzialal.
>>
>> Bylyby inne?
>>
>
>
> Przeciez w Javie nie ma arytmetyki wskaznikow.
>
Ale są inne założenia. Dla każdego jest jasne, że chodzi o analogię.
Soft w C napisany z założniem, że sizeof(long int) == sizeof(void*) nie
zadziała na Win64bit. Soft w Javie napisany z założniem, że wielkość
liter w nazwach plików nie ma znaczenia nie przeniesie się z Windows na
*nixy, itd...
> Dlatego pisalem ze nie ma sensu z wami rozmawiac. Wypowiadaja sie
> osoby na temat na ktory nie maja pojecia. Tu wlasnie przyklad kogos
> kto nie wie ze w Javie nie ma arytmetyki wskaznikow i sie
> wypowiada....
Cóż, jakoś wydaje mi się że Seweryn wie że w Javie nie ma artymetyki
wskaźników. Widać posłużył się zbyt wysokim poziom abstrakcji dla
programisty Javy ;)
Muszę, niestety, stwierdzić, że to nie poziom grupy jest niski tylko
pewnego osobnika co tak twierdzi
mgk
Windows i na Linux.
Ja nie wiem jak mozna tego nie wiedziec.
Nie mialem tez zadnych problemow nigdy ze znakiem konca lini 10 13, a
10.
Co z tego ze 1 rzecz na 100 w Javie moze sie zdarzyc nie przenosna (mi
sie jeszcze nie zdazyla). Chyba lepiej myslec o 1 rzeczy w Javie niz o
100 rzeczach w C.
Rewelacyjna macie logike... W Javie myslenie o 1 rzeczy zamiast o 100
to zadna zaleta.... lol.
mgk
> > jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
> > dyskusja. No i widac kto mial racje.
>
> z "false sharing", wady i zalety GC. Rzeczywiście żałosny poziom grupy.
>
O poziom kultury mi chodzi !
Ale nawet takie pojecie widze jest tu obce...
sorry ale pisalem kulturalnie, ale z wami sie nie dalo kontynuowac
kulturalnej dyskusji... Co chwila tylko zlosliwe zaczepki. Zyjcie
sobie dalej w waszym swiecie.
Sebastian Kaliszewski
>> Co do samych j�zyk�w "rzeczywi�cie nowoczesnych" to pomijaj�c ca��
>> stajni� deklaratywn� o kt�rej wszyscy m�wi� a nikt nie u�ywa, to
>> rzeczywi�cie nowoczesne b�d� cho�by Python >2.2, Ruby czy Scala
>
> Na jakiej podstawie twierdzisz, �e s� "rzeczywi�cie nowoczesne"?
Na podstawie ich cech :)
Sebastian Kaliszewski
> A. Zaraz ktos zlosliwy sie czepi tego 1000 godzin.
> Oczywiscie ze w obu jezykach mam kilkadziesiat tysiecy godzin
> spedzonych i nie tylko w nich.
Policzmy. kilkadzeisiąt tysięcy to tak powyżej 20000. Na każdy 20000 +
na "nie tylko w nich" kolejne 20000. Razem 60000. Rok pracy to 2000.
Czyli min. 30 lat pracy. Jakoś nie bardzo wierzę. Do tego dołóżmy, że
żeby wypowiadać się o obu językach to trzeba mieć w obu doświadczenie
rozsądnie świeże a nie (cytuję) "jak 10 lat temu". Czyli doświadczenie
"przeplatane", sięgające 30 lat do tyłu. Tylko mały problemik: 30 (ani
20) lat temu to Javy nie było :)
Sebastian Kaliszewski
> Od lat uzywam sciezek w formacie /../ zamiast ..\..\ i dziala i na
> Windows i na Linux.
Pisałem o wielkości liter.
Widać progtramując w Dżawie treaci się umiejętność czytania ze
zrozumieniem ;)
BTW. są systemy operacyjne gdzie nie używa się ani ../../ ani ..\..\.
> Ja nie wiem jak mozna tego nie wiedziec.
Ja nie wiem jak można
>
> Nie mialem tez zadnych problemow nigdy ze znakiem konca lini 10 13, a
> 10.
>
> Co z tego ze 1 rzecz na 100 w Javie moze sie zdarzyc nie przenosna (mi
> sie jeszcze nie zdazyla). Chyba lepiej myslec o 1 rzeczy w Javie niz o
> 100 rzeczach w C.
>
> Rewelacyjna macie logike... W Javie myslenie o 1 rzeczy zamiast o 100
> to zadna zaleta.... lol.
Niech, dziecko. W Javie też myśli się o 100 rzeczach, tylko inne to są
zwykle rzeczy.
Sebastian Kaliszewski
>>> I to jest kolejny przyklad poziomu tej grupy. A ktos pisal "Moze sie
>>> jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
>>> dyskusja. No i widac kto mial racje.
>>
>
> O poziom kultury mi chodzi !
> Ale nawet takie pojecie widze jest tu obce...
>
> sorry ale pisalem kulturalnie, ale z wami sie nie dalo kontynuowac
> kulturalnej dyskusji... Co chwila tylko zlosliwe zaczepki.
ROTFL!
Oto pierwsza z�o�liwa zaczepka w tym w�tku...
"Musisz wrocic na studia, albo poczytac troche ksiazek. Brakuje Ci
wiedzy np na temat dlaczego w nowoczesnych jezykach odchodzi sie od
wielodziedziczenia. Ani Java ani C# go nie maja. I maja po temu
powody."
Zgadnij czyj to tekst :)
Kolego, zanim b�dziesz kogo� odsy�a� na studia i kontynuowa� popisywanie
si� wiedz� "in�yniersk�" (o nowoczesnych j�zykach) rodem z folder�w
reklamowych Suna, to poczytaj sobie np. jak rozwi�zano
wielodziedziczenie w takim j�zyku jak Dylan. Powiesz, "kto tego u�ywa?",
wyjedziesz ze statystykďż˝ ofert pracy z jakiegoďż˝ portalu w UK, itp to ci
odpowiem, �e to rozwi�zanie przej�to w j�zykach "nieco" bardziej
popularnych. O jakich j�zykach mowa pozostawiam jako zadanie domowe.
> Zyjcie
> sobie dalej w waszym swiecie.
Och, ach! Biedny, odrzucony prorok...
Na wszystkie cho�by kwazi-merytoryczne wypowierdzi (cho�by bzdurne, jak
te powszechnie przyj�te 10-20% kt�re rzadko kiedy ma pokrycie w
rzeczywisto�ci) otrzymywa�e� konkretne odpowiedzi poparte danymi i
przyk�adami. Za� teksty o "poziomie" nadaj� si� tylko do wy�miania.
BTW. Od kilku post�w opowiadasz "dla mnie koniec. mam dosc tej
dyskusji." i ci�gle dyskutujesz, w dodatku coraz "ni�ejpoziomowo"
BTW2. Java jak najbardziej ma jak najbardziej konkretne zalety. Jakbyďż˝
chciaďż˝ merytorycznie dyskutowaďż˝ a nie biďż˝ pianďż˝ to byďż˝ o nich napisaďż˝.
Seweryn Habdank-Wojewódzki
> Przeciez w Javie nie ma arytmetyki wskaznikow.
A opowiadales o bledach w kodzie C/C++.
> Dlatego pisalem ze nie ma sensu z wami rozmawiac. Wypowiadaja sie
> osoby na temat na ktory nie maja pojecia. Tu wlasnie przyklad kogos
> kto nie wie ze w Javie nie ma arytmetyki wskaznikow i sie
> wypowiada....
Oh ... zapomnialem, ze mowa byla o bugach w programch w C/C++.
Nic nei pisalem o wskaznikach w Javie - chociaz te sa w ukryciu.
Seweryn Habdank-Wojewódzki
> I to jest kolejny przyklad poziomu tej grupy. A ktos pisal "Moze sie
> jeszcze czegos nauczysz w zyciu" gdy napisalem ze nie ma sensu dalsza
> dyskusja. No i widac kto mial racje.
Kolego, jesli zatem Java dziala tylko na Windows i na niektrorych
Linuxach,
to przestan piac o jej wszedobylskosci i portowalnosci kodu.
Moj SW na moim DSP tez dziala nawet jesli uzywam arytmetiki wskaznikow
i calego narecza rozszerzen do C/C++.
Seweryn Habdank-Wojewódzki
> sorry ale pisalem kulturalnie, ale z wami sie nie dalo kontynuowac
> kulturalnej dyskusji... Co chwila tylko zlosliwe zaczepki. Zyjcie
> sobie dalej w waszym swiecie.
No tak w niszy C/C++, ktora nijak nie chce sie przezucic na pisanie
softu w J. Takie chamy jestesmy, ze zanamy sie na rzeczy i nie
odstepujac
swojego zdania pokazujemy bledy u innych. No poprostu chamstwo
w pelnej krasie.
Maciej Sobczak
<s.bez_sp...@remove.this.informa.and.that.pl> wrote:
> >> Co do samych języków "rzeczywiście nowoczesnych" to pomijając całą
> >> stajnię deklaratywną o której wszyscy mówią a nikt nie używa, to
> >> rzeczywiście nowoczesne będą choćby Python >2.2, Ruby czy Scala
>
> > Na jakiej podstawie twierdzisz, że są "rzeczywiście nowoczesne"?
>
> Na podstawie ich cech :)
Faktycznie, jest to dobra podstawa. :-D
Na poważnie - od 30 lat w językach programowania nic się nie dzieje i
wszystkie obecne języki to są różne kombinacje ze zbioru starych
pomysłów. Dlatego nowoczesnych języków *nie ma*.
Oczywiście chciałbym się mylić.
Sebastian Kaliszewski
> On 13 Sty, 12:17, Sebastian Kaliszewski
> <s.bez_sp...@remove.this.informa.and.that.pl> wrote:
>
>>>> stajni� deklaratywn� o kt�rej wszyscy m�wi� a nikt nie u�ywa, to
>>>> rzeczywi�cie nowoczesne b�d� cho�by Python >2.2, Ruby czy Scala
>> Na podstawie ich cech :)
>
> Faktycznie, jest to dobra podstawa. :-D
>
> wszystkie obecne j�zyki to s� r�ne kombinacje ze zbioru starych
> pomys��w. Dlatego nowoczesnych j�zyk�w *nie ma*.
> Oczywi�cie chcia�bym si� myli�.
Mam mniej ortodoksyjne stanowisko. W dziedzinie podstawowych konstrukcji
to faktycznie nie wiele siďż˝ dzieje, ale sďż˝ juďż˝ jakieďż˝ zmiany po pierwsze
w "interfejsie programisty" po drugie zaďż˝ "w opanowaniu istotnych
szczeg��w".
O tym pierwszym to mo�na flejmowa� bez ko�ca.
Z tego drugiego, to np. dobre rozwi�zanie MRO (method resolution order)
przy wielodzidziczeniu (-> Dylan a po nim co poniekt�re popularniejsze
j�zyki) to p�niejsze lata 90.