Da li je greska birati VB.Net

Moje pitanje se odnoslio isto na ovaj drugi deo oko dynamic typing-a, ne ovo sto je jablan spomenuo. Po tome je c# strongly typed, dok VB nije. Ta implicitna konverzija me je i nervirala kod VB6, tako da sam svuda koristio CString, Cint itd. Nego ono sto sam zeleo reci je - da je dynamic typing nepozeljan na dosadasnji nacin. A sta bi znacilo dosadasnji nacin? Pa ako se pogleda zasto je nastao dynamic typing, razlog su neke zaista mocne programske konstrukcije. Recimo kod javascripta, mmix spomenu prototypes, ili duck typing gde se zaista jako lako manipulise podacima ali problem u celoj toj prici je da je kompajler ne obavestren o cemu se radi a i to iz jednog razloga, da bi se omogucila ova dinamicna izrada programa, sto je po meni apsolutna glupost, jer, ovo ce mozda zvucati cudno, ako programer, covek zna da postoji greska ne vidim razlog zasto ne bi znao i kompajler. Problem su samo ne dovoljno razvijeni kompajleri ali i ovo ce izgleda da se promeni, c# 3.0 vec uveliko pozajmljuje neke stvari od Lispa i slicnih programskih jezika i sve to uz strong type. Recimo, ako se neko igrao sa Orcas, mogao je videti sta radi intellisense sa lambda konstrukcijama tj. sa type inference pogotovo u kombinaciji sa anonymous type, gde intellisense izbaci tooltip sa anonymous type-om koji se koristi u lambda konstrukciji. Ne znam, mozda ce neko reci nista narocito, ali meni je ovo izvuklo osemeh na licu

A evo i jedan korisan link o tipovima provera (doduse blog je, ali ima dosta lepih clanaka o novom c#)
http://blogs.msdn.com/wesdyer/.../12/20/types-of-confusion.aspx

Hvala, hvala :)

Međutim, autor teksta (kao i većina diskutanata ovde) izgleda nije upoznat sa inferencom tipova kod statičkih jezika: http://www.novetehnologije.com/Default.aspx?tabid=96 i http://boo.codehaus.org/Type+Inference

Nažalost većina popularnih statičkih jezika nema inferencu tipova, ali će neki da je dobiju u skoroj budućnosti (C#, C++) a ostali će nadam se da crknu i propadnu (Java) i budu zamenjeni boljim jezicima (Scala) :)

Sve u svemu, radio sam dosta i sa jednim i sa drugim jezicima i kao što rekoh "na malo" dinamički zaista imaju svojih prednosti, ali za komplikovanije projekte - neka hvala :)

Potpis

IOCC

Sta se desava kod Type Inference-a u situaciji var x=5? Da li je to byte, int16, int32...?
BTW, citao sam ali zaboravih, da li se T.I. planira za VB u novoj verziji? Rekao bih da da, ali nisam siguran.

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

U c# mislim da je int32 ali to moze da se razlikuje od kompajlera do kompajlera. Verovatno je sve stvar dogovora, kompromisa. Doduse u .NET ce se verovatno ici da ako je var x = 5, bude int32 i u VB-u kada se otkuca dim x = 5, cisto da ne bude zabune tokom prelaska sa jednog na drugi jezik, da bude 'known behavior'
Sto se VB-a tice, cim ima mogucnost za LINQ manipulaciju mora da ima i TI, doduse ne mora ali onda bi zaista bilo veselo.

Da li to mislis na sistem provere kod dnamickih jezika ili na dinamcike feature dinamickih jezika. Jer slazem se da dosadasnji dinamcki jezici su nocna mora za bilo kakav iole veci rad ali neki feature-i dinamickih jezika su zaista dobri, i ne vidim zasto bi smetali u vecim projektima. Ali, ponavljam, trebalo bi razgraniciti tu proveru od samih mogucnosti dinamickih jezika, jer c# 3.0 ce imati neke dinamicke osobine a da je i dalje static type jezik.

Ja nisam bio upoznat. Međutim, koliko vidim, type inference je tu samo zbog štednje kucanja, a ustvari ne rešava probleme koje adresira dinamičko tipiziranje (samo izdaleka liči). I dalje nećeš moći funkciji da proslediš bilo šta, tj. i dalje ćeš morati da restruktuiraš program, praviš nove interfejse i apstraktne klase kadgod budeš na primer hteo da iskoristiš parče koda na dve različite klase (videti Ekelov primer sa speak() metodom).

BTW, Ekel u drugom članku dotiče type inference i kaže sličnu stvar:


Drugo, statični jezici definitivno ne rešavaju problem sloppy programera. Koliko puta sam video kako se u npr. ArrayList trpa sve živo, pa se posle kastuje nazad zato što programera mrzi da iskodira tipiziranu kolekciju (sad postoje generičke kolekcije, ali opet niko lošeg programera neće da natera da ih koristi). To su takođe greške gde vam kompajler neće pomoći...

Jablane, TI nije bas zamena za stednju u kucanju. U vecini slucajeva moze da se koristi tako ali najfunkcionalnija primena je u deklarisanju ad-hoc objekata i ovo donekle pruza neke osobine dinamickih jezika. Po meni dynimc typing moze da dovede do samo lose organizacije koda, jer tamo je sve u fazonu "podrazumeva se" sto je jasno samo onome ko pise taj program i nikom vise, zobg ovoga kompajler i ne moze da zna o cemu se radi.

Ovo je tacno, ali boxing je ujedno i jedini aspekt c#-a koji je podlozan ovome. Za to sluzi ovaj VS regular expression pattern : i ocekujem objasnjenje za svaki match koji nije auto-generisan. Moras priznati da je jednostavnije od pokusavanja da provalis na sta tip lici u kom trenutku izvrsavanja.

Ja jesam, i opet se slazem sa tobom, infered tipovi su i dalje staticki tipovi, samo se kompajleru daje voljno da sam protumaci tip na osnovu inicijalne dodele. Nema tu nikakve magije, to je jednostavno privid dinamicnosti kroz "varanje" Kunem se, mislim da ovo nikad ne bi ubacili u C# da im nije trebalo kao platforma za anonymous tipove u LINQ-u. Za sve ostale primene infered tipovi jednostavno nemaju smisla.

I sad meni neko hoce da kaze da je dinamicnost dobra Ma daj, ako ja treba stalno da "citam misli" kompajleru onda ode mas' u propas'.


Slazem se sa prvim delom, ali ne i sa drugim. Zaista je more typing u samom programu, ali ne slazem se da mi kompajler ne daje nista interesantno, daje mi potvrdu da program nece puci zbog nestabilnosti tipova.
Necu ni da komentarisem ovaj new age movement oko testiranja, testiranje je veoma dobar pristup, ali talking about overdoing it... Da bi tvoj dinamicki kod stvarno bio u potpunosti istestiran par-to-par sa ekvivalentnim statickim kodom tvoji testovi moraju da sadrze sve provere koje bi inace staticki kompajler obavio tokom builda. Suma sumarum kolicina koda koju napises mora biti veca u dinamickom aspetku od statickog zato sto staticki kompajler to vec ima ugradjeno i ne mora biti predmet testiranja Ako nije vise koda onda nisi test uradio kako treba. Iz nekog razloga svi ti new-age testing funadmentalisti i proroci misle da testing code nastaje ni iz cega i da ne kosta nista i da je to odgovor na sve nase probleme oko kvaliteta koda. E pa nije.
I pride jos imas nezgodan aspekt da se tipovi menjaju tokom izvrsavanja programa i da tvoji testovi moraju to da imaju u vidu i da je skoro nemoguce predvideti sve moguce situacije koje ce dovesti do razlicitih "verzija" istog tipa, sto isto vodi kompleksnosti testova i dodatne mogucnosti za ljudske greske u samom testu.

Tako da ja ne kupujem ideju da je testing validna alternativa statickim tipovima i da kvalitet proizvoda dinamickog jezika podize na isti nivo.

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ć

Amin, Miljane.

Samo bih još dodao da pokretanje testova oduzima vreme, a ponekad i ububože puno vremena. Kad sam radio na sistemu za automatsko prevođenje teksta (eh, dobra stara vremena...) testove smo pokretali uveče i ujutru bi nas čekali rezultati.

Nego, da ne ispadne da sam "static typing fundamentalista", moram da naglasim da dinamički tipovi imaju puno smisla kad se radi sa SQL upitima i HTTP protokolom; obe ove tehnologije su dinamičke po prirodi stvari i tu se dinamički jezici lepo uklapaju. Pazi ovaj primer (čitanje application state u ASP.NET):



Ako "Source" nije referenca na DataView static typing ti ne pomaže ništa.


Za SQL doduše postoje typed datasets koji daju izvesnu compile-time proveru i mogu lepo da se koriste sa statičkim tipovima, ali ako DBA promeni šemu baze, možeš da se slikaš sa tipiziranim daasetom :D

Potpis

IOCC

Sam sebi si odgovorio
Onaj link koji sam dao, upravo o tome i govori da var ima jedino realnu primenu u anonimnim tipovima.