AMD konci s x86?!?

[Marek Sembol]

Dovolim si lehce vstoupit do diskuze:)
Nejdriv se vyjadrim k tomu, ze "po prepsani do .NET je to pooooomale":
zde je problem prekvapivy - programovani v .NET je (zdanlive) prilis
jednoduche a tak si kazdy BFU mysli, ze je Pan Programator, Ten
Nejchytrejsi a tak. Kdysi, kdyz to bylo v C tak clovek prece jen musel
neco malo umet. Ted to splaca v .NET kdekdo a vysledky byvaji obcas
tristni:( Sam jsem zazil nasledujici situaci ve zdrojaku (VB.NET).
Funkce GetCount byla deklarovana, ze vraci String! Uvnitr se samo
vracelo cislo (takze chudak framework si musel Int32 prekonvertovat do
textove podoby, naalokovat na to pamet, inicializovat objekt a tak).
No a na strane odkud se to volalo byl vysledek (zcela logicky)
prirazen do Int32 (takze opet si musel framework rozparsovat ten
String co dostal vcetne vsech kontrol zda to opravdu cislo
predstavuje). Ja rikam: neni problem v .NET, ale v programatorech (a
tech co se za ne vydavaj)

Proc "neni calc v .NET"? Nevim co k tomu M$ vedlo. Jeden velmi dobry
duvod mne napada: mne osobne se nezda .NET prilis vhodny na malicke
utilitky (kterou calc bezesporu je). Nemile na .NET je to, ze i
drobnost naroste v pameti do nechutnych rozmeru. U vetsiny sluzeb to
neni problem (vetsinou to neni jen "mala utilitka"). U baliku typu
Visual Studio ci Office to taky neni problem (jestli to bere 60M nebo
65M uz neni takove nestesti). Horsi je to u tech drobnosti (clovek ma
rozjeto bezne 20 "drobnosti" a kdyz kazda bere 20M misto 2M tak je to
nestesti). Ale treba byl duvod ten, ze to opravdu prislo jednoduzsi M$
jen "trochu prepsat stavajici kod".

Proc je .NET prinosem?
-automaticke uvolnovani pameti. Ja vim, opravdovi programatori to
nepotrebuji:) Ale kdo z nas se nikdy netrapil s tim, ze mu aplikace
uzirala.... Mnozi z nas resili problemy ne s "neuvolnovanim" pameti,
ale s rozfragmentovanim pameti (a to byvalo jeste horsi). U slozitych
datovych struktur jsme venovali hromadu usili pocitani referenci na
naalokovanou pamet a travili bezesne noci kde jsme ji zapomneli zvysit
(a aplikace padala) ci snizit (a zrala pamet).
-kontrola bufferu. Komu z nas se nestalo, ze si "cmaral po pameti"
(vetsinou psal par bajtu za naalokovane pole) a ono to pak "nekdy
spadlo". Hodne neprijemne se to hledalo. Ja sam jsem vydelal celkem
dobre penize u nekolika externich firem kdyz jsem jim pomahal s
hledanim techto problemu. Podobne problemy s bezpecnostnimi derami
typu "podteceni/preteceni bufferu". Techy taky bylo az az...
-zavedeni atributu ohromne zjednodusilo a zprehlednilo hodne problemu
-reflexe taktez
-velmi zajimava je nezavislost na CPU (mne osobne stejna aplikace bezi
na 64bit OS jako 64bit, na x86 bezi jako 32bit a na par prenosnych
terminalech bezi ani nevim na jakem CPU (asi ARM? bez zaruky). Vse
stejny EXE! Teoreticky by asi bezela i na Linuxu s Mono...
-hodne veci se zjednodusilo (napr. lokalizace)
Takhle by slo pokracovat asi jeste dlouho. ANO, prinasi i radu
nevyhod, to nepopiram:)

Marek



2011/11/30 Miroslav Šinko <sinkomiro na gmail.com>:
> On 29. 11. 2011 20:44, Petr Zahradnik wrote:
>>
>> Od Microsoftu je toho v .NET napsáno mnoho a mnoho. Že jádro
>> operačního systému není napsáno v .NET, to je rozumné, že aplikace
>> typu Kalkulačka nejsou přepsané do .NET, to mi nevadí a je to i
>> logické.
>
> Toto ma zaujalo. Aby som uviedol suvislosti.. som programator, vacsinou
> robim ANSI C procesy pod Win (teda okrem startupu by mali byt platformovo
> nezavisle, ale na nicom inom ako Win32 a WinCE testovane neboli), poznam
> Win32API (pred nejakymi rokmi som vyvijal Win aplikacie, t.j. GUI, atd je mi
> celkom doverne zname). Naopak Linux nepoznam takmer vobec (ako BFU som
> chvilu cez GUI Debianu cosi obsluhoval, spustal, apod).
>
> Ale nerozumiem nazoru, ze to ze Kalkulacka nie je v .NET, je logicke. Na
> Win7 je prave ta kalkulacka uplne ina, ako na W2k/XP (este aj na W95 snad
> bola rovnaka). T.j. pre Win7 ju prepisovali. Preco nie .NET? A preco je to
> logicke?
>
> Zaverecne suvislossti: podla mna je .NET blbost (ok, mozno silne slovo,
> subjektivny nazor, ale stojim si za nim). Prave preto, ze poznam WinAPI, mi
> .NET nesedi. Co prinas nove? Kniznice? Daju sa urobit aj pre WinAPI. Mensie
> naroky na programatorov? OK... Ale za cenu vyssich narokov na RAM vykon PC
> atd... preco? naco? aj zabudanie uvolnovania buffrov programatormi sa da
> riesit kniznicne. Ked si za nim MS tak stoji, preco aj tu kalkulku neurobila
> v nom? Na tak primitivnej aplikacii by to vobec, ale vobec nevadilo
> (spomalenie by nebolo na sucasnych PC pozorovatelne).
> Sam tiez nepoznam "nic viditelne" od MS napisane v .NET. Pozrime sa inde.
> Take ovladace ATI kariet. Kedysi bol Control Panel pisany vo WinPAI...
> click, click, OK a bolo. Potom prisiel .NET Control Center.
> 1) nesiel spustit, ziadal instalaciu .NET Framework. OK, dnes to ma kazdy,
> ale vtedy to bol krok navyse (a par 10-tok MB cohosi na HDD)..
> 2) click................wait............aaa nieco nabehlo....
> click..........wait..... no a tak. OK na sucasnych strojoch wait=1s, ale kde
> je prinos? Preco by nesiel ovladaci panel aj dnes napisat jednoducho a rycho
> pri zachovani funkcnosti?
>
> Tot votazky. A este raz opakujem - som vyvojar pod Windows.
>
> miro
>
>
>> Že má Microsoft tuny kódu už napsaného a chce ho využít, to
>> je také logické. K čemu by bylo, kdyby ty malé aplikace, které jsou
>> součástí operačního systému, jsou tam už roky, jsou spolehlivé a ten
>> kód existuje, někdo přepisoval?
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>