Die Sprache Carbon https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md tritt an, ein paar Altlasten von C++ über Bord zu werfen und einige (wenige) Vorteile gegenüber C++ zu haben. Dazu ist Carbon konzeptionell sehr nah an C++, und syntaktisch etwas gefälliger (Aussage der Entwickler). Tatsächlich kenne ich von Carbon noch nicht viel, und kann mir deswegen noch gar kein Urteil erlauben. Vielleicht kann aber jemand von Euch etwas dazu sagen?
Alle 3 Jahre gibt es eine neue Sprache Mal ist es D. Dann ist es Rust oder Zig. Nun ist es Carbon. Ich mache jetzt >25 Jahre C++. Das geht bestimmt noch mal 25 Jahre.
Hier Chandler Carruths Talk dazu: https://youtu.be/omrY53kbVoA Wilhelm M. schrieb: > Vielleicht kann aber jemand von Euch etwas dazu sagen? Technisch was dazu zu sagen ist im aktuellen Stadium noch schwierig. Der Idee den AST zwischen C++ <-> Carbon stets abzugleichen um die Interop zu wahren kann ich aber einiges abgewinnen. Ansonsten ist die Wahrscheinlichkeit dass daraus was wird wohl ziemlich groß. Man blicke nur auf Go, Kotlin und Dart...
:
Bearbeitet durch User
Beitrag #7140041 wurde von einem Moderator gelöscht.
Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a. mit "var", "let" und "fn" verunstalten muss?
1 | fn Foo() -> i64 { |
2 | ...
|
3 | |
4 | fn Fibonacci(limit: i64) { |
5 | var (a: i64, b: i64) = (0, 1); |
6 | while (a < limit) { |
7 | Console.Print(a, " "); |
8 | let next: i64 = a + b; |
Return multiple ... sinnvoll?
1 | fn DoubleBoth(x: i32, y: i32) -> (i32, i32) { |
2 | return (2 * x, 2 * y); |
3 | }
|
Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool" zurückliefern.
Vincent H. schrieb: > Der > Idee den AST zwischen C++ <-> Carbon stets abzugleichen um die Interop > zu wahren kann ich aber einiges abgewinnen. Wenn das möglich ist, dann kann ich mir nicht vorstellen, dass es funktional wesentliche Unterschiede zwischen Carbon und C++ geben kann. Carbon wäre dann nur syntactic sugar. Der Punkt für (z.B.) Rust ist doch, dass damit andere Konzepte verfolgt werden, um einige der häufigen Fehler oder Schwachstellen in C++ zu vermeiden.
Tilo R. schrieb: > Vincent H. schrieb: >> Der >> Idee den AST zwischen C++ <-> Carbon stets abzugleichen um die Interop >> zu wahren kann ich aber einiges abgewinnen. > > Wenn das möglich ist, dann kann ich mir nicht vorstellen, dass es > funktional wesentliche Unterschiede zwischen Carbon und C++ geben kann. > Carbon wäre dann nur syntactic sugar. > > Der Punkt für (z.B.) Rust ist doch, dass damit andere Konzepte verfolgt > werden, um einige der häufigen Fehler oder Schwachstellen in C++ zu > vermeiden. Der Talk geht eh recht deutlich darauf ein: - Interop first - Safety later Binnen der ersten paar Minuten erklärt Carruth dass Carbon eben kein Rust sein soll.
PittyJ schrieb: > Alle 3 Jahre gibt es eine neue Sprache > Mal ist es D. Das geht bestimmt noch mal 25 Jahre. Und was macht man, wenn man Z erreicht hat? :-)
Harald W. schrieb: > PittyJ schrieb: > >> Alle 3 Jahre gibt es eine neue Sprache >> Mal ist es D. Das geht bestimmt noch mal 25 Jahre. > > Und was macht man, wenn man Z erreicht hat? :-) AA
Harald W. schrieb: > Und was macht man, wenn man Z erreicht hat? :-) Man nimmt längere Namen. "Carbon" fängt mit "C" an, schon gemerkt?
DerEgon schrieb: >> Und was macht man, wenn man Z erreicht hat? :-) > > Man nimmt längere Namen. "Carbon" fängt mit "C" an, schon gemerkt? Und wie sieht's dabei mit dem Carbon Footprint aus? ;-)
Wilhelm M. schrieb: > Vielleicht kann aber jemand von Euch etwas dazu sagen? Ja, für 5000€ + MWSt erstelle ich Dir ein Gutachten über die Eignung dieser Programmiersprache.
PittyJ schrieb: > Alle 3 Jahre gibt es eine neue Sprache > Mal ist es D. Dann ist es Rust oder Zig. Nun ist es Carbon. > > Ich mache jetzt >25 Jahre C++. Das geht bestimmt noch mal 25 Jahre. so ist es. eine neue programmiersprache zu entwickeln ist eine sache, entwickler dazu zu bringen die neue zu lernen eine andere.
Random .. schrieb: > Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a. > mit "var", "let" und "fn" verunstalten muss? Du bist der Erste, der C++ als "einfach" und "lesbar" bezeichnet! Du findst es gut, weil du es gewöhnt bist. Tatsächlich ist die C++-Syntax derart komplex, das man sie nicht als kontextfreie Sprache beschreiben und damit einfach Parser generieren könnte. Daher gibt es da auch so Scherze wie "Most-Vexing Parse" oder "foo.template blub<X>" oder "typename X::Y" und die Syntax für Type Inference ist ziemlich schlimm. Allgemein hat C++ Probleme damit zu unterscheiden wann ein Typ und wann ein Objekt kommen soll. Postfix-Typnotation wie ":i64" macht die Syntax für Typinferenz viel einfacher, und in vielen Fällen lässt man den Typ eh weg. "fun", "let" etc. vermeiden diverse Uneindeutigkeiten und Hässlichkeiten wie das Most-Vexing Parse und es ist immer klar wann ein Typ kommt und wann nicht. Typdefinitionen in C und C++ sind i.A. schlimm - definiere mal eine Referenz auf ein Array aus Funktionspointern welche einen Pointer auf was konstantes zurückgeben, aber eine Referenz auf einen konstanten Pointer auf was nicht-konstantes als Parameter bekommen. In modernen Sprachen kein Problem, aber in C++ macht das einen ziemlichen Knoten ins Hirn. Random .. schrieb: > Return multiple ... sinnvoll? Hat sich in vielen Sprachen seit Jahrzehnten als sinnvoll erwiesen. So ist direkt klar, was Rückgabe und was Eingabe ist. Beim Aufruf erspart man sich ein paar Zeilen. Die Idee, eine neue Syntax für C++ zu bauen, hatte ich auch schon!
Random .. schrieb: > Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a. > mit "var", "let" und "fn" verunstalten muss? Du hast wohl noch nie C++-Code gelesen, oder? :) So richtig schöner C++-Template-Code. Guck mal in die C++ stdlib rein. Kurze Keywords für Kernkonzepte zu verwenden, macht es einfacher lesbar, für Mensch und für den Compiler. > Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool" > zurückliefern. Warum denn? Das kann doch nur eine schlechte Angewohnheit sein. Wirkliche Vorteile gibts da doch keine.
Genusskoch schrieb: > so ist es. eine neue programmiersprache zu entwickeln ist eine sache, > entwickler dazu zu bringen die neue zu lernen eine andere. FAANG Firmen haben das eben nicht nötig. Niemand braucht Swift. Und? Apple zieht es trotzdem durch. Wer braucht Carbon? Niemand. Wird aber Google morgen Carbon intern nutzen, dann werden es sofort viele anfangen zu lernen. Siehe Rust, Google und Linux.
Der arme Bjarne! Alle zwei Jahre die Sprache verunstalten und es reicht immer noch nicht. Es ist immer noch zu wenig.
können jedem das Genick brechen schrieb: > Es ist immer noch zu wenig. Das Problem an C++ ist nicht, dass es zu wenig ist. Ganz im Gegenteil. Das Problem ist, dass es zu viel ist.
Wilhelm M. schrieb: > tritt an, ein paar Altlasten von C++ über Bord zu werfen und einige > (wenige) Vorteile gegenüber C++ zu haben. Ich würde sagen, dass das ein RIESEN Vorteil ist ;-) , (wenn sie die Sprache einigermaßen stabil halten können und nicht alle 2 Jahre die eigenen Altlasten entsorgen müssen) können jedem das Genick brechen schrieb: > Der arme Bjarne! > Alle zwei Jahre die Sprache verunstalten und es reicht immer noch nicht. > Es ist immer noch zu wenig. Bjarne sieht nicht allzu unglücklich aus, wenn er jährlich auf der cppcon über die Fortschritte von C++ berichtet.
Random .. schrieb: > Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a. > mit "var", "let" und "fn" verunstalten muss? Um nicht mit der von Beginn an verkorksten syntaktischen Form von C und den von C abgeleiteten Sprachen weiter zu machen. Bei einer guten Grammatik ist ein Datentyp ein normaler Identifier wie eine Variable, dieser Identifier steht vor seiner Beschreibung, und die Typbeschreibung entwickelt sich linear, nicht verschachtelt. Das macht ein reserviertes Wort erforderlich, ein Keyword, um Deklarationen einzuleiten. Ob das var/let/fn ist, oder Schnurzelfix, ist dann Geschmacksache.
:
Bearbeitet durch User
Wilhelm M. schrieb: > tritt an, ein paar Altlasten von xxx über Bord zu werfen und einige > (wenige) Vorteile gegenüber xxx zu haben Grundprinzip einer neuen Sprache. Wenn da nicht die Einführung neuer Unzulänglichkeiten wäre. Wie soll eine Sprache überhaupt noch führend werden können wenn fortlaufend neue Sprachen Unzulänglichkeiten jener adressieren? Unter dem Strich zersplittert die Sprachlandschaft immer mehr. Vereinfacht das irgendwas? Hat sich mit Carbon überhaupt irgendetwas Grundsätzliches verbessert?
:
Bearbeitet durch User
Random .. schrieb: > Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool" > zurückliefern. Genau, warum auch mit einer Zeile glücklich sein, wenn man ein Dutzend haben kann.
Ron T. schrieb: > Vereinfacht das irgendwas? Nein. Aber es verschlimmert auch nichts. Niemand muss neue Sprachen nutzen. Und die meisten neuen Sprachen sind ja auch Nischensprachen.
MaWin schrieb: > Nein. > Aber es verschlimmert auch nichts. Der neue Turm zu Babel. Und ihr merkt es nicht mal. Das ist sehr wohl ein Problem.
er hat Jehova gesagt schrieb: > Das ist sehr wohl ein Problem. Warum? Könntest du das einmal an einem Beispiel ausführen?
Random .. schrieb: > Return multiple ... sinnvoll?fn DoubleBoth(x: i32, y: i32) -> (i32, i32) > { > return (2 * x, 2 * y); > } > Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool" > zurückliefern. Ich hab mich früher öfter gefragt, warum man eigentlich beliebig viele Parameter, aber nur maximal einen Resturnwert haben kann. Diese Asymmetrie kam mir wenig sinnvoll vor. Warum findest du es besser, wenn du mehrere Werte zurückliefern willst, das indirekt über Pointer-Parameter zu machen, statt eben als Returnwerte. C++ bietet mehrere Returnwerte indirekt über Strukturen oder Tupel und unpacking auch, aber nicht sehr elegant. Da würde die Funktion dann so aussehen:
1 | #include <tuple> |
2 | #include <iostream> |
3 | |
4 | std::tuple<int, int> DoubleBoth(int x, int y) |
5 | {
|
6 | return { 2 * x, 2 * y }; |
7 | }
|
8 | |
9 | int main() |
10 | {
|
11 | auto [ x2, y2 ] = DoubleBoth(3, 5); |
12 | std::cout << x2 << '/' << y2 << '\n'; |
13 | }
|
(prx) A. K. schrieb: > dieser Identifier steht vor seiner Beschreibung, Warum?
:
Bearbeitet durch User
MaWin schrieb: > Aber es verschlimmert auch nichts Die bloße Existenz sicher nicht. Aber es ist doch klar daß sich das Angebot von Programmierern für eine bestimmte Sprache bei immer mehr verwendeten Sprachen zwangsläufig verkleinert (mal vom generellen Unterangebot an Programmierern ganz abgesehen). Und Du meinst immer noch "es verschlimmert auch nichts" ? Als wesentliches Ziel wurde bei Carbon die C++ Kompatibilität und Weiterverwendbarkeit diesbezüglichen Codes genannt. Ob die dabei entstehenden Mischkonstrukte dadurch verständlicher und leichter handelbar werden? Sicher nicht - das steht vielmehr diametral entgegengesetzt dem Ziel effizienten, verständlichen Codes. MaWin schrieb: > Niemand muss neue Sprachen nutzen. Carbon?
:
Bearbeitet durch User
Ron T. schrieb: > Als wesentliches Ziel wurde bei Carbon die C++ Kompatibilität und > Weiterverwendbarkeit diesbezüglichen Codes genannt. Ob die dabei > entstehenden Mischkonstrukte dadurch verständlicher und leichter > handelbar werden? Sicher nicht - das steht vielmehr diametral > entgegengesetzt dem Ziel effizienten, verständlichen Codes. Was würdest du tun, um das Ziel zu erreichen?
Mombert H. schrieb: > Was würdest du tun, um das Ziel zu erreichen? Sicher nicht dadurch ein um die andere Sprache aus dem Boden zu stampfen und gar kombinieren zu wollen. Aber vielleicht weißt Du ja warum Carbon nun die Offenbarung sein kann? Diesbezüglich bin ich hier nur Fragender...
:
Bearbeitet durch User
Ron T. schrieb: > Mombert H. schrieb: >> Was würdest du tun, um das Ziel zu erreichen? > > Sicher nicht dadurch ein um die andere Sprache aus dem Boden zu stampfen > und gar kombinieren zu wollen. Aber vielleicht weißt Du ja warum Carbon > nun die Offenbarung sein kann? Diesbezüglich bin ich hier nur > Fragender... Das bedeutet wohl, dass du keine bessere Idee hast. Niemand hat gesagt, dass Carbon die Offenbarung ist oder sein will. Du hast dir offensichtlich nichtmal die Mühe gemacht, das oben verlinkte Video anzusehen. Sonst wüsstest du, dass die Schöpfer selbst Carbon als ein Experiment sehen und nicht wissen, ob es die Zukunft von C++ ist.
Programmierer schrieb: > Allgemein hat C++ Probleme damit zu unterscheiden wann ein Typ und wann > ein Objekt kommen soll. Dieses Problem scheint es in Carbon - wenn auch in ganz anderer Form - aber auch zu geben: "Expressions compute values in Carbon, and these values are always strongly typed much like in C++. However, an important difference from C++ is that types are themselves modeled as values; specifically, compile-time constant values. This means that the grammar for writing a type is the expression grammar." Jeder Typ ist also selbst wiederum ein Objekt. Wie soll da eine saubere Trennung zwischen den beiden funktionieren?
Rolf M. schrieb: > "Expressions compute values in Carbon, and these values are always > strongly typed much like in C++. However, an important difference from > C++ is that types are themselves modeled as values; specifically, > compile-time constant values. This means that the grammar for writing a > type is the expression grammar." > > Jeder Typ ist also selbst wiederum ein Objekt. Wie soll da eine saubere > Trennung zwischen den beiden funktionieren? Das ist nicht das, was in dem von dir zitierten Text steht. Da steht niergends das Wort Objekt sondern es ist die Rede von Werten und Ausdrücken.
Ron T. schrieb: > Sicher nicht dadurch ein um die andere Sprache aus dem Boden zu stampfen > und gar kombinieren zu wollen. Wie würdest du zielsicher die einzig wahre Sprache ausfindig machen? Die einzig wahre Sprache ist doch FORTRAN, und alles was danach kam sind nur ein Wust unnötiger Sprachen, die man im blinden Fortschrittsglauben aus dem Boden gestampft hat. Damals konnte jeder FORTRAN, weil es nichts anderes gab. Jetzt gibt's eine Unzahl an Entwicklern für alle möglichen Sprachen, und es ist schwierig einen für die gewünschte Sprache zu finden (Cobol? APL? LISP? ALGOL? ...). 1960 gab es bereits einen großen Wildwuchs an Sprachen die keiner braucht, was war schlecht an FORTRAN? Rolf M. schrieb: > Jeder Typ ist also selbst wiederum ein Objekt. Wie soll da eine saubere > Trennung zwischen den beiden funktionieren? Das geht in Sprachen wie Python ganz wunderbar. Tatsächlich ist das ziemlich clever, weil es die Syntax vereinfacht und man sich die Unterscheidung erspart. Mombert H. schrieb: > Da steht > niergends das Wort Objekt sondern es ist die Rede von Werten und > Ausdrücken. Naja, Werte sind Objekte (in C++). Ausdrücke geben Werte (Objekte) zurück.
Ron T. schrieb: > Aber es ist doch klar daß sich das Angebot von Programmierern für eine > bestimmte Sprache bei immer mehr verwendeten Sprachen zwangsläufig > verkleinert Nein. Wieso? Ist es verboten mehr als zwei Sprachen zu beherrschen? Außerdem kann man die allermeisten Programmiersprachen relativ schnell erlernen. Diese Erwartungshaltung (auch vieler Arbeitgeber), dass man möglichst alle im Unternehmen verwendeten Sprachen schon vor der Einstellung beherrscht, ist überholt. Lieber einen guten Entwickler einstellen, der Sprache X nicht beherrscht, und ihm dann ebenjene Sprache beibringen. Unterm Strich ist das ein Gewinn für alle. Ron T. schrieb: > Ob die dabei > entstehenden Mischkonstrukte dadurch verständlicher und leichter > handelbar werden? Sicher nicht Sicher doch. Das nennt sich (Modul-)Kapselung. Wenn du deine Funktionalität quer durch das Programm und auch noch quer über Programmiersprachen streust, dann ist das nicht die Schuld der Sprache. Auch in C++ muss man die Interna von Qt nicht verstehen, wenn man Qt verwendet. Es ist völlig egal, in welcher Sprache Qt intern implementiert ist, solange es ein C++-API hat für mein C++-Programm. Ron T. schrieb: > Sicher nicht dadurch ein um die andere Sprache aus dem Boden zu stampfen Du tust gerade so, als gäbe es eine globale Verschwörung von Sprachstampfern, die nur darauf aus sind möglichst viele Sprachen zu veröffentlichen, um die Welt in die Knie zu zwingen. Rolf M. schrieb: > Jeder Typ ist also selbst wiederum ein Objekt. Wie soll da eine saubere > Trennung zwischen den beiden funktionieren? Was meinst du mit sauberer Trennung?
Programmierer schrieb: > Mombert H. schrieb: >> Da steht >> niergends das Wort Objekt sondern es ist die Rede von Werten und >> Ausdrücken. > > Naja, Werte sind Objekte (in C++). Ausdrücke geben Werte (Objekte) > zurück. Nein zum ersten Satz und ja zum zweiten, wenn man die Klammer streicht. Aus dem C++17 Standard Draft:
1 | The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is |
2 | created by a definition (6.1), by a new-expression (8.3.4), when implicitly changing the active member of a |
3 | union (12.3), or when a temporary object is created (7.4, 15.2). An object occupies a region of storage in its |
4 | period of construction (15.7), throughout its lifetime (6.8), and in its period of destruction (15.7). [ Note: |
5 | A function is not an object, regardless of whether or not it occupies storage in the way that objects do. |
6 | — end note ] The properties of an object are determined when the object is created. An object can have a |
7 | name (Clause 6). An object has a storage duration (6.7) which influences its lifetime (6.8). An object has a |
8 | type (6.9). Some objects are polymorphic (13.3); the implementation generates information associated with |
9 | each such object that makes it possible to determine that object’s type during program execution. For other |
10 | objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 8) |
11 | used to access them. |
:
Bearbeitet durch User
Mombert H. schrieb: > Nein zum ersten Satz und ja zum zweiten, wenn man die Klammer streicht. > Aus dem C++17 Standard Draft: Hä? "3+7" ist ein Ausdruck. Dieser gibt ein Objekt zurück, und zwar einen Integer mit dem Inhalt "10".
Programmierer schrieb: > Mombert H. schrieb: >> Nein zum ersten Satz und ja zum zweiten, wenn man die Klammer streicht. >> Aus dem C++17 Standard Draft: > > Hä? > > "3+7" ist ein Ausdruck. Dieser gibt ein Objekt zurück, und zwar einen > Integer mit dem Inhalt "10". Woher kommt die Annahme, dass der Ausdruck ein Objekt "gibt"? Und was ist "Inhalt"?
Mombert H. schrieb: > Woher kommt die Annahme, dass der Ausdruck ein Objekt "gibt"? Was soll er sonst zurückgeben? Alle Ausdrücke, die nicht den Typ "void" haben, geben ein Objekt zurück. Die genaue Stelle im Standard habe ich jetzt keine Lust zu suchen. Mombert H. schrieb: > Und was > ist "Inhalt"? Naja, der Wert eines Integers, der durch die Bytes im Speicher repräsentiert und mithilfe des Typs interpretiert wird.
Programmierer schrieb: > Mombert H. schrieb: >> Woher kommt die Annahme, dass der Ausdruck ein Objekt "gibt"? > Was soll er sonst zurückgeben? Alle Ausdrücke, die nicht den Typ "void" > haben, geben ein Objekt zurück. Die genaue Stelle im Standard habe ich > jetzt keine Lust zu suchen. > Mombert H. schrieb: >> Und was >> ist "Inhalt"? > Naja, der Wert eines Integers, der durch die Bytes im Speicher > repräsentiert und mithilfe des Typs interpretiert wird. "Was soll er sonst" ... das was im Standard steht ...
Harald W. schrieb: > > > Und was macht man, wenn man Z erreicht hat? :-) Dann sucht man sich korrupte Nachbarn - und beginnt dort mit Aufräumen
:
Bearbeitet durch User
Im Moment kann man die Sprache noch nicht detailliert bewerten, da sowohl die Spezifikation als auch die Implementierung noch ganz am Anfang stehen. Eine erste produktiv nutzbare Toolchain ist für etwa 2024/2025 anvisiert, aber auch nur dann, wenn rechtzeitig vorher alle noch offenen (und teilweise überhaupt nicht trivialen) Probleme in der Spezifikation gelöst sind. Davon gibt es bereits jetzt sehr viele, und noch viele mehr werden sicherlich hinzukommen. Auf die Schnelle (ich habe nicht alle Dokumente gelesen) sind mir die folgenden Dinge positiv bzw. negativ aufgefallen: Gut: - Wie bei C++, Rust und D steht auch bei Carbon die Abstraktion ohne Performanzeinbußen sowie die Unterstützung der hardwarenahen Programmierung im Vordergrund. - Carbon ist interoperabel mit C++. Dabei kann nicht nur auf Funktionen und globale Variablen, sondern auch auf Typ-/Klassendeklarationen und Templates zugegriffen werden und das sogar bidirektional (C++ <-> Carbon). Das scheint derzeit ein Alleinstellungsmerkmal von Carbon zu sein. - Die Syntax wirkt im Vergleich zu C++ aufgeräumt und übersichtlich. Vieles davon, was in C++ schon in Ordnung war, wurde mehr oder weniger unverändert übernommen, so dass für C++-Programmierer der Umstieg auf Carboin nicht allzu schwer fallen sollte. - Einige wichtige Datentypen, wie bspw. Strings, Tuples, Named Tuples und Tagged Unions sind nativ in der Sprache enthalten und werden durch entsprechende Syntaxelemente unterstützt. - Destructuring Patterns, Pattern Matching in match-case - Anders als in C und C++ haben die bitweisen Operatoren Vorrang vor den Vergleichoperatoren. Damit wird bspw. ioreg & mask == value auch ohne Klammern erwartungsgemäß interpretiert. Interessant in diesem Zusammenhang: Der Operatorvorrang ist, anders als in den meisten anderen Programmiersprachen, keine Total- sondern eine Halbordnung, weswegen für viele Kombinationen von Operatoren (bspw. in a * b % c oder in a and b or c) Klammern zwingend gesetzt werden müssen. Dies erspart einem das Auswendiglernen ellenlanger Vorrangtabellen. Nicht so gut: - Die Interoperabilität hat bereits jetzt schon einige Einschränkungen. Vieles davon lässt sich mit Bridge-Code überwinden, nur ist das halt wieder mit zusätzlicher Arbeit verbunden. Weitere Einschränkungen werden möglicherweise noch hinzukommen, wenn das C++-Komitee mal wieder den Turbo aufdreht und uns mit tausend neuen Features von zweifelhaftem Nutzen beglückt ;-) - Es scheint (wie auch in C und C++) keinen Potenzoperator zu geben. Allgemein: Wenn das mit der Interoperabilität tatsächlich so gut klappt, dass etwa 95% des in Firmen und Open-Source-Projekten bestehenden C++-Codes direkt, und die restlichen 5% mit minimalem Anpassungsaufwand in Carbon-Projekte übernommen werden können, würde ich Carbon als einen recht aussichtsreichen C++-Nachfolger sehen. Der Erfolg von C++ liegt vor allem darin begründet, dass es wegen seiner (weitgehenden) Abwärtskompatibilität zu C einen sanften Übergang von C ermöglichte. Ähnlich sanft wäre auch der Übergang von C++ nach Carbon, was diesem einen deutlichen Vorteil gegenüber Rust und D bescheren würde. Die Realisierung der Interoperabilität scheint aber keine triviale Aufgabe zu sein, was dazu führen könnte, dass vielleicht nur 70% des bestehenden C++-Codes ohne Zusatzaufwand weitergenutzt werden kann. Sollte dieser Fall eintreten, würde das die Akzeptanz von Carbon stark hemmen. Auch bei der derzeit noch frisch aussehenden Syntax von Carbon könnten – um die Ähnlichkeit mit der C++-Syntax nicht komplett über Bord zu schmeißen – zukünftig Probleme (bspw. durch Mehrdeutigkeiten) auftreten, die letztendlich zu einem zusammengewürfelten Kompromiss führen wie wir ihn mit C++ jetzt schon haben. Spätestens dann wird sich jeder die Frage stellen, welchen Nutzen die Einarbeitung in die neue Sprache überhaupt noch hat. Auf jeden Fall halte ich Carbon für ein interessantes Projekt, das ich auf meiner Beobachtungsliste halten werde.
Yalu X. schrieb: > - Es scheint (wie auch in C und C++) keinen Potenzoperator zu geben. Ich denke, dass wir damit gut leben können, wenn der Rest funktioniert ;-)
MaWin schrieb: > Außerdem kann man die allermeisten Programmiersprachen relativ schnell > erlernen. Grob die Synthax. Und auch das nur, wenn es Ähnlichkeiten zwischen Sprachen gibt. Wie willst du schnell z.B. Java oder C++ erlernen? Java hat bestimmt 5000 Klassen. Und dann hat jede Klasse 10, 20 Methoden. Wie soll man das schnell erlernen?! Java und C++ haben eigene Libs zur Zeitverwaltung. Sogar C liefert dazu eine Bibliothek. Kannst du aus dem Kopf ein Programm schreiben, welches für ein bestimmtes Datum (12.06.1925) den Wochentag (Montag, Dienstag, Mittwolch, ...) ausgibt? Und das in allen Sprache, die du "relativ schnell gelernt" hast? Nein, das kannst du nicht.
Bis jetzt besteht Carbon ja nur aus ganz viel "wir wollen das ganz toll machen" und wenig Konkretes. Dafür wird darüber ziemlich viel geredet und "die Community" soll es irgendwie richten. Auf der technischen Seite bringt es kaum was Neues. Carbon will sich zu C++ wie Typescript zu Javascript vergleichen. Das halte ich etwas ambitioniert. Typescript hat Javascript ein modernes Typsystem hinzugefügt. C++ hat schon ein Typsystem. Schielt man zu Rust, gibt es da z.B. einen ganz anderen Ansatz mit Speicher und Referenzen umzugehen. D.h. diese Sprachen haben merkliche Verbesserungen eingeführt. Bei Kotlin ist es z.B. der Klassiker, dass ein Unternehmen mit Marktmacht die Sprache für Android bestimmt hat. D.h. Carbon hat nicht wirklich irgendein neues "Killer-Feature" das irgendwie spannend ist oder ein grundlegendes Problem löst und keine Schlüsselanwendung. Es soll einfach nur C++ ersetzen, einfach so, ohne weiteren Grund. Ich halte die "Kompatibilität" zu C++ auch eher minderwichtig. Jede Software-Komponente, die irgendwie den Garten ihrer eigener Programmiersprache verlassen will, braucht und hat genau ein Interface, nämlich den C-Call-Standard. Und das Problem, das Carbon irgendwie immer dem (unbeliebten) C++-Standard nachrennen muss, macht es auch nicht besser. Das alles zusammen lässt mich zur Prognose hinreißen: Stand heute hat Carbon keine signifikante Zukunft. Carbon wird nicht verschwinden und irgendwo wird es vor sich hin leben, so wie hunderte andere Programmiersprachen. Zu mehr reicht es aktuell aber nicht. Einfach nur "Wir mach das jetzt anders, damit es anders ist", reicht nicht.
können jedem das Genick brechen schrieb: > Sogar C liefert dazu > eine Bibliothek. Kannst du aus dem Kopf ein Programm schreiben, welches > für ein bestimmtes Datum (12.06.1925) den Wochentag (Montag, Dienstag, > Mittwolch, ...) ausgibt? Und das in allen Sprache, die du "relativ > schnell gelernt" hast? Nein, das kannst du nicht. Lernst du solche Details auswendig?
Ein anderer Programmierer schrieb: > Bis jetzt besteht Carbon ja nur aus ganz viel "wir wollen das ganz toll > machen" und wenig Konkretes. Dafür wird darüber ziemlich viel geredet > und "die Community" soll es irgendwie richten. Wo genau ist das Problem damit? Ein anderer Programmierer schrieb: > Auf der technischen Seite bringt es kaum was Neues. Braucht C++ etwas "Neues"? Wenn ja, was? Ein anderer Programmierer schrieb: > Es soll einfach nur C++ ersetzen, einfach so, ohne > weiteren Grund. Ich sehe das Beseitigen von Altlasten als sehr sehr sehr guten Grund an. Ein anderer Programmierer schrieb: > das Carbon irgendwie immer > dem (unbeliebten) C++-Standard nachrennen muss, macht es auch nicht > besser. Woher weißt du das? Hast du es ausprobiert?
MaWin schrieb: > Ron T. schrieb: >> Aber es ist doch klar daß sich das Angebot von Programmierern für eine >> bestimmte Sprache bei immer mehr verwendeten Sprachen zwangsläufig >> verkleinert Dass mehr Sprachen das Angebot an Programmierern zwangsläufig verkleinern sehe ich auch nicht, da Sprachen auch wieder aus der Mode kommen. Die Mehrheit derer, die irgendwann mal z.B. Fortran, Basic, Perl oder Pascal programmiert hat, wird heute eine andere Sprache nutzen. > Nein. Wieso? > Ist es verboten mehr als zwei Sprachen zu beherrschen? Man kann (imho sollte) mehrere Sprachen zumindest kennen. > Außerdem kann man die allermeisten Programmiersprachen relativ schnell > erlernen. Das ist imho falsch, von C-Programmierern hört man ähnliches aber relativ häufig. Das liegt daran, dass viele C-Konstrukte auch in anderen Sprachen vorhanden sind. Die lernen dann die neue Syntax für diese Konstrukte und haben damit die neue Sprache "gelernt". Daher kommt der Spruch: "Ein C-Programmierer kann in jeder Sprache C programmieren." Für einen idiomatischen Programmierstil, der Sprachkonstrukte in der Art und Weise verwendet, wie es in der Sprache üblich ist, wird man deutlich länger brauchen. Aber ein bischen Wahrheit ist trotzdem dran. Wer eine imperative objektorientierte Sprache beherrscht, der sollte sich in anderen imperativen objektorientierten Sprachen einigermaßen zurechtfinden. *Aber zurück zu Carbon:* C++ hat viele syntaktische Altlasten. Und ich stimme yalu zu, Carbon hat viele gute Ansätze. Ich bin aber trotzdem sehr skeptisch, ob Carbon eine große Anhängerschaft (vergleichbar mit z.B. Rust) finden wird. Gründe: * Ich vermute, C++ Programmierer nehmen die C++ Probleme nicht wirklich wahr. * Es gibt auch nicht das Gefühl, man wäre mit C++ in einer Sackgasse. Es gab ja bei C++ in den letzten Jahren immer wieder substantielle Verbesserungen, sogar mit Abwärtskompatibilität. * ich bin mir auch nicht sicher bezüglich der Leute, die hinter Carbon stehen: Haben die den langen Atem? Gibt es eine Organisation die Geld in die Hand nimmt um die Sprache zu bewerben? Oder um Konferenzen abzuhalten? Im relativ weit oben verlinkten Video gibt es Vergleichsbeispiele und ich möchte TypeScript als Evolution zu Javascript herausgreifen. Da war fast alles anders als hier mit Carbon zu C++: * In JavaScript gibt es so viele Probleme, dass selbst der Spracherfinder ein Buch "Java Script - the good parts" schreiben musste. * es war einigermaßen absehbar, dass viele der Probleme in JavaScript auch in zukünftigen Versionen nicht verschwinden würden. * Microsoft (der Erfinder von TypeScript) hat in das passende Tooling investiert und die Sprache beworben. Zudem zeigten sie sich offen für Verbesserungsvorschläge aus der Community. Ich sehe für Carbon 3 Möglichkeiten: 1. Die Sprache wird in der Versenkung verschwinden und längerfristig keine breite Anwendung finden. 2. Günstigstenfalls werden einige der Ideen in einen zukünftigen C++ Standard aufgenommen. 3. Ich irre mich und Carbon wird im C++-Universum groß und wichtig.
können jedem das Genick brechen schrieb: > Wie willst du schnell z.B. Java oder C++ erlernen? Java hat bestimmt > 5000 Klassen. Und dann hat jede Klasse 10, 20 Methoden. Wie soll man das > schnell erlernen?! Die braucht man mit Sicherheit nicht alle direkt am ersten Tag. Mir ist bewusst, dass die vollständige Lernphase für eine halbwegs komplexe Programmiersprache lebenslang dauert. Man ist jedoch bei praktisch allen Sprachen bereits nach wenigen Wochen Einsatzbereit für die ersten Programmiertätigkeiten. > Kannst du aus dem Kopf ein Programm schreiben, welches > für ein bestimmtes Datum (12.06.1925) den Wochentag (Montag, Dienstag, > Mittwolch, ...) ausgibt? Und das in allen Sprache, die du "relativ > schnell gelernt" hast? Nein, das kannst du nicht. Nein, ich kann tatsächlich nicht ad-hoc jedes erdenkliche Programmierproblem lösen. In keiner Sprache. Das habe ich auch nie behauptet.
Tilo R. schrieb: > * ich bin mir auch nicht sicher bezüglich der Leute, die hinter Carbon > stehen: Haben die den langen Atem? Gibt es eine Organisation die Geld in > die Hand nimmt um die Sprache zu bewerben? Oder um Konferenzen > abzuhalten? Der Typ, der den Vortrag auf der cpp North hält (das verlinkte Video) ist Chandler Carruth Leiter der C++, Clang und LLVM Teams bei Google. Und von der github Seite:
1 | Who pays for Carbon's infrastructure? |
2 | Carbon is currently bootstrapping infrastructure with the help of Google. As soon as a foundation is ready to oversee infrastructure, such as continuous integration and the CLA, we plan to transfer them so they are run by the community. |
Google steckt also schonmal etwas Geld und Zeit in das Projekt.
Yalu X. schrieb: > Nicht so gut: Du hast noch vergessen: - Muss die alten Probleme zu Memory- und Threadsafety wegen der eng verzahnten Interoperabilität mit C/C++ weiterhin mitschleppen. > Ähnlich sanft wäre auch der Übergang von C++ nach Carbon, > was diesem einen deutlichen Vorteil gegenüber Rust und D bescheren > würde. Das sehe ich nicht so. API-Wrapper sehe ich nicht als Problem. Die sind relativ einfach zu entwickeln und oft sogar autogenerierbar. Diese Wrapper sehe ich eher als Vorteil, weil sie eine ganz exakt und bewusst definierte Schnittstelle sind, statt einfach automatisch "alle" Typen, Strukturen, Funktionen und Variablen über die Sprachgrenze hinweg bereitzustellen. Ich glaube auch nicht, dass das überhaupt so allgemeingültig geht. Bei zwei Sprachen, die sich hinreichend voneinander unterscheiden, wird es zwangsläufig Dinge geben, die man nicht automatisch intersprachlich übergeben kann, oder die nicht eindeutig zuordbar sind. Da wird es immer starke Einschränkungen geben, was einen dann schlussendlich doch zu Wrappercode zwingt.
MaWin schrieb: > Muss die alten Probleme zu Memory- und Threadsafety wegen der eng > verzahnten Interoperabilität mit C/C++ weiterhin mitschleppen. Welche Probleme sind das? Das Threading und Speichermodell wurden für C++11 überhaupt erst definiert. Das war so gut, dass C das direkt übernommen hat, und Java in abgeschwächter Form auch. Was möchte man da nicht mitschleppen? Klar ist das Speichermodell von C++ sehr komplex, aber das braucht man halt wenn es maximal effizient sein soll. Den Anspruch hat Carbon doch auch?
Programmierer schrieb: > Was möchte man da nicht mitschleppen? Schrub ich doch. Die nicht vorhandene Memory- und Threadsafety.
MaWin schrieb: > Programmierer schrieb: > >> Was möchte man da nicht mitschleppen? > > Schrub ich doch. Die nicht vorhandene Memory- und Threadsafety. Hä? Seit C++11 ist sie vorhanden, in so ziemlich maximal möglicher Ausführung.
Programmierer schrieb: > Hä? Seit C++11 ist sie vorhanden, Wenn der Programmierer sie denn verwendet. > in so ziemlich maximal möglicher Ausführung. Ja. In für *C++* maximal möglicher Ausführung. Das ist genau mein Kritikpunkt. Das wird nicht besser, wenn man "seamless integration" anstrebt in Carbon. Es wird dieses Manko erben.
MaWin schrieb: > Programmierer schrieb: >> Hä? Seit C++11 ist sie vorhanden, > > Wenn der Programmierer sie denn verwendet. > >> in so ziemlich maximal möglicher Ausführung. > > Ja. In für *C++* maximal möglicher Ausführung. Das ist genau mein > Kritikpunkt. > Das wird nicht besser, wenn man "seamless integration" anstrebt in > Carbon. Es wird dieses Manko erben. Ich sehe nicht so ganz warum die Interaktion von Carbon mit C++ ein größeres Problem sein soll als die Interaktion von anderen Sprachen mit C (z.B. rust).
:
Bearbeitet durch User
MaWin schrieb: > Ja. In für *C++* maximal möglicher Ausführung. Das ist genau mein > Kritikpunkt. > Das wird nicht besser, wenn man "seamless integration" anstrebt in > Carbon. Es wird dieses Manko erben. Naja, ich finde es gut dass C++ hier alle Möglichkeiten bietet und man wirklich effiziente Software schreiben kann. Insbesondere ist es auch auf Portabilität ausgelegt, sodass es die Details von anderen Plattformen, die z.B. eine schwächere Cache-Kohärenz bieten als x86, effizient ausnutzen kann. Das kann z.B. Java nicht (in der Effizienz). Man kann es ja auch in Form von Libraries nutzen, welche die fiesen Details kapseln. Libs für Lock-Less (via atomics) Queues wären da z.B. sehr interessant. Das Ganze dann noch mithilfe von Carbon in eine schönere Syntax verpackt fände ich nicht verkehrt.
Mombert H. schrieb: > Ich sehe nicht so ganz warum die Interaktion von Carbon mit C++ ein > größeres Problem sein soll als die Interaktion von anderen Sprachen mit > C (z.B. rust). Ja, wir wissen bereits, dass du keine Ahnung von Rust hast. Das hast du im Rust-Thread bereits ausführlich dargelegt. Memory-Safety muss an der C-Schnittstelle von Unsafe-Rust explizit vom Entwickler sichergestellt werden. Das geht nicht automatisch/seamless. Da Carbon aber offenbar diese praktisch unsichtbare Schnittstelle bereitstellen will, muss es die Memory-Safety-Probleme genau dort zum Großteil erben. Und das ist ganz einfach ein Nachteil. Memory-Safety ist seit 20 Jahren in neuen Hochsprachen Standard. Und mit Rust hat es endlich auch in die Domäne der System-Level-Hochsprachen Einzug erhalten. Jetzt kann man sagen, dass das einen bei Carbon nicht stört. Und das ist auch Ok. Aber es ist eine Funktionalität, die Carbon nicht bieten können wird.
Programmierer schrieb: > Naja, ich finde es gut dass C++ hier alle Möglichkeiten bietet und man > wirklich effiziente Software schreiben kann. Insbesondere ist es auch > auf Portabilität ausgelegt, sodass es die Details von anderen > Plattformen, die z.B. eine schwächere Cache-Kohärenz bieten als x86, > effizient ausnutzen kann. Das kann z.B. Java nicht (in der Effizienz). > > Man kann es ja auch in Form von Libraries nutzen, welche die fiesen > Details kapseln. Libs für Lock-Less (via atomics) Queues wären da z.B. > sehr interessant. Das alles bringt leider nur bedingt etwas, wenn der Compiler es nicht erzwingen kann. So werden wir die CVE-Flut der letzten Jahrzehnte nicht eindämmen können.
Rein optisch sieht Carbon aus, wie wenn man C++ hätte Rosten lassen. (Es errinnert etwas an Rust, wenn auch nur rein optisch). Vielleicht ist sie nur als eine art Einstiegsdroge für Rust gedacht? Vermutlich einfacher zum anfangen, aber weniger Nachfrage. Später, bei rust denkt man dann "oh, das sieht bekannt aus", und fängt an es zu lernen? Ich mag, dass des weiterhin deklarationen und header gibt (auch wenn die etwas anders funktionieren als in C++). Ausserdem sehe ich immer gerne, wenn eine Sprache ein interface keyword hat. Ich liebe Interfaces, in allen Farben und Formen! Async haben sie glaube ich (noch) nicht? Das ist schade. Für eine moderne derartige Sprache ist async eigentlich ein muss... Insgesammt überzeugt es mich noch nicht.
MaWin schrieb: > Memory-Safety ist seit 20 Jahren in neuen Hochsprachen Standard. Und mit > Rust hat es endlich auch in die Domäne der System-Level-Hochsprachen > Einzug erhalten. Die Logik verstehe ich nicht. C++ ist seit 11 Jahren Memory-Safe. MaWin schrieb: > Das alles bringt leider nur bedingt etwas, wenn der Compiler es nicht > erzwingen kann. Was meinst du mit erzwingen? Kann man woanders einen komplexen Algorithmus welcher sich auf Atomics und Memory Order verlässt sicher (!) statisch prüfen? Genau solche Algorithmen möchte C++ ermöglichen, denn welche Sprache kann das sonst bieten? Assembler? Nicht besonders portabel! MaWin schrieb: > So werden wir die CVE-Flut der letzten Jahrzehnte nicht eindämmen > können. Dafür ist C++ sowieso nicht gemacht und Carbon ebenso nicht. "Gewöhnliche" Anwendungslogik einfach multithreading-sicher machen geht dann in Java, Rust, Erlang oder über Libraries die das in ein High-Level-API verpacken.
Programmierer schrieb: > C++ ist seit 11 Jahren Memory-Safe. Nein. Nur der Teil von C++, der memory-safe ist, ist memory-safe. Wenn der Entwickler das (versehenlich) nicht verwendet, dann bringt das wenig. Und das geht schnell. Vector per operator[] zugegriffen? Schwupps ist das Programm nicht mehr memory-safe. Es gibt tausende weitere Falltüren. Programmierer schrieb: > Was meinst du mit erzwingen? Kann man woanders einen komplexen > Algorithmus welcher sich auf Atomics und Memory Order verlässt sicher > (!) statisch prüfen? Memory Order nicht. Aber Atomics schon. Rust kann Memory- und Threadsafety zu 99% statisch prüfen. Aber es geht hier nicht um Rust, deshalb führe ich das nicht weiter aus. Es geht hier aber um Carbon und darum, dass es dies nicht bietet und IMO auch niemals bieten kann. > Genau solche Algorithmen möchte C++ ermöglichen, Auch C++ kann bei Memory Order nicht helfen. Das ist alleine dem Programmierer überlassen. Es bietet lediglich die Primitive an. > Dafür ist C++ sowieso nicht gemacht und Carbon ebenso nicht. Ok. Dann sind wir uns ja 100% einig. ;)
MaWin schrieb: > Und das geht schnell. Vector per operator[] zugegriffen? Schwupps ist > das Programm nicht mehr memory-safe. Es gibt tausende weitere Falltüren. Das ist der Preis für die Flexibilität und Effizienz. Übrigens haben die allermeisten Sprachen dort keine Sicherung, Java auch nicht. MaWin schrieb: > Memory Order nicht. Aber Atomics schon. > Rust kann Memory- und Threadsafety zu 99% statisch prüfen. In C++ kann man eben alles nutzen, was die Maschine bietet. Der Preis ist eben, dass sich nicht alles sicher statisch prüfen lässt. Das ist nunmal schon immer das Konzept von C++. Rust ist eh eher die Ausnahme dass es so etwas prüft - wenn nichtmal Java das kann, braucht es so eine "Kindersicherung" auch nicht unbedingt für C++. MaWin schrieb: > Es geht hier aber um Carbon und darum, dass es dies nicht bietet und IMO > auch niemals bieten kann. Ich denke das soll es auch gar nicht. Es bietet eben genau das was auch C++ bietet, mit anderer Syntax. MaWin schrieb: > Auch C++ kann bei Memory Order nicht helfen. Das ist alleine dem > Programmierer überlassen. Es bietet lediglich die Primitive an. Logisch, man muss schon wissen wie man sie nutzt.
MaWin schrieb: > Mombert H. schrieb: >> Ich sehe nicht so ganz warum die Interaktion von Carbon mit C++ ein >> größeres Problem sein soll als die Interaktion von anderen Sprachen mit >> C (z.B. rust). > Ja, wir wissen bereits, dass du keine Ahnung von Rust hast. > Das hast du im Rust-Thread bereits ausführlich dargelegt. Was habe ich an dieser Stelle nicht verstanden? Sei bitte mal konkret. > Memory-Safety muss an der C-Schnittstelle von Unsafe-Rust explizit vom > Entwickler sichergestellt werden. Das geht nicht automatisch/seamless. Habe ich etwas anderes behauptet? Die C Bibliothek bleibt aber unsicher. Der rust Programmierer hat nur die Möglichkeit sie mit "unsafe" zu nutzen oder sie nicht zu nutzen. Wer sagt, dass das in Carbon anders sein wird? Und da C++ von Carbon vollständig verstanden wird, könnte Carbon selbstständig alles in C++ identifizieren, was unsicher ist.
Programmierer schrieb: > Das ist der Preis für die Flexibilität und Effizienz. Nein, ist es nicht. Siehe Rust. > Java auch nicht. Ich kenne Java jetzt nicht im Detail, aber ich kann mir kaum vorstellen, dass Java dann eine memory corruption und/oder UB macht. Eine Exception ist memory-safe. > Ich denke das soll es auch gar nicht. Es bietet eben genau das was auch > C++ bietet, mit anderer Syntax. Ja, das weiß ich. Und ich halte es für einen riesigen Nachteil und nicht mehr zeitgemäß. > Der rust Programmierer hat nur die Möglichkeit sie mit "unsafe" zu > nutzen oder sie nicht zu nutzen. Blödsinn. Um unsafe-APIs werden safe-Wrapper gebaut.
MaWin schrieb: >> Der rust Programmierer hat nur die Möglichkeit sie mit "unsafe" zu >> nutzen oder sie nicht zu nutzen. > Blödsinn. > Um unsafe-APIs werden safe-Wrapper gebaut. Du redest nur von der API. Mit diesem Wrapper kannst du nicht sicher machen was in der Blibliothek passiert. Sichere Wrapper für eine unsichere API kann man in nahezu jeder Sprache bauen. Das gleiche trifft erstmal für Carbon zu. Wenn du anderer Meinung bist, dann liefere mal eine etwas konkretere Erläuterung.
:
Bearbeitet durch User
Mombert H. schrieb: > Sichere Wrapper für eine > unsichere API kann man in nahezu jeder Sprache bauen. Nein. Nicht vom Compiler statisch oder dynamisch geprüfte sichere Wrapper. Das geht nur in Sprachen, die eine solche Prüfung unterstützen. Und darum geht es mir. Es geht mir nicht um optionale sichere Konstrukte. Die kann man auch in C implementieren.
MaWin schrieb: > Mombert H. schrieb: >> Sichere Wrapper für eine >> unsichere API kann man in nahezu jeder Sprache bauen. > Nein. Nicht vom Compiler statisch oder dynamisch geprüfte sichere > Wrapper. Das geht nur in Sprachen, die eine solche Prüfung unterstützen. > Und darum geht es mir. Es geht mir nicht um optionale sichere > Konstrukte. Die kann man auch in C implementieren. Dann versuch bitte in Zukunft mal zu schreiben was du wirklich meinst. Dann verstehen dich andere Menschen auch. Oder brauchst du einen Browser, der dich dazu zwingt?
MaWin schrieb: > Programmierer schrieb: >> Das ist der Preis für die Flexibilität und Effizienz. > > Nein, ist es nicht. Siehe Rust. Ich dachte Rust kann auch nicht alles prüfen an der Memory Order. MaWin schrieb: > Ich kenne Java jetzt nicht im Detail, aber ich kann mir kaum vorstellen, > dass Java dann eine memory corruption und/oder UB macht. Doch. Du kannst fröhlich von mehreren Threads auf Datenstrukturen zugreifen und es passiert "irgendwas". Integer-Zugriffe sind zwar atomic, aber die Reihenfolge ist auch nicht garantiert. MaWin schrieb: > Ja, das weiß ich. Und ich halte es für einen riesigen Nachteil und nicht > mehr zeitgemäß. Dann gibt es aber nicht viele zeitgemäße Sprachen!
Programmierer schrieb: > Ich dachte Rust kann auch nicht alles prüfen an der Memory Order. Ja. Und? Das widerspricht sich doch nicht. Memory Order hat nichts mit Memory-Safety oder Thread-Safety zu tun. > Integer-Zugriffe sind zwar > atomic, aber die Reihenfolge ist auch nicht garantiert. Also ist es Memory-Safe. Dann ist ja alles Ok. > Dann gibt es aber nicht viele zeitgemäße Sprachen! Doch. Fast alles, was in diesem Jahrtausend entwickelt wurde und einige frühere.
MaWin schrieb: > Programmierer schrieb: >> Ich dachte Rust kann auch nicht alles prüfen an der Memory Order. > > Ja. Und? Das widerspricht sich doch nicht. > Memory Order hat nichts mit Memory-Safety oder Thread-Safety zu tun. Aha. Ohne Memory-Order kann man manche nebenläufige Algorithmen und Datenstrukturen aber nicht umsetzen. MaWin schrieb: >> Integer-Zugriffe sind zwar >> atomic, aber die Reihenfolge ist auch nicht garantiert. > > Also ist es Memory-Safe. > Dann ist ja alles Ok. Man kann sich in Java trotzdem wunderbar einen Deadlock bauen, oder Race-Conditions bei Zugriffen auf Datenstrukturen. Nicht umsonst hat Java die üblichen Primitive wie Mutexe und Semaphoren. Deren Verwendung aber nicht im Geringsten statisch geprüft wird. In Java ein threadsicheres Singleton zu bauen ist eine lustige Knobelei. Was ist daran sicher? C++ auf ARM (und ich glaube auch x86) hat bei Integern zufällig sogar die gleiche Garantie, da sind korrekt alignte 8-32bit Integer-Einzel-Zugriffe auch immer atomic. Nur die Read-Modify-Write-Zyklen nicht, in Java aber auch nicht. MaWin schrieb: >> Dann gibt es aber nicht viele zeitgemäße Sprachen! > > Doch. Fast alles, was in diesem Jahrtausend entwickelt wurde und einige > frühere. Dann bin ich gespannt welche das sind und wie die statische Prüfung funktioniert.
Programmierer schrieb: > Aha. Ohne Memory-Order kann man manche nebenläufige Algorithmen und > Datenstrukturen aber nicht umsetzen. Richtig. > Man kann sich in Java trotzdem wunderbar einen Deadlock bauen, oder > Race-Conditions bei Zugriffen auf Datenstrukturen. Korrekt. All dies ist Memory-Safe. > Dann bin ich gespannt welche das sind und wie die statische Prüfung > funktioniert. Ich habe nicht behauptet, dass die Prüfung statisch sein muss. Lediglich, dass sie vorhanden sein sollte.
Programmierer schrieb: > Na dann ist C++ auch memory safe. Glück gehabt! Du hast es leider nicht verstanden. Sind Data Races in C++ möglich? Ja? Dann ist es nicht Memory Safe.
MaWin schrieb: > Programmierer schrieb: >> Na dann ist C++ auch memory safe. Glück gehabt! > Du hast es leider nicht verstanden. > Sind Data Races in C++ möglich? Ja? Dann ist es nicht Memory Safe. Nein sind sie nicht.
In jeder Sprache gibt es Möglichkeiten Unfug zu treiben. Was ich aber absolut nicht verstehe ist wieso schon wieder jemand mit einer neuen Sprache ankommt. Fast alles was die meisten super tollen Sprachen der letzten Jahre angeblich haben ist in pascal seit Anfang an drin bzw wurde da vor mehr als 30 Jahren eingebaut (Objekte). Ich musste mich den Kunden anpassen und c lernen sonst würde ich bestimmt noch heute alles in pascal machen.
Dirk schrieb: > Fast alles was die meisten super tollen > Sprachen der letzten Jahre angeblich haben ist in pascal seit Anfang an > drin Ziemlicher Unfug.
Na dann klär mich mal auf. Vielleicht habe ich ja was wichtiges verpasst.
MaWin schrieb: > Yalu X. schrieb: >> Nicht so gut: > > Du hast noch vergessen: > - Muss die alten Probleme zu Memory- und Threadsafety wegen der eng > verzahnten Interoperabilität mit C/C++ weiterhin mitschleppen. Dazu kann ich nicht viel sagen. Da muss man wohl abwarten, was den Carbon-Entwicklern in Zukunft noch dazu einfällt. Natürlich wird Carbon-Code, in den fehlerhafter C++-Code eingebunden wird, als Ganzes ebenfalls fehlerhaft sein. Das ist aber nicht anders, wenn derselbe fehlerhafte C++-Code in Rust eingebunden wird. >> Ähnlich sanft wäre auch der Übergang von C++ nach Carbon, >> was diesem einen deutlichen Vorteil gegenüber Rust und D bescheren >> würde. > > Das sehe ich nicht so. > API-Wrapper sehe ich nicht als Problem. Die sind relativ einfach zu > entwickeln und oft sogar autogenerierbar. Hmm, ich weiß nicht. Wie schreibst du in Rust einen API-Wrapper für eine stark template-lastige C++--Bibliothek, wie sie bspw. in Boost häufig anzutreffen ist? > Diese Wrapper sehe ich eher als Vorteil, weil sie eine ganz exakt und > bewusst definierte Schnittstelle sind, statt einfach automatisch > "alle" Typen, Strukturen, Funktionen und Variablen über die Sprachgrenze > hinweg bereitzustellen. Es sind ja nicht alle, sondern nur die im API des jeweiligen C++-Moduls, also typischerweise in einem C++-Header-File definierten. Von denen möchte man auch keine weglassen, den sonst wäre ja das API nur unvollständig umgesetzt und damit – wenn überhaupt – nur eingeschränkt nutzbar. > Ich glaube auch nicht, dass das überhaupt so allgemeingültig geht. Es gibt tatsächlich Einschränkungen, aktuell beschränken sich diese aber nur auf RTTI und Exceptions. Die Carbon-Entwickeln begründen den Verzicht auf die genannten Features damit, dass diese die Performanz negativ beeinflussen und auch in C++ ohnehin nur selten benutzt werden. Ich kann mir aber durchaus vorstellen (das habe ich ja in meinem obigen Beitrag schon geschrieben), dass in Zukunft weitere Probleme und damit weitere Einschränkungen der Interoperabilität auftreten werden. Da möchte ich aber nicht vorweg greifen und bin gespannt, wie die Carbon-Entwickler das alles in den Griff bekommen :) > Da wird es immer starke Einschränkungen geben, was einen dann > schlussendlich doch zu Wrappercode zwingt. Wenn in ganz wenigen Ausnahmefällen Wrapper-Code geschrieben werden muss, wird dies auch sicher akzeptiert werden. Als ich im obigen Beitrag von einem "sanften Übergang" schrieb, hatte ich nicht mein Einmannhobbysoftwarelabor, sondern eine Softwarefirma oder eine größere Entwicklergruppe im Hinterkopf, die bisher auf C++ setzt und darin bereits eine große, in mehreren Softwareprodukten verwendete Code-Basis aufgebaut hat, und nun darüber nachdenkt, von C++ auf eine modernere Programmiersprache umzusteigen. Für die meisten der neueren Sprachen (einschließlich Rust) bedeutet dies: - Alle beteiligten Programmierer sollten sich bis zum Start der Migration in die neue Sprache eingearbeitet haben. - Die bestehende Code-Basis muss – wo dies möglich ist – gewrappt werden, um sie weiterverwenden zu können. - Wo Wrapper unmöglich oder mit vertretbarem Aufwand nicht praktikabel sind, muss der jeweilige C++-Code in die neue Sprache umgeschrieben werden. Das alles ist u.U. gar kein großes Problem, und der Aufwand, der in die Migration gesteckt wird, amortisiert sich durch die höhere Produktivität der neuen Sprache möglicherweise schon nach kurzer Zeit. Allerdings kann das im Voraus nicht hundertprozentig garantiert werden. Nichts fürchten Verantwortliche in der professionellen Softwareentwicklung mehr, als wenn durch eine solche Migration die Entwicklung für unbestimmte Zeit nahezu zum Erliegen kommt. Ein Umstieg auf Carbon hingegen bedeutet: - Die beteiligten Programmierer können sich nach und nach in die neue Sprache einarbeiten. Ein paar Neophile machen den Anfang, der Rest zieht später nach und erhält dabei Unterstützung durch die bereits Eingearbeiteten. - Diejenigen, die vorerst weiterhin in C++ programmieren, achten darauf, keine C++-Features zu nutzen, die die Interoperabilität einschränken könnten. - Die bestehende Code-Basis kann zu großen Teilen ohne Zusatzaufwand direkt weiterverwendet werden. - Nur für die wenigen Teile, für die dies nicht möglich ist, muss Wrapper-Code geschrieben oder der bestehende Code in Carbon umgeschrieben werden. Der eigentliche Softwarentwicklungprozess wird dadurch nicht angehalten (schon gar nicht auf unbestimmte Zeit), sondern höchstens etwas verlangsamt, was von den Verantwortlichen aber eher akzeptiert wird. Das ist der Grund dafür, dass ich für Carbon – natürlich nur unter der Voraussetzung, dass die Carbon-Entwickler ihre angekündigten Ziele auch tatsächlich erreichen – höhere Chancen sehe, längerfristig C++ beerben zu können, als für Rust, D oder andere vergleichbare Sprachen. Damit du mich nicht falsch verstehst: Auch wenn ich Carbon als ein interessntes Projekt empfinde und es aus meiner Sicht die genannten Vorteile hat, würde ich persönlich Rust gegenüber Carbon (u.a. aus den Gründen, die du schon genannt hast) ganz klar vorziehen. Ich bin aber weder ein hauptberuflicher Softwareentwickler in einer größeren Entwicklergruppe noch ein Verantwortlicher in einer Softwarefirma, weswegen meine Meinung diesbezüglich kein großes Gewicht hat :) Noch etwas zur Safety vs. C++Interoperabilität: Wie du richtig erkannt hast, lässt sich beides nur schwer unter einen Hut bringen. Rust legt den Schwerpunkt auf Safety, Carbon auf Interoperabilität. Beide haben auch das jeweils andere Ziel im Auge, werden es aber weniger gut erreichen als das jeweils primäre Ziel. Beide gehen deswegen unterschiedlich an die Sache heran: Zitat von den Carbon-Entwicklern: "The difference between Rust's approach and Carbon's is that Rust starts with safety and Carbons starts with migration." Carbon sieht sich auch nicht als Konkurrenz zu Rust: Zitat von den Carbon-Entwicklern: "If you can use Rust, ignore Carbon"
Yalu X. schrieb: > Zitat von den Carbon-Entwicklern: > > "If you can use Rust, ignore Carbon" Oh, wow, dann lag ich ja richtig. Hätte ich nicht gedacht, dass die das gleich selbst sagen.
Yalu X. schrieb: > Dazu kann ich nicht viel sagen. Gemessen an diesem Satz ist aber dein Beitrag ziemlich weitschweifig ausgefallen. Aber mal zur gewünschten Einschätzung: Ich sag nur, daß es mal wieder eine neue Geschmacksrichtung von C ist. Nicht mehr. W.S.
W.S. schrieb: > Ich sag nur, daß es mal wieder eine neue Geschmacksrichtung von C ist. > Nicht mehr. Natürlich wäre dir eine neue Geschmacksrichtung von Pascal lieber gewesen ;-)
Yalu X. schrieb: > Natürlich wäre dir eine neue Geschmacksrichtung von Pascal lieber > gewesen ;-) Also irgendwie fühlst du dich angepiekst - da hilft auch ein drangesetztes "Grinsen" nix. Und ob und was ich lieber hätte, gehört nicht zum Thema. Also bleibe auch du beim Thema. Zur Sache selbst meine ich, daß man durchaus bei der Sache (hier eben normales C) bleiben kann. Alles andere sind Programmierübungen von frustrierten C-Programmierern, um speziell eben DAS zu verschlimmbessern, was ihnen im Moment störend vorkommt. Und deshalb sind solche immer wieder anzutreffenden Geschmacksrichtungen von C eben im Grunde Eintagsfliegen. Sowas endet in einer kleinen Gruppe von Fans, die exakt denselben Geschmack haben und dennoch nicht die Kraft oder den Willen, die Nase mal aus ihrer Furche zu erheben. Mich erinnert das an die amerikanischen "Schlitten" der Fünfziger: dieselben zu popligen Bremsen wie anno dunnemals, dieselben viel zu großvolumigen und schlecht konstruierten Motoren, aber jedes Jahr größere und ausladendere Kotflügel und Kühler in Form der Akropolis. W.S.
Mombert H. schrieb: > dass die Schöpfer selbst Carbon als ein Experiment sehen und nicht > wissen, ob es die Zukunft von C++ ist Das ist ja eher nicht der Anspruch wenn man eine neue Sprache entwickelt. Aber man kann ja mal vorbauen und die Erwartungslatte tiefer legen. Psychologisch geschickt wenn systemimmanenter Zweifel realexistent bleibt. Programmierer schrieb: > Wie würdest du zielsicher die einzig wahre Sprache ausfindig machen? Menschen und Anwendungen sind dazu viel zu unterschiedlich. Hier geht es aber um ein etwas tiefergehängtes aber immer noch imposantes Ziel: C/C++ Ablösung. Bei dem was ich von Carbon höre (und verstehe) fehlt dafür aber das revolutionär Neue was irgendwie zum Einstieg einladen könnte. MaWin schrieb: > Du tust gerade so, als gäbe es eine globale Verschwörung von > Sprachstampfern, die nur darauf aus sind möglichst viele Sprachen zu > veröffentlichen, um die Welt in die Knie zu zwingen. Für eine schlechte Entwicklung brauchts nicht unbedingt organisierte Weltverschwörung. Ich tu so als ob immer größere Sprach-Vielfalt letztlich Minderung von Software-Kompatibilität und Ressourcenverschwendung an Zeit und Vergrößerung von Fehlerpotential bedeutet. Ist es nicht so? Permanent hochfrequente Fehlerkorrekturupdates bei vielerlei Profi-Software und Betriebssystemen sprechen eine deutliche Sprache! Das ist alles andere als professionell... Hier wird doch schlicht entstandene Komplexität nicht beherrscht. Aller hochgezüchteter Sprachen und Softwarewerkzeugen zum Trotz. Oder gerade deswegen? Yalu X. schrieb: > letztendlich zu einem zusammengewürfelten Kompromiss führen wie wir > ihn mit C++ jetzt schon haben. Spätestens dann wird sich jeder die Frage > stellen, welchen Nutzen die Einarbeitung in die neue Sprache überhaupt > noch hat. Immer höheren Einstiegshürden dürften einen wichtigen Beitrag zum Programmierermangel leisten. Die Entscheidung wird durch immer mehr Sprachvielfalt nicht vereinfacht. Welche lohnt sich wirklich, welche hat eine Zukunft? Der Weg zum Holzweg war nie leichter. W.S. schrieb: > verschlimmbessern Kein Begriff charakterisiert die Sprach-Evolution besser. Man kennt das aus der Software-Entwicklung: Ehe mühsam ein schwerer, in vielerlei Software Bestandteilen verstrickter Design-Fehler behoben wird pflastert man lieber ein paar Korrekturschichten drüber.
MaWin schrieb: > können jedem das Genick brechen schrieb: >> Es ist immer noch zu wenig. > > Das Problem an C++ ist nicht, dass es zu wenig ist. > Ganz im Gegenteil. Das Problem ist, dass es zu viel ist. ACK. C++ ist schon lächerlich aufgeblasen mittlerweile...
Ron T. schrieb: > Permanent > hochfrequente Fehlerkorrekturupdates bei vielerlei Profi-Software und > Betriebssystemen sprechen eine deutliche Sprache! Ja. Sie sprechen in großen Teilen die Sprache C/C++. Mit all ihren Unzulänglichkeiten. Allem voran die fehlende Memory Safety. Deshalb wird es höchste Zeit für eine Ablösung. > Ich tu so als ob immer größere Sprach-Vielfalt letztlich Minderung von > Software-Kompatibilität und Ressourcenverschwendung an Zeit und > Vergrößerung von Fehlerpotential bedeutet. Ist es nicht so? Ja, das ist nicht so. So funktioniert Weiterentwicklung. Wenn man neue Konzepte nicht ausprobiert, bleibt man auf dem Stand von K&R C. > Immer höheren Einstiegshürden dürften einen wichtigen Beitrag zum > Programmierermangel leisten. Die Einstiegshürden in die Softwareentwicklung waren noch nie so niedrig wie heute. Und sie sinken immer weiter. Hauptverantwortlich dafür sind moderne Sprachen. z.B. Python. Aber auch die allgemeine Informations- und Toolverfügbarkeit über das Internet. > Die Entscheidung wird durch immer mehr > Sprachvielfalt nicht vereinfacht. Welche lohnt sich wirklich Das ist gar keine Frage, die man sich stellen sollte, denn jede Sprache lohnt sich. Man erwirbt Fach- und Methodenkompetenz. Egal mit welcher Sprache. Diese Kompetenzen sind zum allergrößten Teil übertragbar. Vom Lernen wird man nie dümmer. > Ehe mühsam ein schwerer, in vielerlei > Software Bestandteilen verstrickter Design-Fehler behoben wird pflastert > man lieber ein paar Korrekturschichten drüber. Das hat aber nichts mit der Sprache zu tun, sondern mit Entwicklungsprozessen.
Ron T. schrieb: > Mombert H. schrieb: >> dass die Schöpfer selbst Carbon als ein Experiment sehen und nicht >> wissen, ob es die Zukunft von C++ ist > Das ist ja eher nicht der Anspruch wenn man eine neue Sprache > entwickelt. Aber man kann ja mal vorbauen und die Erwartungslatte tiefer > legen. Psychologisch geschickt wenn systemimmanenter Zweifel > realexistent bleibt. Warum ist das nicht "der Anspruch"? Was ist falsch daran? Dürfen die Entwickler nicht realistisch sein? Einen C++ Nachfolger zu entwickeln ist schwer. Es ist vollkommen unklar, ob der Weg der vorgeschlagen wurde zum Erfolg führen kann, oder ob es einen besseren gibt. Wie kann man das herausfinden? Indem man es ausprobiert. Es ist ein Experiment. Ron T. schrieb: > Programmierer schrieb: >> Wie würdest du zielsicher die einzig wahre Sprache ausfindig machen? > Menschen und Anwendungen sind dazu viel zu unterschiedlich. Hier geht es > aber um ein etwas tiefergehängtes aber immer noch imposantes Ziel: C/C++ > Ablösung. > Bei dem was ich von Carbon höre (und verstehe) fehlt dafür aber das > revolutionär Neue was irgendwie zum Einstieg einladen könnte. Ok, dann nochmal die gleiche Frage. Wie würdest du eine Ablösung für C++ entwickeln? Formuliere mal in ein paar Sätzen klare Ziele und Anforderungen.
MaWin schrieb: > Wenn man neue Konzepte nicht > ausprobiert, bleibt man auf dem Stand von K&R C. Stell Dir doch umgekehrt mal die Frage: Warum ist C dann heute noch so verbreitet? Ob dessen Konzept für viele Anwendungen nicht schlicht und einfach ausreicht? Gegen das Ausprobieren neuer Konzepte kann niemand etwas ernsthaft haben- nur bleibt es nicht dabei: Es bläst ja die Sprachen fortlaufend auf- bis schließlich bei all den (immer spezielleren) Verschlimmbessungen der Effekt zum Tragen kommt daß es schlicht zuviel wird, sich da noch einen Gesamtüberblick zu erhalten (eine Phase in die C++ längst eingetreten ist). MaWin schrieb: > Die Einstiegshürden in die Softwareentwicklung waren noch nie so niedrig > wie heute. Und sie sinken immer weiter. Hauptverantwortlich dafür sind > moderne Sprachen. z.B. Python. Jenem Effekt unterliegt selbst Python. Da fällt nichts, da steigt was unaufhörlich. MaWin schrieb: > denn jede Sprache > lohnt sich. Man erwirbt Fach- und Methodenkompetenz. Egal mit welcher > Sprache. Diese Kompetenzen sind zum allergrößten Teil übertragbar. Sicherlich. Doch ist hier eher nicht die Rede von Fach- und Methodenkompetenz sondern schlicht von Beherrschung einer Sprache mit all ihren überbordenden Möglichkeiten und Abstraktionen. Vieles mag sich ja ähnlich sein- doch wie man weiß liegt der Teufel immer im Detail. > Vom Lernen wird man nie dümmer. Die Zeit dafür ist nur dummerweise endlich. Produktiv leisten möchte man dann doch eher. MaWin schrieb: > Das hat aber nichts mit der Sprache zu tun, sondern mit > Entwicklungsprozessen. Nö das Bild ist schon ganz richtig. Verschlimmbesserung auf Ebene der Sprachinflation. Steigender Overhead und Wasserkopf auf allen Ebenen. Interessant dazu die Parallelen zur fortlaufenden Bürokratisierung in Staat und Wirtschaft. Da wirken letztlich dieselben Mechanismen: Immer detailliertere Vorgaben und Kontroll-Wahn steuern das Gesamtsystem letztlich zur Unbeherrschbarkeit.
Ron T. schrieb: > Stell Dir doch umgekehrt mal die Frage: Warum ist C dann heute noch so > verbreitet Die Verbreitung von C kennt nur eine Richtung. Sie sinkt seit mindestens 20 Jahren. An allen Ecken und Enden wird und wurde C bereits verdrängt. Die einzigen verbliebenen Bereiche sind System- und Embeddedprogrammierung. Am Systemprogrammierungsbein von C wird schon ordentlich gesägt. Ron T. schrieb: > Es bläst ja die > Sprachen fortlaufend auf- bis schließlich bei all den (immer > spezielleren) Verschlimmbessungen der Effekt zum Tragen kommt daß es > schlicht zuviel wird Wenn etwas aufgeblasen ist, dann sind das alte Sprachen mit ihren Altlasten. Siehe C++. Neue Sprachen sind eigentlich immer schlank. Konzepte, die vor 20 Jahren noch als Muss galten, werden heute über Bord geworfen. Nicht verschlanken zu können ist ein Problem von alten Sprachen aufgrund der Rückwärtskompatibilität. Da gibts bisher kaum Lösungsansätze zu. Außer vielleicht ein Edition-System, wie Rust es versucht. Ron T. schrieb: > Jenem Effekt unterliegt selbst Python. Da fällt nichts, da steigt was > unaufhörlich. Das sehe ich nicht so. Richtig ist, dass Python fortwährend neue Features bekommt. Falsch ist hingegen, dass diese die Einstiegshürde vergrößern. Einsteigerprogramme sehen heute noch genau so einfach (oder sogar einfacher) aus, als vor 30 Jahren. Ron T. schrieb: > Produktiv leisten möchte man dann doch eher. Du tust gerade so, als könne man nicht "produktiv leisten", wenn man nicht jedes kleinste Detail kennt. Dem ist nicht so. Ron T. schrieb: > Steigender Overhead und Wasserkopf auf allen Ebenen. Ja. Aber die Ebenen kann man nicht vermischen, denn sie haben nichts miteinander zu tun. Ein System wird nicht plötzlich unbeherrschbar, nur weil man eine andere Programmiersprache in einem Modul nutzt. Wenn dein System so fragil designed ist, dann ist das ein grundlegenderes Problem in deinen Entwicklungsprozessen. Abstraktion und Separierung von Aufgaben ist nicht grundsätzlich schlecht. Oft ist es auch genau das Richtige, um ein System beherrschbar zu behalten. Alte Sprachen wie C unterstützen einen dabei leider nicht. In modernen Sprachen wird man eigentlich immer zu einer halbwegs im Ansatz vorhandenen Modulseparierung ermutigt. Eine Sache, die in C nicht einmal technisch vorhanden ist. Ron T. schrieb: > Immer > detailliertere Vorgaben und Kontroll-Wahn steuern das Gesamtsystem > letztlich zur Unbeherrschbarkeit. Dinge über Bord werfen hilft dem entgegenzusteuern. Also zum Beispiel von C++ auf eine schlankere Sprache wechseln.
MaWin schrieb: > Also zum Beispiel von C++ auf eine schlankere Sprache wechseln. Also doch back to C oder wie?
Hans schrieb: > Man braut nur Java Und einen Rechner, der genug Power hat. Aber da ist es wie mit Windows: Egal wie stark der Rechner ist - es ist einfach zu wenig.
war nie wirklich weg schrieb: > Und einen Rechner, der genug Power hat. Aber da ist es wie mit Windows: > Egal wie stark der Rechner ist - es ist einfach zu wenig. Was mit einiger Kenntnis über heutige "Softwarearchitektur" jetzt kein Wunder ist. Objekt-orientiertes Programmieren ist schnell anspruchsvoll, da verliert man schnell mal den Überblick über den Ressourcenverbrauch. Da wird eine Schicht auf die andere gelegt als gäbe es kein Morgen. Wenn ich meinem >100MB Microchip-Studio beim ewigen Starten auf einem wirklich guten Ryzen System so zuschaue frage ich mich wo das alles noch enden soll. Vor allem wenn man es in Relation zum eher simplen Programmeditor/Debugging Zweck sieht.
Mombert H. schrieb: > Ok, dann nochmal die gleiche Frage. Wie würdest du eine Ablösung für C++ > entwickeln? Formuliere mal in ein paar Sätzen klare Ziele und > Anforderungen. Ja, Du machst es Dir schön einfach. Soll doch der Kritisierende was besseres auf die Beine stellen, was besseres vorweisen. Utopisch. Also: Kritik verboten??? Oder mit anderen Worten: Du hälst die Entwicklung für dann doch eher für zwangsläufig. Erstmal: Sieht man sich den Byte-Wust an den heutige Entwicklung so produziert ist doch schon fast jedem Laien klar daß dieselbe Funktionalität ganz grundsätzlich mit einem Bruchteil an Speicherplatz und Prozessorzeit auskäme wenn, ja wenn sie nur effizienter programmiert wäre. Ein tägliches Ärgernis nannte ich einen Beitrag zuvor. Das wichtigste Ziel wäre jetzt ganz allgemein: Runter mit der Komplexität! D.h. Eindampfen des Sprachumfangs, Reduktion wechselseitiger Abhängigkeiten, drastische Vereinfachung der SW Interfaces zu Ausgaben aller Art bzw. fürs Netzwerk/Internet. Zugegebenermaßen reden wir dann nicht nur von der Programmiersprache sondern auch vom mehr oder weniger intelligenten Funktionsangebot von Betriebssystemen. Das Kleinteilige, hochflexible ist gleichzeitig das was es so kompliziert macht.
:
Bearbeitet durch User
IMHO ist Carbon sinnlos. Kopiert die Rust Syntax in großen Teilen und bietet dann nicht mal das Hauptfeature, weshalb alles in Rust neu programmiert werden sollte - memory safety. Ich bleib lieber bei Rust - läuft auch super auf Risc-V oder STM32s. Bin eh nicht der Typ, der jedem Hype hinterherläuft ... Rust ist mittlerweile mature genug, um für mich relevant zu sein - und ich finde es toll 😍
Ron T. schrieb: > Runter mit der Komplexität! [...] > drastische Vereinfachung der SW > Interfaces zu Ausgaben aller Art bzw. fürs Netzwerk/Internet. [...] > intelligenten Funktionsangebot von Betriebssystemen. Lustig ist, Du widersprichst Dir selbst: Auf der einen Seite willst Du keine Komplexität, auf der anderen Seite willst Du "intelligente Funktion(en)" die alles automatisch machen. Wo soll denn dieses Angebot an toller, einfacher Funktionalität herkommen, ohne Komplexität? Diese Systeme gibt es schon längst: Z.b. kann jeder Junior-Programmierer innerhalb kürzester Zeit eine SPA-App in HTML/Javascript zusammenbasteln, die faktisch auf allen Geräten dieser Welt läuft und auch installiert werden kann. Vom Tablet, über Handy, TV-Glotze, Auto-Entertainment, Notebook. Und dabei spielt es keine Rolle welcher Hersteller, welcher Prozessor, etc. Und für diese Einfachheit, dass die App einfach überall läuft, benötigt es eben Infrastruktur, die Du so kritisierst: Web-Browser mit Javascript, dutzende Internet-Protokolle und unzählige Software-Komponenten die das alles erst ermöglichen. Was Du willst ist: Wasch mich, aber mach mich nicht nass.
Ein anderer Programmierer schrieb: > Lustig ist, Du widersprichst Dir selbst: Auf der einen Seite willst Du > keine Komplexität, auf der anderen Seite willst Du "intelligente > Funktion(en)" die alles automatisch machen. So recht verstanden hast Du, so recht verstehen willst Du nicht. Das finde ich lustig. > Wasch mich, aber mach mich nicht nass. Mit anderen Worten: Es kann nicht anders laufen als wie es läuft? Alles optimal? Nass wird man immer- die Menge an Wasser aber kann durchaus variieren. Denk mal darüber nach ;-)
Mal ganz allgemein: Ich finde es interessant, wie hier einige vehement einer neuen Programmiersprache das Existenzrecht absprechen, von der sie vielleicht nie erfahren hätten, wenn nicht Wilhelm diesen Thread gestartet hätte. Das ist ein wenig so wie bei der Vorstellung eines neuen Buchs, wo sich sofort einige aufregen: "O je, nicht noch ein Buch, es gibt doch schon so viele davon. Wann soll ich die denn alle lesen?"
Ron T. schrieb: > Mit anderen Worten: Es kann nicht anders laufen als wie es läuft? Alles > optimal? Ganz sicher nicht. Ron T. schrieb: > Erstmal: Sieht man sich den Byte-Wust an den heutige Entwicklung so > produziert ist doch schon fast jedem Laien klar daß dieselbe > Funktionalität ganz grundsätzlich mit einem Bruchteil an Speicherplatz > und Prozessorzeit auskäme wenn, ja wenn sie nur effizienter programmiert > wäre. Ja, genau. Gut gesagt. Laien ist das "klar". Experten erkennen nur, warum die Komplexität da ist. Ich bin auch für Komplexitätsreduktion. An allen Stellen, wo das möglich und sinnvoll ist. Ron T. schrieb: > Das wichtigste Ziel wäre jetzt ganz allgemein: Runter mit der > Komplexität Völlig korrekt. Also aufhören Dinge in C++ zu entwickeln. Ron T. schrieb: > Soll doch der Kritisierende was besseres auf die Beine stellen, was > besseres vorweisen. Utopisch. Also: Kritik verboten??? Nein. Aber du bist auf der "Contra" Seite. Also "musst" du schlüssige Argumente vorbringen. Es ist nicht die Aufgabe der Pro-Leute die Argumente der Contra-Leute zusammenzutragen. Und wenn du diese Argumente nicht vorbringen kannst, dann ist dein Standpunkt mehr als wackelig. Es reicht nicht aus nur zu behaupten alles sei komplex, um die Pro-Seite zu überzeugen. Wir wissen alle, dass Software komplex ist. Lösungen statt blafasel sind gefragt.
MaWin schrieb: > Lösungen statt blafasel Nun, es geht durchaus auch ganz global darum wie sinnvoll jedwede neue Sprache für dieselbe Hardware überhaupt sein kann. Es täte mir leid wenn Du meine Ansicht da in die Kategorie blafasel einordnest. Denn mit > Also aufhören Dinge in C++ zu entwickeln. erkennst Du immerhin an, daß es durchaus auch in der Natur der verwendeten Sprache liegt, welches Komplexitätslevel damit gezüchtet wird bzw. zu welchem sie verleitet. Nun wäre ich meinerseits ganz wißbegierig, welchen konkreten Vorteil Du diesbezüglich bei Carbon siehst- denn das ist meines Erachtens hier langfristig die entscheidende Frage wenn es um Zukunftsfähigkeit geht. Ist das alles eher evolutionär (wie ich glaube und was beileibe nicht reicht lang etablierten Sprachen den Garaus zu machen) oder steckt in Carbon der Funken einer Revolution? Ohne hier konkret zu werden sehe ich eher > dein(en) > Standpunkt mehr als wackelig Yalu X. schrieb: > wie hier einige vehement > einer neuen Programmiersprache das Existenzrecht absprechen Nein Yalu. Existenzrechte abzusprechen wäre doch etwas vermessen. Die Sinnfrage zu stellen ist hingegen durchaus berechtigt. Oder geht es nur darum sich "an neuen Konzepten" intellektuell zu erfreuen? Da möchte ich nicht weiter stören!
:
Bearbeitet durch User
Ron T. schrieb: > Denn mit > >> Also aufhören Dinge in C++ zu entwickeln. > > erkennst Du immerhin an, daß es durchaus auch in der Natur der > verwendeten Sprache liegt, welches Komplexitätslevel damit gezüchtet > wird bzw. zu welchem sie verleitet. Ja. Alle neuen Sprachen (die ich kenne) sind weniger komplex als C++. Ron T. schrieb: > Ist das alles eher evolutionär (wie ich glaube und was beileibe nicht > reicht lang etablierten Sprachen den Garaus zu machen Es reicht aus, um die Bedeutung der Sprache auf von World-domination auf ein wenige Nischengebiete zu reduzieren. Das ist, was bereits mit C passiert ist. C wird nie vollständig aussterben. Das ist auch gar nicht das Ziel. Aber es wird den Weg der Cobols, Fortrans und Pascals dieser Welt gehen. Es befindet sich bereits seit langer Zeit auf diesem Weg. Und andere Sprachen werden folgen. Auch Carbon, Rust und Python werden irgendwann diesen Weg gehen. Ron T. schrieb: > Die Sinnfrage zu stellen ist hingegen durchaus berechtigt. Wenn man Fragen stellt, muss man die Antworten aber auch aushalten können.
MaWin schrieb: > Ron T. schrieb: >> Ist das alles eher evolutionär (wie ich glaube und was beileibe nicht >> reicht lang etablierten Sprachen den Garaus zu machen > > Es reicht aus, um die Bedeutung der Sprache auf von World-domination auf > ein wenige Nischengebiete zu reduzieren. Das ist, was bereits mit C > passiert ist. PC-Anwendungen und Handy-Apps sind nur ein geringer Bruchteil der gesamten Software, die geschrieben wird. Außerhalb dieses Bereichs ist C durchaus weit verbreitet. Die Zahl an Geräten mit einem Prozessor, wo überhaupt kein C-Code drin steckt, dürfte recht überschaubar sein, und das gilt für alle Ausbaustufen, von der Smartcard bis zum Supercomputer. Mir würde keine andere Sprache einfallen, für die das auch nur annähernd in diesem Umfang gilt.
Rolf M. schrieb: > PC-Anwendungen und Handy-Apps sind nur ein geringer Bruchteil der > gesamten Software, die geschrieben wird. Außerhalb dieses Bereichs ist C > durchaus weit verbreitet. https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages Ich sprach ganz bewusst von Gebieten und Nischen. Nicht von der absoluten Anzahl von C-freien Geräten. C wird nur noch in der Embedded- und Systemprogrammierung verwendet und in Altprojekten. Das ist von der reinen Codemasse natürlich wahrscheinlich immer noch mit an der Spitze. Aber es ist kein aufsteigender Ast, sondern ein (relativ zum Rest gesehen) absteigender Ast.
MaWin schrieb: > C wird nur noch in der Embedded- und Systemprogrammierung verwendet und > in Altprojekten. Gibt Statistiken dazu: https://www.tiobe.com/tiobe-index/ Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - ist also quasi schon so gut wie tot ;-) Aber, tbh, die letzten Jahre / Jahrzehnte kamen viele Programmiersprachen raus, aber die erste, die wirklich irgendwas ändern konnte, ist Rust. Alles andere ist mehr oder weniger der gleiche Kram und die Konzepte sind alle gleich. Untereinander austauschbar usw ... Daher sehe ich die höchste Relevanz für die Zukunft in Rust, weil es wirklich mal Probleme beseitigt hat und trotzdem auf dem Level von C und C++ mitspielen kann. Und bei Carbon seh ich diesen Vorteil nicht - andere Syntax, gleiche grundlegende Krankheit. Hier heißt es nur, sie versuchen und sie wollen usw ... https://github.com/carbon-language/carbon-lang/blob/trunk/README.md#memory-safety Bei Rust ist es garantiert, dass es memory safe ist und DAS grundlegende Konzept.
:
Bearbeitet durch User
Mampf F. schrieb: > Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - > ist also quasi schon so gut wie tot ;-) So sehe ich das (unironisch) auch. 13% Market share bedeutet, dass 87% nicht in C geschrieben ist. Insbesondere, wenn man die enorme Menge an C-legacy-Code sieht, die es natürlich noch lange geben wird, ist das ein vergleichsweise kleiner Anteil. Es ist der absteigende Ast. Und das seit Jahrzehnten. Mampf F. schrieb: > Daher sehe ich die höchste Relevanz für die Zukunft in Rust, weil es > wirklich mal Probleme beseitigt hat und trotzdem auf dem Level von C und > C++ mitspielen kann. Das sehe ich ähnlich. Aber ich gehe nicht so weit und spreche Carbon das Existenzrecht ab, wie einige das hier tun. Ob Carbon eine Zukunft hat, kann man nur herausfinden, indem man es weitertreibt. Und vieleicht kommt ja etwas bei rum, was uns weiterbringt. Selbst wenn es nur ein innovatives Teilkonzept ist, was dann in andere Sprachen übertragen werden kann. Es war schon immer so, dass Sprachen sich gegenseitig beeinflussen und befruchten.
MaWin schrieb: > Rolf M. schrieb: >> PC-Anwendungen und Handy-Apps sind nur ein geringer Bruchteil der >> gesamten Software, die geschrieben wird. Außerhalb dieses Bereichs ist C >> durchaus weit verbreitet. > https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-programming-scripting-and-markup-languages > Ich sprach ganz bewusst von Gebieten und Nischen. Nicht von der > absoluten Anzahl von C-freien Geräten. > C wird nur noch in der Embedded- und Systemprogrammierung verwendet und > in Altprojekten. Nur weil du das gerne so hättest, ist das noch lange nicht so.
Mombert H. schrieb: > Nur weil du das gerne so hättest, ist das noch lange nicht so. Na dann zeig doch mal die Neuprojekte, die heute in C aufgesetzt werden? Außerhalb von Embedded- und Sytementwicklung.
MaWin schrieb: > Mombert H. schrieb: >> Nur weil du das gerne so hättest, ist das noch lange nicht so. > Na dann zeig doch mal die Neuprojekte, die heute in C aufgesetzt werden? > Außerhalb von Embedded- und Sytementwicklung. Ahh, jetzt sind wir schon bei "neu aufgesetzt in C". Das hört sich so an, als würdes du die Anforderung "ausschließlich in C" hinzufügen ;-) Im HPC Bereich gibt es 3(½) Sprachen, die relevant sind: Python, C++ und C (+CUDA). Und Python ist nur möglich, weil C++ oder C den eigentliche HPC Teil übernehmen.
Carbon’s most exciting feature is its calling convention https://www.foonathan.net/2022/07/carbon-calling-convention/
Mombert H. schrieb: > jetzt sind wir schon Nö. Wenn du aufmerksam gelesen hättest, waren wir schon immer da. Das habe ich mehrfach so geschrieben.
MaWin schrieb: > Mombert H. schrieb: >> jetzt sind wir schon > Nö. Wenn du aufmerksam gelesen hättest, waren wir schon immer da. Das > habe ich mehrfach so geschrieben. Kannst du bitte mindestens zwei deiner Beiträge zitieren, in denen das explizit drin steht? In dem Beitrag, auf den ich geantwortet, steht nichts davon. Auch die vorausgehenden Beiträge enthalten nicht
1 | C wird nur* noch in der Embedded- und Systemprogrammierung verwendet und in Altprojekten. |
2 | *es werden nur Projekte gezählt die ausschließlich in C geschrieben sind. |
Mombert H. schrieb: > Kannst du bitte mindestens zwei deiner Beiträge zitieren Wozu? Alles steht hier im Verlauf. Ich habe immer nur von Embedded- und Systemprogrammierung gesprochen. Mehrfach. Dass es um neue Entwicklungen geht versteht sich ja auch von selbst. Alte Entwicklungen, die in C geschrieben sind, sind per Definition in C geschrieben. Neue Sprachen ändern die Vergangenheit nicht.
MaWin schrieb: > Die Verbreitung von C kennt nur eine Richtung. Sie sinkt seit mindestens > 20 Jahren. An allen Ecken und Enden wird und wurde C bereits verdrängt. Naja, schau dir mal die Diagramme in Tiobe & Co an. Ja, es ist ein leichter Abfall zu erkennen, bei Tiobe sind es in den letzten 11 Jahren im Mittel -0,65 Prozentpunkte pro Jahr. Setzt man das linear fort, wird C also erst in 20 Jahren tot sein. Tatsächlich wird der Verlauf eher asymptotisch gegen 0 verlaufen, so dass C auch in 20 Jahren ein paar Prozente für sich vereinnahmen kann. Die C-Programmierer wandern aber nicht direkt nach Rust ab, sondern erst einmal nach C++, weil dafür so gut wie kein Migrationsaufwand entsteht und die Einarbeitung graduell erfolgen kann. C++ ist aber – nachdem es ein Zeitlang Federn zu Gunsten von C# lassen hat müssen – derzeit sogar wieder leicht am Ansteigen. Da C im Wesentlichen nichts anderes ist als ein sehr stark verschlanktes C++, wäre es IMHO ohnehin sinnvoller, sie in der Statistik als eine Sprache führen. MaWin schrieb: > Ich sprach ganz bewusst von Gebieten und Nischen. Nicht von der > absoluten Anzahl von C-freien Geräten. > C wird nur noch in der Embedded- und Systemprogrammierung verwendet und > in Altprojekten. Embedded-Programmierung ist für dich eine Nische? Ich würde sagen, nirgends wird derzeit mehr Software entwickelt und werden mehr neue Projekte gestartet als im Embedded-Bereich, und dieser Anteil dürfte künftig noch steigen. Das ist ja auch genau der Bereich, in dem sich Rust einen Teil des Kuchens abschneiden will und wofür ich langfristig auch realistische Chancen sehe (oder zumindest erhoffe ;-)). Natürlich kann man in Rust auch gewöhnliche PC-Anwendungen schreiben, aber in diesem Bereich gibt es genügend andere neuere Sprachen, die – was die Spracheigenschaften betrifft – dafür mindestens so gut geeignet sind wie Rust, es aber ähnlich schwer haben, einen nennenswerte Anzahl von Entwicklern von den Platzhirschen C/C++ und Java wegzulocken. Ich finde das zwar schade, aber man der Realität halt ins Auge sehen. MaWin schrieb: > Mampf F. schrieb: >> Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - >> ist also quasi schon so gut wie tot ;-) > > So sehe ich das (unironisch) auch. 13% Market share bedeutet, dass 87% > nicht in C geschrieben ist. Der Tiobe-Index erfasst 275 Sprachen. Auf jede entfallen im Mittel also 0,36%. Da empfindest zu 13% (das ist das 36-fache(!) des Mittelwerts) als wenig? Betrachtet man C und C++ aus den o.g. Gründen als eine Sprache, liegt der Anteil sogar bei über 23%, also auf ein knappes Viertel. Rust hingegen liegt mit 0,42% deutlich hinter Fortran (0,76%) und sogar hinter Cobol (0,53%). Wendet man deine Argumentation von oben auf Rust an, kommt man zum Schuss, dass 99,58% der Software (also de facto alle Software) nicht in Rust geschrieben ist. Bis Rust in der gleiche Liga wie C/C++ spielen wird, werden noch viele Jahre vergehen, und wer weiß, was bis dahin die Konkurrenz noch alles vorstellen wird. Vielleicht arbeitet ja Microsoft bereits an einer Sprache, die genauso systemnah und memory-safe wie Rust ist und darüberhinaus noch viele neue Features für die Produktivitätssteigerung bietet. Sollte dieser Fall eintreten, wäre Rust schneller tot als du es dir in deinen kühnsten Träumen für C erhoffst :)
Yalu X. schrieb: > Setzt man das linear fort, wird > C > also erst in 20 Jahren tot sein. Tatsächlich wird der Verlauf eher > asymptotisch gegen 0 verlaufen, so dass C auch in 20 Jahren ein paar > Prozente für sich vereinnahmen kann. völlig korrekt. Yalu X. schrieb: > Embedded-Programmierung ist für dich eine Nische? Ja? Oder nenn es Gebiet oder wie du es auch immer nennen willst. Yalu X. schrieb: > nirgends wird derzeit mehr Software entwickelt und werden mehr neue > Projekte gestartet als im Embedded-Bereich Gibts dafür auch Belege? Yalu X. schrieb: > Natürlich kann man in Rust auch gewöhnliche PC-Anwendungen schreiben, > aber in diesem Bereich gibt es genügend andere neuere Sprachen, die – > was die Spracheigenschaften betrifft – dafür mindestens so gut geeignet > sind wie Rust Aha. Welche sollen das denn sein? Werden Kernels jetzt auch in Java programmiert? Yalu X. schrieb: > Wendet man deine Argumentation von oben auf Rust > an, kommt man zum Schuss, dass 99,58% der Software (also de facto alle > Software) nicht in Rust geschrieben ist. Ja. Und? Yalu X. schrieb: > Bis Rust in der gleiche Liga wie C/C++ spielen wird, werden noch viele > Jahre vergehen Korrekt. Habe nie etwas anderes behauptet. Yalu X. schrieb: > Vielleicht arbeitet ja Microsoft bereits an einer > Sprache, die genauso systemnah und memory-safe wie Rust ist und > darüberhinaus noch viele neue Features für die Produktivitätssteigerung > bietet. Sollte dieser Fall eintreten, wäre Rust schneller tot als du es > dir in deinen kühnsten Träumen für C erhoffst :) Ja, bitte. Ich hoffe das passiert tatsächlich. Wieso sollte ich etwas dagegen haben? Anzeichen gibts dafür bisher aber leider keine.
Yalu X. schrieb: > Mal ganz allgemein: Ich finde es interessant, wie hier einige vehement > einer neuen Programmiersprache das Existenzrecht absprechen, Dein Satz enthält zwei Unwahrheiten: 1. es ist eben KEINE neue Sprache, sonden eben bloß mal wieder eine Art Vorbrenner für C und Leute, die außer C eigentlich nichts akzeptieren wollen. Also keine neue Programmiersprache, sondern eben nur eine neue Geaschmacksrichtung von C. Sozusagen ein neues Einwickelpapierchen um die alte Kamelle. 2. hier spricht keiner irgend ein Recht auf Existenz ab, sondern gar viele schrieben, daß sie keine rechte Anwendung für diesen Entwurf sehen. Das ist ein Unterschied. Ich sehe das so, daß über die letzten Jahre hinweg immer mal einige C-Programmierer recht deutlich gespürt haben, daß C für manches nicht ausreicht und auch nicht modernisierbar ist und da sie im Grunde bei C bleiben wollen, haben sie den Spagat gewagt, etwas Renoviertes zu erfinden un zugleich all die liebgewonnenen Details von C zu behalten. Das ist wohl eher das "wasch mich, aber mach mich nicht naß". Und deshalb ist auch alles, was da erfunden wurde, am ehesten mit dem Bild von dem altbekannten Bonbon im neuen Einwickelpapier zu beschreiben. Und eben deshalb ist auch diese Diskussion fruchtlos, denn im Grunde wird ja nur diskutiert, wie man die Nachteile von C beseitigen kann, ohne sie tatsächlich zu beseitigen. W.S.
W.S. schrieb: > Also keine neue Programmiersprache, sondern eben nur > eine neue Geaschmacksrichtung von C So ein Käse. Hast du dir Carbon auch nur mal 2 Minuten angeschaut? W.S. schrieb: > etwas Renoviertes zu > erfinden un zugleich all die liebgewonnenen Details von C zu behalten. Also ja. Du hast nicht einmal das Readme gelesen. Das ist offensichtlich.
Yalu X. schrieb: > Ich würde sagen, > nirgends wird derzeit mehr Software entwickelt und werden mehr neue > Projekte gestartet als im Embedded-Bereich Süß. Die Embedded-Leute überschätzen sich regelmäßig. Habe jetzt keine Lust, stundenlang irgendwelche Zahlen zu googeln, auf die Schnelle habe ich für Deutschland folgende Umsätze gefunden: Embedded-Software 2008: 0,7 Milliarden Euro SAP 2008: 11,5 Milliarden Euro Natürlich ist Umsatz nicht gleich "Menge Software". Allerdings werden die Größenordnungen klar und wahrscheinlich korreliert der Umsatz recht gut zu der Anzahl der Code-Zeilen, was ja wiederum einer Art "Menge Software" entspricht. Embedded-Software ist eine Nische.
MaWin schrieb: > Yalu X. schrieb: >> Embedded-Programmierung ist für dich eine Nische? > > Ja? > Oder nenn es Gebiet oder wie du es auch immer nennen willst. Eins, das ziemlich groß ist, daher ist "Nische" kein wirklich passender Begriff. Und dort kommt man um C bzw. C++ nicht herum. > Yalu X. schrieb: >> nirgends wird derzeit mehr Software entwickelt und werden mehr neue >> Projekte gestartet als im Embedded-Bereich > > Gibts dafür auch Belege? Ist das nicht logisch? Immer mehr Geräte und insbesondere auch Teilfunktionen von Geräten besitzen einen µC. Die programmieren sich nicht von selbst. > Yalu X. schrieb: >> Natürlich kann man in Rust auch gewöhnliche PC-Anwendungen schreiben, >> aber in diesem Bereich gibt es genügend andere neuere Sprachen, die – >> was die Spracheigenschaften betrifft – dafür mindestens so gut geeignet >> sind wie Rust > > Aha. Welche sollen das denn sein? > Werden Kernels jetzt auch in Java programmiert? Ich würde einen Kernel nicht unbedingt als "gewöhnliche PC-Anwendung" bezeichnen.
Rolf M. schrieb: > Ist das nicht logisch? Nein, ist es nicht. > Immer mehr Geräte und insbesondere auch > Teilfunktionen von Geräten besitzen einen µC. Eben. Das beschränkt sich aber nicht auf Embedded. Überall wächst die Komplexität. Davon abgesehen sind die Programmgrößen auf Embeddedgeräten winzig im Vergleich zu dem, was auf "richtigen" Rechnern läuft. Du musst schon Smartphones zu Embedded mit hinzuzählen, damit deine Massen-Argumentation halbwegs hinkommen könnte. Und wenn du das tust, dann würde ich mal gerne die C-Dominanz auf diesen Geräten erklärt bekommen. Rolf M. schrieb: > Ich würde einen Kernel nicht unbedingt als "gewöhnliche PC-Anwendung" > bezeichnen. Gut, gut. Und welche nach deiner Definition "gewöhnlichen" PC-Anwendungen werden heute so noch in C entwickelt? C hat fertig. Es ist ein Zombie. Jede Minute, die ihr noch an der C-Brust weiternuckelt, könnt ihr nicht investieren, um zukunftsfähig zu werden.
MaWin schrieb: > C hat fertig. Es ist ein Zombie. Jede Minute, die ihr noch an der > C-Brust weiternuckelt, könnt ihr nicht investieren, um zukunftsfähig zu > werden. Stattdessen zu der Sackgasse* rust wechseln? Wenn wir die Zahlen von oben annehmen, sind meine Chancen 50x größer einen Job mit C oder C++ zu bekommen als mit rust. Da bleib ich lieber bei C und C++ und wette auf Carbon ;-) Im Notfall habe ich noch Python und Fortran in Gepäck, die auch nach einer besseren Wette auasehen. *könnte sich um leichte Übertreibung handeln
MaWin schrieb: > Yalu X. schrieb: >> Natürlich kann man in Rust auch gewöhnliche PC-Anwendungen schreiben, >> aber in diesem Bereich gibt es genügend andere neuere Sprachen, die – >> was die Spracheigenschaften betrifft – dafür mindestens so gut geeignet >> sind wie Rust > > Aha. Welche sollen das denn sein? > Werden Kernels jetzt auch in Java programmiert? Ich schrieb von PC-/Anwendungen/. Kernel sind ein anderes Thema, da kann ich mir neben C/C++ auch Rust gut vorstellen. Allerdings macht die Kernel- im Vergleich zur Anwendungsentwicklung nur einen verschwindend kleinen Anteil an der gesamten Softwareentwicklung aus. Das wäre übrigens ein Beispiel für eine Nische. MaWin schrieb: > Yalu X. schrieb: >> Wendet man deine Argumentation von oben auf Rust >> an, kommt man zum Schuss, dass 99,58% der Software (also de facto alle >> Software) nicht in Rust geschrieben ist. > > Ja. Und? Naja, mit deiner Aussage, dass 87% aller Software nicht in C geschrieben ist, wolltest du bekräftigen, wie tot C doch ist: MaWin schrieb: > Mampf F. schrieb: >> Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - >> ist also quasi schon so gut wie tot ;-) > > So sehe ich das (unironisch) auch. 13% Market share bedeutet, dass 87% > nicht in C geschrieben ist. Wie tot muss dann erst eine Sprache sein, in der 99,58% der Software nicht programmiert ist? MaWin schrieb: > Yalu X. schrieb: >> Bis Rust in der gleiche Liga wie C/C++ spielen wird, werden noch viele >> Jahre vergehen > > Korrekt. Habe nie etwas anderes behauptet. Deine bisherigen Aussagen habe ich so interpretiert, dass C in einem halben Jahr in die Bedeutungslosigkeit abgesunken sein und Rust dessen Platz eingenommen haben wird. Vielleicht hättest du eine Sätze etwas weniger provokant formulieren sollen :) Aber gut, dass du das richtiggestellt hast, dann sind wir diesbezüglich ja einer Meinung. MaWin schrieb: > W.S. schrieb: >> Also keine neue Programmiersprache, sondern eben nur >> eine neue Geaschmacksrichtung von C > > So ein Käse. Hast du dir Carbon auch nur mal 2 Minuten angeschaut? Für W.S. ist alles, was geschweifte Klammern statt BEGIN und END zur Blockklammerung verwendet, eine "Geschmacksrichtung von C". Warum sollte man da auch genauer hinsehen? ;-) Ein anderer Programmierer schrieb: > Habe jetzt keine Lust, stundenlang irgendwelche Zahlen zu googeln, auf > die Schnelle habe ich für Deutschland folgende Umsätze gefunden: > > Embedded-Software 2008: 0,7 Milliarden Euro > SAP 2008: 11,5 Milliarden Euro Wird Embedded-Software primär in Deutschland entwickelt? Ist der Umsatz von SAP deswegen so exorbitant hoch, weil da laufend so unglaublich viel neue Software entwickelt wird, oder könnten da evtl. auch noch andere Gründe eine Rolle spielen? Ganz abgesehen davon sind die 0,7 Milliarden für Embedded natürlich Quatsch. Wenn jeder Embedded-Entwickler auch nur für einen Umsatz von 100 k€ sorgt (für noch weniger würde es sich für eine Firma kaum lohnen, ihn anzustellen), gäbe es in ganz Deutschland gerade einmal 7000 davon. Ich schätze, die 0,7 Milliarden beziehen sich nur auf diejenige Software, die als Entwicklungsleistung an andere Firmen verkauft wird (also direkt mit einem Preis beziffert werden kann), nicht aber auf die, die von Geräte- und Fahrzeugherstellern selber entwickelt und als Bestandteil der jeweiligen Geräte und Fahrzeuge verkauft wird. Es lässt sich ja auch schwer herausfinden, welcher Anteil des Umsatzes eines Endprodukts auf die Softwareentwicklung entfällt.
Mombert H. schrieb: > Stattdessen zu der Sackgasse* rust wechseln? Wenn wir die Zahlen von > oben annehmen, sind meine Chancen 50x größer einen Job mit C oder C++ zu > bekommen als mit rust. Und deine Chancen sind noch höher, wenn du beides beherrschst. Ich habe nirgendwo gefordert, dass du dein C-Wissen vergessen musst oder sofort alles umwerfen sollst. Man wird nicht dümmer vom Lernen. Mombert H. schrieb: > Im Notfall habe ich noch Python und Fortran in Gepäck, die > auch nach einer besseren Wette auasehen. Python als C-Ersatz? Ja. Kann man machen. Mache ich auch. Für Prototypen. Oder für Dinge, wo Effizienz und Echtzeit eh keine Rolle spielt.
Yalu X. schrieb: > Ich schrieb von PC-/Anwendungen/. Ah ja gut. Danke für die Erklärung. Aber nun mal Butter bei die Fische: Welche PC-/Anwendungen/ sind das denn so, wo heute C noch dominant ist? Also Anwendungen aus dem aktuellen Jahrtausend. Yalu X. schrieb: > Naja, mit deiner Aussage, dass 87% aller Software nicht in C geschrieben > ist, wolltest du bekräftigen, wie tot C doch ist: Dir ist aber schon klar, dass Rust aus der anderen Richtung gelaufen kommt? Oder sind Babies auch schon tot, nur weil sie nahe an einer der beiden Begrenzungen des Lebens stehen? Yalu X. schrieb: > Deine bisherigen Aussagen habe ich so interpretiert, dass C in einem > halben Jahr in die Bedeutungslosigkeit abgesunken sein Ich weiß nicht, wo ich das gesagt haben soll. Ich habe sogar das exakte Gegenteil gesagt. C wird niemals komplett verschwinden. Und das ist auch gar nicht schlimm. Schlimm ist nur Betonkopfdenken und Ausgrenzen weil das-war-ja-immer-schon-so und nicht-hier-erfunden-kann-weg.
MaWin schrieb: > Mombert H. schrieb: >> Stattdessen zu der Sackgasse* rust wechseln? Wenn wir die Zahlen von >> oben annehmen, sind meine Chancen 50x größer einen Job mit C oder C++ zu >> bekommen als mit rust. > Und deine Chancen sind noch höher, wenn du beides beherrschst. Auf die winzige Erhöhung kann ich verzichten. > Ich habe nirgendwo gefordert, dass du dein C-Wissen vergessen musst oder > sofort alles umwerfen sollst. > Man wird nicht dümmer vom Lernen. Mein Arbeitgeber wird mich sicherlich nicht dafür bezahlen, rust zu lernen. Ich müsste das also in meiner Freizeit tun. Aber da kann ich was interessanteres lernen, oder das was ich kann für interessantere Dinge einsetzen. Es würde mich also etwas kosten. > Mombert H. schrieb: >> Im Notfall habe ich noch Python und Fortran in Gepäck, die >> auch nach einer besseren Wette auasehen. > Python als C-Ersatz? Ja. Kann man machen. Mache ich auch. Für > Prototypen. Oder für Dinge, wo Effizienz und Echtzeit eh keine Rolle > spielt. Habe ich etwas von Ersatz geschrieben?
Mombert H. schrieb: > Aber da kann ich was > interessanteres lernen, oder das was ich kann für interessantere Dinge > einsetzen. Es würde mich also etwas kosten. Das ist dein gutes Recht. Aber dann solltest du Sprachen, die dich offenbar gar nicht interessieren, besser auch nicht bewerten. Warum diskutierst du hier eigentlich mit? > Habe ich etwas von Ersatz geschrieben? Es ist das Thema des Threads.
MaWin schrieb: > C hat fertig. Es ist ein Zombie. Und C++? Warum trampelst du überhaupt die ganze Zeit auf C herum? Um es noch einmal in Erinnerung zu rufen: In diesem Thread geht es um einen potentiellen Nachfolger von C++, nicht von C. C braucht keinen Nachfolger, da es bereits einen hat (nämlich C++).
Soviel Palaver um Carbon, wo doch die Politik die Decarbonisierung beschlossen hat. Steigt ab vom toten Pferd! Geniesst den Sonntag!
Yalu X. schrieb: > Warum trampelst du überhaupt die ganze Zeit auf C herum? Ich trampele hier auf gar nichts herum. Das habe ich gerade eben noch wiederholt geschrieben. Ich antworte nur auf offensichtlichen Quatsch und frage, wie die Quatschredner zu diesen Aussagen kamen. Vielleicht kann ich ja noch was lernen.
MaWin schrieb: > Mombert H. schrieb: >> Aber da kann ich was >> interessanteres lernen, oder das was ich kann für interessantere Dinge >> einsetzen. Es würde mich also etwas kosten. > Das ist dein gutes Recht. > Aber dann solltest du Sprachen, die dich offenbar gar nicht > interessieren, besser auch nicht bewerten. > Warum diskutierst du hier eigentlich mit? Weil es hier um Carbon und nicht um rust geht. Mein persönliches interessen an Carbon ist deutlich höher als für rust, damit ist es wahrscheinlicher, dass ich die Zeit investieren würde und die Chancen, dass mein Arbeitgeber die Zeit zum Carbon lernen zahlt, ist deutlich höher. >> Habe ich etwas von Ersatz geschrieben? > Es ist das Thema des Threads. Ist es das? Auch wenn das der Fall sein sollte, bezieht sich nicht jeder Satz in jedem Beitrag darauf. Ich habe in dem von dir zitierten Satz nichts von Ersatz geschrieben oder angedeutet.
Vincent H. schrieb: > Carbon’s most exciting feature is its calling convention > > https://www.foonathan.net/2022/07/carbon-calling-convention/ Das ist tatsächlich interessant. Aber ehrlichgesagt, #3 verstehe ich nicht wirklich, wie das geht. Wenn eine Variable auf dem Stack ist, und ich geb sie zurück, kann die ja nicht einfach dort beleiben, sonst hat man da schnell eine Lücke auf dem Stack. Also muss man es doch kopieren. Das wäre ja sonst wie in C bei "int* func(){int x=1; return &x;}". Solange man keine Referenzen darauf haben kann, klar, dann kann man es transparent Kopieren, ohne anderswo die Referenzen anpassen zu müssen, ist dann also trivial Kopierbar. Aber das ist ja nicht, was da behauptet wird. Oder geht es da nur um Daten, die selbst vollständig in ein Register passen, also nicht um Referenzen? Oder liegen die Daten vielleicht alle immer auf dem Heap? Und dann frage ich mich noch, wie viel Performance verliert man bei so einer trivialen Kopie überhaupt? Rust macht glaube ich viel mit kopieren, und dank CPU Caches ist es trotzdem extrem effizient? Also ist das ein realer Vorteil? Und was wenn man mehrere Referenzen von was weiss ich wo übergibt, könnte es ab einem gewissen Punkt eventuell sogar ein performance nachteil werden, wenn das nicht mehr alles in den Cache bereich passt?
Daniel A. schrieb: > Aber ehrlichgesagt, #3 verstehe ich > nicht wirklich, wie das geht. Wenn eine Variable auf dem Stack ist, und > ich geb sie zurück, kann die ja nicht einfach dort beleiben, sonst hat > man da schnell eine Lücke auf dem Stack. Ich denke es geht da um Move-Semantik. Das hat weniger damit zu tun, was auf Bitebene auf dem Stack passiert, sondern mehr damit, welche Aktionen die Sprache dir erlaubt. Wenn man etwas moved, dann wird der alte Speicher ungültig. Das sagt aber erst einmal nichts darüber aus was mit dem alten Bitmuster passiert.
Daniel A. schrieb: > Rust macht glaube ich viel mit kopieren Naja. Jetzt ist die Frage, was du mit "kopieren" meinst. Wenn du damit Copy-Semantik meinst dann: Nein. Rust macht standardmäßig Move-Semantik. Es sei denn, man gibt es explizit anders an/frei. Was bei einem Move jetzt auf Bitebene passiert, ist dann die Sache des optimierenden Compilers. Oft passiert gar nichts und es wird nur auf Compilerebene das Zugriffsrecht gewechselt. Manchmal muss es aber auch zu einem Umkopieren der Daten kommen. Und das kann mehr oder weniger effizient sein, je nach Szenario. Rust hat keine Copy- und Move-Konstrukturen und hat deshalb grundsätzlich eine bessere Optimierungsbasis, weil es mehr Annahmen treffen kann, als z.B. C++. > Und was wenn man mehrere Referenzen von was > weiss ich wo übergibt, könnte es ab einem gewissen Punkt eventuell sogar > ein performance nachteil werden, wenn das nicht mehr alles in den Cache > bereich passt? Diese Überlegungen stellen sich in Rust eigentlich gar nicht. Man muss sich in Rust Gedanken darüber machen, wem ein Objekt gehört. (Das sollte man im Übrigen in allen Sprachen tun. Aber Rust erzwingt es.). Das heißt es "ergibt" sich vom Ownership her, ob ich ein Objekt move (= Ownership übergebe), oder eine Referenz übergebe (= Ownership borrow). So, genug offtopic :)
Daniel A. schrieb: > Vincent H. schrieb: >> Carbon’s most exciting feature is its calling convention >> https://www.foonathan.net/2022/07/carbon-calling-convention/ > Das ist tatsächlich interessant. Aber ehrlichgesagt, #3 verstehe ich > nicht wirklich, wie das geht. Wenn eine Variable auf dem Stack ist, und > ich geb sie zurück, kann die ja nicht einfach dort beleiben, sonst hat > man da schnell eine Lücke auf dem Stack. Also muss man es doch kopieren. > Das wäre ja sonst wie in C bei "int* func(){int x=1; return &x;}". Bei #3 gehts (wie bei den anderen Punkten) um das Aufrufen einer Funktion, nicht um das was sie zurück liefert. In der Funktion sieht es aus als wäre der Funktionsparameter eine Kopie wie in C++. Der Compiler muss dafür in Carbon aber keine echte Kopie anfertigen. Es reicht, wenn es in der Funktion so aussieht. > Solange man keine Referenzen darauf haben kann, klar, dann kann man es > transparent Kopieren, ohne anderswo die Referenzen anpassen zu müssen, > ist dann also trivial Kopierbar. Aber das ist ja nicht, was da behauptet > wird. Oder geht es da nur um Daten, die selbst vollständig in ein > Register passen, also nicht um Referenzen? Oder liegen die Daten > vielleicht alle immer auf dem Heap? Es gibt keine Referenzen in Carbon.
MaWin schrieb: >> Immer mehr Geräte und insbesondere auch >> Teilfunktionen von Geräten besitzen einen µC. > > Eben. Das beschränkt sich aber nicht auf Embedded. Überall wächst die > Komplexität. Sicher tut sie das. Aber wie schon gesagt: PC-Anwenungen und Handy-Apps machen nur einen kleinen Teil der gesamten entwickelten Software aus. > Davon abgesehen sind die Programmgrößen auf Embeddedgeräten winzig im > Vergleich zu dem, was auf "richtigen" Rechnern läuft. Auch auf "richtigen" Rechnern läuft sehr viel embedded Code. In und um einen PC herum gibt es massig µCs, sei es in der SSD, in der Tastatur, dem Monitor, der Webcam, dem Drucker oder auch nur für die Bling-Bling-LED-Steuerung. Und so sieht es inzwischen bei immer mehr Geräten aus, von so Dingen wie Autos ganz zu schweigen. Da ist ein Sensor eben nicht mehr analog angebunden, sondern hat einen eigenen µC und kommuniziert per Bus-System. > Du musst schon Smartphones zu Embedded mit hinzuzählen, damit deine > Massen-Argumentation halbwegs hinkommen könnte. Die zähle ich dazu, aber nicht den SOC, auf dem das Betriebssystem und die Apps laufen, sondern die zahlreichen µCs, die da noch nebenher ihren Dienst tun, im GPS, im WLAN-Modul, im Mobilfunkmodul, in der Kamera, im BMS, in der SIM-Karte, der µSD-Karte, ja inzwischen sogar im Mikrofon und vermutlich noch vielen weiteren Komponenten. Ich habe den Eindruck, dass du gar keine Vorstellung davon hast, an wie vielen Stellen embedded-Code heute seinen Dienst tut. > Und wenn du das tust, dann würde ich mal gerne die C-Dominanz auf diesen > Geräten erklärt bekommen. Die genannten Dinge werden meines Wissens hauptsächlich in C programmiert. Hast du da andere Informationen? > Rolf M. schrieb: >> Ich würde einen Kernel nicht unbedingt als "gewöhnliche PC-Anwendung" >> bezeichnen. > > Gut, gut. Und welche nach deiner Definition "gewöhnlichen" > PC-Anwendungen werden heute so noch in C entwickelt? Lies nochmal den Satz, auf den du geantwortet hattest, als du den Kernel erwähnt hast. Da ging es gar nicht um C, sondern um Rust. > C hat fertig. Es ist ein Zombie. Jede Minute, die ihr noch an der > C-Brust weiternuckelt, könnt ihr nicht investieren, um zukunftsfähig zu > werden. Ich mache tatsächlich nicht mehr viel in C. Ich programmiere im Wesentlichen in C++ und ab und zu ein bisschen in Python. Mehr Sprachen brauche ich aktuell nicht.
Mombert H. schrieb: > Es gibt keine Referenzen in Carbon. Das konzept der Referenzierung ist aber trotzdem relevant. Eine Referenz auf etwas ist generell einfach etwas, was sich auf etwas bezieht / darauf zeigt. Auch wenn Carbon kein Sprachkonstrukt hat, dass es Referenz nennt, ist es dennoch sinvoll zu betrachten, wann etwas woanders referenziert sein kann und wann nicht, usw. Das, zusammen mit was wo wann geändert werden kann, ist ja gerade, was diese interessante calling convention gefahrlos ermöglicht. Ausserdem, nur so nebenbei, carbon hat Pointer: https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#pointer-types Und die können nicht 0 sein, und keine poiter arithmetic. Pointer in Carbon sind also so ziemlich das selbe, wie Referenzen in C++. Ich denke es wäre daher nichteinmal falsch zu sagen, dass Carbon referenzen hat. Abgesehen von der Syntax gefällt mir Carbon eigentlich recht gut. Das ein oder andere könnte man vielleicht noch streichen, aber insgesammt sieht es recht nett aus. Vielleicht probier ich es sogar mal aus, wenn ich dafür zeit finde.
Rolf M. schrieb: > Ich habe den Eindruck, > dass du gar keine Vorstellung davon hast, an wie vielen Stellen > embedded-Code heute seinen Dienst tut. Keine Sorge. Ich bin hauptberuflich Embedded-SW-Entwickler. Rolf M. schrieb: > Hast du da andere Informationen? Solange du keine belastbaren Zahlen lieferst, bleibe ich bei meiner Einschätzung. Denn dein "Argument" kann ich einfach Spiegeln: Ich habe den Eindruck, dass du gar keine Vorstellung davon hast, an wie vielen Stellen nicht-embedded-Code heute seinen Dienst tut. Das ist genau so nichtssagend, wie deines. Zwei Statistiken, nach denen beide C und C++ weit von der Führungsposition entfernt sind, habe ich geliefert. Interpretierte Sprachen führen vor allem, nach diesen Statistiken. Jetzt kommst du mit deinem Argument, dass Embedded führt. Wenn C angeblich weiter verbreitetet ist als die typischen highlevel (teils interpretierten) Anwendungssprachen, dann müssen ja die Statistiken falsch sein. Achso und: Die Anzahl der Devices spielt übrigens keine Rolle bei dieser Betrachtung. Wenn ich 100 Milliarden Devices ausliefere mit jeweils 1000 Zeilen identischem Code, dann sind das 1000 Zeilen Code insgesamt. Rolf M. schrieb: > Ich programmiere im > Wesentlichen in C++ und ab und zu ein bisschen in Python Das ist ja ein Ding. Und der Rest der Welt hängt auf C fest. Ganz bestimmt ist das so.
Daniel A. schrieb: > Mombert H. schrieb: >> Es gibt keine Referenzen in Carbon. > Das konzept der Referenzierung ist aber trotzdem relevant. Eine Referenz > auf etwas ist generell einfach etwas, was sich auf etwas bezieht / > darauf zeigt. > Auch wenn Carbon kein Sprachkonstrukt hat, dass es Referenz nennt, ist > es dennoch sinvoll zu betrachten, wann etwas woanders referenziert sein > kann und wann nicht, usw. Das, zusammen mit was wo wann geändert werden > kann, ist ja gerade, was diese interessante calling convention gefahrlos > ermöglicht. Wo ist denn dann jetzt dein Problem mit #3? Daniel A. schrieb: > Ausserdem, nur so nebenbei, carbon hat Pointer: > https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/README.md#pointer-types > Und die können nicht 0 sein, und keine poiter arithmetic. Pointer in > Carbon sind also so ziemlich das selbe, wie Referenzen in C++. > Ich denke es wäre daher nichteinmal falsch zu sagen, dass Carbon > referenzen hat. Das ist etwas zu stark vereinfacht. Welche Addresse hat eine C++ Referenz? Welchen Wert hat sie und kann man ihn ändern? Wie sieht das bei einem C++ Pointer aus? Gibt es vielleicht doch ein paar mehr Unterschiede als "können nicht 0 sein"?
Mombert H. schrieb: > Das ist etwas zu stark vereinfacht. Welche Addresse hat eine C++ > Referenz? Welchen Wert hat sie und kann man ihn ändern? Wie sieht das > bei einem C++ Pointer aus? Gibt es vielleicht doch ein paar mehr > Unterschiede als "können nicht 0 sein"? Seit wann definiert C++ was eine "Referenz" ist?
MaWin schrieb: > Mombert H. schrieb: >> Das ist etwas zu stark vereinfacht. Welche Addresse hat eine C++ >> Referenz? Welchen Wert hat sie und kann man ihn ändern? Wie sieht das >> bei einem C++ Pointer aus? Gibt es vielleicht doch ein paar mehr >> Unterschiede als "können nicht 0 sein"? > Seit wann definiert C++ was eine "Referenz" ist? Tut es nicht. Aber hättest du zwei Zeilen früher mit dem Lesen begonnen, hättest du viellecht gesehen, dass Daniel explizit mit C++ Referenzen verglichen hat.
:
Bearbeitet durch User
Mombert H. schrieb: > Wo ist denn dann jetzt dein Problem mit #3? Keins mehr, hat sich mittlerweile geklärt.
Mombert H. schrieb: > Aber hättest du zwei Zeilen früher mit dem Lesen begonnen, > hättest du viellecht gesehen, dass Daniel explizit mit C++ Referenzen > verglichen hat. Weil du behauptet hast Carbon hätte keine Referenzen. Er hätte es auch mit Rust oder weiß der Kuckuck vergleichen können. Merkste deinen Fehlschluss jetzt? Natürlich hat Carbon Referenzen. Sie nennen es nur nicht so.
MaWin schrieb: > Mombert H. schrieb: >> Aber hättest du zwei Zeilen früher mit dem Lesen begonnen, >> hättest du viellecht gesehen, dass Daniel explizit mit C++ Referenzen >> verglichen hat. > Weil du behauptet hast Carbon hätte keine Referenzen. > Er hätte es auch mit Rust oder weiß der Kuckuck vergleichen können. Hat er aber nicht. Und ich habe nicht auf "er hätte ja" geantwortet. > Merkste deinen Fehlschluss jetzt? > Natürlich hat Carbon Referenzen. Sie nennen es nur nicht so. Kein Fehlschlus und ich bleibe dabei. Carbon hat aktuell keine Referenzen. Carbon hat Pointer. C++ hat Referenzen und Pointer. C hat Pointer. Für mich gibt es einen deutlichen Unterschied zwischen dem Konzept Pointer und Referenz. Wenn diese Konzepte in einer anderen Sprache anders heißen ist das Ok, dann sollte man die Sprache aber nennen, wenn es vorher explizit um Carbon und C++ ging.
MaWin schrieb: > Jetzt kommst du mit deinem Argument, dass Embedded führt. Da drehst du mir aber das Wort im Mund rum. Das hab ich nicht behauptet. > Wenn C angeblich weiter verbreitetet ist als die typischen highlevel > (teils interpretierten) Anwendungssprachen, dann müssen ja die > Statistiken falsch sein. Auch das hab ich nicht behauptet. Viel mehr hast du behauptet, C sei kaum noch relevant und würde weiter an Bedeutung verlieren. Dazu hast du dann aber ausgerechnet die Bereiche, wo C am weitesten verbreitet ist, nämlich embedded und Systemprogrammierung, ausgeschlossen, da es sich dabei ja nur um Nischen handle. Das sehe ich anders. > Rolf M. schrieb: >> Ich habe den Eindruck, >> dass du gar keine Vorstellung davon hast, an wie vielen Stellen >> embedded-Code heute seinen Dienst tut. > > Keine Sorge. Ich bin hauptberuflich Embedded-SW-Entwickler. Dann ist es besonders erstaunlich, dass du diesen Bereich für irrelevant hältst. MaWin schrieb: > Mombert H. schrieb: >> Das ist etwas zu stark vereinfacht. Welche Addresse hat eine C++ >> Referenz? Welchen Wert hat sie und kann man ihn ändern? Wie sieht das >> bei einem C++ Pointer aus? Gibt es vielleicht doch ein paar mehr >> Unterschiede als "können nicht 0 sein"? > > Seit wann definiert C++ was eine "Referenz" ist? In C++ ist eine Referenz einfach ein anderer Name für ein bestehendes Objekt. Sie hat keinen Wert und keine Adresse. Jegliche Zugriffe auf die Referenz sind dementsprechend gleichbedeutend mit den entsprechenden Zugriffen auf das referenzierte Objekt. Ein Compiler kann Referenzen natürlich über einen versteckten Zeiger implementieren und tut das an manchen Stellen auch. Aber das ist ein Implementationsdetail, das vom C++-Standard nicht gefordert wird.
Rolf M. schrieb: > Dazu hast du dann aber ausgerechnet die > Bereiche, wo C am weitesten verbreitet ist, nämlich embedded und > Systemprogrammierung, ausgeschlossen, da es sich dabei ja nur um Nischen > handle. Das sehe ich anders. Es ist schon ziemlich krass, was du mir in den Mund legst. Dir ist bewusst, dass man hier alles nachlesen kann? Ich habe gar nichts "ausgeschlossen". Ich habe gesagt, dass C in allen Bereichen AUßER Embedded- und System bereits nicht mehr relevant ist. Und, dass C auch insgesamt nicht mehr führend und auch absteigend ist. Nicht mehr, und nicht weniger. Du siehst jetzt hoffentlich den Unterschied zu > "nämlich embedded und > Systemprogrammierung, ausgeschlossen, da es sich dabei ja nur um Nischen > handle Das ist nie gesagt worden, außer von dir.
Es gibt jetzt Syntaxhighlighting für Vim und Neovim: https://github.com/carbon-language/carbon-lang/commits/52f80c25ab79773260b618e12774d57fa661ecb4/utils/vim/syntax/carbon.vim Damit haben die Carbon-Entwickler einen entscheidenden für den produktiven Einsatz von Carbon getan :)
Yalu X. schrieb: > Es gibt jetzt Syntaxhighlighting für Vim und Neovim: > > Damit haben die Carbon-Entwickler einen entscheidenden für den > produktiven Einsatz von Carbon getan :) https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-integrated-development-environment Das sehe ich unironisch ganz genau so. 24%
Und Carbon ist in C programmiert, nicht Assembler, Pascal, Basic, Fortran oder so. Daher ist C, bzw. C++, zu lernen weiterhin eine gute Basis, auch wenn danach nur Carbon verwendet werden sollte.
MaWin schrieb: > Es ist schon ziemlich krass, was du mir in den Mund legst. Das müsste eher ich sagen. > Dir ist bewusst, dass man hier alles nachlesen kann? > Ich habe gar nichts "ausgeschlossen". Ich habe gesagt, dass C in allen > Bereichen AUßER Embedded- und System bereits nicht mehr relevant ist. Du schriebst: MaWin schrieb: > Es reicht aus, um die Bedeutung der Sprache auf von World-domination auf > ein wenige Nischengebiete zu reduzieren. Das ist, was bereits mit C > passiert ist. und: MaWin schrieb: > C wird nur noch in der Embedded- und Systemprogrammierung verwendet und > in Altprojekten. Das klingt, als ob du sagen willst, dass embedded und Systemprogrammierung nicht der Rede wert sei und du sie daher genau wie die Altprojekte nicht weiter betrachtest. Wenn du das nicht gemeint hast, war es wohl einfach ein Missverständnis. > Und, dass C auch insgesamt nicht mehr führend und auch absteigend ist. Du schriebst, es würde nur noch in Nischen genutzt werden (siehe oben). Das ist etwas anderes als "nicht mehr führend".
Zumindest in meiner Welt ist vieles vom C++-Code eigentlich nur C-Code (vielleicht noch ein bisschen C++ifiziert, 5-10% oder so). Aus meiner Sicht zählt sowas trotzdem zur Verbreitung von C, auch wenn man einen C++-Compiler benutzen muss. Und oben wurden fast 25% für die Verbreitung von C/C++ genannt, definitiv kein "fast tot". Und was die Diskussion um Kernel angeht: Ja, ich gehe davon aus, dass wir in ein paar Jahren auch Betriebssystemkernel in Javascript sehen werden. Die laufen dann zwar auch nur im Browser, aber da läuft sowieso inzwischen fast alles. Inklusive Windows 95.
S. R. schrieb: > Javascript Das ist auch in C/C++ programmiert. D.h. an den darunter liegenden Grundlagen ändert sich nichts.
S. R. schrieb: > Und was die Diskussion um Kernel angeht: Ja, ich gehe davon aus, dass > wir in ein paar Jahren auch Betriebssystemkernel in Javascript sehen > werden. Die laufen dann zwar auch nur im Browser, aber da läuft sowieso > inzwischen fast alles. Eher WebAssembly (was man übrigens auch aus C oder C++ generieren kann)
WebAssembly, zumindest im Browser, kann immernoch nur 1 memory für das gesamte Programm. Sachen wie (DMA)buffer sharing, shmem, eine page 2mal hintereinander mappen als Ringbuffer, Dateien mmappen, also diverse mmap Sachen, kann man damit, zumindest im browser, leider noch nicht implementieren... (Auch für multithreading ist es ein Problem, ein memory kann als shareded erstellt werden, und geshart zwischen js workern, aber wenn man nur 1 memory haben kann, naja, ist es entweder oder...) Ich denke das ist die grösste Limitation, die das zeug momentan hat. Wenn das nicht währe, könnte man vermutlich so ziemlich alles unverändert für WebAssembly cross compilieren, mit einer geeigneten runtime. Vielleicht probier ich dass dann mal wieder. Ich hoffe, dass irgendwann ein WASM builds von Debian userspace existieren wird, es wäre echt cool, dann könnte man einfach eine Anwendung aus dem Debian Repo auf einer Webseite einbinden, oder gleich eine ganze DE starten, ohne Vollemulation. Der Proposal dafür ist zwar mittlerwerile in der "Implementation" phase, also vielleicht gibt es das ja endlich bald. Ich muss mir auch mal diese "reference-types" Anschauen, als ich WASM vor einigen Jahren zuerst angeschaut hatte, gab es das noch nicht.
Rolf M. schrieb: > Das klingt, als ob du sagen willst, dass embedded und > Systemprogrammierung nicht der Rede wert sei und du sie daher genau wie > die Altprojekte nicht weiter betrachtest. Nein. Das steht mit keinem Wort so da. Es steht sogar genau das Gegenteil dort: C ist weiterhin relevant in Embedded- und Systemprogrammierung. Ich glaube du hängst dich viel zu viel an dem Wort "Nische" auf und interpretierst da alle möglichen Wertungen hinein. Es ist einfach nur eine Beschreibung eines "Gebiets" oder eines "Umfelds" oder eben einer "Nische". Da ist keinerlei Wertung drin. > Wenn du das nicht gemeint > hast, war es wohl einfach ein Missverständnis. Genau so ist es. Ich glaube ich habe das Missverständnis nun auch verstanden und es tut mir leid. Ich werde das Wort Nische einfach nicht mehr verwenden, weil das offenbar zu viel Interpretationsspielraum hat. Rolf M. schrieb: > Eher WebAssembly (was man übrigens auch aus C oder C++ generieren kann) Und natürlich aus Rust auch. ;)
Einfach mal wuehlen: https://github.com/carbon-language/carbon-lang https://github.com/carbon-language/carbon-lang/blob/trunk/README.md https://github.com/carbon-language/carbon-lang/find/trunk Languages: C++ 82.8% Python 9.2% Starlark 6.4% JavaScript 0.7% Vim Script 0.3% Shell 0.3% Other 0.3%
MaWin schrieb: > Ich glaube du hängst dich viel zu viel an dem Wort "Nische" auf und > interpretierst da alle möglichen Wertungen hinein. Eigentlich nur eine: Eine Nische ist etwas sehr kleines.
die syntax scheint kurz und knackig zu sein, aber ohne richtige alg. datentypen und somit ohne pattern matching ... das sind 80-ger
Daniel -. schrieb: > die syntax scheint kurz und knackig zu sein, aber ohne richtige alg. > datentypen > und somit ohne pattern matching ... das sind 80-ger Was genau meinst du mit "richtige alg. datentypen" und was erwartest du unter "pattern matching"?
Mombert H. schrieb: > was erwartest du unter "pattern matching"? Ich vermute er erwartet pattern matching.
Mombert H. schrieb: > Was genau meinst du mit "richtige alg. datentypen" und was erwartest du > unter "pattern matching"? Naja, bin zwar nicht "Daniel", aber er meint sicherlich algebraische Datentypen. Und von Pattern Matching könnte im Jahr 2022 jeder der ernsthaft programmiert, schon mal was gehört haben... https://de.wikipedia.org/wiki/Pattern_Matching#Programmierung
Experte schrieb: > Mombert H. schrieb: >> Was genau meinst du mit "richtige alg. datentypen" und was erwartest du >> unter "pattern matching"? > Naja, bin zwar nicht "Daniel", aber er meint sicherlich algebraische > Datentypen. Und explizit welche sind das genau? Es gibt soweit ich weiß kein Naturgesetzt, dass die "algebraischen Datentypen" definiert. Die, an die ich denke, werden in der Design-Doku beschrieben, oder zumindest erwähnt. MaWin schrieb: > Mombert H. schrieb: >> was erwartest du unter "pattern matching"? > Ich vermute er erwartet pattern matching. Experte schrieb: > Und von Pattern Matching könnte im Jahr 2022 jeder der ernsthaft > programmiert, schon mal was gehört haben... > https://de.wikipedia.org/wiki/Pattern_Matching#Programmierung Also sowas wie hier https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/pattern_matching.md die Anfänge beschrieben werden? Man sollte meinen, dass jemand der ernsthaft programmiert, die Doku lesen kann. Oder habt ihr erwartet, dass der Teil der Sprache schon fertig ist? Ist das der wichtigste Teil einer neuen Sprache und muss zuerst definiert werden?
:
Bearbeitet durch User
MaWin schrieb: > Mampf F. schrieb: >> Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - >> ist also quasi schon so gut wie tot ;-) > > So sehe ich das (unironisch) auch. 13% Market share bedeutet, dass 87% > nicht in C geschrieben ist. Insbesondere, wenn man die enorme Menge an > C-legacy-Code sieht, die es natürlich noch lange geben wird, ist das ein > vergleichsweise kleiner Anteil. > Es ist der absteigende Ast. Und das seit Jahrzehnten. > > Mampf F. schrieb: >> Daher sehe ich die höchste Relevanz für die Zukunft in Rust, weil es >> wirklich mal Probleme beseitigt hat und trotzdem auf dem Level von C und >> C++ mitspielen kann. > > Das sehe ich ähnlich. > Aber ich gehe nicht so weit und spreche Carbon das Existenzrecht ab, wie > einige das hier tun. Ob Carbon eine Zukunft hat, kann man nur > herausfinden, indem man es weitertreibt. Und vieleicht kommt ja etwas > bei rum, was uns weiterbringt. Selbst wenn es nur ein innovatives > Teilkonzept ist, was dann in andere Sprachen übertragen werden kann. > Es war schon immer so, dass Sprachen sich gegenseitig beeinflussen und > befruchten. Mir kommt vor die Statistik hinkt möglicherweise. Wenn also da steht, dass C "nur" 13% Market share hat, ist das nicht unbedingt realistisch oder vielleicht eher eine Verzerrung des Gesamtbildes. Viele neuzeitlichen Apparate werden mit Internet Fähigkeiten konzipiert die naturgemäß viele Zusatzfunktionen braucht die einfachere 8-bit Systeme ohne dem nicht benötigen. Die Frage müsste dann so gestellt werden, den Market share nach uC Größe und Anwendung aufzuteilen. Der Anteil an C dürfte dann möglicherweise bedeutend höher für einfachere 8-Bit Systeme sein als für komplexe Neuzeitsachen mit Netzanbindung und Co. Was aber höchstwahrscheinlich ausschlaggebender ist, welche der uC und Sprachen kommerzielle Werkzeuge und zertifizierte Bibliotheken hat. Mangels Recherche habe ich natürlich nicht die Fakten zur Hand, aber solange die Werkzeugplatzhirsche die neuen Sprachen nicht unterstützt wird man bei C und C++ für viele Anwendungen bleiben. Die Kunden werden schon wissen warum sie jedes Jahr die teuren Unterstützungskosten bezahlen. Auch sind im industriellen Umfeld noch gewaltige (zertifizierte) Altlasten da, die auch noch unterstützt werden müssen. Es gibt noch genug andere gute Gründe warum man in der Industrie langsam mit der Zeit gehen will und nicht andauernd (leichtsinnig) auf neue Pferde setzen möchte. Ich sehe wenig Grund, sich fanatisch mit Paradigmenwechsel abzugeben. Wenn Deadlines und Produktivität den Horizont erleuchten, dann tut man besser mit den Werzeugen und Sprachen und Ressourcen zu arbeiten anstatt andauernd Neuland zu beschreiten und Umwege machen zu müssen. Ich vermute eher, daß normale Generationenkonflikte für die andauernden Unruhen sorgen. Erst wenn die "Alten" ausgestorben oder zumindest pensioniert sind, wird ein Wandel gemächlich die Sprachenszene verändern. Die Wahrheit ist, die Alten wollen einfach ihre Ruhe haben und die anfallenden Sachen schnell abhaken. Die Jungen dagegen, lieben das Neue und das Spielen. War schon immer so und ich war früher genau so. Mit dem Alter legt sich das aber etwas und man will dann einfach meist nur seine Ruhe haben und mit dem zu arbeiten, dass man aus den Hemdsärmeln beherrscht. Abgesehen davon lernt man im Alter nicht mehr so leicht. Warum soll ich nicht zugeben, dass ich starrsinnig, voreingenommen, faul und gefrässig bin:-) Ok, Feuer frei:-)
:
Bearbeitet durch User
Egal wie die sprache heisst und wie der hype ist, wenn dein IQ unter 120 ist dann vergiss das mit dem programmieren ganz schnell. Du kannst ja webdesign oder andere einfachstsachen machen.
Wenn ich Sprachen wie Carbon, Rust und Go sehe dann wunder ich mich immer was in dem Hirn des Entwicklers vorging als er sich den Namen ausgedacht hat. Vermutlich wollte sein Unterbewusstsein das die Sache gegen die Wand faehrt weil man so beim suchen im Internet zum maximalen Misserfolg kommt. :) Aber okay, "C" war auch kein besonders weitblickender Name. Vielleicht sollten wir alle "Plankalkül" verwenden. Wuerde ich eine neue Sprache erfinden so wuerde die "tobowombo" heissen. (Keine Sucherergebnisse bei Google!) Olaf
Olaf schrieb: > Wenn ich Sprachen wie Carbon, Rust und Go sehe dann wunder ich mich > immer was in dem Hirn des Entwicklers vorging als er sich den Namen > ausgedacht hat. Das haben sie sich bei Microsoft abgeschaut. Deren Software ist mit so Namen wie "Word", "Teams" oder "Explorer" auch nicht gerade sehr innovativ benannt.
Carbon: Am Fahrrad absolut dufte aber beim Computer nein danke! Wir sollten generell Computer abschaffen!
Willhelm T. schrieb: > wenn dein IQ unter 120 ist dann vergiss das mit dem programmieren ganz > schnell. Hast du denn einen IQ Test gemacht?
Olaf schrieb: > Wenn ich Sprachen wie Carbon, Rust und Go sehe dann wunder ich mich > immer > was in dem Hirn des Entwicklers vorging als er sich den Namen ausgedacht > hat. Vermutlich wollte sein Unterbewusstsein das die Sache gegen die > Wand faehrt weil man so beim suchen im Internet zum maximalen Misserfolg > kommt. :) Du hast es ja nicht einmal ausprobiert. Rust: 1) Gemeinde Rust. 2) The Rust Programming Language Carbon: Auf der ersten Seite unten: Carbon Programmiersprache Was erwartest du noch?
Willhelm T. schrieb: > wenn dein IQ unter 120 ist dann vergiss das mit dem programmieren ganz schnell. Programmieren könnte jeder, wenn er den wollte. Man braucht nur das richtige Mindset. Man muss nur das, was man will, in kleine Abläufe / Schritte aufteilen, die umsetzen, und richtig kombinieren. Etwas Kochen, etwas Zeichnen, etwas Bauen, ist alles recht ähnlich, wie etwas Programmieren. Man muss etwas vorausscheuen, was man braucht, und wo man was hinsetzt / was man rein tut. Aber man ist sehr flexibel, und kann eigentlich machen, was auch immer man will / gerade Lust hat. Und wenn man etwas Erfahrung gesammelt hat, schmeckt die Suppe am Schluss auch. Die Leute heutzutage können nur nicht programmieren, weil sie sich damit, und mit Computern generell, überhaupt nicht auseinandersetzen wollen. Stattdessen wollen sie alles als Magische Zauberkisten verstehen, und glauben Code währe eine unverstehbere, komplexe Sonderzeichengrütze, ohne überhaupt je eine Zeile echten Code angesehen zu haben. Es sei ja alles zu kompliziert, reden sie sich ein / raus. Aber tatsächlich ist es extrem simpel. Es kann jenachdem viel Arbeit sein / Zeit brauchen, ein Programm zu schreiben. Aber kompliziert ist am Programmieren nun wirklich nichts. (Zumindest nicht, solange man nicht versucht eine Sprache wie z.B. APL, Brainfuck / OOK oder Rust zu verwenden).
DPA schrieb: > Programmieren könnte jeder, wenn er den wollte. Man braucht nur das > richtige Mindset. Man muss nur das, was man will, in kleine Abläufe / > Schritte aufteilen, die umsetzen, und richtig kombinieren. Etwas Kochen, > etwas Zeichnen, etwas Bauen, ist alles recht ähnlich, wie etwas > Programmieren. Das habe ich auch mal gedacht aber ich glaube das stimmt nicht. Eine Aufgabe on Teilaspekte zerlegen und sie logisch zu analysieren können viele nicht. Informationen suchen, aufnehmen, verarbeiten können sogar manche Akademiker nicht. Bei Google "Reis kochen" eingeben und die textuellen Anweisungen in konkrete Handlungen übersetzen ist zu viel für viele Leute. Die können sogar sehr intelligent sein, ein schockierend gutes Gedächtnis haben, aber eine eher intuitive Denkweise haben; irgendwo gibt es im Hirn eine "Lücke" zwischen "Eingabe" und "Handlung". Dazu kommt noch das Hantieren mit Zahlen, was manche einfach überhaupt nicht können.
Programmierer schrieb: > Eine Aufgabe on Teilaspekte zerlegen und sie logisch zu analysieren > können viele nicht. Das können konventionell Programmierende für gewöhnlich aber. Und sind auch nicht dumm. Und dennoch bleiben Rust & Co für viele uninteressant. Gerhard O. schrieb: > die anfallenden Sachen schnell abhaken geht konventionell mit vorhandener Erfahrung und Codebasis eben schneller als fortlaufend "Neuland" testend.
DPA schrieb: > Programmieren könnte jeder, wenn er den wollte. Man braucht nur das > richtige Mindset. Dieses "richtige Mindset" haben eben die meisten (erwachsenen) Menschen nicht. Und darum können sie eben genau nicht programmieren und werden es auch niemals mehr lernen. Den meisten Menschen verursacht der Gebrauch des eigenen Hirns dermaßen starke Schmerzen, dass sie so verängstigt sind, niemals wieder selbst nur einen einzigen eigenen Gedanken zu entwickeln oder zu einer eigener Schlussfolgerung zu kommen. Davon abgesehen ist "Programmieren" nur der erste Schritt. Software entwickeln, so dass jemand anderes den Kram versteht, oder der Kram nicht beim ersten lauen Lüftchen in sich zusammenfällt, können noch weniger. Es ist so wie mit der Muttersprache: Jeder Mensch spricht eine und kann sich irgendwie mit seinen Mitmenschen unterhalten. Aber erschreckend viele Menschen haben einen völlig verkümmerten (aktiven) Wortschatz. Stelle Dir vor, die Personen in Deinem Umfeld müssten eine Geschichte schreiben. Sagen wir mal, 20 DIN A4-Seiten. Was glaubst Du, wie viele bekämen die 20 Seiten überhaupt voll? Bei wie vielen würde auch nur eine einigermaßen zusammenhängende Geschichte zustande kommen? Du würdest Dich erschrecken, was für ein Kauderwelsch da produziert würde.
> auch nicht dumm. Und dennoch bleiben Rust & Co für viele uninteressant.
Das Problem von neuen Sprachen ist halt das sie neu sind. "Neu" fuehrt
zu einer Reihe von interessanten Problemen:
1. Massentraegheit in den Hirnen der vorhandenen Programmier.
Man ist ja meistens schon gut ausgelastet und kann seine
Probleme mit dem vorhandenen loesen. Warum also weitere
Muehen aufwenden?
2. Altlasten die man unterstuetzen muss. Jeder der als
Anfaenger eine neue Sprache lernt der MUSS zwingend auch
alte Sprachen wie C oder C++ lernen weil es eine gigantische
vorhandene Codebasis gibt die weiterhin unterstuetzt werden
muss.
3. Zumindest im Deutschprachigen habe ich den Eindruck als wenn
sogenannte Fachbuecher bewusst schwer lesbar geschrieben
werden. Man braucht da oft das Umfeld und den Mindset eines
Informatikstudiums um dem folgen zu koennen. Das ist im
Englischen besser. Aber etwas in einer Fremdsprache zu lernen
macht es einem Anfaenger auch nicht einfacher.
Das war frueher mal besser als wir im Kinderzimmer am ZX Spektrum
oder C64 gesessen haben!
4. Neue Sprachen bieten Definitionsgemaess ein viel kleineres
Umfeld von Leuten die man Fragen kann oder wo man abschreiben kann.
Klar Internet hilft, aber Internet hilft bei etablierten Sprachen
halt 100x mehr.
5. Das Problem von Sprachen wie C oder C++ ist letztlich das sie
einem extrem viele Freiheiten bieten. Zum guten lernen dieser
Sprachen gehoert es auch bewusst auf so manches zu verzichten.
(vgl. MISRA)
Eine neue Sprache wird deshalb gerne als neu/gut angesehen
weil sie den Anwender bewusst in die richtige Richtung zwingt.
Es fuehlt sich aber nicht unbedingt gut an immer gezwungen zu
werden. .-)
6. Mein Eindruck ist es das viel Druck auf den Einsatz von neuen
Sprachen von Firmen kommen denen es nicht passt das man
zum Programmieren tendenziell eher gut ausgebildete und teure
Fachkraefte braucht. Die haetten lieber billige und preiswerte
Menschen die man leichter austauschen kann.
Man koennte dann fragen ob komplexe und fehleranfaellige
Sprachen nicht langfristig besser fuer den eigenen Kontostand
sind.
Olaf
Olaf schrieb: > Wenn ich Sprachen wie Carbon, Rust und Go sehe dann wunder ich mich > immer > was in dem Hirn des Entwicklers vorging als er sich den Namen ausgedacht > hat. Vermutlich wollte sein Unterbewusstsein das die Sache gegen die > Wand faehrt weil man so beim suchen im Internet zum maximalen Misserfolg > kommt. :) Das ist überhaupt kein Problem. Die Konvention für die Suchmaschine ist Suffix "lang" dranhängen. Rustlang, Golang etc.
Berufsprogrammierer schrieb: > Stelle Dir vor, die Personen in Deinem Umfeld müssten eine Geschichte > schreiben. Sagen wir mal, 20 DIN A4-Seiten. Was glaubst Du, wie viele > bekämen die 20 Seiten überhaupt voll? Bei wie vielen würde auch nur eine > einigermaßen zusammenhängende Geschichte zustande kommen? Ich kenne jemanden, der schreibt eine 600-seitige Dissertation mit 500 Literaturquellen. Der hat kein Problem über jedes x-beliebige Thema sofort 20 Seiten zu schreiben und Wörter einsetzen die du noch nie gehört hast. Der muss 1sec auf ein monumentales mittelalterliches Gemälde schauen und kann dir sofort sagen von wann und von wem es ist und dir jedes einzelne versteckte Symbol erläutern und wie es die zeitgenössischen religiösen Vorstellungen und Gedankenschulen widerspiegelt und welche moralischen Aussagen es enthält. Aber wenn die Homebanking-App anzeigt "Bitte geben Sie hier ihre Mobilfunknummer ein" weiß er nicht was er machen soll und gerät in Panik. Die Verbindung zwischen Anweisung und Handlung fehlt irgendwie.
Mombert H. schrieb: > Und explizit welche sind das genau? Es gibt soweit ich weiß kein > Naturgesetzt, dass die "algebraischen Datentypen" definiert. Die, an die > ich denke, werden in der Design-Doku beschrieben, oder zumindest > erwähnt. Im Kontext der Programmiersprachen sind das "sum types" und "product types". struct ist z.B. ein Produkttypen in C. Bei Summentypen hat C und C++ nur was halbgares zu bieten, nämlich enum und union. Mombert H. schrieb: > Also sowas wie hier > https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/pattern_matching.md > die Anfänge beschrieben werden? Man sollte meinen, dass jemand der > ernsthaft programmiert, die Doku lesen kann. Oder habt ihr erwartet, > dass der Teil der Sprache schon fertig ist? Ist das der wichtigste Teil > einer neuen Sprache und muss zuerst definiert werden? Typensystem lässt sich im Nachhinein schwer einbauen bzw. modifizieren. Das angegebene Beispiel war mir nicht bekannt, ist dennoch eher kosmetisch. Eine Funktion gibt 3 Werte zurück, die im match zerlegt werden. Richtiges pattern matching kann in die verschachtelten Datenstrukturen hineinschauen bzw. zerlegen. Die Sprachen der ML Familie wie Ocaml, F# (Beispiel unten) haben das aus meiner Sicht sauber gelöst. Haskel hat das ähnlich plus Lazy Datentypen on top. Bei Rust merkt man ebenfalls die ML Abstammung.
1 | // sum type |
2 | type S = S0 | S1 | S2 | S4 |
3 | |
4 | // product type tuple |
5 | type P = int*int*int |
6 | |
7 | // product type record syntax |
8 | type PR = {x1 : int; x2 : int; x3 : int}
|
9 | |
10 | // discriminated union |
11 | type DU = |
12 | | A |
13 | | B of int |
14 | | C of int*int*int |
15 | | D of int array |
16 | | E of int option |
17 | | F of float option |
> Der muss 1sec auf ein monumentales mittelalterliches > Gemälde schauen und kann dir sofort sagen von wann und von wem es ist > und dir jedes einzelne versteckte Symbol erläutern und wie es die > zeitgenössischen religiösen Vorstellungen und Gedankenschulen > widerspiegelt und welche moralischen Aussagen es enthält. Das ist der Grund warum Kunstwerke erst teuer (also wertgeschaetzt) werden wenn der Kuenstler Tod ist. Vorher ist das Risiko zu hoch das der Urheber dieser Interpretation widerspricht. Man kann jetzt natuerlich ueberlegen in wieweit das auch auf Programmiersprachen zutrifft. :-) Olaf
Olaf schrieb: > Das ist der Grund warum Kunstwerke erst teuer (also wertgeschaetzt) > werden wenn der Kuenstler Tod ist. Vorher ist das Risiko zu hoch > das der Urheber dieser Interpretation widerspricht. Haha, das stimmt, daher konzentrieren sich viele Experten auf alte Kunst, um sich nicht mit rezenten Künstlern herumschlagen zu müssen. Die können nämlich ganz schön kompliziert sein. Und es ist tatsächlich so dass Künstler sich oft traditioneller Symbolik und Bildsprache bedienen ohne es zu wissen und ohne den Kontext zu kennen. Und natürlich lügen Künstler auch gerne mal. Daher ist es gut wenn es Experten gibt die das kontextualisieren können. Olaf schrieb: > Man kann jetzt natuerlich ueberlegen in wieweit das auch > auf Programmiersprachen zutrifft. Tja, Aussagen, Erkenntnisse, Symbolik oder Wortwahlen zu kontextualisieren, oder absichtlichem Falsch-Verstehen vorbeugen, oder Verharmlosung aufzudecken oder Desinformation zu analysieren ist aktueller denn je.
Daniel -. schrieb: > Bei Summentypen hat C und C++ nur > was > halbgares zu bieten, nämlich enum und union. std::variant und std::any?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.