vergesst C++ ...

<C++ hat mit seinem + Operator mehr Ausdruckskraft.>

Das gestehe ich zu Wobei mehr Ausdruckskraft als Ook! zu haben nun ein so
großes Kunststück auch wieder nicht ist.

maximAL

Optimizer schrieb:

Du verwendest den Begriff "ausdrucksstark" falsch...

ich glaube eher, dass beides richtig ist.

Schön wie die C++-Gegner mein Kommentar ignorieren

Naja für mich ist das Thema damit erledigt, denn don't feed the trolls

Power Off

O'Rakl schrieb:

TRIPOS ist schon genial, vor allem angesichts seines Alters. Daß man so ein
Großrechner-OS in dem als "Spielcomputer" unterschätzten Amiga verwendet hat,
hat mich damals sehr fasziniert -- der Amiga war in Wahrheit ja allen Konkurrenten
mit ihren nicht-Multitasking-fähigen Spar-Betriebssystemen (ST, Mac, PC) weit überlegen, zumindest, bis Windows 95 kam, also ein Jahrzehnt lang.

Ja, und in manchen Punkten noch länger. Z.B. Das Gerätetreibermodell (Devices/Resources) und auch die AmigaDOS-Handler findet man sonst in keinem anderen Betriebssystem. Mal kurz einen Treiber schreiben? Nur mit AmigaOS! Power to the user!

Übrigens, hast Du gewußt, daß es Amiga Inc. immer noch gibt? Seit einigen Jahren ist es endlich möglich, Amiga-Technologie zu lizensieren. Es gibt von AmigaOS 4 schon Beta-Versionen (entwickelt von Hyperion Entertainment). Es gibt auch mehrere neue Amiga Mainboards von Eyetech UK unter dem Namen "AmigaONE" mit PPC Prozessoren bis 1 GHz. Ist leider sehr kostpielig und es gibt wohl auch noch Probleme damit, aber die Schar von Fans wird immer größer. Hoffentlich ziehen die das voll durch. Wenn ich Geld hätte, würde ich Geld in diese Projekte pumpen und würde auch neue, eigene Systeme entwickeln. Mir persönlich würde ein Fork von AmigaOS 1.3 aus gefallen, würde ich notfalls selber machen, wenn ich die Kohle dazu hätte. Mir hat nämlich nicht gefallen, wie Commodore damals das AmigaOS erweitert hatte. Mit RJ Mical wäre das nicht passiert.

Ich kannte ja das AmigaOS damals fast buchstäblich bis ins letzte Bit, ich würde mir gerne mal das OS so richtig vornehmen.

Aber so weit ich weiß ist das AmigaOS 4 schon äußerst gut geworden. Es gibt z.B. Views auf Libraries, d.h. man kann verschiedene Sichten auf eine Library bekommen (so ähnlich wie die Interfaces bei OLE, nur viel besser). Das Multitasking ist auch erwartungsgemäß sehr schnell, Message Roundtrip Zeit (also von Thread zu Thread und wieder zurück) von unter 1 Mikrosekunde.

Sovok

O'Rakl schrieb:

Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ?
5 bis 10 cm Papier.

sry aber meine c++ referenz hat das format einer festplatte
is nix mit 5-10 cm

abgesehn davon haben c++ programmierer die möglichkeit hinter die kulissen zu schaun
es existiert die "möglichkeit" aber es is keine "bedingung" zu anwendung

sowohl char* als auch std::string lassen sich in 5min erklärn wenn der erklärende sie wirklich kennt... is letztendlich alles ned wirklich wild

Sovok schrieb:

O'Rakl schrieb:

Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ?
5 bis 10 cm Papier.

sry aber meine c++ referenz hat das format einer festplatte
is nix mit 5-10 cm

abgesehn davon haben c++ programmierer die möglichkeit hinter die kulissen zu schaun
es existiert die "möglichkeit" aber es is keine "bedingung" zu anwendung

sowohl char* als auch std::string lassen sich in 5min erklärn wenn der erklärende sie wirklich kennt... is letztendlich alles ned wirklich wild

Meine Referenz heißt "Die C++ Programmiersprache" und enthält weit mehr als nur die Sprache selbst und ist noch lange nicht 10cm dick.

volkard

Sovok schrieb:

sowohl char* als auch std::string lassen sich in 5min erklärn wenn der erklärende sie wirklich kennt

wem?

Sovok

jemandem der sie verwenden will
theoretisches blabla bringt nix und is gleich wieder vergessen
aber wenn der string für eine bestimmte verwendung benötigt wird lassen sich lösung und hintergrundwissen leicht vermitteln

Ben04

Sovok schrieb:

jemandem der sie verwenden will
theoretisches blabla bringt nix und is gleich wieder vergessen
aber wenn der string für eine bestimmte verwendung benötigt wird lassen sich lösung und hintergrundwissen leicht vermitteln

Da bin ich ganz deiner Meinung. Jeder, der std::string verstehen will und ein wenig Grips hat und der jemand hat der ihm weiter hilft sollte etwas nicht offensichtilich sein, hat es innerhalb von 5min kapiert. Hier, in diesem Thread, wäre es aber wirklich Zeitverschwendung das zu erklären.

Power Off schrieb:

Ich hab schon etliche Compiler geschrieben. Compilerbau gehört schon seit 1989 zu meinen Spezialgebieten.

Das kann ich mir jetzt aber nicht erklären, selbst Betatester müssten doch bereits etwas von der Onedefinitionrule gehört haben. (Frag jetzt nicht mich sondern google was das ist!)

Power Off

Ben04 schrieb:

Das kann ich mir jetzt aber nicht erklären, selbst Betatester müssten doch bereits etwas von der Onedefinitionrule gehört haben. (Frag jetzt nicht mich sondern google was das ist!)

Also, das was im Standard (ISO 14882:2003) in Kapitel 14 Vers 8 geschrieben ist? Da sind aber auch die Ausnahmen erklärt, und auf die habe ich mich ja bezogen.

Wenn die STL so geschrieben ist, daß alle Template-Klassen internal linkage haben, dann hat man als Programmierer die A****karte gezogen, wenn man die STL verwendet und sich der Code dadurch ohne Grund auf Megabyte-Größe aufbläht.

@Power off:

<Übrigens, hast Du gewußt, daß es Amiga Inc. immer noch gibt?>

Ja, der Name ist meines Wissens durch einige Hände (Escom, u.a.) gegangen, die aber nicht an den Erfolg von Commodore in den späten 80ern anknüpfen konnten.

Eigentlich schade, daß die Amiga-Geschichte so in den Hintergrund getreten ist,
aber gegen hunderte von Hard- und Software-Herstellern mit den IBM-Industriestandards im Rücken, die begannen, PCs Multimedia-tauglich zu machen, konnte eine einzelne Firme nicht gewinnen, sei das Konzept auch noch so gut.

Angesichts der Tatsache, daß heute "hello, world" schon 300-KByte-Compilate
erzeugt, erscheint es mir nahezu unglaublich, daß man 1986 in ein paar hundert
KByte ROM ein komplettes OS für 68k mit Multitasking, Fenster-GUI,
Grafik-Bibliotheken usw. unterbringen konnte.

Ja, die gute alte Zeit...was wäre wohl passiert, wenn sich Tripos gegen UX
durchgesetzt hätte oder UX gar nicht begonnen worden wäre, da es ja mit
Tripos bereits etwas Ähnliches gab ?

Gibt es eigentlich Tripos im Augenblick für x86 ? So schlank wie Tripos ursprünglich war,
müßte das doch heute auf dem Handy oder der Armbanduhr zum Laufen zu
bringen sein

Ich weiss, nach 15 Seiten ist es etwas spät so grundsätzliche Fragen aufzuwerfen, aber ich kann nicht wiederstehen: Warum können die Python-ist-das-einzig-wahre-Leute und die C++-ist-das-einzig-wahre-Leute nicht mal wieder auf den Boden der Tatsachen zurückkommen? Die Frage ist nicht schwarz/weiss, letztlich nimmt man eben das richtige Tool für das Problem das man lösen will. Und keine der beiden (alle anderen die noch erwähnt wurden eingeschlossen) taugt gut für alles. Wenn ich ein Loch bohren will, nehme ich keinen Hammer, und eine Suppe koche ich nicht in der Pfanne.

Natürlich hat C++ viele Probleme und erzwingt nicht, den Entwickler vor sich selbst zu schützen, und es ist eben wie eine Kettensäge, bevor man damit zu arbeiten Versucht muß man halt lernen worauf man achten muß, sonst sind schneller ein paar Finger weg als einem lieb ist. Aber man kann damit auch anspruchsvolle Probleme lösen wenn man es kann. Und natürlich wird aus einem schlechten Coder durch Python kein guter. Die Behauptung wird auch für Java suggeriert und sie gilt für beide nicht.

Wenn Python das einzig heilsbringende ist, warum ist Python dann nicht in Python implementiert? Weil PyPy nach eigenen Angaben der Entwickler 4000mal langsamer ist? Mag schon sein. Oder pyc, ein Python-Compiler in Python, der guten VM-Bytecode erzeugt, aber ebenfalls brutal langsam ist, ist eben auch nur ein Python-Compiler, worin ist die VM geschrieben? In Python? Natürlich nicht. Und die tollen GUIs? Worin sind die implementiert? In Python? Natürlich nicht.

Was lernen wir daraus? Das Python nix taug, weil es alleine nix kann? Natürlich nicht, sondern das es eben Ein Werkzeug für eine passende Gruppe von Problemem ist, wie C oder C++ oder Java oder Lisp oder von mir aus auch Ook! (naja, vielleicht das nicht ).

Also cool bleiben, eine Diskussion über die Vor- und Nachteile von den jeweiligen Sprachen ist prima (auch wenn sie die Sprachen wohl nicht ändert) und auch für mich immer wieder interessant, aber eine Sprache für alles ist absurd, und das ist auch gut so.

Ich bin beruflich hauptsächlich mit C++ unterwegs, und das schon eine ganze Weile, aber ich habe schon vorher, und werde auch weiterhin immer wieder mal andere Sprachen für verschiedenste Probleme benutzen, wenn sie mir dafür geeignet erscheinen. Und ich halte C++ nicht für die genialste Sprache, sondern halt für die von mir meist (und für meine Brötchen) bearbeiteten Probleme für geeignet, beobachte aber die Entwicklung der anderen Sprachen durchaus.

Achja, und wenn man damit Geld verdienen will, ist eh selten eine freie Wahl der Sprache möglich, da sucht man sich halt (aus dem Angebot) ein Projekt das zu einem passt. So ist die Sprachwahl nicht immer nur eine technische Entscheidung.

maximAL

Augenroller schrieb:

die Python-ist-das-einzig-wahre-Leute

"die"? also davon habe ich hier nur einen einzigen gesehen.

volkard

Augenroller schrieb:

Die Frage ist nicht schwarz/weiss

doch, das ist sie eindeutig.

maximAL

volkard schrieb:

Augenroller schrieb:

Die Frage ist nicht schwarz/weiss

doch, das ist sie eindeutig.

ach, was ist nur aus dir geworden? einst noch halbwegs differenziert, heute könntest du TGGCs vater sein...

volkard

maximAL schrieb:

volkard schrieb:

Augenroller schrieb:

Die Frage ist nicht schwarz/weiss

doch, das ist sie eindeutig.

ach, was ist nur aus dir geworden? einst noch halbwegs differenziert, heute könntest du TGGCs vater sein...

beweis: http://www.volkard.de/sw.png

maximAL

was sagst du denn dazu:

...
ja, ich weiß, daß diese spielregel einen dicken bonus auf funktionale sprachen wirft, wo man mit ohne viel code wirklich große konzepte implementieren kann. wenn sie an erste stelle kommen, dann ist das verdient. wenn nicht, ist die unmittelbarkeit der main-stream-sprachen noch ausreichend, um bei extremen speed-tests zu gewinnen. (meine prophetische ader sagt: die funktionalen sind so viel geiler zu optimieren und die optimierer werden besser, daß sie noch zu meinen lebzeiten ein zwischenhoch erfahren bei solchen speed-tests und c++ und asm auf breiter front plätten).

Sovok

is zeitverschwendung das zu kommentiern

GPC

daß sie noch zu meinen lebzeiten ein zwischenhoch erfahren bei solchen speed-tests und c++ und asm auf breiter front plätten).

Wenn's dann soweit ist, können wir ja umsteigen.

maximAL schrieb:

was sagst du denn dazu:

...
ja, ich weiß, daß diese spielregel einen dicken bonus auf funktionale sprachen wirft, wo man mit ohne viel code wirklich große konzepte implementieren kann. wenn sie an erste stelle kommen, dann ist das verdient. wenn nicht, ist die unmittelbarkeit der main-stream-sprachen noch ausreichend, um bei extremen speed-tests zu gewinnen. (meine prophetische ader sagt: die funktionalen sind so viel geiler zu optimieren und die optimierer werden besser, daß sie noch zu meinen lebzeiten ein zwischenhoch erfahren bei solchen speed-tests und c++ und asm auf breiter front plätten).

Funktionale Sprachen sind schon spannend, keine Frage. Zu der Prognose ist zu sagen, das man das einfach abwarten muss (wenn man nicht selber den Versuch machen will einen so guten Compiler zu schreiben). Aber solange C und C++ so grosse Bedeutung haben, wird sich sicher auch in deren Compilern noch einiges tun, die CPU-Hersteller sind da durchaus dran interessiert, denn sie wollen ja, das ihre CPUs in Benchmarks gut abschneiden. Nicht umsonst hat sich Intel in den Jahren eine gute Crew zusammengekauft und pflegt die Entwicklung eines C++- (und eines Fortran-)Compilers der versucht die CPUs mehr ins Schwitzen zu bringen. Und deren Fortschritte treiben wiederum die GCC-Jungs (und sicher auch die MSler) an, um nicht zu arg zurückzufallen.

Ich bestreite nicht das Potential, aber ich würde meine berufliche Entscheidung eher nicht davon abhängig machen das die Forschung ein Problem irgendwann löst. Wenn es soweit ist, kann man immernoch schwenken. Wenn man nur "for fun" codet oder an Uni oder Forschungsprojekten arbeitet, kann man sich da durchaus mehr austoben, aber für Geld gibt es leider nur einen kleinen Markt für exotischere Sprachen. (Was nicht heisst das man nichts finden kann.)