Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A slightly related rule that I've been trying[1] to follow: Only vary one piece at the time.

- Learning a new language? Pick a problem you know very well.

- Solving a new problem? Pick a language you know very well.

- Trying a new front-end framework? Pick a backend you know very well.

And so on…

[1]: I say "trying" because it's so easy to try all the cool new things at once.



The last time Peter Norvig’s Sudoku solver came up there was a discussion about how some people use the same design to try out new programming languages. I need to get on that.

On the flip side of this, I always end up wearing the performance hat on every project I’m on, and one thing I keep meaning to do is to write myself a benchmark/test suite that asserts some things I “know” about the behavior of the language. Why? So that I can run it again on every release to make sure that the slow but pretty solution didn’t suddenly get 10x faster or the fast but ugly one didn’t get 2x slower to fix a security hole, narrowing or flipping the heuristic for selecting the correct solution. Speaking of, I really miss jsperf even though half the benchmarks there were misleading.


I fairly often do something like this. I have a simple CLI project that I write that hits a few web APIs and reads a file. It's fairly simple, but these are the kind of basic things I want to know in each language.

I then benchmark it and go and try to make it as idiomatic according to that languages style.


The opposite perspective also has some value. e.g. If you try to learn a new language and solve a new problem, then when you get stuck on one you can make headway on the other, then return. It is harder to juggle effectively though.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: