3 ms·

I get incredibly frustrated with 1) people who "design" (and I use the term very, very loosely) the actual tools you're learning, and 2) then even more so for t

I get incredibly frustrated with 1) people who "design" (and I use the term very, very loosely) the actual tools you're learning, and 2) then even more so for the people who teach the tools, as though it's the only thing that existed - even though any member of the target audience has to know a thousand very closely related things, so that honestly you could just point out the 5 tricky things. For point 1 - things should be like Python, not like resolving dependency hell in the 90's. Installation should be a double-click. Errors should not be easy to make, it should be obvious what things do, and error messages should be obvious. The people who design tools don't care about any of this stuff. For point 2 - honestly, 99% of people - as in, 99 out of 100 people, who pick up a Rust tutorial have programmed literally 4 other languages - they have written working lines of code in 4 other languages. Look at this shit: https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ (open the menu at top-left) - Guessing Game! The Dining Philosophers! "Let’s set up a new project. Go to your projects directory. Remember how we had to create our directory structure and a Cargo.toml for hello_world?" in just as many words that your poor audience has to read through you could have said: "semicolons terminate statements; blocks in curly braces; module import is use module::submodule::symbol; comment with // or /* */ which can nest." Look very very closely at my two strings in this paragraph: they contain literally just as many characters. You could start by summarizing go in a sentence and get people going, not trace it back to the ENIAC. I hate this GOBS and GOBS of time people assume we have. And back to point 1, tool writers assume we have like infinite time to follow 27-point directions that could be 100% automated. And tutorial writers assume we have infinite time to read all about the history of the world. I have to watch YouTube videos at 2x speed so that they're sounding like they're rapping, just so I can get to all the stuff I don't need. Get to the point, people. Not everyone has a picnic following directions that shouldn't even exist.

maxerickson 11y ago
1, tool writers assume we have like infinite time to follow 27-point directions that could be 100% automated. And tutorial writers assume we have infinite time to read all about the history of the world. An alternative explanation is that their audience is wider than your stated 99%. Somewhat ironically, if you scroll down ~20 lines on the Rust book page you linked there is the deep water you are demanding.
- logicallee 11y ago
  I don't think, for example, "semicolons terminate statements; blocks in curly braces; module import is use module::submodule::symbol; comment with // or /* */ which can nest." is deep water. The tutorial has to make a decision: does its audience know what a loop is, or how to even think about an algorithm that would use it? If the audience doesn't, then it's not a Rust programming language book, it's a Beginning Programming with Rust book. If the audience does, then they just need to be told the syntax. Even when they ostensibly do that, "The main concept that makes Rust unique is called ‘ownership’. Consider this small example:" could be better-stated as a difference between Rust and (list the languages that don't have it.) Tutorial authors and tool authors also waste INCREDIBLE amounts of time through dishonesty. For example, Functional Programming like Haskell is largely defined by the hoops you have to jump through syntactically and in program structure due to what it avoids. But a Haskell tutorial will NEVER make it obvious within the first two minutes that you are doing something fundamental different from C, Java, Python, C#, Perl, whatever - and that it has a whole concept, monads, just to get around this artificially imposed self-limitation. They're just dishonest, waste incredible gobs of time, and don't get to the point. When was the last time you picked up a language book that made it completely obvious in the first minute what it was and wasn't suited for, how many hours you would need to practice it before you made progress, and what the absolute bare minimum number of minutes you would need to invest before you could start doing anything in it was? It's a guessing game. "Wow, this only took me two minutes!" (json). "Wow this took me two weeks and I still can't do shit!" (haskell) I Googled "I tried learning haskell for" to report on what I found. There happens to be one hit on that exact syntax. Guess how long the guy "tried" learning haskell for? A few months.
  - maxerickson 11y ago
    This gets back to the thing where the author (probably necessarily) has to write for a wide audience. Someone who enjoyed math in various school classes will probably understand the basics of functional programming faster than someone who only worked their way through it. So one of them might be just as angry as you are at the bad advice in the front matter of the book.
muraiki 11y ago
From the Rust book intro: "After reading this introduction, you’ll want to dive into either ‘Learn Rust’ or ‘Syntax and Semantics’, depending on your preference: ‘Learn Rust’ if you want to dive in with a project, or ‘Syntax and Semantics’ if you prefer to start small, and learn a single concept thoroughly before moving onto the next. Copious cross-linking connects these parts together." It sounds like you should have started at "Syntax and Semantics". For me, I really enjoyed starting in "Learn Rust" because I'm more of a "learn by doing" kind of person, and I find that I cannot retain any information from pages of syntax descriptions. Neither of us are wrong, we're just both different when it comes to learning.
- logicallee 11y ago
  I didn't read through that book, I've never tried learning Rust so that's why I googled Rust tutorial so I would have an unbiased opinion on the first thing I found. You've just LITERALLY made my point for me by quoting instructions that sound like they expect to spend 20 hours on this thing right now, including referencing two other tutorials. Imagine if the first time you used a hammer it came with a reference to three different books you should read about it. That would be stupid - nobody would use a hammer then. They should replace their expectation of 20 hours with 20 well-chosen lines anyone can use to start. If the language doesn't do that because it's too high-context, change the language so it's easier. Baby steps in Rust, or any other language, shouldn't take any number of days.
  - muraiki 11y ago
    You can use a saw to cut a stick in half, but you can also use it to create joinery. Learning something as complex as joinery -- and doing it well -- is necessarily going to take some time... even though you could probably teach an ape to use a saw. Different learning resources have different goals. This is a book that is meant to be comprehensive, but also provides two different ways to approach learning the language. The target audience of this book was never intended to be someone who only wants to devote 20 lines of effort to learning a programming language. If that's what you want, read http://learnxinyminutes.com/docs/rust/ http://learnxinyminutes.com/docs/rust/ Edit: But when you realize you can't grok language semantics like borrow checking or sum types for results, you might have to spend more than 20 lines of code to understand the usage and benefits of those concepts. This is when you move from sawing to joinery.

maxerickson 11y ago

1, tool writers assume we have like infinite time to follow 27-point directions that could be 100% automated. And tutorial writers assume we have infinite time to read all about the history of the world. An alternative explanation is that their audience is wider than your stated 99%. Somewhat ironically, if you scroll down ~20 lines on the Rust book page you linked there is the deep water you are demanding.

logicallee 11y ago
I don't think, for example, "semicolons terminate statements; blocks in curly braces; module import is use module::submodule::symbol; comment with // or /* */ which can nest." is deep water. The tutorial has to make a decision: does its audience know what a loop is, or how to even think about an algorithm that would use it? If the audience doesn't, then it's not a Rust programming language book, it's a Beginning Programming with Rust book. If the audience does, then they just need to be told the syntax. Even when they ostensibly do that, "The main concept that makes Rust unique is called ‘ownership’. Consider this small example:" could be better-stated as a difference between Rust and (list the languages that don't have it.) Tutorial authors and tool authors also waste INCREDIBLE amounts of time through dishonesty. For example, Functional Programming like Haskell is largely defined by the hoops you have to jump through syntactically and in program structure due to what it avoids. But a Haskell tutorial will NEVER make it obvious within the first two minutes that you are doing something fundamental different from C, Java, Python, C#, Perl, whatever - and that it has a whole concept, monads, just to get around this artificially imposed self-limitation. They're just dishonest, waste incredible gobs of time, and don't get to the point. When was the last time you picked up a language book that made it completely obvious in the first minute what it was and wasn't suited for, how many hours you would need to practice it before you made progress, and what the absolute bare minimum number of minutes you would need to invest before you could start doing anything in it was? It's a guessing game. "Wow, this only took me two minutes!" (json). "Wow this took me two weeks and I still can't do shit!" (haskell) I Googled "I tried learning haskell for" to report on what I found. There happens to be one hit on that exact syntax. Guess how long the guy "tried" learning haskell for? A few months.
- maxerickson 11y ago
  This gets back to the thing where the author (probably necessarily) has to write for a wide audience. Someone who enjoyed math in various school classes will probably understand the basics of functional programming faster than someone who only worked their way through it. So one of them might be just as angry as you are at the bad advice in the front matter of the book.

muraiki 11y ago

From the Rust book intro: "After reading this introduction, you’ll want to dive into either ‘Learn Rust’ or ‘Syntax and Semantics’, depending on your preference: ‘Learn Rust’ if you want to dive in with a project, or ‘Syntax and Semantics’ if you prefer to start small, and learn a single concept thoroughly before moving onto the next. Copious cross-linking connects these parts together." It sounds like you should have started at "Syntax and Semantics". For me, I really enjoyed starting in "Learn Rust" because I'm more of a "learn by doing" kind of person, and I find that I cannot retain any information from pages of syntax descriptions. Neither of us are wrong, we're just both different when it comes to learning.

logicallee 11y ago
I didn't read through that book, I've never tried learning Rust so that's why I googled Rust tutorial so I would have an unbiased opinion on the first thing I found. You've just LITERALLY made my point for me by quoting instructions that sound like they expect to spend 20 hours on this thing right now, including referencing two other tutorials. Imagine if the first time you used a hammer it came with a reference to three different books you should read about it. That would be stupid - nobody would use a hammer then. They should replace their expectation of 20 hours with 20 well-chosen lines anyone can use to start. If the language doesn't do that because it's too high-context, change the language so it's easier. Baby steps in Rust, or any other language, shouldn't take any number of days.
- muraiki 11y ago
  You can use a saw to cut a stick in half, but you can also use it to create joinery. Learning something as complex as joinery -- and doing it well -- is necessarily going to take some time... even though you could probably teach an ape to use a saw. Different learning resources have different goals. This is a book that is meant to be comprehensive, but also provides two different ways to approach learning the language. The target audience of this book was never intended to be someone who only wants to devote 20 lines of effort to learning a programming language. If that's what you want, read http://learnxinyminutes.com/docs/rust/ http://learnxinyminutes.com/docs/rust/ Edit: But when you realize you can't grok language semantics like borrow checking or sum types for results, you might have to spend more than 20 lines of code to understand the usage and benefits of those concepts. This is when you move from sawing to joinery.