Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Programer Pocetnik

[es] :: C/C++ programiranje :: Programer Pocetnik

Strane: << < .. 2 3 4 5 6 7 8 9

[ Pregleda: 118239 | Odgovora: 164 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Programer Pocetnik28.07.2017. u 10:59 - pre 81 meseci
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.


 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Programer Pocetnik28.07.2017. u 11:04 - pre 81 meseci
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 :)

 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Programer Pocetnik28.07.2017. u 11:10 - pre 81 meseci
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 :)
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Programer Pocetnik28.07.2017. u 11:32 - pre 81 meseci
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.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p1-76.bvcom.net.



+1064 Profil

icon Re: Programer Pocetnik28.07.2017. u 11:33 - pre 81 meseci
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.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Programer Pocetnik28.07.2017. u 12:34 - pre 81 meseci
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?




 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12846



+4783 Profil

icon Re: Programer Pocetnik28.07.2017. u 13:13 - pre 81 meseci
Citat:
Branimir Maksimovic: run-time error vs compile-time error, i to je to.

Kako ovo nekome uopste moze biti dilema?
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Programer Pocetnik28.07.2017. u 13:20 - pre 81 meseci
@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...
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Programer Pocetnik28.07.2017. u 13:23 - pre 81 meseci
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.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p1-76.bvcom.net.



+1064 Profil

icon Re: Programer Pocetnik28.07.2017. u 13:38 - pre 81 meseci
Shadowed napisa:
Citat:

Kako ovo nekome uopste moze biti dilema?


Pa ne znam, sa obzirom da takvi jezici postoje , ocigledno da moze biti dilema....
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Programer Pocetnik28.07.2017. u 14:06 - pre 81 meseci
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.
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Programer Pocetnik28.07.2017. u 14:07 - pre 81 meseci
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.
 
Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6041



+4631 Profil

icon Re: Programer Pocetnik28.07.2017. u 18:17 - pre 81 meseci
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
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ć
 
Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.dynamic.isp.telekom.rs.



+171 Profil

icon Re: Programer Pocetnik28.07.2017. u 19:05 - pre 81 meseci
@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]
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Programer Pocetnik28.07.2017. u 20:07 - pre 81 meseci
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.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p1-76.bvcom.net.



+1064 Profil

icon Re: Programer Pocetnik28.07.2017. u 21:45 - pre 81 meseci
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....

 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p1-76.bvcom.net.



+1064 Profil

icon Re: Programer Pocetnik28.07.2017. u 22:46 - pre 81 meseci
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 ;)
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 2679



+690 Profil

icon Re: Programer Pocetnik28.07.2017. u 22:50 - pre 81 meseci
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.
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
c-bg-d-p1-76.bvcom.net.



+1064 Profil

icon Re: Programer Pocetnik28.07.2017. u 22:55 - pre 81 meseci
Ajmo ovako. Weak type jezik je onaj koji nema nikakav type checking ili ima implicitne konverzije. To nema veze sa dinamickim tipovima.
 
Odgovor na temu

jablan

Član broj: 8286
Poruke: 4541



+710 Profil

icon Re: Programer Pocetnik29.07.2017. u 06:40 - pre 81 meseci
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).
 
Odgovor na temu

[es] :: C/C++ programiranje :: Programer Pocetnik

Strane: << < .. 2 3 4 5 6 7 8 9

[ Pregleda: 118239 | Odgovora: 164 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.