What do you like/dislike about .NET

Quote

Am intalnit situatii in care se creau prea multe instante ale unor clase acolo unde nu era nevoie (ex.: Ai o clasa care nu isi mentine starea si o bucla; ce faci: creezi cate o instanta de fiecare data cand treci prin bucla sau creezi o singura instanta si o folosesti de 1000 de ori? Ai sa fii suprins cati programatori aleg prima varianta... si tu trebuie sa afli ce nu merge bine). GC functioneaza absolut ok asa cum este, nu are nevoie de hinturi. Mai degraba trebuie educati programatorii sa aloce ce si cum trebuie; un alt exemplu: Functie enorma (sute de linii) cu multe apeluri si o groaza de cod spaghetti. De unde sa stie saracul GC ca un obiect enorm alocat la inceputul functiei si utilizat o data nu mai e folosit absolut deloc dupa aia? (De fapt, are de unde sa stie si asta e subiectul unei optimizari dintr-o versiune viitoare - problema e ca trebuie sa vina niste hinturi de la compilator, GC nu are cum sa faca asta pe cont propriu).

Quote

Bitch...

Quote

1. mscorjit.dll este cpu-dependent si face optimizari masive. Ngen va face optimizari si mai destepte in Whidbey, dar va fi gata doar in Orcas. Dar, ca tot veni vorba de compilatorul de C++... Tu folosesti toate optiunile lui? Pun pariu ca exista cel putin 2-3 optiuni in compilerul de C++ pe care Ngen le foloseste in mod transparent in versiunea curenta si de care tu nu stii deloc  
2. Da, in 1.x metadata se incarca din fisierul initial. Problema a fost rezolvata in Whidbey. Afirmatia ca working setul este dublu este gratuita. Ai masurat? (Daca nu, joaca-te putin cu vadump.exe de exemplu; diferenta de marime consta exact in numarul de pagini cu metadata luate din assembly-ul original; scaderea de performanta nu provine de aici, ci din faptul ca trebuie deschise de 2x mai multe fisiere la incarcare. Measure, daca nu ma crezi)

Quote

E bad design sa scrii in app.config. Se pare ca nu stii de ce, asa ca sa iti explic: Sa presupunem ca te intereseaza calitatea si aplicatia este logo-compliant; in cazul asta, intrebare de 10 puncte: Ai voie sa umbli la fisierele din Program Files?

Quote

Am facut o cautare extensiva prin baza mea de abrevieri si nu imi dau seama ce e aia ES... Amaze me. :cya:

M-a lovit acum cateva zile revelatia: ES = Enterprise Services Acum pot sa dorm linistit

Quote

Eu as fi zis ca daca nu stii de ES mai bine ramai la Delphi si VB6   ; ca aia era programare enterprise   ; nu ca ES ar fi cine stie ce (cine a programat COM+ stie la ce ma refer), dar macar informativ  

Quote

Faptul ca nu-mi spuneau nimic initialele pe moment nu inseamna ca nu stiu de Enterprise Services. Eu ii spun COM+ pur si simplu, nu ES. Si cine a programat COM+ stie ca ES e ceva, dar in fine... Oricum, multumim pentru contributia la topicul initial

Cineva s-a dat 'cocoș' în acronime

S-a uitat ceva foarte important :nu:
Faptul ca oricine poate decompila codul si obtine originalul mult prea usor. Cum va mai protejati aplicatiile in .NET ? Atit timp cit "eu" intru in executabil si extrag secventele de cod ce contin o protectie impotriva rularii neautorizate !

Asta e o problemă falsă, după părerea mea. Se poate obține (foarte ușor) codul sursă și dacă te apuci să dezasamblezi programe de x86, Itanium sau AMD64. Există tooluri și există oameni deștepți care să le folosească.

În altă ordine de idei, un pop-quiz (Bine, mai degrabă un poll): Câți dintre voi folosesc Debug.Assert?

De acord cu reply, aici: problemă falsă ( numai că eu îmi formez și o părere proastă despre meritul celor care fac programe de genul ăla. ).

Programul executabil este ultimamente inteligibil, în orice limbaj e scris! De ce? pentru că trebuie să fie executat de procesor, duh!

Ca notă: nu cred că sunt chiar așa de ușor de înțeles bucățile de cod de algoritmică (relativ) inovatoare (prin care ar fi mai merituoasă "culegerea" ta de comenzi din help )

Si de ce e o problema falsa ? Ai auzit tu de programe ce decompileaza un executabil nativ in cod C/C++ precum in .NET ?
Una e sa studiezi un .asm si alta un cod in limbaj de nivel inalt ! Plus ca acel executabil nativ poate fi rasucit in fel si chip de sa nu mai semene cu cel generat de compilator si atunci sa-l vad pe cel ce mai intelege ceva din acel .asm desi procesorul il ruleaza fara probleme.
Voi traiti din programare ? Cum va suna daca orice pusti face varza din codul vostru si in loc sa vindeti 10 programe vindeti doar 1 ? De ce Microsoft nu a portat programele sale in .NET ? Pai cum ar fi sa ne mai jucam si noi prin codul Word ?!

Da, există destule programe care decompilează cod Windows/Unix/Linux/DOS și generează cod C++, chiar și din cod optimizat.

și dacă crezi că Microsoft nu portează codul pe .NET... Mai citește știrile un pic. Ai auzit de Longhorn? De Office 12? De Visual Studio 9?

I'm back  :yeah baby

"mscorjit.dll este cpu-dependent si face optimizari masive"
Nope. In 1.1 JITerul "scuipa" doar cod x86 generic ( cit se poate de cpu independent). Chestia cu optimizarea e hilara... . JITerul NU face optimizari. Rolul lui e de a primi IL si de a-l converti in x86(x86-64/ia64). ATIT. Si cit mai repede cu putinta.

"Ngen va face optimizari si mai destepte in Whidbey, dar va fi gata doar in Orcas."  
  Iar in versiunea post Orcas ( codename  "Dreams";)) optimizarile vor  fi atit de destepte incit.....aaaa......o sa fie tare oricum. Link pt chestia cu Whidbey si "optimizari destepte" please. A aparut si versiunea beta a .NET 2.0 pt IA64. Sint curios daca ngenul face acolo optimizari.... A incercat-o cineva ?

Da, in 1.x metadata se incarca din fisierul initial. Problema a fost rezolvata in Whidbey.
Link please.

Afirmatia ca working setul este dublu este gratuita. Ai masurat? (Daca nu, joaca-te putin cu vadump.exe de exemplu; diferenta de marime consta exact in numarul de pagini cu metadata luate din assembly-ul original; scaderea de performanta nu provine de aici, ci din faptul ca trebuie deschise de 2x mai multe fisiere la incarcare. Measure, daca nu ma crezi)
Corect...scuze....nu e chair dublu. More like ~ 20%.

"E bad design sa scrii in app.config. Se pare ca nu stii de ce, asa ca sa iti explic: Sa presupunem ca te intereseaza calitatea si aplicatia este logo-compliant; in cazul asta, intrebare de 10 puncte: Ai voie sa umbli la fisierele din Program Files?"
IsolatedStorage. But you are missing my point.....de ex pot avea in app config niste setari "globale" pt program care se aplica tuturor utilizatorilor. Nu vad ce rost are sa salvez pt fiecare in parte chestia asta. AppSettingsWriter ar fi fost handy....

Scuze pt chestia cu acronimul.  

C# a avut o idee beton cu threadul asta. Seamana cu un supliment la NetReport (Merlin parca ii zicea) in care se discuta tema: Linux vs. Windows. Evident, gramezi de argumente si contraargumente curgeau de amble parti. Partea cu morala: Intr-un reply, un pinguin arunca cu argumentul decisiv - "in windows nu se poate sorta un numar de nu-stiu-cate fisiere intr-un nu-stiu-ce-fel din 5 linii in consola". Raspunsul a venit instant din partea unui meserias sub forma unui vbscript din 4 linii. Asa ca nu e bine sa dai pareri negative din tine pana nu cunosti FOARTE bine subiectul.

O chestie care imi lipseste in c# este "checked exception" care exista in java. Sunt avantaje si dezavantaje in ceea ce privesc exceptiile verificate, dar per total avantajele sunt mai multe. Intotdeauna codul pe care l-am scris in java a fost mai robust decat cel pe care l-am scris in c#. Java te forteaza la un anumit stil de lucru, care e in beneficiul programatorului.

Ptr cei interesati de subiect, vedeti urm link-uri:
PRO:
http://www.artima.com/intv/solid.html

CONS:
http://www.artima.co.../handcuffs.html

Mdeah.....fiecare cu ce-l doare. Nici mie nu-mi place .NET Framework din cauza build systemului infect din VS.NET      

"Intotdeauna codul pe care l-am scris in java a fost mai robust decat cel pe care l-am scris in c#. "
Si atribui asta faptului ca Java are checked exceptions ?    Poate ca nu stii tu prea bine C#.....
Checked exceptions sunt "a pain in the ass" atunci cind lucrezi la librarii si mai introduci o exceptie. FORTEAZA modificarea codului de catre client. Asta e inacceptabil. In plus pot fi oarecum "emulate"...nu ai decit sa throw System.Exception. Asta are avantajul ca nu te forteaza sa iti modifici codul. In plus poti afla si tipul exceptiei folosind proprietatea InnerException. So there you have it....un fel de checked exceptions in C# dar fara dezavantajele din Java.


"Java te forteaza la un anumit stil de lucru, care e in beneficiul programatorului."
Daaaa.....adica sa declari getters si setters pt ca Java nu suporta nici acum properties ?   Serios....poti sa detaliezi ?

Salutare,

După ce am citit tot ce s-a scris până acum în acest topic m-am gândit să adaug și eu ceva. Eu personal consider platforma .NET un mare progres pentru industria software. Nu cred că ASP.NET ar trebui considerat o rușine. Microsoft a încerat să ofere un mediu mai sigur pentru aplicațiile web, cu un set de clase foarte bine organizat, menit să completeze vechiul asp care începuse să fie depășit.
Ați observat probabil că majoritatea siturilor Microsoft au fost deja portate spre această tehnologie. MSN este un portal foarte complex după părerea mea și nu cred că Microsoft l-ar fi trecut pe ASP.NET doar de dragul tehnologiei. Nu zic că ASP.NET reprezintă perfecțiunea, pentru că nu există software perfect, însă nu poate fi considerat o rușine. Modul în care se face legătura între elementele de pe pegina web și codul sursă cred că este foarte util, mai ales pentru cineva care face trecerea de la aplicațiile windows spre cele web.
Designerul este cam slab însă poate fi înlocuit foarte bine de FrontPage 2003 sau Dreamweaver . Personal consider FrontPage 2003 cel mai bun software care a fost scos până acum pentru editarea paginilor web. Dreamweaver are în schimb avantajul că oferă un control mai bun asupra bazelor de date.
Uitați-vă însă și la nou venitul Visual Studio .NET 2005 Beta 2 (poate fi comandat gratuit) . Acolo cred ca designerul web rezolvă toate deficiențele din trecut. Folosirea unui software specializat pentru editarea paginilor web cred că ar fi făcută mai mult din obișnuință, mai puțin din necesitate.
Referitor la .NET Framework 2.0 consider că noua ierarhie de clase ar trebui să îi mulțumească chiar și pe cei mai pretențioși pentru ceva timp. Mi se pare interesantă implementarea unor funcții DirectX pe Compact Framework 2.0 .

Deocamdată cam atât.

Toate cele bune.

visitor, on Mar 8 2004, 14:14, said:

Bineinteles ca se poate instala, dar nu stii tu! Oricum, daca ai un super calculator (din moment ce rulezi Win9x, iti spun eu ca-ti va merge bestial

Salut, vin si eu sa raspund ca sa ma aflu in treaba.

Imi plac:
    + delegates si anonymous delegates din C# 2.0
    + unsafe code - pentru ca programarea cu unsafe code din C# este mai sigura decat programarea cu JNI din Java.
    + operator overloading
    + Mono exista si este destul de complet pt web
    + auto-boxing + toate primitivele sunt implementate ca struct

nu-mi plac
    - multi-cast delegates si events - doar adauga complexitate limbajului
    - setters/getters - baietii viseaza prea mult la programare bazata pe componente si au dat-o in bara aici - rezultatul este un C# cu usoare urme de message passing ala Smaltalk, destul cat sa adauge confuzie.
    - VS.NET este de cacat comparativ cu Eclipse / IntelliJ IDEEA
    - IL-ul nu a fost implementat pt a fi interpretat iar tehnici avansate gen optimizarea adaptiva din HotSpot compiler de la Sun nu sunt practice in CLR.
    - Standardele ECMA/ISO nu sunt "royalty free" in mod implicit (open-source cere "royalty free"), si singura garantie de existenta a proiectului Mono este o scrisoare a unui angajat M$ (John Miller) care promite ca standardele vor fi "royalty free". Dar nu este nimic finalizat, iar Mono ar putea fi omorat chiar si cu o simpla amenintare.

KLAMATH, on Jun 21 2004, 10:59, said:

Si ce este in neregula cu Java la capitolul asta ?
http://www.robert-to...mlanguages.html

Rugaminte pentru cei care o sa mai posteze. Incercati, pe cit posibil, sa si argumentati. Daca aruncati un "VS.NET este de cacat comparativ cu Eclipse / IntelliJ IDEEA" nu faceti decit sa fiti penibili in loc sa contribuiti la discutie. Mersi.

Si ce este in neregula cu Java la capitolul asta ?
[url="http://www.robert-tolksdorf.de/vmlanguages.html"]http://www.robert-tolksdorf.de/vmlanguages.html[/url]
[/quote]

Cu JVMul si bytecodeul Java e in neregula faptul ca nu a fost creat pt language interoperability ci DOAR pt Java. Bytecodul suporta doar "featuresurile" limbajului Java. De ex daca eu vreau
sa scriu un compilator pt un limbaj care ruleaza sub JVM si limbajul meu suporta overloading
by return type (de exemplu) nu o sa pot implementa chestia asta. JVMul exista de 10 ani. Singurele chestii oarecum interesante care ruleaza sub el sunt Jython si Groovy ambele niste subseturi, din pct de vedere al complexitatii, Java. Sub CLR se pot rula limbaje complexe gen C++/CLI sau Eiffel si pina la ....Boo . In plus CLRul suporta explicit language interoperability prin CTS/CLS. Ca sa nu mai amintesc de unsigned types...

   - multi-cast delegates si events - doar adauga complexitate limbajului
Simplifica. In cazul multicast delegates....daca ai , de ex, 3 metode cu acceasi parametrii si vrei sa le invoci printr-un delegate. Daca nu ar exista multicast delegates ai avea nevoie sa declari 3 delegates separati. Cu ajutorul mulicast delegates nu ai nevoie decit de unul singur.
Legat de events....e o implementare mult mai clean si "directa" fata de inner classurile din Java.

    - setters/getters - baietii viseaza prea mult la programare bazata pe componente si au dat-o in bara aici - rezultatul este un C# cu usoare urme de message passing ala Smaltalk, destul cat sa adauge confuzie.
Pt mine personal nu are nici o logica fraza de mai sus. Ce legatura au proprietatile cu componentele si cu message passingul din Smalltalk ?!?

    - VS.NET este de cacat comparativ cu Eclipse / IntelliJ IDEEA
Genial argument.  

IL-ul nu a fost implementat pt a fi interpretat iar tehnici avansate gen optimizarea adaptiva din HotSpot compiler de la Sun nu sunt practice in CLR.
Wake up man. La ce foloseste HotSpot atita timp cit un limbaj interpretat va fi intodeauna mai slow decit native code ?!!!!

Standardele ECMA/ISO nu sunt "royalty free" in mod implicit (open-source cere "royalty free"), si singura garantie de existenta a proiectului Mono este o scrisoare a unui angajat M$ (John Miller) care promite ca standardele vor fi "royalty free". Dar nu este nimic finalizat, iar Mono ar putea fi omorat chiar si cu o simpla amenintare.

Atunci Novell n-are decit sa scoata niste bani din buzunare. Poate aceeasi bani pe care i-a incasat de la Microsoft anul trecut. Btw MONO NU are nici o garantie de la MS pentru implementarea partilor care nu fac parte din CLI....gen ASP.NET, ADO.NET, Windows Forms  etc.