101
-
BlackRose #101 :) Marketing nélkül nem megy a dolog, de én a marketing alatt nem tisztára a reklámot (vagyis advertizingot értem), na de legyen igazad, habár akárhogy is nézed, a memóriakapacitás mindég gyorsabban fejlődött mint a CPU teljesítmény, és ez a jövőben csak fokozódni látszik, tehát marketing ide vagy oda, szerintem jobban kell odafigyelni a kód sebességére mint a memóriaigényre. És aki programozik az tudja, hogy a kettő alapjában nem fér össze, ha akarsz gyorsabb kódót akkor általában nem tudod a memóriaigényt is optimizálni, persze nem minden alkalommal de legtöbbször.
Ami pedig a 10-évvel ezelőtti alkalmazásokat illeti, ha összehasonlítjuk őket a maiakkal akkor nagyon nagy a változás, funkcionálissan is de sokszor sebességben is, gondold csak el mire volt képes egy 3D Studio 4-es vagy most a MAX 8-as... persze az igaz, hogy az OO kód ezt a sebességi különbséget egy picit leszűkítette, de ha nem lett volna az OO akkor a mai komplexitású szoftver sem lenne, mert egyszerűen tiszta C-ben vagy ASM-ben egy MAX 8-ast lehetetlen megírni, elméletileg persze lehetséges, de nem lenne az a csapat aki ezt ki tudná hozni és még ha ebben is tévednék, akkor nem lenne az a csapat aki azt ki tudná hozni elfogadható időn belül. Tehát minden technológiának megvannak az előnyei és hátrányai, de legtöbbször éppen a lehető legjobban csináljuk, elméletben ugyan nem, de gyakorlatban sokszor lehetetlen kísérni az elméletet. -
Caro #100 Ebben igazad van.
Itt vagyunk mostmár 4GHz fele tartó procikkal, meg 10x annyi RAM-al, mint 10 éve, és az alkalmazások közel sem futnak gyorsabban, mint 10 éve.
És annyi funkcionális bővülés nem volt. -
FTeR #99 és mennyire nincs igazad
1. szted ki akarná megfizetni azt az 15000 ember egész napos munkáját?
2. egyáltalán nem igénye ez a felhasználónak. az az érdeke, h funkcionálisan használható legyen. mutass már nekem valamit a világban, ami tökéletes és sosincs vele gond. ezzel a felfogással biztos autód sincs és buszra se szoktál szállni, meg repülőn sem utazol. pedig a hiba bekövetkeztének esélye ugyan annyi (pl kocsinál), csak a következmények súlyosabbak. ennek ellenére használják az emberek.
nemtom az sw-nek mér kéne teljesen tökéletesnek lenni. tudod egyáltalán, h az intel 4x86-os alaplapja volt az utcsó hw amit teljeskörűen leteszteltek?
nem is tudom minek eröltetem magam. egyértelmű, h egyáltalán nem vagy képben és még hajlandóságot sem mutatasz az érvek elfogadására. csak ugyan azt a bullshitet szajkózod. -
totya4 #98 "Pl. 2-3 év múlva nem lesz probléma (aprópénz lesz) 4 GB RAM-ot rakni a gépbe, am a mai átlag 8 szorossa lesz, de alig ha hiszem hogy addigra a CPU a mai átlag 2-3 szorossa is lenne."
Na ez megint egy marketing duma, már bocs :)
Véletlenül nem marketing szakember vagy?
Mert ez olyan amit mondassz, hogy figyelj, vedd meg a Z.X.C autót ami ugyan aszfalton csak 20-al megy, de 2-3 év múlva mindenhol e-aszfalt lesz, amin fog tudni menni 200-al is.
Tehát a jelenbe nem előnyös, de a jövőbe sem, mert azt feltételezed hogy a fejlődés megáll.
De nem áll meg, 2-3 év és megint itt egy új MS oprendszer egy új C%%%%++++ ami még 2x olyan lassú lesz 2x annyi erőforrást zabál (persze a programfejlesztés fele annyi ideig tart benne, ezért a programozók isteníteni fogják), tehát ha ugyanúgy rábeszéled a felhasználót hogy vegye meg, akkor megint csak lassan fog a gépén futni az alkalmazás, és így tovább örökkön-örökké, ergó sosem fog a felhasználó gépén olyan alkalmazás futni, amely azon megfelelő sebességgel és nem a rendszert agyonterhelve működik. Tehát megint a felhasználó jár rosszul. -
totya4 #97 Neked meg az a bajod hogy végletesen be vagy szűkülve, azt fel kell fogni, hogy a felhasználót kurvára nem érdekli hogy 10-en dolgoztak a programján vagy 15000-en, hogy napi 5 órában vagy 24-ben, elvárja hogy a korszerűnek mondható hardverén a programok normális sebességgel és hibamentesen fussanak.
-
FTeR #96 bármi változtatás csak jót tett volna a javanak :D
ha sikerül ms-nek a cucc, akkor most nem örülhetnénk a .Net-ek. szal sun elérte, h erős támogató helyett kapott egy mindent elsöprő ellenfelet...
ugyan már, ms hova törekedett volna, amikor még csak 1 volt a sok kicsi sw cég között? akkor nem volt mit megtartania. egyszerűen kielégítette a piac igényét, ezért elterjedt. -
Alfa Of NS #95 Bár nyilván figyelembe vette a piaci igényeket is, de az MS szándékosan törekedett mindenféle eszközzel elérni a monopóliumot és megtartani azt. Lásd a Java megváltoztatására tett nem éppen dicső kisérlete. -
FTeR #94 #92 ha ze alatt azt érted, h nem programozási szentírásokat követett, hanem a piac valós igényeit próbálta kielégíteni akkor igazad van. én ezt inkább pozitívumnak veszem.
#93 így igaz.
#91 félelmetes, mennyire nem vagy képben és ennek ellenére nem vagy hajlandó elfogadni a tapasztaltabbak állítását. tuti, h még 1 valós projektben sem vettél részt. -
Alfa Of NS #93 Inkább vesz sok vásárló újabb hardvert és használja az új szoftert, mint várjon még egy évet az optimalizáltabb (és emiatt drágább) szoftverre. -
Alfa Of NS #92 "a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elő és az optimizálás meg a többi dolog csak másodlagos volt számukra."
Az MS azért lett sikeres, mert az üzleti oldalára koncentrált a szoftverfejlesztésnek, nem a technikai oldalára. Nem úgy ért el sikereket, hogy életképesebb szoftvert indított a versenyben, hanem úgy, hogy a versenyt alakította a maga termékéhez
-
totya4 #91 Továbbra is az a véleményem hogy irreális hogy minden attól hangos hogy gyorsabb proci gyorsabb memória gyorsabb hardver...azzal senki se törődik hogy a programozók lustasága/vagy a fejlesztést vezénylő cég pénzéhsége miatt egyre lassabb programok jelennek meg.
Tehát a hardver hiába gyorsul, ha a szoftver "költségkímélési szempontok" miatt lassabb lesz.
Akkor legalább a korrektség miatt tájékoztatni kellene az átlagvásárlót, hogy azért kell kétévente új gépet vennie, mert a szoftvergyártó cégek minnél nagyobb haszonkulccsal akarnak dolgozni.
Egyébként a sebesség és erőforrásigény egy dolog, ma inkább a gond azzal van, hogy a szemét termékekhez hasonlóan szemét programok jelennek meg. Persze, a fejlesztő mondhatja, hogy azért programoztam c#-ben mert basztam megtanulni programozni és szoros volt a határidő, de
1. megtanulhatott volna programozni
2. szólni kell hogy a határidő nem tartható, vagy a végeredmény szemét lesz.
Pont a Vistáról lehetett olyan cikket olvasni, hogy azért csúszott fél évet mert az MS vezetője nem hitte el az egyik vezető programozója állítását, melyszerint az egész Vista fejlesztés úgy szar ahogy van, újra kell írni nulláról.
Tehát a határidőre való hivatkozás nem éppen jó védekezés...
Korábban írta valaki az AMS-et, de én nem említettem az ASM programozást.
Gyakorlatilag minden program előbb utóbb AMS-ben (gépi kód szavasítva) fut, hiszen a proci azt érti, persze nem mindegy hogy ezt a fordító állítja elő, vagy pedig maga az ember.
Szerintem direkt ASM-ben való programozás specifikus esetekben lehet szükséges, pl. sebességkritikus részeknél.
Nade ez nem azt jelenti hogy az egész alkalmazást ASM-ben kell írni (programozók ilyet nem gondolnának), hanem csak azt az adott részt (függvényt/szubritint/eljárást...) tehát akár a program kódméretének ezred vagy tízezred részét. -
BiroAndras #90 "de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni"
Utólag már nem lehet akármit megcsinálni. Az optimalizálás legeslegfontosabb része éppen a jó tervezés (nem csak adatbázisoknál). Az elsődleges kérdés, hogy milyen adatokat kell egyáltalán tárolni, aztán jön az adatstruktúra és a munkafolyamatok felépítése, és végül a konkrét lekérdezések optimalizálása. Csak az utolsó fázist lehet utólag is könnyen elvégezni.
"mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet."
Általában nem nulláról kezdik. Ma már legtöbbször van egy régebbi rendszer, ami alapján a fontosabb üzemi paraméterek ismertek. Ha meg még nincs semmilyen korábbi adatbázis a cégnél, akkor sokkal-sokkal több időt kell a tervezésre fordítani. Rettentő költséges dolog utólag újratervezni az egész rendszert . -
BlackRose #89 Na megérkeztünk az én területemre :) SQL.
Az adabázis optimizálás vagy inkább nevezném tuningolás, egy extra komplex téma. És ha apró bázisról van szó akkor általában nem foglalkoznak vele, ha közepes bázisról van szó akkor már nem árt odafigyelni, míg massziv bázisok esetében a legfontosabb dolog. De minden esetben az SQL tuningolás egy komolyan kezelt vállalkozás kell, hogy legyen. Az adatbázis teljesítményét lehetetlen egyoldalúan növelni, vagyis szoros együttműködésre van szükség a fejlesztők az adatbázis adminisztrátorok az infrastruktúra vagyis rendszermérnökök (ide beleértem a rendszergazdákat is és a hálózati mérnököket is). Először is egy adatbázis teljesítménye nagyon függ az adatok struktúrájától, a normalizáció fokozatától (van ahol a denormalizáció gyorsít), az indexeléstől, a hálozati forgalomtól (ez különössen érvényes amikor néhányezer kliens konkurensen lóg a rendszeren), stb. Tehát optimizálni az SQL kódot a többi nélkül nem nagyon érdemes, habár alapszabály, hogy oda kell figyelni a joins-okra és a subquery-kre, meg az ORDER BY-ra. És sokszor segít még az átlagos user pattern is, vagyis egyfajta Paretó diagram ami arról szól, hogy melyik adatcsoportot használják jobban, ezekre különössen odakell figyelni a tuningoláskor. Na, hogy ne dumáljak reggelig, az adatbázisok tudományának fele éppen a tuningolás, és ez nagyrendszerek esetében extra fontos, mert néhány extra CPU vagy extra szerver az évi költségeket képes jócskán megterhelni, mint licensz úgy karbantartási és energiaszámlákon keresztül, tehát ez egy olyan terület ahol az optimizáció nem elenyészhető, bár amikor nagyobb bázisokról beszélünk. -
fflx #88 ezt egy fel pillanatig se kerdojelezem meg, de megnezem azt a programot, aminek az adatbazisat elore szejjel optimalizaljak. Szerintem sokkal gyakoribb, hogy utolag kezdenek el optimalizalni, mivel olyan teszt kornyezetet nehez csinalni, mint egy egyeves eles kornyezet. Akkor aztan johet az oracle es kianalizalhatja magat es majd jol megmondja a statisztikai alapjan, hogy mi a szar meg mi a jo. Aztan ebbol elindulva - meg a felhasznalok epito otleteibol (lassu ez a szar) - mar lehet is optimalizalni. (szerintem) -
FTeR #87 a ms-részt hányszor próbáltam elmagyarázni az ilyen sebesség mindenek felett linux fan vagyok-nak, de nem képesek megérteni... -
FTeR #86 egyelőre. de ha megfigyeled akkor láthatod, h azt is írtam, amint elterjednek a .netes programok, onnantól kezdve minden rendzser fejlesztőjének érdeke lesz implementálnija a frameworköt. és ebben semmi nem akadájozza meg, mivel teljesen nyílt a dolog.
azon az osen, amin nincs framework, arra nem lehet .net-es progit írni... -
kbupdate #85 jaja, jó meglátás:) -
BiroAndras #84 Egyébként az nagy baromság, hogy a Vista csak biztonsági frissítésekeket tartalmaz.
Nem is egyszer volt róla cikk itt az SG-n is, hogy teljesen újragondolták az egész platformot, majd félúton mégegyszer, amikor kiderült, hogy a HW nem a várt ütemben fejlődik. És nem csupán a biztonságról van szó, sok más is javult (pl. memória kezelés).
De az pláne vicces, hogy évekig a biztonság miatt fikázták az MS-t, és most hogy az új win legfőbb tulajsonsága a nagyobb biztonság, már azt mondják, hogy jó az XP is.
Meg a win vs. linux vitákban is megy a fikázás, hogy milyen szar a win, aztán meg most kiderül, hogy semmi baj az xp-vel, nem is kell a vista. -
BiroAndras #83 "hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na."
Ott meg az SQL utasításokat kell optimalizálni. Az se könnyebb. -
fflx #82 nem ertek veled teljesen egyet. mert persze hulyeseget nem fogsz leirni kodban, de peldaul meg veletlenul sem irtam volna 1.0-as frameworkon for ciklust foreach helyett pedig megmondtak, hogy sokkal lassab. es 1.1-ben ki is javitottak. aztan meg szamtalan ilyen van, pl most a 2.0-rol meseltek sokat a bemutato konferencian, hogy mi minden gyorsult. szoval en arra gondoltam, amikor azt irtam amit irtam, hogy a franc fog allandoan mindent IL kodra foditva leellenorizni, hogy ertelmesen foditja-e vagy sem.
Nezz meg egy switchet, hogy milyen lesz IL kodban :)
altalaban ervenyes, hogy real time dolgokat nem irnak ilyen nyelven -bar irtam mar valos ideju mozgaserzekelot. persze unsafe blokkban pointerekkel. ott erdemes pocsmorogni a sebesseggel, meg meregetni, de az, hogy valami 1 vagy 10 millisec alatt fut az annyira tok mindegy egy adatbazis alapu uzleti szoftvernel, hogy csak na. -
BlackRose #81 hmm? ASM-ben sokkal könnyebb rossz kódot írni, mert ott nincs aki megakadályozzon, tehát lefoglalok a memóriából, és elfelejtem felszabadítani, akkor ez rossz kód, szintén beletömök egy long-ot értéket egy short-ba és ez is rossz kód, a biztonságról ne is beszéljünk, de még sorolhatnám, tehát ASM esetében a programozón múlik minden, mígy C-ben már nem annyira, habár ott is egy pici pointer aritmetika ha nem figyelünk oda zűrzavart okoz, C++ ettől még egy picit többet segít a programozónak, C# meg már egész jó barátunk lesz. Szóval amit lejebb leírtam az áll, és oda kell figyelni, ismerni kell az architektúrát akármennyire is abstrakt szinten dolgozunk, de ha ASM-ben nyomjuk a dolgokat akkor sokkal de sokkal jobban oda kell figyelni, mert ott minden sorocska töllűnk függ, ellentétben a magasabb nyelvekkel ahol a könyvtárakban levő funkciók, osztályok stb. kódja már elég jól van optimizálva, és széleskörűen van használva, ezért sokkal magasabb minőségre és biztonságosabb kódra támaszkodhatunk. Szóval ASM szerintem ma csak oda kell, ahol tényleg a teljesítmény a legfontosabb, vagyis olyan rutinok optimizálására amelyek sokszor futnak ezáltal sok ciklust és vagy memóriát takarítva meg. De a valóságban az az igazság, hogy nagyon kevés a jó kód, és már örülni szoktam, ha a kód átlagon felüli, és ha ehhez hasonlítanánk egy tökre csiszolt kódot akkor sirva fakadnánk, de a gyors fejlődés és még gyorsabb elavúlás ehhez nem ad sem időt sem szükséget. Ma egyszerűen sokkal fontosabb a funkcionális kód, aki nem hiszi, gondoljon a Microsoftra, mert aligha volt nekik a legjobb kódjuk a világon és mégis a legsikeresebb programokat mondhatják magukénak, mindez éppen azért mert használható kódot állítottak elő és az optimizálás meg a többi dolog csak másodlagos volt számukra. Tehát fontos a dolgokat meghatározott keretek közé rakni és úgy figyelni, ha csak egy vagy néhány dologra összpontosítunk akkor jobb ha nem is csináljuk, mert nem fog az ég világon semmit sem érni.
Különben jól elmásztunk a Vistá-tól... vagy a Gartnertől... :) -
#80
"A változások legnagyobb része ugyanis olyan biztonsági frissítésekből áll, amelyek különböző forrásokból jelenleg is hozzáférhetők."
tovább:
"Az otthoni felhasználóknak azonban mindenképpen érdemes lesz belevágniuk a cserébe, már csak a nagyobb biztonság miatt is." De most akkor mirőőől beszélünk?
Emiatt nem fogok 40rugót(vagy többet)kiadni. Nehogymá' a 'biztonság' miatt vegyek új csili-vili winfost
Mellesleg ezt az ablak elfordítgatósdit már egy sw program (is) tudja....
-
dez #79 Persze, csak arról van szó, hogy pl. ASM-ben egy fokkal nehezebb nagyon rossz kódot írni (persze vannak kivételek), mint C-ben, és talán méginkább igaz ez a C++-ra, C#-ra, Javára, stb. Szal a programozón is sok múlik. De a legtöbben mégsem figyelnek oda. (Lásd pl. amit BlackRose írt a #78-ban.) -
BlackRose #78 Egyetértünk :)
Különben egyértelmű, hogy a .NET a Windows világban sokkal jobb mint a Java, és én a Java-t csak a non-Windows világban támogatom, azért mert ott nincs .NET, a Mono ugyan fejlődik, de legyünk komolyak, jelenleg nem igen fejleszt rajta senki sem komolyabb üzleti alkalmazást.
A másik dolog, pedig ha már a kód hordozhatóságának és optimizálásának a kombinációja a fő téma, akkor az igazság ott van, hogy habár a fordítók verzióról verzióra jobbak, még mindég nem lehet tényleg optimális kódot írni, ha nem célozzuk meg az adott architektúrát, processzorcsaládot. Pl. nézzük a követlező peldát - na itt most C/C++ és ASM fánok mind meglesznek elégedve :)
int i;
i = i / 4;
a fordtító a következő kódot generálja...
mov eax, i
cdq
and edx, 3
add eax, edx
sar eax, 2
mov i, eax
na most tegyük ugyanezt a következő képpen...
unsigned int i;
i = i / 4;
a fordító megtakarít egy csomó ciklust...
shr i, 2
tehát ismerve az x86 architektúrát, amikor lehet használom az unsigned tipust, másik architektúrákon ez lehet, hogy szintén jó lesz, de nem biztos, azokat is ismerni kell.
Na a baj ott van, hogy ha nem tudom ezt, és persze lusta vagyok gondolkodni, hogy az adott változónak csak pozitív értekei lehetnek vagy esetleg kell negatív is, akkor ezt én kihagyom és ezáltal lasabb tehát optimizátlanabb kódot írok.
Na most ide bejön a MSIL a közepébe vagy a JVM kód, és most akkor itt sok minden magától a JIT-től függ, na a .NET előnye itt éppen abban rejlik, hogy a JIT x86-ra optimizálódik, míg a Java esetében biztos, hogy szintén törekszenek az optimizálásra, de mivel több architektúrán kell, hogy dolgozzon ez vagy extra időbe kerül a Sun fejlesztőinek, vagy egyszerűen kihagyják. Na szerintem ez is hozzájárul a Java és .NET közötti teljesítménykülönbséghez. Érdekes, de ha a fenti peldát C#-ban megírjuk a fordító jó MSIL kódot generál és a JIT is ugyanezt teszi, tehát megkapjuk az optimizált gépi kódot éppen úgy mintha sima C-ben írnánk, vagy ha akarjátok ASM-ben is. -
Caro #77 Pont te mondtad, hogy .net winen kívül csak linuxra van eddig :) -
FTeR #76 azért az nem teljesen mindegy, h 1x megírok 1 fájl kezelő rutint, vagy 3x mert 3 különböző osre is szeretném elkészíteni... -
Caro #75 Na jó, de az ASM meg a C közt sokkal nagyobb a különbség, mint a C és a C# között.
A lényeg úgyis maga az algoritmus, azt meg semmilyen nyelv nem találja ki neked.
Az, hogy a C#-ben bevezettek néhány magasabb szintű dolgot, az csak egy dolog, ezek viszonylag kis részei a programnak, és nem azok, amik felett órákig kell rágódni. Szóval azokat a függvényeket megírod több platformra, és készen vagy. -
FTeR #74 asszem kicsit elcsúsztunk, mert onnan indultunk ki, h C/C++ban optimálisabb végeredményt kapunk. nem arról volt szó, h maga a programozó hogy old meg egy metódust.
Egy genercióval előbbi példát véve, hiába kapunk ASMben optimálisabb kódot, mégis C/C++ben programozunk (sőt C helyett is inkább C++ban), mert egy komolyabb progi (akár egy játék) 10 év és 100 fős csapat helyett 2 év 20 fős csapatból is megvan. Ez a C#ban mégjobban előjön, a létrejött kód újra hasznosíthatóbbságáról ([apto]de szép szó :)[/apro]) nem is beszélve. -
FTeR #73 értem én.
egyébként a kliens oldali kódnál teljesen más számít optimizációnak. nem kell azt szídni. ott a legfontosabb a forráskód mérete, aztán szünet, majd a teljesítménye. ezek a php-s dolgok is, meg olyanok, h méretüknél fogva egyáltalán nem éri meg optimizálni őket.
#70 ez is rendben, de a létrehozott objektum hiába foglal többet a memóriában, ha progrem többi része lehet semmenyit nem foglal, mert egy másik progival közösen használ (olvas!) egy memóriaterületet. ezért mondtam, h minnél több fut párhuzamosan, annál jobban előjön.
pl: memóriafoglalás párhuzamosan futtatott programnál (egységekben)
.NetC# | JAVA
4 | 3
elindítom a köv progit:
6 | 6
kövnél:
8 | 9
10 | 12
12 | 15
14 | 18
és akkor még nem számoltam ide, h ekkora javanál már 6 JVM van betöltve.
de teljesen mind1, mert minden másban egyértelműen jobb, tehát végeredményben .NetC# éri meg jobban. -
dez #72 Nem csak utólagos optimizálással lehet viszonylag optimális kódot készíteni, hanem átgondoltsággal, kiforrottabb programozási stílussal, jó programszervezéssel, stb. 5 perc gondolkodás többet ér, mint több óra "szívás". De milyen sokan megfeledkeznek erről... -
fflx #71 optimalizaljon az, aki nem ismeri hatarido urat. -
BlackRose #70 OK, de nem erre gondoltam.
Pl. ha csinálsz egy új objektumot
blablaOsztaly blablaObjektum = new blablaOsztaly();
ez .NET-ben több memóriát zabál meg mint a Java környezetben, ha meg pl. ebből csinálsz egy 100.000-es array-t akkor ez akár 2-3 szor is több lehet mint a Java környezetben. De mégegyszer mondom, ugyanakkor 2x gyorsabban fogok dolgozni ugyanezekkel a nagy memóriazabáló objektumokkal mint a Javaban. Különben erről valahol a TheServerSide.net-en vagy .com-on (egyik .NET, másik Java) lehetett olvasni, éppen a .NET 2.0-át és a Java 5-öt tették egymás ellen. -
BlackRose #69 A kód optimizálása akkor fontos, ha a befektetett erőforrás és idő megtérül azáltal, éppen úgy mint más dolgok által a listán.
De a jelenlegi szoftverfejlesztésben a kód újrahasználhatósága (komponensek fejlesztése) általában a legfontosabb. A második helyen általában a kód biztonsági oldala van vagy bár kellene, hogy legyen, harmadik a kód jó azaz bővíthető szervezése van. Az optimizáció a mai memóriaözönben meg processzor teljesítményben csak ritka alkalmazások esetén fontos, persze ez nem jelenti, hogy tökhülye kódod kell írni... de mégis megvan a határ. Általában azt tapasztalom, hogy azok a fejlesztők akik ismerik a C/C++, vagy még jobb az ASM-emet is, azok jobb és optimizáltabb kódot írnak, azok az általában újkeletű fejlesztők akiknek a Java vagy VB, Delphi volt a tanulóplatforma vagy még roszabb, webfejlesztéssel kezdték és JScript-en, PHP-én meg HTML-en lovagolnak, azok sokkal optimizálatlanabb kódot termelnek. Persze van kivétel, de általában ez a szabály. Különben a .NET-el tényleg lehet nemnormálissan optimizálatlan kódot írni, ezért kell előbb jól megtanulni, sokan nekiűlnek és a Hallo World után produkciós kódot írnak, de ez általában szemét kód. Nem szeretem azokat akiknek nincs legalább 6-9 hónap erőss (mindennapi néhányórás) gyakorlatuk, egy csómó könyv elolvasásával együtt. Mennyire nem szeretem őket, annyira, hogy nem dolgozok velük. Különben a fejlesztői munkakörnyezetemben 3 emberre számíthatok akik végig csinálták az ASM-től a C#-ig, és kimondott szabálynak tartom, hogy Phyton, Ruby, Perl vagy valami hasonló dolog is legyen az újjukban, mert a soknyelvűség nagyon jó effektussal jár mint az optimizált kód írására, úgy a jó szervezettségre is. Mégegyszer mondom nagyon kevés függ a platformtól, inkább az emberek határozzák meg a kód minőségét. -
FTeR #68 "A .NET mindenben jó, kivéve egy dologban nem, ez pedig a memóriaigény. És ennek megvan az oka, mivel abstrktizál kereskedni kell két dolog között ami nem éppen fér össze, nagyon neház ilyen magasszintű abstrakt környezetben memóriatakarékosnak és gyorsnak is lenni. Ha a .NET-et és a Java környezetet hasonlítom össze, akkor a .NET jóval gyorsabb, de jóval memóriaigényesebb is. Míg a Sun valahogy a kettő közé beült, a Microsoft inkább a teljesítményt választotta."
ez addig igaz, míg 1db futó programról beszélünk. JVM-nél ha párhuzamosan elidítasz egy másik programot is, akkor egyből minden erőforrás igénye megduplázódik. .NetFW-nél ez egyáltalán nem így működik. minnél több progit futtatsz párhuzamosan, annál jobban előjön, h a .Net a jobb.
példa: ha az előző progi már betöltött egy osztály könyvtárat, akkor az újonnan indúló már ugyan azt fogja használni. JVMnél úgy tesz, mintha a másik nem is lenne. próbálkozások vannak, de egyelőre ahány JAVA progi fut, annyi JVM aktív.
és lássuk be, az elég valószínűtlen, hogy egy gépen csak 1 progit futtasson az ember. -
FTeR #67 az a valóság, h a kód optimalitása a sokadik szempont...
ha az lenne az első, mint ahogy hiszitek, akkor még mindig asmben programoznánk. -
Caro #66 Igen, de mégis minden más szempontból optimálisabb kódot kapsz.
És azért ez elég ritka, tegyük hozzá. -
FTeR #65 de .nettel ellentétben ennél nem lehet arra számítani, h az adott könyvtár rajta van a platformon, vagyis máris nem lehet rá építeni. az esetleges platformok könyvtárai közötti eltérésről nem is beszélve. már azzal is gond lehet, ha 1 fájlt el akarok menteni... -
dez #64 Nem kell mindent tartalmaznia a programnak. Vannak multiplatform GUI-kezelők, OpenGL és klónjai, stb. -
FTeR #63 érdekes itt egy ilyen hír és még sincs flém. tök normális a vita. 100+ komment így is meglesz. mennyivel normálisabb lenne így az egész. -
Alfa Of NS #62 Lehet azert annal komolyabbakra is 
En pl egy ideig igy fejlesztettem egy kollegaval egy mesterseges intelligencia programot, igaz a grafikus resznel bebuktuk a hordozhatosagot 
Amugy mivel a .NET lenyeget tekintve igy mukodik, igy elmeletileg lehetseges lenne a dolog.