Hallo, ich arbeite u.a. als Entwickler. Sehr oft erlebe ich, dass deutsche Entwicklerkollegen m.M. nach viel zu komplex einfachste Sachverhalte lösen. Beispiel : es geht in einer ERP Anwendung um einfachste Benutzerabfragen und Eingabevalidierungen. Sowas löse ich meist in einer Softwareschicht und gut ist. Meine deutschen Entwicklerkollegen führen für sowas mind. 3 bis 5 Schichten ein, programmieren 100 Klassen so das kein Mensch mehr durch blickt und sagen dann das sei "sauberes Coding" während ich solche Trivialitäten mit ein paar Methoden abhandle. Es ist auch so, ich bin Dipl.-Mathematiker und viele meiner Kollegen sind nur Fachinformatiker teils sogar ohne Abi / Fachabi. Aus meiner Sicht sind das die totalen Bürokraten. Da wird ein popeliges Entwicklungsprojekt aufgezogen als würde man ein neues Betriebssystem entwickeln und wehe man geht mal einen weniger bürokratischen Weg dann ist man gleich ein "Frickler" oder sonst was. Auch wenn ich mal eine geschickte, intelligente Lösung z.B. per Rekursion aufzeige, dann meinen die, sowas verstehe doch kein Mensch, dass sei doch blosses Gefrickel. Sollte ich vllt den Job wechseln ? intellektuell zu öde ist mir das sowieso schon zu lange. Ich denke da halt eher amerikanisch. Wenn mein Kunde z.B. eine Hundehütte haben will, kriegt er eine Hundehütte. Wenn diese nicht mehr den Anforderungen entspricht, wird diese halt abgerissen und eine neue gebaut. Meine Deutschen Kollegen denken selbst bei einer softwaretechnischen Hundehütte so : man muss die so bauen, dass die 200 Jahre hält und auch noch an die Anforderungen die ein Hund in 200 Jahren hat, einfach und günstig erweiterbar ist. Geht das nur mir so ? oder ist das generell der deutsche Entwicklungsstil ?
:
Verschoben durch User
Carl schrieb: > Ich denke da halt eher amerikanisch. Wenn mein Kunde z.B. eine > Hundehütte haben will, kriegt er eine Hundehütte. Wenn diese nicht mehr > den Anforderungen entspricht, wird diese halt abgerissen und eine neue > gebaut. Diese Denke fuehrt dann dazu, dass auch in Gebieten, in denen jedes Jahr Tornados vorkommen, Hundehuetten fuer Menschen vorherrschen. Die Bilder sieht man dann immer in den Nachrichten, versehen mit dem Kommentar "ach wie schrecklich". In D wuerden dort eben keine Hundehuetten gebaut. Geh besser nach Amerika. fonsana
Nein, das ist kein getrolle. Ich kenne das auch aus dem Technischen Zeichnen. Am Beispiel der Bemaßung kann man das ersehen. In deutschen Zeichnungen ist alles genau definiert. Ich war auch erst erschrocken, wie leger die Bemaßung im amerikanischen ist. Das sieht man, wenn man mal im CAD von deutsch auf amerikanisch umschaltet. Bei Schaltplänen sieht das ähnlich aus.
Als Mathematiker solltest du auch nicht das machen welches die Programmierer machen. Mach was Anderes. Mach was, was die Programmierer nicht koennen. Als vor 15 Jahren jeder Klempner an einer Datenbank rumkloppte hab ich beschlossen, dass ich keine Datenbanken anfasse. Es gibt immer noch hinreichend viel, dass geschrieben werden muss.
Ein Programmierer ist kein Informatiker. Das kann schon sein, dass deine Kollegen zu weit über den Tellerrand schauen und nie einen 2ten Teller ereichen. Wenn man Leute hat die einen Weitblick haben sowie die Details nicht außeracht lässt, kann man dadurch durch aus Zeit und Geld sparen in einem weiteren Projekt. Jetzt mal in deinen Worten: Wenn ein Kunde nur eine Hundehütte möchte und auch nicht mehr zahlt, kann es trotzdem zum Vorteil sein, ein einstöckiges Flachdachhaus zu entwickeln, auf das man einfach mehrer Stockwerke darauf setzen kann. Natürlich muss man auch das Potenzial in dem Projekt sehen, sonst macht die Sache natürlich überhaupt keinen Sinn dann. Ich weiß auch nicht, ob bei euch Software geplant wird, oder es nur heißt mach mal. Weil was ich persönlich garnicht leiden kann, wenn es jeder irgendwie macht und man nie einen roten Faden finden kann, obwohl man schon die Lupe auspackt. Jeder hat seinen Stil das ist klar, aber es sollten schon alle den relativ kurzen Wege verwenden der zum Ziel führt. Solang man die Funktion mit einen Aussage kräftigen Kommentar verseht, sollte doch jeder Informatiker erkennen was an dieser Stelle gemacht wird. Gute Nacht, Matthias
@Fuenf Tassen >Als Mathematiker solltest du auch nicht das machen welches die >Programmierer machen. Mach was Anderes. Mach was, was die Programmierer >nicht koennen. Uii! Gut, dass Du kein Germanist bist... @Carl >Meine deutschen Entwicklerkollegen führen für sowas mind. 3 bis 5 >Schichten ein, programmieren 100 Klassen so das kein Mensch mehr durch >blickt und sagen dann das sei "sauberes Coding" während ich solche... Ok, sauber Trennen zeugt schon von einem vernünftigen Stil. @Carl >Ich denke da halt eher amerikanisch. Wenn mein Kunde z.B. eine... Nein, Du denkst nicht amerikanisch sondern pragmatisch. @Carl >Geht das nur mir so ? oder ist das generell der deutsche >Entwicklungsstil ? Würde ich so nicht generalisieren. Vielleicht versuchen Deine Kollegen den nicht vorhandenen akademischen Abschluss durch formale Prozesse wettzumachen. Da schiessen die dann häufig weit über das Ziel hinaus.. Rosa
Wie sieht es denn mit der Wartung der Software aus? Versteht jemand, der keine Ahnung von Deiner Software hat Deine genialen Ideen? Wie ist das mit der Software Deiner Kollegen? Software ist nicht nur, wenn am Ende das Programm läuft.
Oj je wenn alle amerikanische Ingenieure so wäre wie du dann wäre es klar warum USA inzwischen der größte Importeur und Deutschland vielfacher Exportweltmeister ist. Aber zum Glück gibt es durchaus noch viele amerikanische Kollegen die wissen was Qualität ist.
Carl schrieb: >ich solche Trivialitäten > ich bin Dipl.-Mathematiker und viele > meiner Kollegen sind nur Fachinformatiker teils sogar > ohne Abi / > Fachabi. > popeliges Entwicklungsprojekt > ich mal eine geschickte, intelligente Lösung Mit Bürokratie hat das wenig zu tun, es ist Dein persönliches Problem. Wenn Du Mathematiker bist, solltest Du Dich in der Tat fragen, ob Trivialitäten lösen in einem Team, wo viele der Kollegen nur angelernt, ja sogar ohne Abitur sind, das richtige Arbeitsumfeld ist. So wie ein Bauingenieur keine Hundehütten gemeinsam mit Schreinern, teils sogar ohne Abitur, zusammenschrauben sollte. Dieser Tage waren interessante Artikel in den Medien über Alan Turing und seine Arbeit im Bletchley Park. Da würde ich eigentlich einen Mathematiker sehen und nicht beim Codebasteln.
Carl schrieb: > Es ist auch so, ich bin > Dipl.-Mathematiker und viele meiner Kollegen sind nur Fachinformatiker > teils sogar ohne Abi / Fachabi. Sag mal, hast du Minderwertigkeitskomplexe weil du dich "nur" mit Mathe auskennst? Hältst du deshalb generell Menschen ohne Abi für Vollidioten? Solche Aussagen kotzen mich regelmäßig an, sie zeugen nur von Arroganz und sozialer Inkompetenz. Viele der „ungebildeten“ Fachinformatiker haben schon programmiert, da hast Du wahrscheinlich noch am Schnuller genuckelt.
Im allgemeinen schon, ich habe hier nicht eine Gruppe Menschen abwertend beurteilt. Die Kritik ging nur an den TO nicht an dich. Entschuldig bitte, dass ich hier meine Meinung kund getan habe und diese nicht mit deiner übereinstimmt. Übrigens der Herr Burgerauskenner, was haben Burger mit dem Thread hier zu tun?
Carl schrieb: > Meine Deutschen Kollegen denken selbst bei einer softwaretechnischen > Hundehütte so : man muss die so bauen, dass die 200 Jahre hält und auch > noch an die Anforderungen die ein Hund in 200 Jahren hat, einfach und > günstig erweiterbar ist. Ja, das hört sich doch gut an. Von Software hast du als Mathematiker noch nicht so die große Ahnung, oder?
Michael H. schrieb: > Solche Aussagen kotzen mich regelmäßig an, sie zeugen nur > von Arroganz und sozialer Inkompetenz. Sie zeugen davon, daß dem jeweiligen Menschen die Anerkennung fehlt, geht in Richtung Profilneurose. Sowas ist nicht selten, vielleicht gibt es sogar Menschen an der Ladenkasse, die darauf bestehen, von den Kollegen mit Doktortitel angesprochen zu werden. Der Autor hat das Problem, daß er es mit seinem Studium noch nicht zu etwas adäquatem gebracht hat.
Michael_ schrieb: > Ich kenne das auch aus dem Technischen Zeichnen. Das kann ich allerdings (leider) bestätigen. ISO ist da ein Fremdwort. Maße werden irgendwo angetragen, den Rest kann man raten. Eine Seitenansicht von links steht auch schon mal links neben der Vorderansicht, man wird das schon erkennen, wie das gemeint ist. ;-) Dinge, die wir seinerzeit noch in der 7. Klasse gelernt haben, wissen dort offenbar selbst Ingenieure nicht ...
Karli schrieb: > Profilneurose Also eigentlich können nur Inder effektiv programmieren. Liegt am Preis. Mathematiker - und noch schlimmer, Physiker - sind mit Bits und Bytes völlig überfordert. Elektrotechniker schaffen es gerade so, vielleicht eine GUI zusammenzuklicken. Danach tut ihnen der Finger weh. Informatiker könnten programmieren, wenn sie nicht besseres zu tun hätten. Wirtschaftsinformatiker können nicht programmieren, haben aber auch nichts besseres zu tun. Achja, und Medieninformatiker gucken den ganzen Tag Fernsehen.
So, so, von ein paar Erfahrungen mit Kollegen (wenn sie denn überhaupt stimmen), wird direkt mal auf das ganze deutsche Volk geschlossen. Ein Mathematiker sollte schon etwas mehr von Stichproben und Statistik verstehen.
Es ist halt einfach im Trend, etwas so kompliziert und verworren zu entwickeln, dass niemand da durchblickt. Ein Programm mit 1000 Knöpfen "muss" ja z.B. auch zwangsläufig besser sein als eins mit 2, 3 Buttons. Es kommt schon stark darauf an wo du arbeitest. Arbeitest du in der Raumfahrt, ist es wohl besser, wenn die Programmierer so denken wie von dir beschrieben. Arbeitest du in einem Firma für elektrische Dosenöffner geht wohl durchaus mal die "Frickel"-Lösung. Sowieso wird unter Ing. und Entwicklern im Allgemeinen alles gleich als "Bastel" abgetan, was nicht von einem selbst stammt. Der einzige der weiss wie's geht ist jeder für sich selbst :P Gruss Gordon
Also ich liebe basteln. Programmieren tue ich im Hex-Editor.
Jörg Wunsch schrieb: > Eine Seitenansicht von links steht auch schon mal links > neben der Vorderansicht, man wird das schon erkennen, wie das > gemeint ist. ;-) Das lernt man in der ersten Stunde, dass es verschiedene drei Tafelprojektionen gibt. Bei den Amis gilt eine andere Norm, steht auch immer auf dem Plan, wenn man es richtig gemacht hat. Auf deutschen Vordrucken steht das unten im Textfeld welche Norm zur ansicht gilt. > Dinge, die wir seinerzeit noch in der 7. Klasse gelernt haben, > wissen dort offenbar selbst Ingenieure nicht ... Hättest du aufgepasst wüsste du das.
> m.M. nach viel zu komplex einfachste Sachverhalte lösen.
Wer Informatik studiert hat, weiß, daß ein Programm dann gut ist,
wenn es möglichst effizient das Problem löst, das heisst mit
möglichst wenig abzuarbeitenden Befehlen bzw. möglichst wenig
Platzverbrauch.
Erst wenn an einem Programm nichts mehr weggelassen werden kann
ohne daß es seine Funktion nicht mehr erfüllt, dann ist es gut
programmiert.
Die meisten Programmierer haben diese Grundsätze aus dem Studium
vergessen oder als Seiteneinsteiger nie gerlernt, und geben sich
alle erdenkliche Mühe Ausreden zu erfinden, warum ihr Programm
angeblich trotzdem gut ist, gerne benutze Schlagworte:
"erweiterungsfreundlich", "gut wartbar", "zukunftsorientiert"
natürlich alles gelogen, denn das optimale Programm (siehe oben)
wäre darin am besten.
MaWin schrieb: > Die meisten Programmierer haben diese Grundsätze aus dem Studium > vergessen oder als Seiteneinsteiger nie gerlernt, und geben sich > alle erdenkliche Mühe Ausreden zu erfinden, warum ihr Programm > angeblich trotzdem gut ist, gerne benutze Schlagworte: > "erweiterungsfreundlich", "gut wartbar", "zukunftsorientiert" > natürlich alles gelogen, denn das optimale Programm (siehe oben) > wäre darin am besten. Das ist natürlich nur eine Sichtweise. "Unter einem Optimum [...] versteht man das best erreichbare Resultat im Sinne eines Kompromisses zwischen verschiedenen Parametern oder Eigenschaften unter dem Aspekt einer Anwendung, einer Nutzung oder eines Ziele" http://de.wikipedia.org/wiki/Optimum Ein Optimum ist also ein Kompromiss, die Abwägung zwischen der Erreichbarkeit von Zielen. Dabei kann die Wartbarkeit durchaus höher angesiedelt sein.
gordon51freeman schrieb: > Es ist halt einfach im Trend, etwas so kompliziert und verworren zu > entwickeln, dass niemand da durchblickt. Ein Programm mit 1000 Knöpfen > "muss" ja z.B. auch zwangsläufig besser sein als eins mit 2, 3 Buttons. Die Genialität einer Konstruktion liegt in ihrer Einfachheit - Kompliziert bauen kann jeder. Koroljow (Raketenkonstrukteur)
MaWin schrieb: > Erst wenn an einem Programm nichts mehr weggelassen werden kann > ohne daß es seine Funktion nicht mehr erfüllt, dann ist es gut > programmiert. Insbesondere sollte man alle Überprüfungen auf sinnvolle Eingaben weglassen, da die sowieso nur das Programm unnötigt aufblähen und nichts zur verlangten Funktion beitragen. ;-) Apropos Simplizität: Was ist komplexer: Ein Programm mit vielen Zeilen, das auf dem Win32-API aufsetzt, oder ein Programm mit deutlich weniger Zeilen, das auf DotNet 4 aufsetzt?
MaWin schrieb: > "erweiterungsfreundlich" Das kommt drauf an. Es soll Programme geben, die nicht erweitert werden müssen/sollen. MaWin schrieb: > "gut wartbar" Hier gehts auch um Dinge wie Dokumentation und Kommentare, also nicht nur um das Ergebnis des Compilers. Meine Meinung: Echte Programmierer brauchen keine Doku. MaWin schrieb: > "zukunftsorientiert" Das ist wirklich Schwachsinn. Wann ist ein Programm zukunftsorientiert? Wenn es in 64 Bit geschrieben wurde?
MaWin schrieb: "Wer Informatik studiert hat, weiß, daß ein Programm dann gut ist, wenn es möglichst effizient das Problem löst, das heisst mit möglichst wenig abzuarbeitenden Befehlen bzw. möglichst wenig Platzverbrauch. Erst wenn an einem Programm nichts mehr weggelassen werden kann ohne daß es seine Funktion nicht mehr erfüllt, dann ist es gut programmiert." Und wenn der Kunde dann mit dem ersten Erweiterungswunsch kommt (und er WIRD kommen!), dann verstehst Du Dein eigenes Programm nicht mehr und schreibst alles neu? Ich hab das irgendwie anders in Erinnerung mit dem "guten Programm": Es muß zumindest so strukturiert und kommentiert sein, daß es ein anderer Programmierer in die Hand nehmen und ändern / erweitern kann. Ist es das nicht, ist es allenfalls für den privaten Gebrauch gut, aber hat im professionellen Umfeld, in dem ganz selten nur ein einzelner Programmierer am Code werkelt, nichts verloren. Es darf auch durchaus geniale Ansätze geben, aber sie müssen nachvollziehbar bleiben. Und wenn man gelegentlich Teile eines Programms in einem anderen wiederverwenden kann, schadet das auch nichts. Die Zeiten, in denen einzig effektiver, schneller und platzsparender Code zählte, sind glücklicherweise lange vorbei.
Alter Sack schrieb: > Die Zeiten, in denen einzig effektiver, schneller und platzsparender Code > zählte, sind glücklicherweise lange vorbei. Ich lebe gerne weiter in dieser Zeit, du alter Sack.
Alter Sack schrieb: > Ich hab das irgendwie anders in Erinnerung mit dem "guten Programm": Es > muß zumindest so strukturiert und kommentiert sein, daß es ein anderer > Programmierer in die Hand nehmen und ändern / erweitern kann. Ist es das > nicht, ist es allenfalls für den privaten Gebrauch gut, aber hat im > professionellen Umfeld, in dem ganz selten nur ein einzelner > Programmierer am Code werkelt, nichts verloren. Die meisten Kommentare sind total überflüssig und führen nur dazu, dass du zwei Sprachen (die Programmiersprache und die Sprache der Kommentare) lesen und verstehen musst.
Carl schrieb: > Meine Deutschen Kollegen denken selbst bei einer softwaretechnischen > > Hundehütte so : man muss die so bauen, dass die 200 Jahre hält und auch > > noch an die Anforderungen die ein Hund in 200 Jahren hat, einfach und > > günstig erweiterbar ist. gut formuliert! Die Freunde der Klassenbibliotheken legen natürlich noch gleich bewegliche Dächer an, eine Autobewässerung und vieles mehr, das dann wieder deaktiviert wird. will sagen: Es wird sehr viel Universalität eingebaut, die dann wieder eingeschränkt wird.
> Ein Optimum ist also ein Kompromiss Na Blubb, du gehörst zu den Programmieren, die die grösste Ansterngung in die Verargumentierung ihres abgelieferten Schrotts stecken ? Das Optimum beim Programmieren ist der Kompromiss zwischen PLatzbedarf und Geschwindigkeit, dafür gibt es sogar ein Fachwort welches du kennen müsstest wenn du gelernt hättest wovon du hier rum-blubbst "space vs. speed tradeoff", NICHT zwischen "ich habe keine Lust in der verbleibenden Zeit mein Programm zu überarbeiten und denke mit lieber Pseudoargumente mit denen ich meine Auftraggeber beschwichtige". > Insbesondere sollte man alle Überprüfungen auf sinnvolle Eingaben > weglassen, Ach A. K., du hättest deine Eingabe hier ins Forum lieber selbst mal überprüfen sollen, aber das hast du bei dir wohl schon wegrationalisuiert: Eingabeprüfungen gehören im Allgemeinen zu "seiner Funktion" des Programms (es sei denn sie gehören wirkilch nicht zur Aufgabe). > Was ist komplexer Die Betrachtung geht in die Gesamtanzahl der Instruktionen die ausgeführt werden, inklusive derer aus dem Betribssystem, also wäre DotNET die falsche Wahl, selbst wenn das verbleibend zu Implementierende dabei weniger Arbeitsaufwand gewesen wäre. Um ein paar Prozent muß man sich keine Sorgen machen, schliesslich werden auch Betriebssystem im Laufe der Lebenszeit des Programm modifiziert und optimiert, aber wenn das Problem auf dem nativen Windows API lösbar gewesen wäre (also z.B. keine Portierbarkeit zu Mono in der Aufgabenstellung gefordert war), dann wäre die Wahl von DotNET nicht optimal und nur durch Faulheit zu begründen.
blubb schrieb: > Die meisten Kommentare sind total überflüssig und führen nur dazu, dass > > du zwei Sprachen (die Programmiersprache und die Sprache der Kommentare) > > lesen und verstehen musst. Da hast du aber was nicht verstanden! Die Kommentare sollen nicht den Programmiertext erklären sondern die Funktion! - also, warum dort etwas gemacht wird. Das "wie" ist ja durch den Code selbst erklärt! Beispiel: A=A+1; # Nächstes Flächenelement fokussieren C(A) = Q(A)/U(A) # Kapazitätsbelag schätzen T=T+DT; # Nächste Zeitebene für dieses Flächenelement fokussieen T1=T+DT*DT; # Vorherige Zeitebene aus differential schätzen Fuction(&DT,T,T1); # Differential auf Vorwärtsschätzungskorrektur Nur so kriegt jemand mit, was da warum passiert. Es kann 1000 Gründe habe, warum irgendwo im Code irgendwas gerechnet wird. Die Vorstellung, man könne sich das alles erdenken, ist irrig, denn es kostet zuviel Zeit, birgt Fehler und man erkennt nicht die Dinge, die gezielt weggelassen wurden, weil sie nicht nötig waren, bei Änderungen aber wieder nötig werden könnten.
Ich denke ein Programm ist dann gut, wenn der Kunde bereit ist dafür mehr zu zahlen, als die Erstellung gekostet hat und mögliche zukünftige Beanstandungen kosten können.
MaWin schrieb: > Das Optimum beim Programmieren ist der Kompromiss zwischen > PLatzbedarf und Geschwindigkeit, dafür gibt es sogar ein > Fachwort welches du kennen müsstest wenn du gelernt hättest > wovon du hier rum-blubbst "space vs. speed tradeoff", Das ist natürlich ein Aspekt. Aber nur weil es dafür eine Bezeichnung gibt, ist es nicht der einzige.
Dodi schrieb: > Da hast du aber was nicht verstanden! Die Kommentare sollen nicht den > Programmiertext erklären sondern die Funktion! - also, warum dort etwas > gemacht wird. Das "wie" ist ja durch den Code selbst erklärt! Ich glaube du hast da was nicht verstanden!
Ich sehe das so: Angenommen, der Kunde will eine Hundehütte für seinen Hund. Deiner Meinung nach soll er also genau das bekommen - eine Hundehütte für seinen Hund. Nun - man könnte ihm nun eine Hundehütte verkaufen, die nur für genau einen Hund (nämlich für seinen) geeignet ist und die nur auf einem Grundstück (nämlich auf seinem) steht. Der Hundebsitzer ist zufrieden - und du bekommst dein Geld. Der Hundebesitzer wird aber garantiert wieder kommen - spätestens wenn sien Hund stirbt und er nen neuen kauft, oder wenn er umziehtund die Hundehütte mitnehmen will. Wenn dein Vorschlag nun "Hundehütte abreißen und eine komplett neue bauen" ist, kannst du davon ausgehen, dass du den Folgeauftrag nicht mehr bekommst. Es wird dann eine neue Firma gesucht, die die Hundehütte so umbaut, dass auch der neue Hund rein kann. Alleine die Kosten für Softwarewartung liegt - laut Wiki ;) - zwischen 10 und 30 Prozent. Es kann also durchaus wirtschaftlicher sein, ein Programm zu entwickeln, dass von vornehrein "aufgeblasen" wirkt, aber bereits so strukturiert ist, dass es leichter angepasst oder erweitert werden kann. Das lernt man so nicht unbedingt in den Vorlesungen (da kommt es wirklich eher darauf an, dass das Programm genau seinen Zweck erfüllt) - aber im Arbeitsalltag merkt man, wie teuer es ist, Programme nachträglich zu ändern, die zwar ihre Aufgabe nach wie vor fehlerfrei erfüllen, aber nun trotzdem ausgetauscht/erweitert werden müssen.
> A=A+1; # Nächstes Flächenelement fokussieren > C(A) = Q(A)/U(A) # Kapazitätsbelag schätzen ... Super Beispiele für nutzlose Kommentare.
Ein effizientes Programm darf auch ruhig möglichst kurz sein, sodass man es noch überblicken kann. Namen prägnant, aber nicht so, dass man sich "einen abtippt". Ein Programm kann man auch erweitern, ohne 10 zwischenlagen eingebaut zu haben. Oftmals ist es sogar nötig Teile neu zu schreiben, weil sich die KundenAnforderungen oder (Hard/Software) Schnittstellen geändert haben. Dann ist es gut, wenn das Programm so faktorisiert wurde, dass sich einzelne Teile leicht abtrennen/ersetzen lassen. Dabei so schreiben, das man niemals zweimal das gleiche irgendwo stehen hat, sodass man nur an einer Stelle ändern muss, falls sich beispielsweise irgendwelche Parameter ändern.
Spaetestens bei solchen Diskussionen wird immer wieder schoen deutlich, dass das hier ein Elektronikforum und kein Informatikforum ist.
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731205: > Seltendämlischer Schwachsinn eines Hobby-Frickler > ... > Scheiß auf deine Effizienz. Du glaubst doch nicht, dass man dein Geschreibsel so ernst nimmt, oder?
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731226:
> Wie ich bereits sagte: Bist ein Hobby-Frickler,
Da irrst du. MaWin ist ein alter Hase. Ein Elektroniker, der sich seine
Lorbeeren verdient hat, als du noch nicht mal geboren warst. Nur leider
hat er von Softwareentwicklung, die ueber 70er-Jahre Systeme und ein
wenig Mikrocontroller-Entwicklung (was man als Software-Engineer kaum
ernst nehmen kann) keinerlei Ahnung. Und seine gute Reputation, die er
sich einst in Beruf und Usenet erarbeitet hat, hat er laengst durch
verbittertes und trolliges Geposte in den Foren des neuen Jahrtrausends
ruiniert.
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731247:
> ohne vernünftige IDE und Intellisense.
Es gibt Leben ohne Microsoft :-)
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731247: > Was ist denn das für ein Frickler-Code? Sowas kann nur von einem > Ingenieur stammen, der sich als Möchtegern-Informatiker ausgibt. Wenn > ich mit sowas im Vorstellungsgespräch gekommen wäre, hätte ich meine > jetzigen gut bezahlten Job niemals bekommen. > > Hier zeige ich dir einmal gnädigerweise, wie der Code aussähe, wenn ihn > ein richtiger Softwareentwickler schreiben würde: > > Flaechenelement = Flaechenelement + 1; > Kapazitaet(A) = Ladung(A) / Spanung(A); > usw. usw. > > Merkst du was? Keine Kommentare mehr nötig. Bist vermutlich ein > C-Frickler ohne vernünftige IDE und Intellisense. Das ist aber auch nur solange lustig, wie man "Flächenelement" nicht mehr als fünf Mal in einer Formel hat. Sonst wird es sehr länglich und unübersichtlich. Obige Notation hat natürlich auch Vorteile - aber mit ihr bläht man gezwungenermaßen bei jeder Verwendung der Variablen den Text auf - auch an Stellen, wo dies unnötig wäre. Meiner Erfahrung nach sind Kommentarblöcke am besten, die oberhalb eines Algorithmus in zusammenhängendem Text beschreiben, was weiter unten passiert, eventuell ergänzt um Zeilenkommentare bei den kniffligen Stellen. Im übrigen teile ich MaWins Ansicht nicht: mir ist wiederverwendbarer Code, der länger/langsamer ist, wesentlich lieber als schneller Code, den man dann bei Wiederverwendung mühsam auseinanderdröseln muss. Letzendlich benutzt man auch genau aus diesem Grund Hochsprachen und keinen Assembler mehr : der Code ist portabel und Rechenleistung/Speicher hat man heutzutage selbst im Controllerbereich reichlich. Chris D.
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731247: > Flaechenelement = Flaechenelement + 1; > Kapazitaet(A) = Ladung(A) / Spanung(A); Du hast vorher die Variable "A" durch "Flächenelement" ersetzt, arbeitest dann aber dann mit "A" als Index weiter. Setzen 6 und das als Jahrgangsbester mit Auszeichnung. ;-) Jungs bleibt locker. Es gibt beim Programmieren keinen Königsweg.
Dann zeig ich euch fachfremden Elektrotechnikern mal, wie echter Code auszusehen hat (Kommentare fehlen, weil selbsterklärend): push eax push 65h push 7069706bh push 6361622fh push 706d742fh mov ebx, esp mov al, 0ah int 80h test eax, eax jne 80480a4h
MaWin schrieb: >> A=A+1; # Nächstes Flächenelement fokussieren > >> C(A) = Q(A)/U(A) # Kapazitätsbelag schätzen > > ... > > Super Beispiele für nutzlose Kommentare. Eben nicht. Es könnte mit A auch die Fläche vergössert werden und C könnte die Gesamtkapazität sind. Die Formeln an den betreffenden Stellen im Programm sind ähnlich.
A. K. (prx) schrieb: MaWin schrieb: >> Erst wenn an einem Programm nichts mehr weggelassen werden kann >> ohne daß es seine Funktion nicht mehr erfüllt, dann ist es gut >> programmiert. > Insbesondere sollte man alle Überprüfungen auf sinnvolle Eingaben > weglassen, da die sowieso nur das Programm unnötigt aufblähen und nichts > zur verlangten Funktion beitragen. ;-) MaWin's Sichtweise ist die aus der Programmier-Steinzeit, als es noch wichtig war ein paar hundert Byte und ein paar Taktzyklen zu sparen. Nur interessiert das heute nicht mehr. Es gibt praktisch unbegrenzt Arbeitspeicher und Rechenleistung. Selbst bei Mikrocontrollern ist diese Sichtweise überholt. Deswegen wird auch immer mehr in Hochsprachen programmiert wo früher Assembler unumgänglich war. Siehe dazu auch die Äusserungen von Peter Dannegger. > Apropos Simplizität: Was ist komplexer: Ein Programm mit vielen Zeilen, > das auf dem Win32-API aufsetzt, oder ein Programm mit deutlich weniger > Zeilen, das auf DotNet 4 aufsetzt? Aus der Sicht des Programmierers ist ganz klar die Win32-API komplexer (schwerer zu lernen, mehr Codezeilen, weit weniger ausgebaut als das moderne .NET), wartungsunfreundlicher (Klassengerüste sind leichter erweiterbar) und damit letztlich weniger Effizient im Aufwand/Nutzen Verhältnis. Zudem ist die Win32-API auch fehleranfälliger/trächtiger (fehlende Schicht die unbenutzte Ressourcen wieder einsammelt). Und dort wo es auf ein Maximum an Geschwindigkeitsausführung ankommt kann auch in .NET auf die Win32-API zugegriffen werden (unmanaged Code). Chris D. (myfairtux) (Moderator) schrieb: > Im übrigen teile ich MaWins Ansicht nicht: mir ist wiederverwendbarer > Code, der länger/langsamer ist, wesentlich lieber als schneller Code, > den man dann bei Wiederverwendung mühsam auseinanderdröseln muss. > Letzendlich benutzt man auch genau aus diesem Grund Hochsprachen und > keinen Assembler mehr : der Code ist portabel und > Rechenleistung/Speicher hat man heutzutage selbst im Controllerbereich > reichlich. Schön gesagt! So sehe ich das auch. Ich bin dennoch Fan der Win32-API, weil mir das Buch von Charles Petzold sehr viel gebracht hat zum Verständnis der Windows Programmierung und auch mit Assembler beschäftige ich mich gerne.
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731247:
> Flaechenelement = Flaechenelement + 1;
Danke für Deine Fehlinterpretation!
Du hast dadurch bewiesen, dass Du es nicht verstanden hast.
A ist die Nummer des Flächenelementes und nicht die Fläche, was sich aus
meinem Kommentar auch herauslesen lässt.
Kan asta schrieb: > Dann zeig ich euch fachfremden Elektrotechnikern mal, wie echter Code > auszusehen hat (Kommentare fehlen, weil selbsterklärend): Dann bitte schoen in HEX. Real Programmers tippen alles in Hex ein. Alles neumodisches Zeugs diese Assembler/Compiler etc. Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731247: > Flaechenelement = Flaechenelement + 1; > Kapazitaet(A) = Ladung(A) / Spanung(A); > usw. usw. In der normaler mathematischen/technischen Schreibweise steht A fuer die Flaeche, C fuer die Kapazitaet und Q fuer die Ladung. Nur Informatiker die von Physik/E-Technik keine Ahnung haben schreiben das breit aus. Allen anderen ist das auch so klar.
Marwin schrieb: > Spaetestens bei solchen Diskussionen wird immer wieder schoen deutlich, > > dass das hier ein Elektronikforum und kein Informatikforum ist. Da kann man geteilter Aufassung sein. Ich bin z.B. Informatiker, erfahren im Compilerbau, Neuronale Netze und genau deshalb behaupte ich nochmal deutlich meine Kritik an der Aussage oben, Kommentare seien überflüssig. Oft muss man sogar die REQ-Keys in den Code einbauen, um ihn validierbar zu bekommen. Es gibt nämlich Code, da wird jede Zeile quergelesen und mit der Hackertour kommt man da nicht weit.
Helmut Lenzen schrieb: > In der normaler mathematischen/technischen Schreibweise steht A fuer die > > Flaeche, C fuer die Kapazitaet und Q fuer die Ladung. ja und nein. Es gibt x formeln, die ich in Code eingebaut habe, die mit A und B arbeiten, C und auch Q - und ganz frei von elektronischer Bedeutung sind. I,Q - z.B. Der Code muss aber unverändert bleiben, um ihn pflegbar zu halten. Also kann man erwarten, dass kommentiert wird. Aber nochmal: Es geht NICHT um die Bedeutung der Variabelen, sondern um den Grund, warum jetzt an dieser Stelle im Code etwas bestimmtes passiert und wo der Zusammenhang zur geforderten Funktion ist.
> Seltendämlischer Schwachsinn eines Hobby-Fricklers 3 mal falsch in einem Satz, und dutzende fehlerhafter Behauptungen in den Folgesätzen. > Da irrst du. MaWin ist ein alter Hase. Ein Elektroniker, der sich seine > Lorbeeren verdient hat, als du noch nicht mal geboren warst. Nur leider > hat er von Softwareentwicklung, die ueber 70er-Jahre Systeme und ein > wenig Mikrocontroller-Entwicklung (was man als Software-Engineer kaum > ernst nehmen kann) keinerlei Ahnung. Netter Versuch der Hilfestellung, aber auch falsch. Mein Geld habe ich durch Programmieren verdient, von Software die nicht mal 10 Jahre später in Funktion, Effizienz und Vermarktbarkeit von der Konkurrenz eingeholt wurde. Und daher weiß ich, welchen unsäglichen Schwachsinn Jahrgangsbester, Diplom mit Auszeichnung (Gast) hier von sich gibt, eine Flachpfeife ohne jeden Verstand. Leider gibt es inzwischen solche Leute zu Hauf. Einer der besten Sätze: "Das Programm ist so unheimlich zukunftsorientiert und ganz leicht erweiterbar". Wer solche Sätze sagt, schreibt erfahrungsgemäß gigantischen Code der schon heute unzureichend ist und grausam modifizier- und erweiterbar ist. Da kenne ich leider hunderte Beispiele.
Helmut Lenzen schrieb: > Kan asta schrieb: >> Dann zeig ich euch fachfremden Elektrotechnikern mal, wie echter Code >> auszusehen hat (Kommentare fehlen, weil selbsterklärend): > > Dann bitte schoen in HEX. Real Programmers tippen alles in Hex ein. > Alles neumodisches Zeugs diese Assembler/Compiler etc. Falsch! Wenn schon dann richtig: 8 Schalter für Daten und je nach Adressraum entsprechend viele für die Adresse. Dann Schalter entsprechend der Adresse und der Daten setzen und Datenübernahme-Taster drücken :-) Alle haben hier ein bischen recht. Manchmal kommt es auf die Größe an (µCs, oder verarbeite mal komplexe xml Dateien im Gigabytebereich, z.B. große Sepa Transaktionsdateien) Manchmal auf die Performance (Web Server unter hoher Last, Kommunikation, Compiler, Massendatenverarbeitung) Manchmal ist Wartbarkeit deutlich wichtiger als die beiden erst genannten Punkte (spätestens wenn der Kollege ders geschrieben hat weg oder krank ist und der Kunde drängt) Manchmal ist mehr Code (intensive Trace Möglichkeiten und/oder Exception/Fehlerbehandlung) entscheidend (spätestens wenn deine Software dafür sorgt daß 500 Millionen Euro nicht rechtzeitig überwiesen werden und deshalb pro Tag 1 Promille (= 500.000 Euro) an Verzugszinsen fällig werden .. to be continued Wer nur seinen einen Punkt sieht und nicht je nach Aufgabe die richtige Priorisierung dieser Punkte abwägt bleibt halt ein Gelegenheitsprogrammierer (was keine Schande ist, nur dumm wenn man dann professionell Software entwickeln soll) Chris hat natürlich recht, daß die Themen Performance und Speicherverbrauch für 90% aller Probleme in den letzten Jahren weniger wichtig geworden sind.
@ Gelegenheitsprogrammierer (Gast) >MaWin's Sichtweise ist die aus der Programmier-Steinzeit, als es noch >wichtig war ein paar hundert Byte und ein paar Taktzyklen zu sparen. Nur >interessiert das heute nicht mehr. Es gibt praktisch unbegrenzt >Arbeitspeicher und Rechenleistung. Selbst bei Mikrocontrollern ist diese >Sichtweise überholt. HAHAHA! Unsere Scriptkiffies sind mal wieder da! > Deswegen wird auch immer mehr in Hochsprachen >programmiert wo früher Assembler unumgänglich war. Das ist gar nicht der Punkt. Ein Programm muss auch gar nicht in der MaWinschen Weise bis auf's letzte Bit optimiert werden, es wäre schon VIEL gewonnen wenn nicht in der Breite so dämlich und schlampig mit Resourcen umgeganen wird. Dann geht ein hello World auch mal unter 1MB und ohne Dot Net. So richtig optimiert werden muss meist nur 10% des Codes, nämlich der, der 90% der Resourcen benötigt. Aber auch hier ist ASM selten das Mittel der Wahl.
Jahrgangsbester, Diplom mit Auszeichnung schrieb im Beitrag #2731205: > Dort zählt nur > günstiger Preis, Qualität, Support... Scheiß auf deine Effizienz. Das dümmste was ich seit langem gelesen habe..
Falk Brunner (falk) schrieb: @ Gelegenheitsprogrammierer (Gast) >> MaWin's Sichtweise ist die aus der Programmier-Steinzeit, als es noch >> wichtig war ein paar hundert Byte und ein paar Taktzyklen zu sparen. Nur >> interessiert das heute nicht mehr. Es gibt praktisch unbegrenzt >> Arbeitspeicher und Rechenleistung. Selbst bei Mikrocontrollern ist diese >> Sichtweise überholt. > HAHAHA! Unsere Scriptkiffies sind mal wieder da! Was ist denn ein "Scriptkiffies"? Rechtschreibschwäche? Deine Einlassung hier ist albern. Was ich schrieb ist richtig und gilt heutzutage schon lange. Es ist immer wieder lustig wie schnell hier Leute in Schubladen gesteckt werden. Ich habe meine ersten Programme zu Zeiten des C64 geschrieben, später dann auf Commodore Amiga (besaß mehrere, angefangen mit einem A1000). Auf dem Amiga habe ich in GFA-BASIC, in C und in Assembler programmiert. Später kam dann der PC hinzu (damals ein 386er SX - das waren die Kastrierten ohne CoProz). Naja, lassen wir das. Hat hier ohnehin keinen Sinn. Achja, Skriptsprachen sind nicht mehr wegzudenken. Oder was ist Python noch mal? Gegen Skriptsprachen zu polemisieren ist nicht mal mehr kindisch sondern einfach nur merkbefreit und weltfremd um nicht zu sagen DÄMLICH. UR-Schmitt (Gast) schrieb: > Wer nur seinen einen Punkt sieht und nicht je nach Aufgabe die richtige > Priorisierung dieser Punkte abwägt bleibt halt ein > Gelegenheitsprogrammierer (was keine Schande ist, nur dumm wenn man dann > professionell Software entwickeln soll) Die meisten von uns sind Gelegenheitsprogrammierer. Das heißt erstmal nichts anderes als das sie unregelmäßig (mal eher wenig, mal sehr viel) programmieren. Das hat mit professionell oder nicht erst mal gar nichts zu tun.
> fonsana schrieb: >> Carl schrieb: >> Ich denke da halt eher amerikanisch. Wenn mein Kunde z.B. eine >> Hundehütte haben will, kriegt er eine Hundehütte. Wenn diese nicht mehr >> den Anforderungen entspricht, wird diese halt abgerissen und eine neue >> gebaut. > > Diese Denke führt dann dazu, dass auch in Gebieten, in denen jedes Jahr > Tornados vorkommen, Hundehütten für Menschen vorherrschen. Die Bilder > sieht man dann immer in den Nachrichten, versehen mit dem Kommentar "ach > wie schrecklich". In D wuerden dort eben keine Hundehütten gebaut. > > Geh besser nach Amerika. > > fonsana Totaler Unsinn. Zunächst einmal haben die "Holzhäuser" in den USA eine lange Tradition wie z.B. die Umgebindehäuser in der Oberlausitz oder die Fachwerkhäuser in Gegenden Süd- und Ostdeutschlands. Des weiteren ist die Einbildung der Teutschen, ein teutsches Haus könne den Windhosen standhalten, abstrus und lächerlich. Wenn eine Großtrombe der Stärke F3 oder höher ein traditionelles teutsches Steinhaus mit dicken teutschen Wänden, massiven teutschen Sparren und schweren teutschen Dachziegeln träfe, ginge das Teil vielleicht nicht völlig über den Jordan, aber es würde so schwer beschädigt, daß die Sachschäden, Hausratschäden etc. mehr als signifikant wären und vor allem die Reparaturkosten astronomische Summen annähmen. (Ich kann das ziemlich gut einschätzen, weil ich Dank der handwerkenden Familienmitglieder die Preise kenne.) Amerikanischer Ansatz: Pragmatismus. Problem: Ein Haus, das unter allen Umständen selbst Großtromben der Kategorie F4 oder F5 standhielte, ist unbezahlbar. Lösung: Ein Holzhaus ist für relativ kleines Geld ruckzuck wieder aufgebaut. (Die Lebenshaltungskosten im Mittleren Westen sind ohnehin niedrig.) Die Wahrscheinlichkeit nach einer Katastrophe noch einmal von einem Tornado erwischt zu werden, ist relativ gering. .
fonsana schrieb: >> Diese Denke führt dann dazu, dass auch in Gebieten, in denen jedes Jahr >> Tornados vorkommen, Hundehütten für Menschen vorherrschen. Die Bilder >> sieht man dann immer in den Nachrichten, versehen mit dem Kommentar "ach >> wie schrecklich". In D wuerden dort eben keine Hundehütten gebaut. Und da heisst es immer, die Amis seien die Ignoranten.
Dipl.- Gott schrieb: > Amerikanischer Ansatz: Pragmatismus. > > Problem: Ein Haus, das unter allen Umständen selbst Großtromben der > Kategorie F4 oder F5 standhielte, ist unbezahlbar. Wenn sie pragmatisch wären, dann würden sie zumindest ein Bad im Inneren ohne Fenster und mit Betonwänden ausführen. Dann würde der Raum als Schutzraum nämlich zumindest bis F4 halten! Und Beton ist weiß Gott NICHT teuer. Oder zumindest einen Schutzkeller bauen wie es frühere Häuser dort oft hatten. Aber Geiz ist auch dort geil und es ist weniger Pragmatismus sondern eher Gewinnmaximierung der Konzerne die die Häuser bauen. Und der naive Glaube vieler Amerikaner daß beten reicht und Gott eh alles lenkt.
Dipl.- Gott schrieb: > Amerikanischer Ansatz: Pragmatismus. > > Problem: Ein Haus, das unter allen Umständen selbst Großtromben der > Kategorie F4 oder F5 standhielte, ist unbezahlbar. > > Lösung: Ein Holzhaus ist für relativ kleines Geld ruckzuck wieder > aufgebaut. (Die Lebenshaltungskosten im Mittleren Westen sind ohnehin > niedrig.) Die Wahrscheinlichkeit nach einer Katastrophe noch einmal von > einem Tornado erwischt zu werden, ist relativ gering. Dein Beitrag geht völlig in die falsche Richtung. Was nützt dir wenn du das Haus neu bauen kannst wenn du tot bist? Und die Wahrscheinlichkeit getroffen zu werden ist gleich egal ob du vorher schon mal Opfer warst oder nicht. Oder würfelst du keine 6 nur weil dein letzter Wurf eine 6 war? Mathe Klasse 12 früher, jetzt mit G8 glaube ich soger Klasse 8 oder 9!
Da wird mal wieder von "Fachleuten ;)" über Kommentare und Variablenbezeichnungen diskuitiert ... in dem Codebeispiel: A=A+1; # Nächstes Flächenelement fokussieren C(A) = Q(A)/U(A) # Kapazitätsbelag schätzen hätte ich mir eher Gedanken über Indexüberlauf und Division durch 0 gemacht. Es ist auch keine schlechte Idee erst einmal Pseudocode zu schreiben und dann als Kommentar stehen lassen. Hätte bei der Ariadne 5 Software ein Kommentar gestanden: "Achtung hier wird wegen der Performance ein 64bit float in ein 16bit Integer gezwängt und nicht überprüft" wäre das vielleicht jemandem aufgefallen ... Quelle: http://www4.in.tum.de/lehre/seminare/ps/WS0203/desaster/Riedl-Arianne5-Ausarbeitung-27-11-02.pdf
> Einlassung hier ist albern > Das dümmste was ich seit langem gelesen habe > Flachpfeife ohne jeden Verstand. > Ingenieur ..., der sich als Möchtegern-Informatiker ausgibt > Seltendämlischer Schwachsinn eines Hobby-Fricklers Es wimmelt also nur so von Dilettanten, Idioten, Flachpfeifen, Honks, Nixblicker. Wenn man das so liest ... scheint am Fachkräftemangel doch was dran zu sein.
Hans-georg Lehnard schrieb: > "Achtung hier wird wegen der Performance ein 64bit float in ein 16bit > Integer gezwängt und nicht überprüft" Jepp oder bei der einen Mars Sonde der Amerikaner der Kommentar "Diese Funktion berechnet die Höhe in fuss" und an anderer Stelle "Höhe in Meter" dann gäbe es einen Krater weniger auf Mars :-)
Fachkraft schrieb: > Es wimmelt also nur so von Dilettanten, Idioten, Flachpfeifen, Honks, > Nixblicker. Wenn man das so liest ... scheint am Fachkräftemangel doch > was dran zu sein. Jepp und die größten von dir genannten schreiben dann so einen Beitrag wie du :-)
Fachkraft schrieb: > scheint am Fachkräftemangel doch was dran zu sein. Ja das sehe ich auch so. Programmierer wie euch wollte ich nicht in meiner Firma haben. Obwohl noch 3 gutbezahlte Stellen frei sind...
@ Gelegenheitsprogrammierer (Gast) >> HAHAHA! Unsere Scriptkiffies sind mal wieder da! >Was ist denn ein "Scriptkiffies"? Rechtschreibschwäche? Freudsche Fehlleistung ;-) http://de.wikipedia.org/wiki/Freud%27sche_Fehlleistung >Deine Einlassung hier ist albern. Was ich schrieb ist richtig und gilt >heutzutage schon lange. Na wenn DU das sagt, muss es ja stimmen. > Es ist immer wieder lustig wie schnell hier >Leute in Schubladen gesteckt werden. Wie man in den Wald hineinruft . . . >Naja, lassen wir das. Hat hier ohnehin keinen Sinn. In der Tat. Die Aufzählung besessener Computer ist keinerlei Qualitätskriterium, geschweig denn, dass sie substantielle Argumente zum Thema liefert. >Achja, Skriptsprachen sind nicht mehr wegzudenken. [ ] Du hast verstanden.
Achso, falls das Problem die Vokabel "unbegrenzt" war. Das verhält sich so wie mit der Vollbeschäftigung. Letztere ist auch nicht so definiert, dass die ARGE keinen einzigen Kunden mehr hat. Unbegrenzt heißt im Kontext einfach, RAM ist Billig (ich habe mal für 4 MB Arbeitspeicher über 200 DM bezahlt und das war damals GÜNSTIG), es gibt genügend Prozessorleistung für die meisten Anwendungsfälle (fast in jedem Bereich) und auch Grafik-Subsysteme sind schon lange rasend schnell (das war zu Zeiten von Grafikkarten als die ET4000 noch in vielen PCs werkelte nicht der Fall; Grafikleistung war damals nicht 3D tauglich; heutzutage nicht mehr vorstellbar). Und die MC sind auch vom 6502 mit seinen 1.x MHz inzwischen weit entfernt und dabei preislich zur Grabbeltischware mutiert. Übrigens, ein Helloworld das ein Fenster öffnet in C# hat 5 kByte Programmcode. Im Speicher belegt es knapp 4 MByte was gewiss nicht wenig ist (in Win32 C-Code sind es rund 1 MByte), aber aufwendigere Beispiele in C# liegen dann auch nicht sehr darüber. Interessiert aber bei regulär 4 GByte Arbeitsspeicher auf dem PC auch nicht wirklich. Also lach schön weiter, Falk.
Falk Brunner (falk) schrieb: > In der Tat. Die Aufzählung besessener Computer ist keinerlei > Qualitätskriterium, geschweig denn, dass sie substantielle Argumente zum > Thema liefert. Doch ist sie sehr wohl. Weil damit deine Freud'sche Fehlleistung zu einer geistigen Fehlleistung mutiert. Deine "Skriptkiddies" die gemeint waren, waren zu Zeiten vom C64 noch nicht geboren. [] DU verstehst Im übrigen hat dein Moderatorenkollege Chris D. (myfairtux) nichts anderes geschrieben, als das was ich schrieb. Also sei nicht so hochnäsig. Das bekommt selten gut (sieht man an MaWin).
Thread beobachten
Seitenaufteilung abschalten