Mono Paint — w końcu konkurent GIMP-a?
- Dodano: 23 grudnia 2007
- Wprowadził: michuk
- Komentarze: 171
Miguel de Icaza udostępnił przyjazną zwykłym śmiertelnikom wersję programu paint-mono — portu Paint.NET, edytora grafiki rastrowej dla platformy Mono. Teraz paint-mono może skompilować każdy legitymujący się Mono w wersji 1.2.6, dowolnym systemem uniksowym oraz klientem SVN.
paint-net pod Linuksem
Port biblioteki SystemLayer.dll nie jest jeszcze zakończony, ale większość funkcji Paint.NET powinna działać.
Jako że twórcy Paint.NET poprosili, aby nie korzystać z ich nazwy na użytek portów, Miguel proponuje nazywać nowe dziecko Mono Paint.
Na Google Code udostępniony jest kod projektu.
Więcej informacji: http://tirania.org/blog/archive/2007/Dec-21.html
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
171 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Wszystko mnie cieszy, tylko ten .NET jakoś niezbyt…
W Javie nie ma takich problemów – Java oferuje prawdziwą przenośność aplikacji pomiędzy różnymi platformami!
I prawdziwe ZOO szarych zwierzątek afrykańskich.
hm
wybacz ale program do grafiki w javie? nie, chyba podziekuje
przenośność super sprawa ale coś za coś – wydajność spada i wzrasta obciążenie, a przecież grafika to przede wszystkich w 3 i troche obliczeń przy filtrach, efektach i innych edycjach
wiec… raczej się nie sprawdzi
takoz i w mono, te same wady
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.
Akurat grafika w Javie(java2d) jest bardzo wydajna.
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.
A podsumowując wojnę java vs mono, najlepsze jest po prostu programowanie przy użyciu przenośnych bibliotek widżetów takich jak Qt czy GTK oraz poprawnego kodu.
Lepiej skompilować 3 razy na różne platformy, niż udawać, że chodzi na każdej, ale jakby nie do końca.
Co w Javie chodzi Ci nie do końca?
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
To taka sama teoria, jak przenośność .Net
Jak robisz w Qt coś nietrywialnego i coś co trochę wykracza poza frontend do bazy danych, to nie unikniesz setek #ifdefów zapewniających wieloplatformowość.
Oby Paint-Mono zmotywował developerów GIMP-a i Krity do ulepszenia swoich programów – taki pozytywny aspekt widzę. Bo .NET czy Mono jakoś mi się nie uśmiecha.
Uff Dobrze że w końcu jest jakiś konkurent dla Gimp'a przecież photoshop nie jest żadną konkurencją
Choć jest w tym trochę prawdy.
Photoshop jest może lepszy o kilka przydatnych efektów oraz możliwość przełączania ich zastosowania (czyli masz nadal dostęp do pierwotnej warstwy).
A cała reszta to tragedia. Kiedy już się człowiek przyzwyczai do GIMPa, to za nic nie można wrócić do Photoshopa. Wolę poczekać, aż GIMP nadrobi niektóre zaległości, niż męczyć się z Photoshopem.
To prawda Nijak nie potrafię się przestawić na PS i zawsze wybieram GIMPa Siła przyzwyczajeń
Screen nie działać.
I Java i .NET zużywa więcej zasobów zasobów niż natywny exec. Czasami ważniejsze jest to że program działa w ogóle (Worse is Better), czy też to że można go przenieść bez kompilacji na inną platformę. Ale używanie .NET czy Javy do tworzenia programów codziennego użytku to chory pomysł. No bo po co ? Niestety do pana Miguela to niedociera, on "rewolucjonizuje". Wróćmy do czasów kiedy programy działały wolno, bo te nowe procesory takie szybkie są…
Używam RSSowl i Azureusa na codzień i jakoś nie narzekam – a najszybszej maszyny nie mam (jeden rdzeń – 2,6 MHz, 1GB ram). Poza tym Netbeans i Eclipse to dla niektórych też programy 'codziennego użytku'
Eclipse? Wolne żarty.
To tnie się bardziej niż mocna gra 3D. Szczególnie przy edycji interfejsu, choć samo środowisko też muli.
Jeżeli tak ma wyglądać przyszłość oprogramowania, to ja wolę, żeby na Linuxa nadal nie było aplikacji. Przynajmniej nikt nie będzie mi wmawiał, że są.
Precz z javą/.net !
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.
I zapewniam, że gdyby NB był szybszy ucieszyłbym się… A on sam zajuje prawie 512 MiB (tyle mam właśnie pamięci
).
Faktycznie niezbyt szybkiej używasz maszyny. Nawet moja stara Amiga miała 16 MHz
ja mam k6 450 mhz i 256 mb ramu, obawiam sie ze to by byla rzezba, mam tez laptop 1,6 ghz i 512 ram twoj nie najszybszy to przy moich rakieta. A po co to pisze? Puenta jest taka ze nie ma znaczenia jaka ty masz maszyne ale jaka jest przecietna maszyna kowalskiego.
Powiedz to developerom np. IBM/Lotus, bo oni chyba nie wiedzą i piszą dalej w tej Javie, a nie w szybkim C++.
Azureus, Eclipse i Lotus do najszybszych programów nie należą… zresztą porównajcie sobie. Jeden z najpopularniejszych klientów BitTorrenta to µTorrent. Dlatego że podaje tyle informacji co Azureus zuzywając nieporównywalnie mniej zasobów. To że się da, nie znaczy że trzeba. Jeśli nie ma dobrej alternatywy, ludzie będą używać zamulacza. Ale jeśli się pojawi, od razu zdobędzie dużą popularność, tak jak µTorrent.
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.
hmm… to o co wlasciwie chodzi w tym calym mono czy dotnecie – jak napisze program w C++ to tez moge go sobie przekompilowac pod innym systemem…
a w Javie dziala po prostu, bez potrzeby rekompilacji…
w dotnet też nie trzeba rekompilować.
to dlaczego Paint.NET nie dziala pod linuksem?
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.
Jak programista jest leniem, to moze zawsze lapac wyjatki i je ignorowac. Wiec wymuszenia bezpieczenstwa nie ma.
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…
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
a w C++ masz wybor
mozesz uzywac Qt, ktore dziala wszedzie, mozesz uzywac GTK
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.
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.
Tyle że Qt musisz sobie kupić by rozwijać komercyjne aplikacje.
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.
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.
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
Dlatego, że na 10 programistów na 3 lata kilku zmieni pracę, trzeba będzie znaleźć osobę, którą da się szybko wdrożyć.
Jedno jest pewne, zostanie to napisane szybko. Bat/minimalne zapewnienie jakości – nazywaj to jak chcesz.
Co to znaczy?
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.
Pisałeś coś w Javie kiedyś? Wygląda na to, że nie. (mała podpowiedź… zajrzyj do System.getProperties())
Przytakiwanie, myślisz, że to przez to sporo dużych aplikacji pisze się w Javie? Jak Ty sobie to wyobrażasz?
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.
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:
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
> hmm… to o co wlasciwie chodzi w tym calym mono czy dotnecie – jak napisze
> program w C++ to tez moge go sobie przekompilowac pod innym systemem…
>
> a w Javie dziala po prostu, bez potrzeby rekompilacji…
W dotniecie zasadniczo chodzi o to samo co w zjawie, novum jest tu brak podstawowej wady javy, którą jest konieczność pisania w javie. W dotnecie można pisać w zasadzie dowolnym języku, warunkiem jest istnienie kompilatora tegoż języka do CIL-a (dotnetowy bajtkod). Programy dla dotneta można pisać w basicu, c, pascalu, jak również, o zgrozo, w javie. Oczywiście lista ta krótka nie wyczerpuje wszystkich języków.
@zuzia: Java ma identyczny mechanizm. Możesz pisać w Python, JavaScript, Groovy, Scheme czy Ruby i odpalać te aplikacje na JVM po skompilowaniu do bajtkodu Javy.
Java : jeden jezyk, wiele platform.
.NET : wiele języków, JEDNA platforma
Technologicznie może i pokrewne, ale doktrynalnie to przeciwne kierunki. Z czasem na JVM przeniesiono inne języki, ale to raczej hobbystyczna robota.
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ć.
nie umiem tego zainstalować ;/ wywala mi jakiś błąd 1 i błąd 2 0.o ;(
u mnie nie przechodzi make. Szkoda. GIMP ssie.
Nie wiem jak u Was, ale u mnie pojawia się dokładnie ta sytuacja. Brakuje pliku System.Xml.Linq.
dokladnie to mam
Do tych co narzekają na java albo .net-> dlaczego nie piszecie w assemblerze?Przecież będzie szybko i wydajnie hehe
Tak się śmiesznie składa, że pisałem w assemblerze x86 przez dobrych parę lat, i w razie czego po dziś dzień mam gotowe routines pod parę różnych technologii (MMX, 3DNow!) do wykonywania krytycznych fragmentów obliczeń (operacje macierzowe itp.), a nawet jeśli jakichś mi brak, to wiem gdzie mogę je znaleźć (MPlayer chociażby). Uwaga wielokrotnie w komentarzach sformułowana jest co najmniej trafna (pisanie aplikacji typu Photoshop w Java/.NET to trochę mijanie się z celem zastosowania tych języków IMO), natomiast pytanie postawione przez Ciebie jest co najmniej trollowate, bo każdy, nawet najbardziej zielony developer wie, że odpowiednie języki stosuje się do odpowiednich projektów, i tak, owszem, można napisać KDE w asemblerze, tylko czy stwarza to sens wydajnościowy? Jak dobrze wiadomo, nie, podobnie jak nie stwarza sensu wydajnościowego pisanie KDE w, nie wiem, PHP. :]
Jeśli moja argumentacja Cię nie przekonuje, to zadaj to pytanie na LKML. No chyba że tylko bawisz się w Jasia Śmietanę.
>(pisanie aplikacji typu Photoshop w Java/.NET to trochę mijanie się z celem zastosowania tych języków IMO)
To tez jest trollowanie. Rzucasz haslo, nie podajesz zadnych argumentow.
"pisanie aplikacji typu Photoshop w Java/.NET to trochę mijanie się z celem zastosowania tych języków IMO"
Nie koniecznie! Interfejs może być w Javie, a pluginy (filtry etc) mogą być pisane uniwersalnie, nawet w assemblerze, przy zachowaniu wersji w Javie dla pełnej kompatybilności. Wtedy dostajesz od ręki działające narzędzie, które będzie działać na wszystkich platformach, a dodatkowo możesz zoptymalizować pewne fragmenty pod najczęściej używane architektury.
Mnie wiele razy zdarzyło się wywalenie GIMPa – w odpowiedzi dostałem tylko "Segmentation fault", zamiast pełnego stosu wywołań z nazwami plików/metod i numerami linii w kodzie, co standardowo generuje VM Javy w przypadku dowolnego wyjątku. Ta informacja w 95% pozwala błyskawicznie poprawić błąd, niestety w C++ nadal one będą a user po prostu włączy program drugi raz. VM Javy ma jeszcze jedną zaletę, pozwala niezmodyfikowany program uruchomić z otwartym portem dla debuggera, wtedy developer może podłączyć się debuggerem zdalnie i sprawdzić dlaczego nie działa – to przydaje się zwłaszcza w biznesie, gdzie aplikacje stoją na serwerze.
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
Od kiedy kompilatory C potrafią wyprodukować znacznie bardziej wydajny kod niż ten w asm to nie sądze, żeby był duży nacisk na pisanie w assemblerze (wyjątek to chyba SIMD) – a na pewno na nie więcej niż wstawki assemblerowe.
SIMD i operacje atomowe plus bariery.
"kompilatory C potrafią wyprodukować znacznie bardziej wydajny kod niż ten w asm"
To nigdy nie będzie prawdą, człowiek potrafi o wiele lepiej zoptymalizować kod niż kompilator. Oczywiście ASM nadaje się do pisania tylko krytycznych fragmentów kodu, ponieważ inne i tak nie będą odczuwalne dla użytkownika.
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.
Odnoszę wrażenie, że relacja programista asemblerowiec vs. kompilator… jest mniej więcej stała. Kompilatory optymalizujące są coraz sprytniejsze, ale i procesory są coraz bardziej skomplikowane. GCC (wiem, opensourceowe badziewie, nie to, co profesjonalne narzędzia Intel czy Microsoft) prawie nigdy nie wykorzystuje pełnego zestawu możliwości x86_64, nawet jeśli nie wchodzi w grę SSE/3dNow!.
Efektywnie 20 lat temu można było w asemblerze średnio o 50% przyspieszyć każdy ambitniejszy kawałek kodu "robiąc go na asemblera"… i dzisiaj też można, mimo, że kompilatory lepsze. Tylko, że dzisiaj jest to mniej potrzebne, bo procesory są szybsze.
Ja bym (wiem, że to nienaukowe) wyróżnił 3 języki: niskiego poziomu, gdzie programista kontroluje zużycie pamięci i procesora (asembler), średniego, gdzie programista kontroluje zużycie pamięci (C, Pascal), i wysokiego, gdzie nawet użycie pamięci jest kontrolowane bardzo pośrednio (n.p. Java). Gdzie się mieści C++? biorąc pod uwagę, że można używać C++ z Garbage Collectorem? dalej w średnim poziomie. Wysoki poziom to języki interpretowane. Niezależne od sprzętu.
Czy te języki (wysokiego poziomu) są złe? nie koniecznie. Ale są złe, jeśli stawiają dużo większe wymagania co do hardware. Komputery na prawdę nie są za darmo, a domowy użytkownik to nie czytelnik CD Action, który ekscytuje się benchmarkami procków i kart graficznych by co 2 lata się upgrade'ować. Użytkownik domowy kupuje komputer raz na7 lat i liczy, że będzie mu przez te 7 lat ten komputer służył.
Co do użytkownika biznesowego, to jest to różnica, czy wystarczy instalacja za 400 tysięcy, czy trzeba wybulić 800 tysięcy, bo program jest "tak nowoczesny, że potrzebuje".
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%
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.
Trochę przerażają mnie te wymagania jeśli chodzi o Mono 1.2.6. To jest nowiutka wersja której nie znajdzie się w żadnej ze znanych mi dystrybucji (łącznie z najnowszymi typu ubuntu hardy alpha 2).
W portage jest conajmniej od 16 grudnia.
> Trochę przerażają mnie te wymagania jeśli chodzi o Mono 1.2.6. To jest
> nowiutka wersja której nie znajdzie się w żadnej ze znanych mi dystrybucji
> (łącznie z najnowszymi typu ubuntu hardy alpha 2).
Instalujesz tylko to co jest dostępne na płytkach/ISO? Update'ów z sieci nie robisz? Ratunku.
A kto powiedział, że nie robię?
A nikt, nikt. Pogratulować zatem aktualnej dystrybucji.
A dziękuję. To pewnie dlatego, że używam tab bardzo mało znanych dystrybucji jak Ubuntu i Fedora
, nie to co Ty 
Dla mnie osobiście ważnym wydarzeniem jest też wydanie Monodevelop 1.0b3 – jeżeli ktoś zdążył się już zniechęcić do tego IDE przez notoryczne wysypywanie się w najmniej oczekiwanych momentach, to mogę z czystym sumieniem powiedzieć że warto przyjrzeć mu się jeszcze raz.
Uważam że Mono jest jednym z najważniejszych *niksowych projektów dających dostęp do całej rzeszy nowopowstających aplikacji i dziwi mnie że Apple nie chce jakoś mocniej w to wejść (chyba że czegoś nie wiem).
Ważnym projektem dla uniksów (i reszty) to jest Qt i GTK.
Tyle że niektórzy postępowcy nadal spychają je na margines, choć jest to rozwiązanie kwestii _prawdziwej_ przenośności.
Hm, nie widzę związku między tym co napisałem a Twoją odpowiedzią (nie mówię tego złośliwie – po prostu nie bardzo rozumiem dlaczego porównujesz maszynę wirtualną z zestawami widgetów). Gtk nie rozwiąże mi np. problemu łączenia programów w Fortranie, Pythonie i C# (przykład realny).
No przecie jest najlepsza rzecz pod słońcem: GTK#
No to czekamy na ebuilda
Paint.NET jest naprawdę niezły
Póki co Gimp nie ma konkurencji (nie mówię o PS czy Corelu, chodzi o świat OpenSource). Krita niestabilna i nienadająca się do poważnej pracy (ten CMYK to promyczek, ale co mi po nim, jak program wywala bez przyczyny co kilkanaście minut), a Paint.NET nawet w pełni działającej wersji na Windows nie umywa się do Gimpa ilością funkcji i filtrów…
Swoją drogą proste programy do grafiki np. xpaint mają swoje poważne zalety i do niektórych rzeczy lepiej się nadają. Ileś lat temu jak używałem softu M$ to używałem zwykłego painta gdzie się da, a w ostateczności Photoshopa albo Paint Shop pro. To nie tylko moje zdanie ale też znajomych.
Co do wydajności to uważam że programista powinien o to dbać jak to tylko możliwe. Jest ku temu wiele powodów.
Wydajność osiąga się przez projekt, a nie przez programistyczne wygibasy, których sam autor po kwartale nie rozumie. Programista ma pisać prosto i poprawnie.
Spokojnie. Pierwsze koty za płoty, dajmy (pomóżmy?) aplikacji się rozwinąć. Dotnetowcy do boju
Koledzy, troszkę dziwią mnie opinie o tym, że Java, czy .NET jest niedobry do pisania aplikacji. Z mojego doświadczenia wynika coś zupełnie innego…
Wiem, w ASM się da, w C się da, we wszystkim się da. Tylko weźcie pod uwagę, że duże projekty prowadzone są często przez kilkunastoosobowe grupy programistów – z różnym poziomem wiedzy i całkiem sporą rotacją w teamie. Stawiane są dość ostre wymagania eksportowe, a to, żeby np. projekt można było wdrożyć w Iraku. Sporo jest ograniczeń odgórnych – a to, żeby nie dorzucać żadnych bibliotek na licencji jakiejśtam, bo nikomu nie będzie się chciało sprawdzić, jakie nakłada ograniczenia. Często nie ma czasu na zrobienie czegoś dobrze, więc dobrze, żeby język pilnował, żeby zrobione było dobrze. Itd. itd. dużo się zmienia podczas pisania projektu. Java naprawdę się sprawdza w takich sytuacjach, a Sun "trzymający" ją w garści i wspierający cały proces standaryzacji setek API opartych o konkretny JSR, (certyfikacji programistów też) zapewnia sporą stabilność tego języka, dla dużych projektów przeznaczonych na kilka-kilkanaście lat jak znalazł.
Wsparcie takich gigantów jak Sun, IBM, Apache i innych (SWT, eclipse platform, ant, maven, WebSphere, JUnit, emma, spring, hibernate, itd. itd.) też pozostaje nie bez znaczenia. Weźcie to proszę pod uwagę przed napisaniem "Java ssie".
Aha, co może Was ucieszyć, czasami pojawia się też wymaganie, żeby działało również pod GNU/Linux.
Jak już pisałem Java może być wolniejsza, ale nie musi. Aha, używanie eclipse na 512MB jest trochę niepoważne (mówię o Java IDE [JDT]). A wszystkim, którym eclipse muli na komputerze średniej klasy współczuję (i życzę Św. Mikołaja z quadem od Intela
)- u mnie gra i buczy, ale podobno pod MS Windows działa szybciej. 
> A wszystkim, którym eclipse muli na komputerze średniej klasy współczuję (i
> życzę Św. Mikołaja z quadem od Intela
)- u mnie gra i buczy, ale podobno
> pod MS Windows działa szybciej.
Siedzę od długiego czasu na Aptanie i przyznam, że nie widzę różnicy w prędkości pracy aplikacji pomiędzy Win32 i Linux.
A ja widzę różnicę w wielu aplikacjach, również graficznych a np w PHP jest ogromna różnica w wydajności na tym samym kompie na win i Linux.
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.
Chodziło mi konkretnie o eclipse. Po prostu rozmawiałem z kimś kiedyś, kto pracował trochę na obu systemach i stwierdził, że na GNU/Linux działa mu wolniej. Ja takiej różnicy nie zauważyłem, ale kilka rzeczy w w Linuksie było w eclipse kiedyś zrobione wolniej, np. wykrywanie zmian w pliku – ale może teraz używają już jakiegoś FAM, czy coś w tym stylu nie wiem.
Na Linuksie może być odczucie wolniej pracującego Eclipse, a to za sprawą GTK, które jest używane przez SWT. WinAPI jest bardziej responsywne niż GTK (Qt zresztą też), dlatego Eclipse może wydawać się pracować szybciej, ale w rzeczywistości jest to tylko złudzenie mniej responsywnego GUI.
A teraz z innej beczki
Ciężko przebrnąć przez te komentarze, czyta się to jak scenariusz jakiegoś serialu o programistach który wykazują swoją wyższość.
PS1.
Piszę te słowa z punktu widzenia użytkownika-głupka co na programowaniu się nie zna a jak się mu zachce coś napisać to wybiera język w którym będzie mu łatwiej to coś napisać.
PS2.
Z ortografią i gramatyką też mam problemy.
Gimp jest doskonałym programem. Mój kolega żałuje, że wybulił kupe forsy na PSa.
@doominic:
łatwość i szybkość pisania programu jest odwrotnie proporcjonalna do szybkości jego działania.
Dlaczego?
Proponuję Ci – całkiem poważnie – przyjrzeć się źródłom eclipsa, coś co jest dobrze zaprojektowane i później zaimplementowane naprawdę się sprawdza. Widać, że IBM/Eclipse foundation ma dobrych inżynierów.
Ja liczę, że Pavel da kiedyś radę wydać stabilną wersję programu Pixel, który choć płatny (sensownie), byłby nie lada konkurencją dla GIMP-a. W aktualnych betach wciąż jest praktycznie nie do użytku…
Ja tam sie nie znam na tych wszystkich jezykach, komputerowych terminach i wogole ale wiem ze jakie programy nie mialem ktore do dzialania potrzebuja javy zawsze sa wolne, takie jakies niestabilne i dziwne , nie wiem, moze to mylne odczucie
asd, a ja jeździłem kikoma różnymi daewoo i jakieś zawieszenie takie strasznie miękkie miały…
wiesz, daewoo to badziew, o tym kazdy wie … co jak co, ale mercedesa z daewoo nie porownasz … podobnie jest z programami … cos jest Lepsze i juz
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ć!
Miguel zaproponował nazwę Paint Mono, a nie Mono Paint.
Nawet URL zawiera paint-mono a nie mono-paint.