Forum: Compiler & IDEs Carbon - wie ist Eure Einschätzung?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Wilhelm M. (wimalopaan)


Lesenswert?

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?

von PittyJ (Gast)


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

Hier Chandler Carruths Talk dazu:
https://youtu.be/omrY53kbVoA

Wilhelm M. schrieb:
> Vielleicht kann aber jemand von Euch etwas dazu sagen?

Technisch was dazu zu sagen ist im aktuellen Stadium noch schwierig. Der 
Idee den AST zwischen C++ <-> Carbon stets abzugleichen um die Interop 
zu wahren kann ich aber einiges abgewinnen.

Ansonsten ist die Wahrscheinlichkeit dass daraus was wird wohl ziemlich 
groß. Man blicke nur auf Go, Kotlin und Dart...

: Bearbeitet durch User
Beitrag #7140041 wurde von einem Moderator gelöscht.
von Random .. (thorstendb) Benutzerseite


Lesenswert?

Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a. 
mit "var", "let" und "fn" verunstalten muss?
1
fn Foo() -> i64 {
2
  ...
3
4
fn Fibonacci(limit: i64) {
5
  var (a: i64, b: i64) = (0, 1);
6
  while (a < limit) {
7
    Console.Print(a, " ");
8
    let next: i64 = a + b;

Return multiple ... sinnvoll?
1
fn DoubleBoth(x: i32, y: i32) -> (i32, i32) {
2
  return (2 * x, 2 * y);
3
}
Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool" 
zurückliefern.

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

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.

von Harald W. (wilhelms)


Lesenswert?

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? :-)

von AA (Gast)


Lesenswert?

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

von Harald W. (wilhelms)


Lesenswert?

AA schrieb:

>> Und was macht man, wenn man Z erreicht hat? :-)
>
> AA

Iih!

von DerEgon (Gast)


Lesenswert?

Harald W. schrieb:
> Und was macht man, wenn man Z erreicht hat? :-)


Man nimmt längere Namen. "Carbon" fängt mit "C" an, schon gemerkt?

von Falk B. (falk)


Lesenswert?

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? ;-)

von fünf Kinder daheim (Gast)


Lesenswert?

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.

von Genusskoch (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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!

von MaWin (Gast)


Lesenswert?

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.

von können jedem das Genick brechen (Gast)


Lesenswert?

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.

von können jedem das Genick brechen (Gast)


Lesenswert?

Der arme Bjarne!

Alle zwei Jahre die Sprache verunstalten und es reicht immer noch nicht. 
Es ist immer noch zu wenig.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Random .. schrieb:
> Ich frage mich, warum man einfaches, lesbares C/C++ so kompliziert u.a.
> mit "var", "let" und "fn" verunstalten muss?

Um nicht mit der von Beginn an verkorksten syntaktischen Form von C und 
den von C abgeleiteten Sprachen weiter zu machen. Bei einer guten 
Grammatik ist ein Datentyp ein normaler Identifier wie eine Variable, 
dieser Identifier steht vor seiner Beschreibung, und die Typbeschreibung 
entwickelt sich linear, nicht verschachtelt.

Das macht ein reserviertes Wort erforderlich, ein Keyword, um 
Deklarationen einzuleiten. Ob das var/let/fn ist, oder Schnurzelfix, ist 
dann Geschmacksache.

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

Wilhelm M. schrieb:
> tritt an, ein paar Altlasten von xxx über Bord zu werfen und einige
> (wenige) Vorteile gegenüber xxx zu haben

Grundprinzip einer neuen Sprache.
Wenn da nicht die Einführung neuer Unzulänglichkeiten wäre.

Wie soll eine Sprache überhaupt noch führend werden können
wenn fortlaufend neue Sprachen Unzulänglichkeiten jener adressieren?
Unter dem Strich zersplittert die Sprachlandschaft immer mehr.
Vereinfacht das irgendwas?

Hat sich mit Carbon überhaupt irgendetwas Grundsätzliches verbessert?

: Bearbeitet durch User
von Jemand (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von er hat Jehova gesagt (Gast)


Lesenswert?

MaWin schrieb:
> Nein.
> Aber es verschlimmert auch nichts.

Der neue Turm zu Babel.

Und ihr merkt es nicht mal. Das ist sehr wohl ein Problem.

von MaWin (Gast)


Lesenswert?

er hat Jehova gesagt schrieb:
> Das ist sehr wohl ein Problem.

Warum? Könntest du das einmal an einem Beispiel ausführen?

von Rolf M. (rmagnus)


Lesenswert?

Random .. schrieb:
> Return multiple ... sinnvoll?fn DoubleBoth(x: i32, y: i32) -> (i32, i32)
> {
>   return (2 * x, 2 * y);
> }
> Da ist mir Pointer oder Reference lieber, und lasse die Funktion "bool"
> zurückliefern.

Ich hab mich früher öfter gefragt, warum man eigentlich beliebig viele 
Parameter, aber nur maximal einen Resturnwert haben kann. Diese 
Asymmetrie kam mir wenig sinnvoll vor. Warum findest du es besser, wenn 
du mehrere Werte zurückliefern willst, das indirekt über 
Pointer-Parameter zu machen, statt eben als Returnwerte. C++ bietet 
mehrere Returnwerte indirekt über Strukturen oder Tupel und unpacking 
auch, aber nicht sehr elegant.
Da würde die Funktion dann so aussehen:
1
#include <tuple>
2
#include <iostream>
3
4
std::tuple<int, int> DoubleBoth(int x, int y)
5
{
6
    return { 2 * x, 2 * y };
7
}
8
9
int main()
10
{
11
    auto [ x2, y2 ] = DoubleBoth(3, 5);
12
    std::cout << x2 << '/' << y2 << '\n';
13
}

(prx) A. K. schrieb:
> dieser Identifier steht vor seiner Beschreibung,

Warum?

: Bearbeitet durch User
von Ron T. (rontem)


Lesenswert?

MaWin schrieb:
> Aber es verschlimmert auch nichts

Die bloße Existenz sicher nicht.
Aber es ist doch klar daß sich das Angebot von Programmierern für eine 
bestimmte Sprache bei immer mehr verwendeten Sprachen zwangsläufig 
verkleinert (mal vom generellen Unterangebot an Programmierern ganz 
abgesehen). Und Du meinst immer noch "es verschlimmert auch nichts" ?

Als wesentliches Ziel wurde bei Carbon die C++ Kompatibilität und 
Weiterverwendbarkeit diesbezüglichen Codes genannt. Ob die dabei 
entstehenden Mischkonstrukte dadurch verständlicher und leichter 
handelbar werden? Sicher nicht - das steht vielmehr diametral 
entgegengesetzt dem Ziel effizienten, verständlichen Codes.

MaWin schrieb:
> Niemand muss neue Sprachen nutzen.

Carbon?

: Bearbeitet durch User
von Mombert H. (mh_mh)


Lesenswert?

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?

von Ron T. (rontem)


Lesenswert?

Mombert H. schrieb:
> Was würdest du tun, um das Ziel zu erreichen?

Sicher nicht dadurch ein um die andere Sprache aus dem Boden zu stampfen 
und gar kombinieren zu wollen. Aber vielleicht weißt Du ja warum Carbon 
nun die Offenbarung sein kann? Diesbezüglich bin ich hier nur 
Fragender...

: Bearbeitet durch User
von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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?

von Mombert H. (mh_mh)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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?

von Mombert H. (mh_mh)


Lesenswert?

Programmierer schrieb:
> Mombert H. schrieb:
>> Da steht
>> niergends das Wort Objekt sondern es ist die Rede von Werten und
>> Ausdrücken.
>
> Naja, Werte sind Objekte (in C++). Ausdrücke geben Werte (Objekte)
> zurück.

Nein zum ersten Satz und ja zum zweiten, wenn man die Klammer streicht.
Aus dem C++17 Standard Draft:
1
The constructs in a C++ program create, destroy, refer to, access, and manipulate objects. An object is
2
created by a definition (6.1), by a new-expression (8.3.4), when implicitly changing the active member of a
3
union (12.3), or when a temporary object is created (7.4, 15.2). An object occupies a region of storage in its
4
period of construction (15.7), throughout its lifetime (6.8), and in its period of destruction (15.7). [ Note:
5
A function is not an object, regardless of whether or not it occupies storage in the way that objects do.
6
— end note ] The properties of an object are determined when the object is created. An object can have a
7
name (Clause 6). An object has a storage duration (6.7) which influences its lifetime (6.8). An object has a
8
type (6.9). Some objects are polymorphic (13.3); the implementation generates information associated with
9
each such object that makes it possible to determine that object’s type during program execution. For other
10
objects, the interpretation of the values found therein is determined by the type of the expressions (Clause 8)
11
used to access them.

: Bearbeitet durch User
von Programmierer (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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"?

von Programmierer (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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

von Walter K. (walter_k488)


Lesenswert?

Harald W. schrieb:
>
>
> Und was macht man, wenn man Z erreicht hat? :-)

Dann sucht man sich korrupte Nachbarn - und beginnt dort mit Aufräumen

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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

von können jedem das Genick brechen (Gast)


Lesenswert?

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.

von Ein anderer Programmierer (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von Mombert H. (mh_mh)


Lesenswert?

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?

von Tilo R. (joey5337) Benutzerseite


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

Programmierer schrieb:
> Was möchte man da nicht mitschleppen?

Schrub ich doch. Die nicht vorhandene Memory- und Threadsafety.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Programmierer schrieb:
>> Hä? Seit C++11 ist sie vorhanden,
>
> Wenn der Programmierer sie denn verwendet.
>
>> in so ziemlich maximal möglicher Ausführung.
>
> Ja. In für *C++* maximal möglicher Ausführung. Das ist genau mein
> Kritikpunkt.
> Das wird nicht besser, wenn man "seamless integration" anstrebt in
> Carbon. Es wird dieses Manko erben.

Ich sehe nicht so ganz warum die Interaktion von Carbon mit C++ ein 
größeres Problem sein soll als die Interaktion von anderen Sprachen mit 
C (z.B. rust).

: Bearbeitet durch User
von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von DPA (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
>> Der rust Programmierer hat nur die Möglichkeit sie mit "unsafe" zu
>> nutzen oder sie nicht zu nutzen.
> Blödsinn.
> Um unsafe-APIs werden safe-Wrapper gebaut.
Du redest nur von der API. Mit diesem Wrapper kannst du nicht sicher 
machen was in der Blibliothek passiert. Sichere Wrapper für eine 
unsichere API kann man in nahezu jeder Sprache bauen. Das gleiche trifft 
erstmal für Carbon zu. Wenn du anderer Meinung bist, dann liefere mal 
eine etwas konkretere Erläuterung.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von Programmierer (Gast)


Lesenswert?

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!

von MaWin (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

MaWin schrieb:
> Korrekt. All dies ist Memory-Safe.

Na dann ist C++ auch memory safe. Glück gehabt!

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Dirk (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

Dirk schrieb:
> Fast alles was die meisten super tollen
> Sprachen der letzten Jahre angeblich haben ist in pascal seit Anfang an
> drin

Ziemlicher Unfug.

von Dirk (Gast)


Lesenswert?

Na dann klär mich mal auf.
Vielleicht habe ich ja was wichtiges verpasst.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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"

von DPA (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Hans (Gast)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von war nie wirklich weg (Gast)


Lesenswert?

MaWin schrieb:
> Also zum Beispiel von C++ auf eine schlankere Sprache wechseln.

Also doch back to C oder wie?

von Hans (Gast)


Lesenswert?

Man braut nur Java, der Rest ist Schnickschnack

von war nie wirklich weg (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

Mombert H. schrieb:
> Ok, dann nochmal die gleiche Frage. Wie würdest du eine Ablösung für C++
> entwickeln? Formuliere mal in ein paar Sätzen klare Ziele und
> Anforderungen.

Ja, Du machst es Dir schön einfach.
Soll doch der Kritisierende was besseres auf die Beine stellen, was 
besseres vorweisen. Utopisch. Also: Kritik verboten??? Oder mit anderen 
Worten: Du hälst die Entwicklung für dann doch eher für zwangsläufig.

Erstmal: Sieht man sich den Byte-Wust an den heutige Entwicklung so 
produziert ist doch schon fast jedem Laien klar daß dieselbe 
Funktionalität ganz grundsätzlich mit einem Bruchteil an Speicherplatz 
und Prozessorzeit auskäme wenn, ja wenn sie nur effizienter programmiert 
wäre. Ein tägliches Ärgernis nannte ich einen Beitrag zuvor.

Das wichtigste Ziel wäre jetzt ganz allgemein: Runter mit der 
Komplexität! D.h. Eindampfen des Sprachumfangs, Reduktion 
wechselseitiger Abhängigkeiten, drastische Vereinfachung der SW 
Interfaces zu Ausgaben aller Art bzw. fürs Netzwerk/Internet. 
Zugegebenermaßen reden wir dann nicht nur von der Programmiersprache 
sondern auch vom mehr oder weniger intelligenten Funktionsangebot von 
Betriebssystemen.

Das Kleinteilige, hochflexible ist gleichzeitig das was es so 
kompliziert macht.

: Bearbeitet durch User
von Mampf F. (mampf) Benutzerseite


Lesenswert?

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 😍

von Ein anderer Programmierer (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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?"

von MaWin (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

MaWin schrieb:
> Lösungen statt blafasel

Nun, es geht durchaus auch ganz global darum wie sinnvoll jedwede neue 
Sprache für dieselbe Hardware überhaupt sein kann. Es täte mir leid wenn 
Du meine Ansicht da in die Kategorie blafasel einordnest. Denn mit

> Also aufhören Dinge in C++ zu entwickeln.

erkennst Du immerhin an, daß es durchaus auch in der Natur der 
verwendeten Sprache liegt, welches Komplexitätslevel damit gezüchtet 
wird bzw. zu welchem sie verleitet.

Nun wäre ich meinerseits ganz wißbegierig, welchen konkreten Vorteil Du 
diesbezüglich bei Carbon siehst- denn das ist meines Erachtens hier 
langfristig die entscheidende Frage wenn es um Zukunftsfähigkeit geht.
Ist das alles eher evolutionär (wie ich glaube und was beileibe nicht 
reicht lang etablierten Sprachen den Garaus zu machen) oder steckt in 
Carbon der Funken einer Revolution? Ohne hier konkret zu werden sehe ich 
eher

> dein(en)
> Standpunkt mehr als wackelig

Yalu X. schrieb:
> wie hier einige vehement
> einer neuen Programmiersprache das Existenzrecht absprechen

Nein Yalu. Existenzrechte abzusprechen wäre doch etwas vermessen.
Die Sinnfrage zu stellen ist hingegen durchaus berechtigt.
Oder geht es nur darum sich "an neuen Konzepten" intellektuell zu 
erfreuen?
Da möchte ich nicht weiter stören!

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mampf F. (mampf) Benutzerseite


Lesenswert?

MaWin schrieb:
> C wird nur noch in der Embedded- und Systemprogrammierung verwendet und
> in Altprojekten.

Gibt Statistiken dazu:

https://www.tiobe.com/tiobe-index/

Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen - 
ist also quasi schon so gut wie tot ;-)

Aber, tbh, die letzten Jahre / Jahrzehnte kamen viele 
Programmiersprachen raus, aber die erste, die wirklich irgendwas ändern 
konnte, ist Rust.

Alles andere ist mehr oder weniger der gleiche Kram und die Konzepte 
sind alle gleich. Untereinander austauschbar usw ...

Daher sehe ich die höchste Relevanz für die Zukunft in Rust, weil es 
wirklich mal Probleme beseitigt hat und trotzdem auf dem Level von C und 
C++ mitspielen kann.

Und bei Carbon seh ich diesen Vorteil nicht - andere Syntax, gleiche 
grundlegende Krankheit.

Hier heißt es nur, sie versuchen und sie wollen usw ...

https://github.com/carbon-language/carbon-lang/blob/trunk/README.md#memory-safety

Bei Rust ist es garantiert, dass es memory safe ist und DAS grundlegende 
Konzept.

: Bearbeitet durch User
von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Vincent H. (vinci)


Lesenswert?

Carbon’s most exciting feature is its calling convention

https://www.foonathan.net/2022/07/carbon-calling-convention/

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von MaWin (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Ein anderer Programmierer (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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

von Yalu X. (yalu) (Moderator)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

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

von Dieter (Gast)


Lesenswert?

Soviel Palaver um Carbon, wo doch die Politik die Decarbonisierung 
beschlossen hat.

Steigt ab vom toten Pferd!

Geniesst den Sonntag!

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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?

von MaWin (Gast)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Daniel A. (daniel-a)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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"?

von MaWin (Gast)


Lesenswert?

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?

von Mombert H. (mh_mh)


Lesenswert?

MaWin schrieb:
> Mombert H. schrieb:
>> Das ist etwas zu stark vereinfacht. Welche Addresse hat eine C++
>> Referenz? Welchen Wert hat sie und kann man ihn ändern? Wie sieht das
>> bei einem C++ Pointer aus? Gibt es vielleicht doch ein paar mehr
>> Unterschiede als "können nicht 0 sein"?
> Seit wann definiert C++ was eine "Referenz" ist?
Tut es nicht. Aber hättest du zwei Zeilen früher mit dem Lesen begonnen, 
hättest du viellecht gesehen, dass Daniel explizit mit C++ Referenzen 
verglichen hat.

: Bearbeitet durch User
von Daniel A. (daniel-a)


Lesenswert?

Mombert H. schrieb:
> Wo ist denn dann jetzt dein Problem mit #3?

Keins mehr, hat sich mittlerweile geklärt.

von MaWin (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

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.

von Yalu X. (yalu) (Moderator)


Lesenswert?

Es gibt jetzt Syntaxhighlighting für Vim und Neovim:

  https://github.com/carbon-language/carbon-lang/commits/52f80c25ab79773260b618e12774d57fa661ecb4/utils/vim/syntax/carbon.vim

Damit haben die Carbon-Entwickler einen entscheidenden für den
produktiven Einsatz von Carbon getan :)

von MaWin (Gast)


Lesenswert?

Yalu X. schrieb:
> Es gibt jetzt Syntaxhighlighting für Vim und Neovim:
>
> Damit haben die Carbon-Entwickler einen entscheidenden für den
> produktiven Einsatz von Carbon getan :)

https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-integrated-development-environment

Das sehe ich unironisch ganz genau so.

24%

von Dieter (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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

von S. R. (svenska)


Lesenswert?

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.

von Dieter (Gast)


Lesenswert?

S. R. schrieb:
> Javascript

Das ist auch in C/C++ programmiert. D.h. an den darunter liegenden 
Grundlagen ändert sich nichts.

von Rolf M. (rmagnus)


Lesenswert?

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)

von Daniel A. (daniel-a)


Lesenswert?

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.

von MaWin (Gast)


Lesenswert?

Dieter schrieb:
> Und Carbon ist in C programmiert

Du hast es dir ja nicht einmal angeschaut.

von MaWin (Gast)


Lesenswert?

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

von Dieter (Gast)


Lesenswert?

Einfach mal wuehlen:
https://github.com/carbon-language/carbon-lang
https://github.com/carbon-language/carbon-lang/blob/trunk/README.md
https://github.com/carbon-language/carbon-lang/find/trunk

Languages:
C++ 82.8%
Python 9.2%
Starlark 6.4%
JavaScript 0.7%
Vim Script 0.3%
Shell 0.3%
Other 0.3%

von Rolf M. (rmagnus)


Lesenswert?

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.

von Daniel -. (root)


Lesenswert?

die syntax scheint kurz und knackig zu sein, aber ohne richtige alg. 
datentypen
und somit ohne pattern matching ... das sind 80-ger

von Mombert H. (mh_mh)


Lesenswert?

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"?

von MaWin (Gast)


Lesenswert?

Mombert H. schrieb:
> was erwartest du unter "pattern matching"?

Ich vermute er erwartet pattern matching.

von Experte (Gast)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

Experte schrieb:
> Mombert H. schrieb:
>> Was genau meinst du mit "richtige alg. datentypen" und was erwartest du
>> unter "pattern matching"?
> Naja, bin zwar nicht "Daniel", aber er meint sicherlich algebraische
> Datentypen.
Und explizit welche sind das genau? Es gibt soweit ich weiß kein 
Naturgesetzt, dass die "algebraischen Datentypen" definiert. Die, an die 
ich denke, werden in der Design-Doku beschrieben, oder zumindest 
erwähnt.

MaWin schrieb:
> Mombert H. schrieb:
>> was erwartest du unter "pattern matching"?
> Ich vermute er erwartet pattern matching.

Experte schrieb:
> Und von Pattern Matching könnte im Jahr 2022 jeder der ernsthaft
> programmiert, schon mal was gehört haben...
> https://de.wikipedia.org/wiki/Pattern_Matching#Programmierung
Also sowas wie hier
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/pattern_matching.md
die Anfänge beschrieben werden? Man sollte meinen, dass jemand der 
ernsthaft programmiert, die Doku lesen kann. Oder habt ihr erwartet, 
dass der Teil der Sprache schon fertig ist? Ist das der wichtigste Teil 
einer neuen Sprache und muss zuerst definiert werden?

: Bearbeitet durch User
von Gerhard O. (gerhard_)


Lesenswert?

MaWin schrieb:
> Mampf F. schrieb:
>> Demnach ist C auf Platz 2. Innerhalb eines Jahres von 1 auf 2 gefallen -
>> ist also quasi schon so gut wie tot ;-)
>
> So sehe ich das (unironisch) auch. 13% Market share bedeutet, dass 87%
> nicht in C geschrieben ist. Insbesondere, wenn man die enorme Menge an
> C-legacy-Code sieht, die es natürlich noch lange geben wird, ist das ein
> vergleichsweise kleiner Anteil.
> Es ist der absteigende Ast. Und das seit Jahrzehnten.
>
> Mampf F. schrieb:
>> Daher sehe ich die höchste Relevanz für die Zukunft in Rust, weil es
>> wirklich mal Probleme beseitigt hat und trotzdem auf dem Level von C und
>> C++ mitspielen kann.
>
> Das sehe ich ähnlich.
> Aber ich gehe nicht so weit und spreche Carbon das Existenzrecht ab, wie
> einige das hier tun. Ob Carbon eine Zukunft hat, kann man nur
> herausfinden, indem man es weitertreibt. Und vieleicht kommt ja etwas
> bei rum, was uns weiterbringt. Selbst wenn es nur ein innovatives
> Teilkonzept ist, was dann in andere Sprachen übertragen werden kann.
> Es war schon immer so, dass Sprachen sich gegenseitig beeinflussen und
> befruchten.
Mir kommt vor die Statistik hinkt möglicherweise.

Wenn also da steht, dass C "nur" 13% Market share hat, ist das nicht 
unbedingt realistisch oder vielleicht eher eine Verzerrung des 
Gesamtbildes.

Viele neuzeitlichen Apparate werden mit Internet Fähigkeiten konzipiert 
die naturgemäß viele Zusatzfunktionen braucht die einfachere 8-bit 
Systeme ohne dem nicht benötigen. Die Frage müsste dann so gestellt 
werden, den Market share nach uC Größe und Anwendung aufzuteilen.

Der Anteil an C dürfte dann möglicherweise bedeutend höher für 
einfachere 8-Bit Systeme sein als für komplexe Neuzeitsachen mit 
Netzanbindung und Co.

Was aber höchstwahrscheinlich ausschlaggebender ist, welche der uC und 
Sprachen kommerzielle Werkzeuge und zertifizierte Bibliotheken hat.

Mangels Recherche habe ich natürlich nicht die Fakten zur Hand, aber 
solange die Werkzeugplatzhirsche die neuen Sprachen nicht unterstützt 
wird man bei C und C++ für viele Anwendungen bleiben. Die Kunden werden 
schon wissen warum sie jedes Jahr die teuren Unterstützungskosten 
bezahlen.

Auch sind im industriellen Umfeld noch gewaltige (zertifizierte) 
Altlasten da, die auch noch unterstützt werden müssen. Es gibt noch 
genug andere gute Gründe warum man in der Industrie langsam mit der Zeit 
gehen will und nicht andauernd (leichtsinnig) auf neue Pferde setzen 
möchte.

Ich sehe wenig Grund, sich fanatisch mit Paradigmenwechsel abzugeben. 
Wenn Deadlines und Produktivität den Horizont erleuchten, dann tut man 
besser mit den Werzeugen und Sprachen und Ressourcen zu arbeiten anstatt 
andauernd Neuland zu beschreiten und Umwege machen zu müssen. Ich 
vermute eher, daß normale Generationenkonflikte für die andauernden 
Unruhen sorgen. Erst wenn die "Alten" ausgestorben oder zumindest 
pensioniert sind, wird ein Wandel gemächlich die Sprachenszene 
verändern.

Die Wahrheit ist, die Alten wollen einfach ihre Ruhe haben und die 
anfallenden Sachen schnell abhaken. Die Jungen dagegen, lieben das Neue 
und das Spielen. War schon immer so und ich war früher genau so. Mit dem 
Alter legt sich das aber etwas und man will dann einfach meist nur seine 
Ruhe haben und mit dem zu arbeiten, dass man aus den Hemdsärmeln 
beherrscht. Abgesehen davon lernt man im Alter nicht mehr so leicht. 
Warum soll ich nicht zugeben, dass ich starrsinnig, voreingenommen, faul 
und gefrässig bin:-)

Ok, Feuer frei:-)

: Bearbeitet durch User
von Willhelm T. (tellensohn)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von Onkel Ted (Gast)


Lesenswert?

Carbon: Am Fahrrad absolut dufte aber beim Computer nein danke! Wir 
sollten generell Computer abschaffen!

von Onkel Ted (Gast)


Lesenswert?

Willhelm T. schrieb:
> wenn dein IQ unter 120 ist dann vergiss das mit dem programmieren ganz
> schnell.

Hast du denn einen IQ Test gemacht?

von MaWin (Gast)


Lesenswert?

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?

von DPA (Gast)


Lesenswert?

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

von Programmierer (Gast)


Lesenswert?

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.

von Ron T. (rontem)


Lesenswert?

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.

von Berufsprogrammierer (Gast)


Lesenswert?

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.

von Olaf (Gast)


Lesenswert?

> 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

von Daniel -. (root)


Lesenswert?

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.

von Programmierer (Gast)


Lesenswert?

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.

von Daniel -. (root)


Lesenswert?

Mombert H. schrieb:
> Und explizit welche sind das genau? Es gibt soweit ich weiß kein
> Naturgesetzt, dass die "algebraischen Datentypen" definiert. Die, an die
> ich denke, werden in der Design-Doku beschrieben, oder zumindest
> erwähnt.

Im Kontext der Programmiersprachen sind das "sum types" und "product 
types".
struct ist z.B. ein Produkttypen in C. Bei Summentypen hat C und C++ nur 
was
halbgares zu bieten, nämlich enum und union.

Mombert H. schrieb:
> Also sowas wie hier
> 
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/design/pattern_matching.md
> die Anfänge beschrieben werden? Man sollte meinen, dass jemand der
> ernsthaft programmiert, die Doku lesen kann. Oder habt ihr erwartet,
> dass der Teil der Sprache schon fertig ist? Ist das der wichtigste Teil
> einer neuen Sprache und muss zuerst definiert werden?

Typensystem lässt sich im Nachhinein schwer einbauen bzw. modifizieren.
Das angegebene Beispiel war mir nicht bekannt, ist dennoch eher 
kosmetisch.
Eine Funktion gibt 3 Werte zurück, die im match zerlegt werden.
Richtiges pattern matching kann in die verschachtelten Datenstrukturen
hineinschauen bzw. zerlegen.

Die Sprachen der ML Familie wie Ocaml, F# (Beispiel unten) haben das aus 
meiner Sicht sauber gelöst. Haskel hat das ähnlich plus Lazy Datentypen 
on top. Bei Rust merkt man ebenfalls die ML Abstammung.
1
// sum type
2
type S = S0 | S1 | S2 | S4
3
4
// product type tuple
5
type P = int*int*int
6
7
// product type record syntax
8
type PR = {x1 : int; x2 : int; x3 : int} 
9
10
// discriminated union
11
type DU =
12
    | A
13
    | B of int
14
    | C of int*int*int
15
    | D of int array
16
    | E of int option
17
    | F of float option

von Olaf (Gast)


Lesenswert?

> 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

von Programmierer (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

Daniel -. schrieb:
> Bei Summentypen hat C und C++ nur
> was
> halbgares zu bieten, nämlich enum und union.

std::variant und std::any?

von Unbekannt U. (Gast)


Lesenswert?

Mombert H. schrieb:
> std::variant und std::any?

Turing-Vollständigkeit?

von MaWin (Gast)


Lesenswert?

Unbekannt U. schrieb:
> Turing-Vollständigkeit?

Toast Hawaii?

von Vincent H. (vinci)


Lesenswert?

Neuer Talk auf der CoreCppIL
https://youtu.be/9Y2ivB8VaIs

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.