Donnerstag, 30. August 2001 link
nun doch eine .NET replik, im speziellen auf henso (hier, hier), da hier wenigstens fundierte diskussion gefuehrt wird (was ich anderswo manchmal vermisse).
in erster linie sind .NET und im speziellen WinForms die evolution der klassischen windows programmierung - auch wenn microsoft's marketing das natuerlich nie so darstellen wuerde und auch gar nicht hoeren moechte. win32 wird abseits von Java und visual basic wieder wirklich GUI-programmierbar - visual c++ und die MFC sind ja leider sehr muehsam (geworden).
es ist bei weitem nicht microsofts erster versuch eine GUI lib zu entwickeln, allerdings nach der MFC und diversen WinCE ausritten der zweite ernstzunehmende. die microsoft research arbeitet aber dem vernehmen nach schon seit geraumer weile sehr intensiv an studien und projekten zur effizienten GUI programmierung. ob WinForms dann ein zufriedenstellendes ergebnis ist, sei dahingestellt.
C# aehnelt Java in weiten strecken wirklich sehr stark, durch hinzunahme von ein paar kleineren konzepten ('properties', '99% oo', foreach, ...) programmiert es sich teilweise ein wenig angenehmer und auch die .NET libs sind sehr schoen konzipiert und gut abgestimmt. auch das ganze assemblies zeug (packaging und distribution) ist sehr durchdacht und eigentlich angenehm.
summa summarum ergibt sich in .NET ein wuerdiger, sehr ausgereifter nachfolger zu COM, der MFC und WinInet. natuerlich schwebt dann noch sehr viel andere technologie mit (ASP.NET, ADO.NET, CLR/CLI spaesse, ....) - die will und vor allem kann ich aber (noch) nicht auf relevanz und sinnhaftigkeit beurteilen. eines ist jedoch aber klar, wenn .NET die nachfolge von COM antritt und multi-language programming wirklich gut funktioniert, dann ergeben sich dadurch schon angenehme moeglichkeiten - wie und wie gut das wirklich funktionieren wird, wird sich wohl erst nach releases tatsaechlich beurteilen lassen.
Mono kann man wirklich nur viel glueck wuenschen, wie henso treffend bemerkt, gehen VM-implementationen immer mit viel aufwand einher. doch nicht nur im technischen braucht Mono glueck, auch im rechtlichen sei es ihnen sehr vergoennt - mit ein wenig glueck gelingt es vielleicht doch, einen offenen standard zu etablieren.
rainman tsr 8484 days ago:
hast du irgendwelche news ueber compact .NET gehoert?
floritz 8484 days ago:
.NET ist sicher eine sehr mächtige Umgebung. Problem ist nur, wie bei Microsoftschen Entwicklungen, dass wieder ewig viele Librarys mitgeschleppt werden.
Es ist eigentlich schockierend wieviel ein "Hello World" benötigt.
chris 8484 days ago:
hello.exe: 3.072 Bytes - schockierend? mit sicherheit ;-)
earl 8484 days ago:
ist immer alles so relativ ;)
extensible.exe: 57.344 Bytes
(ich verschweige jetzt aber ganz geflissentlich wieviel extensible zu runtime frisst ;)
diese riesigen libs haben halt eine hohe "entrance barrier" ;) auch "hello world" verlaesst sich zb auf streaming I/O etc. - das hat halt so seinen preis ;)
hns2 8483 days ago:
Schon lustig wie unterschiedliche Gefühle mit grossen Libraries verbunden sind. Für den Programmierer sind die grossen, standardisierten Libs ja etwas schönes an .NET - denn eine Sprache ohne Standardlibraries ist de facto vollkommen unportabel, und grosse zusammenhängende Class Libs neigen in letzter Zeit mehr und mehr dazu, gut designt zu sein. Vor allem aber macht es einen grossen Unterschied, ob man auf der Server- oder der Clientseite arbeitet. Hier wo ich bin auf der Serverside ist es nämlich fast vollkommen wurscht, ob man erst mal 40 Megs runterladen muss, damit Hallo Welt läuft. Und wenn es zur Laufzeit viel Speicher frisst ist das auch nicht das Ende. Aber ja, das Aufmischen der Grenze zwischen Server und Client ist natürlich auch ein interessantes Phänomen der letzten Jahre...
Übrigens würde ich aus der Entfernung auch sagen, dass die .NET-Class Library in manchen Details besser designt ist als die von Java. Wäre auch blöd wenn Microsoft nicht aus den Fehlern der anderen lernen würde (Sun hat bei Java ja auch aus den Fehlern von Microsoft gelernt).
earl 8483 days ago:
ganz lustige beobachtungen. bei vanilla zb ist es auch auf serverside absolut kritisch, wie lang und wieviel geladen wird - einer der desastroesesten side-effects klassischer cgi programmierung ;)
client seitig in bezug auf .NET ist der ladevorgang ein wenig ambivalent. nachdem .NET vorraussichtlich irgendwann in eines der microsoft os' integriert wird, spielen sich dann dort ladezeitlich ganz interessante dinge ab.
assemblies (erweiterte shared libraries) bieten volle versionierung (endlich!) und werden beim ersten mal laden in einen assembly cache gestellt (wie genau der funktioniert ist noch ein wenig unterdokumentiert). damit ergeben sich dann die klassischen vorteile von dll-sharing allerdings ohne die dll-hell.
assemblies werden JIT-compiled gecached, dh auch hier faellt einiges an aufwand weg, irgendwann wird alles ziemlich schnell. also auch client seitig ist microsoft sehr bemueht die klassischen VM probleme zu umschiffen.
lernen ist ja auch was gutes ;) vielleicht schaut sich ja sun fuer zukuenftige java releases ein paar design-dinge ab.
Please log in (you may want to register first) to post comments!
search
40 active users
- unknown (40)
backlinks (more)
none, yet
recent stores (more)
recent comments
echo earlZstrainYat|tr ZY @.
