Programer Pocetnik

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:



ako cu da ga indentiram:


ne vidim neko konkretnu prednost ovog drugog, niti vidim kako bi mi sintaksa bez zagrada pomogla

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

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.

wow enterprise, krenuli smo sa teškom artiljerijom...

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.

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

Ma to dynamic vs static typing je pitanje dal greske o pogresnim tipovima dobijas u run-time ili compile-time, big deal ;p

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 :)

O cemu ti pricas? O dokazivanju korektnosti programa ili o statickim tipovima? Nisi bas razumljiv ;p

Potpis

Blessed are those who can laugh at themselves, for they shall never cease to be amused.

Ne znam sta bi trebalo da predstavlja "dokazivanje koreknosti". Ja pricam o validnosti programa kroz static cheking, sto se odnosi na staticke tipove.

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 :)

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

Rajko govorili smo o dynamic/static types ;)
A ti sad pricas o interpretiranju/kompajliranju ...

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.

Cekaj sad i ti govoris o kompajliranju vs interpretiranja?

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 :)

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

Š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.



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


[/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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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 ;)

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



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.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

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.