Dlaczego C taki popularny?

dzień dobry,
muszę przyznać że bardzo interesujaca dyskusja. właśnie szukałem na sieci takiego tematu ponieważ chcę nauczyć się programować. jestem studentem politechniki na kierunku o specjalnosci elektronika i inz. komputerowa i własnie staje przed "zyciowym" ;) wyborem C czy Java. dodam tylko ze zacząłem juz nauke ASM i bardzo odpowiada mi ten jezyk a raczej mozliwosci jego wykorzystania. (dodam tylko ze jestem poczatkujacym elektronikiem i kazdy nawet najprostszy działajacy kod sprawia mi frajde) Teraz mam do was pytanie. czy opłaca mi sie rozpoczynać naukę C jesli zacząłem juz ASM, czy lepiej uczyć sie Javy?

Jeżeli jesteś na elektronice to ucz się C - do elektroniki bardziej Ci się przyda. Wszelkie mikrokontrolery programuje się właśnie w C i asmie. Java w sumie też mogła by pasować do profilu twoich studiów jezeli zająłbyś się programowaniem komórek. Najlepiej sprawdź oba i zobacz co Ci bardziej pasuje. Ale jeżeli piszesz, że asm przypadł Ci do gustu to wróże z fusów, że pewnie C też Ci przypasuje.

Krolik napisał(a)

RR napisał(a)

C, ASM jeszcze długo będą królować na miniaturowym sprzęcie, bo tak naprawdę tylko taki sprzęt jest najwyższej klasy i nikt chyba javie nie powierzy czuwania nad piecem hutniczym :). Przynajmniej ja bym z takiej pracy nie skorzystał :P

Hmm. A co powiesz na duży akcelerator cząstek w CERN? Oprogramowanie, które go monitoruje napisali w Javie [1].

Właśnie, monitoruje a nie steruje.

Krolik napisał(a)

Myślę, że skala tego rozwiązania jest na tyle duża, iż w asmie czy C bardzo ciężko byłoby to napisać przy zachowaniu odpowiedniej stabilności i bezawaryjności.

Jesteś na 100% pewien że sterowanie jest w JAVIE? Akurat też pisałem kiedyś kawałek oprogramowania dla jednego z komponentów akceleratora w Australii i zgadnij w czym było pisane? :D Zgadnij w czym była oprogramowana cała jego elektronika hrhrhrhrhrhr....

Krolik napisał(a)

Być może czuwanie nad piecem hutniczym jest prostsze...

I tu polemizowałbym. [diabel]

Witam,
Po przeczytaniu tego tematu zauważyłem, że wiele osób wypowiadających się nie ma pojęcia o tym co pisze. To jest forum przede wszystkim programistów, którzy programowanie kojarzą z komputerem klasy PC. Ludzie, przecież na świecie istnieje cała masa mikrokontrolerów oraz układów programowalnych. Bzdurą jest pisanie, że elektronika jest coraz bardziej skomplikowana, zminiaturyzowana i tania więc „C” umrze na rzecz Javy itp.
Z zawodu jestem konstruktorem elektronikiem i powiem wam, że urządzenia embedded mają tak szerokie zastosowania jak szeroki jest nasz świat. Najprostszy przykład: urządzenie monitorujące temperaturę w jakimś obiekcie, którego zadaniem jest wysyłanie przez sieć GSM informacji do bazy. Na jednej baterii musi działać 4-5lat. W takim momencie nawet do głowy nie przychodzi jakakolwiek Java. Tu musi być zastosowany super energooszczędny mikrokontroler posiadający szereg sprzętowych rozwiązań pozwalających zminimalizować pobór prądu. Programista ma za zadanie efektywnie wykorzystać te funkcje, także – jak się można domyślić - podstawą jest dogłębne poznanie budowy mikrokontrolera, przestudiowanie jego data sheet’a. Wtedy jasne staje się, że najprostszym i najefektywniejszym językiem staje się C w połączeniu z asemblerem.
A przecież takich przykładów jest cała masa: telewizor w naszym domu, komputer w samochodzie, zegarek na ręku, no po prostu full itd. Tam się Javy nie stosuje, bo nie do tego ona jest. Dziś zobaczyłem fajny projekt na elektrodzie pokazujący możliwości prostego 8 bitowego mikrokontrolera, który na pokładzie posiada 8KB (sic!) pamięci programu oraz 1KB(sic!) pamięci danych. Link: http://www.elektroda.pl/rtvforum/viewtopic.php?t=1006991
Na koniec: język „C” trzyma się naprawdę dobrze i nic nie wróży aby miałoby się to zmienić,
pozdrawiam

A ja tylko chcę zapytać, jak to jest z tą javą i od kiedy to natywnie jest wykonywana. Bo zawsze myślałem, że trzeba VM zaimplementować i nagle się okazuje, że VM Javy w Javie nie jest robione, a podobno tak dynamicznie się rozwija, więc chyba ktoś ją rozwijać musi...

Przenośność Javy, no super - jest przenośna, bo ma warstwę pośrednią. Nowe urządzenie, nowy procesor - nowa VM. A przepisanie dobrej VM jest na 100% trudniejsze od przepisania wielu wielu aplikacji, których kod mieści sie w 4KB, bo musi się w tym mieścić.

BIOS musi być w niskim, sterowniki muszą być w niskim, OS musi być w niskim, i dopiero jak to masz, to możesz o tworzeniu VM myśleć, ewentualnie o pisaniu 'jądra' systemu dla Javy, ale nie czarujmy się, to będzie kernel monolityczny, w którym fragmenty będą w niskim, albo będziesz miał mikrojądro, którego Javowe będzie używać. I dopiero teraz, jak masz 3-4 albo więcej warstw, to możesz sobie przenośny, wydajny, bezpieczny kod pisać.

Sorry, z tym nie wygrasz. Java w próżni nie działa. Ktoś jej musi środowisko stworzyć. Java była projektowana dla sprzętu, więc nie ma co patrzeć jak wyszło? No chyba jednak trzeba patrzeć na to co wyszło, a nie na to, co chciałoby się mieć - myślenie życzeniowe piękne jest, ale nieżyciowe trochę.

Bezpieczeństwo Javy - jako użytkownikowi totalnie mi zwisa, czy dostanę komunikat: "program wykonał nieprawidłową operację" czy "unhandled exception" - tak czy inaczej, coś się wyje..ło.

Marketing i sztuczny tłum - to dokładnie to samo co z Rubym, ostatnią gwiazdą - tak ofensywna i nachalna strategia mnie osobiście odstręcza, a nie zachęca. Nie lubię, gdy ktoś mi coś wciska na siłę, mimo, że wyraźnie krzyczę, że nie chcę. Zazdrość? Chyba koziołek to słowo napisał... czego zazdroszczę? Ani ja C++ nie stworzyłem, ani ty Javy żeś nie wymyślił - obaj jesteśmy 'użytkownikami' języka, nie wiem jak ty, ja na siebie patrzę bardziej jak na rzemieślnika, niż na cudowne dziecko XXI wieku. Ty masz swój ukochany język, ja też mam. Tu chodzi tylko o prośbę "dość propagandy". Jak będę chciał, to przeczytam drugi raz Thinking in Java, wierz mi - potrafię, w podstawówce mnie uczyli.

Elektronika niszowa - o lol, embedded niszowe, o lol.
btw: jeden z najbogatszych polaków dorobił się na produkucji... nakrętek do butelek na wódkę - i cały świat obsługuje (jasne... nie tylko on;) ). Podobnie z melexami - logo firmy z małego podkarpackiego miasteczka można znaleźć w każdym kraju na każdym kontynencie (inna sprawa, że firmą zarządzają idioci, i trochę się sypie, nvm). Niszowe, to nie znaczy niepotrzebne, niedochodowe, umierające - często wręcz przeciwnie - trafiasz w niszę i ustawiony jesteś do końca życia.

Tendencja - procki w górę, a programy mulą coraz bardziej... niestety też to zauważam czasami. Mam komp 3x szybszy od starego, a na dobrą sprawę to wzrostu komfortu pracy nie widzę wcale... Tego akurat Javie nie zawdzięczam, chociaż nie ma co ukrywać, i zawsze będę to powtarzał:
ile javowcy mi testów, benchmarków i mądrych skrótów nie wymienią ja będę potrafił na PC-cie rozpoznać aplikację w Javie tą samą metodą co teraz - mam w trayu wykres zużycia RAMu i CPU - i dziwnym trafem podczas używania nawet prostych tooli pisanych w Javie wykresy potrafią mi tak skoczyć, że mało czkawki nie dostają. Jako user nie trawię apletów, bo przy nich się tnę - jest to główny powód, przez który nie sięgam do tego języka jako programista.

Aplikacje www - dopóki Java siedzi na serwerze, to róbcie co chcecie, a co mi tam. Jeśli chodzi o www to do server-side nie mam wyrobionego zdania, zresztą jako dla odbiorcy jest to dla mnie 'transparentne', i czy ktoś pisze w PHP5, RoR, ASP czy innym cudzie, to mam gdzieś. Ja osobiście podniecam się obecnie tym, że JavaScript używam zarówno po stronie klienta, jak i serwera - jeden język mniej, a w dodatku dostęp do standardowego DOM już podczas generowania odpowiedzi (tak! da się i tak!)

Summary: trochę tu jeszcze podocznych wątków było, które mi się spodobały, ale już nie pamiętam, ogólnie to myśl mi się pojawia tylko taka, że jak ktoś pyta o pozycję C z w rankingu, to odpowiada się w kwestii pozycji C, a nie zaczyna reklamę, bo reklamami to już wszyscy rzygają, przynajmniej niech prywatni ludzie powstrzymają się od marketingowej papki. Koziołek - płacą ci prowizję od każdego pobranego SDK Javy, czy co? :/

Wiem, że potraktujecie to jako offtop, ale czy to tylko ja czy topic brzmi "Dlaczego C taki popularny"?

@Ranides, nie płacą choć nie... w pewnym sensie płacą, bo fabryka zarabia na rozwiązaniach robionych w Javie.

Co do natywności javy to jak na razie mamy dedykowane rozwiązanie polegające na tym, że do JVM dopisano odpowiednie fragmenty związane z obsługą sieci i filesystemu w sposób znany z np. linuxa. Działa to w ten sposób, że odpalany jest bardzo okrojony system operacyjny (linux; coś na poziomie tego z tutoriala "Piszemy system operacyjny") i na nim jako jedyny proces działa wzbogacona JVM.

Wracamy do tematu, bo mam tu przed oczyma SDJta z marca, a w nim szóstą edycję rankingu. C "spadł" o trzy pozycje i został wyprzedzony przez C#, Rubiego i Perla. Tu mam pytanie czy to nie jest tak, że rynek ma ograniczone zapotrzebowanie na C i język ten będzie, w przeciwieństwie do języków "webowych", powoli spadał aż do momentu gdy rynek nazyci się i ustabilizuje?

Bezpieczeństwo Javy - jako użytkownikowi totalnie mi zwisa, czy dostanę komunikat: "program wykonał nieprawidłową operację" czy "unhandled exception" - tak czy inaczej, coś się wyje..ło.

Nie do końca. Po unhandled exception zasoby (przynajmniej część) są zwalniane przez JVM ;)

Marketing i sztuczny tłum - to dokładnie to samo co z Rubym, ostatnią gwiazdą - tak ofensywna i nachalna strategia mnie osobiście odstręcza, a nie zachęca. Nie lubię, gdy ktoś mi coś wciska na siłę, mimo, że wyraźnie krzyczę, że nie chcę.

Gdy Java nie była do pewnych zadań dobrym językiem na pewno nie zdobyła takiej popularności. Microsoft swojego .NETa też ostro promuje ale pod względem popularności daleko mu do Javy.

Elektronika niszowa - o lol, embedded niszowe, o lol.

Ranides - elektronika w Polsce to niestety nisza, nawet było kilka tematów o tym na elektrodzie. W Polsce nie projektuje się zbyt wielu sprzętu a elektronicy po studiach zamiast mieć twórczą pracę często muszą siedzieć w serwisie.

Jako user nie trawię apletów, bo przy nich się tnę - jest to główny powód, przez który nie sięgam do tego języka jako programista.

Javowe aplety to akurat niewypał i nawet Sun się do tego przyznaje. Moim zdaniem niezbyt mądrze negować język patrząc tylko jedną technologie (niezbyt rozpowszechnioną z resztą).

Jeśli chodzi o www to do server-side nie mam wyrobionego zdania, zresztą jako dla odbiorcy jest to dla mnie 'transparentne', i czy ktoś pisze w PHP5, RoR, ASP czy innym cudzie, to mam gdzieś

No nie wiem czy by Ci było obojętne jakby ktoś wyczyścił Ci konto bankowe tyko dlatego, że portal banku był słabo zabezpieczony. A chociażby korzystając z PHP b. ciężko porządnie pozabezpieczać strony.

rnd napisał(a)

No nie wiem czy by Ci było obojętne jakby ktoś wyczyścił Ci konto bankowe tyko dlatego, że portal banku był słabo zabezpieczony. A chociażby korzystając z PHP b. ciężko porządnie pozabezpieczać strony.

Maly OT: bzdury pleciesz. Zmartwilbym sie, gdyby bezpieczenstwo moich pieniedzy opierano na technologii, a nie np. matematyce i przemyslanych algorytmach, nie sadzisz?

Zmartwilbym sie, gdyby bezpieczenstwo moich pieniedzy opierano na technologii, a nie np. matematyce i przemyslanych algorytmach, nie sadzisz?

johny_bravo - za przeproszeniem sam bzdury pleciesz :P Algorytmy trzeba w czymś zaimplementować i nawet najbardziej wymyślny algorytm nie pomoże jeżeli strona będzie podatna na chociażby SQL injection.
Mały przykład: http://www.chip.pl/arts/archiwum/n/articlear_120054.html

Np. Sql injection nie dotyczy php a sposobu wykonania zapytan. Rownie dobrze mozna sie tak samo nadziac w ASP.NET czy JSP. To, ze dana technologia uprzedza czasem programiste nie zwalnia tego ostatniego od myslenia i wiedzy 'co sie dzieje'.
//edit
Banki sa kiepskim przykladem, bo wiekszosc ich slabosci opiera sie wlasnie na kiepskim algorytmie autoryzacji transakcji (np. tylko login i haslo) - stad bledy sa niezalezne od wykorzystywanych technologii.

A SQL injection w Javie to się nie da? :>

Owszem, Java ma dosyć istotne zalety w zakresie bezpieczeństwa nad C, ale dotyczy to raczej błedów typu buffer overflow, off-by-one itp. No i w Javie jak coś się wywala, to jednak łatwiej zlokalizować źródło błędu, a w C to jeden fałszywy delete, a błąd występuje ileś tysięcy taktów procka później.

No i na banki bym się tak nie powoływał, bo to nie zawsze dobry przykład. Kumpel był konsultantem w banku i opowiadał mi jak to 2 systemy zintegrowali za pomocą FTPa, a później "zgubiło"* im się 3 mln zł [glowa].

*) na szczęście nietrwale - odzyskali z logów.

Oczywiście, że się da. Ale jednak J2EE jest bardziej uporządkowany od PHP i trudniej w nim strzelić głupi błąd. No i PHP może pozazdrościć Javie acegi ;)

To, ze dana technologia uprzedza czasem programiste nie zwalnia tego ostatniego od myslenia i wiedzy 'co sie dzieje'.

Pewnie, że nie zwalnia. Ale ludzie są tylko ludźmi i zawsze będą popełniać błędy (nawet Ci najlepsi/najbardziej przezorni). Dlatego potrzebne są mechanizmy, które będą maksymalnie utrudniały popełnianie błędów.

o lol, ale się offtop robi :D Ale ...
co ma SQL injection do PHP do jasnej anielki?! Co to, w PHP niby filtrować I/O się nie da za pomocą funkcji tekstowych z libc, wyrażeń regularnych POSIX i z Perla na dodatek? I myśleć, co się wysyła do bazy, a nie słać wszystkiego na pałę? Co to, nie da się określić uprawnień skryptom, safe_mode, listowania zakazanych funkcji, odciąć PHP od systemu plików innych niż te na www? A obsługi bazy trzymać w oddzielnych modułach i na tyle restrykcyjnie jej napisać, że jak coś się 'wywali' to po prostu nic się nie będzie dało zrobić, bo nie będzie uprawnień, dostępu do OS i API z modułu? Hello, ja rozumiem że PHP jest zwalone, sam to powtarzam, ale niech nikt nie gada bzdurów, że ktoś się włamie do zarządzania bankiem, bo warstwa prezentacji napisana jest w PHP. Przecież skrypty www powinny mieć tak mało pola do manewru, jak się tylko da, a i tego pilnować ostro. A bezpieczeństwa nie tylko one powinny pilnować, ale i również (a może przede wszystkim) sam wewnętrzny system bankowy. A i mechanizm sesji www można identycznie zwalić w każdym innym systemie, bo to akurat mało ma wspólnego z PHP, a więcej z http, który do 'sesjowania' wymyślony nie został.

//please, wywalcie, ale za 24 godziny, albo sam jutro po południu wywalę...
dopisane: ok, nie tylko ja się dałem "wciągnąć w maliny", to może poczekamy, do czego ten offtop w offtopie się rozrośnie ;)

Bosze, ale się ludzie przyczeplili do tego SQL injection :p A to był tylko przykład, że same matematyczne wzorki nie wystarczą do zabezpieczenia aplikacji. Realne przykłady podałem w linku strone wcześniej. Dla mnie koniec tematu.

Realne przyklady podane w linku potwierdzaja, ze liczy sie algorytm zabezpieczenia, nie jezyk implementacji. Dla mnie tez koniec OT. Juz sie nie bede wtracal.

Krolik napisał(a)

Owszem, Java ma dosyć istotne zalety w zakresie bezpieczeństwa nad C, ale dotyczy to raczej błedów typu buffer overflow, off-by-one itp. No i w Javie jak coś się wywala, to jednak łatwiej zlokalizować źródło błędu, a w C to jeden fałszywy delete, a błąd występuje ileś tysięcy taktów procka później.

moze ja gowniarz jestem ale

1. do zadan programisty przede wszystkim nalezy MYSLENIE(!) a nie klepanie wciemno i opieranie sie na kompilatorze :P skoro koder zjeb** to nic nie pomoze :P poza tym obsluga pamieci w c/c++ ma dwa oblicza, z jednej strony mozna tworzyc naprawde cuda za pomoca rzutowania wskaznikow i struktur z drugiej trzeba wiedziec co sie robi bo wlasnie bedzie dupa :P
2. jakby nie bylo to ochrona pamieci w jabie jest okupiona czasem dzialania, a to czasami jest niedopuszczalne
3. w kazdej lepszej ksiazce do c/c++ pisza aby uzywac asercji no wiec jak komus sie nie chce to nie win jezyka
4. w c++ sa wyjatki, ten mechanizm mozna polaczyc ze sledzeniem stosu jezeli programista dopilnuje aby kazdy nefralgiczny fragment kodu byl sprawdzany wtedy blad zostanie wykryty Od razu z pelnym przebiegiem programu

podsumowujac: nie mozna winic jezyka za bledy programisty :P

// dopisane tak btw:
Sory ale odnosze wrazenie ze wielu z Was chce byc strasznie trendi, nie mam w sumie nic do javy ba twierdze nawet ze to niezle rozwiazanie w miejsce php ale kurde caly swiat sie na javie nie opiera, poza tym to ze jest popularna nie wynika czasem z tego ze najczesciej firmy produkuja oprogramowanie dla innych firm w wiekszosci uslugowych? skoro wydajnosc ani efektywnosc nie maja znaczenia to faktycznie mozna isc po bandzie i uzywac jezykow n^n poziomu :P
ktos tu wyzej nadmienil ze moc obliczeniowa procesorow wzrosla przez ostatnie lata o cale rzedy wielkosci a dalej cos sie tnie zacina, a jak sie pusci taki eclipse to po prostu zal i rozpacz.
a juz zupelnie mnie krew zalewa jak widze gdy ludzie sie biora za pisanie duzych ogolnodostepnych projektow np: w pythonie i twierdza ze to przecieŻ jest szybkie...

PS. w c nie ma delete ;p

Jeszcze odnośnie SQL injection: http://www.webappsec.org/projects/whid/list_class_sql_injection.shtml . Pierwszy przykład to zhakowany bank. Więc johny, zastanów się może najpierw zanim kogoś oskarżysz o bzdure.

bo warstwa prezentacji napisana jest w PHP

Jak to nazywazs, ta warstwa prezentacji jest najbardziej narażona na ataki. Poza tym bzdurą jest, że PHP ogranicza się tylko warstwy prezentacji. Nie wiem czy słyszałeś o MVC ale tam tylko jedna literka służy do prezentacji.

Dzizyz, rnd... Czy Ty czytasz te litereki, ktore piszemy, jakos inaczej, czy ja pisze cos czego nie rozumiem? Pisalem, ze bezpieczenstwo banku POWINNO opierac sie na sensownych algorytmach autoryzacji i nie POWINNO zalezec od jezyka, w jakim jest napisane. To, ze ktos zhakowal bank za pomoca sql injection to nie wina PHP tylko programista byl dupa. Sql injection jak i inne techniki (XSS chocby) nie sa zalezne od jezyka - zadzialaja na kazdym mozliwym systemie, nawet uzywanym przez NASA i NATO i inne cuda jesli tylko programista na to pozwoli.

Tobie zapewne chodzi o to, ze w przypadku Javy nie martwisz sie o to co kto wpisuje w zapytanie, bo zapytania sa parametryzowane, jak powiedzmy w ADO.NET. Rownie dobrze mozesz w php uzywac PDO i parametryzowac zapytania i tez problem z glowy. Mozesz sprawdzac co kto podal w formularzu i nie skladac na slepo zapytan i tez bedzie ok. Jezyk NIE MA nic do rzeczy. Zarowno w Javie, php jak i .Net sluza do tego odpowiednie klasy i od programisty zalezy czy z nich skorzysta czy bedzie robil to recznie. W drugim przypadku w kazdym z jezykow naraza sie na dziure w systemie.

To sa podstawy zabezpieczen. Artykul, ktory zaprezentowales mowi o dalszym poziomie - czyli zlozeniu loginu, hasla, tokenow, smstokenow, itp tak by ogolny algorytm autoryzacji wlasciciela i transakcji byl bez dziur. Jak mi zaraz napiszesz, ze w Javie jest klasa, ktora to robi to padne (bo taki jest na razie Twoj tok myslenia).

A wypowiedz Ranidesa masakrycznie wyrwales z kontekstu, wiec no comment.

EOOT.

Poza tym jest jedna stara prawda: Kto umie c++ ten bez problemu nauczy sie kazdego innego jezyka. (No moze oprocz Prologa i LISPa ;) )

moze ja gowniarz jestem ale

1. do zadan programisty przede wszystkim nalezy MYSLENIE(!) a nie klepanie wciemno i opieranie sie na kompilatorze :P skoro koder zjeb** to nic nie pomoze :P poza tym obsluga pamieci w c/c++ ma dwa oblicza, z jednej strony mozna tworzyc naprawde cuda za pomoca rzutowania wskaznikow i struktur z drugiej trzeba wiedziec co sie robi bo wlasnie bedzie dupa :P

Ok, wszyscy się zgadzamy, że myślenia nie zastąpi się żadną super technologią.

1. jakby nie bylo to ochrona pamieci w jabie jest okupiona czasem dzialania, a to czasami jest niedopuszczalne

Nie jest okupiona bardziej niż w C i C++, przynajmniej jeśli porównasz ją z typowym programowaniem
z użyciem malloc/free oraz new/delete. W przypadku aplikacji, które alokują dużo małych obiektów, model zarządzania pamięcią z odśmiecaniem jest wydajniejszy. Oczywiście zaraz padnie standardowy argument o możliwości napisania sobie własnych specjalizowanych alokatorów, pul obiektów itp. Ok, zgadzam się, tylko że takie cuda kosztują zdecydowanie więcej czasu programistów (czyt. zwiększają koszty projektu) i wymagają większych umiejętności, a sumaryczny zysk wydajności jest stosunkowo niewielki. W większości projektów taki wysiłek się nie opłaca (może z wyjątkiem gier).

1. w kazdej lepszej ksiazce do c/c++ pisza aby uzywac asercji no wiec jak komus sie nie chce to nie win jezyka
2. w c++ sa wyjatki, ten mechanizm mozna polaczyc ze sledzeniem stosu jezeli programista dopilnuje aby kazdy nefralgiczny fragment kodu byl sprawdzany wtedy blad zostanie wykryty Od razu z pelnym przebiegiem programu

Wiesz, to nie jest do końca tak. Tzn. masz rację - są mechanizmy, zarówno w C++ jak i w Javie, które należy stosować, i które pomagają uniknąć błędów. Z drugiej strony w żadnym z języków nie istnieją mechanizmy gwarantujące bezbłędność wykonania programu. Sprawa rozbija się jednak o szczegóły, dosyć istotne przy zespołowym pisaniu kodu. Wyjątki C++ nie ochronią Cię nigdy przed złym/złośliwym kodem, który nie Ty napisałeś. Zilustruję to przykładem.

Powiedzmy, że masz do napisania Bardzo Ważny Moduł (BWM), który nie może się wysypać. Moduł ten opcjonalnie korzysta z drugiego Źle Napisanego Modułu (ZNM), który czasem działa, a czasem nie. W każdym razie ZNM był pisany przez programistów z innej firmy, którzy wyjechali do Irlandii i ślad po nich zaginął, a nikt nie rozumie za bardzo ich kodu. Teraz, jak się zabezpieczysz przed wywaleniem BWM w C++? Jedyne co możesz zrobić, to wyłapać wszystkie wyjątki rzucane przez ZNM. Ale tu jest problem: ZNM może wcale nie rzucić żadnego wyjątku, a cichaczem spowodować uszkodzenie sterty, zamazać Twoje dane itp. Wtedy BWM nie ma żadnych szans na obronę, może się wywalić dużo później po powrocie z obsługi ZNM, w miejscu jak najbardziej poprawnym i niczemu nie winnym. W Javie czy .NET masz gwarancję, że jeśli wrócisz z obsługi ZNM, stan maszyny wirtualnej / pamięci jest spójny. Masz przynajmniej szansę wyświetlić użytkownikowi grzeczny komunikat: "Chwilowo nieczynne, pretensje prosimy kierować do programistów ZNM" i aplikacja działa dalej, jakby nic się nie stało.

Dlatego jestem zdania, że Java nie chroni przed wszelkimi błędami / dziurami, ale eliminuje kilka klas bardzo upiornych i trudnych do debugowania błędów, które mogą wystapić w C/C++. SQLInjection czy XSS jest o tyle błahym problemem, że można go wykrywać np. statyczną analizą kodu / audytem oraz istnieją PROSTE praktyki gwarantujące niepopełnienie takiego błędu.

// dopisane tak btw:
Sory ale odnosze wrazenie ze wielu z Was chce byc strasznie trendi, nie mam w sumie nic do javy ba twierdze nawet ze to niezle rozwiazanie w miejsce php ale kurde caly swiat sie na javie nie opiera, poza tym to ze jest popularna nie wynika czasem z tego ze najczesciej firmy produkuja oprogramowanie dla innych firm w wiekszosci uslugowych? skoro wydajnosc ani efektywnosc nie maja znaczenia to faktycznie mozna isc po bandzie i uzywac jezykow n^n poziomu :P

Mają znaczenie. Ale w zastosowaniach serwerowych Java jest językiem tej samej klasy szybkości co C/C++. LISP obecnie też wykonuje się tak samo szybko jak kompilowane C. W desktopach jest tylko problem powolnego startu, ale przy dzisiejszym sprzęcie, powoli traci to na znaczeniu.

ktos tu wyzej nadmienil ze moc obliczeniowa procesorow wzrosla przez ostatnie lata o cale rzedy wielkosci a dalej cos sie tnie zacina, a jak sie pusci taki eclipse to po prostu zal i rozpacz.

Mnie się Eclipse za pierwszym razem odpala 8 sekund, za drugim 6. 8 s stracone 1 lub 2 razy dziennie, to nie wiem, czy jest już sens płakać?

a juz zupelnie mnie krew zalewa jak widze gdy ludzie sie biora za pisanie duzych ogolnodostepnych projektow np: w pythonie i twierdza ze to przecieŻ jest szybkie...

Bo w wielu projektach jest wystarczająco szybki, mimo że jest jakieś 30-60 razy wolniejszy niż Java. A koduje się zdecydowanie szybciej niż w C.

PS. w c nie ma delete ;p

#define delete free

:-P

Dzizyz, rnd... Czy Ty czytasz te litereki, ktore piszemy, jakos inaczej, czy ja pisze cos czego nie rozumiem?

Ok to przeczytam jeszcze raz.

Maly OT: bzdury pleciesz. Zmartwilbym sie, gdyby bezpieczenstwo moich pieniedzy opierano na technologii, a nie np. matematyce i przemyslanych algorytmach, nie sadzisz?

Na technologii również się opiera. Jak myślisz czemu naprawde duże systemy pisze się w Javie czy .NET a nie np. w C ? Przecież wg Ciebie technologia nie ma znaczenia więc dobry programista mógłby pisać w C i by się nic nie posypało.

Tobie zapewne chodzi o to, ze w przypadku Javy nie martwisz sie o to co kto wpisuje w zapytanie, bo zapytania sa parametryzowane, jak powiedzmy w ADO.NET.

Nie, nie o to. Jak już pisałem w PHP bardzo łatwo zrobić bajzel w kodzie a to sprzyja różnym błędom.

Jak mi zaraz napiszesz, ze w Javie jest klasa, ktora to robi to padne (bo taki jest na razie Twoj tok myslenia).

Akurat 'ogólnego algorytmu' nie ma, ale przejrzyj sobie biblioteke acegi i powiedz co z tego ma PHP. Może znajdziesz odpowiedź czemu do niektórych rzeczy lepsza jest Java.

Ogólny sens wypowiedzi Ranidesa też rozumiem. Znowu truizmy, że można napisać dobry kod w PHP i zwalić program w Javie. Ja się z tym zgadzam. Ale może jeszcze raz powtórze pytanie: dlaczego spora część systemów opartych komunikujących się przez web jest oparta na Javie, chociaż javowe serwery aplikacji mają większe wymagania ? Gdybyś znał odpowiedź na te pytania pewnie nie było by całej tej dyskusji. No i oczywiście nie dlatego, że java jest "trendy" tudzież "jazzy" :D

Java w tym przypadku jest o tyle lepsza, ze ma biblioteki i tyle. Sam jezyk jest tak samo gietki jak php (bo przeciez w obydwu mozesz pisac w pelni obiektowo). W Javie bibliotek jest wiecej - nie mowiac juz o standardowo dostepnych klasach - stad szybciej sie w niej pisze i nie trzeba wielu rzeczy pisac samemu. Ot, cala przewaga Javy w podanych przez Ciebie zastosowaniach.

Zreszta sam sie potknales:

przejrzyj sobie biblioteke acegi i powiedz co z tego ma PHP

Biblioteka(acega) a jezyk(php) to dwie rozne rzeczy, czyz nie? Pytanie powinno brzmiec - czy w php jest taka biblioteka jak w Javie acega.

A wracajac do tematu i kwestii, ktora poruszyl EgonOlsen - moim pierwszym na serio jezykiem byl wlasnie c, a pozniej c++ i rzeczywiscie duzo latwiej pozniej przejsc do javy, php, czy c# wlasnie.

Java w tym przypadku jest o tyle lepsza, ze ma biblioteki i tyle. Sam jezyk jest tak samo gietki jak php (bo przeciez w obydwu mozesz pisac w pelni obiektowo). W Javie bibliotek jest wiecej - nie mowiac juz o standardowo dostepnych klasach - stad szybciej sie w niej pisze i nie trzeba wielu rzeczy pisac samemu. Ot, cala przewaga Javy w podanych przez Ciebie zastosowaniach.

Pusty śmiech mnie bierze jak to czytam. Fakt, java ma 'tylko' biblioteki lepsze od PHP. Tyle, że siła języków tkwi właśnie w bibliotekach, frameworkach oraz ogólnie ilości (i jakości!) kodu napisanego w danym języku. Jeżeli by patrzeć tylko na język to pewnie wygrał by Scheme albo Lisp tylko co z tego wynika ? :P

Ech... nie ma w zasadzie czego komentowac, ale jeszcze napisze. Widzisz - ja rozrozniam jezyk od calej reszty, a Ty to wiazesz - stad nasze roznice w pogladach. Dla mnie jezyk to skladnia, gramatyka i wspierane paradygmaty, dla Ciebie to rowniez dostepne IDE, dzialajace systemy w roznych firmach, biblioteki, itp. Stad caly czas zaznaczalem, ze jezyk (w mojej definicji) nie ma znaczenia. Znaczenie ma wygoda - czyli cala ta otoczka wlasnie. Ja tez wole pisac w C# niz w c++ dlatego, ze jest mi wygodniej. Mam dokumentacje pod reka, szeroka game klas na zawolanie, darmowe srodowisko, itp. Ale porownujac jezyki porownuje to co oferuje C# a co C++, a nie .NET'a z c++. Taka roznica.

Krolik napisał(a)

W przypadku aplikacji, które alokują dużo małych obiektów, model zarządzania pamięcią z odśmiecaniem jest wydajniejszy. Oczywiście zaraz padnie standardowy argument o możliwości napisania sobie własnych specjalizowanych alokatorów, pul obiektów itp. Ok, zgadzam się, tylko że takie cuda kosztują zdecydowanie więcej czasu programistów (czyt. zwiększają koszty projektu) i wymagają większych umiejętności, a sumaryczny zysk wydajności jest stosunkowo niewielki. W większości projektów taki wysiłek się nie opłaca (może z wyjątkiem gier).

no napisalem ze czasami niedopuszczalne chodzi mi o np: waskie gardla w projekcie itp, kiedy najwazniejszym i biznesowym czynnikiem jest czas wykonania zadania. Oczywiscie pisanie wyspecjalizowanych alokatorow najczesciej mija sie z celem, bo podnosi rozmiar kodu a wiec i czas potencjalnego ladowania itp a przede wszystkim zmniejsza elastycznosc projektu.

Krolik napisał(a)

Wyjątki C++ nie ochronią Cię nigdy przed złym/złośliwym kodem, który nie Ty napisałeś. Zilustruję to przykładem.

Hmm moim zdaniem to do managera projektu nalezy ocena z jakich narzedzi nalezy skorzystac i jakie sa potencjalne koszty z ich uzycia, czy nie jest tak ze skoro dany gotowy fragment kodu przysporzy tylu potencjalnych problemow to nie jest taniej napisac go wewnetrznie w firmie, slowem koszt kontroli bledow moze przewyzszyc ponowe "wywazenie drzwi" :P

Krolik napisał(a)

W Javie czy .NET masz gwarancję, że jeśli wrócisz z obsługi ZNM, stan maszyny wirtualnej / pamięci jest spójny. Masz przynajmniej szansę wyświetlić użytkownikowi grzeczny komunikat: "Chwilowo nieczynne, pretensje prosimy kierować do programistów ZNM" i aplikacja działa dalej, jakby nic się nie stało.

Dlatego java nadaje sie do biznesowych projektow, gdybys chcial taki motyw zrobic w aplikacji medycznej czy do np: kontrolowania jakiegos procesu technicznego to szybko musialbys zmienic profil dzialalnosci na produkcje kapsli do butelek :P

Krolik napisał(a)

Dlatego jestem zdania, że Java nie chroni przed wszelkimi błędami / dziurami, ale eliminuje kilka klas bardzo upiornych i trudnych do debugowania błędów, które mogą wystapić w C/C++.

Dlatego wlasnie dobre opanowanie zwlaszcza C++ trwa tak dlugo, a w kilkuset stronicowych ksiegach opisuje sie metodyke i podchodzenie do bledow :P

Krolik napisał(a)

Mają znaczenie. Ale w zastosowaniach serwerowych Java jest językiem tej samej klasy szybkości co C/C++. LISP obecnie też wykonuje się tak samo szybko jak kompilowane C. W desktopach jest tylko problem powolnego startu, ale przy dzisiejszym sprzęcie, powoli traci to na znaczeniu.
Mnie się Eclipse za pierwszym razem odpala 8 sekund, za drugim 6. 8 s stracone 1 lub 2 razy dziennie, to nie wiem, czy jest już sens płakać?

Nie chodzilo mi o takie prozaiczne zeczy jak ladowanie programu, chodzi mi o to ze od paru lat klasa zlozonosci problemow pozostaje taka sama, natomiast wymagania sa czasami wrecz niebotyczne. Najlepiej widac to wlasnie w obecnie pisanych grach.

Krolik napisał(a)

Bo w wielu projektach jest wystarczająco szybki, mimo że jest jakieś 30-60 razy wolniejszy niż Java. A koduje się zdecydowanie szybciej niż w C.

Twierdze ze kazdy jezyk nadaje sie do czegos innego i nie ma jezyka idealnego. Idealnym bylby zapewne kompilator komentarzy ale takich narzedzi nie ma. Zgodze sie ze im wyzszy poziom tyl latwiejsze jest kodowanie ale im wyzej od procesora tym ciezej mu to przetlumaczyc i tym wolniejszy jest to proces. Jak sie tworzy projekt to nalezalo by wiedziec ktore narzedzie do czego sie nadaje.

rnd napisał(a)

Na technologii również się opiera. Jak myślisz czemu naprawde duże systemy pisze się w Javie czy .NET a nie np. w C ? Przecież wg Ciebie technologia nie ma znaczenia więc dobry programista mógłby pisać w C i by się nic nie posypało.

Wlasnie, naprawde duze, java ma w tym punkcie taka przewage ze mozna ja zaliczyc to jezykow kompilowanych (mniejsza o vm), poza tym jest kontrola typow, w php nigdy nie wiadomo co jest na wejsciu wiec potencjalnych zagrozen jest znacznie wiecej, z drugiej strony male projekty tworzy sie w php znacznie szybciej, stad tez wynika popularnosc tej technologi, ogromna wiekszosc witryn to proste serwisy. A w C sie tego nie pisze bo poco skoro od strony uzytkownika koncowego roznica miedzy C a Java w tym przypadku bedzie wlasciwie zadna, natomiast koszt napisania tego w C znacznie wiekszy niz w Javie. Ktos kiedys napisal ze nie strzela sie z armaty do muchy :P

rnd napisał(a)

No i oczywiście nie dlatego, że java jest "trendy" tudzież "jazzy" :D

W srodowisku uczelnianym, czyli tym ktore ma niby wyksztalcic przyszlych programistow w tym mnie, java jest zwyczajnie popularna, troche to owczy ped przypomina wszyscy wszedzie chca jave choc czesto sami nie wiedza dlaczego :P

Krolik napisał(a)

#define delete free

:-P

 delete(cos) to nie ta konstrukcja :P

W srodowisku uczelnianym, czyli tym ktore ma niby wyksztalcic przyszlych programistow w tym mnie, java jest zwyczajnie popularna, troche to owczy ped przypomina wszyscy wszedzie chca jave choc czesto sami nie wiedza dlaczego :P

W środowisku akademickim jest całkiem pouparna bo łatwiej się nauczyć programowania na Javie niż w C. Druga kwestia, że znając Jave łatwiej znaleźć prace (a chyba uczelnia właśnie ma przygotować pracy). W ogóle ja bym się cieszył na Twoim miejscu, u mnie na uczelni tylko C i C++ ;)

@Johny - była poruszona kwestia, że Java bardziej nadaje się do systemów bankowych niż PHP więc niby jak można uwzględniać w tym przypadku tylko język ? Naprawde, zastanów się dobrze zanim zaczniesz oskarżać kogoś o gadanie bzdur.

johny_bravo napisał(a)

Ech... nie ma w zasadzie czego komentowac, ale jeszcze napisze. Widzisz - ja rozrozniam jezyk od calej reszty, a Ty to wiazesz - stad nasze roznice w pogladach. Dla mnie jezyk to skladnia, gramatyka i wspierane paradygmaty, dla Ciebie to rowniez dostepne IDE, dzialajace systemy w roznych firmach, biblioteki, itp. Stad caly czas zaznaczalem, ze jezyk (w mojej definicji) nie ma znaczenia. Znaczenie ma wygoda - czyli cala ta otoczka wlasnie. Ja tez wole pisac w C# niz w c++ dlatego, ze jest mi wygodniej. Mam dokumentacje pod reka, szeroka game klas na zawolanie, darmowe srodowisko, itp. Ale porownujac jezyki porownuje to co oferuje C# a co C++, a nie .NET'a z c++. Taka roznica.

W pelni sie zgadzam, ci "javovcy" zachowuja sie jak jakas sekta ;) klapki na oczy i do przodu z ta java ;)
Nie wiedza chyba ze sa tysiace problemow do rozwiazania ktorych java po prostu sie nie nadaje.

Hmm, normalnie olalbym ten temat cieplym moczem, ale cos mam nastroj na flejma jak za starych, dobrych czasow, wiec pÓÓÓÓki jeszcze nikt tego tematu nie zamknol:

Co do pierwszego offtopa pt. "w czym sie programuje piece hutnicze i inne akcelaratory czastek":
Hmm, moze ja mam jakies stare informacje, ale z tego co ja wiem to powazne projekty tego typu nie sa pisane ani w C, ani w Javie, ani nawet w Pythonie jeno w Forthu: http://forth.gsfc.nasa.gov/

A co do drugiego, pt. "kto ma naj..." ekhm... "ktory jezyk programowania jest najlepszy":
<flame> Tu tez powiem, ze ani C, ani Java, jeno (Common) Lisp! Odkad dzieki paru osobom z tego forum poznalem ten jezyk wlasciwie nie mialem ochoty programowac w czymkolwiek innym. Jave bije na leb dynamiczna typizacja (w ogole kto to wymyslil zeby robic jezyk wysokiego poziomu ze statyczna typizacja? Moze to zdaje egzamin w jezykach typu C++ (ktory jest wysokopoziomowy tylko tak na krzywy ryj), ale nie w prawdziwych jezykach wysokiego poziomu jakim stara sie byc Java), Pythona miazdzy mozliwoscia kompilacji, wszystko co sie rusza i na drzewo nie ucieka wgniata w glebe makrami, kompilacja w trakcie dzialania, biezpieczenstwem (o tym za chwile) oraz prostota skladni, a co za tym idzie, czytelnoscia kodu (moze i to jest dyskusyjne, ale ja wole jeden rodzaj nawiasow i jeden sposob wywolywania wszelakich funkcji czy operatorow od uzywania wszystkich mozliwych znakow specjalnych na klawiatorze i swietych wojen na temat tego gdzie umiescic otwierajacy nawias) W sumie ze znanych mi jezykow tylko Forth dorownuje Lispowi w tych aspektach (poza bezpieczenstwem ;))

Czemu nikt w takim razie w nim nie programuje? No coz, jak to jest nikt:
http://wiki.alu.org/Industry_Application
to ja tez chcialbym byc nikim.
Jeszcze jeden ciekawy przyklad uzycia tego jezyka, zwiazany ze wspomnianym bezpieczenstwem:
http://www.flownet.com/gat/jpl-lisp.html (glownie chodzi mi o czesc '1994-200 Remote Agent')
Jest to jedyny znany mi jezyk, ktory takie cos umozliwia: jak podczas dzialania zdazy sie np. niewylapany wyjatek, to zamiast wypiac sie na uzytkownika (!) i wykrecic sie jakims banalym komunikatem, kompilator Lispa uruchamia REPLa, gdzie mozna program samemu naprawic przedefiniowujac jedna funkcje czy dwie, albo nawet zapisac stan programu i uruchomic pozniej, po znalezieniu pomocy. Oczywiscie, ze to nic milego, ale zawsze lepsze to, niz crash. Nie tylko na sprzecie za miliony dolcow.

Nie zrozumcie mnie zle, nie mowie, ze ten jezyk nie ma wad: np. najwieksza jest koniecznosc targania za soba kompilatora przez skonczone juz programy. Jest tez nieco latwiej napisac w nim okropny kod jesli proboje w nim programowac kiepski programista (taka cena duzych mozliwosci). No i nie mozna zapomniec o tym, ze po stycznosci z nim ciezko sie przestawic na cokolwiek innego ;) </flame>

Ghostek napisał(a)

<flame> Tu tez powiem, ze ani C, ani Java, jeno (Common) Lisp! Odkad dzieki paru osobom z tego forum poznalem ten jezyk wlasciwie nie mialem ochoty programowac w czymkolwiek innym. Jave bije na leb dynamiczna typizacja (w ogole kto to wymyslil zeby robic jezyk wysokiego poziomu ze statyczna typizacja? Moze to zdaje egzamin w jezykach typu C++ (ktory jest wysokopoziomowy tylko tak na krzywy ryj), ale nie w prawdziwych jezykach wysokiego poziomu jakim stara sie byc Java), Pythona miazdzy mozliwoscia kompilacji, wszystko co sie rusza i na drzewo nie ucieka wgniata w glebe makrami, kompilacja w trakcie dzialania, biezpieczenstwem (o tym za chwile) oraz prostota skladni, a co za tym idzie, czytelnoscia kodu (moze i to jest dyskusyjne, ale ja wole jeden rodzaj nawiasow i jeden sposob wywolywania wszelakich funkcji czy operatorow od uzywania wszystkich mozliwych znakow specjalnych na klawiatorze i swietych wojen na temat tego gdzie umiescic otwierajacy nawias) W sumie ze znanych mi jezykow tylko Forth dorownuje Lispowi w tych aspektach (poza bezpieczenstwem ;))

Makra w CLu są wrecz katastrofalnie nadużywane - widzę dla nich uzasadnione użycie jedynie w loop/format + definiowanie funkcji/metod/klas/itd. Cała reszta to po prostu pomyłka, omijanie złego designu na o wiele niższym poziomie.
Niesamowity MOP, świetny (ale 'trochę' niedopracowany) CLOS, fantastyczny obiektowy system wyjątków/zdarzeń... koncepcje utopione w wielkim bagnie. Istnienie funkcji w języku z takim systemem obiektowym to w ogóle pomyłka; brak użycia OO w standardzie (poza CLOS oczywiście) to już katastrofa (najlepiej widać to chyba po coerce... coś co idealnie działałoby jako metoda ze specjalizerem eql jest funkcją!...).

Ten język jest spójny tylko na poziomie MOP (który też jest małym bałaganem, ale ma ogromne możliwości).

Najlepszym językiem nazwać go na pewno nie można; ma wiele zalet (to co wyżej + dynamiczne typowanie, makra (ale nie nadużywane!), sexpy (nie jestem pewien, no ale ok)), ale brak mu tak podstawowych rzeczy jak np. pattern matching* czy leniwość.

• można to oprzeć na MOP, przynajmniej do pewnego momentu; składnia sexpów jednak średnio na to pozwala (czytelność).

Jeszcze taka mała uwaga - długość kodu. Te długaśne nazwy szybko stają sie dość denerwujące, szczególnie gdy zaczyna brakować ci miejsca na kolejne wcięcie...

Jest to jedyny znany mi jezyk, ktory takie cos umozliwia: jak podczas dzialania zdazy sie np. niewylapany wyjatek, to zamiast wypiac sie na uzytkownika (!) i wykrecic sie jakims banalym komunikatem, kompilator Lispa uruchamia REPLa, gdzie mozna program samemu naprawic przedefiniowujac jedna funkcje czy dwie, albo nawet zapisac stan programu i uruchomic pozniej, po znalezieniu pomocy. Oczywiscie, ze to nic milego, ale zawsze lepsze to, niz crash. Nie tylko na sprzecie za miliony dolcow.

Erlang?

Nie zrozumcie mnie zle, nie mowie, ze ten jezyk nie ma wad: np. najwieksza jest koniecznosc targania za soba kompilatora przez skonczone juz programy.

To jest opcja kompilatora, jedyne miejsce gdzie ten kompilator jest potrzebny to eval (więc w konsekwencji repl); to już zależy od wymagań projektu.

Jest tez nieco latwiej napisac w nim okropny kod jesli proboje w nim programowac kiepski programista (taka cena duzych mozliwosci). No i nie mozna zapomniec o tym, ze po stycznosci z nim ciezko sie przestawic na cokolwiek innego ;)

Polecam ci Haskella. Ma o wiele węższy zakres zastosowań niż CL, ale do pisania algorytmów (wejście -> obróbka -> wyjście) jest niezastąpiony - automatyczne dzielenie programu na wątki, STM, leniwość, typy algebraiczne... różnica w ekspresywności między CL mniej więcej taka jak między CL a ANSI C (w tych zastosowaniach które wymieniłem).
(nie nadaje się za to zupełnie do pisania czegoś nie-funkcyjnego - 'sławne' monady, świetne narzędzie do pisania imperatywnego kodu funkcyjnego...).

P.S kiedyś myślałem tak samo jak ty ;)