Rust als Embedded-Programmiersprache

[S. R. (svenska)]

mh schrieb:
> Wer sagt, dass c einen Nachfolger hat oder braucht?
> Und wenn es einen braucht, was spricht gegen c++?

Vorweg: Ich programmiere gerne in C. Gleichzeitig sehe ich aber auch 
ein, dass C nicht der Weisheit letzter Schluss ist, aus wohlbekannten 
und bereits bekannten Gründen.

Meiner Meinung nach leider C++ an der gleichen Überkomplexität wie Perl: 
Es gibt zuviele Wege, ein Problem zu lösen. Das führt dazu, dass jeder 
sein persönliches Subset der Sprache benutzt, mit dem er Probleme gut 
lösen kann, aber am Ende beherrscht niemand die Sprache so gut, um die 
Lösungen anderer zuverlässig zu lesen (sprich: zu debuggen).

Und innerhalb dieser Diskussion hier habe ich nicht so richtig das 
Gefühl, dass Rust da wesentlich besser ist. Ich kann mich täuschen, habe 
aber gerade wenig Lust, mich in eine neue Sprache einzuarbeiten (im 
Augenblick arbeite ich ständig mit C++, Java, Kotlin, VHDL und hab den 
Kopf voll).

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Bernd K. schrieb:
> Timm R. schrieb:
>> schenk uns doch bitte mal ein MWE dazu, das wäre interessant(er).
>
> Was ist ein "MWE"?

Hey Bernd,

sorry! Minimal Working Example

vlg
 Timm

[Kaj G. (Firma: RUB) (bloody)]

Bernd K. schrieb:
> Option und Result, wer fühlt sich bei diesen beiden Enums nicht sofort
> an Haskell

https://doc.rust-lang.org/book/second-edition/ch06-00-enums.html

Enums are a feature in many languages, but their capabilities differ
in each language. Rust’s enums are most similar to algebraic data types
in functional languages, such as F#, OCaml, and Haskell.

Was ein valides struct ist, ist auch ein valides enum:
https://doc.rust-lang.org/rust-by-example/custom_types/enum.html

The enum keyword allows the creation of a type which may be one of a
few different variants. Any variant which is valid as a struct is also
valid as an enum.

mh schrieb:
> Warum ist es weniger fehleranfällig?
Weil du nicht irgendwo in der Funktion hinspringen kannst, sondern nur 
aus der Schleife raus. Nicht mehr und nicht weniger. Grosser Unterschied 
zu goto.

mh schrieb:
> Dein Beispiel ist meiner Meinung nach ziemlich schlecht lesbar. Eine
> Variablen wird über 5 Zeilen initialisiert.
Musst du ja nicht so machen. Kannst du ja genauso machen wie in C/C++:

fn main() {
    let cond = true;
    let mut x: i32 = 6;

    if cond {
        x = 5;
    }
}

Es gibt jetzt nur einen eklatanten unterschied:
In meinem Beispiel

let x = if cond {
    5
} else {
    6
};

ist x danach read-only, aber nicht const, d.h. x koennte per shadowing 
ueberdeckt werden, wenn man es braucht.

fn main() {
    let cond = true;
    let x = if cond {
        5
    } else {
        6
    };

    x = 7;
}

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:9:5
  |
3 |     let x = if cond {
  |         - first assignment to `x`
...
9 |     x = 7;
  |     ^^^^^ cannot assign twice to immutable variable

Soweit ich das sehe, ist sowas in C/C++ nicht moeglich.


mh schrieb:
> Ich kann mich nicht daran erinnern, dass das für mich in c oder c++ im
> letzten Jahrzehnt ein Problem gewesen ist.
Nur weil es fuer dich kein Problem ist, heisst das nicht, dass es kein 
generelles Problem ist. Schau nur mal wie viele Bugs es wegen nicht 
initialisierten Variablen (UB) gibt.

Bei meinem alten Arbeitgeber haben wir mal genau so einen Bug gesucht, 
der nur aufgefallen ist, weil unsere Software auf FreeBSD und auf 
Windows laufen musste. Auf BSD kein Problem, unter Windows hat sich das 
Programm aber anders verhalten. Was war das Problem?

bool flag;

// jede menge code

if (flag) {

} else {

}

Ist halt doof, wenn die Variable auf dem einen System Wert x und auf dem 
anderen Wert y hat.

Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit 
einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer, 
User-After-Free, etc. Alles UB.

mh schrieb:
> Und nein, es ist kein Sicherheitsrisiko, wenn man es sorgfältig
> macht.
Du sagst es ja selbst: Man muss extra aufpassen, weil genau sowas UB 
ist. Und gerade UB ist eben etwas, auf das ich in Rust nicht achten 
muss, und ich mir auch keinen Kopf darum machen will.

Kannst ja mal hier schauen, was so alles UB ist. Und dann sag mal, ob du 
das alles wusstest, und wenn nicht, ob du deine Programme jetzt danach 
durchsuchst und das behebst. ;)
Keine Angst, sind nur 203 Aufgelistet.
https://wiki.sei.cmu.edu/confluence/display/c/CC.+Undefined+Behavior

Und dazu kommt dann auch noch unspecified behavior. Auch das sind 'nur' 
58.
https://wiki.sei.cmu.edu/confluence/display/c/DD.+Unspecified+Behavior

Sind also gut 260 Fallstricke, die du immer im Kopf haben musst. Und das 
nur fuer C.
Man brauch ja nur mal hier im Forum suchen, wie es immer und immer 
wieder zu der Frage nach union kommt. Das endet nahezu immer darin, das 
man dem TO erklaeren muss, dass das was er da macht UB ist, und er es 
einfach ignoriert, weil es ja beim ihm funktioniert. 'Works for me!'
Kann also gar nicht falsch sein.

Sorry, aber damit gewinnt C und auch C++ keinen Blumentopf mehr.

[Carl D. (jcw2)]

mh schrieb:
> Kaj G. schrieb:
.
>> Was ich ebefalls schoen finde:fn main() {
>

>      let cond = true;
> 
>      let x = if cond {
>          5
>      } else {
>          6
>      };
>  }
>

>> In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert
>> oder belegt es erstmal mit einen dummy Wert, der dann wieder
>> ueberschrieben werden muss.
.
> Ja, in einigen Fällen kann man so ohne uninitialisierte Variable
> auskommen, wo man sie in c++ nicht vermeiden kann. In den meisten Fällen
> kann man uninitialisierte Variablen aber leicht umgehen. Für dein
> Beispiel sieht das dann so aus:
>

> auto x = 6;
> if(cond) {
>   x = 5;
> }
>

> Der Compiler erzeugt vermutlich identischen Code. Bei komplizierternen
> Fällen sollte man sich fragen, warum es so kompliziert ist und es
> vereinfachen.

Oder vielleicht schlicht die 1:1 Variante

auto x = (cond) ? 5 : 6;

[mh (Gast)]

Kaj G. schrieb:
> Soweit ich das sehe, ist sowas in C/C++ nicht moeglich.
Wenn man es unbedingt braucht:

auto const x = cond ? 5 : 6;

Kaj G. schrieb:
> Du sagst es ja selbst: Man muss extra aufpassen, weil genau sowas UB
> ist. Und gerade UB ist eben etwas, auf das ich in Rust nicht achten
> muss, und ich mir auch keinen Kopf darum machen will.
Das bringt mir wenig, wenn ich statt dessen andauernd den Compiler 
"umgehen" muss, um meine Probleme zu Lösen (siehe: use of possibly 
uninitialized `x`).

Kaj G. schrieb:
> bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {
>
> }
Bei rust nen Error bei c++ ne Warnung.


Kaj G. schrieb:
> Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit
> einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer,
> User-After-Free, etc. Alles UB.
Nullpointer und Use-After-Free sind keine wirklichen Probleme in c++, da 
man keine Raw-Pointer verwendet.

Kaj G. schrieb:
> Kannst ja mal hier schauen, was so alles UB ist.Und dann sag mal, ob du
> das alles wusstest, und wenn nicht, ob du deine Programme jetzt danach
> durchsuchst und das behebst.
Ich kenne nicht alle Fälle von UB, aber alle die relevant sind. Hast du 
die Liste gelesen?

A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment (5.1.1.2).

Sehr relevant... Wenn ich mich nicht irre hat gcc früher trotzdem 
gewarnt.

A program in a hosted environment does not define a function named main using one of the specified forms (5.1.2.2.1).

Kennt jemand einen Linker, der nicht meckert, wenn er kein main findet?

A reserved keyword token is used in translation phase 7 or 8 for some purpose other than as a keyword (6.4.1).

Muss ich davor Angst haben?

Kaj G. schrieb:
> Sorry, aber damit gewinnt C und auch C++ keinen Blumentopf mehr.
Wo findet man nochmal den vollständigen rust-Standard, in dem es kein 
Undefined Behaviour gibt? Die Antwort auf 
https://www.rust-lang.org/en-US/documentation.html:
> While Rust does not have a specification, the reference tries to describe
> its working in detail. It tends to be out of date.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

mh schrieb:

Hallo,

> Kaj G. schrieb:
>> Wenn es fuer dich kein Problem ist, ist ja gut, UB ist trotzdem mit
>> einer der am verbreitesten Fehlerursachen in C/C++. Nullpointer,
>> User-After-Free, etc. Alles UB.
> Nullpointer und Use-After-Free sind keine wirklichen Probleme in c++, da
> man keine Raw-Pointer verwendet.

bzw, wenn man sie verwendet, dann sind das Fälle, wo auch in Rust 
"unsafe" stehen würde. Und eine Heap-Allokation die sich heimlich 
verabschiedet kann der Rust "unsafe" genau so wenig vorhersehen, wie ein 
C++ Compiler. Kein Unterschied.

Wobei man eben schon zugeben muss, dass sowas wie der C-Code oben aus 
dem Heartbleed Beispiel in Rust eben nicht so einfach einzuschmuggeln 
ist.



> Kaj G. schrieb:
>> Kannst ja mal hier schauen, was so alles UB ist.Und dann sag mal, ob du
>> das alles wusstest,

na, das ist doch mal etwas schräg? Ich kenne auch nicht alle Fraun, mit 
denen ich nicht verheiratet bin. Wozu denn auch? Du musst ein gutes 
Gebiet defined behavior kennen und das UB, dass dir auf die Füße fallen 
könnte, wenn du im Halbschlaf rumtipperst.

Kaj, du hast ja scheinbar einen riesen Fundus UB ausgegraben, dann nenn 
doch bitte mal ein einziges UB, das einen C++ Dilettanten wie mich 
überrascht, gern auch als Quizzfrage. Ich war noch nie von UB 
überrascht, sondern höchstens mal, dass etwas nicht UB ist, aber das ist 
ja nicht gefährlich.

vlg
 Timm

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

nicht 100% ernst gemeint:

Vielleicht beginnt ja dann in Zukunft jeder noob sein Rust Programm mit

unsafe {

so wie in c++ das

using namespace std;

:-))

vlg
 Timm

[A. S. (Gast)]

Kaj G. schrieb:
> bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {

Da schlägt doch der Compiler Alarm, oder zumindest Lint. Ja, man kann in 
C so programmieren, dass solch Warnungen untergehen ...

[Privatfrickler (Gast)]

Kaj G. schrieb:
> Bei meinem alten Arbeitgeber haben wir mal genau so einen Bug gesucht,
> der nur aufgefallen ist, weil unsere Software auf FreeBSD und auf
> Windows laufen musste. Auf BSD kein Problem, unter Windows hat sich das
> Programm aber anders verhalten. Was war das Problem?bool flag;
>
> // jede menge code
>
> if (flag) {
>
> } else {
>
> }

Selbst in Pelles C bekomme ich da bei un-initialisiertem Gebrauch von 
flag eine Warning geworfen!

C99 mit

<stdbool.h>

eingebunden

Building main.obj.
C:\Users\..\Documents\Pelles C Projects\bool01\main.c(22): warning #2229: Local 'flag' is potentially used without being initialized.
Done.

[Operator S. (smkr)]

@Kaj G.
Man kann sich die Beispiele auch so zurechtrücken, dass seine Ansichten 
am besten da stehen. So gerne ich Rust auch mag, so sind nicht all seine 
Eigenschaften ein Alleinstellungsmerkmal der Sprache.

Hier sagst du
Kaj G. schrieb:
> C und C++: Sichtbarkeit muss explizit eingeschraenkt werden.
> Rust: Sichtbarkeit muss explizit ausgeweitet werden.

merkst aber sogar selbst an, dass die Funktion über das Headerfile 
öffentlich gemacht werden muss. Noch expliziter gehts ja kaum.
Ausserdem sind in C++ Methoden in einer Klasse default private. 
Umgekehrt sind sie in einem struct default public.

Kaj G. schrieb:
> Auf uninitialisierte Variablen kann in Rust nicht lesend zugegriffen
> werden:
C++ initialisiert diese einem sogar, wenn man es nicht selber 
hinschreiben will.


Kaj G. schrieb:
> Was ich ebefalls schoen finde:fn main() {
>     let cond = true;
>
>     let x = if cond {
>         5
>     } else {
>         6
>     };
> }
> In C/C++ muss man dazu x erstmal anlege und laesst es uninitialisiert
> oder belegt es erstmal mit einen dummy Wert, der dann wieder
> ueberschrieben werden muss.
Die Behauptungen zu C++ stimmen schlichtweg nicht, was aber weiter oben 
schon erläutert wurde.

[Vincent H. (vinci)]

Ich hab über Rust bisher leider nur gelesen und es selbst nie angewandt, 
aber was mir persönlich sehr abgehn würde und wofür es glaub ich bisher 
kein Äquivalent in C++ gibt ist:
- constexpr
- variadic arguments
- function overloading

Kann jemand dazu was sagen?
Grad constexpr wäre für eine embedded Sprache, in der es imho übermäßig 
viele compile-time Checks geben kann und sollte sehr wichtig.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo Vincent,

magst duu deinen Post noch mal lesen? Irgendwas stimmt da nicht.

Viele liebe Grüße
timm

[Vincent H. (vinci)]

Err... zu meinte ich natürlich, Äquivalent zu C++, nicht in.

[Der wo ich bin (Gast)]

Ich hab mal eine grundsätzliche Frage an die Community hier, welche ich 
mir jedesmal stelle, wenn Threads dieser Art (C vs. C++, C vs. Rust, C 
vs. Ada) aufploppen.

Wer würde folgenden Aussagen zustimmen?

Ich bevorzuge C gegenüber C++/Rust/Ada weil:

- diese Sprachen es zu leicht machen sich in eine Ecke zu designen.
- für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen 
Bojackel-Schniepel aus den tiefen des Weltalls.
- ich keine Lust habe mich in die Abstraktionsuntiefen anderer zu 
begeben, wenn das Problem eigentlich einfacher zu lösen ist.

Ich persönlich habe mit Rust experimentiert, und wäre glücklich gewesen 
wenn es ein C mit borrow checker geworden wäre. Der Rest führt meiner 
Erfahrung nach, früher oder später, zu einer over engineering Kultur 
(wie bei allen Sprachen mit "mächtigem Typsystem"). Irgendwann kommt der 
Punkt an dem man sich zur akademisch niedrigsten Lebensform 
zurückentwickelt, dem Taxonomen 
(https://de.wikipedia.org/wiki/Taxonomie).

Aber wahrscheinlich abstrahiere ich nur gerne in die andere Richtung 
(uint8_t vs. Bojackel-Schniepel, denn hey, im Grunde sind alles nur 
Zahlen ;-) ).

P.S.:
Hat jemand Erfahrung mit https://ziglang.org?

[Bernd K. (prof7bit)]

Der wo ich bin schrieb:
> für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen
> Bojackel-Schniepel aus den tiefen des Weltalls.

Der Typ für einen "n-dimensionale Bojackel-Schniepel aus den tiefen des 
Weltalls als Ersatz für uint8_t" heißt in Rust ganz einfach u8.

Darüber hinaus sind Deine Aussagen über die negativen Eigenschaften von 
Rust etwas schwammig und nicht ganz nachvollziehbar. Insbesondere weil 
Du sagst der Borrow-Checker bereitet Dir erstaunlicherweise keine 
Probleme, das ist aber so ziemlich der komplizierteste Teil, alles 
andere ist genau wie C mit ein paar zusätzlichen Schmankerln (Enums, 
Pattern-Matching, etc.) und einer angenehmeren Syntax als C(++).

[Alex G. (dragongamer)]

Der wo ich bin schrieb:
> Ich hab mal eine grundsätzliche Frage an die Community hier, welche ich
> mir jedesmal stelle, wenn Threads dieser Art (C vs. C++, C vs. Rust, C
> vs. Ada) aufploppen.
>
> Wer würde folgenden Aussagen zustimmen?
>
> Ich bevorzuge C gegenüber C++/Rust/Ada weil:
>
> - diese Sprachen es zu leicht machen sich in eine Ecke zu designen.
> - für ein Byte der Typ uint8_t genügt, es braucht keinen n-dimensionalen
> Bojackel-Schniepel aus den tiefen des Weltalls.
> - ich keine Lust habe mich in die Abstraktionsuntiefen anderer zu
> begeben, wenn das Problem eigentlich einfacher zu lösen ist.
Bei Entwicklern die nur ein paar tausendzeilige Programme schreiben 
wirst du ganz sicher Gleichgesinnte finden (Ausnahmen bestätigen die 
Regel).
Das setzt allerdings vorraus dass du eben Probleme hast die sich so 
einfach umsetzen lassen und vorallem vom Menschen (und einem späteren 
Leser des Codes) erfasst werden können. Schließlich ist das der 
Hauptgrundgrund für Abstraktion.

Wobei mein Argument hier wenig mit C vs Rust zutun hat, sondern mehr C 
vs Objektorientierung.
Dass es irgendwann ein "Rust++" mit vollwertiger Objektorientierung 
geben könnte sind Moment nur Gerüchte und Wünsche.

[S. R. (svenska)]

Alex G. schrieb:
> Bei Entwicklern die nur ein paar tausendzeilige Programme schreiben
> wirst du ganz sicher Gleichgesinnte finden (Ausnahmen bestätigen die
> Regel).

Ein mächtiges Typsystem verleitet zu Missbrauch.

Wenn jede einzelne Information zu einem eigenen Datentyp gemacht wird, 
und durch die Abstraktionshierarchien hindurch ständig Datentypen 
ineinander konvertiert werden müssen (weil sie abstrakt definiert 
wurden, statt zueinander kompatibel), dann ist das jeglicher Form von 
Wartung abträglich. Und wenn man dann durch sechs, sieben 
Abstraktionsstufen hindurchgelaufen ist und eine Trivialität findet, 
dann fühlt man sich schon ein bisschen verarscht.

Komplexität taucht immer irgendwo auf, aber mir ist Komplexität in der 
Programmlogik (die man verfolgen kann) lieber, als Komplexität in der 
Abstraktionierung (eben weil man die nicht verfolgen kann - der Code ist 
über viele Dateien verstreut).

Aber das ist definitiv kein Fehler von Rust.

[Der wo ich bin (Gast)]

Der borrow checker ist in der tat kein Problem. Das Problem ist das man 
(wie auch bei C++ und Ada) zum Taxonomen wird, wobei scheinbar immer 
versucht wird möglichst fein granulierte Designs und Typen zu 
implementieren. Nach Möglichkeit nah an der Realität, wobei ich mich da 
dann frage wo die Abstraktion sein soll. Ist dann eher eine 
Nachempfindung.

Mein Beispiel oben (uint8_t) z.B. wurde von Bernd K. falsch verstanden. 
Als ob ich nicht wüsste das es u8 gibt. Im Rust Forum hatte ich die 
Frage genau so auch gestellt (über die offizielle Webseite zu erreichen, 
Stichwort thinking in types). Antwort war "geht auch, aber idiomatisch 
müsstest du..."

Aber ich sehe wir haben einfach zu verschiedene Denkweisen.

P.S.:
Tausendzeilig? Die meisten Kernel und (bedeutenden) libs sind größer 
denke ich.

P.P.S.:
Ich schreibe nie mehr was per Telefon!

[Der wo ich bin (Gast)]

An Alex G.:

Anstatt durch die Blume zu implizieren ich sei kein Profi, hätte keine 
Ahnung oder bin einfach zu dumm, google mal "Rust severely disappoints 
me" von Eric Raymond. Am besten auch googeln wer das ist.

Und kuck dir mal die Sprache Zig an und warum sie ins Leben gerufen 
wurde.
Zitat:
"Small, simple language. Focus on debugging your application rather than 
debugging your knowledge of your programming language."

Wahrscheinlich alle zu dumm, oder?

ein Zitat von L. Toralds, welches ich auf den Punkt gebracht finde:

"inefficient abstracted programming models where two years down the road
   you notice that some abstraction wasn't very efficient, but now all
   your code depends on all the nice object models around it, and you
   cannot fix it without rewriting your app."

[A. S. (Gast)]

Der wo ich bin schrieb:
> Mein Beispiel oben (uint8_t)

Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern 
erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von 
Ingenieuren zugemüllt werden.

Es ging darum, ob den Zahlen Einheiten zugeordnet sein sollten.  Nein! 
Auch wenn dann der Compiler  da ein paar Fallstricke erkennen kann ... 
Eine Zahl ist eine Zahl, wenn ich sie z.b. im Menü eingebe oder mit 
min/max teste...

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Achim S. schrieb:
> Der wo ich bin schrieb:
>> Mein Beispiel oben (uint8_t)
>
> Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern
> erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von
> Ingenieuren zugemüllt werden.
>
> Es ging darum, ob den Zahlen Einheiten zugeordnet sein sollten.  Nein!
> Auch wenn dann der Compiler  da ein paar Fallstricke erkennen kann ...
> Eine Zahl ist eine Zahl, wenn ich sie z.b. im Menü eingebe oder mit
> min/max teste...

kannst Du noch ein wenig ausführen, worum es hier geht? Geht es noch um 
Rust, oder was ist das Thema?

Klingt eher nach c/Assembler vs. die Moderne?

vlg
 Timm

[Privatfrickler (Gast)]

Der wo ich bin schrieb:
> google mal "Rust severely disappoints
> me" von Eric Raymond. Am besten auch googeln wer das ist.
>
> Und kuck dir mal die Sprache Zig an und warum sie ins Leben gerufen
> wurde.
> Zitat:
> "Small, simple language. Focus on debugging your application rather than
> debugging your knowledge of your programming language."

Also ist Zig das neue Rust?

https://ziglang.org/

const builtin = @import("builtin");
const std = @import("std");
const io = std.io;
const fmt = std.fmt;
const os = std.os;

pub fn main() !void {
    var stdout_file = try io.getStdOut();
    var stdout_file_stream = io.FileOutStream.init(&stdout_file);
    const stdout = &stdout_file_stream.stream;

    try stdout.print("Welcome to the Guess Number Game in Zig.\n");

    var seed_bytes: [@sizeOf(u64)]u8 = undefined;
    os.getRandomBytes(seed_bytes[0..]) catch |err| {
        std.debug.warn("unable to seed random number generator: {}", err);
        return err;
    };
    const seed = std.mem.readInt(seed_bytes, u64, builtin.Endian.Big);
    var prng = std.rand.DefaultPrng.init(seed);

    const answer = prng.random.range(u8, 0, 100) + 1;

    while (true) {
        try stdout.print("\nGuess a number between 1 and 100: ");
        var line_buf: [20]u8 = undefined;

        const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) {
            error.InputTooLong => {
                try stdout.print("Input too long.\n");
                continue;
            },
            error.EndOfFile, error.StdInUnavailable => return err,
        };

        const guess = fmt.parseUnsigned(u8, line_buf[0..line_len], 10) catch {
            try stdout.print("Invalid number.\n");
            continue;
        };
        if (guess > answer) {
            try stdout.print("Guess lower.\n");
        } else if (guess < answer) {
            try stdout.print("Guess higher.\n");
        } else {
            try stdout.print("You win!\n");
            return;
        }
    }
}

[Jan W. R. (Gast)]

Der wo ich bin schrieb:

>> "Rust severely disappoints me" von Eric Raymond. Am besten auch googeln wer das 
ist.

https://de.wikipedia.org/wiki/Eric_S._Raymond

„…Er bekennt sich zu den Idealen des Libertarismus und ist starker 
Verfechter des Rechts auf Waffenbesitz“
Verfechter des Rechts auf Waffenbesitz leben meiner Meinung nach in 
Irrtum. Ein Grund für mich sich mit Ihm nicht zu beschäftigen, um 
solchen Leuten kein Zuspruch und Anerkennung zu geben


>>"Small, simple language. Focus on debugging your application rather than
>> debugging your knowledge of your programming language."

Ist eine Coole Aussage, leider sehr Pauschal könnte auch auf der 
folgenden Internetseite stehen :
http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

Dort sind Witze zu finden wie z.B.  :
>>C++ ◦You accidentally create a dozen instances of yourself and shoot them all in 
the foot. Providing emergency medical assistance is impossible since you can't 
tell which are bitwise copies and which are just pointing at others and saying, 
>>"That's me, over there."

Zitat:
>>"inefficient abstracted programming models where two years down the road
>>   you notice that some abstraction wasn't very efficient, but now all
>>   your code depends on all the nice object models around it, and you
>>   cannot fix it without rewriting your app."

Ist auch eine pauschale Aussage, Populismus.

Ein Amerikanischer Senator leugnete den Klimawandel und warf einen 
Schneeball auf den Boden unter dem Stichwort, „Ist doch kalt draußen“
Es war eine coole Aktion, leide Falsch die Aussage. Jeder von uns weis 
das wir den Klimawandel und Erderwärmung haben.
Mit diesem banalen Beispiel wollte ich sagen das solche Zitate keine 
Argumente sind.


Der Profi selbst weiß wie viel Abstraktion und wie viel Typisierung  wo 
und wie eingesetzt wird.

Gruss,
Jan

[Alex G. (dragongamer)]

Sehr schön gesagt.

Das klingt wohl jetzt auch pauschal aber denke auch der Entwickler muss 
eben einschätzen ob das Risiko nach einem Jahr fest zu stellen dass man 
falsch abstrahiert hat, grösser ist, als das Risiko nach eine Jahr nicht 
mehr in seinem eigenen Code durch zu blicken weil man grade nicht 
abstrahiert hat.


Am Ende wird man wohl nie alle glücklich machen können mit einer Sprache 
denn grade bei der Frage wie restriktiv die Sprache sein soll, scheiden 
sich die Geister.

[W.S. (Gast)]

Der wo ich bin schrieb:
> Ich hab mal eine grundsätzliche Frage...
> ...
> Ich bevorzuge C ...

Nö. präziser: GENERAL-NÖ.
Ich bevorzuge C überhaupt nicht, sondern benutze es nur notgedrungen und 
nur dort, wo es keine besseren Alternativen gibt.
Und all diese Pippifax-C-Ersatz-Sprachen sind durchweg eben keine 
Alternativen, geschweige denn bessere Alternativen.

Die Gründe für all dieses Sich-Winden in neuerfundenen Sprachen habe ich 
ja schon viel weiter oben dargelegt: Die Spracherfinder stecken mental 
viel zu tief in der C-Furche und kommen dort zeitlebens nie wieder 
heraus.

Genau DAS ist die Tragik bei all den fruchtlosen Bemühungen.

Wenn man mal bedenkt, wieviel Entwicklungsaufwand vergeigt wird in dem 
Bemühen, eine Art neues C mit allen bisherigen Gewohnheiten aber 
zugleich ohne all die bisherigen Geburtsfehler und Fallstricke und 
natürlich ohne das Aufgeben von bisheriger Syntax, dann wird unsereiner 
melancholisch.

Viel Lärm um nichts, wasch mich ohne mich naßzumachen, nur einmal um 
sich selbst gedreht ohne ein neues (oder wenigstens besseres) Ufer 
erreicht zu haben.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> Viel Lärm um nichts, wasch mich ohne mich naßzumachen, nur einmal um
> sich selbst gedreht ohne ein neues (oder wenigstens besseres) Ufer
> erreicht zu haben.

Was schlägst Du also vor? Du scheinst eine Vision zu haben, wie sieht 
sie konkret aus Deine radikale Abkehr von allem dagewesenen die alles 
endlich wirklich besser macht?

[Karl K. (karl2go)]

Achim S. schrieb:
> Da ins gleiche Horn die 40 Jahre alte Weisheit: die von Mathematikern
> erfunden Zahlen sind kompakt und wunderschön. Sie sollten nicht von
> Ingenieuren zugemüllt werden.

Leider hast Du da eine Kleinigkeit übersehen: Der Zahlenraum in dem 
Mathematiker arbeiten können ist unbegrenzt und unendlich. Der eines 
Computers nicht.

Ergo muss man sich bei der Programmierung auf sinnvolle Einheiten und 
mitunter auch Einheitenvorsätze festlegen, um den vorhandenen Zahlenraum 
sinnvoll nutzen zu können.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo,

also dieser sehr bekannte Benchmark für Rust

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/revcomp.html

mogelt, finde ich, ein bisschen. Das Rust Programm benutzt die externe 
Bibliothek Rayon für parallele Verarbeitung. Rayon gehört nicht zum 
Sprachumfang. Dann müsste ein C/C++ Programm auch externe 
Hilfsbibliotheken benutzen dürfen.

vlg

 Timm

[mh (Gast)]

Timm R. schrieb:
> Hallo,
>
> also dieser sehr bekannte Benchmark für Rust
>
> https://benchmarksgame-team.pages.debian.net/bench...
Wieso bekannt? Und wieso Benchmark? Es nennt sich selbst benchmarkgame.


Timm R. schrieb:
> mogelt, finde ich, ein bisschen. Das Rust Programm benutzt die externe
> Bibliothek Rayon für parallele Verarbeitung. Rayon gehört nicht zum
> Sprachumfang. Dann müsste ein C/C++ Programm auch externe
> Hilfsbibliotheken benutzen dürfen.
>
> vlg
>
>  Timm
Es wird noch mehr "gemogelt". Beim rust-Program auf Platz 1 steht als 
Author unter anderem "Rust Project Developers". Wo ist das Beispiel mit 
den Authoren "g++ Developers" oder "clang++ Developers"?

Wenn dann in den c++ Beispielen sowas wie:

template< class type >
struct vector2 : public std::vector<type> {
   type &last() { return this->operator[]( std::vector<type>::size() -1 ); }
};

oder

struct Chunker {
protected:
   static volatile int printQueue;
};

vorkommt, muss man sich schon fragen, was da überhaupt vergleichbar sein 
soll.

[Privatfrickler (Gast)]

W.S. schrieb:
> Ich bevorzuge C überhaupt nicht, sondern benutze es nur notgedrungen und
> nur dort, wo es keine besseren Alternativen gibt.
> Und all diese Pippifax-C-Ersatz-Sprachen sind durchweg eben keine
> Alternativen, geschweige denn bessere Alternativen.
>
> Die Gründe für all dieses Sich-Winden in neuerfundenen Sprachen habe ich
> ja schon viel weiter oben dargelegt: Die Spracherfinder stecken mental
> viel zu tief in der C-Furche und kommen dort zeitlebens nie wieder
> heraus.
>
> W.S.

Was würdest DU als Alternative vorschlagen?

[mh (Gast)]

mh schrieb:
> Es wird noch mehr "gemogelt".

Ich muss mich korrigieren. Es wird gemogelt! Die Regeln schreiben das 
zeilenweise Einlesen von stdin vor, wobei die Zeilen max. 60 Zeichen 
lang sind. Das rust-Programm liest deutlich größere Blöcke.

[W.S. (Gast)]

Bernd K. schrieb:
> Was schlägst Du also vor? Du scheinst eine Vision zu haben, wie sieht
> sie konkret aus Deine radikale Abkehr von allem dagewesenen die alles
> endlich wirklich besser macht?

Hä?
Du tust ja grad so, als ob ICH sowas wie Rust und Konsorten verzapft 
hätte. Nein, hab ich nicht. Ich habe mich durchaus nicht von allem 
Dagewesenen abgekehrt - insbesondere ICH NICHT.

Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und 
funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern 
eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache 
zu renovieren, und das gründlich.
Also:
- Headerdateien abschaffen und stattdessen ein echtes Modulsystem auf 
Compilerebene einführen, wo sauber geregelt ist, welche Entitäten des 
Moduls von außen sichtbar und zugänglich sein dürfen und welche nicht.
- verläßliche Datentypen auf Compilerebene einführen. Datentypen haben 
gefälligst problemorientiert zu sein und nicht hardwareorientiert. 
Letzteres hinzukriegen, ist Aufgabe des Compilers und nicht der Sprache.
- boolean einführen
- Strings einführen. Also sowas, wo man ohne Abzählen bis null die Länge 
kennt und die man addieren kann, ohne dabei die berüchtigten 
Pufferüberläufe zu riskieren.
- char von allen Integertypen trennen
- keinerlei Defaults zulassen
- keinerlei Wert von Anweisungen zulassen
- die Deklaration von Konstanten, Typen und Variablen radikal umstellen.
  Bei Variablen
 attribut attribut.. name;
 attribut attribut.. name[indexbereich];
auf
 name : typbezeichnung;
wobei die Typbezeichnung ZUVOR dem Compiler bekannt sein muß.
- die Deklarationen sauber von Anweisungen und Funktionen trennen.
- einen sauberen Zuweisungsoperator einführen, um die Verwendung des "=" 
zum Zuweisen abzuschaffen. Das Gleichheitszeichen ist nämlich ein 
mathematisches Zeichen, das man verdammt noch mal nicht mißbrauchen 
sollte. Ein Ähnliches gilt für den Asterisk (das Sternchen) und das Et 
(Kaufmannsund, "&"), was man vom At ("@") unterscheiden sollte. 
Heutzutage ist das At den Leuten ohnehin weitaus geläufiger als das Et 
und das Sternchen für die bisherigen Pointeroperationen.
- Gleichheit für alle Pointeroperationen einführen. Dabei fliegen 
Sternchen und Et raus, ebenso "->", und das Ganze wird mit dem Punkt für 
Members ersetzt.
- Einführen von Variablenreferenzen anstelle von Pointern als Argumente 
zwecks besserer Kontrolle durch den Compiler.

So, reicht das für den Anfang? Bin mal gespannt, ob jetzt ein Gekreisch 
hier einsetzt.

Man muß ja nicht alles auf einmal einführen, damit das Gezeter der ewig 
Gestrigen sich auf einen größeren Zeitraum verteilt.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und
> funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern
> eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache
> zu renovieren, und das gründlich.
> Also:

Ok, also schaun wir mal Punkt für Punkt:

> - Headerdateien abschaffen und stattdessen ein echtes Modulsystem auf
> Compilerebene einführen, wo sauber geregelt ist, welche Entitäten des
> Moduls von außen sichtbar und zugänglich sein dürfen und welche nicht.

check

> - verläßliche Datentypen auf Compilerebene einführen. Datentypen haben
> gefälligst problemorientiert zu sein und nicht hardwareorientiert.

check

> Letzteres hinzukriegen, ist Aufgabe des Compilers und nicht der Sprache.

? Ein Typsystem mit solchen Garantien muß immer Teil der 
Sprachdefinition sein

> - boolean einführen

check

> - Strings einführen. Also sowas, wo man ohne Abzählen bis null die Länge
> kennt und die man addieren kann, ohne dabei die berüchtigten
> Pufferüberläufe zu riskieren.

check

> - char von allen Integertypen trennen

check

> - keinerlei Defaults zulassen

?

> - keinerlei Wert von Anweisungen zulassen

check

> - die Deklaration von Konstanten, Typen und Variablen radikal umstellen.
>   Bei Variablen
>  attribut attribut.. name;
>  attribut attribut.. name[indexbereich];
> auf
>  name : typbezeichnung;
> wobei die Typbezeichnung ZUVOR dem Compiler bekannt sein muß.

check

> - die Deklarationen sauber von Anweisungen und Funktionen trennen.

? Die Syntax ist klar, es ist deutlich ersichtlich was eine 
Variablenddeklaration ist und was nicht, es gibt sogar ein eigenes 
Keyword dafür "let", ist das getrennt genug?
also check (für meine Ansprüche zumindest)

> - einen sauberen Zuweisungsoperator einführen, um die Verwendung des "="
> zum Zuweisen abzuschaffen. Das Gleichheitszeichen ist nämlich ein
> mathematisches Zeichen, das man verdammt noch mal nicht mißbrauchen
> sollte. Ein Ähnliches gilt für den Asterisk (das Sternchen) und das Et
> (Kaufmannsund, "&"), was man vom At ("@") unterscheiden sollte.
> Heutzutage ist das At den Leuten ohnehin weitaus geläufiger als das Et
> und das Sternchen für die bisherigen Pointeroperationen.

Reine Kosmetik. Ob er = oder := oder <- oder sonstwie geschrieben wird 
ist schnurz. Rust hat einen "sauberen" Zuweisungsoperator, der ganze 
andere Kram mit & vs @ ist auch reine Kosmetik, Pascal hätte auch mit & 
statt @ funktioniert und keiner hätte sich daran gestört. Der einzige 
valide Kritikpunkt wäre daß man argumentieren könnte daß das Sternchen 
zum Dereferenzieren auf der falschen Seite steht (ist mir auch sofort 
ins Auge gestochen, bei Pascal zum Beispiel steht das Dach auf der 
richtigen Seite) aber selbst das ist nur minimale Kosmetik die hinter 
weit wichtigerem zurücktritt.

also check

> - Gleichheit für alle Pointeroperationen einführen. Dabei fliegen
> Sternchen und Et raus, ebenso "->", und das Ganze wird mit dem Punkt für
> Members ersetzt.

? Die Sprache soll verständlich sein, also sollte man schon sehen was 
man schreibt, denselben Operator für völlig unterschiedliche 
Operationen?
Unfug

Und übrigens das -> hat in Rust überhaupt nichts mit Pointeroperationen 
zu tun, ich weiß nicht warum Du das jetzt anführst, das -> symbolisiert 
den Abbildungspfeil wie man ihn aus der Mathematik kennt bei der 
Deklaration einer Funktion, es zeigt auf den Zieltyp der Abbildung, zum 
Beispiel so:

fn foo(x: i32) -> i32

> - Einführen von Variablenreferenzen anstelle von Pointern als Argumente
> zwecks besserer Kontrolle durch den Compiler.

Check


Also was war nochmal Deine Kritik an Rust? Als Pascal-Liebhaber müßtest 
Du es eigentlich lieben, endlich ein "Pascal" ohne Boilerplate, dann 
sogar noch mit Typinferenz und die Kompilezeit-Typsicherheit gleich 
nochmal ins übernächste Level katapultiert! Was will man mehr?

[Yalu X. (yalu) (Moderator)]

Da musste ich schon ein wenig grinsen :)

Erst schreibt W.S.:

W.S. schrieb:
> Rust ist ganz offensichtlich nur ein weiterer Vorbrenner für C. Sieht ja
> auch fast genauso aus, ist nur noch ein wenig unübersichtlicher.

Auf die Nachfrage hin, wie denn seine Vision aussehe, schreibt er:

W.S. schrieb:
> Aber anstatt sich immer neue Sprachen auszudenken, die aussehen und
> funktionieren wie ein verwurschteltes C, hätte ich den Neusprachlern
> eher angeraten, ihren Elan darauf zu verwenden, ihre Herkunfts-Sprache
> zu renovieren, und das gründlich.
> Also:
> ...

Da, wo die ... stehen, beschreibt er Features, die zu 95% von Rust
umgesetzt wurden und die Bernd netterweise Stück für Stück aufgedröselt
hat:

Bernd K. schrieb:
> check
> check
> check
> ...

@W.S:

Bist du sicher, dass deine Vision der optimalen Programmierpsrache ein
Vorbrenner für C ist, der fast genauso aussieht und nur ein wenig
unübersichtlicher ist? ;-) SCNR

Wobei man sagen muss, dass die meisten der von dir aufgeführten
Forderungen von fast jeder neueren Programmiersprache erfüllt werden.
Das, was die Sprachen wirklich voneinander unterscheidet, beschränkt
sich nicht auf solche Oberflächlichkeiten.

[Privatfrickler (Gast)]

Bernd K. schrieb:
> Reine Kosmetik. Ob er = oder := oder <- oder sonstwie geschrieben wird
> ist schnurz.

Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und 
schafft somit unnötig zusätzliche Komplexität. Wenn fünf 
Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden, 
dann hast du fünf-fachen Aufwand diese zu unterscheiden. Und es bleibt 
ja nicht bei diesem einen Umstand. Für den Vergleich gibt es dann 
vielleicht wieder fünf verschiedene Symbole. Für einen Zeiger nochmals 
fünf weitere Unterschiedlichkeiten. Vor lauter Symboljongliererei 
verbraucht man dann mehr Hirnschmalz das noch auseinanderzuhalten als 
sich dem eigentlichen Sinn der Programmiererei zuzuwenden.

[Privatfrickler (Gast)]

Oder nehmt mal die ausufernde

const

Verwendung aus dem Beispielcode von ziglang aus meinem Post weiter oben.

Warum muss eine sich verändernde Zeilenlänge unbedingt ein const davor 
tragen? Das erscheint doch irgendwie widersinnig!

const line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

Mit Intuition kommt man jedenfalls nicht darauf.

[Yalu X. (yalu) (Moderator)]

Privatfrickler schrieb:
> Warum muss eine sich verändernde Zeilenlänge unbedingt ein const davor
> tragen? Das erscheint doch irgendwie widersinnig!
> const line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.

Privatfrickler schrieb:
> Oder nehmt mal die ausuferndeA
>
> const
>
> Verwendung

Deswegen sind in Rust alle Variablen defaultmäßig const, so dass dort
nichts ausufert. Nur dijenigen Variablen, die überschrieben werden
sollen, werden speziell deklariert, nämlich mit "mut".

[Privatfrickler (Gast)]

Yalu X. schrieb:
> Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.

Also ich sehe zumindest keine Zeichenkette die Konstant bleibt, sonst 
gäbe es ja kein

try stdout.print("Input too long.\n");

Aber vielleicht habe da auch einfach eine andere Sichtweise als du?

[Bernd K. (prof7bit)]

Privatfrickler schrieb:
> Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und
> schafft somit unnötig zusätzliche Komplexität. Wenn fünf
> Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden,

Die überwiegende Mehrheit inclusive der Zielgruppe C(++)-Umsteiger 
verwendet ja schon das simple = für die Zuweisung, also hat Rust die 
richtige Wahl getroffen. Ein := hätt ich aber genauso akzeptiert, ich 
mach noch viel Pascal nebenher, Probleme mit dem Umdenken kann ich nicht 
feststellen. Ab und zu vielleicht mal ein Vertipper wenn man zehnmal am 
Tag hin- und herwechselt aber der Compiler meckert sofort, keine große 
Sache.

Ich find das überhaupt nicht dramatisch.

Bei vielen (allen) Sachen muß man "umdenken", nicht nur bei der Syntax, 
wenn man die Sprache wechselt, mir rutscht auch zweimal die Woche ein ; 
am Zeilenende in Python raus und sofort klopft mir der Linter auf die 
Finger, ich empfinde das aber nicht als Erschwernis, mit der Zeit 
beherrscht man das im Schlaf und kann in 2 Sekunden fast vollständig 
umswitchen ohne nachzudenken.

[Yalu X. (yalu) (Moderator)]

Privatfrickler schrieb:
> Yalu X. schrieb:
>> Wo ändert sich line_len? Ich sehe da nur lesende Zugriffe.
>
> Also ich sehe zumindest keine Zeichenkette die Konstant bleibt, sonst
> gäbe es ja kein
> try stdout.print("Input too long.\n");
>
> Aber vielleicht habe da auch einfach eine andere Sichtweise als du?

Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
unbedingt, dass der Wert schon zur Compilezeit feststeht.

Auch die Zeichenkettenvariable line_buf könnte als const deklariert
werden, wenn es eine Möglichkeit gäbe, sie direkt bei ihrer Deklaration
zu initialisieren, etwa mit

   const line_buf: [20]u8 = io.readLine();

Da die Funktion io.readLine() die gelesene Zeichenkette aber nicht als
Funktionswert, sondern in einem variablen Funktionsargument zurückgibt,
gibt es diese Möglichkeit nicht. Deswegen wird line_buf zunächst mit
"undefined" initialisiert und danach durch io.readLine() überschrieben.

In Rust ist die "Constness" ebenso definiert, nur dass man dort das
Schlüsselwort "const" nicht explizit hinschreibt.

[Karl K. (karl2go)]

Privatfrickler schrieb:
> Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und
> schafft somit unnötig zusätzliche Komplexität. Wenn fünf
> Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden,
> dann hast du fünf-fachen Aufwand diese zu unterscheiden.

Ja aber wenn es eine Sprache so richtig verkackt hat wie C mit = und ==, 
dann muss man diesen Fehler wirklich nicht ständig wieder machen (JS, 
Python, Rust...).

Das hat schon was von Einsteins Satz über die Definition von Wahnsinn.

[Karl K. (karl2go)]

Yalu X. schrieb:
> Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
> einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
> ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
> unbedingt, dass der Wert schon zur Compilezeit feststeht.

Das ist ne ziemlich ungewöhnliche Definition einer Konstanten, finde 
ich. So wie: Wir wissen zwar noch nicht, wie groß Pi diesmal sein wird, 
aber wenn wir erstmal nen Wert haben lassen wir ihn so.

Gerade für Embedded finde ich das verwirrend, werden Konstanten dort 
doch oft direkt in den Code eingebaut (ldi, cpi, subi), was ja irgendwie 
schwer geht wenn sie noch nicht feststehen.

Also muss der Compiler wieder unterscheiden zwischen "echten" Konstanten 
und - naja, nennen wir sie Variablen.

[Privatfrickler (Gast)]

Yalu X. schrieb:
> Deswegen wird line_buf zunächst mit
> "undefined" initialisiert und danach durch io.readLine() überschrieben.

Dagegen habe ich ja auch überhaupt nichts einzuwenden. Man möchte einen 
Zeichenpuffer bereitstellen, dessen Größe man zunächst nicht angeben 
möchte (wobei das ja an sich schon irrig ist, denn dann müsste man ja 
MÖGLICHERWEISE AUCH von ausgehen, dass der Zeichenpuffer beispielsweise 
auch unsinnig groß (1 TB) werden könnte, aber wer will das schon?). Also 
bekommt er ein "undefined" aufgepappt und geht damit in die while(true) 
Endlosschleife. Nun kommt der Lesevorgang (io.readline). Der wird doch 
immer wieder ausgeführt, solange der catch nix schlimmes signalisiert. 
Also wird der Zeilenpuffer auch immer wieder mit anderen Wertlängen 
beschrieben. Was ist daran nun Konstant?

Mich stört einfach der Begriff const hier. Wenn es nur darum geht, 
auszuschließen, dass sonstwie (an anderer Codestelle) auf den Puffer 
zugegriffen wird, wäre doch so was wie ein blocked viel angebrachter.

anstatt

const line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

müsste es beispielsweise heißen

blocked line_len = io.readLine(line_buf[0..]) catch |err| switch (err)

const. wäre dann nur noch für wirklich konstante Längen verwendbar

Wie auch immer. Sowas nervt mich eben, hält einfach von anderem ab und 
stielt unnütz meine Zeit.

[Yalu X. (yalu) (Moderator)]

Karl K. schrieb:
> Ja aber wenn es eine Sprache so richtig verkackt hat wie C mit = und ==,
> dann muss man diesen Fehler wirklich nicht ständig wieder machen (JS,
> Python, Rust...).

Das Problem bei C ist ja nicht, dass die Operatoren = und == heißen,
sondern dass eine Zuweisung (bspw. a=13) ein Ausdruck mit einem
Ergebniswert (im Beispiel: 13) ist, der als Bedingung in einem if- oder
while- oder for-Konstrukt verwendet werden kann, bspw. in if(a=13) ...,
was oft nicht beabsichtigt ist.

In Python führt if a=13: ... zu einem Syntaxfehler. Aber auch die
C-Compiler sind mittlerweile so weit, dass sie bei if(a=13) ..., obwohl
syntaktisch korrekt, wenigstens eine Warnung auisgeben.

Karl K. schrieb:
> Yalu X. schrieb:
>> Const bedeutet in diesem Zusammenhang, dass die Variable, nachdem sie
>> einmal initialisiert, d.h. an einen Wert gebunden worden ist, während
>> ihrer gesamten Lebensdauer diesen Wert beibehält. Das bedeutet nicht
>> unbedingt, dass der Wert schon zur Compilezeit feststeht.
>
> Das ist ne ziemlich ungewöhnliche Definition einer Konstanten, finde
> ich. So wie: Wir wissen zwar noch nicht, wie groß Pi diesmal sein wird,
> aber wenn wir erstmal nen Wert haben lassen wir ihn so.

Im englischen Sprachgebrauch unterscheidet man zwischen

  compile-time constant

und

  immutable

In C++ werden dafür die beiden Schlüsselwörter "constexpr" und "const"
verwendet, um diesen Unterschied deutlich zu machen.

In der Mathematik wäre eine Konstante wie π oder e compile-time constant
und eine gewöhnliche Variable immutable. Mutable Variablen gibt es in
der mathematischen Formelsprache nicht, da es dort auch keine
Zuweisungen gibt.

[Privatfrickler (Gast)]

Yalu X. schrieb:
> Mutable Variablen gibt es in
> der mathematischen Formelsprache nicht, da es dort auch keine
> Zuweisungen gibt.

Was genau meinst du denn jetzt mit "mathematischer Formelsprache"?

y = 1 Konstant
y = x für x e R nicht mehr allzu Konstant oder?

[Yalu X. (yalu) (Moderator)]

Privatfrickler schrieb:
> Nun kommt der Lesevorgang (io.readline). Der wird doch
> immer wieder ausgeführt, solange der catch nix schlimmes signalisiert.
> Also wird der Zeilenpuffer auch immer wieder mit anderen Wertlängen
> beschrieben. Was ist daran nun Konstant?

Der Zeilenpuffer kann ja aus dem o.g. Grund sowieso nicht als const
deklariert werden. Aber nehmen wir wieder line_len als Beispiel:

Diese (immutable) Variable ist innerhalb der While-Rumpfs deklariert.
Ihre Lebensdauer erstreckt sich damit von der Zeile, in der sie
deklariert wird bis zum Ende des While-Rumpfs, also bis zur schließenden
geschweiften Klammer in der zweitletzten Codezeile.

Mit jedem Schleifendurchlauf wird die Variable (zumindest formal) neu
geschaffen und am Ende dieses Schleifendurchlaufs wieder zerstört.
Dazwischen wird die Variable kein einziges Mal überschrieben.

> Mich stört einfach der Begriff const hier. Wenn es nur darum geht,
> auszuschließen, dass sonstwie (an anderer Codestelle) auf den Puffer
> zugegriffen wird, wäre doch so was wie ein blocked viel angebrachter.

Ich gebe dir recht, dass das Schlüsselwort "const" etwas unglücklich
gewählt ist. Aber auch der Begriff "blocked" würde mich in diesem
Zusammenhang stören. Mit "blocked" verbinde ich etwas Laufendes, was
plötzlich angehalten wird. Vielleicht können wir uns ja auf "immutable"
als besten Kompromiss einigen.

Oder man geht der Diskussion ganz aus dem Weg, indem man wie in Rust
solche const/immutable Variablen gar nicht explizit als solche
deklariert :)

[Yalu X. (yalu) (Moderator)]

Privatfrickler schrieb:
> Yalu X. schrieb:
>> Mutable Variablen gibt es in
>> der mathematischen Formelsprache nicht, da es dort auch keine
>> Zuweisungen gibt.
>
> Was genau meinst du denn jetzt mit "mathematischer Formelsprache"?
>
> y = 1 Konstant
> y = x für x e R nicht mehr allzu Konstant oder?

Richtig, deswegen heißt man y ja auch eine Variable und keine Konstante.
y ist aber auch nicht so variabel wie eine mutable Variable in einer
Programmiersprache. In C kann man schreiben:

  y = 3;
  y = y + 1;

wodurch y am Ende den Wert 4 hat.

In der Mathematik wäre die zweite Zeile entweder eine nicht lösbare
Gleichung oder eine wenig sinnhafte rekursive Definition für y.

Als rekursive Definition wird die zweite Zeile übrigens auch in
Funktionalsprachen (die stark von der mathematischen Schreib- und
Denkweise inspiriert sind) interpretiert. Auch dort ergibt sie praktisch
keinen Sinn.

Der Ausdruck x ∈ ℝ bedeutet in der Mathematik nicht, dass x alle paar
Sekunden einen neuen Wert annimmt. Er bedeutet vielmehr, dass x einen
beliebigen Wert annehmen darf, der aber im nachfolgenden Text (wenn
bspw. irgendwelche Sätze aufgestellt werden, in denen y vorkommt) fest
bleibt.

[Privatfrickler (Gast)]

Yalu X. schrieb:
> Der Zeilenpuffer kann ja aus dem o.g. Grund sowieso nicht als const
> deklariert werden.

Es ging ja auch nicht um den Inhalt des Zeilenpuffers

also ob da "abcde" oder "12345" drin steht, sondern um die Länge also
"abc" (3 Zeichen + Zeilenende) oder "dieKatzeLiegtImSchnee" (21 Zeichen 
+ Zeilenende)

> Aber nehmen wir wieder line_len als Beispiel:
> Diese (immutable) Variable ist innerhalb der While-Rumpfs deklariert.

Richtig.

> Ihre Lebensdauer erstreckt sich damit von der Zeile, in der sie
> deklariert wird bis zum Ende des While-Rumpfs, also bis zur schließenden
> geschweiften Klammer in der zweitletzten Codezeile.

Korrekt.

> Mit jedem Schleifendurchlauf wird die Variable (zumindest formal) neu
> geschaffen und am Ende dieses Schleifendurchlaufs wieder zerstört.

Einverstanden. Das habe ich in der Tat übersehen.

> Dazwischen wird die Variable kein einziges Mal überschrieben.

Es droht aber auch kein einziges Überschreiben. Von nirgendwo.
line_len dient der immutable Variablen guess, um die Methode 
parseUnsigned() mit der richtigen Pufferlänge beim Parsen zu versorgen.

Mir kommt das vor als ob hier eine "Gefahr" bekämpft werden soll, die 
gar nicht besteht. Wenn line_len mutable wäre, was würde sich hier 
ändern?

>> Mich stört einfach der Begriff const hier. Wenn es nur darum geht,
>> auszuschließen, dass sonstwie (an anderer Codestelle) auf den Puffer
>> zugegriffen wird, wäre doch so was wie ein blocked viel angebrachter.
>
> Der Begriff "blocked" würde mich in diesem Zusammenhang stören. Mit
> "blocked" verbinde ich etwas, das blockiert, also angehalten wird.
> Vielleicht können wir uns ja auf "immutable" als besten Kompromiss
> einigen.

Ich meinte halt irgend ein prägnantes Schlüsselwort, das dem 
Programmierer verdeutlicht, diesen Wert von außen nicht ändern zu 
dürfen. In dieser Konstellation geht das aber eh nicht.

Stellen wir uns aber einen Moment vor, line_len wäre außerhalb der 
while-Schleife deklariert. Die Variable line_len würde also nicht mit 
jedem Schleifendurchlauf neu angelegt und wäre somit auch nicht mehr 
ECHT const, erhielte sie doch von readline bei jedem Schleifendurchlauf 
einen neuen Wert zugewiesen.

Würde der Compiler für const. line_len nun eine Fehlermeldung werfen?
Falls ja, dann wäre ja alles wie (intuitiv) erwartet.
Falls nein, wäre der Begriff const hier eigentlich unsinnig.

Wäre die Variable außerhalb der while-Schleife als immutable line_len 
deklariert, würde das vielleicht bedeuten, der Programmierer darf 
line_len nicht (ohne weiteres) im Wert verändern (ergibt 
Compilerfehler?), eine Methode wie io.readline zur Laufzeit aber darf 
das und der Compiler meckert nicht?

> Oder man geht der Diskussion ganz aus dem Weg, indem man wie in Rust
> solche const/immutable Variablen gar nicht explizit als solche
> deklariert :)

Wir nähern uns.

:)

[Privatfrickler (Gast)]

Yalu X. schrieb:
> Der Ausdruck x ∈ ℝ bedeutet in der Mathematik nicht, dass x alle paar
> Sekunden einen neuen Wert annimmt. Er bedeutet vielmehr, dass x einen
> beliebigen Wert annehmen darf, der aber im nachfolgenden Text (wenn
> bspw. irgendwelche Sätze aufgestellt werden, in denen y vorkommt) fest
> bleibt.

Ja, aber es bedeutet auch nicht, dass x zwingend nur EINEN bestimmten 
Wert annehmen muss. Wie willst du eine einfache gerade in der Ebene auf 
EINEN bestimmten Wert vereinfachen? Das sind nun mal unendlich viele 
Werte, die so eine einfache Gerade definieren. Um damit zu rechnen 
vereinfachen wir halt die Gerade auf 2 konkrete Punktpaare (x0,y0), 
(x1,y1).

[malsehen (Gast)]

Konstanten sind variabel, bis sie
verändert werden.

Niclaus Wirth

Habe ich mal gehört, himself

[Hans (Gast)]

Privatfrickler schrieb:
> Yalu X. schrieb:
>> Der Ausdruck x ∈ ℝ bedeutet in der Mathematik nicht, dass x alle paar
>> Sekunden einen neuen Wert annimmt. Er bedeutet vielmehr, dass x einen
>> beliebigen Wert annehmen darf, der aber im nachfolgenden Text (wenn
>> bspw. irgendwelche Sätze aufgestellt werden, in denen y vorkommt) fest
>> bleibt.
>
> Ja, aber es bedeutet auch nicht, dass x zwingend nur EINEN bestimmten
> Wert annehmen muss. Wie willst du eine einfache gerade in der Ebene auf
> EINEN bestimmten Wert vereinfachen? Das sind nun mal unendlich viele
> Werte, die so eine einfache Gerade definieren. Um damit zu rechnen
> vereinfachen wir halt die Gerade auf 2 konkrete Punktpaare (x0,y0),
> (x1,y1).

naja, das wäre x ∈ ℝ² in einem x ∈ ℝ³ Raum... das hat nix mit dem 
beispiel zu tun. mehr dimensionale datentypen können die wenigsten 
sprachen. (complex und simd extentions ausgenommen).

aber tu dir nix an, hier in diesem forum gibt es nur python und 
assembler (habe ich in einem anderen thread lernen müssen).


Jedenfalls hätte ich nebenbei was sinnvolles beizutragen:


S. R. schrieb:
> nga schrieb:
>> Ich habe mir mit C und C++ schon öfters effizient in den Fuß geschossen,
>> was gerade auf µCs oft nicht direkt auffällt, das es keinen SegFault wie
>> auf dem PC gibt
>
> Den gibt es schon, heißt nur HardFault und führt normalerweise zu einem
> Reset. Unterbindet man das (z.B. durch einen eigenen HardFault-Handler),
> dann unterscheidet er sich nicht besonders von seinem PC-Pendanten.
> Weglaufende Pointer fängt man damit relativ gut ein.


eigentlich läuft auf einem ARM Cortex sehr vieles auf einen HardFault 
raus (wenn man nicht explizit was dagegen tut) und normalerweise sollte 
das sogar ein

while(1);

 ergeben (uuhhhhh schon wieder diese pöse syntax) und keinen reset.

ich würde mir grundsätzlich im startup file vom gdb einen breakpoint auf 
dein hardfault-symbol setzen.
Damit bekommst du dann im normalfall auch alle busfaults usw mit.

Aus den registern wird man mit ein bisschen Übung eigentlich recht 
schnell schlau. Man muss sich nur einmal die paar seiten in der ARM 
Bibel durchlesen um zu verstehen was wo steht.

btw. z.B. der gcc zeigt dir mit -Wall und -Wextra viele "beinschüsse" 
als warning an...

nga schrieb:
> Ich gehe stark davon aus, dass pure C/C++ eine
> kleinere Runtime hat (und damit erst einmal ein kleineres Binary), aber
> bei größeren Projekten sieht das evtl. anders aus (kann ich mangels
> einem solchen Projekt nicht testen).

C/C++ hat keine "runtime" ... die crt0 ist mehr oder weniger eine 
funktion die speicherbereiche initialisiert. das ist mit anderen 
compiler sprachen aber nicht anders.

am PC kommt einiges dazu weil um das betriebsystem "herumgebaut" wird.

Speicher ist im übrigen ein ziemlich dummer benchmark heutzutage... 
kleiner asm code muss nicht notwendigerweise schneller sein wie 
längerer.

dazu kommt, dass sogar die cortex prozessoren pipelines und dma haben. 
damit ist jegliches "ausrechnen" von zyklen eigentlich obsolet.


beim gcc und llvm sollte die sprache außerdem ziemlich wurscht sein...

im endeffekt steht zwischen source und binary immer irgend ein 
intermediate code...

also nimm was du für effizent empfindest.

73

[Privatfrickler (Gast)]

Der wo ich bin schrieb:
> An Alex G.:
>
> Anstatt durch die Blume zu implizieren ich sei kein Profi, hätte keine
> Ahnung oder bin einfach zu dumm, google mal "Rust severely disappoints
> me" von Eric Raymond. Am besten auch googeln wer das ist.

Da habe ich auch noch einen gefunden

https://hackernoon.com/why-im-dropping-rust-fd1c32986c88?gi=c50c80e066a1

"Conclusion

The problems I've encountered in option 1 through 3 leave me to believe 
that option 4, making bindings to C, would be the only working 
alternative for the library I'm trying to write. And now that I'm at 
this stage, I'm thinking, why write bindings to C when I could just as 
well be writing in C? Or C++?

There are some good things about Rust as a programming language. I quite 
like the way Match works. I like the idea behind traits much like the 
interfaces in Go, I like cargo as a packaging tool. But when it comes to 
the implementation details of traits, reference counting and impossible 
to overwrite behaviour of the compiler, I'm just forced to say: no. This 
will not work for me.

I sincerely hope that people continue to use and improve Rust. But I 
want to write games. Not wrestle with the compiler or having to write 
RFCs to make the language more favourable towards my goals."

Diesen Text inkl. Verweis auf Beispiele schrieb er aber Sep 11, 2016. 
Vielleicht ist der Inhalt damit auch nicht mehr ganz taufrisch. Das 
müssen andere beurteilen.

[Vincent H. (vinci)]

Privatfrickler schrieb:
> Da habe ich auch noch einen gefunden
>
> https://hackernoon.com/why-im-dropping-rust-fd1c32986c88?gi=c50c80e066a1

Nachdem du offensichtlich nicht einmal verstehst warum const wichtig ist 
oder dich mit der Lappalie der Wortwahl herumschlägst kann ich mir nicht 
vorstellen dass du auch nur eines der angesprochenen Probleme aus dem 
Link verstehst...

Wer das Konzept von Immuteability für unwichtig hält dem lege ich 
folgenden Talk ans Herz:
https://youtu.be/sPhpelUfu8Q

[W.S. (Gast)]

Yalu X. schrieb:
> Bist du sicher, dass deine Vision der optimalen Programmierpsrache ein
> Vorbrenner für C ist, der fast genauso aussieht und nur ein wenig
> unübersichtlicher ist? ;-) SCNR

gröhl...

Erstens ist es keineswegs meine Vision einer optimalen 
Programmiersprache, denn die war und ist schlichtweg Pascal.

Zweitens ist das, was ich beschrieben habe, eine Renovierung von C - mit 
dem Zweck, daß die Leute, die sich ansonsten Rust2, Tust, FRust und so 
weiter ausgedacht hätten - also alles Neuerfindungen, die dennoch 
genauso aussehen wie C und Basic - ihre Lebensenergie stattdessen in's 
Renovieren von C stecken würden.

Natürlich würde ein renoviertes C noch immer so ähnlich aussehen wie das 
bisherige C. Was denn sonst? Die Leute wie deine Rust-Erfinder können 
doch erwiesenermaßen nichts anderes als C (oder WOLLEN nichts anderes, 
was auf's Gleiche hinausläuft).

Und nochwas:

Warum seid ihr hier so unendlich kindisch?

Aus den Tagen früher Pubertät ist mir erinnerlich, daß wir Schulbuben 
uns damit übertreffen wollten, ob wie ganz besonders ausschließlich 
nur blonde Mädel oder rothaarige Mädel toll fänden.

Genauso geht das hier bei euch mit den Programmiersprachen.

Auch du glaubst, daß mein von mir an den Horizont von C-Programmierern 
angepaßter Vorschlag mein eigenes Ideal sei. Welch ein Irrtum. Oder 
eine böswillige Unterstellung.

W.S.

[Yalu X. (yalu) (Moderator)]

Privatfrickler schrieb:
> Stellen wir uns aber einen Moment vor, line_len wäre außerhalb der
> while-Schleife deklariert. Die Variable line_len würde also nicht mit
> jedem Schleifendurchlauf neu angelegt und wäre somit auch nicht mehr
> ECHT const, erhielte sie doch von readline bei jedem Schleifendurchlauf
> einen neuen Wert zugewiesen.
>
> Würde der Compiler für const. line_len nun eine Fehlermeldung werfen?

Ja.

> Falls ja, dann wäre ja alles wie (intuitiv) erwartet.

Freut mich :)

[Yalu X. (yalu) (Moderator)]

W.S. schrieb:
> Zweitens ist das, was ich beschrieben habe, eine Renovierung von C - mit
> dem Zweck, daß die Leute, die sich ansonsten Rust2, Tust, FRust und so
> weiter ausgedacht hätten - also alles Neuerfindungen, die dennoch
> genauso aussehen wie C und Basic - ihre Lebensenergie stattdessen in's
> Renovieren von C stecken würden.

Lass mich mal zusammenfassen:

1. Wie Bernd gezeigt hat, erfüllt Rust weitgehendst deine Anforderungen
   an ein renoviertes C.

2. Nach deiner Aussage sieht Rust sogar aus wie C.

Damit ist doch Rust genau das von dir propagierte, renovierte C,
zumindest müsste es das – nach allem was du geschrieben hast – aus
deiner Sicht sein.

Leute, die sich schon einmal wenigstens eine halbe Stunde mit Rust
beschäftigt haben, sehen das natürlich komplett anders. Und das zu
Recht, denn Rust hat zwar ein paar Kleinigkeiten mit C gemeinsam, wurde
aber im Wesentlichen von anderen Sprachen beeinflusst, die (mit Ausnahme
von C++) nicht das Geringste mit C zu tun haben:

  https://doc.rust-lang.org/reference/influences.html

[Jörg W. (dl8dtl) (Moderator)]

Yalu X. schrieb:
> Im englischen Sprachgebrauch unterscheidet man zwischen
>
>   compile-time constant
>
> und
>
>   immutable
>
> In C++ werden dafür die beiden Schlüsselwörter "constexpr" und "const"
> verwendet, um diesen Unterschied deutlich zu machen.

Danke. Endlich mal eine einfache und kurze Erklärung, was der
Unterschied zwischen "constexpr" und "const" ist.

[W.S. (Gast)]

Bernd K. schrieb:
> ? Die Syntax ist klar, es ist deutlich ersichtlich was eine
> Variablenddeklaration ist und was nicht, es gibt sogar ein eigenes
> Keyword dafür "let", ist das getrennt genug?
> also check (für meine Ansprüche zumindest)

Nein, so nicht.

Wenn man es überhaupt zuläßt, Typ- Konstanten- oder 
Variablendeklarationen innerhalb des Codes zuzulassen, dann öffnet das 
den Freiraum für Pfusch, was wir ja deutlichst in C bisher gesehen 
haben.
Erinnerst du dich an sowas:
static long otto = 77;
Die nächst hirnrissigere Stufe wäre dann sowas:
if((static long otto = 77)==karlheinz)...;
Also: saubere Trennung und basta.


Bernd K. schrieb:
> ? Die Sprache soll verständlich sein, also sollte man schon sehen was
> man schreibt, denselben Operator für völlig unterschiedliche
> Operationen?
> Unfug

Kein Unfug. Es ist nämlich die gleiche Operation, lediglich einmal via 
Referenz sprich Zeiger.

Ich erklär's dir:
Wenn eine Variable vom Typ Pointer ist, dann weiß der Compiler und der 
Codeschreiber, daß das ein Pointer ist. Folglich sollte man das auch 
nicht nochmal durch überflüssige Schreibweisen doppelmoppeln. Bei 
Funktionsargumenten via Referenz tut man das ja auch nicht.

Kleines Beispiel aus dem Stegreif:
( ":=" von Pascal übernommen, wäre aber diskutabel)
typ
 Typ1 : struct { X : int; Y : int };
 Typ2 : pointer of Typ1;

var
 VAVA : Typ1;
 POIN : Typ2;
 POI2 : Typ2;

code
 VAVA.X := 7;    // Zuweisungen an Members
 VAVA.Y := -3;
 POIN   := new(Typ1);
 POIN.X := 14;   // auch Zuweisung an Members
 POIN.Y :=  0;
 POI2   := @VAVA;

Da also jeder weiß, daß POIN ein Zeiger ist, braucht das für den Zugriff 
auf die Members des Zeigers nicht nochmal separat mit sowas wie -> 
ausgewiesen zu werden, ein schlichter Punkt reicht aus - und das 
vereinheitlicht die Syntax.

Ob man dabei wie in Pascal auch noch den Zeiger als solchen kennzeichnen 
soll ( POIN^.X := 14; ) oder ob man das wegläßt, weil es ja ohnehin klar 
ist, daß da ein Zeigerzugriff fällig ist, sei mal dahingestellt.


Bernd K. schrieb:
> fn foo(x: i32) -> i32

Das wiederum ist unsystematisch und führt nur zu Verwicklungen.
Immerhin wäre das Generalschema so:
typ
 bezeichner : typbeteichnung;

und da fällt eben auch eine Funktion darunter:
 function bezeichner < argumentdeklaration >  < : typbezeichnung > ;

also
 // eine function mit Argument(en), aber void
 function angela (a: integer; b: sonstwas);

 // eine function, hier ohne Argumente
 function horst : boolean;

 // eine function mit allem
 function konrad (a: integer; b: sonstwas): string;

Kurzum, für die Typ-Deklaration einer Funktion eine Extrawurst per "->" 
zu braten, halte ich für unsystematischen Unfug.


Privatfrickler schrieb:
> Gerade die "Kosmetik" zwingt aber leidlich zum permanenten Umdenken und
> schafft somit unnötig zusätzliche Komplexität. Wenn fünf
> Programmiersprachen fünf verschiedene Symbole für Zuweisungen verwenden,
> dann hast du fünf-fachen Aufwand diese zu unterscheiden. Und es bleibt
> ja nicht bei diesem einen Umstand. Für den Vergleich gibt es dann
> vielleicht wieder fünf verschiedene Symbole. Für einen Zeiger nochmals
> fünf weitere Unterschiedlichkeiten. Vor lauter Symboljongliererei
> verbraucht man dann mehr Hirnschmalz das noch auseinanderzuhalten als
> sich dem eigentlichen Sinn der Programmiererei zuzuwenden.

DAS ist mMn. ein würdiges Schlußwort unter diese ganze fruchtlose 
Diskussion um Rust und andere einschlägige Eintagsfliegen.

W.S.

[W.S. (Gast)]

Yalu X. schrieb:
> Const bedeutet in diesem Zusammenhang,...

Das ist erstens die Implikation, daß eine jegliche Konstante 
grundsätzlich in einer Variablen gehalten werden muß. Also auch die 
Konstanten, die ansonsten direkt in den Code eingebaut wären.

Das ist zweitens ein Hinweis darauf, daß CONST in anderen Zusammenhängen 
eben andere Bedeutungen hat. Also ist das Ganze nur eine 
Verkomplizierung der Sprache - genauso wie z.B. der Asterisk in C.

Die Lösung all dieser unseligen Verkomplizierungen sind Konstanten und 
typisierte Konstanten.

const
// normale Konstante OHNE Typangabe
  A = 100;
// typisiert, also in Form einer vorbelegten Variable
  B : integer = 100;

Das ist für jeden Programmierer weitaus klarer und übersichtlicher als 
das Herumgeeiere bei Rust.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> Yalu X. schrieb:
>> Bist du sicher, dass deine Vision der optimalen Programmierpsrache ein
>> Vorbrenner für C ist, der fast genauso aussieht und nur ein wenig
>> unübersichtlicher ist? ;-) SCNR
>
> gröhl...
>
> Erstens ist es keineswegs meine Vision einer optimalen
> Programmiersprache, denn die war und ist schlichtweg Pascal.
>
> Zweitens ist das, was ich beschrieben habe, eine Renovierung von C

Du hast mein Posting also nicht gelesen in dem ich auf alle Deine Punkte 
einzeln eingegangen bin. Ich haben auch das Gefühl daß Du Dir Rust keine 
einzige Sekunde lang angesehen hast und einfach so blind drauf los 
polterst, sonst würdest Du nicht fortlaufend behaupten Rust hätte keinen 
der Fehler von C behoben denn alle (in Worten: ALLE) von Dir 
aufgezählten Wunscheigenschaften einer Sprache bzw Verbesserungen 
gegenüber C(++) sind in Rust auf höchst elegante Weise implementiert!

Und die Grammatik von Rust hat übrigens deutlich mehr Ähnlichkeit mit 
Pascal als mit C!

> meine Vision einer optimalen
> Programmiersprache, denn die war und ist schlichtweg Pascal.

Dir gefällt also Pascal besser als C oder C++, das ist verständlich, mir 
geht es genauso. Aber Rust ist das bessere Pascal! Du behauptest Rust 
erreicht das nicht? Dann erklär also bitte mal was die letzten 
verbliebenen Vorteile von Pascal gegenüber Rust sein sollen und zwar an 
konkreten Beispielen (mit Code den man vergleichen kann).

Die konkrete Schreibweise von Schlüsselworten, Operatoren oder sonstigen 
Syntaxelementen, also sowas wie & statt @ oder = statt := oder {} statt 
begin end oder fn statt function oder struct statt record lass ich NICHT 
gelten, das ist reine Kosmetik, dadurch wird eine Sprache kein bisschen 
besser oder schlechter, es geht um die Grammatik und um die 
Eigenschaften der Sprache und die Eigenschaften des Typsystems und 
welche konkreten Vor- und Nachteile die bringen.

So leid es mir tut, aber da mußt Du jetzt leider entweder endlich etwas 
tiefer einsteigen um eine sinnvolle Antwort formulieren zu können oder 
Du mußt sagen "Sorry, ich hab keine Ahnung von Rust, ich kann also nicht 
das geringste zu der ganzen Diskussion beitragen" und dann in diesem 
Thread von Schreib- auf Lesemodus umschalten!

Ich erwarte eine sinnvolle Antwort erst in 7 Tagen, lass Dir also die 
Zeit die Du brauchst. Eine Woche sollte reichen um einen groben 
Überblick über die Eigenschaften von Rust zu bekommen und es einschätzen 
zu können.

Du kannst auch ablehnen. Ich kann durchaus verstehen daß man keinen Bock 
hat sich eine neue Sprache genauer anzuschauen wenn man schon alles hat 
was man in der Praxis braucht oder zu brauchen glaubt. ABER dann 
poltert man nicht wie ein Volltrottel drauf los und stellt dümmliche 
Falschbehauptungen über irgendwelche Eigenschaften der vollkommen 
unbekannten Sprache auf sondern hält entweder einfach mal die Klappe und 
liest das was andere Leute zu sagen haben die sich zumindest mal ein 
paar Tage lang damit befasst haben oder man stellt sinnvolle Fragen und 
wertet die Antworten aus.

[W.S. (Gast)]

Yalu X. schrieb:
> Lass mich mal zusammenfassen:

Ich fasse das mal zusammen: Du siehst den Wald vor Bäumen nicht und 
liebäugelst sehr leicht mit Verkomplizierungen und Hakeligkeiten in 
Programmiersprachen. Die regen dein Interesse an. Das war schon früher 
dein Hobby, jaja, ich weiß, denn ich erinnere mich dran und es ist dir 
unbenommen. Schließlich haben wir alle unsere Hobbies - und die sind 
höchst unterschiedlich.

Und nein, Bernd hat lediglich einige meiner Renovierungspunkte für C 
kommentiert. Das ist ein himmelweiter Unterschied zu Rust und ich bin 
mit seinen Kommentaren z.T. überhapt nicht einverstanden.

Ich hatte nicht ohne Grund weiter oben sinngemäß geschrieben, daß man 
die Qualität einer neuen Programmiersprache durchaus daran messen kann, 
ob deren Erfinder sie auf saubere Art per BNF oder einer anderen ebenso 
strengen Darstellung zu beschreiben in der Lage sind.

Das trifft für Rust nicht zu - und wie auch du hättest sehen können in 
diesem Thread, ist Rust noch unsystematischer und mit noch mehr Wenn's 
und Aber's gespickt als C. Rust ist eine Verkomplizierung von C und 
keine Verbesserung, geschweige denn eine Renovierung oder gar ein 
besserer Ersatz für C. Es ist eine Wurschtelsprache.

Und jetzt bin ich's leid.

W.S.

[Bernd K. (prof7bit)]

W.S. schrieb:
> Yalu X. schrieb:
>> Lass mich mal zusammenfassen:
>
> Ich fasse das mal zusammen: Du siehst den Wald vor Bäumen nicht

Nein, Yalu hat in wenigen Zeilen Deinen Widerspruch glasklar auf den 
Punkt gebracht, jeder kann es sehen und Dir fällt jetzt kein Weg mehr 
ein Dich da rauszuwinden.

Die einzige gültige Aussage Deinerseits wäre jetzt: "Sorry, sieht so aus 
als hätte ich totalen inkoherenten Bullshit verzapft. Ich nehme alles 
zurück."

[Yalu X. (yalu) (Moderator)]

W.S. schrieb:
> Wenn man es überhaupt zuläßt, Typ- Konstanten- oder
> Variablendeklarationen innerhalb des Codes zuzulassen, dann öffnet das
> den Freiraum für Pfusch, was wir ja deutlichst in C bisher gesehen
> haben.

Nein, ganz im Gegenteil: Das dient dazu, den Scope einzuschränken.

In früheren Basic-Dialekten hatten alle Veriable globalen Scope, was
sich als schlecht herausstellte, da man bei globalen Variablen nicht
leicht erkennen kann, wo sie überall verändert werden. Also wurden
funktionslokale Variablen eingeführt, wie auch Pascal sie kennt. C (und
die meisten neueren Sprachen) erweitern dieses Prinzips auf blocklokale
Variablen, die zusätzliche Vorteile bieten:

- Der Scope wird weiter eingeschränkt, was vor allem bei größeren
  Funktionen zum Tragen kommt.

- Eine Variable kann genau an der Stelle angelegt werden, wo sie auch
  mit einem sinnvollen Wert initialisiert werden kann. Dadurch werden
  uninitalisierte Variablen und Pseudoinitialisierungen mit sinnlosen
  Dummy-Werten vermieden.

> Bernd K. schrieb:
>> fn foo(x: i32) -> i32
>
> Das wiederum ist unsystematisch und führt nur zu Verwicklungen.
> Immerhin wäre das Generalschema so:
> typ
>  bezeichner : typbeteichnung;
>
> und da fällt eben auch eine Funktion darunter:
>  function bezeichner < argumentdeklaration >  < : typbezeichnung > ;
>
> also
>  // eine function mit Argument(en), aber void
>  function angela (a: integer; b: sonstwas);
>
>  // eine function, hier ohne Argumente
>  function horst : boolean;
>
>  // eine function mit allem
>  function konrad (a: integer; b: sonstwas): string;
>
> Kurzum, für die Typ-Deklaration einer Funktion eine Extrawurst per "->"
> zu braten, halte ich für unsystematischen Unfug.

Ist es aber nicht, denn : und -> haben zwei völlig verschiedene
Bedeutungen:

... :  t bedeutet: ... ist                  vom Typ t.
... -> t bedeutet: ... liefert ein Ergebnis vom Typ t.

Dass in Pascal beide Sachverhalte gleich notiert werden, reduziert zwar
etwas die Zahl der vom Compiler zu parsenden Tokens, aber logisch
konsistent ist das definitiv nicht.

[Yalu X. (yalu) (Moderator)]

W.S. schrieb:
> Und jetzt bin ich's leid.

Es ist ja völlig in Ordnung, dass Pascal für dich die optimale
Programmiersprache darstellt. Es ist auch völlig in Ordnung, wenn du
dich nicht mit anderen Sprachen beschäftigen möchtest, weil dir dazu die
Zeit oder die Lust fehlt.

Nur solltest du dann in Diskussionen über alternative Sprachen etwas
zurückhaltender sein.

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Hallo Yalu,

ich möchte noch kurz anmerken, dass ich deine Geduld in der 
const-Diskussion oben sehr bewundert habe. Ich bin hier schon wie ein 
Rumpelstilzchen auf und ab gehüpft, während Du Dein const-Zen 
durchgezogen hast.

Vorbildlich!

Herzliche Grüße

 Timm

[Karl K. (karl2go)]

Bernd K. schrieb:
> also sowas wie & statt @ oder = statt := oder {} statt
> begin end oder fn statt function oder struct statt record lass ich NICHT
> gelten, das ist reine Kosmetik, dadurch wird eine Sprache kein bisschen
> besser oder schlechter

Ähm: Doch!

Eine Hochsprache sollte für den Programmierer gut lesbar sein, und da 
stinken die C-Derivate - wozu ich auch JS... zähle - mit ihren {(}{)} 
Mischmasch regelmäßig ab. Nicht so sehr beim Schreiben, vor allem beim 
Lesen von fremden oder älteren eigenen Code bekomm ich da regelmäßig 
Augenkrebs.

Schlechte Kosmetik ist ein Argument gegen eine Programmiersprache.

[Carl D. (jcw2)]

Ja die vielen Sonderzeichen. Statt "x=y/z" ist doch "DIVIDE y BY z 
GIVING x" um so viel klarer in der Aussage.

[Alex G. (dragongamer)]

Karl K. schrieb:
> Schlechte Kosmetik ist ein Argument gegen eine Programmiersprache.
Naja, Sache ist allerdings dass dies Gewöhnungssache ist.
Ich benutze auch hauptsächlich Sprachen mit{ und }. Wenn ichd ann mal 
Python code lesen muss, mit seinem BEGIN Kram, ist das extrem 
anstrengend und unübersichtlich...

[Timm R. (Firma: privatfrickler.de) (treinisch)]

Alex G. schrieb im Beitrag #5526641
> Python code lesen muss, mit seinem BEGIN Kram, ist das extrem
> anstrengend und unübersichtlich...

hmm, könnte mir mal kurz jemand auf die Sprünge helfen? Bis betzt dacht 
ich, ich könnte Python ein wenig, aber scheinbar ist mir da etwas 
entgangen? Oder gibt es jetzt neuerdings inline Pascal in Python?

Viele liebe Grüße
Timm

[Privatfrickler (Gast)]

Vincent H. schrieb:
> Privatfrickler schrieb:
>> Da habe ich auch noch einen gefunden
>>
>> https://hackernoon.com/why-im-dropping-rust-fd1c32...
>
> Nachdem du offensichtlich nicht einmal verstehst warum const wichtig ist

Da bist du im Irrtum. Ich habe halt eine eigene Vorstellung davon was 
sich const nennen sollte und was nicht. Im übrigen ging es in dem 
Beispiel um eine mir völlig fremde und somit neue Programmiersprache, 
die sich ziglang nennt und die ein paar Fragen für mich aufwarf. Ich 
habe nicht vor nun zu dieser weitgehend unbekannten Programmiersprache 
umzuschwenken. Dazu fehlt mir die Zeit und auch schlicht die Lust.

Im übrigen wurde das geklärt.

> oder dich mit der Lappalie der Wortwahl herumschlägst kann ich mir nicht
> vorstellen dass du auch nur eines der angesprochenen Probleme aus dem
> Link verstehst...

Du kannst dir wohl einiges nicht vorstellen. Brauchst du auch nicht. Das 
interessiert hier nämlich keinen, was DU dir vorstellen kannst oder 
nicht.

[Alex G. (dragongamer)]

Timm R. schrieb:
> Alex G. schrieb im Beitrag #5526641
>> Python code lesen muss, mit seinem BEGIN Kram, ist das extrem
>> anstrengend und unübersichtlich...
>
> hmm, könnte mir mal kurz jemand auf die Sprünge helfen? Bis betzt dacht
> ich, ich könnte Python ein wenig, aber scheinbar ist mir da etwas
> entgangen? Oder gibt es jetzt neuerdings inline Pascal in Python?
>
> Viele liebe Grüße
> Timm
Wenn du häufig python nutzst, empfindest du das sicherlich nicht so wie 
ich - genau darauf wollte ich ja hinaus.
Mein Gehirn hat sich darauf eingestellt, aus { und }, die Struktur zu 
bilden und das passiert intuitiv.
Bei BEGIN und END muss ich aktiv überlgen "ah, hier beginnt der Block, 
hier endet er".
Nur die Einrückung reicht auch irgendwie nicht für meine Intuition.

Inline Kram ist in der tat häufig unübersichtlicher, wobei das aber mehr 
am Schreiber liegt. In der Regel muss man es ja nicht wirklich in einer 
Zeile schreiben.

[Privatfrickler (Gast)]

W.S. schrieb:
>> fn foo(x: i32) -> i32
>
> Das wiederum ist unsystematisch und führt nur zu Verwicklungen.
> Immerhin wäre das Generalschema so:
> typ
>  bezeichner : typbeteichnung;
>
> und da fällt eben auch eine Funktion darunter:
>  function bezeichner < argumentdeklaration >  < : typbezeichnung > ;
>
> also
>  // eine function mit Argument(en), aber void
>  function angela (a: integer; b: sonstwas);
>
>  // eine function, hier ohne Argumente
>  function horst : boolean;
>
>  // eine function mit allem
>  function konrad (a: integer; b: sonstwas): string;
>
> Kurzum, für die Typ-Deklaration einer Funktion eine Extrawurst per "->"
> zu braten, halte ich für unsystematischen Unfug.

Kann ich gut nachvollziehen. Es drängt sich der Eindruck auf, hier 
teilen sich die Vorstellungen der Beteiligten. Die einen sind 
anscheinend ganz verpicht darauf neue Extrawürste serviert zu bekommen, 
nach dem Motto, öfter mal was neues, das alte kennen wir bereits zu gut, 
wird langweilig. Und die anderen sehen daran mehr Verdruss als 
wirklichen Nutzen.

W.S. schrieb:
> Yalu X. schrieb:
>> Lass mich mal zusammenfassen:
>
> Ich fasse das mal zusammen: Du siehst den Wald vor Bäumen nicht und
> liebäugelst sehr leicht mit Verkomplizierungen und Hakeligkeiten in
> Programmiersprachen. Die regen dein Interesse an. Das war schon früher
> dein Hobby, jaja, ich weiß, denn ich erinnere mich dran und es ist dir
> unbenommen. Schließlich haben wir alle unsere Hobbies - und die sind
> höchst unterschiedlich.

Ich glaube der Kernsatz ist "Die regen dein Interesse an". Vielleicht 
liegt dem geistige Unterauslastung zugrunde, ausgeprägter Spieltrieb, 
Langeweile oder eine Kombination aus all dem. Andere haben halt noch 
andere Neigungen und vor allem Prioritäten. Die Zeit, die man für A 
aufwendet fehlt bei B und umgekehrt.

[Bernd K. (prof7bit)]

Alex G. schrieb:
> Wenn du häufig python nutzst, empfindest du das sicherlich nicht so wie
> ich - genau darauf wollte ich ja hinaus.
> Mein Gehirn hat sich darauf eingestellt, aus { und }, die Struktur zu
> bilden und das passiert intuitiv.
> Bei BEGIN und END muss ich aktiv überlgen "ah, hier beginnt der Block,
> hier endet er".

Du verstehst es nicht. es wurde durch die Blume angedeutet daß Du besser 
mal aufhörst irgendwelche Bemerkungen zu Python zu machen obwohl Du 
offensichtlich noch nie im Leben eine Zeile Python gesehen hast (und 
auch noch nie eine Sprache die begin und end verwendet).

Also nochmal, etwas direkter formuliert:

In Python gibts keine Blockmarkierungen durch begin end. Das ist eine 
andere Sprache. Die Tatsache daß Du die verwechselst sagt daß Du keine 
davon kennst, geschweige denn je damit praktisch gearbeitet hast, also 
bist Du per Definition nicht qualifiziert über deren praktische Vor- 
oder Nachteile auch nur den Hauch einer Aussage zu tätigen.

Verstehst Du es jetzt? Ist es Dir wenigstens ein ganz kleines bisschen 
peinlich?

[Privatfrickler (Gast)]

Yalu X. schrieb:
>> Kurzum, für die Typ-Deklaration einer Funktion eine Extrawurst per "->"
>> zu braten, halte ich für unsystematischen Unfug.
>
> Ist es aber nicht, denn : und -> haben zwei völlig verschiedene
> Bedeutungen:
>
> ... :  t bedeutet: ... ist                  vom Typ t.
> ... -> t bedeutet: ... liefert ein Ergebnis vom Typ t.

Das ist doch die nächste Verwirrung. Wie willst du ein Ergebnis vom Typ 
i32 zurückliefern, ohne das in der Verpackung einer i32 Variablen zu 
transportieren?

Als Pointer auf i32 vielleicht. Aber bestimmt nicht in einem Char.

> Dass in Pascal beide Sachverhalte gleich notiert werden, reduziert zwar
> etwas die Zahl der vom Compiler zu parsenden Tokens, aber logisch
> konsistent ist das definitiv nicht.

Und wie man sieht ist Rust hier auch kein Paradebeispiel für Klarheit. 
Intuition geht anders.

[Privatfrickler (Gast)]

Bernd K. schrieb:
> In Python gibts keine Blockmarkierungen durch begin end. Das ist eine
> andere Sprache. Die Tatsache daß Du die verwechselst sagt daß Du keine
> davon kennst, geschweige denn je damit praktisch gearbeitet hast, also
> bist Du per Definition nicht qualifiziert über deren praktische Vor-
> oder Nachteile auch nur den Hauch einer Aussage zu tätigen.

Naja, über den Unsinn bei Python mit seiner durch Einrückung erzwungenen 
Blockkennzeichnung wird auch heftigst und Kontrovers bestritten.

[Privatfrickler (Gast)]

Karl K. schrieb:
> Eine Hochsprache sollte für den Programmierer gut lesbar sein, und da
> stinken die C-Derivate - wozu ich auch JS... zähle - mit ihren {(}{)}
> Mischmasch regelmäßig ab. Nicht so sehr beim Schreiben, vor allem beim
> Lesen von fremden oder älteren eigenen Code bekomm ich da regelmäßig
> Augenkrebs.
>
> Schlechte Kosmetik ist ein Argument gegen eine Programmiersprache.

Das sehe ich auch so.

[Bernd K. (prof7bit)]

Privatfrickler schrieb:
> Und wie man sieht ist Rust hier auch kein Paradebeispiel für Klarheit.
> Intuition geht anders.

Das kann man sehen wie man will. Ein Mathematiker würde sicherlich den 
Pfeil bevorzugen, das hat wahrscheinlich auch seine Wurzeln in Haskell.

Oder schau Dir mal diesen Schnipsel an:

fn add(x: i32, y: i32) -> i32 {
    x + y
}

fn sub(x: i32, y: i32) -> i32 {
    x - y
}

fn calc(f: fn(i32, i32) -> i32, x:i32, y: i32) -> i32 {
    f(x, y)
}

fn main() {
    let x = calc(add, 2, 3);
    let y = calc(sub, 2, 3);

    println!("{} {}", x, y);
}

Und dann ersetz mal -> durch : und erzähl mir daß es besser aussieht 
oder klarer wird. Das Gegenteil wäre der Fall.

[Bernd K. (prof7bit)]

Privatfrickler schrieb:
> Naja, über den Unsinn bei Python mit seiner durch Einrückung erzwungenen
> Blockkennzeichnung wird auch heftigst und Kontrovers bestritten.

Nur von denen die es nicht selbst benutzen, also von denen die 
eigentlich gar nicht wissen worüber sie schwafeln. Alle anderen sind 
glücklich darüber weil es so viel besser und einfacher zu handhaben ist.

[Bernd K. (prof7bit)]

Privatfrickler schrieb:
> Das sehe ich auch so.

Kannst Du Dich nicht entscheiden? { } ist schlecht, kein { } ist auch 
schlecht, ja was denn nun?

[Karl K. (karl2go)]

Privatfrickler schrieb:
> Naja, über den Unsinn bei Python mit seiner durch Einrückung erzwungenen
> Blockkennzeichnung wird auch heftigst und Kontrovers bestritten.

Sollte man meinen. Aber mir haben schon Pythonianer erklärt, dass das 
ganz toll ist. Die Foren sind zwar voll von Leuten, die rumjammern weil 
ihr Phython-Script nicht geht, und am Ende kommt raus, dass sie mal 
wieder beim Rumkopieren Leerzeichen und Tabs gemischt haben. Aber nee, 
Blöcke allein durch Einrückung ist ganz toll.

[Bernd K. (prof7bit)]

Karl K. schrieb:
> Die Foren sind zwar voll von Leuten, die rumjammern weil
> ihr Phython-Script nicht geht, und am Ende kommt raus, dass sie mal
> wieder beim Rumkopieren Leerzeichen und Tabs gemischt haben. Aber nee,
> Blöcke allein durch Einrückung ist ganz toll.

Ja, ist es, und in der Praxis auch vollkommen problemlos. Und es fühlt 
sich sehr angenehm an. Gäbe es auch nur die geringsten Probleme damit 
wären sie mir schon aufgefallen, ich verbringe immerhin 8 Stunden jeden 
Tag mit Python.

In diesem Thread gehts aber um Rust und nicht um Python oder Haskell 
oder andere Sprachen mit offside-rule, Rust hat geschweifte Klammern und 
seit wann sind in diesem Forum neuerdings geschweifte Klammern verpöhnt 
und kaum ist die Abneigung gegen die Klammern ausgesprochen wird gegen 
die Abwesenheit derselben in anderen Sprachen auch wieder gewettert - 
von den selben Leuten!? Könnt ihr euch mal alle entscheiden für oder 
gegen was ihr seid und könnte man das Thema vielleicht wieder auf Rust 
zurücklenken?

Warum sehe ich zum Beispiel keine Diskussion über klassische 
OOP-Techniken vs Rust oder ähnliche hochexplosive Themen mit ultra 
Flamewar-Potential? DAS wäre vielleicht mal wirklich interessant, da 
könnte man vielleicht noch vereinzelte Perlen aus der Diskussion 
extrahieren aber warum müsst ihr euch stattdessen alle an solchem 
lächerlichen oberflächlichen Kleinkram der jenseits des Parsers schon 
gar nicht mehr existiert weil er so bedeutungslos ist hoch und 
runterziehen wie die bekloppten?

Das ist ja ungefähr so als ob man in größter Erregung schäumend vor Wut 
über den Sinn und die Zukunft von Elektrofahrzeugen streitet und das 
ganze allein am Fehlen des Kupplungspedals festmacht!

Liegts daran daß man dazu etwas tiefer einsteigen müsste in die Materie 
als mit "hello world"-Kenntnissen den selbsternannten 
Programmiersprachenexperten raushängen zu lassen? Liegts daran?

Langsam glaub ich echt der Fachkräftemangel ist real. Wenn dieses 
"Fachforum" in irgendeiner weise repräsentativ sein soll für die 
Insassen der hiesigen Industrieanstalten dann ist wirklich alles am 
Ende! Aber womöglich treffen sich hier auch nur die Ausgestoßenen, wenn 
ja wo gehts dann bitte zum richtigen Forum?

[Bernd K. (prof7bit)]

H. B. Reinhardt schrieb im Beitrag #5527364:
> Der Mod lässt eine Meinung wieder mal nicht gelten

Deine Meinung interessiert niemanden, auch nicht den Mod. Sie ist auch 
nicht relevant in diesem Thread weil sie nichts mit den Thema zu tun hat 
und auch sonst nichts zur Diskussion beiträgt. Du bettelst um Löschung 
und versuchst den Thread zu sabotieren.

Ich hoffe inständig daß bald eine automatische Filterlösung in Kraft 
gesetzt wird die den destruktiven Schwachsinn von asozialen Arschlöchern 
und Krawallbrüdern wie Dir schon löschen bevor er überhaut gespeichert 
wird so daß niemand mehr damit belästigt wird, noch nicht mal die Mods.

@Mods: ich würde das ganze Subnetz des Störers bis auf weiteres auf 
Login-Pflicht vor dem Posten setzen, der Kollateralschaden hält sich in 
Grenzen, lesenswerte Posts werden dadurch nicht behindert werden.

[Rufus Τ. F. (rufus)]

Bedankt Euch bei unserem kleinen gestörten Freund.