Kommentare .NET sowie Microsoft Strategie
Felix von Leitner
> für meine Diplomarbeit benötige ich "Kommentare" von Entwicklern zu
> Microsoft .NET
"Scheiße". "Die größte Verlade seit EMM386.EXE".
"Auf so einen Schwachsinn kann auch nur MICROS~1 kommen".
> und eure Einschätzung, welche Strategie Microsoft damit
> wirklich verfolgt.
"Profitmaximierung."
Hint: die Idee bei einer naturwissenschaftlichen Diplomarbeit ist, daß
man sich mit neuen (das schließt Microsoft und .NET aus) Ideen
beschäftigt und selbständig neue Lösungen entwickelt oder feststellt,
daß die neuen Ideen Mist waren. Bei Microsoft braucht man dazu keine
Diplomarbeit.
Im übrigen: man google.
Edzard Egberts
"Francisco Llorens" <f...@nobiscum.de> schrieb im Newsbeitrag
news:a210le$r92$1...@wrath.news.nacamar.de...
> für meine Diplomarbeit
Fachgebiet und Thema?
> benötige ich "Kommentare" von Entwicklern zu
> Microsoft .NET
*g* der Grund, warum ich hier mitlese und an einem Linux-Umstieg
arbeite!
Naja, kurz ein paar Gedanken:
.NET ist an allen Ecken und Enden zusammengeklaut und verwurstet Java
mit XML mit Windows.
Der übliche Trick der Framework-Hersteller:
Man nehme ein grundlegendes System/ Protokoll, etc., baue da eine eigene
Klassenbibliothek herum, die diese Sachen möglichst weitgehend versteckt
und verkaufe das ganze als grossartige Erleichterung und Verbesserung.
Die Leute arbeiten dann nicht mit der zu Grunde liegenden Basis, sondern
mit dem Framework und sind damit vom Hersteller dieses Frameworks
abhängig. Weil in der Klassenbibliothek natürlich neue Fehler sind,
werden dann Updates vom Framework gekauft (die Basis hat meistens keine
Probleme) und der Hersteller freut sich. Die "Arbeitserleichterung" wird
meistens durch diese Fehler aufgezehrt und man arbeitet besser direkt
mit der Basis (also möglichst den direkten API-Schnittstellen/
Protokollen und nicht mit Hüllklassen).
Vor allem kann man jahrelang mit einem solchen Framework arbeiten und
hat trotzdem keine Ahnung, was man eigentlich macht!
Die Aufgabenstellung, für die .NET vorwiegend geplant ist, e-Commerce
und verteilte Anwendungen im Internet, sind in meinen Augen der falsche
Weg:
Ich möchte nicht an allen Ecken und Enden irgendwelche Software
ausgeführt haben, sondern definierte Schnittstellen. Also z.B. CGI statt
Java.
Die Idee, z.B. ein Office-Programm im Internet "mietweise" zu benutzen,
ist hinsichtlich Sicherheit und auch Verfügbarkeit haarsträubend! Mir
fehlt da der Glaube an die Technik...
Der zweite grosse Vorteil von .NET soll die Wiederverwendbarkeit von
Komponenten sein. Das ist aber sowieso nur ein Problem der Windows-Welt,
weil es MS bisher noch nicht geschafft hat, ein wirklich brauchbares
Konzept der Interprozesskommunikation zu entwickeln - ausprobiert haben
die schon genug (z.B. OLE, COM). Die Fernsteuerung und "Vernetzung" von
Programmen ist IMHO (ich lasse mich da gerne korrigieren, weil nicht
wirklich Ahnung) in der Unix-Welt schon immer Grundkonzept gewesen, über
die Umleitung der I/O.
Eine andere Form der "Wiederverwendbarkeit" ist ja auch das
Open-Source-Modell.
Der dritte Vorteil "Plattformunabhängigkeit" ist ... naja: Laut MS soll
.NET auf allen *Windows*-Plattformen laufen, wenn es also fertig ist,
läuft es auf Windows XP und Windows XP. Der Offenlegung der
Schnittstelle und Portierung auf Linux (durch Corel AFAIK) traue ich
erst, wenn es fertig ist (Tschulligung MS, aber wer einmal einen
schlechten Ruf hat...).
Ich habe mich auch schon ein wenig mit den Internas von .NET auseinander
gesetzt (Managed Code, Laufzeitumgebung, Sicherheitskonzepte etc.) und
bin der Meinung, dass es sich um ein *gigantisches* Projekt handelt.
Ich werde für_jeden_einzelnen_ Programmabsturz von Kunden ans Kreuz
genagelt und die Vorstellung auf so einem Riesending aufsetzend eine
zuverlässige Software programmieren zu müssen, ist für mich ein
Albtraum: Eigene Fehler kann ich in den Griff bekommen, MS macht per
Definitionem keine Fehler und garantiert für rein gar nichts (EULA lesen
bildet).
Mir fehlt da etwas das blinde Vertrauen.
Als bekennender C++-Fan ist der Versuch von Microsoft, eine eigene
Programmiersprache C# als verbesserten Nachfolger einzuführen, für mich
eine absolute Unverschämtheit, die mich ziemlich sauer macht.
Wiederverwendbarkeit ist gerade eines der Konzepte von C++, aber MS
möchte eben .NET und eine neue Sprache und den ganzen alten Scheiss
(*Giga*byte an Quellcode) soll man vergessen - die amerikanische
Wegwerfgesellschaft gefällt mir einfach nicht! ;-)
Wenn jemand dumm genug ist, C# zu benutzen, freut sich MS natürlich über
die Kundenbindung...
> und eure Einschätzung, welche Strategie Microsoft damit
> wirklich verfolgt.
Gewinnmaximierung. Geben die ja selber zu.
Die ständigen "Neuerungen" sind reiner Blödsinn und haben nur den Zweck,
dem werbungsverdummten Normalverbraucher wieder etwas verkaufen zu
können (*g* XP in die Entbindungsstationen - alles wird leichter!).
Für Entwickler ist es das reine Grauen - ich persönlich habe einfach
keine Lust mehr, dauernd MS hinterher laufen zu müssen und die
Fortbildungsveranstaltungen/ den Support von denen kann sich eine kleine
Firma wie wir auch nicht leisten.
Ohne diese Sache mit der Linux-Portierung (Rauchvorhang?) wäre mir die
Strategie klar:
Mit .NET und C# wäre die Windows-Welt endgültig zugemauert - keine
Portierbarkeit mehr möglich. Endweder man macht .NET, oder ist
Aussenseiter, der keine richtige Ahnung mehr hat (das riskiere ich
aber).
Eine andere Sache, über die Du einiges finden könntest, sind schlicht
und einfach neue Geschäftsbereiche: Win-XP stellt sich als Verkaufskiosk
für MS-Produkte dar und im e-Commerce mit den entsprechenden
Zertifizierungen (z.B. Passport) wittert MS jede Menge Kohle. Das
schweift jetzt aber etwas ab und geht in die aktuelle Diskussion über
Kopierschutz und digitale Rechteverwertung (ächz - heisst jedenfalls so
ähnlich, ich meine Sachen wie DVD-Formate usw.).
Um an differenziertere und nicht nur grundsätzlich ablehnende
Stellungnahmen zu kommen, solltest Du diese Frage aber noch in
"microsoft.public.de.vc" stellen - da sollte es auch Entwickler geben,
die bereit sind, sich mit .NET anzufreunden.
Mäh,
Ed
Alexander Bartolich
> [...]
> Die Fernsteuerung und "Vernetzung" von Programmen ist IMHO
> (ich lasse mich da gerne korrigieren, weil nicht wirklich
> Ahnung) in der Unix-Welt schon immer Grundkonzept gewesen,
> über die Umleitung der I/O.
> Eine andere Form der "Wiederverwendbarkeit" ist ja auch das
> Open-Source-Modell.
# Let's Make Unix Not Suck
#
# Miguel de Icaza
#
http://primates.ximian.com/~miguel/bongo-bong.html
--
/* Eternal magic of the Elf - for Linux/i386 */
unsigned char main[] = "\x31\xC0\xB0\x04\x31\xDB\x43"
"\xB9\x01\x80\x04\x08\x31\xD2\xB2\x03\xCD\x80\xEB\xEC";
Edzard Egberts
"Alexander Bartolich" <alexander...@vai.at> schrieb im
Newsbeitrag news:3C47DE7A...@vai.at...
> Edzard Egberts wrote:
> > [...]
> > Die Fernsteuerung und "Vernetzung" von Programmen ist IMHO
> > (ich lasse mich da gerne korrigieren, weil nicht wirklich
> > Ahnung) in der Unix-Welt schon immer Grundkonzept gewesen,
> > über die Umleitung der I/O.
> > Eine andere Form der "Wiederverwendbarkeit" ist ja auch das
> > Open-Source-Modell.
>
> # Let's Make Unix Not Suck
> #
> # Miguel de Icaza
> #
> http://primates.ximian.com/~miguel/bongo-bong.html
Ups! "Various people claim " - darauf bin ich wohl hereingefallen! ;-)
Von COM war ich übrigens auch 'mal begeistert - bis .NET kam und COM von
MS sang- und klanglos verworfen wurde. Da hatte ich mich gerade so weit
eingearbeitet, dass ich dachte, ich könnte es 'mal benutzen...
Hast Du schon mit CORBA und Bonobo gearbeitet? Brauchbar?
Ich wollte mich sowieso auf GNOME festlegen - das passt mir eigentlich
gut in den Kram!
Gruß,
Ed
Alexander Bartolich
> [...]
> Hast Du schon mit CORBA und Bonobo gearbeitet?
Nein. Ich bin in einer völlig anderen Branche.
> Brauchbar?
Ich kann dazu nur ein Meta-Kommentar von mir geben:
Kommt drauf an, mit was du es vergleichst.
Zunächst einmal sollte man streng zwischen Inter-Desktop-
Kommunikation und Client/Server-Protokollen unterscheiden.
Wenn du nur einen HTTP-Browser innerhalb deines
Applikations-Fensters brauchst, ist XReparentWindow(3X11)
(und eventuell XSendEvent oder XTestFake*Event) mit Mozilla
(oder was auch immer) performance-mäßig unschlagbar.
Ein HTTP-Proxy in Perl/Python/Tcl bzw. mit libwww in C
ist auch keine Hexerei. Wenn du allerdings richtige
Fernsteuerung oder Interaktion mit dem Browser brauchst,
kommst du um 'höherwertige Logik' nicht herum.
Die Geschichte hat aber gezeigt, dass solche Konzepte
furchtbar schnell veralten. DDE wurde OLE wurde COM
wurde Distributed COM wurde .NET und keine Ende abzusehen.
IMHO wird COM vor allem für Wegwerfprogramme in VB verwendet.
Edzard Egberts wrote:
> Eine andere Form der "Wiederverwendbarkeit" ist ja auch das
> Open-Source-Modell.
Dem kann ich mich nur anschließen. Wegwerfprogramme schreibt
man auf *nix etwa mit Perl/Tk in Kombination mit CPAN.
Die Kommunikation zum Server ist aber eine völlig andere
Geschichte, wo Performance nicht unbedingt eine Rolle spielt.
MS-Access und MS-SourceSafe (Versionsverwaltung) arbeiten
z.b. auf einem Samba-Share mit File-Locking.
.NET soll mit 'XML over HTTP' arbeiten.
Java bietet eine glorifizierte Variante von RPC.
Ich schätze aber, dass der Großteil der Client/Server-Applikation
direkt auf die (relationale) Datenbank geht.
IMHO zählt in diesem Bereich eher Wartbarkeit und
Interoperabilität.
Und das ist auch gleich eine gute Überleitung zu einer
wagemutigen Prognose. Ich gebe nur vier Modellierungskonzepten
eine Zukunft über 2010 hinaus:
ASCII/UNICODE, SQL, HTTP und XML.
Edzard Egberts
"Alexander Bartolich" <alexander...@vai.at> schrieb im
Newsbeitrag news:3C483667...@vai.at...
> Zunächst einmal sollte man streng zwischen Inter-Desktop-
> Kommunikation und Client/Server-Protokollen unterscheiden.
Ich dachte vorwiegend an Inter-Desktop, also z.B. Verwendung von
Tabellenkalkulation oder Textverarbeitung - das GNOME-Spreadsheet wird
AFAIK ja öfters gelobt und es sollte heute auf keinen Fall mehr nötig
sein, dass jemand seine eigene Textverarbeitung programmiert.
Was IPC und Client-Server angeht, halte ich Sockets für eine optimale
Lösung - funktionieren zwischen Prozessen, zwischen Computern und
zwischen unterschiedlichen Systemen.
Naja, geht jetzt etwas am Thema vorbei - IMHO reden wir über eine höhere
Protokollebene...
> Die Geschichte hat aber gezeigt, dass solche Konzepte
> furchtbar schnell veralten. DDE wurde OLE wurde COM
> wurde Distributed COM wurde .NET und keine Ende abzusehen.
Genau und in meinen Augen ist das ein echtes Problem:
"Investitionssicherheit" hätte ich nämlich auch ganz gerne 'mal für
angeeignete Kenntnisse und ich habe so meine Zweifel, dass das wirklich
nötig ist. Ich bin nicht gerade konservativ, aber neben dem Lernen
müsste ich gelegentlich auch arbeiten.
> IMHO wird COM vor allem für Wegwerfprogramme in VB verwendet.
Nein, COM wurde von MS ja 'mal als Stein der Weisen angepriesen - nur
noch COM - und es existiert da ein ganzer Haufen von Objekten, die weit
über "Wegwerfprogramme" hinausgehen. Ich habe jetzt nur endgültig das
Handtuch geworfen, weil gerade als ich damit halbwegs umgehen konnte,
schon wieder etwas Neues kam.
Das ist aber eine emotionale Reaktion (schliesslich wird COM garantiert
noch viele Jahre unterstützt) - ich fühle mich MS ausgeliefert und habe
Angst vor der Möglichkeit, dass Mannjahre an Arbeit einfach von dritter
Seite abgekündigt werden (das ist mir schon mit der OWL passiert).
> ASCII/UNICODE, SQL, HTTP und XML.
Sieh' an - was SQL angeht, bin ich erst kürzlich zur Erkenntnis gelangt,
dass man sich in Sachen Datenbank mit nichts anderem mehr zu
beschäftigen braucht.
Gruß,
Ed
Jochen Schmitt
>"Investitionssicherheit" hätte ich nämlich auch ganz gerne 'mal für
>angeeignete Kenntnisse und ich habe so meine Zweifel, dass das wirklich
>nötig ist. Ich bin nicht gerade konservativ, aber neben dem Lernen
>müsste ich gelegentlich auch arbeiten.
Gerade hierbei bietet .NET gegenüber JAVA Vorteile für
Programmierer, die aus der Microsoft-Welt kommen.
Wenn man von Visual Basic oder Visual C++ auf .NET umsteigt, dann
ist man eben nicht gezwungen, exisitierende COM-Komponenten
wegzuwerden.
.NET bietet standardmäßig die Möglichkeit, für ein COM-Objekt
einen Wrapper zu erzeugen durchden man das COM-Objekt ohne
Schwierigkeiten aus einer beliebigen .NET-Spache aufrufen kann.
Bei JAVA dagegen wird eine solche Unterstützung natürlich nicht
standardmäßig angeboten, da dies der Plattformunabhängigkeit von
JAVA wderspricht.
mfg: Jochen Schmitt
Andreas Krey
>"Edzard Egberts" <TAN...@T-Online.de> wrote:
>
>>"Investitionssicherheit" hätte ich nämlich auch ganz gerne 'mal für
>>angeeignete Kenntnisse und ich habe so meine Zweifel, dass das wirklich
>>nötig ist. Ich bin nicht gerade konservativ, aber neben dem Lernen
>>müsste ich gelegentlich auch arbeiten.
>
>Gerade hierbei bietet .NET gegenüber JAVA Vorteile für
>Programmierer, die aus der Microsoft-Welt kommen.
>
Andreas
--
@(g){g(g)}(@(g){@(v){v>0 ? g(g)(v-1)*v : 1}})(99);
Matthias Bethke
> [Wrapper für COM-Objekte in .NET]
> Bei JAVA dagegen wird eine solche Unterstützung natürlich nicht
> standardmäßig angeboten, da dies der Plattformunabhängigkeit von
> JAVA wderspricht.
Normale systemabhängige Bibliotheken lassen sich natürlich über das
Native Language Interface (?) einbinden. Keine Ahnung, wie gut das mit
C++-Modulen zusammenarbeitet, aber mit C geht das ganz brauchbar.
regards
Matthias
--
PGP used here!
2048/0x90CF8389 / 8E 1F 10 81 A4 66 29 46 B9 8A B9 E2 09 9F 3B 91
Felix von Leitner
> # Let's Make Unix Not Suck
> #
> # Miguel de Icaza
> #
> http://primates.ximian.com/~miguel/bongo-bong.html
Miguel ist ein verirrter Wahnsinniger, der sich mit Unix nicht auskennt.
Man schaue sich nur an, was er für einen fragilen Haufen Müll-Code aus
GNOME gemacht hat. Sein "man muß das dynamisch reinlinken, weil das
performt dann besser als Pipes" ist auf modernen Systemen nicht nur
weitgehend falsch, es ist auch ansonsten bei sauberem Interfacedesign
irrelevant und auf lose gekoppelten Clustern sogar aktive Performance-
Vernichtung.
Miguel sollte wieder Windows programmieren und Linux endlich in Ruhe
lassen. Es ist schon jetzt fraglich, ob der Schaden, den er angerichtet
hat, jemals wieder repariert werden kann. Wie man ja hier sieht,
glauben alle möglichen Leute den Müll, den er so von sich gibt.
Auf der anderen Seite kann man argumentieren, daß er schon jetzt Windows
macht. Er ist ja der Depp, dem wir .NET für Linux und diesen
unerträglichen Outlook-Klon zu verdanken haben :-(
Felix von Leitner
> Gerade hierbei bietet .NET gegenüber JAVA Vorteile für
> Programmierer, die aus der Microsoft-Welt kommen.
Nein.
> Wenn man von Visual Basic oder Visual C++ auf .NET umsteigt, dann
> ist man eben nicht gezwungen, exisitierende COM-Komponenten
> wegzuwerden.
Das muß man in jedem Fall tun, wenn man portabel programmieren will.
> .NET bietet standardmäßig die Möglichkeit, für ein COM-Objekt
> einen Wrapper zu erzeugen durchden man das COM-Objekt ohne
> Schwierigkeiten aus einer beliebigen .NET-Spache aufrufen kann.
Großartig. Und wie rechtfertigen sie diese Performancevernichtung?
Bestimmt ein Buzzword wie "Refactoring", richtig?
Mann, so dämlich kann man doch gar nicht sein, von einem proprietären
Müll auf den nächsten umzusteigen! Befreit euch von diesem Unfug!
> Bei JAVA dagegen wird eine solche Unterstützung natürlich nicht
> standardmäßig angeboten, da dies der Plattformunabhängigkeit von
> JAVA wderspricht.
Ganz klar, ein himmelschreiender Nachteil von Java.
Was hast du eigentlich geraucht?
Alexander Bartolich
> [...]
> Miguel ist ein verirrter Wahnsinniger, der sich mit Unix nicht auskennt.
> Man schaue sich nur an, was er für einen fragilen Haufen Müll-Code aus
> GNOME gemacht hat. Sein "man muß das dynamisch reinlinken, weil das
> performt dann besser als Pipes" ist auf modernen Systemen nicht nur
> weitgehend falsch, es ist auch ansonsten bei sauberem Interfacedesign
> irrelevant und auf lose gekoppelten Clustern sogar aktive Performance-
> Vernichtung.
>
> Miguel sollte wieder Windows programmieren und Linux endlich in Ruhe
> lassen. Es ist schon jetzt fraglich, ob der Schaden, den er angerichtet
> hat, jemals wieder repariert werden kann. Wie man ja hier sieht,
> glauben alle möglichen Leute den Müll, den er so von sich gibt.
>
> Auf der anderen Seite kann man argumentieren, daß er schon jetzt Windows
> macht. Er ist ja der Depp, dem wir .NET für Linux und diesen
> unerträglichen Outlook-Klon zu verdanken haben :-(
--
Rainer Weikusat
> Miguel ist ein verirrter Wahnsinniger, der sich mit Unix nicht auskennt.
"Zur Illustration"
<URL:http://developer.gnome.org/projects/gup/hig/hig-0.1/usabilityprinciples.html>
--
hoffentlich ist es beton
Felix von Leitner
> > Miguel ist ein verirrter Wahnsinniger, der sich mit Unix nicht auskennt.
> "Zur Illustration"
> <URL:http://developer.gnome.org/projects/gup/hig/hig-0.1/usabilityprinciples.html>
Wieso? Das finde ich gar nicht so schlimm. Man muß halt hinnehmen, daß
er GUIs für eine effiziente Arbeitsumgebung hält, dann macht das
durchaus Sinn. Aber sein Geschreibsel, daß die IPC-Mechanismen von Unix
denen von Windows fundamental unterlegen seien, und daß es nicht möglich
wäre, mit Pipes oder Sockets komplexe Programme zu implementieren, oder
daß die Performance von Pipes denen von CORBA hinterherhinken würden,
das ist schon eher warum ich ihn für einen Wahnsinnigen halte.
Soll der mal sein .NET Gelumpe programmieren und dann arbeitslos werden,
wenn Microsoft Passport zumacht, subtil ändert oder Lizenzgebühren für
die Benutzung mit Nicht-Microsoft-Software erhebt.
Rainer Weikusat
[Gnome-Styleguide]
> Wieso? Das finde ich gar nicht so schlimm. Man muß halt hinnehmen, daß
> er GUIs für eine effiziente Arbeitsumgebung hält, dann macht das
> durchaus Sinn.
Your application should always use the user's language, using
words, phrases, and concepts which are familiar to the user
rather than terms from the underlying system. The terms you
use should be related to the user's conception of the tasks
your application supports: for instance, in medicine, the
paper folder which contains all information about a specific
patient is called a "chart." Hence, a medical application
might refer to a patient record which contains the same
information as a paper chart as a "patient chart" rather than
as a "patient database record".
Rationaler Einsatz eines Arbeitsgerätes erfordert, sich mit den
zugrundeliegenden Konzepten vertraut zu machen, das gilt für jede
Maschine. Die Annahme, der Arzt würde 'sein Leben lang' nur mit einer
Datenbank arbeiten, halte ich für unsinnig. Man kann ihn also dadurch
verwirren, das man demselben Ding acht bis neun unterschiedliche Namen
gibt ('patient chart', 'Adreßbucheintrag' etc pp), aber wofür soll das
gut sein, außer das es ein Defizit der realen Welt 'realistischer'
modelliert?
Your application should always keep the user informed of
what's actually going on through appropriate feedback
presented at an appropriate time. The user should never have
to guess about the status of the system or of your
application. When the user performs an action, provide
feedback to indicate that the system has received the input
and is operating on it.
Das klingt nicht wie 'rm -rf', oder?
Remember that computers exist to serve humans. A user should
always feel in control, able to do what they want when they
want. This means that modes should generally be avoided; users
should be able to switch between different tasks (and
specifically, different windows) at any time.
Abzüglich 'we really dislike vi', was soll das heißen?
It is very important, however, to avoid the trap of allowing
too much configuration, or allowing the configuration of
parameters which most users will not understand or find useful
to modify.
Dann sollen sie schlicht die Finger davon lassen. Ein vernünftiges
Interface vorausgesetzt ('reasonable defaults'), dürfte das kein
Problem darstellen.
In some cases when the action might be very dangerous, and
there is no way to undo the result, the interface should warn
the user and force a confirmation.
Hat hier schon mal jemand absichtlich ein Software-RAID unter Linux
über ein bestehendes drüber angelegt? Als Demonstration bzgl 'Sinn und
Unsinn von Benutzerinteraktion' halte ich das für geeignet abschreckend.
Enable Direct Manipulation
Wherever possible, you should allow users to act on objects
and data directly, rather than through dialog boxes or
explicit commands.
Gemeint ist: Falls immer möglich, nötige den Anwender dazu, reale
Bewegungsabläufe zu simulieren, die ihm aufwendig graphisch
vorgegaukelt werden, _anstatt_ ihm 'direct manipulation' seiner Daten
zu ermöglichen. Das Icon ist nicht das Ding.
> Aber sein Geschreibsel, daß die IPC-Mechanismen von Unix
> denen von Windows fundamental unterlegen seien,
Für Programme, die sich wie oben gefordert aufführen, könnte er damit
durchaus recht haben, denn die reden iA eher 'wie Computer' als 'wie
Menschen' miteinander und Encodings zum Serialisieren strukturierter
Binärdaten sind meistens grauenhaft (Beobachtung: 'Im Schnitt'
verbraucht eine Bridge mehr Zeit damit, ein Datenpaket mit dreißig
Parametern in ASN.1 zu übersetzen, als sie benötigt, um dreißig
einzelne Anfragen zu beantworten. Da klemmt etwas grundsätzliches,
aber nicht 'an den IPC-Mechanismen').
> Soll der mal sein .NET Gelumpe programmieren
IIRC war der 'offizielle Grund', daß GNOME ein furchtbares Chaos
darstellt, über das allmählich der Überblick verloren geht. Inwiefern
hier 'noch mehr disparate Einzelteile' zur Vereinheitlichung beitragen
können sollten, bleibt das übliche Geheimnis professioneller
Softwareentwicklung :->.
Felix von Leitner
> neun unterschiedliche Namen gibt ('patient chart', 'Adreßbucheintrag'
> etc pp), aber wofür soll das gut sein, außer das es ein Defizit der
> realen Welt 'realistischer' modelliert?
Es ging um GUIs. Die werden von Deppen benutzt.
Also sagt er, man soll sich auch in der Terminologie danach richten, daß
das Deppen sind. Macht schon Sinn in meinen Augen.
> Das klingt nicht wie 'rm -rf', oder?
rm -rfv
> Abzüglich 'we really dislike vi', was soll das heißen?
"keine modalen Dialoge bitte!"
> Für Programme, die sich wie oben gefordert aufführen, könnte er damit
> durchaus recht haben, denn die reden iA eher 'wie Computer' als 'wie
> Menschen' miteinander und Encodings zum Serialisieren strukturierter
> Binärdaten sind meistens grauenhaft (Beobachtung: 'Im Schnitt'
> verbraucht eine Bridge mehr Zeit damit, ein Datenpaket mit dreißig
> Parametern in ASN.1 zu übersetzen, als sie benötigt, um dreißig
> einzelne Anfragen zu beantworten. Da klemmt etwas grundsätzliches,
> aber nicht 'an den IPC-Mechanismen').
Das liegt einfach nur daran, daß ASN.1 so schlecht ist. Wenn man mit
minimaler Byte-Anzahl kodieren möchte, dann kann man komplexe ASN.1
Strukturen nicht einfach linear runterschreiben, weil die Länge der
Längenfelder variabel ist und geschachtelte Längenangaben nötig sind.
Bei LDAP z.B. schreibt man an einer Stelle eine dreifach geschachtelte
SEQUENCE mit einem SET OF. Die Länge des Sequence-Headers ist nicht
bekannt, bis man den SET OF komplett kodiert hat. Der enthält Strings,
die auch noch mal Längenangaben haben, deren Länge von der Länge des
Strings abhängen. D.h. man encoded erst alle Strings, dann den SET OF
drumherum, dann kopiert man die encodeten Strings hinter den SET OF
Header, das macht man für alle SET OFs, dann schreibt man einen SEQUENCE
Header davor, da man ja jetzt weiß, wie viele Bytes für die SET OFs
draufgehen, und dann kommt noch der LDAPMessage Envelope mit noch nem
SEQUENCE Header. Man ist also für das Encoden einer an sich trivialen
Nachricht wie ein Bekloppter am Rumkopieren oder mehrfach
Datenstrukturen traversieren. Oder State akkumulieren. D.h. man kann
es nicht sauber und klein implementieren. ASN.1 stinkt halt.
Felix
Andreas Krey
>
>Das liegt einfach nur daran, daß ASN.1 so schlecht ist. Wenn man mit
>SEQUENCE Header. Man ist also für das Encoden einer an sich trivialen
>Nachricht wie ein Bekloppter am Rumkopieren oder mehrfach
>Datenstrukturen traversieren. Oder State akkumulieren. D.h. man kann
>es nicht sauber und klein implementieren. ASN.1 stinkt halt.
>
von hinten nach vorne auf?
Rainer Weikusat
> > Man kann ihn also dadurch verwirren, das man demselben Ding acht bis
> > neun unterschiedliche Namen gibt ('patient chart', 'Adreßbucheintrag'
> > etc pp), aber wofür soll das gut sein, außer das es ein Defizit der
> > realen Welt 'realistischer' modelliert?
>
> Es ging um GUIs. Die werden von Deppen benutzt.
Ein Arzt hätte nicht unbedingt die Wahl.
Felix von Leitner
> Ein Arzt hätte nicht unbedingt die Wahl.
Der ist in seinem Fach ein Experte, aber im Umgang mit Computern
gewöhnlich ein Depp.
armin
Bernd Petrovitsch
>test
Not passed. Good bye.
Bernd
--
Bernd Petrovitsch Email : be...@gams.at
g.a.m.s gmbh Fax : +43 1 205255-900
Prinz-Eugen-Straße 8 A-1040 Vienna/Austria/Europe
LUGA : http://www.luga.at
Immo 'FaUl' Wehrenberg
> From: armin <brezel[_insert_the_@_here_]chello.at>
[...]
> test
*Plonk*, fup2p
FaUl
end
This article does not support incompatible and broken newsreader.
--
Und ausserdem: Das Ende ist Nahe! und wie schon gesagt und hier
zum letztenmal: "Widerstand ist zwecklos, das Monopol hat gewonnen."
in diesem Sinne ein schönes Leben noch.
[KJ in einer Privaten E-Mail]