Comment by axegon_ | Hacker News Reader

Comment by axegon_ | Hacker News Reader

Though those are good points, there are a few things to mention: once you know a few programming languages, jumping into a new one becomes relatively easy. That said, there are a few traps here and there(something I've also noticed when studying a foreign languages after knowing 2 others): "Oh that's the same as in {{X}}". And you pay no real attention to it as a result. A few days later you end up going to check what "{{X}}" was.

My methodology as far as programming languages go, is the following:

1. Learn the nature of the language by understanding it's internals - is it dynamically typed, statically typed, functional, object oriented, single threaded, multi threaded etc.

2. If it's a compiled language, learn the hello-world and then spend some time to figure out how the compiler works.

3. Ecosystem - packaging, distribution, community, etc.

4. No IDE's, plain and simple vim. Getting off the line becomes a lot harder but it teaches you the fundamentals from the start without relying on anything fancy: Get your hands dirty.

5. While you are studying it, think of a small project to work on along the way in that language and try to push your current knowledge over the edge of what you've learned. After you learn a new concept, go over the entire project and see where it can be applied and what would be the benefits/drawbacks. Even if that means re-writing 90% of the project.

Rosetta Code https://rosettacode.org is especially helpful when you know exactly how to do a thing on language X and Y, but don't know about Z.

Definitely. I consider myself somewhat of a PL polyglot. After you've gotten experience in the different semantic paradigms (functional, OOP, imperative, etc), I think it's relatively simple to pick up a new language. It's mostly just a matter of learning some surface syntax and the standard library functions ('how do I concat two lists?', etc).

The hard part is when you encounter a language that has complicated semantics.

I actually think #5 is the most important and shouldn't be discounted. I like three month projects - something moderate hard that might or might not get shipped. A summer of evenings sort of thing is usually enough to get a good grasp for me.

While this approach seems to work for a lot of people, personally I'm in the crowd that has a really hard time with that.

I'm just not a creative person. I consider myself a good developer when it comes to diving into an existing code base and figuring it out, fixing things and adding new features. But I simple cannot come up with stuff on my own. I've been trying ever since I was a kid and started programming, and now it's been 20+ years of drawing blanks when I try to "think of a project."

Hopefully I'm not alone in this :P

There's no need to be creative about it. I never try to (re-)invent the wheel myself. Once I'm done with #1 on the list I posted, I evaluate the strengths and weaknesses of the language and pick something that probably already exists. Say for the case of Rust when I was learning it ~3 years ago, that was a private dropbox-like service which syncs files I listed in a config file to a GCP filestore bucket. Nothing fancy or complicated but still - doing checksums, syncing, error reporting, all the usual stuff. Eventually further extended it to encrypt personal documents before pushing them and so on. Doesn't have to be big or complicated or something that no one has done before. Matter of fact, doing something that already exists is the better option cause you can transfer concepts.

Reply on news.ycombinator.com