Hi OO-Cracks !
Es kann mir blühen, dass ich Smalltalk lernen muss (darf?). Nun ist mir zu Ohren gekommen dass alleine Smalltalk wirklich OO darstellt und C++ eine Programmiersprache sei die eben auch etwas OO kann. Mein oberflächlichster Eindruck ist der dass Smalltalk sehr konsequent gemacht ist aber dass mir eigentlich C++ besser gefallen würde(komme halt von C) weil man einfach flexibler ist.
Hoffe auf eine interessante Diskussion
Gruss
SULU
Smalltalk vs. C++
Re: Smalltalk vs. C++
Hi!
1. Nimm C
2. Füge alle Schlüsselworte hinzu, die du irgendwo findest
3. Achte dabei darauf, alles so komplex wie möglich zu machen
4. Mache das ganze inkompatibel zu C
5. Füge auf keinen Fall eine Klassenbibliothek hinzu
6. Du erhälst C++ <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
(7. Optional kann nach einigen Jahren noch die STL hinzugefügt werden, damit es halbwegs erträglich wird)
Ja, SmallTalk ist eine der wenigen wirklich objektorientierten Sprachen. Java und Python sind auch nur halbwegs objektorientiert. Eine Sprache, die ebenso konsequent objektorientiert ist, aber eine wesentlich "konventionellere" Syntax hat, ist Ruby. Ruby kann als Mix aus SmallTalk und Perl betrachtet werden.
Dass du C++ magst, weil du von C kommst, kann ich nicht verstehen. Ich mag C++ nämlich nicht, _weil_ ich von C komme. Wenn schon eine objektorientierte Erweiterung von C, dann doch bitte Objective-C, denn da wurde wenigstens die Grundidee von C nicht völlig verstümmelt, wie das bei C++ der Fall ist.
Ach ja, Objective-C ist übrigens ein C, das um SmallTalk-Elemente erweitert wurde.
Cheers,
GNU/Wolfgang
1. Nimm C
2. Füge alle Schlüsselworte hinzu, die du irgendwo findest
3. Achte dabei darauf, alles so komplex wie möglich zu machen
4. Mache das ganze inkompatibel zu C
5. Füge auf keinen Fall eine Klassenbibliothek hinzu
6. Du erhälst C++ <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
(7. Optional kann nach einigen Jahren noch die STL hinzugefügt werden, damit es halbwegs erträglich wird)
Ja, SmallTalk ist eine der wenigen wirklich objektorientierten Sprachen. Java und Python sind auch nur halbwegs objektorientiert. Eine Sprache, die ebenso konsequent objektorientiert ist, aber eine wesentlich "konventionellere" Syntax hat, ist Ruby. Ruby kann als Mix aus SmallTalk und Perl betrachtet werden.
Dass du C++ magst, weil du von C kommst, kann ich nicht verstehen. Ich mag C++ nämlich nicht, _weil_ ich von C komme. Wenn schon eine objektorientierte Erweiterung von C, dann doch bitte Objective-C, denn da wurde wenigstens die Grundidee von C nicht völlig verstümmelt, wie das bei C++ der Fall ist.
Ach ja, Objective-C ist übrigens ein C, das um SmallTalk-Elemente erweitert wurde.
Cheers,
GNU/Wolfgang
Re: Smalltalk vs. C++
Ähem !
Es wäre möglich dass meine Gehversuche in C++ immer sehr nahe noch am C waren.
Grossartige Kenntnise besitze ich eigentlich nicht von C++.
Unsere OO-Gurus haben eben gesagt dass man Smalltalk nehmen soll wenns wirklich OO sein soll.
Und das ist mir aufgestossen sodass ich es hier zur Diskussion gestellt habe.
Nur. Dieser Smalltalk-Code ist nahezu unlesbar für mich. Da wird mein kalkangereichertes Gehirn zu einigen Verdrehungen gezwungen.
Wenn Du kein C++ magst. Was hältst Du dann von KDE ?
Gruss
Sulu
Es wäre möglich dass meine Gehversuche in C++ immer sehr nahe noch am C waren.
Grossartige Kenntnise besitze ich eigentlich nicht von C++.
Unsere OO-Gurus haben eben gesagt dass man Smalltalk nehmen soll wenns wirklich OO sein soll.
Und das ist mir aufgestossen sodass ich es hier zur Diskussion gestellt habe.
Nur. Dieser Smalltalk-Code ist nahezu unlesbar für mich. Da wird mein kalkangereichertes Gehirn zu einigen Verdrehungen gezwungen.
Wenn Du kein C++ magst. Was hältst Du dann von KDE ?
Gruss
Sulu
Re: Smalltalk vs. C++
Hi!
> Es wäre möglich dass meine Gehversuche in C++ immer sehr nahe noch am C waren.
D.h. du programmierst in einem Hybrid-Stil aus C und C++? Oh je. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
> Unsere OO-Gurus haben eben gesagt dass man Smalltalk nehmen soll wenns wirklich OO sein soll.
Oder eben Ruby, wenn man SmallTalk bizarr findet.
> Und das ist mir aufgestossen sodass ich es hier zur Diskussion gestellt habe.
Eure OO-Gurus haben aber vollkommen Recht.
> Nur. Dieser Smalltalk-Code ist nahezu unlesbar für mich.
C-Code ist auch unlesbar für jemanden, der kein C kann. Scheme-Code ist unlesbar für jemanden, der kein Scheme kann. Na und?
> Wenn Du kein C++ magst. Was hältst Du dann von KDE ?
Was meinst du hier mit KDE? Die Oberfläche (die mit der Programmiersprache ja nichts zu tun hat)? Die API (also in erster Linie Qt)? Beides? Ich kann insgesamt nicht viel über KDE sagen. Ich sehe neuere Versionen von KDE nur, wenn ich mal die Gelegenheit habe, demon beim Arbeiten zuzusehen, was ja nicht gerade jede Woche passiert. Mein bisherigen Eindruck von KDE war, dass es so viele Features anbietet, dass man leicht Probleme kriegen kann, etwas Bestimtes zu finden. Für riesige Funktionalität sind GUIs vermutlich auch meistens nicht die beste Wahl.
Cheers,
GNU/Wolfgang
> Es wäre möglich dass meine Gehversuche in C++ immer sehr nahe noch am C waren.
D.h. du programmierst in einem Hybrid-Stil aus C und C++? Oh je. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
> Unsere OO-Gurus haben eben gesagt dass man Smalltalk nehmen soll wenns wirklich OO sein soll.
Oder eben Ruby, wenn man SmallTalk bizarr findet.
> Und das ist mir aufgestossen sodass ich es hier zur Diskussion gestellt habe.
Eure OO-Gurus haben aber vollkommen Recht.
> Nur. Dieser Smalltalk-Code ist nahezu unlesbar für mich.
C-Code ist auch unlesbar für jemanden, der kein C kann. Scheme-Code ist unlesbar für jemanden, der kein Scheme kann. Na und?
> Wenn Du kein C++ magst. Was hältst Du dann von KDE ?
Was meinst du hier mit KDE? Die Oberfläche (die mit der Programmiersprache ja nichts zu tun hat)? Die API (also in erster Linie Qt)? Beides? Ich kann insgesamt nicht viel über KDE sagen. Ich sehe neuere Versionen von KDE nur, wenn ich mal die Gelegenheit habe, demon beim Arbeiten zuzusehen, was ja nicht gerade jede Woche passiert. Mein bisherigen Eindruck von KDE war, dass es so viele Features anbietet, dass man leicht Probleme kriegen kann, etwas Bestimtes zu finden. Für riesige Funktionalität sind GUIs vermutlich auch meistens nicht die beste Wahl.
Cheers,
GNU/Wolfgang
-
mvo
Re: Smalltalk vs. C++
Hallo Wolfgang,
es waere schoen, wenn Du Deine Vorbehalte gegen C++ noch etwas praezisieren koenntest. Warum? Ich laufe gerade als C++/QT/KDE-Neuling (kommend von C) gegen einige Waende und frage mich, ob ich auch schon zu verkalkt bin.
Wie kommst Du darauf, dass C++ inkompatibel zu C ist? Ich dachte, C sei eine Untermenge von C++? Warum hat C++ so weite Verbreitung gefunden (ich dachte immer, weil es so kompatibel zu C ist)?
es waere schoen, wenn Du Deine Vorbehalte gegen C++ noch etwas praezisieren koenntest. Warum? Ich laufe gerade als C++/QT/KDE-Neuling (kommend von C) gegen einige Waende und frage mich, ob ich auch schon zu verkalkt bin.
Wie kommst Du darauf, dass C++ inkompatibel zu C ist? Ich dachte, C sei eine Untermenge von C++? Warum hat C++ so weite Verbreitung gefunden (ich dachte immer, weil es so kompatibel zu C ist)?
Re: Smalltalk vs. C++
Hi Wolfgang !
Nein. Nein. Kein Hybrid-Stil. Ich hab halt ein bischen in C++ herumgemacht und dann auch noch etwas JAVA (mag die VM nicht).
Man käme schon hinein. Beim Smalltalk ist es nur so das prozedurales Denken anscheinend gar nicht mehr funktioniert.
Man hat eigentlich nur noch Objekte und Signale (sehr einfach ausgedrückt). Hier ist also massiv umdenken angesagt.
Aber Übung hilft natürlich und man kann sich sicher daran gewöhnen.
Für mich privat ist aber immer noch das gute alte C die erste Wahl. C und LINUX passen ja auch exquisit zusammen.
Apropos Hybrid-Stil. Backend in C und Frontend in C++. Das ist doch OK.?
Gruss und gute Nacht (Muss den alternnden Leichnam betten)
@mvo
C und C++ sind eigentlich erstaunlich unterschiedlich. Man kann schon den Code in den Mehtoden ins C schreiben aber
verlgeiche mal C- und C++-Code. Man meint (bis auf das Semi-Colon <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle"> ) zwei verschiedene Sprachen vor sich zu haben.
Gruss Sulu
Nein. Nein. Kein Hybrid-Stil. Ich hab halt ein bischen in C++ herumgemacht und dann auch noch etwas JAVA (mag die VM nicht).
Man käme schon hinein. Beim Smalltalk ist es nur so das prozedurales Denken anscheinend gar nicht mehr funktioniert.
Man hat eigentlich nur noch Objekte und Signale (sehr einfach ausgedrückt). Hier ist also massiv umdenken angesagt.
Aber Übung hilft natürlich und man kann sich sicher daran gewöhnen.
Für mich privat ist aber immer noch das gute alte C die erste Wahl. C und LINUX passen ja auch exquisit zusammen.
Apropos Hybrid-Stil. Backend in C und Frontend in C++. Das ist doch OK.?
Gruss und gute Nacht (Muss den alternnden Leichnam betten)
@mvo
C und C++ sind eigentlich erstaunlich unterschiedlich. Man kann schon den Code in den Mehtoden ins C schreiben aber
verlgeiche mal C- und C++-Code. Man meint (bis auf das Semi-Colon <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle"> ) zwei verschiedene Sprachen vor sich zu haben.
Gruss Sulu
Re: Smalltalk vs. C++
Hi!
mvo schrieb:
> es waere schoen, wenn Du Deine Vorbehalte gegen C++ noch etwas praezisieren koenntest. Warum? Ich laufe gerade als C++/QT/KDE-Neuling (kommend von C) gegen einige Waende und frage mich, ob ich auch schon zu verkalkt bin.
C++ ist unnötig kompliziert. Wärend andere OO-Sprachen nur eine Vererbungsvariante anbieten, kann man in C++ private, protected und public vererben. Man darf also auswendig lernen, was aus einem public-Element bei einer private-Vererbung wird (und natürlich auch alle anderen Kombinationsmöglichkeiten). Besonders schön sind auch die Typecasts in C++. Neben dem aus C bekannten "(datentyp) ausdruck" gibt es auch "datentyp (ausdruck)", aber damit die C-Variante nicht überflüssig wird, funktioniert die neue Variante nur manchmal (bei Zeigern nämlich nicht). Außerdem gibt's ja inzwischen auch (weil sich der C++-Standard ja bekanntlich minütlich ändert, dazu später mehr) noch die laut Bjarne Stroustrup _absicht_ hässlichen Casts mit reinterpret_cast, static_cast usw.
Ach ja, ist folgendes gültiger C++-Code?
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
for (int i = 0; i <= FOO; i++) {
do_something (i);
}
for (int i = 0; i <= BAR; i++) {
do_something_different (i);
}
</font><hr></pre></blockquote>
Antwort: Vielleicht. Da sich der C++-Standard ja bekanntlich minütlich ändert, kann das obige Konstrukt je nach Standard, den man heranziehen möchte, entweder in Ordnung sein oder nicht. Manchmal bezieht sich die Deklaration von i nur auf den Schleifenrumpf (das ist die aktuelle Version, sofern es sich nicht wieder geändert hat), manchmal aber auch nicht, weil sie ja außerhalb des Rumpfes steht und damit hätten wir hier eine ungültige doppelte Definition. Portabler Code kann weder voraussetzen, dass eine so deklarierte Variable nach der Schleife noch existiert noch dass man den gleichen Bezeichner nochmal verwenden kann.
Noch mehr C++-Unsinn erwünscht? Aber gerne: C++ führt zu Zeigern auch noch zusätzlich Referenzen ein. Das funktioniert im Prinzip so, wie man auch in Pascal Referenzen übergibt, d.h. die einzige Stelle, wo man darüber informiert wird, ist die Deklaration bzw. der Kopf der Funktion/Methode. Ergo: Wärend man sich in C sicher sein konnte, dass bei "foo (bar);" keine Veränderung an "bar" vorgenommen wird, kann man das in C++ nicht mehr sein. Sicher ist es schön, in einer Funktion/Methode "baz = foobar;" statt "*qux = foobar;" schreiben zu können und vor Zeiger-Arithmetik geschützt zu sein, aber dazu ist es sicherlich nicht erforderlich, dass beim Aufruf verschwiegen wird, dass eine Übergabe als Referenz erfolgt. Wenn man etwas Neues einführt, sollte es nicht nur die Probleme des Alten vermeiden, sondern auch keine neuen Probleme einführen.
> Wie kommst Du darauf, dass C++ inkompatibel zu C ist?
toor@dose:~$ echo "int main (void) { int class = 0; return class; }" >foo.c
toor@dose:~$ gcc foo.c
toor@dose:~$ g++ foo.c
foo.c: In function `int main()':
foo.c:1: parse error before `0'
foo.c:1: parse error before `;'
toor@dose:~$
Scheint ja offenbar nicht sehr kompatibel zu sein. Da C++ aber offenbar kompatibel sein möchte, kann dies als Designfehler der Sprache betrachtet werden. Objective-C hat solche Macken nicht, sondern ist _wirklich_ zu C kompatibel, d.h. gültiger C-Code ist auch gültiger Objective-C Code.
Will hier jemand sagen, dass das in der Praxis nie ein Problem sei? Ok, das Gegenteil kann leicht demonstriert werden:
toor@dose:~$ grep class archiv/hurd/hurd/libports/ports.h | head -n 1
struct port_class *class;
Das bedeutet, dass ein C++-Programm nicht die Ports-Library verwenden kann. Probleme in der Praxis können durchaus auftreten, gerade bei so allgemeinen Bezeichnungen wie class, new und delete.
> Ich dachte, C sei eine Untermenge von C++?
C++ ist gewiss eine Obermenge von irgendwas. Wir wissen aber nicht genau, von was. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> Jedenfalls nicht von C.
Ernsthaft: In C können beispielsweise Strukturen innerhalb eines Rückgabetyps einer Funktion deklariert werden:
struct punkt { int x, y; } get_punkt (float winkel, int laenge);
Das ist gültiges C, aber kein C++. Es gibt weitere ähnliche Beispiele, etwa ist das in C erlaubt, nicht aber in C++:
enum fortschritt { planung, pre_alpha, alpha, beta, rc, stable, mature };
fortschritt f = 0;
Manchmal wurde auch C schon geändert, um mit C++ kompatibel zu sein, etwa wurde das implizite int in ISO-C verboten:
const foo = 42; /* Lange Zeit war das in C gültig. */
Du siehst, C++ ist sicherlich keine Obermenge von C.
> Warum hat C++ so weite Verbreitung gefunden (ich dachte immer, weil es so kompatibel zu C ist)?
Pustekuchen. Eine C-Bibliothek, die auch von C++ aus nutzbar sein soll, muss praktisch immer die Existenz von C++ berücksichtigen, und sei das nur durch ein
#ifdef __cplusplus
extern "C" {
#endif
am Anfang einer Header-Datei und ein entsprechendes Konstrukt am Ende. Durch dieses hässliche Konstrukt wird das Name-Mangling verhindert, jenes dafür sorgen soll, dass man in C++ Funktionen und Methoden auch überladen kann. Dies tun zu können ist wichtig, denn sonst müsste es ja keine Regeln geben, wann ein Aufruf eindeutig ist und wann nicht, wodurch die Sprache nicht so kompliziert würde. Außer bei Konstrukturen macht das Überladen wirklich wenig Sinn, sondern führt eher zu Verwirrung, wenn man es verwendet.
Sulu schrieb:
> Für mich privat ist aber immer noch das gute alte C die erste Wahl. C und LINUX passen ja auch exquisit zusammen.
Warum eigentlich? Mit GNU Pascal ist man binärkompatibel zu GNU C, d.h. man kann auch mehr oder weniger alles nutzen, was man mit C kann. Es spricht nichts dagegen, Kernel-Module mal in Pascal zu schreiben (Wer's macht, dem geb' ich auf dem LinuxTag einen aus <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> ). Und Systemrufe kann ich auch mit Ruby machen:
toor@dose:~$ ruby -e 'Kernel::syscall(4,1,"hello\<!--no-->n",6)'
hello
toor@dose:~$
> Apropos Hybrid-Stil. Backend in C und Frontend in C++. Das ist doch OK.?
Spricht nichts grundsätzlich dagegen.
Cheers,
GNU/Wolfgang
mvo schrieb:
> es waere schoen, wenn Du Deine Vorbehalte gegen C++ noch etwas praezisieren koenntest. Warum? Ich laufe gerade als C++/QT/KDE-Neuling (kommend von C) gegen einige Waende und frage mich, ob ich auch schon zu verkalkt bin.
C++ ist unnötig kompliziert. Wärend andere OO-Sprachen nur eine Vererbungsvariante anbieten, kann man in C++ private, protected und public vererben. Man darf also auswendig lernen, was aus einem public-Element bei einer private-Vererbung wird (und natürlich auch alle anderen Kombinationsmöglichkeiten). Besonders schön sind auch die Typecasts in C++. Neben dem aus C bekannten "(datentyp) ausdruck" gibt es auch "datentyp (ausdruck)", aber damit die C-Variante nicht überflüssig wird, funktioniert die neue Variante nur manchmal (bei Zeigern nämlich nicht). Außerdem gibt's ja inzwischen auch (weil sich der C++-Standard ja bekanntlich minütlich ändert, dazu später mehr) noch die laut Bjarne Stroustrup _absicht_ hässlichen Casts mit reinterpret_cast, static_cast usw.
Ach ja, ist folgendes gültiger C++-Code?
<blockquote><pre><font size="1" face="">code:</font><hr><font face="Courier New" size="2">
for (int i = 0; i <= FOO; i++) {
do_something (i);
}
for (int i = 0; i <= BAR; i++) {
do_something_different (i);
}
</font><hr></pre></blockquote>
Antwort: Vielleicht. Da sich der C++-Standard ja bekanntlich minütlich ändert, kann das obige Konstrukt je nach Standard, den man heranziehen möchte, entweder in Ordnung sein oder nicht. Manchmal bezieht sich die Deklaration von i nur auf den Schleifenrumpf (das ist die aktuelle Version, sofern es sich nicht wieder geändert hat), manchmal aber auch nicht, weil sie ja außerhalb des Rumpfes steht und damit hätten wir hier eine ungültige doppelte Definition. Portabler Code kann weder voraussetzen, dass eine so deklarierte Variable nach der Schleife noch existiert noch dass man den gleichen Bezeichner nochmal verwenden kann.
Noch mehr C++-Unsinn erwünscht? Aber gerne: C++ führt zu Zeigern auch noch zusätzlich Referenzen ein. Das funktioniert im Prinzip so, wie man auch in Pascal Referenzen übergibt, d.h. die einzige Stelle, wo man darüber informiert wird, ist die Deklaration bzw. der Kopf der Funktion/Methode. Ergo: Wärend man sich in C sicher sein konnte, dass bei "foo (bar);" keine Veränderung an "bar" vorgenommen wird, kann man das in C++ nicht mehr sein. Sicher ist es schön, in einer Funktion/Methode "baz = foobar;" statt "*qux = foobar;" schreiben zu können und vor Zeiger-Arithmetik geschützt zu sein, aber dazu ist es sicherlich nicht erforderlich, dass beim Aufruf verschwiegen wird, dass eine Übergabe als Referenz erfolgt. Wenn man etwas Neues einführt, sollte es nicht nur die Probleme des Alten vermeiden, sondern auch keine neuen Probleme einführen.
> Wie kommst Du darauf, dass C++ inkompatibel zu C ist?
toor@dose:~$ echo "int main (void) { int class = 0; return class; }" >foo.c
toor@dose:~$ gcc foo.c
toor@dose:~$ g++ foo.c
foo.c: In function `int main()':
foo.c:1: parse error before `0'
foo.c:1: parse error before `;'
toor@dose:~$
Scheint ja offenbar nicht sehr kompatibel zu sein. Da C++ aber offenbar kompatibel sein möchte, kann dies als Designfehler der Sprache betrachtet werden. Objective-C hat solche Macken nicht, sondern ist _wirklich_ zu C kompatibel, d.h. gültiger C-Code ist auch gültiger Objective-C Code.
Will hier jemand sagen, dass das in der Praxis nie ein Problem sei? Ok, das Gegenteil kann leicht demonstriert werden:
toor@dose:~$ grep class archiv/hurd/hurd/libports/ports.h | head -n 1
struct port_class *class;
Das bedeutet, dass ein C++-Programm nicht die Ports-Library verwenden kann. Probleme in der Praxis können durchaus auftreten, gerade bei so allgemeinen Bezeichnungen wie class, new und delete.
> Ich dachte, C sei eine Untermenge von C++?
C++ ist gewiss eine Obermenge von irgendwas. Wir wissen aber nicht genau, von was. <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> Jedenfalls nicht von C.
Ernsthaft: In C können beispielsweise Strukturen innerhalb eines Rückgabetyps einer Funktion deklariert werden:
struct punkt { int x, y; } get_punkt (float winkel, int laenge);
Das ist gültiges C, aber kein C++. Es gibt weitere ähnliche Beispiele, etwa ist das in C erlaubt, nicht aber in C++:
enum fortschritt { planung, pre_alpha, alpha, beta, rc, stable, mature };
fortschritt f = 0;
Manchmal wurde auch C schon geändert, um mit C++ kompatibel zu sein, etwa wurde das implizite int in ISO-C verboten:
const foo = 42; /* Lange Zeit war das in C gültig. */
Du siehst, C++ ist sicherlich keine Obermenge von C.
> Warum hat C++ so weite Verbreitung gefunden (ich dachte immer, weil es so kompatibel zu C ist)?
Pustekuchen. Eine C-Bibliothek, die auch von C++ aus nutzbar sein soll, muss praktisch immer die Existenz von C++ berücksichtigen, und sei das nur durch ein
#ifdef __cplusplus
extern "C" {
#endif
am Anfang einer Header-Datei und ein entsprechendes Konstrukt am Ende. Durch dieses hässliche Konstrukt wird das Name-Mangling verhindert, jenes dafür sorgen soll, dass man in C++ Funktionen und Methoden auch überladen kann. Dies tun zu können ist wichtig, denn sonst müsste es ja keine Regeln geben, wann ein Aufruf eindeutig ist und wann nicht, wodurch die Sprache nicht so kompliziert würde. Außer bei Konstrukturen macht das Überladen wirklich wenig Sinn, sondern führt eher zu Verwirrung, wenn man es verwendet.
Sulu schrieb:
> Für mich privat ist aber immer noch das gute alte C die erste Wahl. C und LINUX passen ja auch exquisit zusammen.
Warum eigentlich? Mit GNU Pascal ist man binärkompatibel zu GNU C, d.h. man kann auch mehr oder weniger alles nutzen, was man mit C kann. Es spricht nichts dagegen, Kernel-Module mal in Pascal zu schreiben (Wer's macht, dem geb' ich auf dem LinuxTag einen aus <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle"> ). Und Systemrufe kann ich auch mit Ruby machen:
toor@dose:~$ ruby -e 'Kernel::syscall(4,1,"hello\<!--no-->n",6)'
hello
toor@dose:~$
> Apropos Hybrid-Stil. Backend in C und Frontend in C++. Das ist doch OK.?
Spricht nichts grundsätzlich dagegen.
Cheers,
GNU/Wolfgang
Last edited by bakunin on 29. Jan 2002 1:10, edited 3 times in total.
Re: Smalltalk vs. C++
Hi Wolfgang.
Danke für deine Abhandlung über C++.
Wäre es möglich dass Du eine paar mal winzige Schwierigkeiten mit C++ gehabt hast? Ich habe daraus auf jeden Fall gelernt dass ich mir Objective-C mal anschauen werden.
Frage: Kann man KDE-Applikationen auch mit Objective-C schreiben oder anders gefragt:
Wie verbreitet ist Objective-C?
Welche Limitationen sind damit verbunden?
Verwendest Du Objective-C?
Gruss und Dank
Sulu
PS: Ich würde lieber ein Kernel-Module in qbasic schreiben <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Danke für deine Abhandlung über C++.
Wäre es möglich dass Du eine paar mal winzige Schwierigkeiten mit C++ gehabt hast? Ich habe daraus auf jeden Fall gelernt dass ich mir Objective-C mal anschauen werden.
Frage: Kann man KDE-Applikationen auch mit Objective-C schreiben oder anders gefragt:
Wie verbreitet ist Objective-C?
Welche Limitationen sind damit verbunden?
Verwendest Du Objective-C?
Gruss und Dank
Sulu
PS: Ich würde lieber ein Kernel-Module in qbasic schreiben <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
-
mvo
Re: Smalltalk vs. C++
Hallo Wolfgang,
danke auch von mir! Wenn Sulu mir nicht zuvorgekommen waere, haette ich jetzt fast das gleiche zu Deiner Abhandlung geschrieben <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">.
danke auch von mir! Wenn Sulu mir nicht zuvorgekommen waere, haette ich jetzt fast das gleiche zu Deiner Abhandlung geschrieben <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">.
Re: Smalltalk vs. C++
Hi!
> Danke für deine Abhandlung über C++.
Kein Problem. Ich genieße es, über C++ herzuziehen. =)
> Wäre es möglich dass Du eine paar mal winzige Schwierigkeiten mit C++ gehabt hast?
Eigentlich nicht. Was ich in C++ bisher gemacht habe, hat astrein funktioniert. Das ändert aber nichts daran, dass ich mich bei C++ mehr mit der Sprache selbst befassen musste als mit den zu lösenden Problemen (was gerade bei einer angeblichen OO-Sprache ja nicht der Fall sein sollte). Es ändert auch nichts daran, dass ich bei dem wirren Design der Sprache nur den Kopf schütteln kann.
> Ich habe daraus auf jeden Fall gelernt dass ich mir Objective-C mal anschauen werden.
Nur zu. Aber *blinkblinkblink* am produktivsten ist man in Ruby *aufhörzublinken* <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
> Frage: Kann man KDE-Applikationen auch mit Objective-C schreiben oder anders gefragt: Wie verbreitet ist Objective-C?
Objective-C ist nicht sonderlich verbreitet. Das bekannteste Programm, das darin geschrieben ist, dürfte der Window Maker sein. Wenn man ernsthaft damit programmieren will und nicht nur rumspielen, sollte man die Klassen verwenden, die GNUstep bereitstellt (GNUstep umfasst neben dem Toolkit auch nichtgrafische, gewöhnliche Klassen). Außer in der Umgebung von NeXT, GNUstep / Window Maker und Mac OS X dürfte Objective-C nur wenigen ein Begriff sein.
> Welche Limitationen sind damit verbunden?
Die üblichen Limitationen von allem, was nicht sehr verbreitet ist. Es gibt wenig speziell dafür vorgesehene Bibliotheken.
> Verwendest Du Objective-C?
Objective-C wäre genau dann die Sprache meiner Wahl, wenn es Ruby nicht geben würde. Ruby kann leicht mit C verbunden werden und ist selbst einfach wundervoll.
> PS: Ich würde lieber ein Kernel-Module in qbasic schreiben
Hmmm... Vielleicht bist du bei C++ doch ganz gut aufgehoben? <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Cheers,
GNU/Wolfgang
> Danke für deine Abhandlung über C++.
Kein Problem. Ich genieße es, über C++ herzuziehen. =)
> Wäre es möglich dass Du eine paar mal winzige Schwierigkeiten mit C++ gehabt hast?
Eigentlich nicht. Was ich in C++ bisher gemacht habe, hat astrein funktioniert. Das ändert aber nichts daran, dass ich mich bei C++ mehr mit der Sprache selbst befassen musste als mit den zu lösenden Problemen (was gerade bei einer angeblichen OO-Sprache ja nicht der Fall sein sollte). Es ändert auch nichts daran, dass ich bei dem wirren Design der Sprache nur den Kopf schütteln kann.
> Ich habe daraus auf jeden Fall gelernt dass ich mir Objective-C mal anschauen werden.
Nur zu. Aber *blinkblinkblink* am produktivsten ist man in Ruby *aufhörzublinken* <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
> Frage: Kann man KDE-Applikationen auch mit Objective-C schreiben oder anders gefragt: Wie verbreitet ist Objective-C?
Objective-C ist nicht sonderlich verbreitet. Das bekannteste Programm, das darin geschrieben ist, dürfte der Window Maker sein. Wenn man ernsthaft damit programmieren will und nicht nur rumspielen, sollte man die Klassen verwenden, die GNUstep bereitstellt (GNUstep umfasst neben dem Toolkit auch nichtgrafische, gewöhnliche Klassen). Außer in der Umgebung von NeXT, GNUstep / Window Maker und Mac OS X dürfte Objective-C nur wenigen ein Begriff sein.
> Welche Limitationen sind damit verbunden?
Die üblichen Limitationen von allem, was nicht sehr verbreitet ist. Es gibt wenig speziell dafür vorgesehene Bibliotheken.
> Verwendest Du Objective-C?
Objective-C wäre genau dann die Sprache meiner Wahl, wenn es Ruby nicht geben würde. Ruby kann leicht mit C verbunden werden und ist selbst einfach wundervoll.
> PS: Ich würde lieber ein Kernel-Module in qbasic schreiben
Hmmm... Vielleicht bist du bei C++ doch ganz gut aufgehoben? <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Cheers,
GNU/Wolfgang
Re: Smalltalk vs. C++
Hi!
Aus aktuellem Anlass noch ein kleiner Nachtrag.
Thema: Speicher anfordern in C++.
int *ptr = new int (10);
Wird hier ein Array aus 10 Elementen angefordert? Nein, wird es nicht. Es wird ein einzelnes Element angefordert und mit dem Wert "10" initialisiert. Für 10 Elemente muss man eckige Klammern verwenden statt Runde. Das Initialisieren eines dynamisch angeforderten Arrays ist anscheinend ganz unmöglich (komisch, bei normalen Array-Deklarationen geht es ja auch). Daraus folgt: Diese beiden Varianten existieren nur, um verwechselt zu werden.
Ich bin inzwischen zu der Erkenntnis gelangt, dass C++ absichtlich fehleranfällig und kompliziert konzipiert wurde, denn es ist nicht möglich, eine Programmiersprache dermaßen schlecht zu designen, ohne explizit darauf hinzuarbeiten.
Ich habe gestern und heute eine Menge Objective-C Code geschrieben und muss sagen, dass es einfach nur Spaß gemacht hat. Gestern abend habe ich mich mit jemandem unterhalten, der früher unter NeXT mit Objective-C entwickelt hat und sich damals sehr ärgerte, weil es von C++ verdrängt wurde.
Ich habe nun auch vollstes Verständnis dafür, dass Microsoft mit "C++" nicht mehr C++, sondern einen Java-Klon bezeichnet (die beiden "+"-Zeichen schreiben sie halt noch etwas näher aneinander, also C#). Anmerkung: Warum sie nicht Java verwendet haben? Naja, Microsoft waren sicherlich nicht die ersten, die sich über Suns Java-Politik geärgert haben und es gibt daher eigentlich wenig Gründe, sich darüber zu beschweren, dass sie nicht Java verwendet haben.
Bleibt nur eine Frage offen:
Warum hat Bjarne Stroustrup das getan? Warum wollte er die Produktivität der Software-Entwickler auf dieser Welt vermindern? Ich habe dafür nur eine Erklärung parat: Je schwieriger Software-Entwicklung ist, desto besser werden geniale Entwickler wie Bjarne Stroustrup bezahlt.
Damit wurde eine latente Gefahr des Kapitalismus aufgedeckt: Es wird absichtlich komplizierte Technologie entwickelt, damit der Eindruck entsteht, Technologie sei eben kompliziert und erfordere großartige Kompetenzen, was eine höhere Bezahlung der Experten bedeutet. Das würde auch erklären, warum Videorekorder so kompliziert sind! <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Ähem, ich höre jetzt wohl besser auf. *g*
Cheers,
GNU/Wolfgang
Aus aktuellem Anlass noch ein kleiner Nachtrag.
Thema: Speicher anfordern in C++.
int *ptr = new int (10);
Wird hier ein Array aus 10 Elementen angefordert? Nein, wird es nicht. Es wird ein einzelnes Element angefordert und mit dem Wert "10" initialisiert. Für 10 Elemente muss man eckige Klammern verwenden statt Runde. Das Initialisieren eines dynamisch angeforderten Arrays ist anscheinend ganz unmöglich (komisch, bei normalen Array-Deklarationen geht es ja auch). Daraus folgt: Diese beiden Varianten existieren nur, um verwechselt zu werden.
Ich bin inzwischen zu der Erkenntnis gelangt, dass C++ absichtlich fehleranfällig und kompliziert konzipiert wurde, denn es ist nicht möglich, eine Programmiersprache dermaßen schlecht zu designen, ohne explizit darauf hinzuarbeiten.
Ich habe gestern und heute eine Menge Objective-C Code geschrieben und muss sagen, dass es einfach nur Spaß gemacht hat. Gestern abend habe ich mich mit jemandem unterhalten, der früher unter NeXT mit Objective-C entwickelt hat und sich damals sehr ärgerte, weil es von C++ verdrängt wurde.
Ich habe nun auch vollstes Verständnis dafür, dass Microsoft mit "C++" nicht mehr C++, sondern einen Java-Klon bezeichnet (die beiden "+"-Zeichen schreiben sie halt noch etwas näher aneinander, also C#). Anmerkung: Warum sie nicht Java verwendet haben? Naja, Microsoft waren sicherlich nicht die ersten, die sich über Suns Java-Politik geärgert haben und es gibt daher eigentlich wenig Gründe, sich darüber zu beschweren, dass sie nicht Java verwendet haben.
Bleibt nur eine Frage offen:
Warum hat Bjarne Stroustrup das getan? Warum wollte er die Produktivität der Software-Entwickler auf dieser Welt vermindern? Ich habe dafür nur eine Erklärung parat: Je schwieriger Software-Entwicklung ist, desto besser werden geniale Entwickler wie Bjarne Stroustrup bezahlt.
Damit wurde eine latente Gefahr des Kapitalismus aufgedeckt: Es wird absichtlich komplizierte Technologie entwickelt, damit der Eindruck entsteht, Technologie sei eben kompliziert und erfordere großartige Kompetenzen, was eine höhere Bezahlung der Experten bedeutet. Das würde auch erklären, warum Videorekorder so kompliziert sind! <img src="http://www.pl-forum.de/UltraBoard/Images/Wilk.gif" border="0" align="middle">
Ähem, ich höre jetzt wohl besser auf. *g*
Cheers,
GNU/Wolfgang
-
mvo
Re: Smalltalk vs. C++
> Es wird absichtlich komplizierte Technologie entwickelt, damit der Eindruck entsteht, Technologie sei eben kompliziert und erfordere großartige Kompetenzen,
Da muss ich Dir widersprechen <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">. Wirklich einfache, elegante Entwuerfe erfordern Genie. Aus der Sicht des Ingenieurs z.B. ist die perfekte Maschine eine, bei der man nichts mehr wegnehmen kann. Die mittelmaessigen Geister entwerfen verwurstelte, komplizierte und stoeranfaellige Schoepfungen.
Leider sind Genies selten, darum ist alles so kompliziert.
Da muss ich Dir widersprechen <img src="http://www.pl-forum.de/UltraBoard/Images/Happy.gif" border="0" align="middle">. Wirklich einfache, elegante Entwuerfe erfordern Genie. Aus der Sicht des Ingenieurs z.B. ist die perfekte Maschine eine, bei der man nichts mehr wegnehmen kann. Die mittelmaessigen Geister entwerfen verwurstelte, komplizierte und stoeranfaellige Schoepfungen.
Leider sind Genies selten, darum ist alles so kompliziert.
Re: Smalltalk vs. C++
Hi!
> Wirklich einfache, elegante Entwuerfe erfordern Genie.
Jaja, schön und gut. Nur ein Entwurf, der dermaßen schlecht ist wie C++, ohne dass es dem oberflächlichen Betrachter auffällt, erfordert mindestens genausoviel Genie.
Ich denke nicht, dass Bjarne Stroustrup inkompetent ist. Er ist sicherlich ein Genie. Daher _kann_ er C++ nur absichtlich mit all den Mängeln entwickelt haben.
Cheers,
GNU/Wolfgang
> Wirklich einfache, elegante Entwuerfe erfordern Genie.
Jaja, schön und gut. Nur ein Entwurf, der dermaßen schlecht ist wie C++, ohne dass es dem oberflächlichen Betrachter auffällt, erfordert mindestens genausoviel Genie.
Ich denke nicht, dass Bjarne Stroustrup inkompetent ist. Er ist sicherlich ein Genie. Daher _kann_ er C++ nur absichtlich mit all den Mängeln entwickelt haben.
Cheers,
GNU/Wolfgang
-
AndreasW
Re: Smalltalk vs. C++
Es wird absichtlich komplizierte Technologie entwickelt, damit der Eindruck entsteht, Technologie sei eben kompliziert und erfordere großartige Kompetenzen, was eine höhere Bezahlung der Experten bedeutet.
kann man das auch auf Unix/Linux beziehen?
kann man das auch auf Unix/Linux beziehen?
Re: Smalltalk vs. C++
Hi!
AndreasM schrieb:
> kann man das auch auf Unix/Linux beziehen?
Nein, nur auf X11.
Cheers,
GNU/Wolfgang
AndreasM schrieb:
> kann man das auch auf Unix/Linux beziehen?
Nein, nur auf X11.
Cheers,
GNU/Wolfgang