For all those hating on this blog post: It's short, but it doesn't have to be long to be useful, and apparently it is useful given a substantial chunk of the comments here. If it wasn't news to you then ignore it, otherwise appreciate that not everybody is quite as enlightened as you are.
HN has a tremendous reach these days, from pioneers in the field to total (and often clueless) newbies. Fogus felt compelled to write down his thoughts, someone else saw fit to post it and as of this moment 100+ people thought it was useful enough to vote it up. If that's not validation enough for you then remember that time when you spent half a day tracking down an endless loop and you had to ask a more seasoned programmer to point it out to you.
Fogus is a respected member of the community because he tends to write down what he thinks in a way that others much further down on the totem pole can grasp it too, his articles are not upvoted because he's 'well known' but mostly because people find them useful.
If you feel like this article was 'devoid of content' or whatever slur you feel like directing at it then please, write a better one.
Content is not determined by the quantity of words on a page.
Some of the deeper links between linguistics and programming can be quite eye opening and it does not require a large number of words to put those down. If you find one of these, especially through your own work (as in 'from the trenches') then that should carry some weight with you.
If you're doing this independently and re-discovering something that apparently a lot of people such as you have already found out or learned about elsewhere then indeed it is devoid of content. But I'll bet that it wasn't the case for the majority of those that read it.
Lots of programming wisdom is so terse that we have acronyms for it (DRY for instance), that does not mean there is no content there.
Anyway, enough said, I think it is worth reading, and worth 'grokking' for want of a better word, in case you had not already discovered this. Naming stuff is one of the harder things in programming, that different streams of programming should lead to different groups of words being used to describe the code should probably come as no surprise and yet I find myself amazed that there are such deep connections.
For me, the big confusion comes from the fact that if you simulate people, you almost inevitably have to deal with data about people. How can those two be mutually exclusive?
Without a clear definition or concrete examples of what the OP meant by "simulate people" versus "data about people", the post is almost devoid of information (to me; apparently, a lot of people understood what OP meant).
For me, the big confusion comes from the fact that if you simulate people, you almost inevitably have to deal with data about people. How can those two be mutually exclusive?
They're not mutually exclusive: the inverse is not necessarily true. This is basically the entire point of the article. When you're just working with data, don't use constructs which are meant for simulation. It's a subtle way of saying "Don't model data about people (or any other piece of pure information) with mutable objects; prefer values instead."
HN has a tremendous reach these days, from pioneers in the field to total (and often clueless) newbies. Fogus felt compelled to write down his thoughts, someone else saw fit to post it and as of this moment 100+ people thought it was useful enough to vote it up. If that's not validation enough for you then remember that time when you spent half a day tracking down an endless loop and you had to ask a more seasoned programmer to point it out to you.
Fogus is a respected member of the community because he tends to write down what he thinks in a way that others much further down on the totem pole can grasp it too, his articles are not upvoted because he's 'well known' but mostly because people find them useful.
If you feel like this article was 'devoid of content' or whatever slur you feel like directing at it then please, write a better one.