PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Die Wurzeln aller Sprachen..


firewars
2003-02-25, 20:32:48
Hallo,

ab und an treibt mich eine Frage an meine Wissensgrenzen.

Fangen wir z.B. mit C an. C ist eine Programmiersprache. Womit wurde der Compiler programmiert, der C kompilieren kann? Und womit wurde die Sprache erfunden, mit der man Compiler erstellen konnte?

Also, es geht darum: Wo liegen die Wurzeln? Wann hatte man womit eine erste "Basis", sprich eventuell "Sprache", auf die alles aufbaut?

Mir fehlt hier eindeutig Wissen ;)

stabilo_boss13
2003-02-25, 20:37:19
Originally posted by firewars
Hallo,

ab und an treibt mich eine Frage an meine Wissensgrenzen.

Fangen wir z.B. mit C an. C ist eine Programmiersprache. Womit wurde der Compiler programmiert, der C kompilieren kann? Und womit wurde die Sprache erfunden, mit der man Compiler erstellen konnte?

Also, es geht darum: Wo liegen die Wurzeln? Wann hatte man womit eine erste "Basis", sprich eventuell "Sprache", auf die alles aufbaut?

Mir fehlt hier eindeutig Wissen ;)
Hier http://irb.cs.tu-berlin.de/~zuse/history/Programmiersprachen.html kannst du dir die "Geschichte der Programmiersprachen" von der Technischen Universität Berlin herunterladen. Gezipptes Worddokument mit ca. 70 Seiten.

Fängt so an:

Die ersten Ideen der Programmierung von Rechnern gehen zurück auf Charles Babbage. Charles Babbage (1792-1871) entwarf zwei Rechenmaschinen, die Difference Machine (1823) und die Analytical Engine (1834). Die Maschinen wurden niemals fertiggestellt. Die einzige arithmetische Operation, die ausgeführt werden sollte, war die Addition mit 27-stelligen Dezimalzahlen. Mit der Addition lassen sich eine Reihe von nützlichen Operationen ausführen.

Abe Ghiran
2003-02-25, 20:43:32
Erste Sprache in diesem Sinne war Assembler, also die Maschinensprache. Das ist der Befehlssatz des Prozessors. Wobei Assembler so auch nicht ganz richtig ist, denn Assembler verwendet ja auch schon Symbole ("mov") statt op. codes. Genaugenommen bezeichnet man als Assembler eigentlich das Programm, das die Symbole in ein binär Programm übersetzt aber das nur am Rande.
Also wurden die ersten Programme direkt in Maschinensprache geschrieben. Der Compiler für die erste Hochsprache (keine Ahnung welche das ist aber Fortran ist sehr alt) dann logischerweise auch, von da an konnte man ja dann mit der ersten Hochsprache weiterarbeiten.

Edit: stabilo_boss13 war schneller, interessanter link btw

Jan

stabilo_boss13
2003-02-25, 20:47:30
Originally posted by Abe Ghiran
Der Compiler für die erste Hochsprache (keine Ahnung welche das ist aber Fortran ist sehr alt) dann logischerweise auch, von da an konnte man ja dann mit der ersten Hochsprache weiterarbeiten.
Jan Also nach dem o.a. Dokument war Plankalkül (1945) die erste Programmiersprache (Hochsprache?). Was für ein bescheuerter Name!

firewars
2003-02-25, 21:38:14
Originally posted by stabilo_boss13

Hier http://irb.cs.tu-berlin.de/~zuse/history/Programmiersprachen.html kannst du dir die "Geschichte der Programmiersprachen" von der Technischen Universität Berlin herunterladen. Gezipptes Worddokument mit ca. 70 Seiten.

Genau das habe ich gesucht, danke :)

Abe Ghiran
2003-02-25, 21:55:54
Originally posted by stabilo_boss13
Also nach dem o.a. Dokument war Plankalkül (1945) die erste Programmiersprache (Hochsprache?). Was für ein bescheuerter Name!

Yep, sieht ganz so aus. Mit Fortran hatte ich ja auch mehr so ins blaue geraten. Plankalkül klingt so nach Beamtendeutsch :).

Jan

micki
2003-03-03, 01:32:25
ich glaube, wenn man "mov ax,01" schreibt, dann nennt sich das doch macro assembler, weil ein makro in "echtes" assembler übersetzt wird, dass ja nur aus 1 und 0 besteht.
soweit ich weiß, war die erste programmierbare maschine die auch lief die Z3 von konrad zuse, ich glaube dich hatte ja noch alles auf filmband... muss lustig gewesen sein das ganze programm auf lochband per hand zu stanzen und das debugen erst...... :D

MfG
micki

Xmas
2003-03-03, 01:41:15
Originally posted by micki
ich glaube, wenn man "mov ax,01" schreibt, dann nennt sich das doch macro assembler, weil ein makro in "echtes" assembler übersetzt wird, dass ja nur aus 1 und 0 besteht.
Nein, aus 0 und 1 besteht Maschinensprache. Ein Makroassembler ist ein Assembler der auch Makros unterstützt.

micki
2003-03-03, 12:37:30
assembler ist doch das synomüm für maschinensprache, oder?

es könnte ja sein dass unter assembler beides gemeint ist, also in den büchern die ich über cpus las stand dass assembler die maschinensprache sei,

MfG
micki

Demirug
2003-03-03, 13:03:07
Originally posted by micki
assembler ist doch das synomüm für maschinensprache, oder?

es könnte ja sein dass unter assembler beides gemeint ist, also in den büchern die ich über cpus las stand dass assembler die maschinensprache sei,

MfG
micki

Manchmal wird es als es Synonum verwendet. Das ist allerdings nicht ganz korrekt.

Bei Assembler handelt es sich um eine von Menschen leichter lessbare Form der Maschinensprache. Ein Assembler ist aber auch gleichzeitig das Programm welche ein in Assembler geschriebenes Programm in Maschinencode (sprache) umsetzt. Bei eigentliche Maschinencode handelt es sich nur um eine binäre Darstellung also das was die CPU am ende auch bekommt. Assembler stellt also schon einen Abstraktionsebene dar und wird aus diesem Grund auch gerne als Maschinennahe Programmiersprache bezeichnet.

stabilo_boss13
2003-03-03, 21:22:30
Originally posted by micki
ich glaube, wenn man "mov ax,01" schreibt, dann nennt sich das doch macro assembler, weil ein makro in "echtes" assembler übersetzt wird, dass ja nur aus 1 und 0 besteht.
soweit ich weiß, war die erste programmierbare maschine die auch lief die Z3 von konrad zuse, ich glaube dich hatte ja noch alles auf filmband... muss lustig gewesen sein das ganze programm auf lochband per hand zu stanzen und das debugen erst...... :D

MfG
micki Ein Makro umfasst eine eine Menge von Anweisungen, die mit bestimmten Befehlen zu einem Block zusammengefaßt werden und dann auf bestimmte Weise bearbeitet werden können. Also schon eine kleine Annäherung an Funktionen von Hochsprachen.

Das sieht dann in einem Makroassembler etwa so aus:
pacc MACRO
push acc
endm

Aufrufen kann man das Makro dann beliebig mit:
pacc

Maschinensprache ist der binäre Befehlssatz der CPU.
Die Bytefolge 0A 02 könnte z.B. bedeuten 'Schiebe den Wert 2 in das Register EAX'.

Da sich nur die wenigsten Menschen die ganzen binären Befehlssätze der CPUs merken können, gibt es Programmiersprachen, die dem natürlichen Sprachgebrauch des Menschen näher sind.

Die unterste Stufe dieser Sprachen ist Assembler. Dort würde das obige Beispiel 'Schiebe den Wert 2 in das Register EAX' dann z.B. heissen MOV EAX,02.

micki
2003-03-03, 21:31:17
ob das korrekt ist oder nicht ist definitionssache

z.B:
http://www11.informatik.tu-muenchen.de/lehre/lectures/ws1999-00/einfinfo/einfinfo-course3.3.5.html

ich kenne jedenfalls niemanden der denkt, dass wenn er sagt, dass er ein programm in maschinensprache geschrieben hat, wirklich 0 und 1 meint, und 0 und 1 ist genauso abstrakt wie mov oder add und lediglich eine andere darstellungsweise denk ich mir, aber schlussendlich schreibt man direkt in der für cpus lesbaren sprache, dass das noch extra für uns in text und nicht in zahlen lesbar dargestellt wird, das macht nichts, hab auch schon in assembler gecodet indem ich zahlen eingeben mußte (hex) und trotzdem daneben die instruktionen lesen konnte....

das ist nur reine definitionssache, es wäre überheblich nur das eine als richtig durchsetzen zu wollen


MfG
micki

stabilo_boss13
2003-03-03, 21:53:38
Originally posted by micki
das ist nur reine definitionssache, es wäre überheblich nur das eine als richtig durchsetzen zu wollen


MfG
micki
Ich wollte keinesfalls meine Meinung als richtig durchsetzen. Ich habe nur eine Erklärung der Begriffe abgegeben. Mich deswegen gleich als überheblich zu bezeichnen, finde ich etwas übertrieben.

Häufigste Ursache für fehlerhafte Definitionen ist hier erfahrungsgemäß die mangelnde Unterscheidung zwischen Maschinensprachen (Bytefolgen) und maschinenorientierten Sprachen (Assembler).

Maschinensprache
Für den Prozessor erforderliche Darstellung von Befehlen im binären Zahlenformat. Maschinensprache ist schwer zu programmieren, da sie an der Hardware ausgerichtet ist und nicht wie die höheren Programmiersprachen am Benutzer. Die Maschinensprache wird vom Compiler oder Assembler erzeugt
Quelle: http://www.glossar.de/glossar/1frame.htm?http%3A//www.glossar.de/glossar/z_programmiersprachen.htm

Maschinensprache
Die Maschinensprache ist ein in binärer Form vorliegendes Programm, das vom Prozessor ausgeführt werden kann. Das Programm, das ursprünglich in einer Programmiersprache geschrieben worden ist, wurde durch einen Compiler in den Maschinencode übersetzt.
Quelle: http://www.computerlexikon.com/?w=1&q=377

Maschinensprachen
Einfachste Sprachen, die der Rechner unmittelbar versteht. Jede Arbeitsanweisung ist eine Basisoperation und kann sofort ausgeführt werden. Der Rechner kann nur Signale verarbeiten. Programme in der Maschinensprache sind somit Bitfolgen. Um die Programmierung im Maschinencode zu vereinfachen, wurde Assemblercode, ein symbolisierter Maschinencode, entwickelt. In solchen maschinenorientierten Sprachen kommt man nur in kleinen Schritten vorwärts. Sie erzeugen sehr lange Programme.
Quelle: Uni Leipzig - Grundlagen der Informatik
http://www.informatik.uni-leipzig.de/~meiler/GL.dir/GLWS02.dir/V03_Inf_Num.pdf

zeckensack
2003-03-03, 22:19:48
Originally posted by stabilo_boss13
In solchen maschinenorientierten Sprachen kommt man nur in kleinen Schritten vorwärts. Sie erzeugen sehr lange Programme.
Ist wohl etwas stark verallgemeinert, das ganze ;)


SHR dword [EDI+12],1
RCR dword [EDI+8],1
RCR dword [EDI+4],1
RCR dword [EDI],1

Und zeig mir mal in C/C++/Java/was auch immer du hast, wie du ein 128 bit-Integer auf einer 32bit-Maschine um eins nach rechts schiebst :bäh:

Hrhr :D

edit: little endian :|

Demirug
2003-03-03, 22:31:11
Originally posted by zeckensack

Ist wohl etwas stark verallgemeinert, das ganze ;)


SHR dword [EDI+12],1
RCR dword [EDI+8],1
RCR dword [EDI+4],1
RCR dword [EDI],1

Und zeig mir mal in C/C++/Java/was auch immer du hast, wie du ein 128 bit-Integer auf einer 32bit-Maschine um eins nach rechts schiebst :bäh:

Hrhr :D

edit: little endian :|


Int128 value = new Int128();

value << 1;


Lang lebe die oop :D

stabilo_boss13
2003-03-03, 22:36:22
Originally posted by zeckensack

Ist wohl etwas stark verallgemeinert, das ganze ;)


SHR dword [EDI+12],1
RCR dword [EDI+8],1
RCR dword [EDI+4],1
RCR dword [EDI],1

Und zeig mir mal in C/C++/Java/was auch immer du hast, wie du ein 128 bit-Integer auf einer 32bit-Maschine um eins nach rechts schiebst :bäh:

Hrhr :D

edit: little endian :| Solang ich überlege, kannst du ja mal diese Schaltjahrfunktion in eine Assemblerzeile quetschen:

BOOL isLeap(long j){return((j%4==0)&&((j%100!=0)||(j%400==0)));}

:lol:

zeckensack
2003-03-03, 22:36:55
Originally posted by Demirug



Int128 value = new Int128();

value << 1;


Lang lebe die oop :D Das ist unfair :P
Zeig mir lieber mal, wie Int128 implementiert ist. Mein Tip: bestimmt nicht in purem C++ ... :naughty:


Was ich eigentlich damit sagen wollte, x86 hat ein paar ziemlich geile Eigenheiten, die einem in Hochsprachen grundsätzlich der Compiler wegnimmt. Dazu gehören vor allem die lustigen Spiele mit dem Carry-Flag, double precision shifts, Erzeugen eines 64bit-Integer-Produkts, gleichzeitiges Berechnen von Division und Modulo und ein paar andere Kleinigkeiten.

Demirug
2003-03-03, 22:43:54
Originally posted by zeckensack
Das ist unfair :P
Zeig mir lieber mal, wie Int128 implementiert ist. Mein Tip: bestimmt nicht in purem C++ ... :naughty:


Was ich eigentlich damit sagen wollte, x86 hat ein paar ziemlich geile Eigenheiten, die einem in Hochsprachen grundsätzlich der Compiler wegnimmt. Dazu gehören vor allem die lustigen Spiele mit dem Carry-Flag, double precision shifts, Erzeugen eines 64bit-Integer-Produkts, gleichzeitiges Berechnen von Division und Modulo und ein paar andere Kleinigkeiten.

Ich finde nicht das das unfair ist. Das ist ja der Sinn und Zweg einer höheren Programmiersprache das man solche Details hinter einer einfachen Fassade versteckt. Über die Implementierung eines Int128 Datentypes kann sich ja dann jemand anders Gedanken machen. Aber mit C++ bräuchte ich dafür wohl etwas mehr Code als du mit Assembler.

zeckensack
2003-03-03, 22:53:31
Originally posted by stabilo_boss13
Solang ich überlege, kannst du ja mal diese Schaltjahrfunktion in eine Assemblerzeile quetschen:
BOOL isLeap(long j){return((j%4==0)&&((j%100!=0)||(j%400==0)));}
:lol:

C-Binding:
extern "C" bool __cdecl _x86_isLeap(int j);
Anmerkung:
1)long? Was soll'n das?

NASM-Source:

SECTION .text

global _x86_isLeap

_x86_isLeap:
PUSH EBX
PUSH EDX
MOV EAX,[ESP+12] ;load j
TEST EAX,3
JNZ .nope
CDQ ;sign extend to EDX:EAX
MOV EBX,100
IDIV EBX
TEST EDX,EDX
JNZ .yup
TEST EAX,3
JNZ .nope
.yup:
MOV EAX,1
POP EDX
POP EBX
RETN
.nope:
XOR EAX,EAX
POP EDX
POP EBX
RETN


*urgs*

micki
2003-03-03, 22:57:28
ok spitzfindiger welcher, hast vollkommen recht *lächel* in der perfektesten definition, gut dass du mich verbessert hast.

bin mir sicher dass dich viele im team mögen, wenn du sie wegen ihrer allgemeinen auslegung und vielleicht schon immmer genutzten termini korrigierst.

MfG
micki

zeckensack
2003-03-04, 02:00:23
Originally posted by Demirug


Int128 value = new Int128();

value << 1;


Lang lebe die oop :D

Oh what the hell :D
class
Int128
{
public:

const Int128& operator >> (unsigned int x) {
if (x==1) //hrhr
{
part0=part0>>1|(part1<<31);
part1=part1>>1|(part2<<31);
part2=part2>>1|((reinterpret_cast <unsigned int> (part3))<<31);
part3>>=1;
}
else
printf("Go to hell!\n");
return(*this); }
private:
unsigned int part0; //least significant 32 bits
unsigned int part1;
unsigned int part2;
signed int part3; //most significant 32 bits
};
:stareup:

Xmas
2003-03-04, 02:29:44
Ah, das ist echter Programmierergeist, nachts um 2 noch Klassen für 128 Bit Integer zu schreiben... ;D

stabilo_boss13
2003-03-04, 20:29:50
Originally posted by zeckensack
1)long? Was soll'n das?
Seit dem Jahr 2000 Problem bin ich sehr großzügig mit Longs.:D

aths
2003-03-08, 22:18:01
Sehr interessant, einen Datentyp als class (und nicht als struct) anzulegen. Muss mir nur noch überlegen, was man da für Vorteile hat.

Demirug
2003-03-08, 22:27:21
Originally posted by aths
Sehr interessant, einen Datentyp als class (und nicht als struct) anzulegen. Muss mir nur noch überlegen, was man da für Vorteile hat.

Bei C++ defakto gar keinen. Bei C# macht es aber einen grossen Unterschied ob man class oder struct benutzt.

zeckensack
2003-03-08, 23:24:09
Originally posted by aths
Sehr interessant, einen Datentyp als class (und nicht als struct) anzulegen. Muss mir nur noch überlegen, was man da für Vorteile hat. In C++ ist eine struct eine class ohne Zugriffsrechte. Das heißt daß alle Members 'public' sind.

Wenn man nun OOP-mäßig gewisse Aspekte vor dem Benutzer des Datentyps verstecken möchte, dann sollte man dies mit 'private' machen, und dann braucht man eben 'class' statt 'struct'.

edit: s->ß

Xmas
2003-03-09, 01:02:17
Originally posted by zeckensack
In C++ ist eine struct eine class ohne Zugriffsrechte. Das heißt das alle Members 'public' sind.

Wenn man nun OOP-mäßig gewisse Aspekte vor dem Benutzer des Datentyps verstecken möchte, dann sollte man dies mit 'private' machen, und dann braucht man eben 'class' statt 'struct'.
Nein, struct ist wie class, aber mit Standardzugriff public. Man kann auch in einer struct private oder protected Member haben.

zeckensack
2003-03-09, 01:33:52
Originally posted by Xmas

Nein, struct ist wie class, aber mit Standardzugriff public. Man kann auch in einer struct private oder protected Member haben. Stimmt
:sulkoff:

aths
2003-03-10, 11:25:30
Ich weiß noch immer nicht, wieso man bei zusammengesetzten Datentypen einige Teile "private" deklarieren sollte.

Man verhindert, dass der Programmierer was "unzulässig" anfassen kann. Aber vielleicht würde eine Erlaubnis, was bestimmtes zu ändern, an gewissen Stellen die effizientere Programmierung ermöglichen. Der Programmierer muss ohnehin aufpassen, die richtigen Propertys etc. zu verwenden. Warum also Daten oder Methoden vor ihm verstecken?

Dieses Paradigma "wir geben nur das frei, wovon wir meinen dass der Programmierer das braucht" und er darf ansonsten NUR mit Memberfunktionen operieren, geht mir ziemlich auf den Senkel *¹

(Wenn ich bei Entitäten gewisse Dinge vor gewissen Benutzern "verstecke" kann ich das im Zuge einer Benutzerrechte-Kontrolle verstehen. Aber der Programmierer ist für mich sowieso immer "root", im übertragenen Sinne.)



Sorry für den genervten Tonfall, aber mir geht in letzter Zeit so einiges auf den Senkel :) Zum Beispiel nervt mich ab, dass wir für das Fach "Anwenderprogrammierung" Java nehmen müssen und nicht mit C++ arbeiten dürfen. Ebenso stöhne ich weil wir im Fach Datenbankensysteme mit relationalen Datenbanken und nicht mit objektorientierten arbeiten. Wieso ziehen nicht mal alle an einem Strang und setzen ein klares Paradigma durch, in diesem Falle konsequente Ausrichtung auf moderne OOP und objektorientierte Sichtweise? Tabellen und Relationen haben im Ansatz mit OOP ohnehin einiges gemein, warum also nicht klar Schiff machen?

Demirug
2003-03-10, 11:56:40
Originally posted by aths
Ich weiß noch immer nicht, wieso man bei zusammengesetzten Datentypen einige Teile "private" deklarieren sollte.

Man verhindert, dass der Programmierer was "unzulässig" anfassen kann. Aber vielleicht würde eine Erlaubnis, was bestimmtes zu ändern, an gewissen Stellen die effizientere Programmierung ermöglichen. Der Programmierer muss ohnehin aufpassen, die richtigen Propertys etc. zu verwenden. Warum also Daten oder Methoden vor ihm verstecken?

Dieses Paradigma "wir geben nur das frei, wovon wir meinen dass der Programmierer das braucht" und er darf ansonsten NUR mit Memberfunktionen operieren, geht mir ziemlich auf den Senkel *¹

(Wenn ich bei Entitäten gewisse Dinge vor gewissen Benutzern "verstecke" kann ich das im Zuge einer Benutzerrechte-Kontrolle verstehen. Aber der Programmierer ist für mich sowieso immer "root", im übertragenen Sinne.)



Sorry für den genervten Tonfall, aber mir geht in letzter Zeit so einiges auf den Senkel :) Zum Beispiel nervt mich ab, dass wir für das Fach "Anwenderprogrammierung" Java nehmen müssen und nicht mit C++ arbeiten dürfen. Ebenso stöhne ich weil wir im Fach Datenbankensysteme mit relationalen Datenbanken und nicht mit objektorientierten arbeiten. Wieso ziehen nicht mal alle an einem Strang und setzen ein klares Paradigma durch, in diesem Falle konsequente Ausrichtung auf moderne OOP und objektorientierte Sichtweise? Tabellen und Relationen haben im Ansatz mit OOP ohnehin einiges gemein, warum also nicht klar Schiff machen?

aths, man merkt das du noch nicht bei einem grossen Projekt mitgearbeitet hast (nicht böse gemeint). Der Grund warum man Dinge Private (oder Protected) macht liegt darin das man dadurch nachträglich die komplette interne struktur einer Klasse ändern kann ohne das dadurch andere Programmteile die diese Klasse benutzten betrofen werden. Bei uns gibt es zum Beispiel die Festlegung das alle Membervariablen private oder protected sein müssen. Wer eine Variable public macht bekommt vor mir immer einen Vortrag gehalten.

Der Punkt ist einfach das alles was einmal public ist immer public bleiben muss. Einfaches Beispiel.

Eine Klasse hat 8 boolean Werte als Statusflags. In einer ursprünglichen implentierung werden diese 8 bools einfach als public Elemente zur verfügung gestellt. Nun merkt man im Laufe des Projekts das man sehr viele Instanzen dieser Klasse braucht und der Speicher etwas knapp wird (man programmiert nicht immer nur für Systeme mit Speicher ohne Ende). Man entscheidet die 8 Bools durch ein Byte zu ersetzen. Als folge daraus müssen nun alle Stellen an denen auf eines dieser 8 Flags zugeriffen wurde geändert werden.

Beim nächsten mal ist man schlauer. Man macht die 8 Bools private und läst das ändern und auslesen der Flags nur über public Member funktionen zu. Jetzt kann man ohne Probleme aus den 8 Bools ein Byte machen und muss lediglich die Memberfunktionen anpassen. Der restliche Code bleibt unverändert.

aths
2003-03-10, 19:01:47
Originally posted by Demirug
Beim nächsten mal ist man schlauer. Man macht die 8 Bools private und läst das ändern und auslesen der Flags nur über public Member funktionen zu. Jetzt kann man ohne Probleme aus den 8 Bools ein Byte machen und muss lediglich die Memberfunktionen anpassen. Der restliche Code bleibt unverändert. Jaja, das kommt davon, wenn in der Entwurfsphase geschlampt wird :P

Bei diesem speziellen Fall - ist der Code der benötigt wird, um 1 Byte in 8 Bits zu zerpflücken nicht größer als 7 zusätzliche Bytes?

zeckensack
2003-03-10, 19:23:59
Originally posted by aths
Jaja, das kommt davon, wenn in der Entwurfsphase geschlampt wird :PMan kann in der Entwurfsphase vieles noch nicht so genau wissen. Das hat wenig mit Schlampigkeit zu tun, IMO :P
Bei diesem speziellen Fall - ist der Code der benötigt wird, um 1 Byte in 8 Bits zu zerpflücken nicht größer als 7 zusätzliche Bytes? Der Code muß nur einmal gespeichert werden, die sieben zusätzlichen Bytes für jedes Objekt. Das rechnet sich irgendwann :)

Demirug
2003-03-10, 19:55:18
Originally posted by aths
Jaja, das kommt davon, wenn in der Entwurfsphase geschlampt wird :P

jaja die theoretiker. ;)

Spätestens wenn du ein grosses Softwaresystem über die zweite Version hinweg warten musst wirst du erkennen das man beim Entwurf das Ursprungsystems gar nicht alles berücksichtigen konnte und du wirst sehr froh sein wenn im System alles verkapselt wurde um die gegenseitigen Auswirkungen von Codeänderungen so gering wie möglich zu halten.

aths
2003-03-10, 22:43:41
Originally posted by Demirug
um die gegenseitigen Auswirkungen von Codeänderungen so gering wie möglich zu halten. *Grummel* dieses Argument ist schwerlich zu leugnen.

Xmas
2003-03-10, 22:46:12
Originally posted by zeckensack
Der Code muß nur einmal gespeichert werden, die sieben zusätzlichen Bytes für jedes Objekt. Das rechnet sich irgendwann :)
Na ja, der Code sollte natürlich nach Möglichkeit auch mehr als einmal vorkommen... ;)