vergesst C++ ...

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

volkard

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

meinste mich?
ich sag doch seit langem, daß java theoretisch besser optimiert werden kann als c++. und daß es mal so kommen wird. und die lispigen sprachen eh. man kann da gut durchgängig auf allen ebenen optimieren, vom x*0 -> 0 ganz oben bis zum mov r,0 -> xor r,r ganz unten. das ist natürlich ein traum für jeden optimizer.
aber was erwartest du denn, wenn einer mit "vergesst C++...spart euch die Zeit und den Stress und nehmt Python...Adieu, C++ und Java" den thread beginnt? und nu schau doch mal den thread durch, wie fein ich überall differenziert habe.
außerdem nuß ich nicht lisp nehmen, nur weil es bald bessere compiler geben könnte und weil man damit prima funktionen bauen kann, die funktionen bauen. übrigens ist das der knackpunkt, warum c++ gegenüber manchen sprachen hoffnungslos unmächtig ist. typen und bla sind nicht der knaller.
aber naja, ich denke in begriffen und verben, die objekte benutzen und verändern. das bildet c++ sehr gut ab. ich denke nicht, daß ich, wenn ich aufstehe, daß das aufstehen mich an den neuen ort kopiert und mein altes ich wegdestruiert wird, sobald keiner mehr dran denkt.

maximAL

volkard schrieb:

meinste mich?

ja. immerhin ist das zitat von dir

volkard schrieb:

aber was erwartest du denn, wenn einer mit "vergesst C++...spart euch die Zeit und den Stress und nehmt Python...Adieu, C++ und Java" den thread beginnt?

vielleicht, dass sich die C++ verteidiger nicht ebenso dämlich anstellen? die trollen genauso gut - nur, dass das natürlich hier deren höhle ist

und was wäre, wenn ich hier plötzlich ne funktionale (oder gar multi-paradigma) sprache bringe, deren compiler ebenso(/ähnlich) schnellen code wie c++ compiler produzieren? würde das etwas ändern? nein, natürlich nicht...

volkard

maximAL schrieb:

volkard schrieb:

meinste mich?

ja. immerhin ist das zitat von dir

cool. da hab ich ja schon vor mehr als jahren so zeug verzapft.

und was wäre, wenn ich hier plötzlich ne funktionale (oder gar multi-paradigma) sprache bringe, deren compiler ebenso(/ähnlich) schnellen code wie c++ compiler produzieren? würde das etwas ändern? nein, natürlich nicht...

wir wären vermutlich einer meinung, was die messergebnisse angeht. ich sag doch gar nicht, daß ich c++ allein deshalb bevorzuge, wel es so schnell ist. ich sag auch nicht, daß man alles in assember programmieren soll. und ich abstrahiere auch gerne, bis man den boden gar nicht mehr sehen kann. wie heute hier, wo ich zuallererst eine array-klasse drunterschiebe und int nach Karte typedeffe.

Weil Python keine Sprache für hardwarenahe oder resourcenkritische Aufgaben
ist, wozu ein Compiler oder Interpreter zweifelsohne gehört.

Nur -- 95% aller Programmieraufgaben sind nicht hardwarenah und auch nicht
resourcenkritisch, und werden dennoch häufig in C "(*(*i++---j)[k-&(*l])" oder C++ geschrieben.

Für resourcenkritische Aufgaben kann man C-Funktionen in Python einbinden, so, wie man Assembler in C einbinden kann.

Ich denke, C wird in Zukunft mehr und mehr die Rolle eines portablen Assemblers einnehmen; vielleicht gibt es eines Tages CPUs, die C nativ ausführen können. Daß im Micro-Controller-Bereich inzwischen immer mehr in C
programmiert wird, weist in diese Richtung.
Dafür und für die Programmierung von Treibern oder Systemsoftware ist C unbestreitbar erste Wahl.

Power Off

O'Rakl schrieb:

vielleicht gibt es eines Tages CPUs, die C nativ ausführen können.

wie soll das funktionieren?

Ob ein C Compiler jetzt Code für eine reale CPU oder eine virtuelle (emulierte), oder neue CPU generiert, ist doch völlig wurscht.

Bei sog. "BASIC-CPUs" bzw. "Java-CPUs" verwendet der Prozessor ja auch einen speziellen Befehlssatz, für den ein entsprechender Compiler erst Code erzeugen muß.

Ein Prozessor C Programmtext ausführen zu lassen (d.h. wenn er einen C-Interpreter oder Compreter eingebaut hat), ist ja schon heute unnötig, wie sieht das dann erst in der Zukunft aus? Es geht mit Sicherheit schneller einen C Compiler zu schreiben, als einen C-Compreter in Hardware zu implementieren.

Power Off

O'Rakl schrieb:

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

Ja, es gibt TRIPOS für jede Plattform.

Du brauchst nur das Cintpos-System zu benutzen:

http://www.cl.cam.ac.uk/users/mr/Tripos.html

Ja, da hast Du wohl recht, wahrscheinlich wird es in Zukunft keine CPUs geben, die C ausführen können. War ja nur so 'ne Idee, um nicht allzu pessimistisch zu
erscheinen, was die Zukunft von C angeht.

Danke für den Cintpos-Link übrigens

groovemaster

maximAL schrieb:

the right tool for the job - aber da C++ ja von low bis highlevel alles perfekt abdeckt, ist es auch immer das richtige werkzeug, gell?

Nein, du versuchst hier irgendwelche Statements zu zitieren, die es nie gegeben hat, zumindest nicht in diesem Thread. Also lass es einfach bleiben. Selbst C++ Programmierer in diesem Forum betonen immer wieder, dass man die Sprache nehmen sollte, die für den Zweck angemessen ist. Und da ist C++ sicherlich nicht immer die beste Wahl. Das ist aber nicht der Punkt. Der Punkt ist, dass C++ einem fast alles ermöglicht, egal wie einfach oder kompliziert das am Ende ausfällt. Und wenn Python für ein Projekt die bessere Wahl ist, dann wäre ich dumm, dies nicht zu nehmen. Auf der anderen Seite hat C++ genauso seine Einsatzgebiete.

O'Rakl schrieb:

C++ ist keine ausdrucksstarke Sprache.

Jede Programmiersprache ist auf seine Art und Weise ausdrucksstark, sonst hätte sie wohl keiner entwickelt und einfach eine bereits vorhandene genommen. Letztendlich könnten wir uns mit Beispielen bewerfen, bis der Arzt kommt. Nur weiss ich, dass das nichts bringt, du auch?

O'Rakl schrieb:

Zur Erinnerung: "ausdrucksstark" bedeutet, daß man eine Vielzahl von Konzepten
mit *wenig* Code beschreiben kann, nicht, daß die Quelltexte besonders viele
Ausdrücke enthalten

Irgendwie scheinst du selbst nicht zu verstehen, was du da von dir gibst. Die Beschreibung von Konzepten und deren Implementierung mit Code sind immer noch zwei verschiedene Dinge. Alles was du uns sagen willst, ist, dass Python eleganter ist. Schön, das tust du aber schon seit Seite 1. Noch irgendwas neues?

btw:
Könntest du endlich mal richtig quoten. Das ist ja noch schlimmer als deine Argumente.

O'Rakl schrieb:

Man kann
nicht die Nicht-Existenz von Features mit Codebeispielen beweisen

Schön, dass das mal jemand sagt. Das war mir bisher nicht bewusst.

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.

Nö, ich sehe ein PDF mit 757 Seiten, auch bekannt als ISO/IEC 14882:2003(E). Aber wenn wir mal davon ausgehen, dass eine Seite 0,1 mm dick ist, ja, dann kommt das ungefähr hin.

O'Rakl schrieb:

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

Ja...ich überlege...hmm, list scheinen 5 Seiten zu sein. string ist etwas mehr, 24 Seiten. Schnell mal nachgeschaut...ist fast so wie erwartet. Viel Code, sehr viel Code. Eigentlich nur für STL Implementierungen hilfreich. Können wir also überspringen. Aahhhhh, jetzt wird's interessant, jede Funktion wird beschrieben mit Effects und Returns. Sehr schön, genau was wir brauchen. Wie war nochmal das Thema?

maximAL schrieb:

mir wärs nun wirklich zu blöd, noch weiter zu machen, denn mir ist eh klar, dass es im grunde keiner hören will.

Naja, zumindest mit boost muss ich dir teilweise Recht geben. boost ist KEIN Standard, kann man somit auch nicht zum Umfang von Standard C++ zählen. Und wer es benutzt, sollte schon gute C++ Kenntnisse besitzen. Ansonsten gibt es natürlich Sachen, die man, wenn schon nicht built-in, sich zumindest in der STL wünschen würde. Das kann man aber nicht C++ zum Vorwurf machen, sondern muss feststellen, dass andere Sprachen aus den Unzulänglichkeiten gelernt haben. Und das soll nicht heissen, dass es sowas in Zukunft nicht auch in C++ geben wird.
Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

groovemaster schrieb:

Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

Typen sind nichts schlimmes. Nur sollten lediglich Werte typisiert sein, nicht aber Variablen. Das ist aber bei C++ leider nicht der Fall.

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

Helium

Ich denke er will es so wie in Python, nicht aber wie in VB.

maximAL

groovemaster schrieb:

Deine Kritik an den Typen kann ich allerdings nicht nachvollziehen. Man sollte sich immer im Klaren sein, dass C++ ein statisches Typsystem verfolgt. Einige Leute scheinen sich darüber zwar aufzuregen. Denen kann man allerdings nur sagen, das ist kein Bug sondern ein Feature.

oh, es gibt auch statische typsysteme, die ohne explizites deklarieren der typen auskommen
mag sein, dass die dann wieder andere fallstricke haben, aber ich fands schon ganz angenehm

Optimizer schrieb:

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

Visual Basic 6 z.B. hat von seinen Vorgängern geerbt, daß es eigentlich gar
keine Datentypen gibt (nur den Typ "variant" mit einem dutzend Untertypen),
man kann aber auch explizit Typen zuweisen.
Das ist dann eine schwache Typisierung, denn dieselbe Variable kann ohne
Konversion mal als Typ A, mal als Typ B verwendet werden, andererseits
kann man durch explizite Typzuweisung Variablen statisch typisieren.

Chew-Z

Klar hat VB6 seine eigenen Typen. Variant ist nichts weiter als eine Art
struct/union die in eine Typkennung hat, und alle "Basisdatentypen" an
entsprechender Stelle der stuct/union aufnehmen kann. Dazu existeren
bequemerweise noch eine paar Funktionen die Typ-Konvertierungen durchführen
und fertig ist der Variant.
Wer halbwegs vernünftig mit VB6 arbeiten will/muss sollte "option explicit"
vrogeben und anschliessend auch explizit die Datentypen wählen die der
Problemstellung angemessen sind.

maximAL

Optimizer schrieb:

Ähm, wie meinst du das genau, dass man ein statisches Typsystem hat, wo aber nicht die Variablen typisiert sind? Kannst du mal ein Beispiel geben?

ahja, wenn du schon fragst:

let make_triple a b c = (a,b,c);;

eine funktion, die aus 3 parametern ein triplet erzeugt. keine typangaben nötig, die funktion ist generisch.
im unterschied zu template-funktionen in C++ muss ich aber nicht den typ des rückgabewerts angeben.
benutzen kann man das ganz einfach so:

make_triple 1 1. 'a';;
- : int * float * char = (1, 1., 'a')

make_triple ("xyz", 10) 'x' (1,(2.,3.));;
- : (string * int) * char * (int * (float * float)) =
(("xyz", 10), 'x', (1, (2., 3.)))

Triple<A, B, C> createTriple<A, B, C>(A a, B b, C c)

Naja super. Möglicherweise übersehe ich was, aber ich finde hier gerade nichts tolles daran. Lässt sich auch ohne Angabe der Typparameter benutzen:

createTriple(2, 5.0f, "hoi!");

O'Rakl schrieb:

Visual Basic 6 z.B. hat von seinen Vorgängern geerbt, daß es eigentlich gar
keine Datentypen gibt (nur den Typ "variant" mit einem dutzend Untertypen),
man kann aber auch explizit Typen zuweisen.
Das ist dann eine schwache Typisierung, denn dieselbe Variable kann ohne
Konversion mal als Typ A, mal als Typ B verwendet werden, andererseits
kann man durch explizite Typzuweisung Variablen statisch typisieren.

Das ist kein besonderes Feature, welches mehr Flexibilität ermöglicht, sondern mehr die Möglichkeit, automatisch Typ-Konvertierungen durchführen zu lassen. Ich denke sogar, dass Variant einfach nur existiert, damit die Sprache noch leichter zu benutzen ist, ohne dass man überhaupt versteht, was Typen sind.

groovemaster schrieb:

Der Punkt ist, dass C++ einem fast alles ermöglicht,...

Das tut Assembler auch.

Nun ist es aber so, daß C++ mangels eingebauter Datenstrukturen und aufgrund des auf C aufgepropften Objekt-Modells viele sehr einfache Dinge (wie L=["a",1.0]) sehr kompliziert macht, auch wenn sie mit hohem Aufwand und unter Verwendung
äußerst raffinierter externer Bibliotheken (STL,boost,...) möglich sind.

egal wie einfach oder kompliziert das am Ende ausfällt.

Hauptsache, C/C++, hm ? So dachte ich auch einige Jahre lang, bis ich
merkte, daß die Evolution der Programmiersprachen in den vergangenen
10 bis 15 Jahren Fortschritte gemacht hat, die das C-Konzept von 1970
ein wenig angestaubt erscheinen lassen, womit ich nicht in Abrede stelle,
daß C für resourcen-kritische und hardware-nahe Aufgaben erste Wahl ist,
das muß ich ja in jedem zweiten Satz erwähnen, um die Gemüter zu besänftigen

Und das soll nicht heissen, dass es sowas in Zukunft nicht auch in C++ geben wird.

Meinst Du wirklich ? Zum Einen erfordert höhere programmtechnische Eleganz
und Kürze eine gewisse Abstraktion in Form eines dynamischen Typkonzepts
und Garbage Collection, zum Andern ist C++ doch schon groß und kompliziert
genug (die komplizierteste Sprache überhaupt, selbst Common LISP mit seinen
900 Funktionen ist leichter).

Vielleicht wäre es im Sinne der Laufzeitoptimierung besser, eine der moderneren Sprachen wie Ruby oder Python
mit einem wahlweise statischen Typkonzept zu erweitern, ähnlich wie es Dylan
wohl schon macht; das würde sicherlich weniger Aufwand erfordern, als C++ nach STL und Templates noch weiter zu verkomplizieren.

maximAL

Optimizer schrieb:

Triple<A, B, C> createTriple<A, B, C>(A a, B b, C c)
Naja super. Möglicherweise übersehe ich was, aber ich finde hier gerade nichts tolles daran. Lässt sich auch ohne Angabe der Typparameter benutzen:
createTriple(2, 5.0f, "hoi!");

äh, wo kommt der triplet-typ jetzt her?