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).
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
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
1 | Enums are a feature in many languages, but their capabilities differ |
2 | in each language. Rust’s enums are most similar to algebraic data types |
3 | 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
1 | The enum keyword allows the creation of a type which may be one of a |
2 | few different variants. Any variant which is valid as a struct is also |
3 | 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++:
1 | fn main() { |
2 | let cond = true; |
3 | let mut x: i32 = 6; |
4 | |
5 | if cond { |
6 | x = 5; |
7 | } |
8 | } |
Es gibt jetzt nur einen eklatanten unterschied: In meinem Beispiel
1 | let x = if cond { |
2 | 5 |
3 | } else { |
4 | 6 |
5 | }; |
ist x danach read-only, aber nicht const, d.h. x koennte per shadowing ueberdeckt werden, wenn man es braucht.
1 | fn main() { |
2 | let cond = true; |
3 | let x = if cond { |
4 | 5 |
5 | } else { |
6 | 6 |
7 | }; |
8 | |
9 | x = 7; |
10 | } |
11 | |
12 | error[E0384]: cannot assign twice to immutable variable `x` |
13 | --> src/main.rs:9:5 |
14 | | |
15 | 3 | let x = if cond { |
16 | | - first assignment to `x` |
17 | ... |
18 | 9 | x = 7; |
19 | | ^^^^^ 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?
1 | bool flag; |
2 | |
3 | // jede menge code
|
4 | |
5 | if (flag) { |
6 | |
7 | } else { |
8 | |
9 | }
|
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.
mh schrieb: > Kaj G. schrieb: . >> Was ich ebefalls schoen finde:fn main() { >
1 | > let cond = true; |
2 | > |
3 | > let x = if cond { |
4 | > 5 |
5 | > } else { |
6 | > 6 |
7 | > }; |
8 | > } |
9 | > |
>> 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: >
1 | > auto x = 6; |
2 | > if(cond) { |
3 | > x = 5; |
4 | > } |
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
1 | auto x = (cond) ? 5 : 6; |
Kaj G. schrieb: > Soweit ich das sehe, ist sowas in C/C++ nicht moeglich. Wenn man es unbedingt braucht:
1 | 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?
1 | 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.
1 | 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?
1 | 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.
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
Hallo, nicht 100% ernst gemeint: Vielleicht beginnt ja dann in Zukunft jeder noob sein Rust Programm mit
1 | unsafe { |
so wie in c++ das
1 | using namespace std; |
:-)) vlg Timm
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 ...
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
1 | <stdbool.h> |
eingebunden
1 | Building main.obj. |
2 | C:\Users\..\Documents\Pelles C Projects\bool01\main.c(22): warning #2229: Local 'flag' is potentially used without being initialized. |
3 | Done. |
Beitrag #5520584 wurde von einem Moderator gelöscht.
Beitrag #5520585 wurde von einem Moderator gelöscht.
Beitrag #5520586 wurde von einem Moderator gelöscht.
Beitrag #5520587 wurde von einem Moderator gelöscht.
Beitrag #5520600 wurde von einem Moderator gelöscht.
Beitrag #5520601 wurde von einem Moderator gelöscht.
Beitrag #5520602 wurde von einem Moderator gelöscht.
Beitrag #5520603 wurde von einem Moderator gelöscht.
Beitrag #5520604 wurde von einem Moderator gelöscht.
Beitrag #5520605 wurde von einem Moderator gelöscht.
Beitrag #5520606 wurde von einem Moderator gelöscht.
Beitrag #5520607 wurde von einem Moderator gelöscht.
Beitrag #5520608 wurde von einem Moderator gelöscht.
Beitrag #5520609 wurde von einem Moderator gelöscht.
Beitrag #5520610 wurde von einem Moderator gelöscht.
Beitrag #5520612 wurde von einem Moderator gelöscht.
Beitrag #5520613 wurde von einem Moderator gelöscht.
Beitrag #5520614 wurde von einem Moderator gelöscht.
Beitrag #5520615 wurde von einem Moderator gelöscht.
Beitrag #5520617 wurde von einem Moderator gelöscht.
Beitrag #5520619 wurde von einem Moderator gelöscht.
Beitrag #5520620 wurde von einem Moderator gelöscht.
Beitrag #5520621 wurde von einem Moderator gelöscht.
Beitrag #5522113 wurde von einem Moderator gelöscht.
Beitrag #5522114 wurde von einem Moderator gelöscht.
Beitrag #5522143 wurde von einem Moderator gelöscht.
Beitrag #5522144 wurde von einem Moderator gelöscht.
Beitrag #5522145 wurde von einem Moderator gelöscht.
Beitrag #5522146 wurde von einem Moderator gelöscht.
@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.
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.
Hallo Vincent, magst duu deinen Post noch mal lesen? Irgendwas stimmt da nicht. Viele liebe Grüße timm
:
Bearbeitet durch User
Err... zu meinte ich natürlich, Äquivalent zu C++, nicht in.
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?
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(++).
:
Bearbeitet durch User
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.
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 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!
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."
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...
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
:
Bearbeitet durch User
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/
1 | const builtin = @import("builtin"); |
2 | const std = @import("std"); |
3 | const io = std.io; |
4 | const fmt = std.fmt; |
5 | const os = std.os; |
6 | |
7 | pub fn main() !void { |
8 | var stdout_file = try io.getStdOut(); |
9 | var stdout_file_stream = io.FileOutStream.init(&stdout_file); |
10 | const stdout = &stdout_file_stream.stream; |
11 | |
12 | try stdout.print("Welcome to the Guess Number Game in Zig.\n"); |
13 | |
14 | var seed_bytes: [@sizeOf(u64)]u8 = undefined; |
15 | os.getRandomBytes(seed_bytes[0..]) catch |err| { |
16 | std.debug.warn("unable to seed random number generator: {}", err); |
17 | return err; |
18 | };
|
19 | const seed = std.mem.readInt(seed_bytes, u64, builtin.Endian.Big); |
20 | var prng = std.rand.DefaultPrng.init(seed); |
21 | |
22 | const answer = prng.random.range(u8, 0, 100) + 1; |
23 | |
24 | while (true) { |
25 | try stdout.print("\nGuess a number between 1 and 100: "); |
26 | var line_buf: [20]u8 = undefined; |
27 | |
28 | const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) { |
29 | error.InputTooLong => { |
30 | try stdout.print("Input too long.\n"); |
31 | continue; |
32 | },
|
33 | error.EndOfFile, error.StdInUnavailable => return err, |
34 | };
|
35 | |
36 | const guess = fmt.parseUnsigned(u8, line_buf[0..line_len], 10) catch { |
37 | try stdout.print("Invalid number.\n"); |
38 | continue; |
39 | };
|
40 | if (guess > answer) { |
41 | try stdout.print("Guess lower.\n"); |
42 | } else if (guess < answer) { |
43 | try stdout.print("Guess higher.\n"); |
44 | } else { |
45 | try stdout.print("You win!\n"); |
46 | return; |
47 | }
|
48 | }
|
49 | }
|
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
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.
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.
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?
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.
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
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:
1 | template< class type > |
2 | struct vector2 : public std::vector<type> { |
3 | type &last() { return this->operator[]( std::vector<type>::size() -1 ); } |
4 | };
|
oder
1 | struct Chunker { |
2 | protected:
|
3 | static volatile int printQueue; |
4 | };
|
vorkommt, muss man sich schon fragen, was da überhaupt vergleichbar sein soll.
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 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.
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.
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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.
Oder nehmt mal die ausufernde
1 | 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!
1 | const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) |
Mit Intuition kommt man jedenfalls nicht darauf.
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".
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
1 | try stdout.print("Input too long.\n"); |
Aber vielleicht habe da auch einfach eine andere Sichtweise als du?
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.
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.
:
Bearbeitet durch Moderator
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.
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.
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
1 | const line_len = io.readLine(line_buf[0..]) catch |err| switch (err) |
müsste es beispielsweise heißen
1 | 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.
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.
:
Bearbeitet durch Moderator
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?
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 :)
:
Bearbeitet durch 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:
1 | y = 3; |
2 | 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.
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. :)
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).
Konstanten sind variabel, bis sie verändert werden. Niclaus Wirth Habe ich mal gehört, himself
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
1 | 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
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.
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
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.
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 :)
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
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.
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.
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.
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.
:
Bearbeitet durch User
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.
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."
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.
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.
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
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.
Ja die vielen Sonderzeichen. Statt "x=y/z" ist doch "DIVIDE y BY z GIVING x" um so viel klarer in der Aussage.
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...
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
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.
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.
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.
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?
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.
Beitrag #5526789 wurde von einem Moderator gelöscht.
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.
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.
Beitrag #5526826 wurde von einem Moderator gelöscht.
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:
1 | fn add(x: i32, y: i32) -> i32 { |
2 | x + y |
3 | } |
4 | |
5 | fn sub(x: i32, y: i32) -> i32 { |
6 | x - y |
7 | } |
8 | |
9 | fn calc(f: fn(i32, i32) -> i32, x:i32, y: i32) -> i32 { |
10 | f(x, y) |
11 | } |
12 | |
13 | fn main() { |
14 | let x = calc(add, 2, 3); |
15 | let y = calc(sub, 2, 3); |
16 | |
17 | println!("{} {}", x, y); |
18 | } |
Und dann ersetz mal -> durch : und erzähl mir daß es besser aussieht oder klarer wird. Das Gegenteil wäre der Fall.
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.
Privatfrickler schrieb: > Das sehe ich auch so. Kannst Du Dich nicht entscheiden? { } ist schlecht, kein { } ist auch schlecht, ja was denn nun?
Beitrag #5526854 wurde von einem Moderator gelöscht.
Beitrag #5526871 wurde von einem Moderator gelöscht.
Beitrag #5526900 wurde von einem Moderator gelöscht.
Beitrag #5526910 wurde von einem Moderator gelöscht.
Beitrag #5526916 wurde von einem Moderator gelöscht.
Beitrag #5526921 wurde von einem Moderator gelöscht.
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.
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?
Beitrag #5527089 wurde von einem Moderator gelöscht.
Beitrag #5527093 wurde von einem Moderator gelöscht.
Beitrag #5527096 wurde von einem Moderator gelöscht.
Beitrag #5527348 wurde von einem Moderator gelöscht.
Beitrag #5527356 wurde von einem Moderator gelöscht.
Beitrag #5527358 wurde von einem Moderator gelöscht.
Beitrag #5527360 wurde von einem Moderator gelöscht.
Beitrag #5527361 wurde von einem Moderator gelöscht.
Beitrag #5527362 wurde von einem Moderator gelöscht.
Beitrag #5527363 wurde von einem Moderator gelöscht.
Beitrag #5527364 wurde von einem Moderator gelöscht.
Beitrag #5527365 wurde von einem Moderator gelöscht.
Beitrag #5527366 wurde von einem Moderator gelöscht.
Beitrag #5527367 wurde von einem Moderator gelöscht.
Beitrag #5527369 wurde von einem Moderator gelöscht.
Beitrag #5527371 wurde von einem Moderator gelöscht.
Beitrag #5527373 wurde von einem Moderator gelöscht.
Beitrag #5527374 wurde von einem Moderator gelöscht.
Beitrag #5527375 wurde von einem Moderator gelöscht.
Beitrag #5527376 wurde von einem Moderator gelöscht.
Beitrag #5527377 wurde von einem Moderator gelöscht.
Beitrag #5527379 wurde von einem Moderator gelöscht.
Beitrag #5527445 wurde von einem Moderator gelöscht.
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.
:
Bearbeitet durch User
Beitrag #5527506 wurde von einem Moderator gelöscht.
Beitrag #5527507 wurde von einem Moderator gelöscht.
Beitrag #5527508 wurde von einem Moderator gelöscht.
Beitrag #5527509 wurde von einem Moderator gelöscht.
Beitrag #5527511 wurde von einem Moderator gelöscht.
Beitrag #5527514 wurde von einem Moderator gelöscht.
Beitrag #5527517 wurde von einem Moderator gelöscht.
Beitrag #5527522 wurde von einem Moderator gelöscht.
Beitrag #5527558 wurde von einem Moderator gelöscht.
Beitrag #5527565 wurde von einem Moderator gelöscht.
Beitrag #5527567 wurde von einem Moderator gelöscht.
Beitrag #5527568 wurde von einem Moderator gelöscht.
Beitrag #5527569 wurde von einem Moderator gelöscht.
Dieser Beitrag ist gesperrt und kann nicht beantwortet werden.