T-R

You probably got downvoted for being off-topic - it'd be better to ask that kind of question on Stack Overflow. Leave out the subjective "is it because I'm a noob?" parts, and stick with the more objective "is there a better way to do this?", and you'll probably be able to figure out from that where any holes in your knowledge/experience might be.

I'd take it a step further, as well - as wide as the friend's friends net may be, I'm still probably not learning anything new. If my group of friends is defined mostly by some common interest, and theirs is too, I'm probably not going to get a good answer to anything outside of that field of interest.

To take the example on the page of restaurants - I'm probably not going to learn about any new restaurants if my friends and I mostly go to the same restaurants, and they go to the same ones with their friends, too.

He's definitely hurting both himself and the people he works with, both from the fact that he's not likely to work to improve himself, and from his depression/frustration and the fact that it's manifesting as resentment towards his coworkers. I don't mean to attack him, it's just that in collaborative work that requires skill (read: practice), a bad team member can be worse than having one too few. If it really is what he's best at, then he really needs to start practicing something he actually does enjoy, or find some way to enjoy it enough to practice.

Concurrency = managing shared resources. Things like mutual exclusion and transactions. Getting processors to get in line (serialization/composition) for a shared resource instead of just trampling over each other by just grabbing it when they want (non-determinism), so that actions that depend on being done in order and without interruption can be done.

Parallelism = splitting up subtasks that don't depend on each other. If the tasks don't depend on each other, the things doing them shouldn't need to talk. If you have enough processors, you can do almost everything at once, so the algorithm is only as slow as things that actually need to be done in order (asymptotic efficiency).

In imperative programming, we tell the computer what order to do things in, so it doesn't know what actions don't depend on each other - to parallelize, we have to worry about concurrency. In functional programming, the compiler knows what depends on what (what uses the result of something else), so it can parallelize things that don't depend on each other. It might be implemented with concurrency, but the programmer doesn't need to worry about it.

I've definitely spent a good while in the past trying to decipher the intent of someone who used &&alwaysFalseExpression - Is it a bug? Am I overlooking some subtle side-effect somewhere? If they just wanted to turn the code off, they would have just commented it out...right?

Maybe true, but still not much consolation for the embedded systems programmers or maintainers of legacy code.

I probably shouldn't have left it at that - if there's much regularity outside of tables, then you're definitely doing something wrong. Within code I see the alignment as a way of highlighting regular areas as potential spots for refactoring. Sometimes it doesn't make sense to turn something into another layer of abstraction yet, but it may later. I can certainly see how the extra spacing might grate on some people's nerve's, though.

Edit: Something I hadn't thought of - you mention "rivers of space" - aligning code might make it harder to read for coders with dyslexia: http://uxmovement.com/content/6-surprising-bad-practices-tha...

Regarding your point about unsigned types - If I'm remembering correctly, "Writing Solid Code" had a section about exactly that - nasty bugs caused by things like looping over unsigned integers in reverse.

I have a lot of respect for him, but it's pretty disappointing to see him so opposed to doing things that would bring more clarity to those trying to understand his work. This is at least the third quote I've seen of him blowing off the idea of giving examples or more documentation. It's further disappointing to see "that document is my dissertation" juxtaposed with "I sometimes need to expand on the terse explanations provided in the dissertation, because I was in a hurry when I wrote it".

One (additional?) constraint that perhaps doesn't fall nicely into one of those categories is "Hypermedia as the Engine of Application State" (HATEOAS), which was emphasized (though not with those exact words) by Roy Fielding on his blog:

http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

> Align everything you can in code

Yes. Makes code easier to read and makes it easier to refactor if you use an editor with column select/multi-line caret.

Also discussed here: http://news.ycombinator.com/item?id=2335555

I didn't get the impression that the article was implying that DNA damage and other stochastic effects are prevented, but that maybe the initial effects of radiation poisoning are avoided, and that (maybe because of this) cells are more able to repair themselves.

That said, I can't disagree with your last point - it's probably at least a little embellished.

Tsunami warning for California: http://forecast.weather.gov/wwamap/wwatxtget.php?cwa=usa&...

Is the cell network still down/overloaded?

The kindle edition isn't too bad, either, though you have to read it in Landscape mode to minimize the number of odd line-breaks in the code.

It definitely gets a little tough around the Parser example, but it does lighten up again once you get through the monad transformer section, though.

For someone who's done some functional programming before, Real World Haskell is probably a good starting point; otherwise something like YAHT would probably be better.

I've gotten the impression that there are, in a sense - in python, list comprehensions are usually preferred over for-loops in places where you would use map and filter, and the most common use cases for fold/reduce are covered by functions like sum and join. List Comprehensions also tend to be preferred over higher order functions, perhaps for readability, but also, in python 3, the higher order functions return generators, which don't always play nicely with mutable data.

For-loops are still suitable for actions (which mutate state or for some other reason need to be evaluated in order) - you see this in Haskell, too, though, with Control.Monad's forM_ and the like.

tptacek has made some good comments on this: http://news.ycombinator.com/item?id=2010226 http://news.ycombinator.com/item?id=1946307

In short, Customs covers counterfeit, which extends to IP rights. Not saying I agree with it, but that seems to be the justification.

I'd argue it's still true, but to a lesser degree. In addition to 1seg, I think FeliCa's a big one.

http://en.wikipedia.org/wiki/FeliCa

My impression has been exactly the opposite - aside from full-internet on smartphones (not to say it isn't a big deal), new features in the US lag by something like 5 to 10 years. QR code reading and easy contact transfer(like 赤外線) still aren't out-of-the-box features (hacked in by third party software like Bump), and most Americans don't know what a QR code is. We still can't pay for things at the grocery store or buy train tickets with a cell phone, whereas Japan has had FeliCa Mobile for 7 years now. Live TV on a cell phone is also non-existent in the US. In Japan, these are all so common that they're available on the free-with-plan phones.

Also, according to the Japanese Wikipedia article, the first camera phone was DDI(Wilcom)'s VP-210 in 1999, and they exploded in popularity with Sharp's J-SH04 on J-Phone(Softbank) in 2000.[1] The US, by contrast, got their first camera phone in 2002.

[1] http://ja.wikipedia.org/wiki/カメラ付き携帯電話

They're gaining a little popularity, but most phones are still flip phones. The main reasons I've seen are that the pre-paid and free-with-plan ones are flip phones, and mobile internet is more popular, so a full built-in web browser doesn't give much advantage. Smart phones also usually don't have infra-red contact-info transfer, which frustrates a lot of people, though I don't really think it's hurt sales. They're also usually only in black and white, and lack a good place to put cell phone charms or purikura stickers, which probably kills some of their appeal.

Edit: Also, lack of Live TV is a big one for businessmen who are sports fans. Lack of a FeliCa reader might be an issue for some people, but probably not a deal breaker, since most people probably also have SuiCa, PasMo, IcoCa, or Edy cards.

I think his points are valid, but I think you're right, the cultural aspect is huge, as is the marketing, for that matter.

They successfully marketed cameras, infra-red transfer, mobile internet, and QR code scanners to high school and college girls (the most profitable demographic in Japan to sell to). Without that, the other issues likely wouldn't have mattered.

Tragically locked - I'd add "Real World Haskell" to the list. Completely changed the way I write code, in a way that books that more directly advocate readability and testability failed to.

I feel like I might enjoy a shared or open office, but my only experience with it involved trying to concentrate on coding while listening to the CEO reduce the new hire to tears on a more-than-weekly basis.

> ...solving “How do you tell if a number is even or odd” with clumsy solutions such as (x % 2). They don’t [...] come to the conclusion that (most) computers are digital machines, all you have to do is check the first bit (x & 1).

Not to be nitpicky, since your overall point still stands, but I'd argue that it's better to use a mathematical abstraction (modulo) than an optimization that's dependent on the way the data is stored (bitwise operations), particularly when the compiler will probably optimize it away anyway.

I have a little trouble conceiving of a completely classless society - at some point you have to acknowledge that, for example, some programmers are better than others, and that that's a positive thing. That acknowledgement alone creates a class. The important thing is upward mobility - we shouldn't define "better" as "knows the other people who are 'better'".

> And I also don't propose that this was all cooked in a room full of cackling conspirators rubbing their hands together. It's just the way a power structure works.

His point is that the system of individuals acting to maximize their own benefit, because of the way that "benefit" is defined, favors entrenched players, even if it wasn't supposed to - no conspiracy necessary.

I don't think he means to focus so much on the historical anecdote about Ivy Leagues. His point is that the existing power structure (whether it's business, gov't, or education) is based on networking, not merit, and that by inviting some people who have merit to network, it only creates the illusion of meritocracy, because success is still founded on networking - which benefits the existing aristocracy, even if the intention was to move toward meritocracy.

There's a lot of duplication (Colors, Tools>Color Tools; Brush in Toolbox & as Dockable window), things that are out of place (View>Show Grid, Image>Configure Grid), common workflows that require more clicks than in other editors (Select-Copy-DeSelect-Paste), odd choice of defaults (When resizing canvas, choose "resize all layers" instead of "None"), and other odd design choices (Toolbox can't be a dockable window, Toolbox needs scrollbar if vertical Resolution<1024) that make GIMP occasionally frustrating to use, despite being an otherwise awesome tool.

I'd like to see this paired with an e-ink screen on the next Kindle. Turn on only the e-ink for reading, only the LCD for UI, or both to show highlighting and notes overlaid onto the text. They could use the touch screen to get rid of all those buttons, too.