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 ?
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
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.
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.
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:
> 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