3 ms·
I think part of the problem is this: if you're say, a C++ programmer, you can write C++ in most other languages and have a working program, even if it's not idi
by Amezarak 10y ago
I think part of the problem is this: if you're say, a C++ programmer, you can write C++ in most other languages and have a working program, even if it's not idiomatic.
You can't in, say, SQL, Rust, or Lisp. That doesn't make them a priori harder than other languages, it just requires a shift in thinking, whereas if you're jumping to say, Java after C++, you can get started right away and hopefully pick up idiomatic Java as you go along.
Instead of thinking "here's how I would implement this in C++, now how do I translate that to Rust?" you have to cut that part out and think "how do I write this in Rust?" I mentioned SQL because that's where that really, really, clicked for me: if you ever write SQL and think imperatively, you are doing it wrong, you have to think in sets, and once you do that, SQL is the easiest and most natural thing in the world. The Rust Book is pretty good, but I think it would really benefit from an in-depth section early on explaining how writing in Rust requires a paradigm shift in your thinking, and exactly how to think Rust-ically. I'd write something here, but I'm still learning how. :)
- steveklabnik 10y agoWe're re-writing the Rust book at the moment: http://rust-lang.github.io/book/ http://rust-lang.github.io/book/ It doesn't explicitly have a section like this, exactly, but there are several "thinking in Rust" style chapters towards the end.
- kazagistar 10y ago(SQL is still kinda a crap language for dealing with sets, because the synatx does not represent the order in which set operation are applied or anything else; instead, they went with the "cobol" strategy of trying to make things like english.) But I agree with your premise, certainly.