Linux za Sve forum

shrike je napisao/la: Ignoriraš kontekst o kojem govorim. Nije poanta u tome što koristiti ako ti treba jednom za seminar. Apsolutno je jasno da češ tada koristiti što je najlakše i najbrže moguće. Znači ponavljam, poanta je u tome da imaš program pisan u jeziku koji će i dalje biti aktualan za više od 10 godina, možda čak i 20-30 godina. Zašto? jer se ralno nalazim u stvarnoj tkavoj diskusiji. To prvo, onda portabilnost i onda performanse. Znači, eksplicitno ne govorim o jednokratnim upotrebama i jednostavnim stvarima. I da budem krsitalno jasan, sa pythonovim backward kompatibilnostima nisam upoznat ali sa primejrice php, ruby i java sam vidio da su neposotjeće/upitne. Također specijalno naglašavam da je ovdje i pitanje frameworka, a ne samo jezika kao takvog.

Isprike, nisam čitao raspravu od početka.
Za dugoročne projekte - treba uzeti dokazano pouzdan jezik i framework. Tu se slažem!

jurastublic je napisao/la:

nicky je napisao/la:Evo real life primjer od prije par sati:
Prvo kad su došli windowsi, kod je razdvojen na gui i ostalo. Kad je došao android, uzeli smo taj isti c kod (ostalo), i na njega dodali android gui i stvar radi identično ko na PC-u.

Pametno ste razdvojili i zato dio koda niste morali dirati. To bi vrijedilo za svaki programski jezik.
Ali što se prave portabilnosti C-a tiče, jeste li onaj Windows GUI dio koda samo jednostavno wrapali u javu kod prebacivanja na android ili ste ga morali ponovo pisati u javi (znam da je nemoguće jer "portabilnost je bitch..."). Mislim da niste. Znači, najvažnije je pametno vođenje projekta i u sklopu toga i biranje najboljih jezika za određenu zadaću u sklopu projekta.

Windows GUI nije prebacivan u javu nego je u javi napisan novi GUI. Naravno, samo oni djelovi koji su trebali od GUI-a.

nicky je napisao/la:Windows GUI nije prebacivan u javu nego je u javi napisan novi GUI. Naravno, samo oni djelovi koji su trebali od GUI-a.

Što na kraju znači da je dio te C aplikacije ipak trebalo portati. Jednostavno, nikad ne znaš što te čeka i C isto nije u tom pogledu puno bolji od ostatka jer velike C aplikacije ovise o promjenjivim third party bibliotekama, kompajlerima i ostalome isto kao i aplikacije u drugim jezicima.

Zato ne koristiš 3rd party biblioteke već svoje, kod ti je odvojen od GUI maksimalno (MVC model) a što se kompajlera tiče to jednostavno nije istina.

shrike je napisao/la:Zato ne koristiš 3rd party biblioteke već svoje, kod ti je odvojen od GUI maksimalno (MVC model) a što se kompajlera tiče to jednostavno nije istina.

Potpisujem.

shrike je napisao/la:Zato ne koristiš 3rd party biblioteke već svoje, kod ti je odvojen od GUI maksimalno (MVC model) a što se kompajlera tiče to jednostavno nije istina.

Ovo nema smisla. 3rd party biblioteke koristiš da ne bi trošio još godinu dana više vremena na pisanje svojih.
Što se kompajlera tiče, to je istina. gcc neće uvijek kompilirati bez greške VC. Keil C neće kompilirati SDCC, itd...
E da, ni gcc ponekad neće kompilirati gcc.

jurastublic je napisao/la: Ovo nema smisla. 3rd party biblioteke koristiš da ne bi trošio još godinu dana više vremena na pisanje svojih.
Što se kompajlera tiče, to je istina. gcc neće uvijek kompilirati bez greške VC. Keil C neće kompilirati SDCC, itd...
E da, ni gcc ponekad neće kompilirati gcc.

Pa čuj, ako ti je bitno jednostavno ih napišeš jer je cilj imati dugoročno stabilnu aplikaciju, što očito nečeš imati korištenjem 3rd party bibliotekama. Što se kompajlera tiče, ti si sada naveo neke neobične kompajlere i verzije. Ja govorim o ISO/IEC C99, C11 i C89 na gcc-u ili sada clang. Ne neke C verzije za mikroprocesore i slično. Također, dosta bitno, do sada svaki put kada mi je netko rekao da mu se njegov kod ne kompilira (u smisli C/C++) to je bilo jer nije bio po standardu. Evo, zadnje, lik je pisao ono što je mislio da je K&R C pa se čudio zašto mu gcc ne kompilira. U stvarnosti nije bio ni K&R C već loš C pisan u stilu tog doba koji je teško kršio sve standarde.

Da, to sam odmah shvatio, da misliš na pisanje po standardu ali ja ti kažem da većina toga u C svijetu nije po standardu napisana. Ni kompajleri se toga u cijelosti ne drže a ponekad ni ne mogu i da hoće.

ed: U stvari, te smjernice koje si naveo vrijede i za Python i daju isti rezultat. Ne možeš uspoređivati Python s frameworkom i goli C. Goli Python je otprilike isto tako otporan na vremenske nepogode kao i C.

Sada ne bih išao u programerske prakse jer je to totalno odvojena diskusija i moglo bi se štošta reći na tu temu. Ovdje ako bi se išlo sa C, defintiivno bi inzisitrao na forsiranju C11 standarda na razini kompajlera (znači ne formalno, vće da se gcc-u alje parametar da forsira c99) i korištenje stvari tipa valgrind.

@Shrike, na nekoliko mesta si ispljuvao javu ... oces da kazes da je NASA debilna institucija koja javu koristi za svemirske stanice ? Opet da napomenem, propusti kod JAVE su propusti programera a ne samog jezika ....

PHP takodje nije krs jer kada se dobro kodira nema toliko problema ... jeste da ima nekih nedostataka i to ozbiljnih ali koj jezik ih nema ... ogradjujem se od te izjave kada je u pitanju C jer verujem da C traljavo kodiran nece ni raditi -

RUBY je donekle prljav jezik iz mnogo razloga u koje ne zelim da ulazim, ali cinjenica je da je prebrz i da se moze meriti sa Pajtonom u tom smislu ....

Neko je pomenuo i hiphop - da, isprobao sam ga i php je zaista brzi, ali taj bajt kompajler ne daje ono sto C npr. vec ima ... Ako ocete akcelerirati php za to postoji milion nacina (varnish, apc, kompresori itd ...)

A ukoliko se radi o samim projektima ... treba porazmisliti naprimer o pristupu samom programiranju i projektovanju aplikacije .. Ne moze programer koj nije kreativan nikada da napravi dobar program, uvek ce biti samo fizikalac, cak iako zna 10 jezika napamet bez izostatka ...
Ovaj svet menjaju kreativci. Programeri (tehnicki deo) su na kraju same hijerarhije - sto implicira da dobar programer i ne mora napraviti dobru aplikaciju, dok kreativan programer cak i sa manje znanja samog jezika zbog same kreativnosti moze napraviti cak i inovativan projekat ...
Mene naprimer fascinira pojam ekstremnog programiranja iz koga mogu izdvojiti jedan pristup za projektovanje same aplikacije ... U pitanju je WaterFall pristup koj se najcesce primenjuje kada se radi na svemirskim stanicama i ozbiljnim projektima, dok ga neki smatraju sitnicavim i birokratskim - tj sa suvise birokratije ...


Evo jednog primera dobre prakse koriscenja slobodnih, besplatnih i "slabijih" softvera koji ne mogu raditi sa petabajtiima naprimer itd ... ali povezivanje vise takvih softvera u jednu celinu i balansiranje samih aplikacija kao i raspodela resursa itd. dovode do mnogo jakih rezultata ...

Ukoliko ovde nisam nesto dobro zakljucio ili napisao, molim iskusnije da isprave i dopune