HN user

muchabi

3 karma
Posts0
Comments6
View on HN
No posts found.

The other answers sound like they're from people who aren't new to the idea of pointers...

Try simple data structures first. Having linked list nodes that actually uses minimal memory (pointer to next node, a data field) is actually pretty exciting. Implement all the operations (get index i, remove index i, etc) because that's where a lot of the insight will come from. Then you can move onto binary search trees and other more complex stuff.

One of the most useful insights I've read was from "Effective C++", which said (paraphrasing) "C++ is a federation / family of languages which work together". Learn the C subset of it first so you're not overwhelmed with available features, and then you can get back to using templates / STL / the other languages later.

Also curious here. I too find Ruby more consistent/predictable than Python.

Ruby is my main/favorite language, but I was exposed to Python first and used it a lot more for work/school, so it's not an experience thing here.

I read it as "given a choice between A and B, I'll choose A". So...

When choices are available for a software library, pick an open-source one over a well-tested black box, and perhaps even contribute. If the black box is the only reasonable thing out there, then use it.

Rather than try to hire by a strict ordering of skill, create an environment with varied viewpoints that can all be heard. (Of course you still hire among the top candidates, and avoid bad coders)

When choosing between two jobs, one of which creates a new product that people love, and the other cuts into someone else's profits through algorithmic/technological superiority, pick the first one. If you don't have such a choice, it's not relevant.

Last one I'm not sure about, but one possibility is "go learn Haskell/Lisp or experiment with the latest algorithms/libraries in the evening rather than work 18 hour days for your job." If you really have to get something done for work, by all means do it.

It's not "always do this", but rather "when you do have the freedom to choose, pick this"

To add another example to the list, Ruby lets you list which attributes can be read/written and which ones can only be read on top. Something like.

  class Car
      attr_reader :model, :company # only read
      attr_accessor :color # read and write
  end