Mono Paint — w końcu konkurent GIMP-a?

Mono/Net rozwiązuje te wady w inny sposób, dlatego też jest on mniej zasobożerny.

W jaki inny? Inny lepszy niż sprzętowo – jak w Javie – o to ciekawe!

To Java rozwiązuje problemy "sprzętowo"?

Tak, w przypadku Java2D korzysta z Direct3D pod MS Windows.

Miało być DirectDraw.

3d zreszta tez(np jwlgl). Zreszta o czym my mowimy. Kto powazny robi cos w mono? Poki co raczej ciekawostka.

Tak na margineise to ze net jest wydajniejszu od javy to bzdura.

Osoby krytykujace jave rzadko maja cos madrzejszego niz cos w stylu "moj kolega uzywal javy 10 lat temu i byla wolna".

.Net było szybsze przed wyjściem Javy 1.5 (w którą dużo włożyli). 1.6 przyniosło kolejne przyspieszenie. W tej chwili nie wiem jak to jest.

> Kto powazny robi cos w mono?

Novell i Medsphere na przykład.
http://www.mono-project.com/Companies_Using_Mono#…

Przy czym moim zdaniem najważniejsze są zdania takie jak przy SplendidCRM:

" is a commercial open source product that was originally developed for Windows and .NET but now runs on SUSE Linux with Mono".

Pół roku temu też zastanawiałem się po co nam to Mono, ale teraz już nie mam wątpliwości.

> Kto powazny robi cos w mono?

Kto poważny robi coś w javie?

PS. Dla niedomyślnych: proszę nie odpowiadać.

te niepowazne firmy to ibm, oracle, redhat, sun – w koncu j2ee to bardzo niepowazne rozwiazanie

.

.net jest w miare szybki, ale jakos oratorzy jego "wolnej" implementacji (mono) zapominaja ze jest ona sporo wolniejsza niz wersja MS. .net ma ciekawe rozwiazania w bibliotece standardowej (wzgledem javy), ale to jave wybraly wielkie korporacje i tak na prawde w powaznych rozwiazaniach ms nie ma co szukac…

.

.net to taka zabawka dla "webmasterow" (popularna grupa w polsce ) – prawdziwi programisci tego czegos nawet kijem nie ruszaja :]

> tak na prawde w powaznych rozwiazaniach ms nie ma co szukac…

Zapewniam Cię że się mylisz. Medycyna to wystarczająco poważne rozwiązania? Microsoft ma się tu zdecydowanie lepiej niż Ci się wydaje.

Może dlatego, że programy kamsoftu do rozliczania się z NFZ są tylko pod windę?

Może nie zauważyłeś, że od roku możesz się rozliczać czym chcesz, nawet vi lub notatnikiem, bo opublikowano format komunikatów XML do sprawozdawczości i rozliczania. Możesz się wykazać i podarować światu hiper implementację softu do rozliczania z NFZ.

@szymon: Nie mówię o tym akurat, Karmi ma prawie rację (prawie, bo nie jest tak hop siup z tym otwartym formatem i np. w moim województwie tak naprawdę ruszy to dopiero od nowego roku). Mówię o systemach przechowujących i serwujących DICOMowe obrazki, sterujących tomografami, wielu przenośnych wspomagaczach (opartych o Pockety z Windows, programy klienckie napisane w C#), BizTalk HL7 i wiele, wiele innych.

Szybkość i zasobożerność.

Niektórzy programiści wykorzystyują w C++ unie, aby oszczędzać pamięć.

Ale po co… teraz komputery takie szybkie.

Ale jaki jest wyznacznik tej szybkości i zasobożerności? Szybkość ASM-a, C, C++?

Czy aby na pewno wiesz po co są unie i jakie jest ich zastosowanie?

PS. Może urządzimy zawody na napisanie jakiegoś work-flowa w 3 językach? ASM, C/C++, Java?

Tak jeszcze dodam.

@ultr: może uświadom Apache Foundation że brną w ślepą uliczkę (Java).

http://projects.apache.org/indexes/quick.html – większość to Java. Ba! Nawet Apache ma własną implementację Javy – Apache Harmony. Po co oni w ogóle to robią zamiast zająć się pisaniem wydajnych programów w C/C++?

ultr: programiści korzystający z unii w C++ (w przypadkach innych niż używanie interfejsów C) to idioci z nożyczkami. Należy uważać bo jak pokaleczą będzie boleć.

.

arturz: a może silnik 3D? Z resztą workflow też nie piszesz w Javie (no chyba, że piszesz — ale to błąd) a w dedykowanym środowisku do modelowania workflow. Takie środowisko możesz napisać i w Javie i w C++ (ba są takie napisane jeszcze w COBOL-u).

> arturz: a może silnik 3D?

A co za problem? Sa silniki 3D w javie i maja sie bardzo dobrze. Nie sa to moze suoper zaawansowane silniki pokroju UGINE ale ale wydajnoscia wcale nie odbieaja od odpowiednikow w c++ – jelsi juz to nieznacznie.

Jakie gry (taki normalne, nie amatorskie pierdółki) mają silnik 3D napisany w Javie? Unreal? QuakeWars? Może Wiedźmin? A może żadna?

.

Aha, ten silnik nazywa się UNIGINE.

>Jakie gry (taki normalne, nie amatorskie pierdółki) mają silnik 3D napisany w Javie? Unreal? QuakeWars? Może Wiedźmin? A może żadna?

A jak to sie ma do sprawy silnikow 3d w javie? Nijak. Bo to nie znaczy ze nie mozna i ze sie nie powinno.

Wielcy gracze z pewnoscia nie rzuca sie na jave dlatego bo od lat robia gry w c++.

Ale mali i sredni dla ktorych licza sie koszty i czas z pewnoscia sie nia zainteresuja. Wiele projektow upada wlasnie ze wgledu na koszty.

@bies: http://bytonic.de/html/jake2.html – silnik Quake II napisany w Javie – polecam podstronę Benchmarks. Wcale nie jest tak źle jak mogło by się wydawać.

Halo, grafikę na poziomie Q2 obecnie pociągną co lepsze komórki. A pecety mogą użyć raytrace'ingu.

> ultr: programiści korzystający z unii w C++ (w przypadkach innych

> niż używanie interfejsów C) to idioci z nożyczkami. Należy uważać

> bo jak pokaleczą będzie boleć.

Dlaczego unia jest zła sama przez się?

@bies: Miałem na myśli porównanie FPS-ów na podstronie Benchmarks a nie to że to działa.

@bies: A Doom chodzi na 30MHz procku, boostowanym do 80MHz z 30MB cache'a (Rockbox, SanDisk Sansa c240) :p

Bez urazy ale masz małe pojęcie o tworzeniu oprogramowania i o nim samym.

To że Visual Editor w Eclipsie jest skopany to każdy wie. Spróbuj Matisse z NetBeans o niebo lepszy i nie tnie się.

Podobnie można powiedzieć precz z Pythonem/Ruby. Porównaj czas i koszty rozwoju jakiegoś większego projektu w Javie i np. w C++.

Można sobie kupić taniego laptopa. Będzie skrzypiał, matryca będzie słaba i po jakimś czasie cały komputer popęka czy w inny sposób się zepsuje.

Można kupić droższego, który nie zaskrzypi, wytrzyma polanie wodą i upadek z kilku metrów.

Można mieć programy w Pythonie, Javie .NET i można mieć programy w "normalnych" językach.

Tylko nie rozumiem porównania oprogramowania w Javie do taniego laptopa?

Jak wytłumaczysz to że większość oprogramowania w korporacjach, firmach tworzona jest w Javie a nie C/C++?

- Tanio? Pewnie tak.

- Szybko? Tak.

- Bezpiecznie? Tak.

- Duże możliwośći w porównaniu do innych języków (jakość IDE, biblioteki itd.)? Tak.

Dla mnie odpowiedź jest jedna

arturz: pierwsza trójka to nadal Java, C, C++. Biznes (banki itp.) to rzeczywiście więcej Javy. Przemysł to więcej C/C++. Rozrywka to tylko C++.

do biznesy dochodzi jeszcze moi drodzy, fox, vb i inne super jezyki. przemysl wyznaje zasady,

po pierwsze firma kupi to co wydaje jej sie ze chce,

po drugie kupi to co w czym ja to napisze (dlatego delphi jeszcze ma takie powiedzenie)

po trzecie wazne zeby dzialalo (za wolno, wymienisie sie czesc maszyn),

po czwarte wazne zeby bylo napisane szybko

pamietajcie ze w firmach nie siedza sami informatycy a ci o czym decyduja czesto sie na niej nie znaja. (prezes nie musi sie znac na programowaniu, dlatego moze kupic soft w czymkolwiek, nawet w cobolu).

powiedzmy sobie rowniez szczerze ze czas prawdziwych programistow minal, na topie znajduje sie php, java etc .net. kiedy wystarczylo znac sprzet, miec pomysl i napisac (w wiekszosci w asemblerze , ciekowe kto go dzisiaj chce sie nauczyc) … aaa btw. przeczytalem gdzies ze C jest jezykiem niskiego poziomu, lol usmialem sie po pachy.

Tak, C jest językiem szalenie wysokiego poziomu, zupełnie abstrahuje się od sprzętu i wprowadza kupę abstrakcyjnych rozszerzeń;) Jasne.

P.S. Piszę to jako oddany fan C.

>powiedzmy sobie rowniez szczerze ze czas prawdziwych programistow minal, na topie znajduje sie php, java etc .net.

Aha, czyli jesli ktos pisze w php, javie, net etc to juz nie jest prawdziwym programista, jak ty ?

>Tak, C jest językiem szalenie wysokiego poziomu, zupełnie abstrahuje się od sprzętu i wprowadza kupę abstrakcyjnych rozszerzeń;) Jasne

Jesli c jest jeszykiem niskiego poziomu to faktycznie wystarczy spojrzec na assemblera zeby zrozumiec ze to zart .

powiedzmy sobie szczerze prawdziwi programisci to np. developerzy kernela, dzisiajesi 'hackerzy', czesc ludzi z demosceny (fox, musashi, miklesz …).

kto z tych co dzisiaj nazywaja sie programistami wiedza co to stos, sterta, rejestry procesora, ramka tcp/ip etc. wiekszosc zalatwia sam jezyk programowania.

porownalbym programistow do kompzytorow, muzykiem nie jest ten co zna trzy akordy i stworzy jakas prosta melodyjke. muzyk powinien przynajmniej wiedziec co to partytura, kontrapunkt etc. chociaz dzisiaj kazdy hip hopowiec to muzyk.

wracajac do programowania, to jak ktos wczesniej napisal, kazdy jezyk zostal stworzony do jakiegos celu, i wyskakiwanie poza ten cel jest bez sensu. programista powinien ze sprzetu wyciagnac maks co sie da, tzn. program dostosowywany jest do sprzetu a nie na odwrot. maluchem tez mozna wystartowac na f1, w koncu dojedzie celu …

ps. gdzies na necie znalazlem ogloszenie, "poszukiwany programista html …" nic dodac nic ujac.

pozdro dla wszystkich

>powiedzmy sobie szczerze prawdziwi programisci to np. developerzy kernela, dzisiajesi ‘hackerzy’, czesc ludzi z demosceny (fox, musashi, miklesz …).

Coz niekotrym techonlogia miesza sie z religia ale mozna i tak.

Programy w javie sa zamulaczami gdy sie uzywa komputera z 256 ramu sprzed 5 lat. Na dzisiejszych komputerach z 1GB RAM+ azureus nie jest zadnym zamulaczem.

A zadnej alternatywy w c/c++ dla linuxa nie ma i nie bedzie.

Poza tym, gdyby bylo tak jak mowisz nikt nie uzywalby azureusa pod windowsem, a wiele osob go uzywa.

Programy w javie sa zamulaczami gdy sie uzywa komputera z 256 ramu sprzed 5 lat. Na dzisiejszych komputerach z 1GB RAM+ azureus nie jest zadnym zamulaczem.

A zadnej alternatywy w c/c++ dla linuxa nie ma i nie bedzie.

Poza tym, gdyby bylo tak jak mowisz nikt nie uzywalby azureusa pod windowsem, a wiele osob go uzywa.

>Ale używanie .NET czy Javy do tworzenia programów codziennego użytku to chory pomysł. No bo po co ?

Wlasnie po to ze programy duzo pisze sie szybciej, duzo latwiej zarzadza sie kodem, robi sie duzo mniej bledow. I wcale nie sa duzo wolniejsze.

"Na dzisiejszych komputerach"… tak. Ulubiona wymówka na "Nie potrafię napisać porządnego programu/biblioteki". Tylko kiedy trzeba uruchomić jeszcze kilka programów, lub szerzej użyć biblioteki, wszystkie wady wychodzą na wierzch.

Przez długi czas używałem "niewspółczesnego" komputera i widziałem znaczące różnice wydajności między Qt a GTK, między Operą a Firefoksem, między Azureusem a Ktorrentem/µTorrentem pod Wine. Po co mam katować moje nowe C2D ? Ma inne rzeczy do roboty, np. Kompilowanie nowych wersji dobrze napisanych programów.

Co do popularności Azureusa… IE też ludzie przecież używają ?

>“Na dzisiejszych komputerach”… tak. Ulubiona wymówka na “Nie potrafię napisać porządnego programu/biblioteki”.

U mnie dziala dobrze i szybko. Zajmuje wiecej ramu niz cos w c++ ale mam go wystarczajaco wiec mnie to nie interesuje. Moge miec uruchomiengo azureusa, eclipse , mysql apacza firefoxa i pare innych rzeczy, i jakos nic mi nie muli.

Tak na marginesie, jak cos bierzesz w cudzyslwo czyli cytujesz, to cytuj to co ktos napisal, a nie swoja interpretacje.

>Przez długi czas używałem “niewspółczesnego” komputera i widziałem znaczące różnice wydajności między Qt a GTK, między Operą a Firefoksem, między Azureusem a Ktorrentem/µTorrentem pod Wine.

Im lepszy sprzet tym takie roznice sa procentowo mniejsze. A to ze cos dziala wolno na zakurzonym zlomie dla mnie nie jest zadnym arugemntem.

Windows 95, tez dziala szybciej niz linux z kde na komptuerze klasy 486, wiec moze powiniennes go uzywac?

>Co do popularności Azureusa… IE też ludzie przecież używają ?

Jesli ktos uzywa IE to przewaznie dlatego "bo jest" a azureusa na wlaasne zyczenie, bo jest dobry, Widzisz roznice?

@userek: "A zadnej alternatywy w c/c++ dla linuxa nie ma i nie bedzie."

Jest KTorrent – moim zdaniem bardzo dobry.

Znam co najmniej 3 dobre alternatywy dla Azeurusa, oprócz tego konsolowego rTorrenta (sam używam, idealny dla mnie), a jak ktoś woli, to nawet uTorrent zadziała.

Popieram, rTorrent — nie ma to jak podłączyć się zdalnie i w screenie ściągnąć nowy odcinek Naruto.

Nie oszukujmy sie nikt normlany nie bedzie uzywal czegos w stylu rTorrent, a kTorrentowi do azureusa to mu troche jednak brakuje. Jesli by szukac na sile to opera rowniez ma klienta torrent.

Jesli ktos uzywa torrenta do scagania jednego odcinka bajki, to faktycznie mozna sobie uzywac czegos typu rTorrent i myslec jakim to jest dzieki temu 31337 .

Hint: ,,zdalnie'', ,,screen''. Azureus już to potrafi?

>Hint: ,,zdalnie”, ,,screen”. Azureus już to potrafi?

Dzieki za uswiadomienie ale wiem co to jest screen. Co nie zmienia faktu ze nikt nie uzywa tego do normalneog sciagania, ale niektorych to dowartosciowuje w pewien sposob widac .

Czyli nie potrafi. Zatem następujący scenariusz nie przejdzie: łącze się zdalnie z pracy do domu przez ssh, puszczam ściąganie Naruto w screenie. Wracam do domu i oglądam Naruto. Nie przejdzie, zatem Azureus nie spełnia moich wymagań.

@userek

> Dzieki za uswiadomienie ale wiem co to jest screen.

> Co nie zmienia faktu ze nikt nie uzywa tego do normalneog sciagania [...]

Myślę, że wiele osób używa.

Ja również. Kiedy chcę coś wrzucić z zewnętrznego komputera, żeby mi się ściągało, to screen jest idealny.

Idąc twoim tokiem myślenia, to niedługo kalkulator będzie potrzebował 1GB ramu tylko żeby się uruchomić. Te nowe komputery są takie szybkie ehh…

jest nawet popularniejszy scenariusz. D domu mam łacze up 128 kpbs, down 512 kpbs, więc w dobrego serwera ciągne około 60kB/s, z torrenta może z 15kB/s "(zależy od prędkości uploadu, zawsze są jakieś przerwy, itp.). Na serwerze na którym posiadam konto shellowe dziele z innymi osobami symetryczne łącze 100Mbps. szybciej ściągnę coś przez torrenta na shella i np. przez ftp do siebie, niż bezpośrednio do siebie. Nie muszę też mieć tak długo włączonego komputera, nie wysyłam danych, więc dalej mi do przekroczenia limitu transferu na domowym łączu.

Nie ma się jednak co łudzić, szary kowalski i tak będzie wolał wyklikać. Narzędzie dobiera się do konkretnego celu, a nie cel do narzędzia.

Żeby skończyć mniej offtopicowo, to analogicznie jest z językami programowania. Jeśli projekt ma być stosunkowo prosty, używany przez dużą grupę osób (czyli rozwijany przez dużą liczbę programistów), a wydajność ma duże znaczenie, najlepszy będzie C/C++, jeśli projekt jest skomplikowany, ma służyć kilku osobom, a wydajność nie ma większego znaczenia, to lepiej wybrać któryś z bardziej wysokopoziomowych języków.

>Czyli nie potrafi. Zatem następujący scenariusz nie przejdzie: łącze się zdalnie z pracy do domu przez ssh, puszczam ściąganie Naruto w screenie. Wracam do domu i oglądam Naruto. Nie przejdzie, zatem Azureus nie spełnia moich wymagań.

Tylko ze to nie kwestia tego co potrafi azureus, tylko tego co umozliwa ssh i screen. Sa inne protokoly zdalnego dostepu, co nie znaczy ze lepiej ich uzywac do sciagniecia jednego pliku.

Bo został napisany w taki sposób, że korzysta z tego czego jeszcze nie było w Mono oraz przebija się bezpośrednio do Win32 API w niektórych sytuacjach. W Javie też tak można poprzez JNI (Java Native Interface). Jest cała masa aplikacji .NET, których nie trzeba przerabiać na inne platformy… Ale tak samo pewnie znajdą się aplikacje Java, które trzeba trochę przerobić żeby działały na czymś innym niż ulubiony system twórców danej aplikacji.

A do wszystkich, którzy narzekają na Java/.NET/… no cóż. W informatyce emocje się nie liczą – liczą się zyski i straty. Programy pisane w tych technologiach zazwyczaj działają trochę, albo dużo wolniej, ale zazwyczaj pisze się je trochę albo dużo dużo szybciej niż w innych i są trochę albo dużo dużo bardziej bezpieczne.

Nie bardzo rozumiem też czemu ktokolwiek miałby nie lubić Paint.NET (czy Mono Paint) tylko dlatego, że jest napisany w jakimś tam języku – bo akurat ten język jest "beee". Dla przeciętnego grafika (a chyba do takich osób jest to adresowane) takie sprawy nie powinny mieć znaczenia. Nawet lepiej żeby nie wiedział o tym, że jest coś takiej jak język programowania, platforma uruchomieniowa, JIT itd. Liczy się użyteczność i funkcjonalność – a tutaj Paint.NET ma naprawdę bardzo dużo do zaoferowania.

@houp

> Bo został napisany w taki sposób, że [...] przebija

> się bezpośrednio do Win32 API w niektórych sytuacjach.

Świetna "technologia" ten .net – nie udostępnia nawet tak podstawowych funkcji, żeby prosty edytor graficzny napisać – trzeba odwoływać się do API systemu.

Żałosne.

Nie chodzi o język a o szybkość (grafika nie obchodzi jak program to wykonuje. Filtr ma nałożyć przed przerwą na obiad i już). Z resztą się zgodzam.

@houp

> Nie bardzo rozumiem też czemu ktokolwiek miałby

> nie lubić Paint.NET (czy Mono Paint) tylko dlatego,

> że jest napisany w jakimś tam języku –

> bo akurat ten język jest “beee”.

Bo wyobraź sobie, że ten język nie jest "beee", bo jest od MS, ale podobnie jak java zaczyna być normalnością wśród developerów, choć takie podejście jest skrajnie nienormalne.

Myślałem że java będzie (i była) tymczasowym rozwiązaniem, a z punktu prawdziwego programowania raczej ciekawostką. A tu pojawia się .net, który jest wizją na kolejne lata.

Kiedy połowa waszych aplikacji to będzie java/.net, wtedy przejrzycie na oczy, jak wszystko muli i nagle wasze C2D będzie się wlokło jak P2.

Ale wszystko w imię postępu (i przenośności).

/ Sorry za podwójny komentarz, ale jestem zbulwersowany krótkowzrocznością niektórych osób /

O właśnie chciałem to napisać, ale widzę że houp mnie ubiegł. .NET i Java są po prostu łatwiejsze, szybciej pisze się aplikacje i są one bezpieczniejsze i stabilniejsze (same języki/środowiska mają w sobie mechanizmy sprzyjające takiemu pisaniu kodu, a często po prostu inaczej niż bezpiecznie się nie da).

Oczywiście nie jest to remedium na wszelkie zło. Dobry programista napisze bezpieczny program i w asemblerze. Ale zajmie mu to 100 razy więcej czasu, ciężko to będzie rozwijać i będzie zdecydowanie mniej przenośne.

Myślę, że chcemy tego czy nie — przyszłość to .NET i Java oraz języki skryptowe i języki systemowe do specyficznych zasosowań.

@ultr

> Kiedy połowa waszych aplikacji to będzie java/.net, wtedy

> przejrzycie na oczy, jak wszystko muli i nagle wasze C2D

> będziesię wlokło jak P2.

Kiedy połowa "naszych" aplikacji będzie napisana w .net to już nie będzie C2D tylko coś co ma dużo rdzeni. Akurat pojawianie się javy/.net podobnie jak rosnąca popularność języków typu python/ruby to dla mnie naturalna kolej rzeczy – tak jak przesiadka z asm na c a potem na c++. Maszyny są coraz szybsze, dzięki temu można tworzyć środowiska, które zamiast być super blisko sprzętu i wyciskać z niego co się da, są super blisko programisty i po prostu ułatwiają życie. I nie uważam, że ktokolwiek sądzi dzisiaj poważnie – z punktu widzenia biznesu czy też branży IT, że java albo .net są tylko "na chwilę". Oczywiście nie będą też nigdy "na zawsze" ale to inna sprawa.

>Świetna “technologia” ten .net – nie udostępnia nawet tak

>podstawowych funkcji, żeby prosty edytor graficzny napisać –

>trzeba odwoływać się do API systemu.

>Żałosne.

Po pierwsze jest to technologia bez "". Po drugie program o którym mówimy to nie jest prosty edytor graficzny, tylko raczej dość nieprosty. Po trzecie użycie API systemu to świadomy wybór twórców Paint.NET a nie wymaganie platformy .NET. Po czwarte mamy tu typową sytuację "coś za coś" – twórcom chodziło o to, żeby program możliwie dobrze integrował się z systemem Windows więc użyli kawałków jego API, tracąc tym samym łatwą przenośność. Gdyby stwierdzili, że robią program dla wszystkich systemów to pewnie postąpili by inaczej. Ale są wolni – tak samo jak i my – i mogą podejmować nawet głupie decyzje. Jak łatwo wywnioskować z bloga Miguela – całość odwołań do API jest w jednym oddzielnym pakiecie i właśnie to zostało przeportowane żeby było przenośne i tyle.

@uzytkownik

>Nie chodzi o język a o szybkość (grafika nie obchodzi jak

>program to wykonuje. Filtr ma nałożyć przed przerwą na obiad i

>już). Z resztą się zgodzam.

Ok. Rozumiem. Zgadzam się w 100%, że programy w .NET są z reguły wolniejsze. Ale pytanie o ile wolniejsze. Na codzień używam Photoshopa, który stanowczo nie jest napisany w .NET i jest bardzo wydajny. Próbowałem Paint.NET i w niewielkich projektach prędkość jest znośna. W dużych jest gorzej. Ale z tego co wiem GIMP, który również nie jest napisany w .NET, w przypadku dużych rozdzielczości radzi sobie raczej średnio.

Tak czy inaczej wydaje się, że podejście typu – piszemy wszystko w języku zarządzalnym (C#, Java… cokolwiek) a to co musi być super szybkie (np. wspomniane filtry) przepisujemy w C++ (albo rzucamy na GPU na przykład) – ma obecnie największy potencjał.

nie wiem jak tam z tym dot netem, ale java służy do pisania aplikacji i apletów internetowych. Używanie javy do pisania programów działających tylko lokalnie to jest jakieś nieporozumienie (obecnie wyjątkiem są telefony komórkowe i temu podobne)…

@michuk

Nie wiem czy takie łatwiejsze. Qt jest proste, a nie ma nawet porządnego IDE.

> Dobry programista napisze bezpieczny program i w asemblerze.

> Ale zajmie mu to 100 razy więcej czasu,

Niby dlaczego pisanie tej samej rzeczy w Javie czy Qt ma zabrać różną ilość czasu? Jeżeli się zna dany język, to programuje się porównywalnie szybko.

> ciężko to będzie rozwijać

To zależy, jak to zostanie napisane. Fakt – tutaj java wymusza pisanie łatwo rozszerzalnego kodu. Czyli mam rozumieć, że dziś na programistów jest bat potrzeby, żeby dobry kod pisali?

> i będzie zdecydowanie mniej przenośne.

Ale przynajmniej nie będzie pseudoprzenośne. Jeżeli zostanie dobrze (poprawnie) napisane, to wystarczy rekompilacja. W tych miejscach, gdzie nie ma przenośności (np. format ścieżek pomiędzy unix a dos) Java też nic nie pomoże. A w C++ i tak wystarczy kilka #define i problem z głowy.

> Myślę, że chcemy tego czy nie —

> przyszłość to .NET i Java

Owszem, jeżeli każdy będzie przytakiwał – to z pewnością.

Myślę, że zaczyna szerzyć się moda na przenośność – i tacy producenci, który dotychczas pisali jedynie dla windowsa, mają wybór: albo prawdziwe pisanie przenośnych programów, albo ominięcie problemów za pomocą javy/.net.

Jeżeli wszędzie zobaczą komentarze, jakie to wspaniałe i przyszłościowe rozwiązania, to zgadnijcie, co wybiorą?

Java/.net powinna być traktowana jak VB. Zastępcze rozwiązania dla małych niekrytycznych programików.

a jakie sa te mechanizmy, ktore wymuszaja bezpieczne programowanie w Javie/dotnecie ?

Chociazby obsluga wyjatkow.

i niby nie ma tego w C++ ?

zreszta, wyjatki nic nie wymuszaja, mozna programowac bez nich. ba, mozna je ignorowac

@stilgar: Są. W Javie łapanie wyjątków jest obowiązkowe (tych nie RuntimeException) także musisz je obsługiwać – niby nic a jednak programista jest zmuszony do obsłużenia wyjątków.

w C++ tez jest obowiazkowe – jak nie bedziesz lapac, to program sie wysypie. i tak samo jak w Javie mozesz lapac wszystkie wyjatki i nie reagowac na nie…

wiec leniwy programista moze bez problemu zrobic blok

try

{

//kod wyrzucajacy wyjatki

}

catch (…)

{

//do nothing

}

i co, niby mamy obowiazkowe wyjatki, ale wcale program nie stal sie bezpieczniejszy, wszystkie zignorowane. Oczywiscie, programista musi pojac decyzje o tym, ze wyjatki bedzie ignorowal, samo sie nie zrobi – ale slaby programista, ktory nie bardzo sie na programowaniu zna, bedzie ignorowal wyjatki, bo nie bedzie wiedzial co z nimi zrobic.

I gdzie tu to wymuszone bezpieczenstwo?

Podsumowujac – i w Javie i w C++ masz taka sama obsluge wyjatkow – ergo, jak to przemawia na korzysc Javy?

@stilgar: brak wskaźników, możliwości odwołania się do komórki o podanym adresie. Kontrola absolutnie wszystkiego, na poziomie kompilacji. Tablica jest obiektem pamiętającym jej rozmiar, zapisanie czegoś pod nieistniejący indeks (adres) skutkuje zgłoszeniem IndexOutOfBoundsExceotion, a nie wyjątkiem ochrony pamięci, przez co nie możliwe jest zrobienie programu w Javie z błędem typu BufferOverflow.

@ultr: pisałem w ASM (x86, 6502, 8051), C/C++ i Java, projektuję i piszę aplikacje zawodowo i komercyjnie. Z mojego doświadczenia mogę CI powiedzieć szczerze, w Javie napiszesz program o wiele wiele szybciej, jeśli ja mam pisać aplikację dla biznesu to pierwsza myśl to Java, a serwerowe aplikacje piszę tylko w Javie i inne rozwiązania nie wchodzą w grę bez konkretnego uzasadnienia.

Dlaczego Java? :

- przenośność

- bezpieczeństwo

- szybkość szukania błędów

- jednolite i bogate API standardowe

Na serwerach nie ma znaczenia czy program działa szybko czy wolno, zazwyczaj maszyna i tak jest na wyrost. Ważne aby aplikacje napisać w miarę szybko i bardzo szybko móc zdiagnozować problem i poprawić.

W Javie jak się wysypie program masz pełnego stack trace'a, który rozwiązuje 90% problemów, w C/C++ masz info, że program wykonał nieprawidłową operację. Po co więc mam ryzykować i dawać klientowi aplikację w C i potem modlić się abym mógł z logów wywnioskować dlaczego się wysypał, zamiast aplikację, która w momencie wysypania się daje mi pełne info. Tak w Javie pisze się o wiele szybciej i to nie podlega dyskusji.

Dlaczego w C++ pisze się wolniej:

- musisz osobno utrzymywać pliki nagłówkowe i źródłowe, np. modyfikujesz parametr w metodzie, to musisz to robić 2 razy w 2 osobnych plikach, piszesz nową metodę to też 2 razy piszesz raz deklarację, potem definicję.

- API jest bardzo ubogie, nie ma standardu co do obsługi socketów, plików ZIP, protokołów internetowych typu HTTP – Java ma to wszystko w podstawowym API

- API Javy jest prawdziwie obiektowym API, niestety ale w C++ inaczej się czyta z pliku, z socketa, z ZIPa z HTTP ….. metody oparte o strumienie Javy mogą nie wiedzieć z czego czytają czy do czego zapisują, dlatego w Javie łatwiej zaprojektować uniwersalne metody.

- C++ nie ma żadnego GUI w standardzie, Java ma SWINGa, który działa wszędzie

- mechanizm exceptionów w Javie jest o wiele lepiej skonstruowany w C++ w Windows w pliku DLL nie złapiesz exceptiona

>nie wiem jak tam z tym dot netem, ale java służy do pisania aplikacji i apletów internetowych.

Widze, ze kolejny expert sie wypowiada. Java sluzy do tego to czego chce sie jej uzyc, a applety akurat sa na wymarciu.

To ze najczesciej jet uzywana j2ee nie wyklucza innych uzyc. Mozna z powodzeniem nawet piasc gry 3d i powstalo pare takich.

>zreszta, wyjatki nic nie wymuszaja, mozna programowac bez nich. ba, mozna je ignorowac

Tak jak kolega napisal wyzej, w c++ mozna je ignorowac, w javie nie. Poza tym operowanie na wskaznikach tez daje mozliwosc popelnienia bledow ktorych w javie nie da sie popelnic.

W Javie łapanie wyjątków jest obowiązkowe (tych nie RuntimeException) także musisz je obsługiwać – niby nic a jednak programista jest zmuszony do obsłużenia wyjątków.

Jak programista jest leniem, to moze zawsze lapac wyjatki i je ignorowac. Wiec wymuszenia bezpieczenstwa nie ma.

- musisz osobno utrzymywać pliki nagłówkowe i źródłowe, np. modyfikujesz parametr w metodzie, to musisz to robić 2 razy w 2 osobnych plikach, piszesz nową metodę to też 2 razy piszesz raz deklarację, potem definicję.

Jak sie pisze w edytorze typu nano czy vim to istatonie moze byc to problemem – ale w KDevelopie to zaden problem, wszystko robi sie samo i to bardzo wygodnie.

A rozdzielenie od siebie deklaracji i implementacji ma wielka zalete – jak widzisz opis klasy, masz po prostu wypisane jej zmienne i metody – szybko mozesz sie zorientowac co ta klasa robi i jakie metody sa jakie – a w javie musisz przebrnac przez tony implementacji…

zreszta, nikt ci nie broni pisac w C++ w ten sam sposob co w javie…

- API jest bardzo ubogie, nie ma standardu co do obsługi socketów, plików ZIP, protokołów internetowych typu HTTP – Java ma to wszystko w podstawowym API

Czesciowo sie zgodze – API Javy jest bardzo rozlegle, swietnie udokumentowane, po prostu sama przyjemnosc – az do momentu, kiedy chce sie uzyc czegos, czego nie ma w standardowym zestawie – np. OpenGL – zeby zmusic JOGLa do dzialania, musialem sie niezle nameczyc… w C++ wystarczyl include i -lGL w opcjach kompilacji

C++ nie ma żadnego GUI w standardzie, Java ma SWINGa, który działa wszędzie

a w C++ masz wybor mozesz uzywac Qt, ktore dziala wszedzie, mozesz uzywac GTK

Tak jak kolega napisal wyzej, w c++ mozna je ignorowac, w javie nie. Poza tym operowanie na wskaznikach tez daje mozliwosc popelnienia bledow ktorych w javie nie da sie popelnic.

Mozna ignorowac tak samo w C++ jak w javie – robisz pustego catch i juz

>- az do momentu, kiedy chce sie uzyc czegos, czego nie ma w standardowym zestawie – np. OpenGL – zeby zmusic JOGLa do dzialania, musialem sie niezle nameczyc…

Coz tak to zwykle bywa jesli nie do konca wie sie co sie robi, bo tak na prawde to nie ma w tym nic skomplikowanego – kwestia dwoch rzeczy, przy ktorych wcale nie trzeba sie nameczyc.

>Mozna ignorowac tak samo w C++ jak w javie – robisz pustego catch i juz

Chyba nie rozumiesz ,ze w c++ nie ma obowiazku obslugiwania wyjatkow, w javie jest.

Jak sie pisze w edytorze typu nano czy vim to istatonie moze byc to problemem – ale w KDevelopie to zaden problem, wszystko robi sie samo i to bardzo wygodnie.

A rozdzielenie od siebie deklaracji i implementacji ma wielka zalete – jak widzisz opis klasy, masz po prostu wypisane jej zmienne i metody – szybko mozesz sie zorientowac co ta klasa robi i jakie metody sa jakie – a w javie musisz przebrnac przez tony implementacji…

Co to za zaleta. Od takich rzeczy jest IDE. Cały wygląd klasy masz w outline a do tego w kontekstowym Javadocu. KDevelop potrafi czytać Doxygena ze źródeł i od razu podpowiadać? KDevelop w porównaniu do NetBeans czy Eclipse to porażka.

a w C++ masz wybor mozesz uzywac Qt, ktore dziala wszedzie, mozesz uzywac GTK

Tyle że Qt musisz sobie kupić by rozwijać komercyjne aplikacje.

Mozna ignorowac tak samo w C++ jak w javie – robisz pustego catch i juz

Nie tak samo. W C++ nie masz wymuszonego złapania wyjątku a rozwiązanie podane przez Ciebie zachowa się inaczej niż nie złapanie wyjątku w ogóle.

>Mozna ignorowac tak samo w C++ jak w javie – robisz pustego catch i juz

Chyba nie rozumiesz ,ze w c++ nie ma obowiazku obslugiwania wyjatkow, w javie jest.

Nie zlapanie wyjatku w C++ powoduje wysypanie sie calego programu.

>Nie zlapanie wyjatku w C++ powoduje wysypanie sie calego programu.

Jesli wystapi, jesli nie to sie nie wysypie przeciez. W javie bez zlapania wyjatku program sie nie skompiluje i o to chodzi.

Nie zlapanie wyjatku w C++ powoduje wysypanie sie calego programu.

Ale nadal nie rozumiesz o co chodzi z łapaniem/nie łapaniem wyjątków. Chodzi o obsługiwanie w stosowny sposób sytuacji wyjątkowych i normalne kontynuowanie programu.

Zauważ że:

<code>

try {

foo();

} catch (…) {}

</code>

to co innego niż:

<code>

foo(); // bez złapania wyjątku

</code>

> W tych miejscach, gdzie nie ma przenośności (np. format > ścieżek pomiędzy unix a dos) Java też nic nie pomoże.

@ultr

Widze, ze nie umiesz programowac w Javie i nie masz

o niej zbyt duzego pojecia:

java.io.File.separator

Niby dlaczego pisanie tej samej rzeczy w Javie czy Qt ma zabrać różną ilość czasu? Jeżeli się zna dany język, to programuje się porównywalnie szybko.

Dlatego, że na 10 programistów na 3 lata kilku zmieni pracę, trzeba będzie znaleźć osobę, którą da się szybko wdrożyć.

To zależy, jak to zostanie napisane. Fakt – tutaj java wymusza pisanie łatwo rozszerzalnego kodu. Czyli mam rozumieć, że dziś na programistów jest bat potrzeby, żeby dobry kod pisali.

Jedno jest pewne, zostanie to napisane szybko. Bat/minimalne zapewnienie jakości – nazywaj to jak chcesz.

Ale przynajmniej nie będzie pseudoprzenośne.

Co to znaczy?

Jeżeli zostanie dobrze (poprawnie) napisane, to wystarczy rekompilacja.

Tak, szczególnie, gdy ktoś 3 lata wcześniej dla wygody użył win32 API, albo gdy po prostu aplikacja w związku z postawionymi odgórnie wymaganiami w win32 została napisana.

W tych miejscach, gdzie nie ma przenośności (np. format ścieżek pomiędzy unix a dos) Java też nic nie pomoże. A w C++ i tak wystarczy kilka #define i problem z głowy.

Pisałeś coś w Javie kiedyś? Wygląda na to, że nie. (mała podpowiedź… zajrzyj do System.getProperties())

Owszem, jeżeli każdy będzie przytakiwał – to z pewnością.

Przytakiwanie, myślisz, że to przez to sporo dużych aplikacji pisze się w Javie? Jak Ty sobie to wyobrażasz?

Myślę, że zaczyna szerzyć się moda na przenośność – i tacy producenci, który dotychczas pisali jedynie dla windowsa, mają wybór: albo prawdziwe pisanie przenośnych programów, albo ominięcie problemów za pomocą javy/.net.

Java zapewnia przenośność – to nie moda, to też nie sposób na ominięcie problemów, to wymagania klientów. I wsparcie dużego producenta oprogramowania.

Jeżeli wszędzie zobaczą komentarze, jakie to wspaniałe i przyszłościowe rozwiązania, to zgadnijcie, co wybiorą?

Java/.net powinna być traktowana jak VB. Zastępcze rozwiązania dla małych niekrytycznych programików.

Kto managerzy, tak siedzą teraz na osnews i czytają Twoje komentarze i lamentują, że powinno być jednak w C++ i QT? Udał Ci się żart.

Hmm, Java nie wymusza wyłapania wyjątków w momencie ich wystąpienia (gdyby tak było mechanizm wyjątków w Javie byłby kompletnie popsuty). Wystarczy zadeklarować, że metoda ,,throws Exception''. Bo zazwyczaj ciężko zareagować na wyjątek na poziomie abstrakcji wywołania konkretnej funkcji. Należy to zrobić wyżej w hierarchii — np. ubić cały wątek który ,,zbłądził''. Jedyne co Java ma to statyczne typowanie wyjątków. C++ ma dynamiczne. Co o tyle jest dziwne, że to Java jest bardziej dynamicznym językiem.

.

Ziew, strasznie dużo bzdur napisaliście (i o Javie, i o C++). Na pl.comp.lang.c i pl.comp.programming są często flame'y nt. ,,C++ vs. Java'' — polecam poczytać. Można dowiedzieć się wielu ciekawych rzeczy o językach które, we własnym mniemaniu, się zna.

>Wystarczy zadeklarować, że metoda ,,throws Exception”.

Whatever szczegol, nie zmienia to faktu ze java wymusza obsluge wyjatku a c++ nie.

@bies: Nie rozumiem co masz na myśli? Przecież opisałem że wyjątki RuntimeException nie muszą być deklarowane w 'throws' sygnatury metody, ani nie muszą być łapane w kodzie (wtedy wyjątek przekazywany jest do góry aż trafi do miejsca gdzie program się zaczął i jest wykonywane printStackTrace() na wyjątku). Niestety nie rozumiem co masz na myśli w:

Bo zazwyczaj ciężko zareagować na wyjątek na poziomie abstrakcji wywołania konkretnej funkcji. Należy to zrobić wyżej w hierarchii — np. ubić cały wątek który ,,zbłądził”. Jedyne co Java ma to statyczne typowanie wyjątków. C++ ma dynamiczne.

To powiedz jak wg. Ciebie powinny wyglądać wyjątki w Javie żeby mogły zaliczyć się do systemy wyjątków "bardziej dynamicznego języka"?

Obrazowo: masz pulę połączeń z klientami. Na pewnym etapie jednego z połączeń występuje błąd i jest sygnalizowany wyjątkiem. Sam obiekt połączenia nie ma wystarczających kompetencji aby taki wyjątek obsłużyć i musi przekazać go wyżej. Dopiero obiekt zarządcy połączeń (opiekujący się całą pulą) może wyłapać wyjątek i ubić popsute połączenie, i uzupełnić pulę.

.

To czy wyjątek będzie dzieckiem RuntimeException to właściwie nie ma znaczenia. Tzn. nie miałoby znaczenia gdyby nie statyczne sprawdzanie obsługi wyjątków. I teraz masz pewną rozbieżność — dzieci RuntimeException lecą w górę bez deklaracji a inne wyjątki musisz deklarować. Przykładem takich wyjątków są wszystkie dzieci IOException. To są typowe wyjątki czasu wykonania ale nie dziedziczą po RuntimeException.

.

A w dynamicznych językach wyjątki zazwyczaj latają bez potrzeby wyliczania. Z drugiej strony są takie wyjątki jak InterruptedException, które warto sprawdzać statycznie (choćby dając ostrzeżenia kompilatora).

Dobry inżynier jest w stanie przewidzieć taką sytuację i nie będzię ona RuntimeException, co spowoduje dalsze konsekwencje…

Co do Javy:

Paradoksalnie właśnie w zastosowaniach serwerowych często jest dużo miejsca na… języki normalne. Jeśli w języku normalnym program będzie konsumował 20% mniej zasobów, to już będzie można kupić 20% mniej hardware. Jeśli nawet napisanie w języku normalnym będzie trwało 2 razy więcej czasu, to się zatrudni programistów 2 razy dłużej, wybuli dodatkowy milion złotych, ale zysk z tego tytułu będzie wprost proporcjonalny do skali rozwiązania.

A na domowych komputerach… no cóż… nie ma dla Javy miejsca w ogóle. to zamulacz i tyle. Ale akurat nieliczenie się z zasobami sprzętowymi to taka widzę nowa moda. To co, że na domowym komputerze nie ruszy? dokupi użytkownik 4 razy więcej pamięci i ruszy. No przecież takie podejście do sprawy jest… niepoważne.

@Maciek: ale faktycznie w 95% zastosowań (strzelam)cena sprzętu są o rząd wielkości mniejsza niż pensja programisty. Dlatego opłaca się minimalizować czas programisty, nawet jeśli kod nie będzie optymalny i potrzeba będzie do jego odpalenia klastra z 3 serwerami, zamiast dwóch.

Tylko w zastosowaniach, które naprawdę muszą się świetnie skalować (np na setki tysięcy maszyn) oraz w przypadku aplikacji instalowanych na komputerze end-usera optymalizacja kodu jest istotna i tu warto poświęcić pieniądze na dobrego programistę.

Takie życie.

michuk: Oczywiście zgoda! Z resztą jeśli n.p. program nie jest "ciężki obliczeniowo", to i … mniejszy jest pożytek z podwojenia szybkości.

>Z resztą jeśli n.p. program nie jest “ciężki obliczeniowo”, to i … mniejszy jest pożytek z podwojenia szybkości.

Czyli uwazasz ze cos napisane w c/c++ jest dwa razy szybsze od tego samego w javie?

@michuk

koszt sprzetu o rzad wielkosci mniejszy od plac programistow? serio? to juz sie ciesze, ze sobie taki zawod wybralem

a na serio: programista dostaje 100k zl za napisanie softu, ktory bedzie odpalany na serwerze za 10k ? no, oczywiscie, to zalezy jaki to soft, jak caly system operacyjny, to pewnie i takie sa proporcje… ale jak ktos zamawia program do obslugi firmy, ktory instaluje na kilku-kilkunastu komputerach w firmie, to jeszcze nie widzialem, zeby placil za niego kilkaset tysiecy zl, raczej kilka…

chociaz ( tu nawiaze do dyskusji z innego watku ) jesli piszesz programy, ktore maja po kilka mln linii kodu, to pewnie i wynagrodzenie jest odpowiednie…

> Czyli uwazasz ze cos napisane w c/c++ jest dwa razy szybsze od tego samego w javie?

Tak dobrze to nie ma

> a na serio: programista dostaje 100k zl za napisanie softu, ktory bedzie odpalany na serwerze za 10k ? no, oczywiscie, to zalezy jaki to soft, jak caly system operacyjny, to pewnie i takie sa proporcje…

Moja firma jest właśnie w trakcie zamawiania dedykowanego systemu ERP. W firmie jest około 20 komputerów, na których będzie działać + około 10 przedstawicieli w trasie. W 100k raczej nie wyrobimy się. Serwer, na którym będzie działać napewno będzie sporo tańszy.

>ale jak ktos zamawia program do obslugi firmy, ktory instaluje na kilku-kilkunastu komputerach w firmie, to jeszcze nie widzialem, zeby placil za niego kilkaset tysiecy zl, raczej kilka…

Widocznie niewiele widziałeś. Nie wiem skąd wymyśliłeś te "kilka" tysięcy na dedykowany soft. Może jeśli studenci piszą go w akademiku to cena jest niewielka, ale jakość takiego kodu będzie proporcjonalna do ceny.

@stilgar: duże systemy pisze się długo – wiele miesięcy – policz sobie np. zapłacenie pensji 10 dobrym programistom po np. 4k zł + podatki przez rok albo i dłużej (bo. tyle powstają duże systemy). Bez podatków jest to 480 000 zł za rok, z podatkami grubo ponad 600 000 zł – cena sprzętu przy tym to w większości przypadków jest nic, a cena systemu operacyjnego – nawet najdroższego Windowsa to darmocha! Tym bardziej, że za rok i tak sprzęt będzie tańszy, a programista za rok będzie chciał tyle samo albo i nawet więcej .

tak tak, macie racje

po prostu mialem na mysli mniejszy kaliber projektow

Co nie zmienia faktu, że wirtualna maszyna .NET, czyli CLR ma praktycznie skopiowaną listę rozkazów z JavaVM, tym samym technicznie kompilowanie z innych języków do bytecodeu JavaVM nie jest problemem, niezależnie od tego jakiej otoczki marketingowej by wokół tego nie zbudować.

hm… przekonywująca argumentacja… choć co do tego stack trace, to wystarczy w C… zarejestrować stosowną funkcję onexit albo jakiś skrypt inicjalizacyjny, który wymusi core dump w razie segmentation faulta

No cóż po minusach widzę, że jednak większość osób jest w błędzie i nadal bezsensownie twierdzi, że kompilatory potrafią wypluć szybszy kod od dobrze dopracowanej procedurki zrobionej przez zaawansowanego kodera… hmmm ja zawsze jak przepisuje na assembler to działa szybciej macie jakiś dziwne doświadczenia, albo brak doświadczeń .

Nie wszystkie procedurki są dobrze dopracowane.

Nie każdy koder jest zaawansowany.

Jedno i drugie kosztuje.

Poza tym ktoś w czasach Pentium I dobrze dopracował kod i działa szybciej. W międzyczasie wychodzi MMX i trzeba przepisywać asma, żeby dalej było szybko. Potem SSE. Potem SSE2. A gcc (czy inny kompilator) robi to gratis;)

mario: zgoda!

el.pescado : też zgoda, ale: jeśli asemblera używa się w programach użytkowych czy grach (generalnie: dla użytkownika domowego), to cel jest w tym nie taki, aby działało "jeszcze szybciej" a w tym, aby jakaś funkcjonalność była w ogóle dostępna na kompach 99% potencjalnych użytkowników. W efekcie gdy wchodzi nowa generacja sprzętu, starego kodu nie trzeba poprawiać… bo co było potrzebne, zostało już osiągnięte.

@el.pescado:

"Nie wszystkie procedurki są dobrze dopracowane.

Nie każdy koder jest zaawansowany.

Jedno i drugie kosztuje."

A ja nie piszę ani o kosztach ani o dobrych i złych koderach – po prostu obalam mit – bo kompilatory nie generują lepszego kodu niż człowiek. Oczywisty jest wybór w języku tak aby wybrać język który zapewni Ci odpowiednio szybki proces powstawania programu, sam większość piszę w Javie!

"Potem SSE. Potem SSE2. A gcc (czy inny kompilator) robi to gratis;)"

GCC nigdy nie zoptymalizuje dobrze procedurki do SIMD, bo jest to ogromnie trudne. Sam kiedyś zaimplementowałem liczenie przezroczystości w MMX i było ok. 2 razy szybsze niż to co jest w bibliotece allegro. Instrukcje SIMD są proste i stworzone pod ręczne pisanie kodu a nie pod kompilatory. Kompilator powinien mieć rozszerzenia do obsługi instrukcji SIMD ze specjalnymi instrukcjami, w których zapisuje się bloki operacji w grupach inaczej to nie ma sensu.

Przebrnąłem przez te komentarze i zauważyłem, że wielu z was wysokopoziomowość kojarzy głównie z przenośnością. Dla mnie poziom języka zależy od tego jakimi "częściami" operuję rozważając program. Dlatego Java jest wyższego poziomu niż C++, bo w niej niemal wszystko jest obiektem. W C++ mamy sporo możliwości operowania na niższym poziomie. A C jest jeszcze niżej, bo tam operuję głównie na typach podstawowych czy adresach pamięci, rzadko operując strukturami "obiektowopodobnymi".

Co do przyspieszania assemblerem i porównywania własnego pisania do automatycznego kompilowania. Wielu z Was twierdzi, że zrobi szybszy kod pisząc go samych. Ale po pierwsze kompilatory nie piszą się same a piszą je ludzi i to bardzo dobrzy eksperci, po drugie Wasz kod zapewne w większości przypadków nie jest bezpieczny i łatwo go wyłożyć. A sprawdzenie każdego warunku, które sprawia, że kod jest bezpieczniejszy niestety kosztuje nas wydajność.

Co do Javy i jej szybkości. Połowę komentarzy można wywalić do kosza od razu, bo bazują na mitach o Javie a nie na realiach. Oczywiście z Javą jest związany pewien nakład obciążenia, który zwraca nam się w bezpieczeństwie. Ale nakład o którym mówicie jest wysoko przesadzony. Pracuje w branży, gdzie wykonywane są bardzo zasobożerne i czasochłonne obliczenia. Co więcej dziedzina się bardzo szybko rozwija, także programy na których bazujemy ewoluują non stop. Same programy jak i ich utrzymywanie kosztują setki tysięcy dolarów/euro. Sprzęt również bardzo szybko ewoluuje. Posiadamy programy różnych dostawców wykorzystujących różne technologie także mam możliwość porównania technologii. Również sami rozwijamy niektóre produkty lub tworzymy własne rozwiązania. Mimo mojego wielkiego sceptycyzmu do Javy po roku doświadczeń z tą technologią mogę przyznać, że w zaawansowanych rozwiązaniach obliczeniowych sprawdza się ona bardzo dobrze. W większości przypadków jesteśmy na etapie zmiksowanego wykorzystywania technologii, czyli część w Javie obsługują np. wejście/wyjście na plikach rozproszonego formatu, a obliczenia jak na razie wykonywane są na starych metodach napisanych w FORTRAN/C. Ale tendencja na dzień dzisiejszy jest jasna – kierunek Java.

Dobrze gada, dać mu wódki (a przynajmniej plusika w karmie).

@tad: zgadzam się z Tobą w dużej mierze, prawie w 100%

Co do przyspieszania assemblerem i porównywania własnego pisania do automatycznego kompilowania. Wielu z Was twierdzi, że zrobi szybszy kod pisząc go samych. Ale po pierwsze kompilatory nie piszą się same a piszą je ludzi i to bardzo dobrzy eksperci,

Problem polega na tym, że stworzenie kompilatora, który dobrze będzie optymalizował do MMX, 3Dnow, SSE jest o wiele trudniejsze od dopracowania specjalizowanej procedurki w ASM – jest to na tyle trudne, że żaden kompilator tego nie potrafi! Robiłem kiedyś testy z liczeniem przezroczystości, zaimplementowałem to w C i w czystym MMX – moja procedurka w czystym MMX była wiele razy szybsza! Zgodzę się że kompilator może wygenerować dobry kod SIMD, ale język musi mieć rozszerzenia w którym zapisuje operacje na zgrupowanych liczbach, inaczej analiza problemu przez kompilator ma poziom złożoności tak wysoki, że praktycznie problem jest nieopłacalny do rozwiązania i lepiej napisać dedykowaną procedurkę w ASM.

Oczywiście niezmiernie rzadko potrzebujemy aż takiej optymalizacji, tym bardziej, że dzisiejsze karty graficzne mają o wiele większą moc obliczeniową od CPU i raczej wszystko się zrzuca na nie. Ze względu na poziom abstrakcji, bezpieczeństwo i wygodę również stosuję w ogromnej większości moich programów Javę, w komercyjnych tylko Java. Również nie zgadzam się z osobami narzekającymi na prędkość Javy, uważam ją za bardzo dobrą – moim zdaniem programy Javy mogą sprawiać wrażenie działających wolniej, ze względu na dużą ilość pamięci jaką zużywają, a tym samym są częściej swapowane.

A nikt, nikt. Pogratulować zatem aktualnej dystrybucji.

Na czyją korzyść ?

Na korzyść Linuksa. Różnica jest zwykle rzędu 5-12 razy.

Najwyraźniej coś jest nie tak z twoim Windowsem. Na tym samym sprzęcie nie powinno być dużych różnic.

sprawdź czy to PHP to jest ta sama wersja i skompilowana z podobnym poziomem optymalizacji.

Gdybyś jednak nie zauważył, w mojej odpowiedzi do Twojego komentarza było sporo ironii. Bo zauważyłeś, że programy pisane w Javie są wolne, sypią się… nie napisałeś nic więcej, jakie programy, jaka VM, w jakiej wersji to wszystko. Ciężko brać na poważnie taki komentarz.

Patrz, a ja nie wiedziałem, że daweoo to badziew. Zawsze myślałem, że robią całkiem niezłe sliniki… popatrz czego to się człowiek może dowiedzieć!