Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Teach Yourself Programming in Ten Years (1998)

norvig.com

Post reply on HN
Print view View original

301–310 of 323 posts

Re: Teach Yourself Programming in Ten Years (1998)

#301

Post by diarrhea »

zozbot234 wrote: post #289
josephg wrote: post #274

Earlier quoted context omitted.

Golang yes, but not rust. I think rust is a terrible beginner language. Despite having decades of experience it took me about a month to feel productive in rust and stop “fighting the borrow checker”. I learned Go in about 12 hours. Let beginners cut their teeth on stuff like Python and Go. Rust can wait.

Yes but that's the thing, if you pass everything by value or read-only reference you don't have to deal with the borrow checker, and that's quite acceptable when you're first writing code. That's why I think Rust is almost a FP language in disguise with imperative features added after-the-fact - and it could be taught as such.

You’re not wrong, but precluding tons of concepts not suitable for beginners. “Just .copy() everything” shouldn’t need to be mentioned in an introductory book.

Re: Teach Yourself Programming in Ten Years (1998)

#302

Post by fuzztester »

stouset wrote: post #175
miiiiiike wrote: post #155

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

I got started buying Borland C++ Builder in… 1997, I think, and read the book that came with it which was similarly named. It was quite bad, I remember the chapter on pointers more or less said “I can’t explain why you’d want to use them, but when you find a situation that requires them you’ll know you need them” or something like that.

>read the book that came with it which was similarly named

Jeff Duntemann? or was he the Pascal books guy?

Maybe Robert Lafore.

Re: Teach Yourself Programming in Ten Years (1998)

#303

Post by josephg »

diarrhea wrote: post #301
zozbot234 wrote: post #289

Earlier quoted context omitted.

Yes but that's the thing, if you pass everything by value or read-only reference you don't have to deal with the borrow checker, and that's quite acceptable when you're first writing code. That's why I think Rust is almost a FP language in disguise with imperative features added after-the-fact - and it could be taught as such.

You’re not wrong, but precluding tons of concepts not suitable for beginners. “Just .copy() everything” shouldn’t need to be mentioned in an introductory book.

Yep; and cloning boxed objects everywhere often leads to slower rust code than the equivalent javascript or Go. And if you only teach a subset of rust without references, people can't read code snippets online, or most of the standard library documentation.

In comparison, Python, Go, Javascript and C# are all much easier to teach and leave students more able to make real software.

Re: Teach Yourself Programming in Ten Years (1998)

#304

Post by bmitc »

mtrower wrote: post #248
bmitc wrote: post #120

Earlier quoted context omitted.

I feel most of my time as a professional software engineer has been learning stuff that I didn't need to. And I would argue that the majority of debugging time goes into debugging external code from libraries, the language itself, company-provided platforms, code, libraries, DLLs, experimentally figuring out how to use a system or tool that isn't documented, and more. It's pretty miserable. It'd be like being a carpe…

At least in woodworking, tool setup and maintenance is a significant portion of the craft.

That's true, but the tools work for their given purpose. If only software tools required basic setup and maintenance.

Re: Teach Yourself Programming in Ten Years (1998)

#305

Post by mmcdermott »

bitwize wrote: post #72
freedmand wrote: post #45

Earlier quoted context omitted.

I wonder how people’s learning habits will change with AI tools like GitHub Copilot. I used it for several months but randomly got logged out and am now finding myself valuing the slight inconvenience of looking up official documentation (and surprised how much more sluggish I felt for the first week). Going through extra steps to learn something through primary sources and valuing being uncomfortable at times are im…

I don't even use autocomplete. I know that autocomplete is, like, table stakes for the developer experience these days, but I just can't stand videogame shit happening in my field of vision whilst I'm coding, and I've learned to relish the extra effort of typing the whole name in every time, it's like a vocabulary word I can wield with power and precision, rather than relying on the machine to finish my thoughts for…

> it's like a vocabulary word I can wield with power and precision, rather than relying on the machine to finish my thoughts for me.

I like that point of view and generally code for fun that way. My biggest use for autocompletion is when working with unfamiliar Java APIs on a tight timeline.

Re: Teach Yourself Programming in Ten Years (1998)

#306

Post by fl0ki »

josephg wrote: post #274
zozbot234 wrote: post #191

Earlier quoted context omitted.

I wonder who's going to write the "Teach yourself Rust from scratch in 21 days" book. If C and even C++ can be learnt effectively as a first programming language, there's little reason why Rust couldn't be. And if not Rust, maybe Golang could play that role.

Golang yes, but not rust. I think rust is a terrible beginner language. Despite having decades of experience it took me about a month to feel productive in rust and stop “fighting the borrow checker”. I learned Go in about 12 hours. Let beginners cut their teeth on stuff like Python and Go. Rust can wait.

I completely agree but do feel it needs qualifying. The problems beginners run into aren't usually the same as the problems experienced devs run into when adopting a language new to them, but where I see the two overlap I know something is a serious hazard in a language.

Java as a first language: won't like the boilerplate but won't have any point of comparison anyway, will get a few NPEs, might use threads and get data races but won't experience memory unsafety.

Go as a first language: much less boilerplate, but will still get nil panics, will be encouraged to use goroutines because every tutorial shows off how "easy" they are, will get data races with full blown memory unsafety immediately.

Rust as a first language: `None` // no examples found

I think Go as a beginner language would be better if people were discouraged from using goroutines instead of actively encouraged (the myth of "CSP solves everything"), otherwise I think it needs much better tooling to save people from walking off a cliff with their goroutines. And no, -race clearly isn't it, especially not for a beginner.

And in one respect I've found Go more of a hazard for experienced devs than beginners: the function signature of append() gives you the intuition of a functional programming append that never modifies the original slice. This has literally resulted in CVEs[1] even by experienced devs, especially combined with goroutines. Beginners won't have an intuition for this and will hopefully check the documentation instead of assuming.

[1] https://github.com/grafana/grafana/security/advisories/GHSA-...

Re: Teach Yourself Programming in Ten Years (1998)

#307

Post by fl0ki »

zozbot234 wrote: post #289
josephg wrote: post #274

Earlier quoted context omitted.

Golang yes, but not rust. I think rust is a terrible beginner language. Despite having decades of experience it took me about a month to feel productive in rust and stop “fighting the borrow checker”. I learned Go in about 12 hours. Let beginners cut their teeth on stuff like Python and Go. Rust can wait.

Yes but that's the thing, if you pass everything by value or read-only reference you don't have to deal with the borrow checker, and that's quite acceptable when you're first writing code. That's why I think Rust is almost a FP language in disguise with imperative features added after-the-fact - and it could be taught as such.

This only gets you so far. In today's software landscape, somebody is going to want to hit a HTTP JSON API to automate something in their second week, and they'll have a really rough time with how async Rust works today. Try explaining to a total beginner why they need Arc> and why the payload struct needs to be :Send+Sync+'static.

For all of Go's faults, "just send it over a channel bro" is easy to explain for trivial cases even if it often risks deadlocks and data races. To avoid the worst risks of this kind of code, Rust makes even trivial cases a big exercise. Go has an opportunity here to become more resistant to bugs without becoming less simple, but resistance to bugs doesn't appear to be a priority even for the Go team itself (e.g. even recently https://github.com/golang/go/issues/64474 )

Re: Teach Yourself Programming in Ten Years (1998)

#308

Post by monkeynotes »

throwawaaarrgh wrote: post #41
monkeynotes wrote: post #37

Earlier quoted context omitted.

> At 8 hours a day, 40 hours a week - 10,000 hours of practice will take 250 full weeks to achieve. That’s about 5 years of nearly non-stop programming. Isn't this basically a software job? Like, get a junior role and work your way up over 5 years doing 40 hrs a week.

If the only programming you do is generic commercial work, you won't get very good, especially if it's at the same job or on the same kind of project. You can learn more about programming by giving yourself new and challenging projects at home. Doing both personal and professional work is the fastest way to progress while learning lessons from both. (commercial work teaches you the "professional" side of software eng…

> If the only programming you do is generic commercial work

Congrats you've found an edge case.

I've spent my whole life working in "commercial" settings, I've learned everything doing that, and it's all programming. I really don't know which places you work at where a software engineer doesn't do programming. That's the whole job, 8hrs a day.

Fuck going home and slugging another 4hrs software, unless you have the energy in which case good for you, you can fast track.

Re: Teach Yourself Programming in Ten Years (1998)

#309

Post by zubairq »

miiiiiike wrote: post #155

I bought a copy of "Sams Teach Yourself C++ in 24 Hours" at a CompUSA in 1999. The guy at the checkout looked at it, laughed, and told me about this article. When I was 16 I was looking at programming books at Borders and a guy handed me a copy of "The C Programming Language"; changed my life. So much of my career has been shaped by running into developers or just people interested in programming out in the world. Th…

I remember reading a "Teach Yourself C++ in 24 Hours / 21 days" type book on a bus trip in the 1990s and learning C++ that way! It was a great start!

Re: Teach Yourself Programming in Ten Years (1998)

#310

Post by arendtio »

I like the timing 'Answers' very much.

And then again you ask the run-of-the-mill SAP consultant how long it takes until an updated data record is available to a connected system and the answer will be something like 86.400.000.000.000ns

or closer to the original wording: 'one day'.

Post reply on HN