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/omrY53kbVoAWilhelm 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...
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
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.
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.
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?
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.
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:
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?
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...
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)
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 ...
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?
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).
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.
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.
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.
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.
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 wackeligYalu 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!
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.
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.
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++).
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.
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.
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:> 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. ;)
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.
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 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?
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:-)
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.
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.
> 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.
Thread beobachten
Seitenaufteilung abschalten