What do you like/dislike about .NET

-oricum, pe ansamblu e cel mai tare lucru de pe piata in materie RAD
-pacat ca desi teoretic e portabil, practic nu prea e asa
-imi place faza ca face fisier .exe si dupa ce il rulezi o data, data viitoare se executa chiar cod executabil nativ (sau cel putin asa spun ei)

Quote

FYI: Parametrii impliciti (si cateva alte caracteristici din C++), au fost eliminate pentru ca sunt, in general, folosite gresit. See below.

Quote

Uite chiar aici un exemplu. Un programator hotaraste ca foloseste << pentru streamuri. Altul pentru altceva. In momentul cand toata lumea foloseste operatorii pentru cele mai ciudate scopuri, codul devine ilizibil. Mie mi se pare mult mai rezonabil sa folosesc functii normale in aceste conditii. "Sa-i schimbi cum vrei tu" mi se pare doar o alta modalitate de "shoot yourself in the foot", sau "blow the whole leg away", sau ce vrei tu...

Quote

Mai face cineva RAD in zilele noastre? Credeam ca a inceput sa invete lumea si ceva Project Management...

Quote

Cui ii pasa de portabilitate? Cat de des schimbi platforma pe care rulezi?

Quote

Aici nu ai dreptate deloc. Cauta, insa, pe net informatii despre "ngen.exe" si vei avea o surpriza interesanta.

"faza cu function overloading nu mi se pare deloc eficienta (am o functie cu o carca de parametri si pentru fiecare parametru implicit trebuie sa creez o alta functie care sa o cheme pe aia mare)"

N-am spus ca e mai eficienta. Am spus doar ca e mai eleganta.  Prefer intotdeauna citeva functii mici  in schimbul unui mastodont.
Mult mai usor de debugged.


de exemplu am incercat sa overlodez operatorul << astfel incat sa trimit o clasa generica in baza de date (de exemplu db << produs), insa am vazut ca al doilea parametru trebuie sa fie obligatoriu int
In c++ poti sa faci overloading la mult mai multi operatori si poti si sa-i schimbi cum vrei tu

  . count (aka "produs" in codul tau) determina cu citi bits faci operatia de shifting. Mi se pare normal sa fie int.  Tu ce te asteptai sa rezulte in urma acelei operatii ?


"Uite chiar aici un exemplu. Un programator hotaraste ca foloseste << pentru streamuri. Altul pentru altceva. In momentul cand toata lumea foloseste operatorii pentru cele mai ciudate scopuri, codul devine ilizibil. Mie mi se pare mult mai rezonabil sa folosesc functii normale in aceste conditii. "Sa-i schimbi cum vrei tu" mi se pare doar o alta modalitate de "shoot yourself in the foot", sau "blow the whole leg away", sau ce vrei tu..."

Nu poti sa "blame" limbajul pt ca featureul X e folosit prosteste de catre programator. Ai vazut vreodata cod de genul :

int x = 56;

//more code

x += ++x+36*x++;

Aici e clar ca nu operatorii (++ si +=) "sint de vina".

"oricum, pe ansamblu e cel mai tare lucru de pe piata in materie RAD"
Sintem in 2004. Chestia asta e taken for granted. Poti sa "RAD"uiesti si in MC++ fara probleme. In plus asta e un "IDE" feature. Ce legatura are cu limbajul ?  


pacat ca desi teoretic e portabil, practic nu prea e asa
Vorbesti de .NET Framework sau C# ?

-imi place faza ca face fisier .exe si dupa ce il rulezi o data, data viitoare se executa chiar cod executabil nativ (sau cel putin asa spun ei)
Nu e asa. Codul este jituit de fiecare data cind e rulat.  Daca vrei sa fie rulat direct nativ fa ce a zis reply.

Quote

Aici e o disputa veche de cand lumea. Sunt unii care sustin ca developerii pot fi educati sa nu scrie tampenii. Eu sustin ca intotdeauna se vor gasi developeri bine educati si mai exista "ceilalti". Aceste caracteristici mai avansate pot fi arme utile pentru developeri talentati in unele situatii, dar arme periculoase in mana celorlalti.

Sunt de parere ca exista o modalitate simpla de a preveni situatiile astea: Eliminarea unor caracteristici "avansate" (care oricum sunt folosite in < 1% din cazuri) si care pot fi periculoase, si exact asta s-a intamplat in C#. Fara rautate, mie mi se pare aberant sa scrii "database << dataset".

Inapoi la topicul initial: Ma surprinde ca nu spune nimeni nimic de securitate (role-based security, code access security, policies), de garbage collection, de JIT vs. NGEN, de suportul pentru versiuni - o chestie esentiala, pentru ca este primul framework de la Microsoft care ofera infrastructura pentru schimbarea codului, web services samd.

Bottom line: Daca nu v-ati atins inca de lucrurile astea, mai bine ramaneti la Delphi sau Visual Basic 6. Altfel, e ca si cum ati avea un Ferrari si ati merge cu el cu 40 km/h.

Carevasazica, daca nu ne-am atins de garbage collection mergem cu 40km/h?

  Ontopic: ce-mi place? Tot!

De garbage collection nu ai cum sa nu te atingi, pentru ca este o caracteristica de baza a CLR. Problema e ca, daca nu intelegi cat de cat cum functioneaza, risti sa dai vina pe garbage collection pentru performantele slabe ale programului cand de fapt de vina e un developer prost educat (si tot la 40 km/h ajungi).

Back on topic: E bine ca-ti place tot. Dar ai vazut Visual Studio 2005?

++++ ADO
+++ Remoting: adio monstruase interfete...
-- n-are submeniuri de ASP. Pana balmajesti unul intr-un grid, sau alt control te plictisesti. Iar daca vrei sa-l modifici cu submeniuri intr-un schelet gen IBuySpy cre ca tre sa fi dus cu capul. Oricum n-a facut asta nimeni din cate am sapat eu pe forumuri.

Quote

Apropos (si de) de Delphi: ce nu imi place la .NET Framework este ca succesul pe care il are este in mare parte bazat pe marketing.
Spune-ti-mi o tehnologie(sau idee de ierarhie de clase) care sa nu fi fost deja folosita in VCL sau de Java (inclusiv Remoting).

Singurul avantaj care il vad acum este ca este standardizat ECMA.

ia zi shi mie cum declar un map in delphi ? sau un template ? sau un hash table ?  sau un enumerator ? sau un multimap ?

shi vreau shi eu un msdn pt. delphi, plz.

Quote

Duh Adica programatorii si decision-makerii din firme sunt cam la fel de destepti ca pustimea care vede la televizor reclame peste reclame la Harry Compotter si dau fuga cu totii la CIO si zic ca vor .NET Framework, nu? Cati anisori ai, nu te supara?

pirannia, ceea ce spui tu poate e corect, dar asta nu inseamna:
1. ca trebuia sa imi consideri literalmente indemnul: "Spune-ti-mi si mie o .."
2. ca nu am voie sa imi displaca faptul ca este o tehnologie bazata pe cantitate, adica pe: popularizare, brand, multe idei vechi sau noi incorporate si cizelate dar prezentate toate ca noi.
Nu am ajuns inca la nivelul tau de cunoastere a tuturor lucrurilor, dar cele pe care le-am intalnit imi erau deja familiare de ani din alte limbaje/framework-uri.

Despre partea cu MSDN-ul.. e ca si cum ai cere sa ai Windows la OS/2 or smth..

Cat despre reply, ... , nice try, dar tocmai top managementul este mai comod si se uita mai mult la televizor. E exact ca si cazul Athloanelor in firme.. sunt? Nu, pentru ca nu stie nimeni ce fel de "Pentium" e ala.
Deci "dot net" suna ca si "the mother of 'em all" pentru cine acum incepe sa programeze. Inventatorii 'net-ului, right? -- O istorie..

Repet: singurul lucru care ma deranjeaza este ca mi se pare ca nu mai lasa nici o sansa, pe termen lung, altor tehnologii, pentru ca este propulsata de Microsoft. Si ca face asta fara o inovatie vizibila.
Altfel, imi place si mie si imi este comod.

b100dian argumentele tale sint "flawed"  :

Apropos (si de) de Delphi: ce nu imi place la .NET Framework este ca succesul pe care il are este in mare parte bazat pe marketing.
Imi pare rau sa te dezamagesc dar "in the real world" deciziile acestea nu se iau asa. Daca acolo unde lucrezi tu deciziile sint luate dupa reclamele la televizor atunci......well...te compatimesc.

Spune-ti-mi o tehnologie(sau idee de ierarhie de clase) care sa nu fi fost deja folosita in VCL sau de Java (inclusiv Remoting).
Hihihi. Primul limbaj cu un class lib care continea metode de RPC, GUI, collections etc a fost SMALLTALK (probabil n-ai auzit niciodata de "Talk small and carry a big class library" , nu ? Java/VCL/*whatever* nu au fost nici primele nici ultimele.....

Singurul avantaj care il vad acum este ca este standardizat ECMA.
Wrong. Nu tot ce apare in FCL e standard ECMA/ISO.


ca nu am voie sa imi displaca faptul ca este o tehnologie bazata pe cantitate, adica pe: popularizare, brand, multe idei vechi sau noi incorporate si cizelate dar prezentate toate ca noi"
Muhahha......adica Java sau  Delphi  nu sint popularizate de catre SUN respectiv Borland ?!!! Nu sint "branduri" ?!!  Poti sa-mi demonstrezi si mie ce anume leagat de .NET a fost "prezentat ca fiind nou" ?

ingurul lucru care ma deranjeaza este ca mi se pare ca nu mai lasa nici o sansa, pe termen lung, altor tehnologii, pentru ca este propulsata de Microsoft

And Mircosoft is eviiiiiiiil, right ? Vai ce de gogosari bagi.....nu mai poate Borland sa "inoveze" acum. Geeeez....atunci cum iti explici ca Borland a scos un compilator (+ IDE)  Delphi pt .NET ? Cum iti explici ca a scos un IDE pt C# ?

Si ca face asta fara o inovatie vizibila.
Primul VM care, cu ajutorul specificatiilor CTS, suporta mai multe limbaje de programare (exista peste 20 compilatoare pt .NET).

Hohooo omule - e chestie de "ce nu imi place", nu ce nu e profitabil. Unii ajung sa faca mai mult din ce nu le place altii nu, altora incepe sa le placa.. depinde de om.
Parerile nu pot fi "flawed". Daca nu stiu de smalltalk decat din auzite asta nu inseamna ca nu pot sa am pareri, right?

And btw, tie ce iti place/nu-ti place la .NET Framework?
Pentru ca daca nu ai avut "the gots" sa te pronunti primul, ca initiator al threadului, macar acum ulterior puteai sa-ti fi format o parere

Quote

Daca asa se lucreaza in firma ta, bail out, repede. In lumea reala e un pic altfel. Daca cumva chiar e firma ta... Si mai rau

Quote

Ba iti place, ba nu iti place. Tu lucrezi pe undeva sau te dai pe net si citesti una, alta...?

Argumentul cu marketingul pleaca de la o premisa falso-jenanta deci E "flawed".

"Daca nu stiu de smalltalk decat din auzite asta nu inseamna ca nu pot sa am pareri, right?"
Evident ca poti sa ai o parere si sa ti-o exprimi aici.  Si la fel de evident e faptul ca nu aveai dreptate...

Ce nu-mi place :

- faptul ca ES e unmanaged code. Faptul ca un assembly in care folosesti ES trebuie neaparat sa fie sk.
- nu exista mai multe moduri pt GC. Mi s-ar parea foarte utile inca 2  moduri pt GC:
  1. sa poti stabili tu thresholdurile GCului ( si acesta sa fie in continuare self tuning).
  2. Gcul sa aiba decit gen0 si sa poti seta tu valoarea la care se face collectul (e.g  pe romaneste colecteaza dupa fiecare X mb alocati).
- sa am optiunea de a colecta si LOH.
- System.Collections e cam saraca.
- ceva greseli de design prin BCL : de ex nu poti sa returnezi key/value dintr-un hashtable stiind indexul (fara sa folosesti enumeratorul). Din sorted list merge...
- existenta namespaceului System.Data.Common
- faptul ca tipul care a "conceput"  semnatura delegatului ThreadStart nu a fost impuscat.
- faptul ca pe MS nu-i intereseaza deloc de ngen si se gindesc ca jiterul e de ajuns.
- faptul ca nu exista un wrapper oficial pt win32 api.
- sint clase care NU ar fi trebuit sa fie sealed.
- nu exista AppSettingsWriter.

(more to come).


PS: se scrie "guts" .
PPS: sa inteleg ca dpdv "tehnic" .NET Framework e perfect pt tine,  nu ?  

hehe... trebuie sa mai invat

Quote

Nici tu nu ai dreptate peste tot Hai sa le luam pe rand:

- chestiile legate de GC. Crede-ma, am studiat in detaliu ce se intampla acolo (daca vrei, detaliez, dar e mult de zis). NU vrei sa te bagi sa il configurezi de mana. Ar fi la fel de rau ca si a apela GC.Collect(). Mai bine iti studiezi aplicatia bine (cauta dupa "CLR Profiler" pe net) si vezi ce poti imbunatati in strategia de creare si folosire a obiectelor.

- System.Collections: Check out System.Collections.Generic in .NET Framework 2.0. Chiar vroiai totul in v1.x? Java a reusit dupa aproape un deceniu  

- Ceva greseli de design prin BCL. Aici sunt de acord. Vroiam doar sa-ti amintesc ca sunt de partea ta Totusi, trebuie sa intelegi ca proiectarea unei aplicatii perfecte este imposibila. Proiectarea unei librarii perfecte este si mai imposibila. Nimeni nu poate anticipa totul.

- System.Data.Common si tipul care a conceput ThreadStartDelegate: Eu nu as fi asa sever.

- Ngen: Gresesti amarnic cand vorbesti despre ngen. Longhorn se va baza masiv pe el: Pe CDul de instalare va fi IL iar la install-time ngen creeaza imagini optimizate pt masina destinatie. Ce zici de asta? Nepasare?

- AppSettingsWriter: Sper ca nu vrei o clasa care sa scrie in App.config. Asa ceva ar fi aberant (iarasi, pot detalia, dar sper ca te prinzi si tu). Pentru alte scopuri, ar fi utila, intr-adevar.

-GC:
Oricit de bine arfi "tweaked" GCul, intotdeauna se va gasi cineva care va spune "hmm...dar eu as vrea sa colecteze putin altfel". Prin definitie GCul nu poate fi perfect.  Nici nu se pune pb sa-l configurez de mina (ma refeream prin intermediul clasei System.GC) . MS nu recomanda sa call  GC.Collect() dar exista cazuri in care e "benefic" faptul ca chemi tu Collect(). . Am vazut niste cazuri in care GC.Collect() era apelat in event handleul Idle !!! Talk about stupid things....
CLR Profilerul e aproape useless. In "real world"  nu prea exista timp sa-ti imbunatatesti "strategia de alocare a obiectelor". Eventual incerci sa profiti de deterministic finalization (IDisposable + using) si sa pui cit mai putin "pressure" pe GC.  Personal cred ca, cu cit ai mai mult control asupra GCului cu atit mai bine. Adica....sa exista un "default" rezonabil (cum exista acum de ex) pt cei care nu stiu decit ca "exista GC si ala curata memoria"    dar sa am si posibilitatea sa modific modul in care functioneaza GCul.
Pt referinte....mie personal imi place bucata din "Applied .NET Framework Programming" a lui Richter. Si parca mai sint si vreo 2 articole interesante printr-un MSDN Mag de anul trecut.....

- aici vorbim de prezent.

-Proiectarea unei librarii perfecte este si mai imposibila.
That doesn't mean i can't bitch and moan about it....   


System.Data.Common si tipul care a conceput ThreadStartDelegate: Eu nu as fi asa sever.
Eu sint. Data.Common  nu incurca prea mult dar greseala cu  ThreadStart  e pur si simplu prea mare ca sa poata fi trecuta usor cu vederea.

Ngen: Gresesti amarnic cand vorbesti despre ngen. Longhorn se va baza masiv pe el: Pe CDul de instalare va fi IL iar la install-time ngen creeaza imagini optimizate pt masina destinatie. Ce zici de asta? Nepasare?

Optimizate spui tu.   Sint 2 mari probleme cu ngen.:
1. In varianta actuala ngen e o gluma. Foloseste mscorjit.dll pt transformarea ilului in cod nativ si apoi "scuipa" rezultatul intr-un fisier. Atit. No cpu dependent optimization , no nothing.  Tu cind spui "imagini optimizate" pe ce te bazezi ? In plus ...hai sa fim seriosi cu "optimizarile"....cind o sa ajunga ngenul sa faca optimizarile pe care le face compilatorul VC++ mai vorbim. Pina atunci......   
2. Imaginile native generate de ngen nu contin metadata. Deci, ca sa poata fi "utilizat" assemblyul respectiv sint incarcate AMBELE fisiere (atit ILul cit si nativul) in address spaceul procesului respectiv. Si uite asa te trezesti cu un working set aproape dublu fara a avea mari beneficii dpdv al vitezei de executie .


AppSettingsWriter: Sper ca nu vrei o clasa care sa scrie in App.config. Asa ceva ar fi aberant (iarasi, pot detalia, dar sper ca te prinzi si tu). Pentru alte scopuri, ar fi utila, intr-adevar."
E vorba de ...simetrie. Good design.  Faptul ca pot sa XmlTextWriter -uiesc in app.config nu ma incalzeste cu nimic.

O sa mai scriu cite ceva despre dislikes....

PS: sa inteleg ca sintem de acord cu ES ?