vergesst C++ ...

Power Off

O'Rakl schrieb:

@Power Off:

Nur aus Neugier:
Wo hast Du denn in BCPL programmiert ? Ist ja eine äußerst seltene Sprache,
der Vor-Vorgänger von C sozusagen.

Ich hab 1989 damit angefangen, als ich das AmigaDOS Manual (von der AmigaOS "dos.library") gelesen habe.

Da stand bei der Dokumentation von AmigaDOS-Handlern:

AmigaDOS Manual schrieb:

This is normally written in BCPL.

Sonst nix. Da bin ich dann neugierig auf die Sprache geworden. Ich hatte den offiziellen Entwickler-Kit nicht, in dem ein BCPL Compiler enthalten war, also kaufte ich mir das Buch "BCPL - The Language and Its Compiler" von Martin Richards und Colin Whitby-Strevens.

Und dann war's um mich geschehen; denn als ich sah, wie einfach und genial BCPL im Vergleich zu C war, wollte ich einiges damit machen.

Ich hab dann in C Programme geschrieben, die genau so wie der BCPL Compiler funktionierten (der teilweise im Buch abgedruckt war), und so lernte ich Compilerbau.

Später fand ich dann das Original BCPL-Paket von Richards im Netz (kann man sich von Cambridge Universität, UK saugen), und schrieb als erstes einen INTCODE-Interpreter und später auch einen INTCODE-Assembler für 68030.

Der INTCODE-Interpreter war in ANSI C geschrieben und lief auf jedem Betriebssystem. Das war echt cool! Ein kleines Programm compilieren, und schon laufen alle BCPL-Programme auf einem neuen Targetsystem.

Da wurde mir klar, daß Richards wirklich der beste Spezialist für portable Compiler und Betriebssysteme war.

Übrigens: Die "dos.library" auf dem Amiga war eine Portierung von TRIPOS, einem Mini-Computer-Betriebssystem, das Richards mal entwickelt hatte. Als MetaComCo für Commodore die "dos.library" entwickeln sollte, habe sie einfach TRIPOS genommen.

Das hat sehr stark zur Erweiterbarkeit und Skalierbarkeit von AmigaOS beigetragen, auch wenn Commodore später (in AmigaOS 2.0) den TRIPOS-Code in C neu entwickelt hatte (lustig waren die damit verbundenen Programmfehler, die es vorher nicht gab, ich brauchte eine Weile, um mich an AmigaOS 2.x und 3.x zu gewöhnen). Aber ohne TRIPOS hatte es irgendwie etwas von seinem Reiz verloren, auch wenn die Funktionalität im Prinzip dieselbe war. Man konnte halt nicht mehr BCPL-Code ins OS einbetten!

maximAL

GPC schrieb:

Schon mal was von Typlisten gehört? Sind auch ganz nett. Wo gibt's die in Python?
Falls es sie gibt (keine Ahnung?!?) ist das sicherlich gut. Aber andersherum gefragt, wie oft brauch ich solche Teile im normalen Alltag? Sowohl in Python als auc h in C++?

typlisten hauen mich auch nicht grad um, mal davon ab werden die meissten programmierer auch davon nie was gehört haben.
und wozu man tupel braucht? also langsam wirds lächerlich...
übrigens hab ich mit python nichts zu tun.

Power Off

Power Off|_work schrieb:

In der Steinzeit.

Sehr witzig! Was soll der Quatsch??

@MaximAL:

Doch. Ist doch eine interessante Diskussion, wie ich finde

@power off:

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.

O'Rakl schrieb:

Ausdrucksschwäche ist keine lokale Eigenschaft, sondern eine globale.
Eine Sprache kann nur an sich ausdrucksstark sein oder eben nicht. Man kann
nicht die Nicht-Existenz von Features mit Codebeispielen beweisen, nur
deren Existenz.

Dann beweise doch mal mit ein paar Python-Beispielen (bitte mit Erklärung, ich kann kein Python), was so unglaublich ausdrucksstarkes möglich ist.

Aber gut, ich gebe Dir dennoch einen Tip, wie Du Dich einem Verständnis des
Problems nähern kannst:
Leg' Deine C++-Referenz mal auf den Schreibtisch und dann sieh von vorne
auf das Buch. Was siehst Du ?
5 bis 10 cm Papier.

-- und nun überlege mal scharf, ob wir hier über eine ausdrucksstarke
Sprache reden, wenn soviel Papier notwendig ist, um überhaupt erst mal
an den Datentyp "string" oder "liste" (der zweiteinfachste zusammengesetzte Datentyp) zu gelangen.

Du verwendest den Begriff "ausdrucksstark" falsch. Eine Sprache ist ausdrucksstark, wenn ich den Index-Operator überladen kann, anstatt eine Methode get(int) schreiben muss, die nicht ausdrückt, dass hier indizieren stattfindet. Es gibt in C++ für alle denkbaren und sinnvollen, sowie für alle nicht sinnvollen (nicht sinnvoll: Überladen von &&, ||, Komma) Dinge ein Sprachmittel, mit dem ich ausdrücken kann, was ich erreichen will. Man kann C++ einiges vorwerfen, z.B. mangelnde Eleganz (foreach), mangelnde Einfachheit (templates), mangelhaftes Übersetzungsmodell (lange compile-zeiten, affige Fehlermeldungen), aber mit Sicherheit kann man C++ nicht vorwerfen, dass es keine Ausdrucksstärke besitzt.
Eine Sprache, die nicht besonders ausdrucksstart ist, ist Ook! und jetzt ist es wichtig zu kapieren, warum. Nicht, weil es nur 2 Syntaxelemente gibt, sondern weil ich in Ook! nicht ausdrücken kann, was ich eigentlich bezwecken will. "Erhöhe den Wert an der aktuellen Adresse um 1" kann ich sagen. Dass ich einen Subtrahierer baue, der erst das 2-Komplement bildet und dann die Stellen addiert, fällt dabei nicht auf. C++ hat mit seinem + Operator mehr Ausdruckskraft.

LUZA

genau

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