5 ms·

For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the b

by e_y_ 6y ago

For reading code, which arguably should happen more often than writing code, having the variable name first makes it easier to find, since it's right near the beginning of the line and it's a single word. If the type comes first, I have to scan the line to figure out where the type ends and the variable name begins. Also, having "let" at the beginning of the line makes it immediately clear that it's a variable definition, whereas if it starts with some arbitrary type I haven't seen before I have to spend more time figuring out what's happening. Good syntax highlighting helps, but I think starting with types like C/C++/D is less elegant than starting off with a keyword that clearly identifies what the line does. Similar applies for function definitions. It's nice when the function names are all lined up and not buried halfway across the screen because it has some long return type.

tastyminerals2 6y ago
Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name? double[] arr; bam! Simple and clear. What about functions? It has input, name and output and D nicely presents you with double[] createArray(int size) {...} This is as little typing as you can get while keeping readability. And here is a basic Rust function fn add_one(x: i32) -> i32 {...} What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala. What about Rust unable to drop parenthesis after a function? self.host_addr.clone() Should I mention Rust's UFCS? But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.
- skocznymroczny 6y ago
  You are nitpicking. size_t is architecture dependent, on x86 it will usually be 32-bit, on x86_64 it will be usually 64-bit. It's not equivalent to i32, u32 types. Also, I find i32 and u32 types much cleaner than D's "unsigned int" and "int". What is the difference between "unsigned int" and "unsigned long" in D? It's still better than C++, but I'd rather write i32 and i64 rather than "int" and "long".
- jbboehr 6y ago
  > this is just D's size_t Rust has usize [0] as a size_t equivalent. [0]: https://doc.rust-lang.org/std/primitive.usize.html https://doc.rust-lang.org/std/primitive.usize.html
- vvillena 6y ago
  > Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Usually, the reason is to make parsing easier. C++ is infamous for having undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is a clusterfuck. Newer languages have learned from that, so they try to have simpler grammars. Another reason for those small syntax markers is to avoid implicit language decisions. In Rust, having to write one of "let/let mut/const" means forcing the programmer to make an explicit choice regarding mutability and memory usage. In Scala, "val/lazy val/var/lazy var/def" means having to think about mutability and evaluation times. > What about Rust unable to drop parenthesis after a function? In the case of Rust, the reason is uniformity. Even Scala, of all languages, is walking back on the optional parentheses, because the language allows to define functions with multiple argument lists, and optional parentheses introduce ambiguity between functions with empty argument lists and functions with no argument lists.
  - tastyminerals2 6y ago
    Yes, "make an explicit choice regarding mutability" can be done even easier by actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr = [1, 2, 3];". See, no Scala val/var which to a person who doesn't know the language tell nothing. When the language grammar is unambiguous and coherent you have faster compiling times and occasionally better readability. D hits a nice spot in here by capitalizing on C++ mistakes. "optional parentheses introduce ambiguity" -- true, they do. However, I am struggling to understand why it is necessarily a bad thing? For a user I see a clear convenience of being able to write "double[] zeroArr = arr.zeros;" or "double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if that is not enough, you can also inject your custom method into this chain and it will just work. Don't know about Rust but Scala simply refuses to compile in such cases which for a functional language looks like a limitation. These are the D features that I really enjoy.

by e_y_ 6y ago

tastyminerals2 6y ago

Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Why would you want to explicitly tell that something is a value while all you need to do is write its type and name? double[] arr; bam! Simple and clear. What about functions? It has input, name and output and D nicely presents you with double[] createArray(int size) {...} This is as little typing as you can get while keeping readability. And here is a basic Rust function fn add_one(x: i32) -> i32 {...} What kind of type is i32 btw? oh, there is u32 as well. integer 32bit and unsigned 32bit? What on earth are these? Ah, this is just D's size_t, the same size_t as in C/C++. So that C/C++ ppl have zero overhead reading D code and for Rust they will google. To top that, you have also -> because of the type after the definition scheme. Needless verbosity, same thing in Scala. What about Rust unable to drop parenthesis after a function? self.host_addr.clone() Should I mention Rust's UFCS? But I am nitpicking, right. This doesn't make a language bad in any way. However, as I said, Rust readability is pretty subpar in addition to already steep language learning curve.

skocznymroczny 6y ago
You are nitpicking. size_t is architecture dependent, on x86 it will usually be 32-bit, on x86_64 it will be usually 64-bit. It's not equivalent to i32, u32 types. Also, I find i32 and u32 types much cleaner than D's "unsigned int" and "int". What is the difference between "unsigned int" and "unsigned long" in D? It's still better than C++, but I'd rather write i32 and i64 rather than "int" and "long".
jbboehr 6y ago
> this is just D's size_t Rust has usize [0] as a size_t equivalent. [0]: https://doc.rust-lang.org/std/primitive.usize.html https://doc.rust-lang.org/std/primitive.usize.html
vvillena 6y ago
> Subjectively, I see no point in having "val", "var", "let", "def", "fn" symbols which bring only noise to code. Usually, the reason is to make parsing easier. C++ is infamous for having undecidable grammar. Ruby is extremely pleasing to the eye, but its grammar is a clusterfuck. Newer languages have learned from that, so they try to have simpler grammars. Another reason for those small syntax markers is to avoid implicit language decisions. In Rust, having to write one of "let/let mut/const" means forcing the programmer to make an explicit choice regarding mutability and memory usage. In Scala, "val/lazy val/var/lazy var/def" means having to think about mutability and evaluation times. > What about Rust unable to drop parenthesis after a function? In the case of Rust, the reason is uniformity. Even Scala, of all languages, is walking back on the optional parentheses, because the language allows to define functions with multiple argument lists, and optional parentheses introduce ambiguity between functions with empty argument lists and functions with no argument lists.
- tastyminerals2 6y ago
  Yes, "make an explicit choice regarding mutability" can be done even easier by actually writing "immutable double[] arr = [1, 2, 3];", "const double[] arr = [1, 2, 3];". See, no Scala val/var which to a person who doesn't know the language tell nothing. When the language grammar is unambiguous and coherent you have faster compiling times and occasionally better readability. D hits a nice spot in here by capitalizing on C++ mistakes. "optional parentheses introduce ambiguity" -- true, they do. However, I am struggling to understand why it is necessarily a bad thing? For a user I see a clear convenience of being able to write "double[] zeroArr = arr.zeros;" or "double[] newArr = 6.iota.sliced(3, 2).array.reverse.dropOne.join;". And if that is not enough, you can also inject your custom method into this chain and it will just work. Don't know about Rust but Scala simply refuses to compile in such cases which for a functional language looks like a limitation. These are the D features that I really enjoy.