3 ms·
The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation. Some of your potential synt
by laeri 3y ago
The `return?` idea of yours is nice as the `?` operator at the end might be overlooked but is a significant control flow operation.
Some of your potential syntax changes seem less readable but they might look nicer to you such as changing `attrs.clone().into_object()` into `clone attrs as object`. You probably come from a python background I would assume but the rust version is easier to parse and understand but maybe to you not visually appealing.
Having an explicit return argument I could understand. I found this weird in the beginning but this is something I got accustomed.
Not sure why square brackets should be favored instead of angle brackets.
The imports in the Rust version are also very explicit and fine I think.
Replacing `()` with `None` seems silly, same with replacing `Ok` with `ok`.
Maybe the `py_to_serde` arguments of the function definition spanning 4 lines could be considered unastethically pleasing. This is something I noticed quite a lot with Rust code. Fmt also seems to break to multiple lines quite fastly when writing function or method definitions.
- mjburgess 3y agoI find `<>` are visually distracting and take up far too visual space for their importance. `F[X]` is less arresting than `F<X>`, the thin vertical lines melt-away easier. I replaced () with `None` (& with ref, ! with run, etc.) because I want code to read like english (ie., literate) all other things being equal. I dont find `()` "pays the cost" of illegibility by syntactical convenience. Changing "operator-like methods" to operator words would have a radical impact on the parsing precedence and "overall look" of the lang. ... so `clone ...` would be more readable if those changes were made. The advantage of many keyword primitives is that you dont keep reusing the same syntax for everything... syntax is there to support expression. I think more is better. `Ok()` to `ok()` was more a broad notational philosophy of basic type constructors being unobtrusive. Scala has gone from C-like (v2) to python-like (v3) syntaxes --- and I think the ML-ish whitespace, python-ish "beat poetry" approach is mostly just better. I buy some arguments that symbolic redundancy can help (ie., both indent and use symbols)... but Rust's syntax philosophy is clearly to "keep adding symbols", and I dislike it. C uses symbols, but I do think C is quite beautiful mostly -- because it's so simple. Rust is creaking under the weight of its size and symbolic choices
- laeri 3y agoI would prefer not wanting to read code like english. You most certainly don't want o replace common math operators with plus/minus `c = a + b` is preferrable over `c is a plus b`. The second one is harder to parse and understand. When writing code you are pattern matching and certain special symbols such as `()` over `None` and `attrs.clone().into_object()` over `clone attrs as object` are just faster to detect at an instance. Using more english prose becomes a word salad that is harder to parse than using special symbols which convey meaning. Certainly more familiarity with a programming language and it's syntax elements will help you your pattern matching mechanism and allows you to understand code faster. In my opinion Smalltalk gets it quite well in this regard. I also would rather prefer lisp language syntax, or apl.