[ stray @ 23.03.2017. 13:58 ] @
Pozdrav ljudi otvaram ovu temu jer jer bih zeleo da ucim programiranje i prekvalifikujem se u programera.

Naime, zivim u inostranstvu gde se programiranje dosta placa, i sanse za posao su ogromne. Nikad nisam imao dodirnih tacaka sa programiranjem, ali sam spreman da opet pocnem da ucim i ako treba opet upisem fakultet kako bi naucio programiranje.

Trenutno imam 27 godina, i voleo bih da svi koji misle da me mogu posavetovati da to i urade. Koje knjige da kupim i sa kojim programskim jezikom da pocnem da se bavim?

Zeleo bih da napomenem da sam vec visoko obrazovan i da se vec bavim "ozbiljnim" poslovima, ali po mojoj licnoj proceni IT je buducnost.

Hvala svima koji zele da pomognu
[ jablan @ 23.03.2017. 14:57 ] @
http://norvig.com/21-days.html

(Nažalost, i srpski i hrvatski prevod ne rade kako treba.)
[ stray @ 23.03.2017. 15:24 ] @
@jablan

Dobar imput, samo nije dao nikakve konkretne smernice koju literaturu da pocnem da izucavam itd. Nasao sam ovde jednu "skolu" koja traje dve godine i MUST je da se posle 6 meseci zaposlis u IT branshi da bi bio u mogucnosti da dobijes diplomu. Koliko je to realno?
[ Rapaic Rajko @ 24.03.2017. 09:10 ] @
stray, ti ces bolje znati sa tom lokalnom skolom kako stoje stvari. Da se nauci za 2 godine, moguce je.

Ali dacu ti dobronameran savet. Programiranje jeste dobro placeno, ali to ima svoju cenu - jako je tezak posao. Kako mi rece davno jedna doktorka na medicini rada: 'programirati je teze nego zemlju kopati' (mada nema dodirnih tacaka ). Tako da. u ovom poslu o(p)staju samo oni koji VOLE programiranje kao zanat (ubrajam tu sebe). Svi koji udju u IT zarad plate, relativno brzo (5-10 godina) se izduvaju i traze 'stranputice' - prelaze u management i slicno. Programiranje je, otprilike, nesto kao pismeni iz matematike 5-6 sati SVAKI DAN; naravno da nije sve matematika, ali potrebna koncentracija je tu negde. Pa ti vidi.

Pozz i svako dobro!
[ since1986BC @ 24.03.2017. 09:46 ] @
Bolji naslov teme bio bi 'wanna be programmer'
Naslov moze i da se gugla.

@jablan, dzaba prevodi - engleski u programiranju je required / mandatory.
I Jablan i Rajko su dobili po +1 za postove.
[ djoka_l @ 24.03.2017. 10:13 ] @
Više puta sam pisao na ovu temu, ali kako mi se čini da si ozbiljan, neće mi biti teško da napišem još jednom.

Prvo, postoji jak razlog zašto je programiranje dobro plaćen posao - ne može svako da bude programer, već je potrebno značajno obrazovanje. Nije to slučaj samo sa programiranjem, recimo kod tebe u CH su verovatno i lekari dobro plaćeni, pa ti ne pitaš kako da postaneš lekar za 6 meseci (ili dve godine). Nije nemoguće, ali je teško. Jedan moj poznanik, koji je bio uspešan programer, u jednom momentu je odlučio da postane advokat, završio pravni fakultet, dao pravosudni ispit i sada mlati pare kao advokat. Kao što vidiš, moguće je ali nema uspeha preko noći.

Zato je velika greška ako misliš da za posao programera postoji neka prečica i da se po tom pitanju razlikuje od neke druge struke koja zahteva univerzitetsko obrazovanje. Naravno, programiranje nije medicina, ali nije nešto što može da ti u kratkom roku donese rezultate.

Ja vidim neke četiri oblasti znanja koja su potrebna programeru:

1. Opšte znanje iz matematike. Matematika nije presudna, ali ljudi koji su dobri u matematici obično su i dobri u programiranju. Obe oblasti zahtevaju sličan način razmišljanja - sposobnost da se problem razloži na jednostavnije probleme (to je generalni inženjerijski pristup rešavanju svakog problema) i da se ti sitniji problemi reše na sistematski način.
2. Opšte znanje iz računarstva - algoritmi, strukture podataka, teorija informacija, računarske mreže, operativni sistemi, kompajleri, baze podataka
3. Programski jezici (da jezici, a ne jezik). Jezici su samo sredstvo da se ideje i algoritmi pretoče u kompjuterski kod.
4. Domensko znanje. Recimo, ako praviš sistem za knjigovodstvo, jako je poželjno da znaš kako knjigovodstvo funkcioniše, ako praviš sistem za on-line prodaju, lepo bi bilo da znaš malo o marketingu, kartičarskom poslovanju itd.

Pa sad, šta kupiti.
Za matematiku, postoje udžbenici koji obrađuju ono što je bitno za programera, oblasti kao što su binarna logika, kombinatorika i verovatnoća, brojni sistemi. Ozbiljni kursevi (na primer na Coursera.org) obavezno daju i neke linkove na literaturu iz matematike koja je potrebna u kursu.
Za opšte znanje iz računarstva biblija je The Art of Computer Programming - ne kažem da moraš da imaš, ali bolje knjige nećeš naći. Poenta nije da znaš sve moguće algoritme napamet, ali će pomoći da ne izmišljaš toplu vodu svaki put kada sedneš da nešto kodiraš.
Što se jezika tiče, za bilo koji ozbiljan projekat nećeš proći samo sa jednim jezikom. Recimo, da želiš da napraviš e-commerce sajt. Trebaće ti prvo da dobro savladaš HTML i CSS. Pa će ti onda biti potrebno da napraviš front-end. Za to će ti trebati poznavanje nekog frameworka, recimo Bootstrap 3, a možda će biti potrebno nešto drugo, recimo poznavanje JavaScript jezika i Polymer ili Angular. Polymer koristi JavaScript, dok Angular koristi TypeScript - što je u principu JavaScript koji liči na C#, pa bi bilo zgodno da znaš i C#. Pa će onda biti potrebno da se napiše serverski deo. A tu će možda biti Java. I to ne "gola" Java nego će se koristiti Spring Boot framework.
Naravno, u nekom momentu će ti biti potrebno da malo proučiš OAuth 2 protokol. Pa će komponente aplikacije da komuniciriaju preko AMQP. Naravno, JSON i YAML su obavezni. Pa onda SQL, ODBC ili JDBC. Možda ti neće trebati SQL ako koristiš neki ORM, ili recimo Linq.

Mogu ovako da ređam skraćenice do sutra. Poenta je da i ljudi koji su dugo u ovim vodama morajiu stalno da uče nove stvari i da ne postoji "univerzalni kit" znanja koji nekoga čini programerom.
[ Rapaic Rajko @ 24.03.2017. 11:35 ] @
Sad me je djoka_I gornjim postom (+1) naveo da se zamislim.

Verujete li da je bilo situacija da na pitanje 'da li sam koristio to i to (skracenica)' nisam bio siguran: poznato mi, al opet... i tek kad sednem za masinu i probam, skontam da sam to koristio, apsolvirao, drljao dok je trebalo, i na kraju - potisnuo u zaborav. Toliko je ucenja 'u hodu' u ovom poslu, da se vise pitam gde je tu smisao. Ili sam ja mozda nerealan, posle 20+ godina programiranja... ko bi ga znao.

Pozz
[ zwischenberger @ 24.03.2017. 12:16 ] @
Citat:
djoka_l:
Više puta sam pisao na ovu temu, ali kako mi se čini da si ozbiljan, neće mi biti teško da napišem još jednom.

Prvo, postoji jak razlog zašto je programiranje dobro plaćen posao - ne može svako da bude programer, već je potrebno značajno obrazovanje. Nije to slučaj samo sa programiranjem, recimo kod tebe u CH su verovatno i lekari dobro plaćeni, pa ti ne pitaš kako da postaneš lekar za 6 meseci (ili dve godine). Nije nemoguće, ali je teško. Jedan moj poznanik, koji je bio uspešan programer, u jednom momentu je odlučio da postane advokat, završio pravni fakultet, dao pravosudni ispit i sada mlati pare kao advokat. Kao što vidiš, moguće je ali nema uspeha preko noći.

Zato je velika greška ako misliš da za posao programera postoji neka prečica i da se po tom pitanju razlikuje od neke druge struke koja zahteva univerzitetsko obrazovanje. Naravno, programiranje nije medicina, ali nije nešto što može da ti u kratkom roku donese rezultate.

Ja vidim neke četiri oblasti znanja koja su potrebna programeru:

1. Opšte znanje iz matematike. Matematika nije presudna, ali ljudi koji su dobri u matematici obično su i dobri u programiranju. Obe oblasti zahtevaju sličan način razmišljanja - sposobnost da se problem razloži na jednostavnije probleme (to je generalni inženjerijski pristup rešavanju svakog problema) i da se ti sitniji problemi reše na sistematski način.
2. Opšte znanje iz računarstva - algoritmi, strukture podataka, teorija informacija, računarske mreže, operativni sistemi, kompajleri, baze podataka
3. Programski jezici (da jezici, a ne jezik). Jezici su samo sredstvo da se ideje i algoritmi pretoče u kompjuterski kod.
4. Domensko znanje. Recimo, ako praviš sistem za knjigovodstvo, jako je poželjno da znaš kako knjigovodstvo funkcioniše, ako praviš sistem za on-line prodaju, lepo bi bilo da znaš malo o marketingu, kartičarskom poslovanju itd.

Pa sad, šta kupiti.
Za matematiku, postoje udžbenici koji obrađuju ono što je bitno za programera, oblasti kao što su binarna logika, kombinatorika i verovatnoća, brojni sistemi. Ozbiljni kursevi (na primer na Coursera.org) obavezno daju i neke linkove na literaturu iz matematike koja je potrebna u kursu.
Za opšte znanje iz računarstva biblija je The Art of Computer Programming - ne kažem da moraš da imaš, ali bolje knjige nećeš naći. Poenta nije da znaš sve moguće algoritme napamet, ali će pomoći da ne izmišljaš toplu vodu svaki put kada sedneš da nešto kodiraš.
Što se jezika tiče, za bilo koji ozbiljan projekat nećeš proći samo sa jednim jezikom. Recimo, da želiš da napraviš e-commerce sajt. Trebaće ti prvo da dobro savladaš HTML i CSS. Pa će ti onda biti potrebno da napraviš front-end. Za to će ti trebati poznavanje nekog frameworka, recimo Bootstrap 3, a možda će biti potrebno nešto drugo, recimo poznavanje JavaScript jezika i Polymer ili Angular. Polymer koristi JavaScript, dok Angular koristi TypeScript - što je u principu JavaScript koji liči na C#, pa bi bilo zgodno da znaš i C#. Pa će onda biti potrebno da se napiše serverski deo. A tu će možda biti Java. I to ne "gola" Java nego će se koristiti Spring Boot framework.
Naravno, u nekom momentu će ti biti potrebno da malo proučiš OAuth 2 protokol. Pa će komponente aplikacije da komuniciriaju preko AMQP. Naravno, JSON i YAML su obavezni. Pa onda SQL, ODBC ili JDBC. Možda ti neće trebati SQL ako koristiš neki ORM, ili recimo Linq.

Mogu ovako da ređam skraćenice do sutra. Poenta je da i ljudi koji su dugo u ovim vodama morajiu stalno da uče nove stvari i da ne postoji "univerzalni kit" znanja koji nekoga čini programerom.


Djoka, odlično si to sintetizovao. Moje nedavno zapažanje je da dosta ljudi relativno lako postaju testeri i da je potražnja za njima velika. Koliko se tester razlikuje od "normalnog" programera i koliko je od programerske baze znanja potrebno testeru?
[ dejanet @ 24.03.2017. 14:15 ] @
Knjiga "The Art of Computer Programming ", ako djoka_l misli na Knuth-a, je overkill.
[ djoka_l @ 24.03.2017. 15:06 ] @
Citat:
zwischenberger:
Djoka, odlično si to sintetizovao. Moje nedavno zapažanje je da dosta ljudi relativno lako postaju testeri i da je potražnja za njima velika. Koliko se tester razlikuje od "normalnog" programera i koliko je od programerske baze znanja potrebno testeru?


Danas se dosta pažnje posvećuje automatskom testiranju. Agilne tehnike programiranja (recimo TDD - test driven development) zahtevaju da se testiranje piše zajedno sa kodiranjem i često broj linija koda u testovima prevazilazi broj linija koda u samom softveru. Zbog toga se zahteva da sada programeri budu i testeri. Naravno, postoje i inženjeri koji se isključivo bave testiranjem, konfigurišu kompletna test okruženja i prave gomilu simulacija koje programer koji piše unit testova uopšte i ne testira. Tester programer se, u principu, ne razlikuje mnogo od programera, ali su neki ljudi bolji od drugih u tome.
Na kraju uvek ostaje i ljudsko testiranje gde je presudno domensko znanje, a programersko znanje može da bude samo plus. Recimo, kod nas u firmi dosta ljudi koji rade testiranje su došli iz biznisa - radili su u nekoj od firmi koje koriste naš ili sličan softver i znaju suštinu posla. Takvi ljudi su često radoznali i pre ili kasnije nauče SQL, pa onda direktno u bazi prate rezultat svog rada u aplikaciji. Razlika između takvog testera i nekog ko ne zna ništa o programiranju je slična kao razlika kada kod automehaničara dođe vikend vozač i profesionalni vozač. Onaj prvi će reći - nešto mi lupa ispod haube, a drugi će reći nešto tipa - pri 2300 obrtaja u 4. brzini čuje se neuobičajen zvuk iz turbine a motor reaguje neuobičajeno sporo na dodavanje gasa.
[ zwischenberger @ 24.03.2017. 20:16 ] @
Ja sam stekao utisak (površan) da je testiranje rudarskiji posao od programiranja, jer sam čuo da se često on outsourcuje, pa je meni testiranje više lopatanje - ne moraš da si kreativan i da smišljaš rešenja za problem nego da buljiš u kod i tražiš tuđe greške (banalizujem). Zbog toga mi se učinilo da za brz ulazak u IT testiranje može da bude "prečica"
[ balavi @ 24.03.2017. 20:31 ] @
@ djoka_l

vala objasnio si ga i mutav bi shvatio, taman si mi dao neke smernice ...
svaka čast bate ...


ovaj, testiranje ili QA, koliko vidim to je sada novo a traže ga dosta
gledan smerove na fakultetima, nigde to nema
jel ima neki kurs negde za to ...
mislim, gledao neku literaturu, sve neka teorija , ništa praktično
mene to zanima, nekako više mi glava preteže na tu stranu ...

vidim da programer može biti i QA, kako kaže se ovde, , jel dovoljno da naučiš programiranje,
pa posle , u kodu, tražiš suprotno od onog što si naučio?
[ Branimir Maksimovic @ 24.03.2017. 21:16 ] @
Eh bas pocetnik na C++ forumu ;p
[ Zlatni_bg @ 24.03.2017. 21:21 ] @
Samo djoki da se javim da je dobio + od mene i iskazem postovanje i ovako. Kao iole iskusan programer sam prosao sve te stvari i potpisujem njegov post i svojim imenom.

Kljucna stvar je da precica nema.
[ Zlatni_bg @ 24.03.2017. 21:23 ] @
Citat:
balavi:
@ djoka_l

vala objasnio si ga i mutav bi shvatio, taman si mi dao neke smernice ...
svaka čast bate ...


ovaj, testiranje ili QA, koliko vidim to je sada novo a traže ga dosta
gledan smerove na fakultetima, nigde to nema
jel ima neki kurs negde za to ...
mislim, gledao neku literaturu, sve neka teorija , ništa praktično
mene to zanima, nekako više mi glava preteže na tu stranu ...

vidim da programer može biti i QA, kako kaže se ovde, , jel dovoljno da naučiš programiranje,
pa posle , u kodu, tražiš suprotno od onog što si naučio?


U nekim vecim firmama Q&A sam video da rade vrlo neiskusne osobe koje samo testiraju razvijen softver na dnevnom nivou i prijavljuju bagove, probleme pri radu i slicno. Mislim da cak nije potrebno programersko znanje za tako nesto, osoba koja te bira za posao ce vise gledati tvoje rezonovanje od svega ostalog.
[ Shadowed @ 24.03.2017. 22:13 ] @
Citat:
zwischenberger: ne moraš da si kreativan i da smišljaš rešenja za problem nego da buljiš u kod i tražiš tuđe greške (banalizujem).

Tester nikad (ili gotovo nikad) nema pristup kodu. Ne proverava on kod vec funkcionisanje aplikacije.
Cak i ako pravis unit testove, sto vec spada u programiranje, nemas pristup kodu vec pozivas odredjene delove.

Kad kazem da nemas pristup, ne mislim da fizicki nemas (mada je to cesto slucaj) vec da se testiranje ne bavi samim kodom vec funkcinalnoscu.

Pregledanje tudjeg koda se zove code review i ne rade ga testeri vec drugi programeri, obicno jednako ili vise iskusni od onog ko je pravio taj kod.


Citat:
Zlatni_bg: U nekim vecim firmama Q&A sam video da rade vrlo neiskusne osobe koje samo testiraju razvijen softver na dnevnom nivou i prijavljuju bagove, probleme pri radu i slicno. Mislim da cak nije potrebno programersko znanje za tako nesto, osoba koja te bira za posao ce vise gledati tvoje rezonovanje od svega ostalog.

To je slucaj zato sto je testiranje obicno cisto manuelno testiranje pa se u nedostatku stvarno strucnog kadra uzimaju ljudi po principu "snaci ce se, nije to bas toliko komplikovano". A cesto i nije :)

Edit:
Za neki osnovni QA, programiranje nije neophodno. Ali je vrlo pozeljno da znas npr. osnovni xml (u novije vreme i json) i sql. Razlog je sto ces cesto trebati neke config fajlove podesavati da bi video rezultat tog podesavanja. Takodje, kao sto je neko pomenuo primer, trebace ti da u sql bazi vidis kakve je podatke napravila aplikacija i da li su oni ispravni.

Medjutim, za napredniji QA je izvesno programersko znanje potrebano jer se mnogi testovi sada automatizuju pa je pravljenje raznih skripti vrlo korisno.
[ balavi @ 24.03.2017. 22:14 ] @
@Zlatni_bg

da, u pravu si za testere, to sam i ja čuo
ali onda naiđem na oglas za

- Test Automation Engineer
- Quality Assurance Engineer

pa mi Engineer u imenu mi asocira da to mora biti neko ko je iznad
testera i da mora da ima debelo znanje ...

[ Zlatni_bg @ 24.03.2017. 22:31 ] @
E jeste Shadowed, toga sam se setio, XML je naveden bio kao zahtev...
[ Branimir Maksimovic @ 25.03.2017. 00:53 ] @
Za te skripte i HTML/XML i ne treba znanje programiranja, to moze svaki skript kidi da odradi... koriscenje gotovih frameworka i to, ne treba nista posebno znati... sto se tice znanja iz domena to ti treba jedino ako soliras... pa nema strucnjaka u datom domenu iz firme.. kolko god sam radio uvek je bilo strucnjaka iz date oblasti koji su mi objasnili sta i kako. Osnovne stvari u programiranju se nauce za metar dana ako je jezik lak. tipovi, petlje i uslovi te pozivi funkcija. Neko dublje razumevanje nije potrebno za pocetak rada.
[ Zlatni_bg @ 25.03.2017. 05:31 ] @
Jasta. Ja sam sa prvom ozbiljnom web aplikacijom za rad sa nekim proizvodima (necu imenovati ovde) i generisanjem faktura, profaktura, 100 nekih gluposti za koje nisam cuo sa 18 godina, pa potom naplatom preko PP i jos nekih servisa, morao vise da se informisem oko toga kako funkcionise naplata firme i ucim ono sto bi neko na ekonomiji recimo ucio nego sto mi je PHP i ostalo bilo problem :) Problemi freelancinga. Ali danas kako nas ubise indijci slaba vajda od istog, bar u web programiranju.
[ Shadowed @ 25.03.2017. 10:54 ] @
Citat:
Branimir Maksimovic: Za te skripte i HTML/XML i ne treba znanje programiranja

Za xml ti ne treba znanje programiranja nego ti treba osnovno znanje xml-a za testiranje.
Za pisanje skripti i automatizaciju testova ti treba osnovno znanje programiranja i tog jezika u kojem to radis.
[ Panta_ @ 29.03.2017. 07:36 ] @
Citat:
Pozdrav ljudi otvaram ovu temu jer jer bih zeleo da ucim programiranje i prekvalifikujem se u programera.

Trenutno imam 27 godina, i voleo bih da svi koji misle da me mogu posavetovati da to i urade.

Zeleo bih da napomenem da sam vec visoko obrazovan i da se vec bavim "ozbiljnim" poslovima, ali po mojoj licnoj proceni IT je buducnost.

Hvala svima koji zele da pomognu


Prijavi se u SNS skolu programiranja, tu ces najlakse i najbrze (3 meseca) da se prekvalifikujes u programera ili bilo sta drugo iz oblasti IT-a. A, imaces i starije i "iskusnije" kolege od kojih ces moci da ucis.

Citat:
Od stotinu njih, 22 je starosti od 22 do 25 godina, 62 kandidata je od 26 do 35 godina starosti, dok je 16 kandidata starijih od 36 godina. Najstariji učesnik ima 56 godina.


100 NAJBOLJIH Odabrani prvi polaznici za prekvalifikacije u IT sektoru
[ balavi @ 29.03.2017. 15:11 ] @
ostavite temu bez mešanja politike

gde odem , učlani se u ovo u ono, političati ovo ono ne rade samo kradu, nakrali se ne misle na narod, ovi se nakrali, oni ... sendvičari .... botovi ....

ne moram to i ovde da čitam i da me smara ... taman krenula tema lepo, javlja se fin i pametan narod, kad dođe neko sa tipom komentara kao na blicovom sajtu
kada se komentariše dnevno politička scena

ništa ne može da prođe bez politike pa i ovo,

a ti panto znaš da prednost imaju SNS-ovci i njihovi sendvičari ...

zahebi molim te


[ Branimir Maksimovic @ 29.03.2017. 16:18 ] @
Ja zaista ne znam nikog ko je fakultetski obrazovan ko se nije lako presaltovao na programiranje. Mislim na ove sto su studirali (elektro)tehniku. Ne mogu danas da zamislim fakultet a da ne nauci bar osnove programiranja. To je danas osnovna pismenost.
[ Rapaic Rajko @ 30.03.2017. 08:10 ] @
Ja, s druge strane, imam kolegu iz gimnazije koji je doktorant matematike, i koji je pre 15-ak godina pokusao da nauci C zarad nekog projekta oko tv box-a. Kad sam ga zadnji put pitao za to (5-6 godina kasnije), projekat je bio 'na ledu'. Nema pravila.
[ Shadowed @ 30.03.2017. 08:43 ] @
Citat:
Branimir Maksimovic: Ja zaista ne znam nikog ko je fakultetski obrazovan ko se nije lako presaltovao na programiranje.

Znam ih ja dosta. Mnogi od njih su nakon neuspelog ulaska u programerski posao otisli u menadzere i testere :]
[ Andreja Dulovic @ 30.03.2017. 09:33 ] @
Nista gore od dev menadzera koji nije tehnicki potkovan.
[ Branimir Maksimovic @ 30.03.2017. 10:30 ] @
Rajko, nisam mislio sad C i embedded ili neko low level programiranje. Za skriptanje i Javu i to sam mislio. Nesto sto zahteva poznavanje hardvera i pogotovo C zahteva disciplinu i znanje koje opet trazi godine ucenja. Recimo iako programiram od 1983. trebalo mi je jedno 5 godina da naucim dobro C++ od 1992. A iznajmljivan sam kao C ekspert vec 1994 ;)
[ keepgoing @ 30.03.2017. 13:00 ] @
@Rapajic
Ne cini ti se da je drugar imao vaznije stvari na listi prioriteta?

Sta je po misljenju ekipe dobar menadzer?
[ Rapaic Rajko @ 30.03.2017. 13:27 ] @
Citat:
keepgoing: @Rapajic
Ne cini ti se da je drugar imao vaznije stvari na listi prioriteta?


Poznajuci ga, nije to gurnuo u zapecak; jednostavno je zapelo. Setih se da sam u startu ponudio pomoc, ali nije me potrazio.
Cinjenica je da programiranje ne lezi svakome.
[ Andreja Dulovic @ 30.03.2017. 13:47 ] @
Citat:
keepgoing:
Sta je po misljenju ekipe dobar menadzer?


Neko ko se brine da tim ima sve sto im treba da rade (cisti zahtevi, jasan put odluke, itd), poznaje tempo i nacin rada svakog clana tima, cesto pita za feedback, ume da stvori odnos poverenja sa klijentom ali i da kaze "ne" kad je potrebno, i drzi u glavi celu strukturu proizvoda/buzeta, itd. Onako generalno, najvaznija osobina bi bila integritet i sposobnost da zaista tehnicki razume projekat.
[ keepgoing @ 30.03.2017. 14:01 ] @
"Ne lezi svakom programiranje" - to je toliko uopsteno da ne vidim smisao iza toga.
Isto kao i "Programiranje je tesko".

@Rapajic
Mislim, kad je nesto vazno, koristis sva raspoloziva sredstva. Kad nije, onda odmahnes rukom i kazes: "mnja".
[ DusanSukovic @ 30.03.2017. 18:13 ] @
Citat:
djoka_l:
Recimo, da želiš da napraviš e-commerce sajt. Trebaće ti prvo da dobro savladaš HTML i CSS. Pa će ti onda biti potrebno da napraviš front-end. Za to će ti trebati poznavanje nekog frameworka, recimo Bootstrap 3, a možda će biti potrebno nešto drugo, recimo poznavanje JavaScript jezika i Polymer ili Angular.
.



Izvint'e gospon Djoka, ali da li za ovo treba bistriti zivotno delo Donalda Knutha, obnoviti ili ako se ne zna i nauciti integrale, plus algoritmi?
[ DusanSukovic @ 30.03.2017. 18:14 ] @
Citat:
Rapaic Rajko:
Ja, s druge strane, imam kolegu iz gimnazije koji je doktorant matematike, i koji je pre 15-ak godina pokusao da nauci C zarad nekog projekta oko tv box-a. Kad sam ga zadnji put pitao za to (5-6 godina kasnije), projekat je bio 'na ledu'. Nema pravila.



Po Djokinoj teoriji onda svi odlicni matematicari su i odlicni programeri? :-D
[ DusanSukovic @ 30.03.2017. 18:16 ] @
Citat:
Zlatni_bg:
Samo djoki da se javim da je dobio + od mene i iskazem postovanje i ovako. Kao iole iskusan programer sam prosao sve te stvari i potpisujem njegov post i svojim imenom.

Kljucna stvar je da precica nema.



Znaci procitao si Donalda Knutha odmah cim si poceo uciti programiranje?
[ DusanSukovic @ 30.03.2017. 18:18 ] @
Citat:
keepgoing:
"Ne lezi svakom programiranje" - to je toliko uopsteno da ne vidim smisao iza toga.
Isto kao i "Programiranje je tesko".

@Rapajic
Mislim, kad je nesto vazno, koristis sva raspoloziva sredstva. Kad nije, onda odmahnes rukom i kazes: "mnja".



Finta je u motivaciji, ako mislis da se domognes para dobrih na brzaka, tesko onda. Jedino ako ti lezi u 1 ujutro da juris neki bug :-D
[ djoka_l @ 30.03.2017. 23:11 ] @
Citat:
DusanSukovic:
Izvint'e gospon Djoka, ali da li za ovo treba bistriti zivotno delo Donalda Knutha, obnoviti ili ako se ne zna i nauciti integrale, plus algoritmi?


1. Nisam pomenuo integrale, čak sam i nabrojao oblasti matematike potrebne programeru.
2. Nemam knjigu The Art... (samo neke delove u kopijama), ali imam gomile knjiga koje pokrivaju većinu stvari koje je Knuth stavio u knjigu.
3. Izvinet gospon Dušane, ali šta Vas kvalifikuje kao eksperta za IT edukaciju? Ovo pitam samo na osnovu napisanog na ovom forumu, prošao sam kroz 26 stranica Vaših postova i osim dve čisto programerske teme u kojima ste učestvovali (i pri tom napravili greške) nisam video ništa drugo. Uzimate za pravo da učestvujete u svakoj diskusiji koja se bavi učenjem programiranja, ali ništa od toga ne videsmo na forumu. Sa druge strane, ja sam svoju IT stručnost pokazao dosta na ovom forumu, pa čak i ako sam slučajno pogodio temu, kako to da se moje mišljenje poklapa sa sadržajem većine ozbiljnih informatičarskih kurikuluma?
[ DusanSukovic @ 31.03.2017. 06:05 ] @
Citat:
djoka_l: 1. Nisam pomenuo integrale, čak sam i nabrojao oblasti matematike potrebne programeru.
2. Nemam knjigu The Art... (samo neke delove u kopijama), ali imam gomile knjiga koje pokrivaju većinu stvari koje je Knuth stavio u knjigu.
3. Izvinet gospon Dušane, ali šta Vas kvalifikuje kao eksperta za IT edukaciju? Ovo pitam samo na osnovu napisanog na ovom forumu, prošao sam kroz 26 stranica Vaših postova i osim dve čisto programerske teme u kojima ste učestvovali (i pri tom napravili greške) nisam video ništa drugo. Uzimate za pravo da učestvujete u svakoj diskusiji koja se bavi učenjem programiranja, ali ništa od toga ne videsmo na forumu. Sa druge strane, ja sam svoju IT stručnost pokazao dosta na ovom forumu, pa čak i ako sam slučajno pogodio temu, kako to da se moje mišljenje poklapa sa sadržajem većine ozbiljnih informatičarskih kurikuluma?



Nisam se proglasio ekspertom za IT edukaciju niti definitivno to jesam. Gresim kao i svi ljudi na svetu. Samo ovako sa skromnim iskustvom vidim da nisi pedagog u oblasti, moguce je da imas veliko znanje u IT oblasti, ali pedagogija ti nije bas jaca strana IMHO.
Na kojem je univerzitetu kod nas "The Art of Computer Programming" deo curriculuma?
Podsecas me na profesora matematike iz jedne provincijalne gimnazije koji na kontrolnom testu dao ucenicima 4 zadatka da rese, gde su svi pali test, da bi posle na diskusiji o ta cetiri zadatka valjda 2 casa na tabli mrljao samo jedan :-D Taj je lik generacijama ucenika zgadio matematiku do kraja zivota :-D E btw, jesi procitao "Art of Computer Programming" od pocetka do kraja ? Za kraj, sta sam pogresio u tim dvema cistim programerskim temama?


Pozdrav,

Dusan

[ Rapaic Rajko @ 31.03.2017. 12:04 ] @
Citat:
keepgoing: "Ne lezi svakom programiranje" - to je toliko uopsteno da ne vidim smisao iza toga.
Isto kao i "Programiranje je tesko".

@Rapajic
Mislim, kad je nesto vazno, koristis sva raspoloziva sredstva. Kad nije, onda odmahnes rukom i kazes: "mnja".


Hocu da kazem da programiranje trazi specifican nacin razmisljanja; potrebne su godine rada da bi se to izbrusilo. Cak i posle ucenja ('suvog') C-a, sledi ucenje/razumevanje koncepta OOP-a. Pa kad se na to nadoveze konkurentno programiranje (multithreading) itd.itd. ... lista je podugacka.

P.S. Ako ne znas sta je 'suvi' C, OOP i multithreading - dalja diskusija je bespredmetna (bez uvrede ).

P.P.S. Prezivam se Rapaic, bez 'j'
[ keepgoing @ 31.03.2017. 13:04 ] @
@Rajko
Izvini, to "j" sam verovatno pretocio iz "Rajko" :)

Izreke tipa "...potrebne su godine rada da bi se to izbrusilo" nekako podsecaju na "special snowflake" sindrom ;).

@Andreja Dulovic
Hvala na odgovoru.

Bilo bi super kada bi jos neko dao odgovor na pitanje "sta je dobar menadzer?".

@stray
Part-time na ZHAW nije skup a ni pretezak pa probaj :)
1000 foruma nije nista u poredjenju s licnim iskustvom.





[ Rapaic Rajko @ 03.04.2017. 09:02 ] @
Citat:
keepgoing: @Rajko
Izreke tipa "...potrebne su godine rada da bi se to izbrusilo" nekako podsecaju na "special snowflake" sindrom .


[ mwac @ 04.04.2017. 08:10 ] @
Postovanje ljudi, vidim da ima dosta kurseva koji uz neke fine cifre obećavaju da će vas naučiti programiranju, koliko je to realno za neki peridod od pola god ?
[ mwac @ 04.04.2017. 08:10 ] @
I da li neko može da preporuči koja je programerska "školica" dobra u NS ?
[ jablan @ 04.04.2017. 09:36 ] @
Citat:
mwac:
Postovanje ljudi, vidim da ima dosta kurseva koji uz neke fine cifre obećavaju da će vas naučiti programiranju, koliko je to realno za neki peridod od pola god ?

Zameni "programiranju" sa npr. "finski jezik", pa proceni sam.
[ Skakawac13 @ 04.04.2017. 12:14 ] @
Svi jezici se sastoje od slova(kodova),naucis slova tj. azbuku,pa krenes da ucis reci pa da sklapas recenice...proste,prosto prosirene,itd...kad to naucis mozes samostalno da krenes u kombinaciju slova,reci ,recenica ,tekstova(metafora)...iskoristis potencijal mozga da razume tj. dekodira nove kodove zavisno koji programski jezik ili jezike ucis jer su svi povezani i onda ce ti biti razumljivo i naucices,samo-motivacija,rad,rad,rad i sve je to moguce. 😆

Potencijal svog intelekta ne potcenjuj ,iznenadices se sta sve moze.
Ja sam upravo krenuo na it ,php web development i kad hoces to i mozes.
[ DusanSukovic @ 04.04.2017. 15:11 ] @
Citat:
mwac:
I da li neko može da preporuči koja je programerska "školica" dobra u NS ?



Ima ona sto je pre imala saradnju sa Levi9. Posto sam imao predavanja na Zapadu i u njoj, mogu da kazem da je na kvalitet na nivou. Predavanja rade profesori sa NS Uni. Imas osnovni (bio sam na ovom da obnovim gradivo ali sam bio pogubljen nekim drugim privatnim problemima, ali su mi rekli kapiram stvari i da mogu da idem dalje) i napredni kurs, kad ta dva zavrsis mislim da 99 % dolazis u obzir za sljaku da pocnes da radis, ne treba ti na ovom stadiju "The Art Of Programming" ;-) Izvini Djoka
[ DusanSukovic @ 04.04.2017. 15:17 ] @
Evo web sitea :-)

http://aleph.rs/osnoveprogramiranja/


Sigurno je jos neko ovde na forumu bio u ovoj skoli, pa neka iznese utiske, da ne ispadne da sam pristrasan :-)
[ djoka_l @ 05.04.2017. 11:47 ] @
Evo mog primera: sa 16 godina sam pomislio da želim da postanem programer, ali nisam ništa znao o tome. Sa 17 sam dobio prvi kompjuter i sve mi je postalo jasnije. Danas, 34 godine kasnije i dalje učim. Trenutno su mi otvorene tri knjige u pdf-u (DevOps, Ansible, Docker).

Kada sam, u jednom momentu, 5 godina nakon fakulteta, napravio rekapitulaciju ispalo je da od konkretnih stvari koje sam naučio na faksu, koristim sam dve stvari i dalje, a sve ostalo što radim sam naučio posle fakulteta.
[ djoka_l @ 05.04.2017. 12:01 ] @
Da to objasnim drugim rečima - posle 6 meseci kursa bićeš bolji programer od većine onih koji su imali kurs od 5 meseci, ali lošiji od skoro svih koji su posvetili više od 7 meseci u tome. A konkurencija za posao će ti biti klinci koji dve ili četiri godine studiraju, a programirnjem se bave od 3 razreda srednje, pa iza sebe imaju po 5 ili više godina iskustva.

Ili zamisli da sada kreneš da učiš da sviraš gitaru/harmoniku/klavir. Moguće je da ćeš da se pojaviš na Pinku, ali je pitanje da li je to za 6 meseci ili ne...
[ DusanSukovic @ 06.04.2017. 17:08 ] @
Citat:
djoka_l:
Evo mog primera: sa 16 godina sam pomislio da želim da postanem programer, ali nisam ništa znao o tome. Sa 17 sam dobio prvi kompjuter i sve mi je postalo jasnije. Danas, 34 godine kasnije i dalje učim. Trenutno su mi otvorene tri knjige u pdf-u (DevOps, Ansible, Docker).

Kada sam, u jednom momentu, 5 godina nakon fakulteta, napravio rekapitulaciju ispalo je da od konkretnih stvari koje sam naučio na faksu, koristim sam dve stvari i dalje, a sve ostalo što radim sam naučio posle fakulteta.




Pa promeni se dosta na polju tehnologije za 32 godine :-)


[ DusanSukovic @ 06.04.2017. 23:03 ] @
Citat:
djoka_l:
Da to objasnim drugim rečima - posle 6 meseci kursa bićeš bolji programer od većine onih koji su imali kurs od 5 meseci, ali lošiji od skoro svih koji su posvetili više od 7 meseci u tome. A konkurencija za posao će ti biti klinci koji dve ili četiri godine studiraju, a programirnjem se bave od 3 razreda srednje, pa iza sebe imaju po 5 ili više godina iskustva.

Ili zamisli da sada kreneš da učiš da sviraš gitaru/harmoniku/klavir. Moguće je da ćeš da se pojaviš na Pinku, ali je pitanje da li je to za 6 meseci ili ne...



Djoka, sto dekuraziras coveka? Koliko znam, nije pitao kako da bude neurohirurg?
[ stray @ 16.04.2017. 21:06 ] @
Ufff promenio sam e-mail, nisam ni skontao da mi ne stizu odgovori na temu. Izvinjavam se na tome.

Hvala svima na odgovorima, hvala vam mnogo jer ste mi dali odgovor koji sam u neku ruku i zeleo da cujem a to je da je moguce, naravno sa velikim trudom, ali sta je inace u zivotu lako...

Od objavljivanja post-a radio sam dosta na ovoj temi, i dosta sam se informisao i kontaktirao par programera itd.

Sastavio sam neku strategiju, budite slobodni da je kritikujete, dodate imput i feedback da date.

Sledece nedelje kontaktiracu Uni SG ili Uni ZH(ZHAW) da upisem ekonomsku informatiku, buduci da imam bachelor i master u ekonomiji sa Swiss UNI "verovatno" ce mi priznati skoro sve ekonomske predmete i ostaviti mi informaticke da polazem da bih dobio diplomu.
Za to ce mi trebati od 1-2 godine da sve polozim i dobijem diplomu. Za to vreme, bih poceo da ucim programske jezike, u zavisnosti od toga cime bih zeleo da se bavim u programiranju.
Tako da bih za dve do tri godine imao diplomu informaticara i nekog iskustva u programiranju.

Moram da napomenem da ja radim 100% i da imam team od 5 ljudi trenutno, koji vecinu posla obavljaju umesto mene, tako da bih dnevno na poslu mogao vezbati oko 2-3 sata dnevno, jel to dovoljno? Ili bih morao min 5 sati dnevno?

Sto se tice matematike, tetka mi je bila profesor matematike na Uni i vezbao sam sa njom math od 7 god, e sad nzm koliko je moja statistika, kombinatorika, slicnost itd povezana sa tom naprednijom matematikom, jer verujem da je to ovde na mnogo vecem nivou.

Da me ne shvatite pogresno, okrecem se programiranju jer je buducnost u koju ja verujem a ne zbog para. Ja trenutno imam lepu poziciju i naravno zaradjujem lepo. Ali jasno vidim da se moja bransha polako gasi, i da cu mozda u buducnosti ostati bez posla ne svojom kruvicom vec zbog stanja na trzistu.
[ djoka_l @ 16.04.2017. 21:41 ] @
Ovo sada već počinje da liči na ozbiljan plan!

Poznajem dosta dobrih programera koji su znanje stekli na ekonomskom fakultetu. Ono što će ti biti plus je to što poznaješ ekonomiju, pa ćeš biti vrlo ozbiljan kandidat za rad na poslovnim aplikacijama. Ono što će ti biti presudno je poznavanje baza podataka, projektovanje poslovnih sistema, sistem analiza, nešto malo matematike koja nije mnogo drugačija od one na ekonomskim studijama. Neki konkretan programski jezik nije tu presudan, nauči ih nekoliko, a velika je verovatnoća da će ti na poslu biti potrebno nešto totalno deseto što nisi ozbiljno ni učio na studijama.

Mislim da je greška da se sada koncentrišeš na konkretan programski jezik, ali ako baš želiš unapred da učiš, mislim da bi ti bilo korisno da kreneš sa web tehnologijama, pa bi možda prvi izbor jezika bio JavaScript. Ono što je zgodno kod njega je što se interpretira, što nema striktnu proveru podataka i što se koristi na klijentskoj strani weba, pa rezultat možeš odmah da vidiš u brauzeru, pa da se ne gnjaviš sa učenjem ogromnog broja biblioteka nekog "ozbiljnijeg" programskog jezika.

Ako budeš stvarno upisao tu ekonomsku informatiku, bolje ti je da se koncentrišeš na to što se tamo uči, a da samostalno samo malo produbljuješ znanje.

Brza rekapitulacija: prvo i osnovno, baze podataka (SQL jezik). po mom iskustvo, za neki početni nivo, treba ti oko 120 sati za ovo (procena se bazira na tronedeljnim kursevima sa 8 sati dnevno, uz predavača, za samostalno učenje možda i više). Drugo, web tehnologije, HTML, CSS, JavaScript, možda PHP. Za ovo računaj bar 300 sati za neki početni nivo.

[Ovu poruku je menjao djoka_l dana 16.04.2017. u 22:56 GMT+1]
[ DusanSukovic @ 18.04.2017. 08:01 ] @
Citat:
stray:
Hvala svima na odgovorima, hvala vam mnogo jer ste mi dali odgovor koji sam u neku ruku i zeleo da cujem a to je da je moguce, naravno sa velikim trudom, ali sta je inace u zivotu lako...

Sto se tice matematike, tetka mi je bila profesor matematike na Uni i vezbao sam sa njom math od 7 god, e sad nzm koliko je moja statistika, kombinatorika, slicnost itd povezana sa tom naprednijom matematikom, jer verujem da je to ovde na mnogo vecem nivou.

Da me ne shvatite pogresno, okrecem se programiranju jer je buducnost u koju ja verujem a ne zbog para. Ja trenutno imam lepu poziciju



"Mozes da mislis da nesto mozes da uradis, a mozes i da mislis da ne mozes da uradis, i oba puta ces biti u pravu" ;-) Ko je to rekao? Ford?

Od autora Kenneth Rosen knjiga "Discrete Mathematics" je udzbenik za Bachelor nivo sto se tice matematike na zapadnim univerzitetima.


http://www2.fiit.stuba.sk/~kva...s_Applications_7th_Edition.pdf


Srecno!


[ sgtalexxx @ 07.05.2017. 18:26 ] @
Drugari,ima li neko ideju kako pronaci prakse u inostranstvu sto se tice ove oblasti? Konkretno Norveska ili Svajcarska u kojoj clan koji je otvorio temu kaze da je veoma velika potraznja za IT sektorom.
[ pl4stik @ 16.05.2017. 09:47 ] @
Off
@sgtalexxx
Google search, kako drugacije?

On
Slazem se da je stavrno tesko nauciti programiranje per se ali nije nemoguce za 1,5-2 godine bar do nekog pocetnickog nivoa da pocnes da zaradjujes ali treba da si bas uporan i da ucis, a jos bitnije da vezbas od jutra do sutra. Sto se tice raznovrsnosti programskih jezika i to se slazem ali na primer za pomenuti e-commerc web site (i ne samo web site) prakticno ti treba HTML/CSS/JS jer u js-u mozes da pises i front-end i back-end, a boga mi i mobile ... Mozes da koristis TypeScript (vremenom hoces jer ce ti olaksati programiranje) a i ne moras ni sa Angularom ni sa bilo kojim js library/framework zatim taj OAuth moze i ne mora al treba da bi standardizovao auth sa velikima, pa lambda isto treba jer ce ti biti lakse al ne mora, etc... Znaci sedi i nauci pure JS i na belom konju si :)

Just my 2c, peace :)
[ sgtalexxx @ 07.06.2017. 16:16 ] @
Mislio sam da li postoje neki specificni sajtovi ili nesto? Ovako je izuzetno tesko. Voleo bih savet nekog ko ima iskustva sa ovim.Hvala
[ mjanjic @ 07.06.2017. 16:42 ] @
Jedan kratak savet: raditi u kontinuitetu, čak i ako se radi o banalnim stvarima.

Ne radiš nešto nekoliko meseci i odmah si "zarđao", počneš da se cimaš oko sitnica...


Najlakše je sređivati sitnice u gotovom kodu.
Uzmimo jednostavniji primer za "programiranje", imaš neki Web sajt sa dosta CSS-a i JS-a, i treba da doradiš neke sitnice, izmeniš funkcionalnosti...
I to nije toliki problem, zar ne.

ALI, kad kreneš od maltene praznog editora, onda odjednom hiljadu problema počinje da se pojavljuje, postane napor da spakuješ najobičniju formu kako treba.
Nađeš neki dobar dizajn forme, ali on ima svoj CSS ili čak više njih, čije ti se deklaracije mešaju sa CSS deklaracijama tvog sajta (imaju npr. neke iste class i id atribute).
Onda kreneš to nešto da budžiš, uzmeš malo CSS-a iz jednog projekta, malo iz drugog, nešto iz trećeg, onda krene glavobolja...

I od najprostije stvar napravi se problem - koji nije nerešiv, nego počneš da se čudiš kako oko banalnih stvari gubiš toliko vremena.

Zato se u Web dizjanu/programiranju često strogo odvajaju poslovi - jedna osoba radi funkcionalnosti, a druga dizajn.
Onaj ko radi dizajn, ne mora da se maltretira oko funkcionalnosti, i obrnuto, tako da je manje glavobolje.



Isto to primeni na neku desktop ili serversku aplikaciju. Čak i da nemaš nekog posla oko dizajna, razlika je ogromna ako radiš na nečemu što već ima poprilično koda i ako krećeš od praznog editora.


To ti je maltene isti efekat kao u osnovnoj/srednjoj školi kad se preslišavaš neki predmet (posebno ako se buba napamet).
Dok bacaš krajičkom oka pogled na knjigu, sve znaš, čim zatvoriš knjigu, odjednom shvatiš da ne znaš ništa.

Tako ti je i u programiranju. Sve dok radiš nešto sa nekim gotovim kodom, čini ti se super i prosto.
Problem je kad treba da kreneš od nule sa bilo čime, tj. od praznog editora...

Onda tek vidiš koliko imaš ili nemaš rutine sa najprostijim stvarima.
A tu je cilj da ono što koristiš 90% vremena znaš vrhunski kako bi na tome gubio najmanje vremena.

Ali, čim napraviš pauzu nekoliko meseci, posebno ako radiš nešto potpuno drugačije, treba ti neko vreme da povratiš staru formu.


Zato sve te "školice" imaju upitnu vrednost ako ne kreneš to znanje odmah da koristiš za nešto konkretno.
[ zimbra @ 10.07.2017. 01:48 ] @
Ja sam cimao par drugara oko ovoga i neki koncenzus je da treba savladati redom

- data tipovi i strukture [detaljno]
- c [detaljno]
- c++ [povrsno ka detaljnom]
- sta de talje zanima (java, swift, php..) do nivoa koji ti je potreban (vrhunski u nekom trenutku) ..

pronasao sam brdo on-line literature za c, c++ i ovo kasnije, ali ono sto mi svi kazu da treba da se prodje pre C-a, ne mogu nigde da nadjem... ne vidim nigde free da mogu da skinem knjigu koja obradjuje osnovne tipove podataka, strukture, racunske operacije u razlicitim osnovama, floating point aritmetiku, relacionu algebru i slicno.. da li neko zna, moze da podeli, neku online knjigu na tu temu?
[ Branimir Maksimovic @ 10.07.2017. 10:56 ] @
Sve to imas na wikipediji sa sve referentom literaturom. Ne djuture, ali ako znas sta da trazis...
[ zimbra @ 10.07.2017. 12:24 ] @
Citat:
Branimir Maksimovic: Sve to imas na wikipediji sa sve referentom literaturom. Ne djuture, ali ako znas sta da trazis...


kad znas sta trazis onda si vec davno preskocio "pocetnicku" poziciju :( tu i jeste problem, savladati te neke osnovne koncepte pre nego se krene sa ucenjem programiranja, a ne mozes da ih trazis na wikipediji pre nego znas sta su, a kad znas sta su onda mozes da se "podsetis" na wikipediji ali tada nisi noob
[ jablan @ 10.07.2017. 13:03 ] @
Po mom mišljenju, nema potrebe da se toliko udubljuješ u podatke i strukture. Te stvari jesu krucijalne, ali možeš ih savladati učeći neki programski jezik. A i mnogo je lakše nego da ih učiš nasuvo.

Još jedan savet: kloni se C++-a, barem dok ne savladaš dobro bar 2-3 jezika (kad kažem dobro, mislim da napišeš ponešto veće u svakom od njih).
[ mjanjic @ 10.07.2017. 17:01 ] @
Programiranje se najlakše uči kroz rešavanje problema, isto kao i matematika ili fizika.

Imaš gomilu primera po raznoj literaturi (nađi npr. knjige 70 ili 150 problema na Google intervjuima i sl., mada je to možda i preteško za početak, ali ima i elementarnih primera), zatim možeš i sam da smisliš problemčiće, kao npr. "naći najmanji i najveći broj od N unetih brojeva" i sl., imaš takvih zadačića u primerima testova/kolokvijuma/ispita iz Uvoda u programiranje i sličnih predmeta na ETF-u i drugim fakultetima koji imaju studijske programe slične Softverskom inženjerstvu.

Iako se primeri čine jednostavni, pokušaj da zapisuješ vreme potrebno za rešavanje. A onda se informiši koliko je nekom iskusnom programeru potrebno vremena za takve "trivijalne" stvari.


Neko pomenu finski jezik, a ja bih pomenuo i sportove kao što su npr. košarka/fudbal/odbojka. Ako nisi dobro savladao elementarne stvari, niko te neće zaposliti niti ozbiljno shvatiti na razgovoru za posao ma koliko poznavao napredne tehnologije i bez obzira koliko ti umeo da radiš neke optimizacije i sl. Jer, jednostavno, u tim naprednim stvarima se sigurno nećeš uvek snaći kako treba ako nemaš odbru osnovu u znanju onoga što se koristi preko 90% vremena.



Dakle, jednostavno odabereš jezik, instaliraš potrebne alate, i kreneš sa jednostavnim primerčićima.
Jeste da neće efekat biti "WOW" kao kad neki "komšijin mali" napravi "web sajt" od gotove bootstrap teme u par klikova, ali tebi nije cilj da radiš za džeparac, već da za nekoliko godina imaš platu bar duplo veću od zvaničnog proseka u Srbiji, zar ne?
[ boguda @ 10.07.2017. 22:46 ] @
Da sad pocnem da ucim programiranje i da razmisljam sta sve treba da naucim poceo bih od oglasa za posao. Npr "Laravel programer sa odlicnim znanjem php-a, phpunit html5 css, sass, Javascript git vagrant itd(to je ono osnovno sto se trazi za programera pocetnika, hehe salim se)".
E onda istrazis sta je svaka od tih stavki, pa naucis da je Laravel ili Yii php framewok, pa vidis koji ima bolji community pa kad sve odaberes nadjes tutorijale sve ih odgledas i tri puta se predomislis, odustanes i vratis se e onda krenes da pravis nesto sto su svi vec pravili i posle par godina tako besumucnog i uzaludnog rada shvatis da ti sad vec gore spomenute tehnike, znas, da mozes da citas i poneki tudji kod ili dokumentaciju i da su ti je vecinom jasani e onda je vreme da trazis posao.
Moze to i lakse, naucis Wordpress(ne omalovazavam samo sam video dosta takvih "programera" ) znas da koristis gomilu plugin-ova napravis nekoliko sajtova koji i ne znas kako rade(a rade) i zaposlis se u nekoj firmi koja stancuje jeftine sajtove i ti si programer.I imas cak i platu. Ali nije fora zapamtiti jednacinu nego je izvesti na tabli pred celim odeljenjem...
[ Bradzorf012 @ 11.07.2017. 12:59 ] @
Prošlo je već tri meseca od kako je postavljena tema, pa autor iste može za početak da dobije i jedan test zadatak. Na primer, da u jednom prolazu prebroji koliko puta se string rec pojavljuje u stringu recenica. Ove nizove karaktera korisnik unosi sa tastature.
[ Branimir Maksimovic @ 11.07.2017. 14:41 ] @
Koji algoritam? boyer-moore, horsepool ili brute force? ;) (a ima i efikasna sse 4.2 instruckija za brute force)
[ Bradzorf012 @ 13.07.2017. 20:51 ] @
Hm, nije poenta naučiti napamet sve poznate algoritme za sortiranje, pretragu, itd, već sa tom osnovom ubaciti mozak u mod koji te tera na razmišljanje i pronalaženje optimalnog rešenja. Recimo, u primeru koji sam naveo u zavisnosti od duzine unetih stringova može se primeniti jedno, drugo ili treće rešenje. Možda je optimalno baš ono koje nije obrađeno u literaturi. Nema recepta za neki problem u praksi, niti postoje gotovi delovi konstrukcije koje slažeš kao lego kockice da bi dobio gotov proizvod. Ok, postoje, ali ako ostaneš samo na tom nivou, nećeš biti u stanju da proračunaš "statiku" objekta, stvari će ti biti jasne samo na površini, a ne i suštinski. Može i to, šta se kome više sviđa i gde se pronalazi. Na kraju, boguda je to bolje objasnio od mene:

Citat:

Ali nije fora zapamtiti jednacinu nego je izvesti na tabli pred celim odeljenjem...
[ Branimir Maksimovic @ 13.07.2017. 22:06 ] @
Problem je u tome sto se ne dolazi lako do tih algoritama inace ne bi dobili imena po svojim pronalazacima ;p
[ Bradzorf012 @ 14.07.2017. 15:54 ] @
Pa čekaj malo, ti se pozivaš na neke algoritme. Kako znaš za njih ako se do istih ne dolazi lako? Imaš love, pa si platio? Šta to nije javno dostupno? Ništa ne shvatam.
[ Branimir Maksimovic @ 14.07.2017. 15:57 ] @
Sto se pravis glup kad nisi ;)
Ti propovedas ovde nekakvu nauku o pametovanju tipa razmisljanja o nekakvim resenjima koje nema u literaturi, umesto da pokupis gotovo resenje i primenis ga shodno.
[ Bradzorf012 @ 14.07.2017. 17:02 ] @
Aham, tako znači. Da li ti čitaš pažljivo ono što sam napisao ili samo kuckaš reda radi? Evo da ti nacrtam, kao arhitekta ili građevinski inženjer bih morao da pogledam(pregledam, naučim) i realizujem bar stotinak različitih planova, projekata kuća pre nego što bih bio u stanju da napravim sopstveni za neki specifičan zahtev kupca. Da li ti je bar malo jasnije? Možeš imati zilion algoritama za sve i svašta, ali konkretni naručilac posla će ti tražiti nešto što nećeš moći da realizuješ samo prepisivanjem iz knjige ili metodom kopiraj i pritisni dugme. Da je tako, niko ne bi učio nikakvu školu, niti bi bilo minimalnog napretka.

Tebi ostaje da nam kažeš do kojih se algoritama ne dolazi lako?
[ Branimir Maksimovic @ 14.07.2017. 17:45 ] @
Jedno je algoritam drugo je implementacija algoritma. Tu imas siroku slobodu i zavisi od toga u kom jeziku radis. E sad retko ko ce i to da radi kad imas vec gotove f-je koje samo pozivas ;)

Implementacija resenja u softverskom svetu zavisi od firme do firme. Osim ako nisi glavni programer u firmi i tek pocinjes posao pa onda biras tehnologije.
Nema tu mnogo mesta za kreativnost ako radis u firmi kao grunt koji treba da dumbara kod koji je neko narucio.
Ne dolazi se lako do novih algoritama za pretrazivanje stringova recimo. Mozes ti da smislis neki pa da kazem koristim Bradzor algoritam ;)
[ Bradzorf012 @ 14.07.2017. 20:53 ] @
Dobro, sve je to lepo, sve se slažem, manje više.

Samo, još uvek mi nije jasan smisao sledećeg:

Citat:
Branimir Maksimovic:
Problem je u tome sto se ne dolazi lako do tih algoritama inace ne bi dobili imena po svojim pronalazacima ;p


Ne dolazi se lako do njih u naučnom smislu? Hm, nešto nisam siguran da će postavljač da radi na nekom institutu ili da vodi doktorante. Zašto bi se on oko toga uopšte potresao? Ne dolazi se lako do dobrih algoritama, zato što nisu svi dostupni javnosti? Ako tako nešto postoji, opet teško da će raditi za ciju ili neku sličnu firmu.

Zaista, šta je poenta citirane izjave, osim da potvrdi očigledno?
[ Branimir Maksimovic @ 14.07.2017. 21:13 ] @
Poenta je da to ne ide tako kako si zamislio ;p
Dakle ima ko da pronalazi algoritme, i ima ko da ih primenjuje. Jedni su naucnici, drugi programeri ;p
Stvar je u tome da naucnik ima oho vremena a programera pritiskaju rokovi ;p
[ Bradzorf012 @ 14.07.2017. 22:27 ] @
Citat:

Poenta je da to ne ide tako kako si zamislio ;p

Kako sam zamislio? Kako ide, objasni mi molim te.

Citat:

Dakle ima ko da pronalazi algoritme, i ima ko da ih primenjuje. Jedni su naucnici, drugi programeri ;p

Ovo nisam znao dok mi ti nisi rekao. Uzgred, do otkrića u nekoj oblasti često dolazi slučajno, do otkrića ne dolazi uvek i samo onaj kome je to posao, tj. naučnik, istraživač, saradnik u institutu.

Citat:

Stvar je u tome da naucnik ima oho vremena a programera pritiskaju rokovi ;p

Ni ovo nisam znao dok mi nisi rekao. Opet, ni naučnik nema sve vreme ovog sveta, ne može ni on baš da digne sve četiri uvis i svirucka, pa ako naiđe inspiracija, naiđe, ako ne nikom ništa. Da, programera pritiskaju rokovi, ali se od njega ne traži da otkrije i uobliči novu naučnu teoriju, ne traži se čak ni da otkrije neki novi algoritam, pa makar ponudio i minimalno poboljšanje. Ne, traži se da bude dobro upoznat sa kretanjima u nauci(oblasti, struci), kako bi sve ono što je do tada otkriveno mogao relativno jednostavno da primeni na konkretan problem koji rešava.

Citat:

Problem je u tome sto se ne dolazi lako do tih algoritama inace ne bi dobili imena po svojim pronalazacima ;p

Zaista, šta je poenta citirane izjave, osim da potvrdi očigledno?
[ sale94 @ 25.07.2017. 21:10 ] @
Za početno učenje programiranja najbolje je pokušati savladati Python, https://www.python.org. Python je jezik budućnosti koji polako uzima primat od jave, barem je tako u USA http://statisticstimes.com/tech/top-computer-languages.php
[ Shadowed @ 26.07.2017. 08:20 ] @
Sunce ti, koliko samo ima tih jezika buducnosti
[ mmix @ 26.07.2017. 08:50 ] @
Mene najvise zapravo odusevljavaju ti indeksi kao sto su TIOBE bazirani na metrici search engine-a

U prevodu najpopularniji i naj-buducniji su jezici o kojima ljudi k*ca pojma nemaju i moraju da guglaju svakih 2 minuta jer nemaju ni pristojan help
[ jablan @ 26.07.2017. 08:56 ] @
Citat:
sale94:
Za početno učenje programiranja najbolje je pokušati savladati Python, https://www.python.org. Python je jezik budućnosti koji polako uzima primat od jave, barem je tako u USA http://statisticstimes.com/tech/top-computer-languages.php

Da si ti živ i zdrav, Python postoji od 1991 (dakle, duže nego ti, sudeći po nicku). :)

Inače, tačno je da je dobar za učenje programiranja.
[ Branimir Maksimovic @ 26.07.2017. 12:37 ] @
Python je dobar ako volis da se boris sa tabulacijom i namestis editor da stavlja space umesto tab ;)
Doduse navikao sam na to preko Haskella ;)
[ Predrag Supurovic @ 26.07.2017. 14:24 ] @
Python ne bi bio loš jezik da nema te hebene tabulacije i nedostatka normalne sintakse za naznaku blokova koda.
[ jablan @ 26.07.2017. 16:01 ] @
"Meni se ne dopada, dakle loš jezik"
[ mmix @ 26.07.2017. 16:20 ] @
Zar u Pythonu ima jos nesto sem tabulacjie i nedostatka normalne sitnakse (grabs popcorn and flies away.... )
[ Predrag Supurovic @ 26.07.2017. 20:50 ] @
Citat:
jablan:
"Meni se ne dopada, dakle loš jezik"


Jablane, u 2017 godini da sintaksa uslovljava broj tabova i da se time naznačavaju blokovi koda je vracanje u vreme Cobola i bušenih kartica čini mi se.

Savremeni jezici ignorišu i spejsove i tabove i nove redove.

Python je inače prilično interesntna platforma. Dosta je pojednostavljen pa je zato zgodan za početnike ali zato naprednijim programerima izgleda čudno jer neki uobičajeni koncepti u njemu ne postoje - recimo objektni model je prilično (ja bih rekao preterano) pojednostavljen.
[ mmix @ 26.07.2017. 23:47 ] @
Manje vise to, moj najveci beef sa Pythonom je potpuna autisticnost i samog runtime-a i biblioteka. Ja mislim da mi se jos nije desilo da mi python izbaci neku gresku a da je ta greska zaista imala veze sa tim sto ne valja.
[ maksvel @ 27.07.2017. 07:53 ] @
E, nemojte me sad obeshrabrivati, taman sam lepo krenuo sa pajtonom, proradio mi je i Hello World i svašta nešto.
[ jablan @ 27.07.2017. 08:24 ] @
Citat:
Predrag Supurovic:
Citat:
jablan:
"Meni se ne dopada, dakle loš jezik"


Jablane, u 2017 godini da sintaksa uslovljava broj tabova i da se time naznačavaju blokovi koda je vracanje u vreme Cobola i bušenih kartica čini mi se.

Imaš neki dokaz za to? Uostalom, šta je problem sa indentacijom? Zar ti ne indentuješ pravilno kod koji pišeš, u ma kom jeziku? Ako, da, onda su zagrade ili šta već stavljaš oko blokova čist višak.


Citat:

recimo objektni model je prilično (ja bih rekao preterano) pojednostavljen.

Znaš kako, meni kao primarno ruby programeru svaki ne-čisti objektni model (Java, PHP, C++, Delphi, C#, štagod) izgleda smešno, pa opet ga ljudi sasvim uspešno koriste.

Kritike koje iznosi mmix imaju logike, jer su očigledno zasnovane na praksi, ali nemaju veze sa samim jezikom, već sa implementacijom i ekosistemom.

@maksvel: ne brini, haters gonna hate, super je python, posebno za početak (a ima i dovoljno posla za python programere)
[ Rapaic Rajko @ 27.07.2017. 10:30 ] @
jablane,

moze li malo pojasnjenje: sta je to sto cini razliku izmedju ruby-ja i pomenutih jezika (sve sam ih koristio/koristim)? Pomenuo si izraz 'ne-cisti' objektni model; na sta si tacno mislio?
Pitam iz ciste radoznalosti (i da nesto naucim ).

A inace, nisam radio s python-om (nisam ga ni video), ali za indentaciju se potpuno slazem: moze se bez zagrada, to je samo stvar treninga.

Pozz
[ negyxo @ 27.07.2017. 10:43 ] @
Iskreno, ja sam skroz protiv zagrada. Haskell demonstrira to lepo, dok recimo za .NET F# je takodje prilicno cist. No, razlog zasto smatram da su zagrade visak je - sto to zaista jesu. Stvar je navike ali rekao bi i nepotreban noise. Treba uzeti u obzir da whitespace sa sobom nosi informaciju i to se vec sada uveliko radi, tako da mu zagrade dodju kao vezba za prste. Recimo, pre par godina dok sam radio za jednu firmu, bilo je pravilo da ne moze da se commituje code koji nije prosao sintaksnu proveru, naravno automatsku (C#, FxCop). Radeci tako, dosao sam u jednu skroz apsurdnu situaciju, nema commita dok ne ispravis svaku nepravilnost, a gomila tih neprovilnosti se odnosila da moras da identujes kako treba i da stavljas zagrade kako treba. Tada ti se upali lampica da sve vreme glumis tool za formatiranje umesto da se bavis samo programiranjem. Neko bi rekao da ovo moze da se automatizuje - i moze, ali cemu onda automatizacija noise-a?
[ jablan @ 27.07.2017. 11:14 ] @
Citat:
Rapaic Rajko:
moze li malo pojasnjenje: sta je to sto cini razliku izmedju ruby-ja i pomenutih jezika (sve sam ih koristio/koristim)? Pomenuo si izraz 'ne-cisti' objektni model; na sta si tacno mislio?

Ukratko, sve je objekat, i to se oslikava i na sintaksi. Možeš da napišeš npr:

Code:

"Rajko".reverse
# => "okjaR"
123.to_s(16)
# => "7b"
[:foo, :bar, :baz].length
# => 3


Takođe, npr. instanciranje objekta Person se radi pozivom metode new na klasi Person, klasa je takođe objekat. Ne postoji posebna sintaksa za instanciranje klase.

Itd itd.

U principu, zgodno je, lepo izgleda, čini programe čitkijim i logičnijim a sintaksu jednostavnijom, ali nije nešto za čiji bih nedostatak objektivno mogao da zamerim jezicima poput C# i Jave.
[ maksvel @ 27.07.2017. 13:26 ] @
Vidim da se i dalje vuče dvojka, bilo bi lepo da se sve nekako prešalta na 3.x - što ne može, naravno tek tako.
Razumem da jezik mora da evoluira, ali malo smaraju ove napomene "u 2.7 to ide ovako, e, ako koristite 3.x, onda ide onako" i tome slično.
[ mmix @ 27.07.2017. 13:41 ] @

Python je lep programski jezik da se nauce strukture linearnog programiranja i osnovne manipulacije linearnih struktura, nesto cemu je nekad BASIC sluzio. Sama cinjenica da je sintaksa bazirana na indentaciji ce pocetnika forsirati da kod struktuira logicki I pregledno pre nego sto mu se daju viticaste zagrade u ruke.

negyxo, ne vidim neku preteranu razliku izmedju maltretiranja od strane FxCOpa za commit I maltratiranja od strane python interpretera u runtime-u za istu stvar. To sto tvoja kompanija tebe tera da indentiras c# kod na samo jedan nacin ne znaci da je to u duhu jezika. Viticaste zagrade omogucavaju neke nove strukture koda koje indent jezici ne mogu, npr razdavajanje scope-a (sto je od koristi u auto-generisanom kodu):

public void MultiScopedFoo {
{
string foo = "foo";
}
{
string foo = "new foo, completely valid";
}
}

That being said, zadrzati se na pythonu i od toga praviti karijeru je podjednako besmisleno. Python je veoma los kao teaching aid za OOP, nacin na koji on radi sa klasama je nesto sto cuci JScript I PHP devovima ali to realno nema veze sa mozgom i necim sto bi senior resource trebao da zna.
Dynamic typing sam uvek dozivljavao kao staku, a programere koji se na njega oslanjanju kao nesposobne da efikasno organizuju svoje strukture podataka.
[ jablan @ 27.07.2017. 13:49 ] @
Citat:
mmix: Dynamic typing sam uvek dozivljavao kao staku, a programere koji se na njega oslanjanju kao nesposobne da efikasno organizuju svoje strukture podataka.

wow hvala lepo
[ Ivan Dimkovic @ 27.07.2017. 14:12 ] @
Citat:
mmix
a programere koji se na njega oslanjanju kao nesposobne da efikasno organizuju svoje strukture podataka.


Ja ne bih isao tako daleko, mozda su mnogi od njih savrseno sposobni da organizuju svoje strukture podataka, ali ne trose svoje vreme na definisanje tipova posto im jezik pruza taj luksuz a eventualni gubitak performansi nije bitan za projekat.

To samo po sebi ne mora biti lose, mozda su ljudi produktivniji na kraju.
[ negyxo @ 27.07.2017. 14:25 ] @
@mmix,

Citat:

negyxo, ne vidim neku preteranu razliku izmedju maltretiranja od strane FxCOpa za commit I maltratiranja od strane python interpretera u runtime-u za istu stvar.


Pa i nema razlike u tome je stos :) Osim sto moras da se bakces sa zagradam za isti rezultat. Ja kada pricam o zagradama mislim na blokove, tj. otvaranje i zatvaranje istih. Ja apsolutno nikad ne gledam gde je pocetak zagrade da bi znao gde je pocetak bloka, nego gledam sta je identovano. Recimo sta ti je citljivije u ova dva slucaja:

Code:

public void Foo
{
DoSomething();
DoSomeOtherThing();
}

public void Foo
{
    DoSomething();
    DoSomeOtherThing();
}


Meni iskreno ovo drugo. Mozes da kazes da je zato sto sam navikao, sto i jeste tacno, ali razlog navike i jeste taj sto se drugo lakse primeti od prvog. Upravo identacija nosi informaciju bloka. Da nema toga, onda bi bukvalno morao ocima da trazis pocetak i zavrsetak zagrada. Hebi ga, ljudi mnogo lakse vizualizuju stvari nego sto ih mentalno parsiraju. Kada uzmes to u obzir, onda shvatis da pravu informaciju o bloku nosi whitespace, tj. identacija a ne zagrade, samim tim, IMHO, zagrade su visak i moram da priznam kako sam poceo malo da radim F# sve vise mi C# code lici na njega (koliko je moguce) :)

Sto se tice multiscope-a, iskreno, koliko si puta to u zivotu koristio, ja se ne secam da sam jednom :)

BTW. Sto se tice dynamic typing-a meni iskreno nema smisla ni malo, bez staticke analize jednostavno sve je... ne znam kako bih rekao, ali meni licno izgleda kao igranje programiranja...



[Ovu poruku je menjao negyxo dana 27.07.2017. u 15:50 GMT+1]
[ mmix @ 27.07.2017. 14:27 ] @
Dobro, lenje ako ti to vise odgovara, posto znam da znas ali te ocigledno mrzi jer je tu ruby da te pusta da radis sta hoces Ali cinjenicno je stanje da je cak i ljudi kao sto si ti sve manje, dolaze horde ignoramusa koji ne znaju i ne zele da znaju nista van skripta a sebi dodeljuju neke grandiozne titule tip "full stack developer". Na to mogu da kazem samo "lol druze, 'stack' ide mnogo dublje nego sto ti mislis".

Jbg, sta cu, opterecen sam tim stvarima, to me je nerviralo jos od VBScript dana gde je "12" + "5" bilo 17, ali nedefinisanih 17 koji postoje u limbu u onim ocajnim Variant strukturama. Decenijama milijarde dolara i milioni inzenjerskih sati odlaze na to da se naprave sto efikasnije i brze hardverske platforme, hyper threading paralelizacija, cache kohezija, mutli-level branching, milioni sati na optimizovane kompajlere i strukture podataka da bi se napravili sto efikasniji kompajleri, milioni sati na razvoj end aplikacija koje ce iskoristiti sve to. I onda dodju script devovi i popisaju se na sve to uz ono "haha, koji ste vi sabani, al ste se isprimali, mi to isto uradili u tri linije koda, mnogo citljivije!" Ja mislim da sam generalno veoma uzdrzan uzimajuci u obzir desavanje naroda u appdev-u.

Mozda je samo vreme da batalim sve ovo i da pocnem da pravim kiflice ili sarajveski cevap, cuo sam da su to odlicne retirement opcije za appdev
[ negyxo @ 27.07.2017. 14:40 ] @
Citat:
Ivan Dimkovic:
To samo po sebi ne mora biti lose, mozda su ljudi produktivniji na kraju.


Iskreno, ja nikad nisam verovao u ovo, niti verujem i dan danas. Ta produktivnst se odnosi na par funkcija kada da treba da se prikaze ekspresivnost. Type system sa druge strane nosi ogromnu ustedu u performansi i developmentu na iole vecem projektu (za mene je licno to bilo sta vece od "hello world"). Daleko od toga da u nekim modernim dinamickim jezicima ne moze elegantan i kratak code da se pise, ali cena je, po meni visoka, sve ono sto radi type system za tebe, moras sada da radis rucno (ovo su uglavnom testovi). Na kraju, ja bi rekao da je razlika izmedju dynamic vs static u man vs machine. Nekako kontam da ljudi svakako gube tu bitku :)
[ mmix @ 27.07.2017. 14:43 ] @
@negyxo, ti pricas o stilu indentacije, i cuvenom religioznom sukobu "to cuddle or not to cuddle"
Fora je u tome sto ti sa zagradama imas 12 varijanti i podvarijanti stilizacije, koji su SVI validni i prepoznati, dok sa whitespace sintaksom imas samo jedan. Java devs uglavnom koriste varijantu K&R-a, c# devovi koriste Allman-a, ali nema pravila. Sta vise, mozes ti da napravis i sopstvenu podvarijantu indentacije i opet ce sve lepo da radi. Dodaj jedan space u python gde ne treba i prica je gotova, ne samo estetski vec i funkcionalno.

https://en.wikipedia.org/wiki/...acement_in_compound_statements
[ jablan @ 27.07.2017. 14:51 ] @
Citat:
mmix:
to me je nerviralo jos od VBScript dana gde je "12" + "5" bilo 17, ali nedefinisanih 17 koji postoje u limbu u onim ocajnim Variant strukturama.

Jesi li siguran da ne mešaš dynamic i weak typing? U rubyju svakako "12" + "5" nije 17, a "12" + 5 baca grešku (naravno, runtime grešku).

I uopšte nije tačno da smo lenji, što ne platimo na mostu, plaćamo na ćupriji jer testove pišemo sa religioznom predanošću. :)
[ negyxo @ 27.07.2017. 14:59 ] @
@mmix, ne ne pricma o tome. Sorry ako te zbunio primer, ostavio sam visak zagrade u oba primera. Sada sam ispravio. Nije bitno gde su zagrade, bitno je da je identovano, jer vizuelno onda vidis blok. Pogotovo blok u bloku u bloki itd.

Recimo evo opet primer:

Code:

namespace FooNameSpace
{
public class FooClass
{
public void Foo
{
DoSomething();
DoSomeOtherThing();
}
}
}


namespace FooNameSpace
{
    public class FooClass
    {
        public void Foo
        {
            DoSomething();
            DoSomeOtherThing();
        }
    }
}


Koliko ti je lakse da razumes drugi primer? Nebitno gde stavis zagrade, u prvom slucaju ti moras stvarno da trazis zagrade i da vizualizujes blok nekako u glavu, u drugom... pa tu je vec, vidis ga :) Treba samo vec sada priznati sebi da inforamaciju o bloku nosi identacija, ne zagrade.
[ mmix @ 27.07.2017. 15:11 ] @
Sto se tice human readable, da, indentacija u velikom boju slucajeva nosi infromaciju o bloku ali ne uvek. Narocita sada u c#-u kad su lambde postale deo jezika.

lupam, npr:

Code (csharp):

   var x = 0;
   list.foreach(l => { x+=l; Console.Write("."); });
 


ako cu da ga indentiram:
Code (csharp):

   var x = 0;
   list.foreach(l =>
   {
      x+=l;
      Console.Write(".");
   });
 


ne vidim neko konkretnu prednost ovog drugog, niti vidim kako bi mi sintaksa bez zagrada pomogla
[ djoka_l @ 27.07.2017. 15:36 ] @
Meni ne smeta dynamic typing u skript jezicima, dokle god se to ne proglašava za religiju.

Savršeno sam srećan kad u shell skriptu ne moram da deklarišem tipove, ali treba shvatiti da skript jezici imaju svoju oblast primene, a to je pisanje SKRIPTOVA. Sasvim OK je da koristim skript jezik da automatizujem neke svakodnevne poslove, ali korišćenje skript jezika za pisanje enterprise aplikacija je potpuna glupost. Isto kao što je nije glupost koristiti NoSQL baze sa skladištenje nestrukturisanih podataka, ali za neke stvari jednostavno MORA relaciona baza.
[ jablan @ 27.07.2017. 15:39 ] @
wow enterprise, krenuli smo sa teškom artiljerijom...
[ mjanjic @ 27.07.2017. 21:01 ] @
A šta kad neko uzme klijentski skript jezik pa za njega napravi RTE za serversku stranu, pa to još postane nenormalno popularno, i onda kad ukapiraju da taj skript jezik i nije baš pravi objektni (jeste npr. objektni, ali je classless), pa se onda tu nađe Microsoft te napravi svoju verziju koja je praktično nadskup tog skript jezika i koji se kompajlira u taj skript jezik (eto, znamo za veći broj slučajeva gde se jedan jezik kompajlira u drugi, npr. Scala u Javu, TypeScript u JS, itd.), pa krenu od verzije do verzije da ubacuju nove stvare koje totalno ruše kompatibilnost unazad...?

Tu je onda najmanji problem da li su mi razmaci važni za sintaksu ili samo da mi kod bude čitljiviji.
[ Branimir Maksimovic @ 27.07.2017. 21:12 ] @
Ma to dynamic vs static typing je pitanje dal greske o pogresnim tipovima dobijas u run-time ili compile-time, big deal ;p
[ negyxo @ 28.07.2017. 07:01 ] @
Ne znam u kom kontekstu si napisao "big deal" ali za mene recimo to jeste big deal, bukvalno delim jezike sa statickom analizom i bez, upravo zbog compile vs runtime, tj. da li masina razume code ili ne. Ako uzmes da je program specifikacija sam po sebi, staticka analiza je tu da ti potvrdi da li je specifikacija validna sama sa sobom, dok kada to nemas, moras da se zezas sa raznim testovima i nikad nemas kompletan dokaz, tj. kada bi hteo da namestis, onda bi upravo poceo da razvijas model koji bi bio radio isto sto i staticka analiza :)

[ Branimir Maksimovic @ 28.07.2017. 07:27 ] @
O cemu ti pricas? O dokazivanju korektnosti programa ili o statickim tipovima? Nisi bas razumljiv ;p
[ mjanjic @ 28.07.2017. 07:27 ] @


[ negyxo @ 28.07.2017. 08:59 ] @
Citat:
Branimir Maksimovic:
O cemu ti pricas? O dokazivanju korektnosti programa ili o statickim tipovima? Nisi bas razumljiv ;p


Ne znam sta bi trebalo da predstavlja "dokazivanje koreknosti". Ja pricam o validnosti programa kroz static cheking, sto se odnosi na staticke tipove.
[ Branimir Maksimovic @ 28.07.2017. 09:14 ] @
U svakom slucaju static type checking ne obezbedjuje validnost programa. Ono sto static type checking radi je da proveri da li sabiras babe i zabe i vraca gresku u slucaju da sabiras.
To isto se desava i u dynmaic type checking samo u run-time -u :)
[ Rapaic Rajko @ 28.07.2017. 09:20 ] @
Citat:
negyxo:
Ne znam u kom kontekstu si napisao "big deal" ali za mene recimo to jeste big deal, bukvalno delim jezike sa statickom analizom i bez, upravo zbog compile vs runtime, tj. da li masina razume code ili ne. Ako uzmes da je program specifikacija sam po sebi, staticka analiza je tu da ti potvrdi da li je specifikacija validna sama sa sobom, dok kada to nemas, moras da se zezas sa raznim testovima i nikad nemas kompletan dokaz, tj. kada bi hteo da namestis, onda bi upravo poceo da razvijas model koji bi bio radio isto sto i staticka analiza :)



Je li na to jablan mislio: 'sto ne platis na mostu, platis na cupriji', pisanje testova do besvesti upravo zbog nedostatka 'statike'..?

Meni licno je pomalo strano pisanje u jeziku koji ne signalizira u compile time-u da nesto ne valja u sintaksi; ono, programer (uvek) zna sta hoce, a sad da vidimo na sta to lici u runtime-u; hvala lepo. (zato i ne volim PHP a o JS da i ne pricam; doduse mozda ne radim u pravom alatu)

Pozz
[ Branimir Maksimovic @ 28.07.2017. 09:27 ] @
Rajko govorili smo o dynamic/static types ;)
A ti sad pricas o interpretiranju/kompajliranju ...
[ negyxo @ 28.07.2017. 10:06 ] @
Citat:
Branimir Maksimovic: U svakom slucaju static type checking ne obezbedjuje validnost programa. Ono sto static type checking radi je da proveri da li sabiras babe i zabe i vraca gresku u slucaju da sabiras.
To isto se desava i u dynmaic type checking samo u run-time -u :)


Opet, ne znam na sta mislis kada kazes "sabiras". Ako stvarno mislis na samo neke operatore, to je samo jedna u moru stvari koje radi staticka analiza. Prilikom kompakliranja ti imas gomilu provera vezanih za sam program, provera se odnosi na to da ono sto si napisao da je u korelaciji sa samim sobom i da umesto runtime dobijas compile time greske. Razlika izmedju compile time i runtime gresaka je ogromna. Kada kazes da isto to dobijas u runtime, previse ublazujes, posto u runtime dobijes samo ako dovedes program u odrjedni state gde se dobija ta greska, dok kod compile time dobijes uvek i odmah za klasu gresaka koje mogu da se detektuju statickom analizom. I zbog toga i kazem, da bi pokrio onaj deo koji staticka analiza radi, morao bi mnogo testova da napises, a nikad nemas garanciju da si sve pokrio, dok kompajler uvek radi 100% za ono sto je napisano, do kraja i bez izuzetaka, tako da imas svojevrsni "dokaz" da ono sto si napisao jeste validno sa samim sobom.
[ Branimir Maksimovic @ 28.07.2017. 10:14 ] @
Cekaj sad i ti govoris o kompajliranju vs interpretiranja?
[ negyxo @ 28.07.2017. 10:23 ] @
Ne. Ne govorim o tome. Tebi je nejasno zato sto kompajliranje danas u vecini slucajevima sa sobom nosi i staticku proveru. Striktno gledano, kompajliranje (prevodjenje iz jednog jezika u drugi, tj. iz jednoga seta instrukcija u druge) je ovde nebitno za pricu. Ono sto je bitno je - razumevanje code od strane static checkera. To su uglavnom kompajleri, ali mozes komotno i da koristis externe static chekere za proveru code-a. Recimo u C# od kako se pojavio Roslyn, mozes da pises svoj static cheker (ili analyzer, kako god ga krstili) , recimo koji ce da analizira na odredjen nacin code, gde u stvari ti mozes unutar svog projekta da automatizujes odredjen process, tipa, lupam, sve metode koje primaju integer kao prvi argument, moraju na pocetku da pozovu logger koji ce da zaloguju vrednost, ukoliko ovo nije slucaj, generises error. Uporedi ovo sa nekim testovima, ili sa nekom internom specifikacijom, ili usmenim dogovorom, bilo cim, sve ostalo se oslanja na neko rucno parsiranje i analiziranje, dok je ovo full automatic, masina uvek radi za tebe :)
[ dusans @ 28.07.2017. 10:24 ] @
Ni jedan ni drugi ne pričaju o interpretiranju, već o static/strong vs weak/dynamic typing.
[ Predrag Supurovic @ 28.07.2017. 10:36 ] @
Citat:
jablan:
Citat:
Predrag Supurovic:
Citat:
jablan:
"Meni se ne dopada, dakle loš jezik"


Jablane, u 2017 godini da sintaksa uslovljava broj tabova i da se time naznačavaju blokovi koda je vracanje u vreme Cobola i bušenih kartica čini mi se.

Imaš neki dokaz za to? Uostalom, šta je problem sa indentacijom? Zar ti ne indentuješ pravilno kod koji pišeš, u ma kom jeziku? Ako, da, onda su zagrade ili šta već stavljaš oko blokova čist višak.


Šta treba da se dokazuje. U Pajtonu se blokovi naznačavaju identacijom.

Naravno da identiram kod ali to ima samo praktičnu vizuelnu svrhu a nikako sintaksnu. Meni je bezvezna ideja da mi kod ne radi zato što negde fali tab ili znak razmaka. Hajde da bar to bude prijavljeno kao sintaksna greška, nego što pogrešno identiran kod (što često nije očigledno kada se kod čita) može da bude sintaksno ispravno ali da skroz promeni način rad programa i postane noćna mora za debag.

Citat:

Citat:

recimo objektni model je prilično (ja bih rekao preterano) pojednostavljen.

Znaš kako, meni kao primarno ruby programeru svaki ne-čisti objektni model (Java, PHP, C++, Delphi, C#, štagod) izgleda smešno, pa opet ga ljudi sasvim uspešno koriste.


Verujem ti. Onda možeš misliti kako tek izgleda objektni model koji je drastično pojednostavljen i u odnosu na te "smešne".

Citat:

Kritike koje iznosi mmix imaju logike, jer su očigledno zasnovane na praksi, ali nemaju veze sa samim jezikom, već sa implementacijom i ekosistemom.

@maksvel: ne brini, haters gonna hate, super je python, posebno za početak (a ima i dovoljno posla za python programere)

[/quote]

Ti si pogrešno zaključio da ja ne volim Pajton. Naprotiv, ta platfoma mi je veoma simpatična. Samo sam naveo neke stvari koje mi se ne sviđaju.

[ Branimir Maksimovic @ 28.07.2017. 10:39 ] @
Ne znam, sad se pominje static checker. Dinamicki tip moze biti i u kompajliranom jeziku. Stvar je u tome da dinamicki tip varijable nije vezan za jedan tip u toku izvrsavanja celog programa.
Dakle kod statickog tipa
int a = 5;
a = "str"; // greska
varijabla a ostaje tipa int kroz ceo program.
Dok kod dinamickog
a = 5;
a = "str";
tip varijable a se menja u zavisnoti sta dodelis varijabli.
To je osnovna razlika.
Ne znam sta sa time ima sad static checker ;)
[ Predrag Supurovic @ 28.07.2017. 10:40 ] @
Citat:
negyxo:
Iskreno, ja sam skroz protiv zagrada.


I ja sam. Uvek su mi se više sviđali begin i end u Paskalu i Delphiju :)

Citat:

Haskell demonstrira to lepo, dok recimo za .NET F# je takodje prilicno cist. No, razlog zasto smatram da su zagrade visak je - sto to zaista jesu. Stvar je navike ali rekao bi i nepotreban noise. Treba uzeti u obzir da whitespace sa sobom nosi informaciju i to se vec sada uveliko radi, tako da mu zagrade dodju kao vezba za prste. Recimo, pre par godina dok sam radio za jednu firmu, bilo je pravilo da ne moze da se commituje code koji nije prosao sintaksnu proveru, naravno automatsku (C#, FxCop). Radeci tako, dosao sam u jednu skroz apsurdnu situaciju, nema commita dok ne ispravis svaku nepravilnost, a gomila tih neprovilnosti se odnosila da moras da identujes kako treba i da stavljas zagrade kako treba. Tada ti se upali lampica da sve vreme glumis tool za formatiranje umesto da se bavis samo programiranjem. Neko bi rekao da ovo moze da se automatizuje - i moze, ali cemu onda automatizacija noise-a?


Upravo zato su i smislili sintaksu koja naznačava ključnim rečima početak i kraj bloka. To omogućava da potpuno slobodno kucaš kod u okvru bloka, ne vodeći računa o identaciji i prelamanju redova.

[ peromalosutra @ 28.07.2017. 10:58 ] @
Kada se radi u timu onda tu nema mnogo diskusije.

Npr. meni je sa code review-a vracan kod samo zato sto sadrzi razmake na kraju linije (trailing space). I smatram da je to ok, jer je razlog sasvim jasan, dodavanje / brisanje ovih nebitnih i uglavnom nevidljivih karaktera unosi nepotreban sum u istoriju revizija (u nasem slucaju git) i nepotrebno zamara reviewer-a.

Rjesenje je vise nego jednostavno, provuci kod kroz style checking tool (npr. uncrustify za C++) i problem rijesen. Na ovaj nacin mogu da se fokusiram konkretno na problem koji rjesavam, a da se ne zamaram previse o stilu koji treba da pratim. Konzistentnost je u ovakvim slucajevima najbitnija.
[ Predrag Supurovic @ 28.07.2017. 10:59 ] @
Citat:
negyxo:
Pa i nema razlike u tome je stos :) Osim sto moras da se bakces sa zagradam za isti rezultat. Ja kada pricam o zagradama mislim na blokove, tj. otvaranje i zatvaranje istih. Ja apsolutno nikad ne gledam gde je pocetak zagrade da bi znao gde je pocetak bloka, nego gledam sta je identovano. Recimo sta ti je citljivije u ova dva slucaja:

Code:

public void Foo
{
DoSomething();
DoSomeOtherThing();
}

public void Foo
{
    DoSomething();
    DoSomeOtherThing();
}



Svi tako radimo. Ovo o čemu ti pričaš je čitkost koda i to nema veze sa sintaksom. Poneta ej da ako imaš sintaksno utvrđene oznake početk ai kraj koda možeš ceo kod da strpaš u jedju liniji, da ga izmoši kako god hoće, identiraš kako hoće, umečeš tabove, znakove razmaka i nove redove kako hoćeš, onj esintaksno ispravan. To ti daje slobodu upravo da ga vizuelno uobličiš tako da bude što čitkiji.

I što ej važnije, nećeš imati problem ni sa sitnansom ni sa izvršavanjem programa zato što si negde ubacio ili izostavo jedan hebeni znak razmaka.

Možda nisi ima prilike da se srećeš sa tim. Ja nažalost jesam, i da je bitan tab i da je bitan znak razmaka, čak i da je bitan novi red pa čak i da je negde bitan prazan red.

[ negyxo @ 28.07.2017. 11:04 ] @
Pa da, spominje se static checker jer je on bitan :) Upravo ta detekcija koju vidis u kompajliranim jezicima dolazi od static chekera, ali to je jedna u moru stvari. Recimo pogledaj ovaj primer:

Code:

class Person
{
    string Name;
    int Age;   
}

class Employee : Person
{
     int Experience;
}

class Company
{
    decimal CalculateSalaryBasedOnExperience(Employee e, decimal amount)
    {
         return amount * (1 + person.Experience / 80);
    }
}


Kako ti u dinamickim jezicima ogranicavas programera da prosledi instancu Employee-a nekoj utility funkciji? Jednostavno, nemoguce, mozes samo da dopunis sa testovima, ali testovi nikad nece biti precizni kao staticka analiza. U ovom prostom primeru mozes da ides u nedogled da budes sto striktniji i sto vise da ogranicavas sebe i druge sa statickom analizom. Recimo sta ce biti ako uradis:

Code:

var e = Employee() { Experience = -1 }


Neko bi rekao da bi ovo mogao da detektujes unit testovima. Ali zasto to kada mozes sebe da ogranicis opet sto vise:

Code:

// pseudo code, recimo u mnogim jezicima ne mogu primitivni tipovi da se naslede, ali lako je kreirati workaround

class Experience : int

       Experiance(int value)
       {
           if (value < 0 || value > 50)
               throw new ArgumentException(...);
       }
}

class Employee : Person
{
     Experience Experience;
}


Recimo, sledece na listi zahteva moze da bude da ogranicis ime, da mora da pocinje uvek velikim slovom, a da ne sme da bude duze od 50 karaktera. Pa recimo da Employee mora da iam neki posao, tj. moze da ima vise poslova, ali mora da ima bar jedan (recimo namestis genericku kolkciju koja mora uvek da ima makar jedan elemenat, nema potrebe da je proveravas za empty), itd. Sve ovo mozes da enforcujes kroz staticku analizu, zavisi samo koliko detaljno zelis i ima smisla da radis, ali u iole vecim projektima, ovo je jednostavno a must (na stanu to sto u 90% slucajeva to nije slucaj, bar sam ja tako stekao utisak, ljudi recimo pisu C# (ili Java) na isti nacin kao javascript). Static cheker ti pruza tu mogucnost da pises code tako da sam sebe (sebe i druge) ogranicavas svuda i uvek :)

[ negyxo @ 28.07.2017. 11:10 ] @
Citat:
Predrag Supurovic:
I što ej važnije, nećeš imati problem ni sa sitnansom ni sa izvršavanjem programa zato što si negde ubacio ili izostavo jedan hebeni znak razmaka.


Sve sto pises ima smisla ali za jezike bez provere. Uzmi haskell ili F#, oni imaju identaciju kao deo sintakse, ali oni ti i daju gresku kada pogresis identovanje prilikom kompajliranja :)
[ jablan @ 28.07.2017. 11:32 ] @
Citat:
negyxo:
moras da se zezas sa raznim testovima

Ne kontam šta znači "zezaš se sa raznim testovima". Da li te čekiranje statičkih tipova oslobađa pisanja testova?

Citat:
Rapaic Rajko:
Je li na to jablan mislio: 'sto ne platis na mostu, platis na cupriji', pisanje testova do besvesti upravo zbog nedostatka 'statike'..?

Da, na to sam mislio. Testovi se ne pišu do besvesti, pišu se da provere funkcionalnost nekog komada koda (ili više komada, kroz funkcionalne i acceptance testove). Sa dinamičkim jezicima, oni "hvataju" i greške tipova.

I to, hvala lepo, sasvim dobro funkcioniše i u "enterprise" okruženjima.
[ Branimir Maksimovic @ 28.07.2017. 11:33 ] @
negyxo napisa:
Citat:

Kako ti u dinamickim jezicima ogranicavas programera da prosledi instancu Employee-a nekoj utility funkciji? Jednostavno, nemoguce, mozes samo da dopunis sa testovima, ali testovi nikad nece biti precizni kao staticka analiza.

Nikako, ali zato dobijas gresku u funkciji ako pokusas pogresan tip da koristis kao Employee. Nema potrebe da proveravas, izbacice gresku i bez toga.
i opet se vracamo na pocetak. run-time error vs compile-time error, i to je to.
[ Predrag Supurovic @ 28.07.2017. 12:34 ] @
Citat:
negyxo:
Citat:
Predrag Supurovic:
I što ej važnije, nećeš imati problem ni sa sitnansom ni sa izvršavanjem programa zato što si negde ubacio ili izostavo jedan hebeni znak razmaka.


Sve sto pises ima smisla ali za jezike bez provere. Uzmi haskell ili F#, oni imaju identaciju kao deo sintakse, ali oni ti i daju gresku kada pogresis identovanje prilikom kompajliranja :)


Kako će kompajler da proveri da li sam ja nešto namerno identirao ili sam pogrešio pa nisam identirao?



[ Shadowed @ 28.07.2017. 13:13 ] @
Citat:
Branimir Maksimovic: run-time error vs compile-time error, i to je to.

Kako ovo nekome uopste moze biti dilema?
[ negyxo @ 28.07.2017. 13:20 ] @
@jablan

Mislim uglavnom na unit testove. Ja ih ne praktikujem u opste, dok recimo integration testove da, iz prostog razloga jer testiraju sirok spektar funkcionalnosti (tj. ja ih proteram kao smoke test, kada se promeni dosta, da vidim da radi bar osnovna funkcionalnost). Treba shvatiti sta testovi rade, oni su druga specifikacija (ili prva) i u osnovi se radi poredjenje jedne sa drugom i u tom mismatch-u se utvrdjuje gde je greska. Sasvim je OK da je jedna specifikacija validna a druga ne (tj. test ili sam program) ali ono sto je meni interesantno, da od ekipe koja je pro-tests, da ce uvek tvrditi da testovima mogu vise da uhvate nego kroz type sistem, ili da su im testovi garant funkcionalnosti, sto je OK, ali pobogu i taj deo moze da se opet daleko bolje automatizuje nego rucno da se pise, u umesto da se islo ka tome, dosli smo do toga da je sasvim OK pisate neke zaludne testove...


@Branimir Maksimovic
Ne znam da li vidis ali to sto dobijas u runtime-u gresku, to je veliki problem. U runtime dobijas gresku samo ako si program progurao u sve moguce state-ove. Znaci ne, neces ti dobiti runtime gresku cim pokrenes program, tj. mozes ako si ti srece, ali runtime greska moze da se vidi kroz odma, do bekonacno, uporedi to sa compile time, koji ti kaze odma i svuda. Velika je to razlika...
[ negyxo @ 28.07.2017. 13:23 ] @
Citat:
Predrag Supurovic:
Kako će kompajler da proveri da li sam ja nešto namerno identirao ili sam pogrešio pa nisam identirao?


Sad mozemo da teramo mak na konac, a kako ce kompajler da proveri da li sam stvarno hteo da zatvorim blok sa zagradom ili nisam. Na isti nacin dobijas poruku i o identaciji. Kompajler ne zna, ali ti javi da nesto nije u redu na isti kriptican nacin kada obrises slucajno (ili stavis) zagradu.
[ Branimir Maksimovic @ 28.07.2017. 13:38 ] @
Shadowed napisa:
Citat:

Kako ovo nekome uopste moze biti dilema?


Pa ne znam, sa obzirom da takvi jezici postoje , ocigledno da moze biti dilema....
[ jablan @ 28.07.2017. 14:06 ] @
Citat:
Shadowed:
Citat:
Branimir Maksimovic: run-time error vs compile-time error, i to je to.

Kako ovo nekome uopste moze biti dilema?

To je false dilema.

Dilema je zapravo compile-time error vs test-time error.
[ jablan @ 28.07.2017. 14:07 ] @
Citat:
negyxo:
Mislim uglavnom na unit testove. Ja ih ne praktikujem u opste

Kako onda znaš da ti funkcija radi ispravno? Static typing ti može garantovati da funkcija prima broj i vraća broj, ali ti ne garantuje da je broj tačan.
[ mmix @ 28.07.2017. 18:17 ] @
Citat:
jablan:
Citat:
Shadowed:
Citat:
Branimir Maksimovic: run-time error vs compile-time error, i to je to.

Kako ovo nekome uopste moze biti dilema?

To je false dilema.

Dilema je zapravo compile-time error vs test-time error.


As seen by TDD crowd a.k.a. kako naterati firmu da plati inzenjerske sate za nesto sto moze kompajler da resi
[ negyxo @ 28.07.2017. 19:05 ] @
@jablan
Citat:

Kako onda znaš da ti funkcija radi ispravno? Static typing ti može garantovati da funkcija prima broj i vraća broj, ali ti ne garantuje da je broj tačan.


O da, moze, samo sto u slucaju type sistema to deluje glupo da radis, ali u slucaju unit testova to je sasvim OK.

Ja bi mogao bez problema da definisem tip, koji ce biti nesto ovako:

edit: Zaboravio sam da stavim link od wikipedia-e, gde se demonstritra unit test https://en.wikipedia.org/wiki/Unit_testing, posto je primer vezan za to.

Code:

class AdderResult : int
{
     AddedResult(int value)
     {
          if (!(value == 1 || value == 2 || value == 3 || value == 4 || value == 2222))
               throw new ArgumentException("Invalid value");
     }
}

class AdderImpl implements Adder {bbbbbbg
    public AdderResult add(int a, int b) {
        return new AdderResult(a + b);
    }
}


I eto, type sistem garantuje da je uvek vracen rezultat koji je definisan u specifikaciji. Ali ocigledno je da je intent da hoces da testiras funkciju sabiranja, i onda je ocito da su sve vrednosti integera zadovoljene, tako da je ovaj primer sa wikipedia-e malo los za demonstraciju ovoga ali i samog unit testa.

Ono gde unit testovi imaju prednost je "snapshot specifikacije", tj. ti imas odredjenu verziju unit testova koja moze biti "out of sync" sa trenutnom implementacijom i tu mozes uhvatiti greske. Tipa imas funkciju da ti vrati, recimo, neki hash, i hoces da jednom kada je razvijes za istu ulaznu vrednost svaki put da dobijes istu izlaznu vrednost, ali recimo krenes nesto vremenom da optimizujes i negde u nekoj hierarhiji promenis code i namestis bug. Unit testovi ti ovo mogu validirati (mada moze i ova smesna konstrukcija gore ali tek u runtime) ali generalno ja nikad nisam imao potrebu za tim, type sistem vec i ovako mi proverava gomilu stvari u svim slucajevima. Ono oko cega dolazi zbun je upravo promena code-a, jednom kada promenis code, promenio si specifikaciju. U sustini ovo meni nikad nije bilo problem i obican smoke test otkriva vecinu stvari ako ga type sistem propusti... no cak i da cepidlacimo, zasto pobogu da radim rucno testove (a da, ja ih ne pisem u opste :)), ali hocu reci, ako neko zaista razume svrhu testova, onda bi trebalo da je skroz za full type system support i automatsko testiranje (ne znam iskreno kakvo je stanje danas kada je u pitanju automatika ali MS je imao u planu tool koji upravo radi to, tamo negde oko 2008, bili su odlicni videi, tool je najavljivan na veliko, ali u sustini to niko nije razumeo, tako da se ostalo na rucnom kucanju).

I na kraju dodjemo do onog sto je mmix rekao, gomile resursa ulozeno u to da se temeljno pisu programi i na to su skripteri pljunuli u lice svim PhD-ovima, inzinjerima i svim ostalima koji su ulozili svoj trud u razvoj raznih alata kako bi programiranje svima bilo lakse i manje kostalo... ali najgore od svega je, sto je recimo neko poput MS popustio (google je davno skontao foru, pa je uglavnom bio u fazonu samo daj community-u a para neka se valja :))

Ja recimo nisam ni dotakao temu alata, to je posebna prica. Bez type sistema ne mozes praviti kvalitetan alat (tj. mozes ali onda radis upravo ono sto ti pruza type sistem na mnogo rudimentarnijem nivou :))

[Ovu poruku je menjao negyxo dana 28.07.2017. u 21:00 GMT+1]
[ jablan @ 28.07.2017. 20:07 ] @
Ja koliko znam, i u statički tipiziranom svetu pišu se unit testovi.

BTW mmix, nisi mi odgovorio da li si u onoj poruci malo mešao dinamičko i weak tipiziranje. Mislim nije lepo da tako pasionirano pljuješ nešto o čemu imaš površno znanje i ne previše iskustva.

A ja još ne videh kako to kompajler rešava pitanje unit testova. Čime tačno zameniš ovo:

Code:

def add(a, b)
  return a + b
end

assert_equal(5, add(2, 3))


Interfejsom FunkcijaKojaZaParametre2i3DajeRezultat5 koji će tvoja funkcija da implementira?

Inače, da se razumemo, potpuno shvatam prednosti statički tipiziranih jezika, ali nemojmo pričati bajke.
[ Branimir Maksimovic @ 28.07.2017. 21:45 ] @
Citat:
negyxo:
@jablan
Citat:

Kako onda znaš da ti funkcija radi ispravno? Static typing ti može garantovati da funkcija prima broj i vraća broj, ali ti ne garantuje da je broj tačan.


O da, moze, samo sto u slucaju type sistema to deluje glupo da radis, ali u slucaju unit testova to je sasvim OK.

Ja bi mogao bez problema da definisem tip, koji ce biti nesto ovako:

edit: Zaboravio sam da stavim link od wikipedia-e, gde se demonstritra unit test https://en.wikipedia.org/wiki/Unit_testing, posto je primer vezan za to.

Code:

class AdderResult : int
{
     AddedResult(int value)
     {
          if (!(value == 1 || value == 2 || value == 3 || value == 4 || value == 2222))
               throw new ArgumentException("Invalid value");
     }
}

class AdderImpl implements Adder {bbbbbbg
    public AdderResult add(int a, int b) {
        return new AdderResult(a + b);
    }
}


I eto, type sistem garantuje da je uvek vracen rezultat koji je definisan u specifikaciji. Ali ocigledno je da je intent da hoces da testiras funkciju sabiranja, i onda je ocito da su sve vrednosti integera zadovoljene, tako da je ovaj primer sa wikipedia-e malo los za demonstraciju ovoga ali i samog unit testa.


Pa cek koja razlika izmedju ovoga i dynamic tipa? Ovde na pogresnu vrednost izbacuje gresku a tamo ce i na tip ;p
U principu veca je verovatnoca da ce neko da se doseti u nekoj buducnosti da baci u f-ju 0 i 1 nego da ce da promasi tip....

[ Branimir Maksimovic @ 28.07.2017. 22:46 ] @
Citat:
jablan:
BTW mmix, nisi mi odgovorio da li si u onoj poruci malo mešao dinamičko i weak tipiziranje. Mislim nije lepo da tako pasionirano pljuješ nešto o čemu imaš površno znanje i ne previše iskustva.

Jablane ovo je napisao dusans:
Citat:

Ni jedan ni drugi ne pričaju o interpretiranju, već o static/strong vs weak/dynamic typing.


Dakle static typing: weak/strong , dynamic typing: something else ;)
[ mjanjic @ 28.07.2017. 22:50 ] @
Kad su u pitanju "loosely (weakly) typed" jezici, kao npr. JavaScript, kako da budete sigurni da je u nekoj HTML formi u polju za unos celog broja JS kod stvarno tretirao tu vrednost kao ceo broj? Pa, lepo, morate uvek koristiti parseInt(). Ali, šta ako hoću u nekom trenutku toj promenljivoj da dodelim float ili string, pa zaboravim da sam dodelio string i nastavim kasnije da radim sa njom kao da je ceo broj?

Sa jedne strane, "strongly typed" jezici sprečavaju da pomešate tipove podataka, ali zato "loosely typed" omogućuju da iskoristite istu promenljivu za različite tipove podataka kada je to pogodno, čime se smanjuje broj promenljivih, ali se i povećava mogućnost za grešku.

Ono što je po jednom kriterijumu prednost, po drugom može dovesti do bagova, a ono što je po jednom kriterijumu ograničenje, po drugom može biti prednost u smislu lakšeg otkrivanja logičkih grešaka u kodu.


Sa druge strane, Unit i drugi testvoi se ne pišu zato što se nekome ćefnulo, nego to najčešće traže klijenti (i plaćaju to). Tamo gde ne traže klijenti, a rade se testovi, uvedeni su od strane firme za proizvode koji će postojati duži niz godina i u budućnosti će se nadograđivati, ljudi na razvoju tog proizvoda će se menjati, pa novi koji dođu će teže napraviti greške koje ih kasnije mogu poprilično koštati - postoji teorijska kriva troškova, gde su najveći troškovi jurenja bagova kada je proizvod maltene završen, i dosta je jeftinije uraditi npr. Unit testove nego kasnije juriti bagove u milion linija koda.

Naravno, za male projekte je besmisleno trošiti vreme na to, tako da iskustva sa malih projekata nisu reprezentativna za priču o testovima.
[ Branimir Maksimovic @ 28.07.2017. 22:55 ] @
Ajmo ovako. Weak type jezik je onaj koji nema nikakav type checking ili ima implicitne konverzije. To nema veze sa dinamickim tipovima.
[ jablan @ 29.07.2017. 06:40 ] @
Tako je. A mmix je u ranijoj poruci napisao:

Citat:
Dobro, lenje ako ti to vise odgovara, posto znam da znas ali te ocigledno mrzi jer je tu ruby da te pusta da radis sta hoces

...

Jbg, sta cu, opterecen sam tim stvarima, to me je nerviralo jos od VBScript dana gde je "12" + "5" bilo 17, ali nedefinisanih 17 koji postoje u limbu u onim ocajnim Variant strukturama.


Što nije tačno, jer te, konkretno ruby (a ni python) NE puštaju da radiš šta hoćeš, nisu weak typed, i ne možeš da sabiraš babe i žabe, osim ako nisi eksplicitno napisao metodu za sabiranje baba i žaba.

I nije tačno da te korišćenje statički tipiziranog jezika automagično oslobađa potrebe da pišeš unit testove. Tačno je da pomaže otkrivanju nekih grešaka u compile time, omogućava bolju analizu koda od strane npr. IDE-a, i u nekim (ponavljam nekim) slučajevima poboljšava razumljivost koda (kontraprimer je ovaj odozgo negyxov gde praviš poseban interfejs da bi simulirao testiranje). Ali apsolutno ne garantuje ispravnost tvog koda, niti garantuje da nećeš imati runtime greške (posebno kod nullable types).
[ negyxo @ 29.07.2017. 07:03 ] @
@jablan
Citat:

Ja koliko znam, i u statički tipiziranom svetu pišu se unit testovi.


Na zalost pisu. To je upravo odlika onih koji ne znaju sta bi radili sa type sistemom i kojima je svejedno da li rade javascript, php, c++, C#, java, haskell, F# itd. Znas kako "funkcija je funkcija, petlja je petlja, if je if, nema tu mnogo razlike" filozofija :)


Digresija: prosle godine sam konkurisao za jednu firmu, remote work C#, dosta je ima na oglasima na SO, da je ne reklamiram, rekoh sebi da okusam srecu. Uglavnom, prvo dobijes pitanja pa zatim zadatak. Kada sam dobio zadatak, koji je manje vise bio neki mini web servis, dobio sam zahtev da se to lepo dokumentuje i napisu unit testovi, inace se ne prihvata kao validno resenje bez toga. Cim sam dobio zadak, samo sam im zahvalio i rekao da unit testove ne treba da radis u C#, tj u strongly typed jezicima i da neko ne razume bas najbolje C#. Nope, ne zelim da radim u startu sa takvima i govori mi u startu o kolicini njihovog znanja kao i filozovije (mogao bi se kladiti da je sledeca stvar na meniu DI :))


Citat:

A ja još ne videh kako to kompajler rešava pitanje unit testova. Čime tačno zameniš ovo:


Ali zasto bi ih resavao. (samo da napomenem, primer koji si dao je skroz neadekvatan isto kao i onaj sa wikipedia, masi se skroz poenta). Zatim deo koji se testira je minoran i skoro pa nebitan u odnosu na ceo eco system. Type sistem ti nudi kompletnu drugu vrstu provere, ne ovu, ona koja je najmanja bitna, a to je lokalna funkcionalnost. Recimo, u C# ti moras bar jednom kada pises svoju f-ju da je proveris i svaki sledeci put kad je nesto menjas - to je jedini "a must". Sve ostalo ti type sistem garantuje. Nija stvar u tome da znas da funkcija lokalno dobro radi, nego da ona u celom ekosistemu ne remeti red.

Cak da uzmemo i ovaj primer sa dodavanjem, sta konkretno on demonstrira, tj. testira? Bez tipova to nekako jos deluje i da ima smisla, sa tipovima ne. Pricamo o konkretnom primeru, sto znaci da je ceo itnent da ti zelis garanciju da ces dobiti uvek broj sabiranjem dva broja. To je sve sto ja mogu da zakljucim. Definisanjem tipa, recimo u C#, ja znam da je ovaj slucaj zadovoljen i na dalje type sistem preuzima proveru code-a i nema ptrebe ja rucno da bilo sta kucam.

Recimo:

Code:

int Add(x, y) => x + y

class Control
{
    int CalculateAbsoluteX(x) => Add(Control.Left + x)

    int CalculateAbsoluteY(x) => Add(Control.Top + y)
}


Sta ces ti dobiti ako testiras Add funkciju? Apsolutno nista, imas garant type sistema da vraca integer. Ali, ako zato recimo promenis taj deo u:

Code:

double Add(x, y) => x + y


Type sistem ce ti se odma pobuniti i reci da si prekrsio contract u svim slucajevima. Kako to postizes testovima? Tako sto moras da pokrijes svaki poziv, svaku kombinaciju svih poziva funkcija i napises gomilu code-a koji opet nece biti precizan kao type sistem. I tu lezi ta moc, ne da testiras loklano, to radis dok razvijas, i dok god ispunjavas contract, dotle nema bojazni, a cak i kada prekrsis tu je type sistem da te podseti.

No, cak i ako ti to nije dovoljno i hoces da imas kroz staticku proveru, onda recimo imas Code Contracts. Njegov static checker ce ti upravo dati opciju da enforce-ujes constrainte sa vrednostima :)

Ako to nije dovoljno, mogao bi da napises svoj static checker koji ce da radi proveru :)

Ako i to nije dovoljno, mozes da automatizujes (tj. potencijalno je moglo) testove daleko bolje nego ti rucno da ih pises.

No samo da napomenem, meni svi ovi primeri nemaju smisla, svaki put kada vidim unit testove izgledaju ko cherry picking i osecam se ko budala koja ispunjava neki ritual :) Cak i kada sam na svom projektu pokusao da koristim Code Contracts, bas upravo zbog ovih stvari, verujuci da unit testovi imaju neki added value, zazalio sam. Kolicina noise koja se tako pravi je jednostavno ogromna naspram added value-a (koji je po mom misljenju skoro pa neprimetan).
[ negyxo @ 29.07.2017. 07:12 ] @
Citat:

Pa cek koja razlika izmedju ovoga i dynamic tipa? Ovde na pogresnu vrednost izbacuje gresku a tamo ce i na tip ;p
U principu veca je verovatnoca da ce neko da se doseti u nekoj buducnosti da baci u f-ju 0 i 1 nego da ce da promasi tip....


Ne razumem sta je ovde a sta je tamo :)

Nije fora u tome sto ces ti da dobijes runtime gresku kada pogresno inicializujes, nego u tome da svuda nadalje u sistemu imas contract za koji te type sistem upozorava ako pokusas da se igras :)
[ negyxo @ 29.07.2017. 07:16 ] @
Citat:
jablan
I nije tačno da te korišćenje statički tipiziranog jezika automagično oslobađa potrebe da pišeš unit testove. Tačno je da pomaže otkrivanju nekih grešaka u compile time, omogućava bolju analizu koda od strane npr. IDE-a, i u nekim (ponavljam nekim) slučajevima poboljšava razumljivost koda (kontraprimer je ovaj odozgo negyxov gde praviš poseban interfejs da bi
simulirao testiranje). Ali apsolutno ne garantuje ispravnost tvog koda, niti garantuje da nećeš imati runtime greške (posebno kod nullable types).


Ja nisam rekao da pravis poseban interface, nego tip, koji ce nositi informaciju o specifikaciji, posto je primer los, onda ti ne treba tip u opste, nego mozes da koristis obican int.

Sto se tice nullable, to jeste najveca boljka, bar meni, ali cak i tu ima leka, Code Contracts (bljak :)) i jos bolje F# (ili za van .NET-a Haskell) :)
[ Branimir Maksimovic @ 29.07.2017. 07:19 ] @
negyxo napisa:
Code:

To je upravo odlika onih koji ne znaju sta bi radili sa type sistemom i kojima je svejedno da li rade javascript, php, c++, C#, java, haskell, F# itd. Znas kako "funkcija je funkcija, petlja je petlja, if je if, nema tu mnogo razlike" filozofija :)


Heh, probaj u Haskell-u da radis neko vreme,(nema ni varijable ni petlje ;p)
Funckionalno programiranje je dijametralno suprotno imperativnom programiranju to su dva razlicita sveta.
[ negyxo @ 29.07.2017. 07:37 ] @
Branimire, ne znam da li si skontao, ali nisam ja taj koji tako misli, nego upravo ekipa kojoj je sve isto. Cak sta vise, jedan od razloga zasto zelim da pobegnem iz C# sveta je upravo ta: TDD, Dependency Injection, Factory Pattern, Visitor Pattern, generalno design patterni itd. Gomila nekog buzzworda s cim se ljudi gadjaju i onda im dodjes na projekat i vidis monolitne strukture sa sve nekim spageti, ali tu su patterni, testovi itd. nigde ni govora o tome da iskoristi prvo type sistem. U F# kontam da je daleko manje tih hypera, samo zasto sto je mnogo teze uci u taj svet. I da moj omiljen twit :)

https://twitter.com/jeroldhaas/status/535919819355598848
[ Branimir Maksimovic @ 29.07.2017. 08:12 ] @
Heh, buzzwordi za patterne su bili jako popularni oko 2000te godine. Vise manje fabrike i wrapperi su svuda potrebni, visitor redje ;)
U principu hijerathije klasa i te fore su sada out. In je funkcionalno programiranje .... a da i sa extreme programming su davili isto pre jedno 10-15 godina.
Ako volis F# probaj Ocaml posto je F# odatle pokupio fore. ili ML to je ta grupa jezika, neki hibrid izmedju imperativnog i funckionalnog programiranja.
[ negyxo @ 29.07.2017. 08:46 ] @
Nije stvar da li su patterni potrebni, ali kada naucis da postoji tamo neki pattern i onda guras svuda i uvek, onda je to problem, a recimo za type sistem nemas pojma cemu sluzi. Tako je recimo bilo pre jedno 8, 9 godina, recimo bas sam ovde na ES pisao, recimo upotreba interface-a, granicila se sa ludilom, danas nije nista bolje, samo dodas sada i razne patterne, containere itd. overbloat^2
[ suncokreet @ 29.07.2017. 10:11 ] @
Citat:
Branimir Maksimovic:n je funkcionalno programiranje ....


Ja nešto nisam primetio da je u Srbiji tako. Misliš generalno u svetu da je in?
[ Branimir Maksimovic @ 29.07.2017. 10:13 ] @
U Srbiji ne znam kako je ;) Da usve tu, pa vidi samo kolko je jezika uvelo anonimne f-je u zadnje vreme ;p

edit:
i da pogledaj kolko je chainovanje metoda tj kompozicija f-ja popularno. To su sve fore iz funkcionalnog programiranja,
koje potice od tzv curringa gde f-ju sa dva argumenta razbijas na dve f-je sa po jednim argumentom gde je rezultat jedne argument
druge.


[Ovu poruku je menjao Branimir Maksimovic dana 29.07.2017. u 11:30 GMT+1]
[ negyxo @ 29.07.2017. 12:16 ] @
BTW. Nisam mogao juce da nadjem automated testing tool sto je MS razvijao, ali evo napokon sam iskopao:

https://channel9.msdn.com/Blog...with-Pex-in-Visual-Studio-2008

Mala digresija samo, PEX nije random generator, PEX upravo koristi staticku analizu da infer-uje ulazne vrednosti (BTW. Sada se zove valjada IntelliTest).

[ mjanjic @ 29.07.2017. 14:45 ] @
Neki izgleda misle da se Unit testovi pišu samo da se ne bi zabrljalo sa tipovima podataka, a sam naziv se u stvari odnosi na testiranje DELA programa/softvera (u principu, treba uzeti najmanju celinu koju je moguće i ima smisla testirati), pri čemu se pri tom konkretnom testiranju za ostatak softvera uzima da funkcioniše pravilno (npr. pri testiranju unosa i obrade podataka, koristi se poseban softver koji će da lažira uspešno upisivanje u bazu, pošto recimo taj segment ne želimo da testiramo u tom trenutku ili još nije spreman za testiranje).

To ne znači da je dovoljno da testiramo neku našu klasu i to je to, već se mora uzeti neka veća celina, npr. više klasa ili modula između kojih postoji značajna komunikacija.



Najbanalniji primer bi bio U/L fajla, pri čemu se zahteva određeni tip. Ali, kako korisnik može greškom postaviti fajl koji ima pravilnu ekstenziju, a sadržaj nije u skladu sa ekstenzijom (npr. ljudi često *.DOC fajlovima samo promene ekstenziju u *.DOCX i misle da je to u redu, pa recimo MS-ov File Formats Convertor ne radi kako treba ako je u pitanju .docx fajl sa .doc ekstenzijom), šta će se desiti sa programom?

Bilo bi suludo da ceo sistem padne ako se postavi u formu pogrešan fajl (npr. online galerija slika koja očekuje .jpg ili .jpeg format slike, a neko postavi .png ili .gif).
Ili, očekuje se XML sa određenim tagovima, a korisnik postavi XML u kome je nešto ručno menjao ili struktura nije onakva kakvu program očekuje.

Testiranje služi tome, a ne da se testiraju pojedinačne klase ili funkcije, a opet, ne može se čekati "production" verzija da se započne sa testiranjem, jer je onda mnogo teže (i skuplje) pronaći greške.

[ Branimir Maksimovic @ 29.07.2017. 14:55 ] @
Tesko onom ko se oslanja na tudj softver prilikom integracionih testova ;p
[ Rapaic Rajko @ 31.07.2017. 08:04 ] @
Citat:
Branimir Maksimovic:
Rajko govorili smo o dynamic/static types ;)
A ti sad pricas o interpretiranju/kompajliranju ...


Ne, dobro sam razumeo o cemu se pisalo. Samo kazem, kao nativni Pascal programer (mnogo pre Delphi-ja) koji je navikao na 'strict typed' (prastajte na izrazu) programski jezik (jer Pascal to jeste), malo su mi cudni/strani svi jezici koji daju toliku slobodu u pisanju koda.
Sad, da li je u pitanju compiler ili interpreter, o tome nisam ni razmisljao.

Pozz
[ Predrag Supurovic @ 31.07.2017. 12:46 ] @
Citat:
negyxo:
Citat:
Predrag Supurovic:
Kako će kompajler da proveri da li sam ja nešto namerno identirao ili sam pogrešio pa nisam identirao?


Sad mozemo da teramo mak na konac, a kako ce kompajler da proveri da li sam stvarno hteo da zatvorim blok sa zagradom ili nisam. Na isti nacin dobijas poruku i o identaciji. Kompajler ne zna, ali ti javi da nesto nije u redu na isti kriptican nacin kada obrises slucajno (ili stavis) zagradu.


Ne može se to porediti. Kada obrišeš greškom ili staviš višak znak koji označava blok, to će se negde manifestovati kao sintaksna greška, pa makar skroz na kraju koda. Ako omaneš u identaciji, to uopšte ne mora da bude sitnaksno netačno.

[ negyxo @ 31.07.2017. 14:54 ] @
Khm, pa isto ce se manifestovati i kada imas indentaciju, tj. ne znam kako ostali rade, ali u F# je tako. Cim omasis indentaciju, kompajler ce se zaliti, jednostavno jezik je tako dizajniran da svaki expression ima tacno sta ocekuje, pa je sansa da ces da promasis veoma mala. Mislim da je najbolje prvo probati pa onda reci da ne valja, ovako deluje da postoji problem gde realno ne postoji (recimo, meni je veci problem discoverability, intelisense daleko bolje radi recimo u C# nego F#, i ovo nije problem do tool-inga nego do API, recimo funkcija find nad listom, prvi argument je funkcija, drugi je lista, intelisense u tom slucaju ne moze da pomogne jer kucas s leva na desno :), recimo zato je LINQ "obrnut" u odnosu na SQL).
[ Bradzorf012 @ 01.08.2017. 03:00 ] @
Može li neko da mi objasni razliku između kompajlera i interpretera i da mi navede primere, bio bih mu jako zahvalan.
[ jablan @ 01.08.2017. 06:17 ] @
Interpreter izvršava izvorni program (sors) koji mu daš. Kompajler ga prevodi u neki oblik koji je prilagođeniji izvršavanju i ne izvršava ga.

Granica je dosta mutna pošto i interpreter obično prvo prevede sors u neki oblik koji je prilagođeniji izvršavanju, ne izvršava program liniju po liniju iz sorsa.

Primeri: kompajler - gcc, interpreter - JS engine u tvom browseru.
[ mjanjic @ 01.08.2017. 09:47 ] @
Većina kompajlera radi slično (mislim na rezultat), a interpreteri su napredovali tako da koriste nešto slično keširanju, tj. često pozivane funkcije i ostale delove koda prevode u neki binarni oblik koji se brže izvršava (primer je sa MS-ovim IIS, kod koga skripte mogu biti u bilo kojem od podržanih jezika, pa i VB, C++..., ali se često pozivani delovi privremeno kompajliraju u binarni izvršni kod, čak i sam programer može to uraditi ručno, tj. kreirati .dll fajl ili šta već).

Praktično, mnogi interpreteri funkcionišu kao JIT (Jut-in-Time) kompajleri.