It's not so much that HTTP itself is RESTful. It's more that using HTTP's existing functionality instead of reinventing your own is RESTful. REST is a set of design principles for building software on top of HTTP.
The only thing I'd do differently here is put the comments and author links as <link rel/> tags as well. No reason not to standardize the representation of links. Optionally you could list inline the entire contents of the sub-resources. Doc types should allow composition in this way and it allows you as a designer to reduce unnecessary traffic and latency.
This article doesn't really clarify things for me. I agree that not many APIs in the wild right now are truly RESTful, but this has been stated for years. We know this. The article then posits that true REST is too hard. This is simply not true when you look at the bigger picture. Yes, it may be easier in the moment to cowboy it up and reinvent the wheel, but when it comes to maintaining your service and integrating it with others, you pay the price for lack of foresight.
The questions that need to be answered are how would true REST be different, and why would I want to spend my precious time learning about it and implementing it?
I appreciate the author's enthusiasm towards REST, but I would prefer to discuss the technical merits rather than engage in justification and categorization of what's out there right now. Yeah, it's not REST, and yeah people are going to call it REST anyway in certain contexts. But in the context of architectural design we have clear definitions about what REST is, and there's no need to muddy the waters.
I've taken small example programs written in C# and pasted them into a java environment, changed the library references and I'm good to go. But doing that with 100k lines of code is quite another level. Still, I think the syntax and design similarities between C# and Java present a unique opportunity for this sort of thing... It would probably be prohibitively difficult to do with almost any other pair of languages.
The statement was that Mono is crippled. Last I checked, Mono was lagging at least one major release behind Microsoft's CLR. So if you're using fancy new features, you'll probably have to refactor to gain cross platform support, and even then you may encounter bugs and memory leaks.
This seems like a bastardization of FP. I've been studying Clojure for the last few months and I'm amazed at the elegance of Lisp syntax. Maybe the perens have corrupted my brain, but F# just looks really ugly to me. It looks like Microsoft is trying to spoon feed it to C# developers, which is ok I suppose, but I don't think that people are really going to grasp the underlying concepts of FP without letting go of a lot of what they've learned in the imperative world. A familiar syntax can actually be an impediment in this effort, as it creates the impression that two expressions are equivalent when they really aren't.
What you say about the experiment results is true. I don't know if this one is any better, but the guy who gave this TED talk found similar results when looking for communities having people with the longest life spans:
One of the places with a lot of centenarians was a place near Okinawa, Japan, where people form life long friendships. They also eat healthy and I'm sure other variables are different. I find the correlations interesting even if they are not conclusive.
Maybe focus on what you're doing instead of what you've done. Be nice to people and find ways to help them out with their problems. Instead of listing out your credentials express your willingness to help.
This seems to be the approach that Richard Feynman took. He says in the BBC series "The Pleasure of Finding Things Out" that he hates the concept of awards, and he did things for the pleasure of doing it and having it used by others, not to earn some sort of recognition.