Hvad er .NET?

Rigtig god artikel, den udpensler nogle af de emner, som jeg synes mange lærebøger om .NET og til dels også Microsoft (selvom mit engelske er ret godt, kan sproget på Microsofts sider omkring emnet godt forvirre) springer let hen over, f.eks det med assemblies.

yir yir min første nyhed (der er kommet igennem nåleøjet) ;)

Man skal ikke læse længe inden man ramler ind i en fejl:
for writing programs that can easily and securely interoperate

Hvis man bruger C# i unsafe mode, har man adgang til pointere og så ryger sikkerheden meget nemt en tur i vasken.

Og siden hvornår har Microsoft været kendt for at lave sikre ting ?

Sguft:
Tillykke :)

#3 - Ja, nu har de aldrig været kendt for det.. men det kan da være der er en smutter :)

Disky:

punkt 1:
.Net er IKKE C# - C# er et selvstændigt sprog der benytter sig af .Net platformen (det ville du vide hvis du læste artiklen)

punkt 2:
bare fordi det kan lade sig gøre, hvis man vælger det meget bevist, at lave unsafe kode betyder det jo ikke at sproget er unsafe - det kan også i f.eks. java lade sig gøre at wrappe en C++ klasse ind i en java klasse og det er jo heller ikke ligefrem safe - gør det java unsafe??? Det skal måske tilføjes at det aldrig nogensinde er nødvendigt at skrive unsafe kode i C# - det er kun muligt for at man, hvis man ved hvad man laver, kan performance optimere sin kode.

"Og siden hvornår har Microsoft været kendt for at lave sikre ting ?"
Den kommentar beviser for det første at du ikke ved ret meget om baggrunden for .Net og for det andet at du kommer til sagen med alt andet end en objektiv holdning.

nah gider ikke starte en lang debat om c# og pointere alligevel, så har slettet teksten (har dog samme mening som regus) :)
og for lige at slå det fast, ms har lavet CLI'en/C# til freebsd/mac os x: http://download.microsoft.com/download/.netframesd...
til linux er der mono (www.go-mono.com), så C# er ikke win only :)

Regus:
Tro mig jeg ved UDEMÆRKET hvad .net er.

Hvor skriver jeg at C# er .net ????

Læs hvad folk skriver, ikke hvad du tror de skrive !

En interfacing til en C++ klasse fra Java er IKKE Java !
Venligst undersøg teknologierne INDEN du udtaler dig om det.

Det er sjovt du falder i med begge ben når man kommer med en mini provokation om .net's sikkerhed.

Men jeg vil da opfordre dig til at modbevise min påstand om at .net er en hullet si hvad angår sikkerhed.

DaQuar:
Ja men jeg tvivler :))))

Glimrende artikel, som kommer omkring nogle ting som de fleste steder på nettet undlader.

Og ihhh hvor er jeg glad for .NET det er helt genialt efter min mening, der er dog nogle småting som ikke er implementeret helt hensigtsmæssigt, men mon ikke det bliver rettet i fremtiden.

#2 nu er det heller ikke så helvedes svært at smide en nyhed igennem newz DJ!!!

#9 - Og det er derfor du kun har et nyhedsindlæg ? :P

#9: uha, der er nok en der er morgengnaven..sagde kæresten nej igår? :p

btw. hvad er en DJ udover at være en discjockey?

Jeg må indrømme, at jeg ikke forstår et klap af den terminologi, artiklen beskriver.
For mig at se skal man vist være lidt mere end autodidakt PHP-nørd på hobby-niveau for at forstå artiklen.
Men ikke desto mindre kunne jeg nu godt tænke mig at lære lidt om, hvad fordelen ved .NET er i forhold til de mere klassiske måde at programmere på.
Er der nogen artikler, der sammenligner og beskriver .NET i forhold til f.eks. traditionel ASP eller PHP?

/Mikkel

#7:
Det kunne være du skulle bevise at det virkeligt er hullet som en si hvad angår sikkerheden, normalt er man ikke skyldig før det modsatte er bevist - så få nogle facts på bordet.

Det er altid nemt at slynge noget ud og bede modparten om at modbevise det, langt sværere er det hvis man også selv må argumentere for de påstande man kommer med.

Der står at .Net er ikke er et rip-off af Java...

Hvis man ser bort fra at man kan bruge flere sprog til at kode .Net; hvad er det så lige der er originalt ved .Net?

#12: Den sammenligning ville være helt krotesk da de 2 ting intet har med hinanden at gøre.

#13:
Hvorfor skulle jeg dog det ?

Min vurdering er subjektiv, ud fra min erfaring med Microsoft produkter, hvis hans modspil også er subjektivt fair nok, så er den ikke længere.

Men hvis han ønsker objektivt at vise at .net er sikkert så må han jo ligesom dokumentere det.

Disky: Normalt er det ret svært at påvise at noget er sikkert før det modsatte er bevist. Så hvis ingen er istand til at bevise at det er usikkert, må det altså betragtes som værende sikkert. Jeg er dog ikke i tvivl om at der findes fejl i .NET, intet er perfekt i denne verden, ej heller java, men som det ser ud indtil videre lader det ikke til at der er mange børnesygdomme i .NET, det virker rent faktisk ret robust.

Derudover skal det jo så også nævnes at det nu er ECMA og ikke Microsoft der varetagerudviklingen af .NET.
Microsoft varetager kun deres egen version af produktet, det står alle frit for at implementere open source versioner etc af .NET, som f.eks. er tilfældet med Mono projektet der har linux platformen som målgruppe, og de ser faktisk ud til at gøre et ganske fremragende stykke arbejde, de har netop portet ASP.NET til linux og en fuld implementering af .NET forventes klar til sommer.

slettet

Jeg synes ikke jeg kan se nogen fordele ved at bruge .Net fremfor Java, tilgengæld kan jeg hurtigt finde et problem. WinForms lyder som noget folk ville være glade for at bruge, men det er nok ikke voldsomt nemt at flytte fra platform til platform. Jeg kunne forstå at Ximian er ville prøve at få Mono til at bruge GTK+ til WinForms delen, men helt ærligt virker det ikke som en fed løsning. Jeg tror ikke man skal forvente at grafiske .Net ting komme til at se ens ud på alle platforme. De brude nok have kikket på en løsning i stil med Javas Swing og AWT.

Jeg ved ikke, måske har jeg bare ikke set lyset, men jeg er ikke imponeret af .Net. I begyndelse virkede det også lidt som om marketings folkene hos MS fandt ud af at .Net lyder smart og så senere hen gav programmører og software designere besked på at lave noget der kunne bære navnet .Net.

Disky
"Tro mig jeg ved UDEMÆRKET hvad .net er."
No offense men det tror jeg faktisk ikke på - din udtalelse omkring Microsoft tyder kraftigt på et ret overfladisk kendskab og uvidenhed omkring adskillensen mellem CLI og CLR

"Hvor skriver jeg at C# er .net ????"

Du indrømmer altså at følgede sæting er fuldstændig malplaceret og off topic
"Hvis man bruger C# i unsafe mode, har man adgang til pointere og så ryger sikkerheden meget nemt en tur i vasken."

Jeg minder for god ordens skyld om at artiklen handler om .NET ikke C# og .NET kun om .Net. C# næves i artiklen kun for at sige at det ikke er en del af .NET

"Læs hvad folk skriver, ikke hvad du tror de skrive !"
Tyv tror hver mand stjæler... 'nough said

"En interfacing til en C++ klasse fra Java er IKKE Java !"
Jo det er det er en del af Java ikke af C++ der gør denne interfacing muligt det er sågar dokumenteret i suns egen Java dokumentation - Det ville jeg egentligt have troet at en der er meget glad for, og angiveligt kometent indenfor, java ville vide.

"Venligst undersøg teknologierne INDEN du udtaler dig om det."
Jeg er ked af det, men JEG har rent faktisk lavet mit hjemmearbejde.

"Det er sjovt du falder i med begge ben når man kommer med en mini provokation om .net's sikkerhed."
Jeg forstår overhovedet ikke hvad du hentyder til - du vil måske sige at din påstand omkring .NET er fuldstændigt uberretiget og kun tænkt til at få .NET sealoter til at falde i?

"Men jeg vil da opfordre dig til at modbevise min påstand om at .net er en hullet si hvad angår sikkerhed."
Jeg vil benytte mig af metoden som foreskrevet af Kuhn, og fremstille den teori at .NET er sikkert - da min påstånd utvivlsomt er vildere end din og da den stadig ikke er modbevist er min påstand at betragte som den rigtige.
Ergo handsken er kastet tilbage hvor den hører til.

Mr.Weasel

lad mig hurtigt nævne et par stykker
1. det bygger på åbne standarder
2. det er sprogneutralt

#20

Ahhahaha...

200 bonus point til Regus for at citere Thomas Kuhn. Er niveauet på Newz.dk ved at hæve sig? Vi håber stadig....;)

#21

De åbne standarder, det er rigtigt, hvordan kunne jeg egentligt over se det. Det er faktisk meget pænt af Microsoft.

Men jeg holder på at man ikke behøver Java for at kører ting på Suns JVM. Man kan sagtens kompile andre sprog til Java bytecode, det er bare aldrig nogne der f.eks kan lavet en C til bytecode kompiler. Jeg har som projekt på AAU været med til at designe til programmeringssprog og vi valgte at kompile til Java bytecode, det er ikke det store problem... selvfølgelig kan det være nogle begrænsninger, men dem ville jeg nu også forvente med .Net.

Mr.Weasel

Det kan sikkert sagtes lade sig gøre, men jeg ved ikke hvor let det ville være at nedarve og andet mellem sprogene - hvor man i .NET snildt kan lave en klasse i Managed C++, nedarve den fra VB og bruge de i C# som han også nævner noget om i artiklen.
.NET er designet med interoperability for øje, hvilket givetvis vil være en fordel i forbindelse med at lave det.

Desuden og vigtigts af alt så er .NET allerede implementeret i en hel del sprog og interoperabilitien er altså en realitet i .NET hvor den er mere teoretisk i java

hmm.... er .NET ikke det der i Antitrust kaldes for Synapse? :-)

#20 Enig...!
Rart at se et at diskussionerne på Newz kan være andet og mere end småknægte der battler. Det kunne være rart hvis man rent faktisk kunne lære noget af indlæggene - og ikke blot spilde sin tid på pladder og ordgejl...

regus:
Bare fordi sun beskriver det er det ikke ensbetydende med at det er i Java interfacingen foregår.

Man laver en

public native void displayHelloWorld();
for at specificere en c++ klasse, ovenstående er det eneste man skal lave i java for at gøre det, resten foregår i C++ koden, hvor eventuelle pointer problemmer osv opstår.

Ellers kalder men metoderne via almindelige metode kald.

Resten af interfacingen foregår i en .h fil der beskriver metoderne man kan kalde.

Hvis du vil vide mere kan du jo læse:
http://java.sun.com/docs/books/tutorial/native1.1/
Som er en glimrende tutorial om emnet.

Angående .net sealot's så faldt du i med begge ben :)

Disky: Det du beskriver der må da være en lige så stor "katastrofe" som pointere i C#?

Du har _mulighed_ for at afvikle unsafe kode i Java (via C++)hvis du meget explicit ønsker det, ligesom du har _mulighed_ for det i C# hvis du meget explicit ønsker det.
Eneste forskel er jo så bare at i C# behøver du ikke gøre brug af et 3rd party sprog for denne fleksibilitet som du tilsynelandende er nødt til i Java.

Derudover kan jeg overhovedet ikke se det problem som du prøver at pointere med unsafe kode i C#, hvis det er man explicit har erklæret det i metoden, erklæret unsafe attributter og tilføjet /unsafe parametre til compileren, så er det nok fordi man mener det seriøst og ikke bare noget man sådan kommer til ved at uheld hvis man ikke ved hvad man laver ;)

Så hvor er det lige den "katastrofe" indtræffer du har så travlt med at hive frem ved enhver given lejlighed?

#23

Men jeg holder på at man ikke behøver Java for at kører ting på Suns JVM. Man kan sagtens kompile andre sprog til Java bytecode, det er bare aldrig nogne der f.eks kan lavet en C til bytecode kompiler. Jeg har som projekt på AAU været med til at designe til programmeringssprog og vi valgte at kompile til Java bytecode, det er ikke det store problem... selvfølgelig kan det være nogle begrænsninger, men dem ville jeg nu også forvente med .Net.

Forskellen er at .NET er designet med multiple source sprog for øje.

Et lokalt daimi (Århus Uni) projekt arbejder netop med at compile deres eget sprog (Beta) til henholdsvis .NET og Java platformen, bla. med henblik på at sammenligne de 2. Check fx. sammenligning af source level debugging ;)

http://www.daimi.au.dk/~beta/ooli/

Disky


Du glemmer en lille detalje og det er at Java ikke kun beskriver sproget men også VM'en og hvad der ellers følger med - og interfacing foregår i Java i den brede forstand hvad enten du vil indrømme det eller ej. Og Java understøtter som man vil kunne læse afviklingen af platformsspecifikt pointer aritmetisk dybt usikker kode gennem bruge af native kode alias C++. Det er en smule mere besværligt end det er i C#, men det er basalt set samme fare endda med lidt ringere features end i C#.


Jeg har uhyre svært ved at se hvorledes MULIGHEDEN for at afvikle usikker kode kan mindske sikkerheden af noget - det er jo ikke fordi programmøren der skal kode det er af ond vilje og hvis han er dum nok til at gøre det uden at vide hvad han laver så fortjener han også den medfølgende lyserøde seddel.
Men jeg er da glad for at du godt kan se at .NET er et fremragende og sikkert koncept, og at C# er et velfungerende sikkert sprog. Jeg er da lidt ked af at du føler det nødvendigt at genere andre af sammen holdning ved at lægge fælder for dem, men du er tilgivet for denne gang.

#17
"Derudover skal det jo så også nævnes at det nu er ECMA og ikke Microsoft der varetagerudviklingen af .NET."
ER DU SINDSYG????
Microsoft vil sq da aldrig forære sådan noget væk!!!

ECMA styrer en lille bitte blok af .NET, menlig CLI/IL.

Der er en lille artikel på securityfocus der måske kunne være interessant i denne sammenhæng:

Secure Programming with .NET

http://online.securityfocus.com/infocus/1645

/bmc

Mazon

Nu er det jo ikke fordi CLI/IL er e lille del af .NET... man kunne fristes til at påstå at det <STRONG>er</STRONG> .NET

#31: Som regus også nævner så ser jeg CLI/IL som kernen i .NET (bemærk at jeg ikke skrev Microsoft .NET).

Microsoft har så deres egen implementering af .NET hvor der ligger noget ekstra gejl med, bl.a. en webdel i form af ASP.NET og en databasedel i form af ADO.NET, hvilket ikke er en del af selve .NET Development Frameworked, men de er en del af Microsoft .NET platformen.

(ja, det kan virke en smule forvirrende ;)

#33
"Nu er det jo ikke fordi CLI/IL er e lille del af .NET... man kunne fristes til at påstå at det er .NET"
Nej, .NET er en eller anden marketing gimmick, MS har opfundet. CLI = Common Language Runtime - at det bliver brugt af .NET platformen er bare hvad det er.
.NET != CLI

Læs i øvrigt mere her:
http://www.ecma.ch/ecma1/STAND/ecma-335.htm

#34
Du er ekstremt forvirrende at forstå - først snakker du om .NET som værende et ikke MS produkt, og derefter nævner du MS.NET...
.NET *er* Microsofts opfindelse - punktum end of discussion.

Der er dele af .NET platformen, som ikke indeholder MS specifikke *udvidelser* - så som ASP.NET, ADO.NET eller sågar System.Data.SqlClient. Men uanset hvordan du vender og drejer det, er .NET et microsoft produkt. De har bare valgt at implementere noget i core(mscore assembly), og andet i extensions

At de så ligger extensions i core namespace er fuldstændig fucked! (System.Data.SqlClient skulle ikke ligge der, men i Microsoft.Data.SqlClient eller whereever - ligesom deres andre specifikke ting (f.eks Microsoft.ViasualBasic.*)

sguft:
Prøv at kig på hvor mange sikkerhedsfejl der skyldes bufferoverrun, så ved du hvorfor at pointere rent sikkerhedsmæssigt kan være noget farligt noget, også selv om man _explicit_ skal bede om det.

MHT security, er jeg enig med 'Disky' om at Java i sig selv ikke er usikker. Det er ikke muligt at lave usikker kode med Java (når vi snakker pointere). Via JNI, er det muligt at lave noget kode der kan få JVM'en til at gå ned - men du kan ikke med *java* kode lave det usikkert...

C# model er jeg meget i mod, generelt har sproget en masse dejlige features (autoboxing specielt) - men som udgangspunkt synes jeg at det er uklogt at give mulighed for unsafe kode - det *vil* give problemer (tænk 32/64 pointere - nams det skal nok give problemer :) ).

Jeg har dog ingen grund til at anfægte .NET's security model (bortset fra unmanaged kode) - tværtimod... - men jeg er ikke nok inde i den endnu...

heh - fra http://online.securityfocus.com/infocus/1645:
"...On the other hand, unmanaged code is not protected by the framework and should be avoided if possible."

Mazon:
Fedt citat.

Man forsøger at lave en sikker model, men så laver man lige et par smuthuller uden om dette, og vupti hele ideen ryger en tur i vasken.

Det er ligesom at stille en kasse hvor der står 'må ikke åbnes' et sted, og så er man helt sikker på folk åbner den.

Skal man lave noget der er sikkert skal man være konsekvent og ikke tillade huller, heller ikke selv om man explicit skal bede om at de åbnes. Husk ingen kæde er stærkere end det svageste led.

35: Jeg indrømmer det måske ikke er helt korrekt at bruge terminologien .NET omkring core elementerne, jeg forsøgte bare at gøre rede for hvad jeg henviste til når jeg brugte den terminologi. Samme terminologi som mono gutterne bruger når de henviser til core elementerne i frameworked, men skal da ikke kunne sige om det bare er et udtryk de bruger for at vise sammenkædningen.

36+37: Som sagt, jeg opfordrer ingen til at bruge UNSAFE kode og det er slet ikke nødvendigt for at programmere i C#, ligesom det heller ikke er nødvendigt i Java.
Ingen ved deres fulde fem vil explicit erklære på 3 forskellige niveauer at de ønsker at tilgå UNSAFE kode, for derefter at skrive koden uden at de er klar over hvilke konsekvenser dette kan få. Det ligger desuden ret implicit i ordet UNSAFE at det typisk er noget man skal holde sig langt fra.

38: Klart de advarer mod brugen af UNSAFE kode, det er også det eneste rigtige at gøre, men jeg ser ikke noget ondt i at muligheden foreligger, eftersom jeg, modsat jer, er overbevist om at de fleste nok skal holde sig langt væk fra det og dem der er dumme nok til at begynde at tilgå det uden at de er klar over risici ved det, er jo stort set lige så absurd som at lade en 3-årig knægt rode rundt i stifinder og hamre lidt tilfældigt ned i tastaturet.

Hmm mindre rettelse. CLI beskriver dele der skal være tilstede i en CLI implementation (hvad MS kalder core, går jeg ud fra):
"There are two Standard Profiles. The smallest conforming implementation of the CLI is the Kernel Profile,
while the Compact Profile contains additional features useful for applications targeting a more resource-rich set
of devices."
alt sammen står i specifikationen...

Hvad angår adskillelsen CLI og CLR så må jeg nok indrømme at jeg ikke gider læse dybt nok i emnet til at tage en seriøs diskution om det - personligt har jeg intet udeståede med MS og er derfor lidt for ligeglad til at studere til en diskution på newz - hvis i forstår hvad jeg mener :-)

<STRONG>Advarsel:</STRONG>
Følgende kan garanteret godt tolkes som et stor og ondt angreb fra en led microsoft tilhænger og kapitalist imod Java, det er på ingen måde tænkt sådan. Jeg skal ikke påstå at jeg er vidre begejstret for Java, men jeg gør et ærligt forsøg på at tage objectivt fat.

og hvad angår unsafe kode så har jeg umenskeligt svært ved at se problemet i at give programøren adgang til at gøre det hvis han virkeligt vil - den holdning deler Sun tydeligvis omend de har implementeret det anderledes end Microsoft. Og jeg ville da aldrig hyrre en spade der var dum nok til at bruge det uden at have en meget god grund til det - jeg kunne heller aldrig finde på at lave inline assembler i mine C++ programmer med mindre jeg har en meget god grund til det (påstand: det meste inline assembler er en dårlig undskyldning for ikke at have forståelse for compileren og pointer aritmetik - jeg er personligt aldrig stødt ind i noget hvor jeg kunne skrive bedre assembler en compileren kunne når jeg havde hjulpet den på vej med pointer aritmetik)

Bufferoverruns skyldes ikke pointere de skyldes at der i bl.a. C++ ikke er range checking på arrays - det eneste punkt hvorpå pointere adskiller sig fra referencer er i muligheden for at lave pointer aritmetik en ting som de færreste i virkeligheden beytter sig af (ensige fatter et klap af) - jeg bruger det selv ofte i forbindelse med strengmanipulation hvor det kan forbedre ydelsen en hel del - men jeg ved også hvad jeg laver og jeg holder skaprt øje med det.

Til trods for at jeg benytter mig af pointeraritmetik og genrel direkte memory manipulation i C++, har jeg aldrig følt nogen trang til det i C#, sproget lægger i modsætning til C++ ganske simpelthen ikke op til det - men jeg er da jublende glad for at jeg kan gøre det skulle jeg en dag få den idé at lave et high performance library til et eller andet, eller på anden vis få brug for det.

Det der gør forskellen på C++ og andre sprog hvori buffer overruns opstår og sprog hvori de ikke opstår er ikke pointere det er hele managed versus unmanged code konceptet og det dækker en del mere end en smule pointere - det er en helt anderledes måde at tænke kode og compilation på, og min kodestil i C++ og C# er da også meget forskellig, jeg vil sige at i C# tenderer man til at blive mere sløset med sin allokering og deallokering af ressourcer, og kan let komme til at lave nogle leaks der er helt unaturlige i sprog med explicit destruction:

Et klassisk eksempel demonstreres i Suns tutorial hvor de skal forklare listeners og opretter deres listener class som en anoymous class i selve kaldet til AddListener uden at beholde en reference til at afregistrere med - og selv om de skulle have gjort det er der ikke noget naturligt punkt at afregistrere da finalize ikke bliver kaldt før efter den er blevet afregistreret. Det er ikke en kritik af Java specielt det er et problem som all managed sprog lider under: Mangel på et naturligt punkt til at frigive ressourcerbindinger.

Ja ja siger i så, men så laver man bare en release metode - og det ville selvfølgelig være fint hvis bare 10% af programørene rent faktisk læste andet ligepræcis den stump af dokumetationen de har brug for - I sprog med explicit destruction er det naturlige punkt givet og med mindre programøre der bruger din klasse enten sover eller ikke strukturerer sin kode ordentligt vil ressourcerne med garanti blive firgivet.

Deværre lever vi langt fra i en perfekt verden, og begge situationer vil næsten med garanti opstå så tit at vi helst ikke vil høre om det. Det der så bekymrer mig ved managed kode er at det giver en falsk trykhed som jeg tror mange nye programører bliver lullet i søvn af.

Men til sidst vil jeg blot sige: programører er ikke spædbørn og man skal ikke pakke dem ind i vat. Et sprog behøver ikke gennemtvinge sikker kode det skal bare lægge op til det og gøre det naturligt og enkelt at skrive. Jeg er stærk modstander af spændetrøjer hvad end de uddeles af Sun, manden i den blå bil eller regeringen.

Det tog lidt tid for mig at acceptere et managed miljø jeg er vant til C++ og har været meget glad for at jeg altid har vist præcist hvad der skete når jeg skrev en stump kode - men den betydeligt højere, og her taler vi måske 2-300%, produktivitet som C# og .NET tilsammen har givet mig, har været et kraftigt incitament for at vælge det frem for C++. Jeg har flere gange kigget på(læs kodet i) Java og det har hverken givet mig en øget produktivitet eller en god fornemmelse at kode, det er for kringlet lidt ligesom Beta - det holder så hårdt på en idé om ægte objektorientering at man glemmer programøren i processen

Undskyld indlæget blev så langt

Jeg mener at .NET er et fremragende initiativ som udover at være en del af MS' strategi vil vise sig at gøre en stor forskel for rigtig mange udviklere verden over. Det er det mest omfattende forsøg på at åbne for muligheden for at dele en kodebase imellem sprog og platforme. Microsoft har brugt mange resourcer på at inddrage mange sprog (og dermed støttet diverse forskningsgrupper) - også småbitte sprog som Mercury og Haskell (http://msdn.microsoft.com/vstudio/partners/languag...
At muligheden for at tilgå unmanaged kode skulle være en flaw på nogen måde har jeg svært ved at sætte mig ind i. Som Regus udmærket formulerer det bør et sprog, framework eller platform ikke begrænse en udvikler men blot lægge op til den mest hensigtsmæssige brug.
Hvis .NET udelukkede al brug af unmanaged kode ville jeg (for one) ikke have en realistisk mulighed for at konvertere min kode da det reelt skulle skrives forfra. Nu har jeg i stedet muligheden for at konvertere komponenter løbende og eventuelt beholde forskellige, særligt optimerede funktionaliteter c++.
Desuden synes jeg vi kan være stolte af at det er Anders Hejlsberg som også gav os Turbo Pascal i sin tid, der er en af hovedarkitekterne bag alt dette. Bjarne er ikke den eneste dansker der kan lave en sej programmeringsplatform.

#43: hehe som gammel pascal udvikler er min konklusion at Anders Hejlsberg er gud ;)

[OT]
"Men til sidst vil jeg blot sige: programører er ikke spædbørn og man skal ikke pakke dem ind i vat."
100% enig, men jeg bliver gang på gang overrasket over hvor mange folk derude som *aldrig* skulle have være programmører...

Mazon
Aye agreed :-)
Men den slags ville kunne ødelægge en to ton tung granitsten med en tot vat

#44 - ja, som Joel Spolsky formulerer det, var skiftet fra IBM Pascal til Turbo Pascal:
[...] as if a company you had never heard of introduced a clone of the Buick LeSabre which could go 1,000,000 MPH and drive around the world on so little gasoline than an ant could drink it without getting sick.