Nobody Understands REST or HTTP - <AUTHOR> http://blog.steveklabnik.com/2011/07/03/nobody-understands-rest-or-http.html <comment><USER2> The biggest problem with today's REST implementations is that they're essentially a database serialization layer. Consider how a RESTful Rails model is typically represented as:

      {
         book: {
            id:1,
            name:"To Kill a Mocking Bird",
            author_id:2
         }
      }

How do you get more info on the author if you only have this piece of information? Rails/ActiveResource guesses through convention: "/authors/2", but that might not be the case, which makes this approach very brittle.

A better more "RESTful" approach might be:

      {
         book: {
            href:"/books/1",
            name:"To Kill a Mocking Bird",
            author: {
               href:"/authors/2"
            }
         }
      }

The REST client would then be able to traverse the representation without making guesses at the URL, and if the end-point of '/authors:id' changes for whatever reason, the href would be updated accordingly.

Pagination/large data-sets could be solved as well:

      {
         books: [
            href:"/books/1",
            name:"To Kill a Mocking Bird",
            author: {
               href:"/authors/2"
            }
         }
        ],
        rel: {
           prev: "/books?page=1",
           next:"/books?page=3"
        }
      }

... and a bajillion other common RESTful API problems through better convention.

I'd agree with the author that REST is misunderstood, but my opinion is that its misunderstood on the grounds that today's "REST" implementations are lame database serializations. The web has been doing this since the <a href/> tag was conceived, but for some reason, modern REST implementations left this out.

<comment><USER3> Pagination is implicitly non-restful as page=X can change anytime a new book is added, depending on the ordering getting done.

<comment><USER2> That's like saying that a resource is implicitly non-restful because its state might change.

If a book is added, the page=x resource is simply outdated and should be refreshed.

<comment><USER4> If you need page stability you can refer to the items at the top of the page not the page numbers, the nice thing about rest is they are still just next and prev links.

</comment></comment></comment></comment><comment><USER5> I thought I finally had REST figured out until I read this.

Does anyone else see a diminishing return on pedantically following the REST- prescribed design and actually creating an API that people are _familiar_ with out of the gate? I feel like if I followed this article to the T in my current design, anyone trying to integrate with it would spend so much time reading my API documentation just to figure out why they weren't getting an XML reply that it would stop being productive.

I am working on an API for imgscalr right now and I think I have it about 80% RESTful at the moment -- the parts I'm not doing is paying any attention to the headers either coming or going between client or server.

I'm using the more recent "classic" /path/object.{format}?arguments format that I have seen folks like Wordnik and Vimeo use.

It may not be purely RESTful, but it is intuitive and I can't help but think: "Remember 3-4 years ago when REST wasn't all the craze and no one knew what it was? The web still managed to function back then..."

I'm trying to mix some practicality in a bowl filled with "best practices" and come up with something that most people can stomach.

I hope I hit that mark, but we'll see. As far as I'm concerned I'm sticking with the versioned URLs because I find it more intuitive for endpoints that change, get renamed or are removed than slamming one inside of a mime type or header or even a query string param a la AWS.

<comment><USER6> using object.format is perfectly ok regarding the rest. using headers might be more pure, but its not the biggest issue.

the biggest issue with the rest-wanna-be interfaces is their use of object ids instead of object uris. so that I have to construct my own urls to access stuff.

in a proper restful api you are NEVER supposed to construct your own url. you are supposed to get all the relevant ones from the service.

and this kind of api is actually much more user friendly and allows for much better discovery. you just get the single top api url which has references for all the available collections objects and operations right there in the result.

<comment><USER5> Vitaly,

So something like:

      GET /image.json/pig.png?size=150x100

as opposed to

      GET /image.json?id=pig.png&size=150x100

where the arguments specific to the noun (or object/entity or image resource in this specific case) go in the query string, but the URL stem itself must be a valid resource reference?

</comment></comment></comment><comment><USER7> He's right, but older web developers might remember the alternative, which was having no design pattern at all.

Most web developers aren't going to read the computer science papers about REST, and how strictly you want to adhere to it, depends on you, and your development team. It's a design pattern, or a tool, but it's not a religion.

On that note, I've gone into several job interviews where they ask me to explain what REST is, and I always start with, "REST stands for Representational State Transfer...", at which point, I get the feeling that the interviewer wasn't aware of that, and I wind up telling them way more about REST than I think they wanted to know.

</comment><comment><USER8> I read the post and I have to say that he's got a nice flamebait title but totally avoided the thorny issues that people argue about. In fact, I'd like to be pointed to a solution for the following problems:

1\. I'm an old Web programmer, and my introduction to the Web started with HTML, not HTTP. I don't just write APIs, I write Web apps. I find it difficult to explain to people what this means:

        <form action="/some/noun" method="POST">

If you are religiously RESTful, you probably think this is fine. But I'm a religious English reader. When I see the word "action", I think of a verb, not a noun. When I see the word "method", I think of "how", not "what". So when I look at the HTTP spec, all the HTTP "verb"s look to me like how-I-should-do- something, instead of what-to-do, and the resources (URLs) look to me like the what-to-do, instead of what-they-represent.

Small semantics issues I suppose, but here's another one:

2\. HTTP is not a programming language, and yet it demands a (very) finite set of actions and an infinite set of objects to model the real world, where there are an infinite number of actions and objects. What I mean is, in Java or whatever OOP language, I can define classes to model objects and define methods in classes to model actions on objects, but I'm not sure if I can do it pragmatically in HTTP without getting yelled at.

3\. HTTP statuses. Almost the same problem as the above. I have many different kinds of statuses, not all of them fit in the finite set of HTTP statuses, and they don't always provide the granularity I want. Can I return a non-standard status number? How would the clients behave? I have no idea.

4\. Being RESTful means not being stateful. But you see, there's this thing called session and login cookies and many other tracking cookies that I have to take care of. Again, I don't just write APIs, I write Web apps. I would like to not do multiple handshake requests just because a paper says I should. I would also like to not get yelled at when I decide not to.

5\. HTTP is RESTful, thus HTTP is REST. Please don't tell me HTTP is the best we can do. Can I have something more minimalist, extensible and powerful enough to model the real world?

\-- A troubled Web dev.

<comment><USER9> 1) HTML isn't English, it just has some similar sounding tokens. You can't assume the semantics are the same.

2) Well, there's HTTP and there's REST, they're related but no the same. HTTP is a full protocol, completely defined; you can't add more verbs, period.

REST is an _architectural style_. It has a series of constraints, and it tells you that if your system architecture complies to them, it'll have some useful properties, like low coupling and such. HTTP is just an example of a RESTful architecture.

Now, if you're designing an architecture and you want to follow REST, you can choose the verbs you want, but these should be _generalist_ and not tied to specific names. This provides an Uniform Interface, which simplifies and decouples the the architecture.

3) See above. _HTTP_ statuses are fixed, you can't return other stuff. If you're designing your own architecture, you can use whatever you want. Hell, you can return different pictures of kitties for each status if you want to.

4) As the Zen of Python states, practicality beats purity. But you should be aware that by adding state to the connection, you'll lose some advantages. Let's say the user is performing a multiple step action, and the server he's using breaks. If the server was holding the state, now the user has lost all the work and he'll be pissed at you. If on the other hand, the state was saved by either the client, or more "RESTfully", by the mere fact that he was on a specific URL, than any other server can pick up where the other left without annoying the user.

5) Sure. We just need to rewrite all the browsers and servers worldwide, including a bunch of embedded ones that can't be reflashed. It's possible...

<comment><USER10> to #4 - that's only true if you designed your app to rely on a single server and have no fault tolerance or distributed sessions. Argh.

<comment><USER11> The original stateless way has fault and partition tolerance baked right in. By breaking this convention you open yourself to a world of hurt, no matter how many band aid concepts you patch over it.

If you had ever designed or worked on a distributed system that needed to scale you wouldn't talk about adding servers and sharing state (distributed anything).

Sure distributing state is a fail-safe strategy - but not a scalable or performant one.

</comment></comment></comment></comment><comment><USER12> Very good read, and thorough. I particularly like the transaction example. It seems like a common idiom that trips people up with REST.

However, I do have a problem with REST that I've been dealing with lately. Specifically, the question of web-hooks. Many services today allow you to pass a URL that they will hit with a POST request whenever something happens. A good example is the GitHub post-receive hook (<http://help.github.com/post- receive-hooks/>). So, to be a good student of REST, I create an /update resource for the POST (similar to the /transaction example from the article). However, /updates might come in a variety of formats. Not just JSON vs XML, but GitHub vs Gitorious vs Beanstalk vs etc.

So, how do I handle these "formats". Presumably the "Accept" header is out of the question (unless the provider happened to know about MIME's vendor extensions and used them). So then is it acceptable to add a parameter? Use "/update?from=GitHub" for example? Or, is it appropriate to use an extra path element like "/update/GitHub", since the resource really is a "GitHub update", not just a vanilla "update"?

<comment><USER13> What I've seen in the past (mainly from Pylons) is to have an extension on the end of the URL so: /updates/ has a default format say XML and then there's a JSON resource called /updates.json, /updates.txt, etc.

Keep in mind what the R in REST stands for. Each resource is a representation of internal data. You can have multiple representations under different URLs even though they're powered by the same internal data structure. Ideally you'd use the Accept header to do it but sometimes you need to be practical.

<comment><USER9> I disagree. A resource is a concept, not a representation of it. A resource in a car dealership is a 'car', not an ' XML document about a car'. One of the examples given by Fielding are "today's weather in LA"; that's not the representation, it's the actual concept.

The concept of internal data structure doesn't enter the picture at all; for all the client knows, the response might even be generated by a monkey typing on a keyboard.

So if you're using different URLs, you're saying that those are different resources, not multiple representations of the same resource.

Sure, it may be useful and 'practicality beats purity', but it's bending the concept.

</comment></comment></comment><comment><USER14> I had a really interesting conversation about this with a coworker a few weeks ago. We were talking about URL design. I argued for URLs like this:

      /networks/
      /networks/girl_talk/
      /networks/girl_talk/tracks/
      /search?term=bass&sort=artist

He argued for URLs like this (note the pluralization):

      /networks/
      /network/girl_talk/
      /network/girl_talk/tracks/
      /search/bass/sort/artist/

My case boiled down to, "A URL represents the path to a resource. You should be able to remove any number of parts from the end of a URL and be left with a different, meaningful URL. In the case of search, the terms are options that describe what you want returned by the search, not resources."

His case boiled down to, "A URL is a sentence. You should be able to read a URL as English and get a good idea of what it represents. In the case of search, adding more path components adds words to the sentence to make the search more specific."

He pointed out (paraphrasing) that URLs are a language — and languages evolve. URLs as paths better embodies the RFC, but a new style of URL might be more meaningful on today's (and tomorrow's) web.

<comment><USER15> Either way I don't think it matters. Just get it done. Clients do not care about URL structure, they just want their problem solved. I redid an app and prettified the urls (yes I know this is slightly off topic) and no one has commented on it.

Developers will use either, just do it and provide documentation and be done with it

<comment><USER16> Exactly. REST is interesting, but understand why its interesting. If you're doing it because its a popular buzzword, that's just cargo cult.

It's good to know about REST so you can use it where it makes sense. But at the end of the day, doing what is right for your app trumps following any given methodology.

<comment><USER9> But then it's important to document when you're breaking the constraints. Nowadays it's impossible to know if a web service is actually following REST or not because everything remotely similar gets the same label.

</comment></comment></comment></comment><comment><USER17> Here's something I've observed:

i) most successful "RESTful" APIs don't really follow all the REST principles (e.g Flickr, Amazon, Dropbox). My thumb rule is this: If an API does not start from a "mother" URI that gives you the most updated list of resources that can then be requested by the application, it is not really HATEOAS.

ii) a purely resource-oriented view of your entire API space shoehorns you into doing really strange things to keep REST "purity"

So my conclusion is that using an architecture/concept originally intended for humans navigating hypermedia documents may not be a natural fit for parts of your API that cannot be modeled as such. See the Dropbox REST API documentation (<http://www.dropbox.com/developers/docs#api-specification>) (" Section: Deviations From Standard REST Style") to see an example of the pragmatic decisions taken.

</comment><comment><USER18> Is there any way to make the browser do an Accept: application/csv header on a hyperlink?

I'm pretty sure users like their "Download as CSV" links, which I've generally done as /normal/resource/url(.csv)

While this post sets out the ideals, I think there are some cases where for usability, you have to do something less than ideal.

<comment><USER19> Looking at the newer spec, we should be able to use "hreftype" for content type or "hreflang" for accept language: [http://www.w3.org/TR/xhtml2/mod- hyperAttributes.html#s_hyper...](http://www.w3.org/TR/xhtml2/mod- hyperAttributes.html#s_hyperAttributesmodule)

I don't know if any browser will implement this or has implemented it, but in real world scenarios we'll probably have to stick with .csv and en/foo or ?locale=en for a couple of years...

<comment><USER20> XHTML2 is never coming. That train has left its station with HTML5. So long, elegance and ideals! At least I have my ruddy practicality here.

</comment></comment></comment><comment><USER21> Some of this feels like trying too hard to adhere to HTTP. For example,

> Accept: application/vnd.steveklabnik-v2+json

This declaration loses information, because it no longer contains the MIME type for JSON in a standardized format. Assuming the server responds with the same string for Content-Type, any application that does not know specifically about this API can no longer recognize that it's JSON and, e.g., pretty-print it for a user, as I haven't seen done for JSON but is regularly done for XML by browsers.

On the other hand, the original suggestion:

> Accept: application/json

works in theory, but in practice makes it more difficult to test the API in a browser. This is not the end of the world, but there does not seem to be any real benefit in using Accept. I cannot think of any practical situation where a tool can use the standardized header for an advantage...

<comment><USER22> Having your clients send an application specific MIME type can actually be better for browsers as well. All you need to do is provide a representation of your resource in HTML which browsers will request by using "text/html" in the Accept header.

I've found this a nice addition to documentation and, depending on how well the HTML representation has been done, is great for learning/exploring an API.

</comment></comment><comment><USER23> I've personally given up trying to save the term REST. It was hijacked and will never recover completely at this point. What I've been looking for is a good alternative name. Sometimes I'll write out representational state transfer which is clever enough to get past most REST pretenders but I have yet to find something short.

<comment><USER23> I guess I should clarify my statement. The article is right on the dot. The point here is that arguments like this really need a new label. That's all I'll say.

<comment><USER17> But I didn't think that he used the terms too loosely. What do you think was lacking/superflous in his arguments ?

<comment><USER23> I meant this to apply in general. Rather than try to correct people we should introduce people into the architectural style and since REST already means something to many, it only seeds confusion.

</comment></comment></comment></comment><comment><USER24> While I generally agree with the principles underlined in the article, using the Accept-Language header is definitely not the right way to control internationalization.

Remember that one of the advantages of URLs is the ability to easily share them, however I'm not sure I'd be comfortable sharing content that could show up translated to some recipients, based on the language of their browser/application/computer. For example, most CMS systems assume that the content can be completely different between languages (for the same article): you can have the full text in English and only a teaser in other languages.

Maybe not a pure REST approach but using '/en','/pt','/fr' in the URL has proven to be much easier and safer, from my experience.

<comment><USER9> It depends on what content is translated. I think that Accept-Language is OK for UI elements - seeing 'entrar' instead of 'log in' and elements like that. For actual content, probably not.

</comment></comment><comment><USER25> A very good and comprehensive writing.

One thing that I cannot find mentioned neither in the article nor in comments, is the confusion related to the idea of state.

While REST is, by definition, stateless, it merely describes the session, not the manipulated data. There's no way to avoid, at least implicit, object's state. For example, if user's password is not empty, it means that the user already set the password.

More comprehensively, with /users/1/edit, or whatever, it is frequently expected to get a different validation error, depending on the flow, such as a paid account might require more billing related details than one without email confirmed.

Of course, it is a nightmare to maintain such matters implicitly. That's why Ruby on Rails plugins like acts_as_machine, and similar, come handy. They do provide an explicit description of the object's behaviour, easy to transform into documentation, depending on the current state.

The idea shows its full potential with multipage forms. Each step of the form might be described with a different state, stored in the state attribute, leaving the controller RESTful, and the model's validations easy to understand.

A yet another confusion comes with too close database mapping. To stick with Ruby on Rails, there is nothing preventing the developer from creating his own setters and getters, like def vattr=(); end; def vattrr(); end.

The framework passes the value of a virtual attribute, using params, to #update_attribute, and other methods, the same way it does for regular attributes created automatically from the database's schema.

Very frequently such attribute provides a much cleaner way to represent the model, rendering either the HTML or the API much more easier to write or understand.

</comment><comment><USER26> I don't think that I can fully agree with the idea that a news article written in English is not different content from the German version.

<comment><USER27> Technology-puristic take on this is that both the English and the German versions are just representations of the 'real' story underneath.

Generally works better for more real entities like for example specific products, than for articles.

</comment></comment><comment><USER28> If nobody understands REST, and as other articles have claimed, nobody does it right, then why do we keep trying to use it? Switch to something simple that everyone can understand like JSON-RPC and quit worrying about pedantry.

</comment><comment><USER29> good article but...he says version numbers in the url are bad but doesn't say why. using accept headers for versioning is a hassle for every client and makes browser based testing much more difficult. also a v1 user really might not be the same as a v2 user so they shouldn't be the same resource.

<comment><USER9> >he says version numbers in the url are bad but doesn't say why.

Because according to the spec, each resource is named by a single URL, so two URLs name two different resources. But if you put version numbers in the URL, you might end up with <http://example.org/v1/rubyrescue> and <http://example.org/v2/rubyrescue>, which according to the spec are two different users but in reality they're the same.

>also a v1 user really might not be the same as a v2 user

In what cases should the users be tied to the API version? I can't think of any.

<comment><USER29> good point, but the point of a restful resource is that the url represents a resource, but then w/accept header versioning, i now need two pieces of data, one of which isn't visible, to properly represent and retrieve a resource.

I guess my point is that if i have to pick, i'd rather occasionally have two request urls with a minor version difference that are actually the same resource than two urls that appear to be the same resource but are not because one was requested with a header that affects the returned data.

<comment><USER9> You're confusing resource with representation. An URL is a resource, but if the representation of that is a JSON document or a picture of him/her, that's up to the server. Just because an header affects the representation of a resource, doesn't mean they're different resources.

<comment><USER29> actually that's a good example that makes my point. if i said to you - well if you want to retrieve a person's user information, just GET /users/1 with Accept: text/json. If you want their photo, just GET /users/1 with Accept: image/jpeg - _philosophically_ , i'm not violating the 'rules of REST' but it feels wrong to me.

<comment><USER9> Sure, I would create a "User's photo" resource too and link it from /users/1, but that's because a user's photo can be a new resource, so it can have its own URL.

</comment></comment></comment></comment></comment></comment><comment><USER30> Excellent article... We followed all of these Rest principals when we designed apis for HP cloud print (i think it will soon become public)..except

1) Representing all resources with noun - We had a tough time representing all resources with Noun. One of our APIs is Post on \PrintJobs\ - creates a new print job

But printing can only start when all the data (content to be printed) is uploaded on the server. So client needed an API to tell the server that it can start printing..something like this..

\printjobs\1\print \printjobs\1\cancel

one way we thought to avoid this was to have a represent it job state and client can change them like this..

\printjobs\1 Put : <job> <state="print"> </job>

But there are cons

1\. These were not actually states, these were actions(verbs)..because state would be initialized, printing etc.. so if client does Get after making it Put..it will get "printing" not "Print".

So we were tangling with keeping semantics clear and making it easy at the same time. Hence we went with these resources. Do you think it could modeled better?

2) When we think of versioning, we always assume that only the representation can be changed..why not behavior? Take for e.g. if api implementation changes but not representation..clients may be dependent upon the implementation (i know this is bad! since implementation details are getting leaked out from the API)

Thoughts?

</comment><comment><USER31> You can't satisfy the HATEOAS constraint by simply returning URLs in the JSON response from your API. The structure of the data is still tightly coupled to your own application, and so must be any client that can make use of it.

It is essential that RESTful applications be able to evolve independently from the client. To allow this, they must use forms of hypermedia generic enough to serve as the engine for all present and future versions of the application. If the client has any code specific to your app, then your app is not RESTful in any scope beyond its own.

I'm not convinced that the whole resource vs action thing is all that important to REST. It's an ideal that has been largely ignored in practice and the web has been quite successful without it. Contrast this with HATEOAS which has been the unavoidable reality of the web since day one.

</comment><comment><USER32> The problem with posts like these is that they say things like "THIS IS BAD!!!!!1" without saying why.

<comment><USER33> That's not true with this post in particular.

It's not saying various practices are "bad," but that they don't conform to REST or the principles laid out in the HTTP specs.

<comment><USER32> The above quote "THIS IS BAD!!!!!1" was lifted directly from the article.

<comment><USER33> Before he even discusses his individual points the author gives his definition of "bad," and the reason the other approaches are "bad." From the introduction:

> _Let's talk about a few cases where either REST or HTTP (which is clearly > RESTful in its design) solves a common web development problem._

> _so they make up a partial solution that solves their given case but doesn't > jive well with the way that everything else works_

</comment></comment></comment></comment><comment><USER34> I don't understand the point of "uri":"/transactions/1". Isn't the new resource's URI already part of the response (in the Location: header)? It's sort of like saying GET /posts/show/1 vs. GET /posts/1.

<comment><USER9> I agree, it's redundant.

<comment><USER35> It's redundant _in that particular instance_. But it's a representation of a resource. It might be nice to define the representation across your entire system so that when you grab a transaction resource with a GET later, it still has that URI in it. Or maybe not. But it's not obvious that this is a bad idea.

<comment><USER9> But to access that JSON document with the URI, you had to know the URI already (in this case, by following the Location header).

It's like having a link on a webpage to itself, what's the point? I can just refresh.

</comment></comment></comment></comment><comment><USER36> Content Negotiation is a critical part of REST APIs and it's my observation that most simply ignore or default to JSON in all cases. Good REST APIs allow the client to "choose" the mime type. Without this part of REST - you have no "representational".

On that topic, to rely on an 'Accept' header is pretty risky. That presumes the client will always have control over the headers. It is in my opinion always wiser to make the API determine mime type by extension (.html, .xml, .json etc).

<comment><USER36> Was there something particularly wrong about my comment(s) here? Seems I was down voted on all 3.

</comment></comment><comment><USER37> This is a great article. One challenge I am facing now is both building a RESTful API, along with a UI that uses the API. The biggest question I have is the use of shebangs in urls with the ajaxy app. We must support IE so pushState is out, but shebang just seems like a hack. I think at this point I have no choice but to implement shebang but I wonder if there are any viable alternatives?

<comment><USER17> Try this : <https://github.com/balupton/History.js>

<comment><USER37> Looking good at first glance, thanks!

</comment></comment></comment><comment><USER38> I've been working with/learning about Webmachine lately. A really nice framework for building REST APIs.

</comment><comment><USER39> I've had this discussion about hundred times now. REST "standards" are as important and significant as brace indentation "standards". A big problem with REST is that it is NOT a canonical (or even important) standard, but rather a useful pattern than can be used to make things exposed via HTTP more intuitive. The evil side effect of this is that a metric crapton of architects/engineers are wasting fifty bajillion programming-hours arguing irrelevant details about who's doing it "right" instead of building useful software. You cannot do REST "wrong" and more than you can do software "wrong"... Folks who argue about the "right" way of doing software are usually "wrong" because they are focused on writing software instead of solving problems.

We need to keep our priorities straight.

<comment><USER35> I understand your frustration but I think you are misguided. Standards (and their cousins, best practices) are important to think about in order to create diverse yet maintainable and inter-operable systems.

"A big problem with REST is that it is NOT a canonical (or even important) standard, but rather a useful pattern than can be used to make things exposed via HTTP more intuitive."

No, its not meant to make HTTP interfaces "more intuitive". HTTP clients are machines. They don't have intuition. When your web browser hits the HN front page, it isn't using intuition to figure out what links to display.

You can make an argument that for a particular web service, adhering to a particular principle of REST doesn't matter. But you have suggested that the principles of rest never need to be an important consideration for any web service, which I submit is plainly false.

</comment></comment><comment><USER40> I really dislike creating resources to represent transient actions. Not a big deal in the case of a bank transaction as that is something you could easily imagine needing to be stored for later retrieval. A different example is relating one social network friend to another or searching for specific people on the site. Those are things that, to me, are much more borderline and I would err on the side of not representing them as resources.

<comment><USER35> You haven't really explained why you don't like creating resources to represent transient actions. What's wrong with POSTing to /friend-requests with requestor=stanleydrew&requestee=mberning? There's no need to keep a log around if you don't have use for it.

</comment></comment><comment><USER41> It really is a good read, I need to digest it, but my initial reaction is that some of this isn't pragmatic. Versions in URLs makes for dead-simple routing in any framework. Also, many APIs are used in a way where you _know_ consumers will create a resource without requesting it (or at least, not within the same session). So why return any location information (whether in a header or in the body)?

</comment><comment><USER42> Ironic that the author's homepage (<http://steveklabnik.com/>) is a confusing pretend console that takes several seconds (on every visit!) to reveal useful information.

</comment><comment><USER43> The title seems rather sensational. Is that really necessary?

<comment><USER43> Why all the downvotes? Is it really true that NOBODY understands REST or HTTP?

</comment></comment><comment><USER44> REST is great and all, but browsers don't allow it. The only thing you can do is GET, nothing else is supported cross-domain.

No matter your thoughts on REST, it's dead. It's never happening. This argument has gone nowhere for 10 years.

Very few if any websites conform to the spec, and browsers have made it impossible to do so.

</comment><comment><USER45> Rest was a really big deal in the Java web-app world for about a year...

It was back when early versions of Struts were 'the designated alternative', and in the bad old days of J2EE and JAX-RPC.

Then Java EE 5 came out, which solved large chunks of the pain that J2EE inflicted, JAX-RPC got replaced with the infinitely better JAX-WS and there was a new breed of web frameworks as well, which blew Struts out of the water.

About that time REST essentially became 'yesterdays technology, solving yesterdays problems'.

I find it interesting that the guy banging the REST drum is a Ruby fan. Has REST always been part of Rails? Or is it something that has crept in over the last couple of years?

Is there anything genuinely new here, or is it the same old story, some dude clinging desperately to an obsolete technology?

<comment><USER46> I want to know what part of the Java web world you are talking about exactly?

I just question the concept that REST is in anyway considered to be obsolete within the Java web world. Spring-MVC focuses more and more around this technology, and is also the delivery point for REST web services from spring; Struts 2 has slowly moved more towards RESTfulness; and additionally frameworks like Play have come around.

</comment></comment><comment><USER47> This is an excellent example of a spec being deemed more important than a useable system.

Frankly, I don't give a damn about the REST spec, and neither should you. When I see an API I want it to be simple and clear.

/getAllPages/

Hey, it's a verb and I've got a pretty good idea of what I'm going to get back

/getAllPageNames/returnType/JSON

Now I really know what I'm getting. The simplicity and usability of this structure absolutely trumps a spec compliant call that involves request headers and nouns.

If you're building a system that requires having read someones dissertation, you're not doing us any favors. Especially when it comes to an API. Keep it simple, stupid.

Remember that your understanding of what a URL 'is' or 'should be' comes from a great deal of technical experience. If you're not working day in and day out to make powerful tools accessible to people WITHOUT such experience, please stop programming. Really, get out of the pool. Whatever awesome knowledge you need to make a system work internally is invaluable, but your interfaces should make the world a simpler, more magical place.

<comment><USER37> Did you read the article? No matter nouns or verbs but in your example you are doing an HTTP GET. Does get getallpages sound right to you?

I did not downvote you but the REST architecture is well thought out, simple to follow, and very sufficient if you are moving content over HTTP.

<comment><USER47> First off, thanks for taking the time to reply to my admittedly baiting post. I do have a serious point I'm making though. Lets walk through it.

<http://www.mywebsite.com/api/getAllPageNames/returnType/JSON>

In this string 'get' appears once. However, as an experienced dev, you know that this is a GET request. To you it looks redundant. However to someone trying to understand what will happen when they hit enter with this URL in their location bar it is meaningful.

The question at that point is naturally "But if you don't know that's a GET request then why are you using an API?"

This is the point I'm driving at. There are scores of underserved individuals who want to do interesting things with your website that go beyond your GUI, and they are just brave enough to read through your API docs.

Now, when I'm thinking about API design I have a big initial choice. Is this API for skilled developers who care about the REST spec? Or is this a tool for as many people as possible to get more out of my service than I have time to accommodate with features. This is where I will always say "I don't care about the spec." A really talented dev will read the docs, discover how my design works, and will write something cool on top of it. I can trust the hackers I know to make things work by hook or by crook. The same cannot be said for someone who really wants to extend my functionality but isn't a talented developer.

I feel it's my responsibility to produce a tool that can be used by as many people as possible. I don't want to make a high-end professional camera, I want to make a better point and shoot. I want to extend the abilities of people, not demand they gain a large skillset to use my new tool.

New programmers and enthusiastic users are always on my mind. These are the people who's preconceptions are that it should 'just work' and that if it doesn't it's my fault.

This is why I applaud decisions like Chrome dropping <http://> It simply doesn't matter to 99% of the users of the product, and in fact makes browsers less friendly and more confusing.

If I can get my api to work like this, then I will:

'I want to see all the names of pages on mywebsite.com'

If I had access to a deterministic natural language parser then I'd use it. As such a thing doesn't yet exist, I try to remain as true to that ideal as possible.

The REST architecture may be less confusing than others, but it is far from simple.

<comment><USER9> But you _still_ have to make a GET request and hence understand what that verb does - so you don't really gain anything - and now you're creating ambiguities for the API users. What if I POST to 'getAllPageNames'? It doesn't make sense, does it?

Personally, I'd say that if a developer can't be bothered to read the whole nine(!) verbs of HTTP, he shouldn't use the API. I mean, GET is described in just 11 lines!

And (s)he doesn't need to read your docs: the smart thing about the Uniform Interface described by REST is that the same verbs work on _all_ services of the same architecture (in this case, HTTP). So that knowledge is generic and transferable.

In any case, it's your prerogative to design your API as you wish, but please don't call it REST if you don't intend to follow its principles.

<comment><USER30> I agree! Making such api make it really confusing. And what if one have to support other verbs. Then, One will end creating apis for each verb. A programmer who is using this APIs knows about HTTP and he knows about verb..making it explicit in the url will make confusing for most developers.</comment></comment></comment></comment></comment>


The State of Meteor Part 1: What Went Wrong - <AUTHOR> https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/ <comment><AUTHOR> _This explains why MDG left things like file structure, routing and forms to the community. Even though these are key part of nearly every single web app out there, they're framework-level components, not platform-level._

When I tried out meteor for the first time, the lack of official consensus on things like folder structure, routing, and what is a "model" kept me from considering it further.

The small demo projects were fun though.</comment>


Hash Algorithm Strength - <AUTHOR> http://www.scientificblogging.com/staring_empty_pages/blog/hash_algorithm_strength

<comment><USER2> Normally when people talk about the birthday paradox, they mean "it is surprisingly likely that some two students in a classroom will have the same birthday" rather than "it is surprisingly likely that some student will have the same birthday as the teacher."

Anyways, let's say h is a hashing function, and x = h(a), where I know x but not a. I want to find b so that h(b) = h(a). Let's say that for a random b, we have P(h(a)=h(b)) = p. Then it is quite easy to compute that the expected number of tries to find b with h(a)=h(b) is 1/p.

(In particular:

      E(#of tries) = (p)(1) + (1-p)(p)(2) + (1-p)(1-p)(p)(3) + ...
      =  p(1/p)(1/p) = 1/p.

    )</comment>


Ask HN: Dual boot OS on SSD, store data on HDD - <AUTHOR>

I recently built a new computer (yay!) and am trying to set up the OS's right now. I've currently got Ubuntu 14.04 and Windows 8.1 installed on an SSD (both are working fine). Now, what I'd like to do is store all of the data (i.e. games, docs, videos, etc.) on the HDD.<p>Has anyone done this before and could maybe give me some advice? I've found lots of information about how to do this with just one OS (i.e. boot Ubuntu on SSD, store /home directory on HDD), but I can't find much about having two OS's and attempting the same thing. <comment><USER2> If it's a fresh hard drive, why not partition it?

Unless you are looking to use it on both Windows and Ubuntu, and in that case Ubuntu should have no problem reading and writing to it if you set it up in Windows.</comment>


Some more hands-on experience with the new MacBook Pros - <AUTHOR> https://sixcolors.com/post/2016/10/some-more-hands-on-experience-with-the-new-macbook-pros/ <comment><USER2> Good to read an actual review rather than e rehashed press release which is what most technology sites offer these days</comment>


Half Life: The Decay of Knowledge and What to Do About It - <AUTHOR> https://www.fs.blog/2018/03/half-life/ <comment><AUTHOR> The doubling of knowledge increases the learning load over time. As a body of knowledge doubles so does the cost of wrapping your head around what we already know. This cost is the burden of knowledge. To be the best in a general field today requires that you know more than the person who was the best only 20 years ago. Not only do you have to be better to be the best, but you also have to be better just to stay in the game.

</comment><comment><AUTHOR> Here is a PDF copy of the book - Little Science, Big Science and Beyond - referred in the post: [http://www.andreasaltelli.eu/file/repository/Little_science_...](http://www.andreasaltelli.eu/file/repository/Little_science_big_science_and_beyond.pdf)</comment>


How to Solder [comic] - <AUTHOR> http://log.andie.se/post/397677855/soldering-is-easy <comment><USER2> Another thing: good tools matter (just like with software). Don't try to solder electronics with a RadioShack iron. It can be done, sure, but it's frustrating. Get a temperature-controller solder station and a fine tip for the iron. This will cost about $100, but will last years and produce much better results.

Another nice thing to get is a circuit board holder so you don't have to lay the board upside down on the table as shown in the comic. A good holder will help you work with surface-mount stuff too.

I also have a fan with a carbon filter to help with the fumes. Much nicer than blowing smoke out of your way yourself :)

<comment><USER3> Great suggestions. A nice Weller station will make your life infinitely better.

Another thing that helps make beautiful, clean solder joints is flux. I used to stuff PCBs with surface mount components, and my general practice was to just swab flux over everything before soldering. Then, when you're done, you need to scrub the board in hot water to remove the flux, but it's worth the trouble.

</comment></comment><comment><USER4> He forgot what I think is one of the most important steps. Before heating the pad and the component lead, touch the solder to the tip of the iron just to wet it a little. The little bit of solder on the tip of the iron really helps in conducting heat to the components. And only use 60/40 lead/tin solder (Radio Shack brand solder works the best.) Save the lead free stuff for when you are in production and someone else is doing the soldering, it is much harder to work with

<comment><USER5> Another thing left out is solder flux. Some surfaces might be too small or too hard to reach and heat with the iron so I put flux onto the surface first and it causes the solder to flow into that area more easily. For instance, if you want to solder a thin wire into a small hole getting the solder to flow into the hole around the wire is difficult. If you put some flux onto the wire first and then slide it into the hole the solder will flow along the wire and will fill the hole nicely.

</comment></comment><comment><USER6> I saw Mitch at an event. He said that 'it's easy to solder. the hard part is unsoldering'.

That being said, he gave some amazing impromptu demonstrations of unsoldering. Stuff like heating up the soldered bit and turning the PCB upside down and hitting it not too hard but still firmly (with the flair and skill of a chef pan flipping a soufflé) to get the solder out of a hole.

</comment><comment><USER7> My soldering iron seems to make inconsistent heat. One minute it will melt the solder instantly and the next anywhere on the iron I touch the solder to, nothing will happen.

Any idea what could be going on there?

Also I seem to be going through tips really fast.

<comment><USER8> You need to "tin" your tips, that is keep them covered with a thin layer of clean solder. I normally touch a piece of solder to the tip then wipe it off lightly with a clean, dry rag just before I unplug my iron each time I use it. Doing it _after_ you finish helps insure against corrosion in storage, plus it is all ready to go the next time.

</comment></comment><comment><USER9> I wish I had read this, or something similar, when I learned how to solder. I initially was doing "cold soldering" by just melting the solder and using it like glue. Soldering became much easier once I learned the right way.

</comment><comment><USER7> Anyone have a good tutorial on soldering really small surface mount components?

<comment><USER10> <http://www.youtube.com/watch?v=3NN7UGWYmBY> This is really good. He does harder and harder stuff, ending with a 208 pin chip.</comment></comment>


Show HN: Review my webapp please - <AUTHOR> http://www.connectedtrips.com/

<comment><AUTHOR> All feedback appreciated, especially:

\- is it clear what we do? \- is it easy to use? \- is the search intuitive?

Thanks :)

<comment><USER2> I didn't read much. But from what I can tell, I am super confused.

I go to a trip website and there is someone doing yoga in like every picture? Is this a yoga trip? Maybe make it more OMiful.

<comment><AUTHOR> Thanks for the feedback.

We're selling trips that are good for you so yoga trips are a big part of what we do.

Not sure what OMiful is - can you explain please?</comment></comment></comment>


Goldeneye 64's inspirational startup story - <AUTHOR> http://www.alexbaldwin.com/goldeneye/ <comment><USER3> Pretty cool to see so many fellow hackers with similar positive memories of this game. It's pretty indicative of the age group here on HN. For reference, I'm 23.

This was one of the greatest games ever made, no doubt. I've actually never been able to relate to a lot of my buddies who can game for hours on end. Starcraft, WoW, etc.. bore me after 30 minutes.

Goldeneye on the other hand ... I could have easily died from starvation without the parental supervision.

Anyhow, back to the original post. It's interesting to me that the original team had no idea what they were doing. I still look back on apps or things I built years ago, lacking absolutely any idea of what I was doing, and being amazed at how successful or great they ended up. Inversely, sometimes the product or thing I spent the most time agonizing over ended up being a total flop. More and more I am learning that you just gotta side with the majority of the 80/20, stick to your gut feelings, and jam jam jam to get that puppy out the door.

It's always tricky to find that perfect place between being a bootstrapped/scaffolded/barebones MVP product and a well-thought out, carefully designed product. I'm glad the Rare team managed to hit it with Goldeneye, they're an inspiration.

<comment><USER4> >> It's pretty indicative of the age group here on HN. For reference, I'm 23.

I'm not sure exactly what it says, but I'm a decade older than you, and I lost countless days to this game. The best opponent I had was four years older than me!

I don't quite understand the love for the four player multi though. It seemed unplayably choppy to me with with that many opponents, but I never did get that expansion pack that sticks in the front. Also didn't care for the limited view range. But heads up multi-player... fantastic.

<comment><USER5> I'm another decade older and I lost countless lives playing this game ... My (then) 9th grade son, his friend and his friend's little sister consistently ended each life just seconds after it began!

</comment></comment></comment><comment> k-mcgrady I've never been a big gamer. I have a short attention span and lose interest too quickly, but I loved Goldeneye 64. The N64 was my first games console (I got it soon after it came out, I think I was 7 at the time) and Goldeneye was the game that was bundled with it. In general there were some great N64 games. The were the obvious ones like Super Mario, Mission Impossible was another good one, but my favourite was Diddy Kong Racing. It was the only game I've ever got 'addicted' too. The N64's also one of the few pieces of tech I've held on to. Every now and then I hook it up and get another few weeks of fun out of it.

</comment><comment><USER6> Power Weapons in the Stack. I owned the top floor.

Immediately prior to reading this, I was writing about how non-game developers can indeed bring a unique perspective to the table when developing games. This is definitely an inspirational story and helpful in reaffirming my thoughts. Thanks for sharing.

<comment><USER7> One of the things that I liked about Goldeneye was just how damn many multiplayer modes there were. eg. The Klobb was a crappy gun (low damage, huge cone of fire), but switch to one-shot-kills and it's suddenly an uber weapon :)

My favorite modes were one shot kills with knives or slappers only, power weapons with health cranked up, or anything involving prox mines :>

I haven't played it for years now, and I'm not sure how easy it is to get N64 consoles now, but if you want something similar, TimeSplitters for the Gamecube had very similar gameplay (and a lot more options, including bots and fully customisable loadouts).

<comment><USER8> I liked the remote mines a lot more. You could go hide in the vent in facility and look at other people's screens to see where they were. When they got to the right place, bam, you detonated the mine.

God that was a great game.

<comment><USER7> The "problem" with remote mines was that you could throw a mine and press A+B at the same time while it was still in mid-air. BOOM! Instant detonation! So you'd be able to just insta-kill people who weren't expecting it.

Eventually it balanced out because everyone would be a lot more careful about getting close and going around corners, but ... let's just say that raegquits are a lot more fun in-person :)

</comment></comment></comment></comment><comment><USER9> I enjoyed reading this until I reached the end: "I still have nightmares about playing Temple and not being able to find the proximity mines. If you like James Bond, lattes, startups and design, you'd enjoy my tweets."

Talk about a non sequitur.

<comment><USER10> Yeah, what the hell? I don't get why people beg for followers at the end of their blog posts. It just leaves a sour taste in my mouth after what would have been a great reading experience.

<comment><USER11> > _I don't get why people beg for followers at the end of their blog posts._

You don't understand why people promote themselves? You made it to the end of the blog post, which likely indicates that you enjoyed the content. Why wouldn't he say "hey follow me on twitter so that if I write another post that doesn't make it to HN front page, you can hear about it," to try to get some extra followers? Would you prefer he ask you to follow him at the beginning of the post?

<comment><USER9> There's a huge "Follow so-and-so" Twitter button immediately following the writing, so I'm pretty sure that the corny self-promotion didn't need to be part of the article itself. I read lots of articles where this happens, and it's always jarring.

<comment><USER12> The suggestion text has been shown to work better than just placing a button. Building up your personal brand can be worth a lot in the long run, so why not?

<comment><USER13> I don't like being manipulated. Every time I see a "You should follow me on Twitter" kinda thing I make it a point to not follow the author, or maybe even unfollow them.

Holding your readership in higher regards than a meaningless metric can be worth a lot in the long run, too.

<comment><USER14> Manipulated ? He just said in other words - "Hey follow me on twitter if you want to stay updated". Is that manipulation according to you ?

I actually looked for the twitter button on his site so that I could follow him - since I did enjoy the post and would like to see more from him. Didn't feel manipulated though.

<comment><USER15> I think the idea is that, if I like what he has to say, I'll just do it. He doesn't have to ask, and doing so _inside_ the post shifts the whole thing from inspirational anecdote, to well-written justification of why you should follow his Twitter.

<comment><USER13> I agree. It devalues the article because it becomes part of an agenda instead of standing on its own.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER16> Proximity Mines under the ammo spawns. Invisible room in facility, entrance in Temple. Race to choose oddjob.

<comment><USER17> Oddjob was banned pretty early on in my family.

<comment><USER7> My house rules were "Pick any character you like, I'll kill you anyway" :)

</comment></comment></comment><comment><AUTHOR> Proximity mines on temple, that almost never happened. Thankfully that one developer stood for what's right and made our childhoods that much better.

</comment><comment><USER18> This article seemed very familiar, and I found the original article where a lot of the quotes/text came from, 'The Making of Goldeneye' from may 2011 [1]

[1]: [http://www.nowgamer.com/features/921602/the_making_of_golden...](http://www.nowgamer.com/features/921602/the_making_of_goldeneye.html)

</comment><comment><USER19> For those interested in more development anecdotes, the game's director did a full postmortem at this year's GDC Europe: [http://www.gdcvault.com/play/1016460/Classic-Postmortem- Gold...](http://www.gdcvault.com/play/1016460/Classic-Postmortem- GoldenEye.php)

</comment><comment><USER20> Alas, the article is a bit thin on the details.

<comment><USER21> Someone throwing some quotes into a reddit-esque nostalgia post and topping it off with his name in size 40 font hardly qualifies as an article. When I first saw the title I was hoping for something along the lines of the recent Starcraft article ([http://www.codeofhonor.com/blog/tough-times-on-the-road- to-s...](http://www.codeofhonor.com/blog/tough-times-on-the-road-to- starcraft)).

</comment></comment><comment><USER22> Best game ever. So many fun times with my buddies playing the 4 screen multi- player, throwing proximity mines on every spawn spot in the Facility.

<comment><USER23> My favorite trick is that the spawn sequences were not actually random. They would cycle predictably and only randomize if someone was too close to the respawn point.

Especially in levels like the bunker, if you hovered just a breadth out of distance in a two-player game, it was possible to wrack up multiple kills very easily and would often take an equally experienced player to even have a chance of making it to the nearest weapon in time.

<comment><USER7> Heh, you even have your HN account named after a 007 character :)

</comment></comment></comment><comment><USER24> I really loved the menu screen showing you what levels you'd done and what difficulty level you'd done them on. Simple, efficient.

It took me weeks to realise that the cut-scene graphics were actually useful and not just fluff. They often provided hints and tips or let you know about enemies.

There's a bunch of stuff still in the rom code that isn't accessible from the game - the hidden island; some glitchy levels. And there's some bits left over from the "notorious" but removed "put your face in the game" mode. (Which used the GB camera to map face photos onto game models for multiplayer but got removed after a mass shooting.)

I loved the train; I loved the tunnel in the damn. I hated trying to keep the bloody hostages alive on the boat. The first few times I set the alarm off were scary.

This was an amazing game. The N64 was a peculiar sweet spot for games and I'm not sure why.

<comment><USER25> > The N64 was a peculiar sweet spot for games and I'm not sure why.

That's arguably age-related nostalgia. I feel the same way about the Super Nintendo instead of the N64.

<http://www.qwantz.com/index.php?comic=1322>

<comment><USER26> The N64 was a very poor system for games. You had a few very good ones and a lot of crap. The Playstation was a way more versatile system with great games in all genres. Hell, even the Saturn was more complete in terms of software.

<comment><USER27> The N64 had fewer games and more expensive than the competition, but the quality standard was far higher (there was a whole lot of unbelievably crap shovelware produced for playstation) and it was a more powerful system; the best N64 games (of which Goldeneye was certainly one) were by and large better than the best Playstation games.

In "top 10 games of all time" lists the only Playstation game you tend to see is FFVII, which deserves its place but is more a triumph of storytelling than gameplay; from the N64 Ocarina of Time and Goldeneye both regularly feature. It was only towards the end of its life that we saw Playstation games comparable to those in technical terms (heck, while it's been overshadowed by later instalments I remember being blown away by Rogue Squadron back in '97 or so), and I don't think we ever saw the equal of Perfect Dark until the next console generation and Halo.

<comment><USER28> Besides FF, Metal Gear Solid is another game for the PS1 that I have seen pop up on top 10 lists. Both the N64 and the PS1 had a range of good games for their system. Tomb Raider, Gran Turismo, Spyro, Castlevania: Symphony of the Night all come to mind as quality games that you could pick up today and enjoy for the PS1. But really these days you can pick up the systems for pocket change ($20 tops?) so if you are a gamer owning both to experience the best in both systems seems like a no brainer.

<comment><USER24> PS1 had some great games. Obviously Gran Turismo needs to be mentioned - <USER2> was important in the development of 'realistic' driving simulations.

IMO the original is much much harder than the follow-ups. Those licence tests were hard. (And a great part of the game play that they only really realised in much later incarnations, that tiny short challenge had the "just one more try" feature that's important for good addictive game play.)

Tomb raider is an interesting choice. It's a huge franchise, and very very popular. Some parts of the games were really good. But the games did suffer from unnecessary bugginess. Which is weird because that company produced other great games that were not full of bugs.

Owning many systems is, obviously, something that people who love games should be doing. BomberMan on SNES is god-like multiplayer; MicroMachines on Genesis / megadrive is the best version; etc.

It's a shame that as the hardware (and the storage medium) is dying that people have to rely on emulation. Mostly this is great. But for some systems it's not, and for all systems it's not legal.

It'd be nice if there was a simple way to pay for playing roms, and if people could work on emulators for dead systems without facing scary legal stuff.

</comment></comment></comment></comment></comment></comment><comment><USER29> Temple in Perfect Dark was the best multiplayer game ever.

Tangential to OP's article, <http://console.fm> is awesome.

<comment><AUTHOR> Haha thank you, it's a really great project to work on.

<comment><USER30> This is brilliant. Thanks so much for doing an API! As much as I like web apps, I'd hate to keep a tab open for the entire day in my browser. I'll go build a simple native mac app that sits in the toolbar and plays music.

</comment></comment></comment><comment><USER31> I'd be just as interested in how Rare went from doing Goldeneye 64 to making what seem to be relatively mediocre games today.

<comment><USER24> Pre MS buyout:

GoldenEye 64, Blast Corps, Donkey Kong Country, Killer Instinct, Banjo- Kazooie, and Perfect Dark.

After MS buyout?

<comment><USER32> I really enjoyed Viva Piniata and Kameo! Both were extremely high quality.

What is amazing about Viva Piniata was that my retired mom (afraid of turning on the computer) got interested seeing me play and started playing herself! She ended up unlocking every single feature/award in the game, and this led her to play other Animal Crossing on the GameCube. I got her the first iPad when it came out and she is now essentially a regular computer user! While Viva Piniata might not have been a commercial success, I know one life it changed and I'd bet there are a lot more.

Frankly, I wish the world had more daring developers/game companies/people. The situation with Rare isn't a good one as your quip points out. Sadly, no matter how artistically awesome your games are, without commercial success, you cannot survive. This leads to a world of xbox games where pretty much every game is a shooter. IMHO, that is why tablets are kicking console gamings behind. It seems more creative titles for tablets (and perhaps the indie game section of xbox live) than for the xbox today.

</comment></comment></comment><comment><AUTHOR> Anyone interested in putting together a game in SF?

<comment><USER33> Yes, yes we are.

 _Edit_ : And by that I mean you should take point and make it happen ;)

</comment></comment><comment><USER34> It's been such a great game, I lost countless hours as well.

They redid the original Goldeneye for Wii and sadly I bought it. It's a horrible remake. Aiming with pointing using the Wii Remote is really hard and turning around takes ages, but this isn't the worst thing. They changed the multiplayer game mode: You can't pick up other weapons as you could in the 64 version - you have to chose in the beginning which weapons you'd like... I always loved this in the 64 version (proximity mines..oh yes :D)

</comment><comment><USER35> I spent a ton of time playing this game as a kid. I remember the game being flawless as far as gameplay, and those were good times.

Point: Maybe more mainstream games should be created by inexperienced teams to compete with the 6-month Call of Duty plot change cycle (i.e. same shit different day).

</comment><comment><USER36> That game was in the top 5 N64 games sold, routinely hitting the top spot for roughly 3 years [and perhaps a little change]. It was an incredible run, I remember following it in EGM.

</comment><comment><USER37> It was still a bad idea to base your game on movie ip.</comment>


James Mickens on JavaScript - joatmon-snoo https://www.youtube.com/watch?v=D5xh0ZIEUOE <comment> joatmon-snoo Goes wonderfully with Gary Bernhardt's Wat talk; I just haven't seen this one mentioned here before.</comment>


TRAPPIST-1 Is Older Than Our Solar System - <AUTHOR> https://www.nasa.gov/feature/jpl/trappist-1-is-older-than-our-solar-system <comment><USER2> I just finished reading The Three Body Problem and I can't help thinking that we could send signals that would reach these planets in 40 years, we could get a response in 80 and if we could achieve c/10 we could get there in something like 500 years depending on acceleration.

<comment><USER3> Receiving a signal would be one of the more chilling things the Earth civilization can ever experience.

Good thing if these guys would be on approximately the same stage as we are, but chances are slim. An answer from someone who knows about radio for 1000 years in much more probable than from someone who knows it for 100 years, as we do.

Meeting the technologically more more advanced European expeditions did change the lives of the natives of the Americas, probably to the better, after a few centuries — if we ignore certain details.

<comment><USER4> _Two possibilities exist: Either we are alone in the universe or we are not. Both are equally terrifying._ \- Arthur C Clarke.

<comment><USER5> Third possibility: we do not exist either.

<comment><USER6> I'm with Descartes on this one.

</comment></comment></comment></comment></comment><comment><USER7> A system that will live for 12 trillion years. A home to seven Earth-sized worlds, rocky planets inside the Goldilocks zone. A hope, at least, for an atmosphere.

What a universe!

<comment><USER8> Not all seven, but three of them are in the habitable zone.

Still better than our system no doubt.

<comment><USER9> We also have three rocky planets in the habitable zone. That's not sufficient to actually make them habitable.

<comment><USER7> I dunno, there's pretty strong evidence that one out of the three here is, in fact, habitable.

<comment><USER10> Whether it harbors intelligent life, however, is still up for debate.

<comment><USER11> By the looks of it, we still have a long way to go. :)

<comment><USER12> So far, we're not doing any better than cyanobacteria -Ray Pierrehumbert.

(The start of photosynthesis by cyanobacteria nearly killed all life on the planet.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Can someone sum this up for me? The site is too slow/buggy for my phone.

<comment><USER14> TRAPPIST-1, a system of seven Earth-size worlds orbiting an ultra-cool dwarf star about 40 light-years away. Researchers say in a new study that the TRAPPIST-1 star is quite old: between 5.4 and 9.8 billion years. This is up to twice as old as our own solar system, which formed some 4.5 billion years ago.

<comment><USER15> Having recently read Eerie Silence, findings like this do underscore the question of just how likely life is. More, given life, is intelligence a given? And if there is intelligence, is scientific expansion style intelligence a given?

I confess these are obvious questions. I had never considered them, though. Is crazy interesting to consider.

<comment><USER16> > _More, given life, is intelligence a given?_

Isn't intelligence just one particular adaptation that helps reproductive success? I'm not sure why it would be more common than flight or warm- bloodedness.

<comment><USER17> It seems intelligence is more of a 'master key' that unlocks reproductive success in a variety of environments and at large scale. The jury is still out on whether it's a given that intelligence ultimately destroys itself.

<comment><USER13> As in the "great filter"

</comment></comment></comment></comment></comment></comment><comment><USER18> 20th century sci-fi: Attack of the Martians

21st century sci-fi: Attack of the aliens from TRAPPIST-1</comment>


Java 8 Features - <AUTHOR> http://www.infoq.com/articles/Java-8-Quiet-Features?utm_source=hackernews&utm_medium=link&utm_campaign=8java_article If you haven't seen some of the videos or tutorials around Java 8, you've probably been super-busy or have a more interesting social life than I do (which isn't saying much). With new features like lambda expressions and Project Nashorn taking so much of the spotlight, I wanted to focus on some new APIs that have been a bit under the radar, but make Java 8 better in so many ways. <comment><USER2> The new Date API will be a big win for new developers. I think it was created by the same person that made Joda-Time, so there's some real world experience behind the new API.

I also like the easy parallelization functions, though as the article indicates they're not suitable for every use case.

<comment><USER3> Absolutely, good thing they've learned from the java logging disaster. I nerdrage so hard every time I think about it - how can one mess up something so basic, yet so important? Maybe some sunny day, they'll fix that too.

<comment><USER4> I'm curious (it's a long time since I programmed in Java) - what is the java logging disaster?

<comment><USER5> Beyond actual capabilities of log4j vs JDK logging, it's not clear that anyone considered how adoption would work. At the time, log4j supported several back versions of the JDK, while JDK logging obviously required you to be on the newest version, v1.4. As a result, if a library wanted to support any older JDKs, they couldn't switch to JDK logging, or had to support two parallel logging frameworks for little gain. And if your libraries are sticking with log4j, what's the advantage to your program of using the JDK logging?

slf4j is the current solution for this kind of problem, a common interface to various different logging solutions.

<comment><USER6> Logback (next gen log4j): [http://logback.qos.ch/](http://logback.qos.ch/)

<comment><USER7> Log4j 2 (next gen logback): [http://logging.apache.org/log4j/2.x/](http://logging.apache.org/log4j/2.x/)

<comment><USER8> Curious, why Ceki Gülcü (Log4J author) is no longer in team?

<comment><USER9> Ceki left Log4J to develop Logback, I think because he felt like he had lost control of the project.

"For me, starting a new project was a lot worse than just "disheartening". The SLF4J vote was just the straw that broke the camel's back. After putting many many hours of work into log4j, it became increasingly painful to waste time in arguments, where opinions got asserted by the one writing the longest email. Not fun."

\- [http://mail-archives.apache.org/mod_mbox/logging- log4j-dev/2...](http://mail-archives.apache.org/mod_mbox/logging- email@example.com%3E)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The best part is that these classes are available for use in other JVM languages. I'm more likely to use these from Scala than I am from Java.

<comment><USER11> I was just thinking the same thing. I'm more likely to use them in Clojure. Pretty cool.

</comment></comment><comment><USER12> I can't wait to do code reviews where people are sprinkling parallelSort() all over the place, not understanding the consequences.

Serious question: isn't this something the JVM could abstract away?

<comment><USER13> Good point. There is definitely a challenge of knowing when a single-threaded collection or stream operation may be preferable to the parallel option. When my colleague wrote his summary of Java 8 [1], he wrote:

 _Returning to the concept of parallel streams, it 's important to note that parallelism is not free. It's not free from a performance standpoint, and you can't simply swap out a sequential stream for a parallel one and expect the results to be identical without further thought. There are properties to consider about your stream, its operations, and the destination for its data before you can (or should) parallelize a stream. For instance: Does encounter order matter to me? Are my functions stateless? Is my stream large enough and are my operations complex enough to make parallelism worthwhile?_

The author of the linked InfoQ article (OP) cites that same dilemma by explaining the potential for context-switching overhead to counter the advantage of splitting the work.

Abstracting it away with rough heuristics might be possible, but doing so with consistent success could be challenging. In other words, you could elect to use the serial algorithm for small collections, or when the CPU contention at the start of the sort operation is low. But if the comparison operator is expensive, CPU contention is volatile, or if operating on a stream of unknown length, the abstraction may choose poorly. Ultimately, I like the option to choose for myself, but like you, I wouldn't mind having a third option that defers that choice to some heuristic.

[1] [http://www.techempower.com/blog/2013/03/26/everything- about-...](http://www.techempower.com/blog/2013/03/26/everything-about- java-8/)

<comment><USER3> Good point. Something like

        Arrays.sort(arr, Concurrency.LEVEL)

might have been more flexible. Do I want to use the GPU if available? With which priority should it run, max. performance or more as a background task?

<comment><USER14> GPU won't handle the comparable interface at all. And the memory transfer CPU<=>GPU would be a true killer. It may work on Direct ByteBuffers only but that's entirely a different subject.

<comment><USER3> Is that still true with the new unified memory architecture (hUMA) that AMD introduced? I agree GPUs probably can't handle more complicated comparators well, but Arrays.sort() could optimize at least for the primitive types.

<comment><USER14> hUMA is brand new and no actual support but in order to work properly the CPU has to stall waiting for the GPU.

GPU should be interruptible the same way the CPU is, so if the GC decides to move the memory it can actually do so. The memory can be pinned instead, though. The latter poses some side effects with the GC. If the GPU is not on the same die it will have to virtually copy the array as the L1/L2 caches won't be accessible.

Arrays.sort(somePrimitive[]) would be too much of an edge case to optimize for. Overall hard nut to crack. Java8 streams and direct buffers, however, could be a good starting point to perform various operations via the GPU.

Disclaimer: I am really not well versed in the GPU tech.

</comment></comment></comment></comment></comment></comment><comment><USER15> Wish Android would move in this direction. We're stuck in a 1.6 API for the most part.

<comment><USER16> Google is not going to try and advance Java development. They should just deprecate it and switch to Go. But right now they seem stuck in the middle, not doing either.

<comment><USER15> I really hope they don't. Go is really good for some things, but true object- oriented languages are great for designing and controlling UIs.

<comment><USER17> Hm, I think the way Go uses interfaces would actually be ideal for manipulation of UI.

<comment><USER18> Go also has true closures and easy concurrency support, both of which are very handy in UI development.

My beef with Go is weak web-programming and prototyping support and immature libraries. I'm surprised there's been so much uptake in the Ruby/Python communities, which are very strong in those areas, but I guess Ruby/Python are now being used outside their original domains and those use-cases are pretty ripe for a language like Go.

</comment></comment></comment></comment></comment><comment><USER19> The process control changes might not seem so exciting but they fix some serious pain points, I'm very excited to integrate these into my code.

Optional is another nice addition, I've been creating one myself in all Java projects I've created since I first encountered it in Rust.

<comment><USER20> My problem with Optional<T> is that it basically makes overloaded Java methods impossible because of erasure. I'm worried that it is going to start getting overused; the JDK developers really only intended for its use in the Streams API.

<comment><USER21> Could you explain that a little bit more? I'm using to Maybe from Haskell and am curious what might be missing from Java's Optional.

<comment><USER22> Basically, because of type erasure you cannot have overloaded methods using different Optional types. So test(Optional<A> a); is the same method as test(Optional<B> b);

I think you can define the types to get around it, but that is messy and a PITA. For example, class OptionalA extends Optional<A>.

<comment><USER23> Wow that's a real pain point. Why would they even do that, is there a use case?

<comment><USER19> Backward compatibility - you could run an application that uses generics, introduced in Java 1.5, on a Java 1.4 VM. At the time that was pretty amazing. These days, with so many backward compatibility-breaking changes being introduced, it doesn't feel so great.

<comment><USER24> That was the original plan, but it never worked in my experience. The compiler as shipped required that -source 1.5 use -target 1.5. So hobbling the language this way served no benefit in the end.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> StampedLocks have been talked about extensively at least on jsr-166 mailing list and they required adding load/load barrier in sun.misc.Unsafe. That was the prime reason it needed Java 8, as previously it required a no-op CAS on the load path.

For most people StampedLock will remain quite a mystery as they are harder to use and the vact majority of Java developers doesn't actually write (or even use) low-level concurrency primitives.

<comment><USER25> _" StampedLocks have been talked about extensively at least on jsr-166 mailing list"_

Isn't that the jsr that designed StampedLock and decided to add it to Java? If so, I would hope it was talked about extensively, but I wouldn't see such talk as a counterexample.

<comment><USER14> That's the thing: people who are interested in them (StampedLocks) were already subscribed on the list. Like I've mentioned - outside there is close to no interest on low-level primitives, down to CPU memory barriers.

</comment></comment></comment><comment><USER26> Which companies are running Java 8 already on production?

<comment><USER27> For already having it in production it's too early, but definitely there are companies that have it in near future roadmap. I know couple of them.

<comment><USER28> Why do you think it's too early?

My company is running it on production with no issues.

</comment></comment></comment><comment><USER29> Wouldn't _Mandatory <MyType>_ (or _NonNullable <MyType>_) be better for Java, since all reference types are nullable (aka optional) already...? Haskell's Maybe monad doesn't meet java's specific needs.

It could check for null in its _setValue_ method, at write-time - more useful than discovering it read-time (though I'm not sure it's worth the abstraction).

<comment><USER30> In Scala Option[T] works great, as in libraries people stopped using nulls to represent optional values. And it actually works out when enough people are using it. Plus, if you're unsure about a value you receive (whether it's nullable or not), you can always assume the worst and wrap it in an Optional.

</comment></comment><comment><USER31> Secure random generation is exciting, especially for endpoints.

</comment><comment><USER32> Java the good parts?

<comment><USER33> Already been written, though not updated for Java 8:

[http://www.amazon.com/Effective-Java-Edition-Joshua- Bloch/dp...](http://www.amazon.com/Effective-Java-Edition-Joshua- Bloch/dp/0321356683)

</comment></comment><comment><USER34> No one sees an irony?)

<comment><USER35> How so?

Is it no one is talking about new Java features is because Java isn't the hot new web stack or JS library? Or because most big Java users move to new things with the speed of continental drift?

<comment><USER36> We're a big Java user but apparently faster - our current environment is JavaSE 7 and JavaEE 6. We'll move to JavaEE 7 when there is commercial support for an application server (probably JBoss EAP 7.0.0) and will likely allow Java SE8 at the same time.

We're quite a bit slower at migrating existing applications (except for security issues), but because we code defensively, we are generally backwards compatible.

</comment></comment></comment><comment><USER37> Re Optional<T>:

If I get this right, the source code of the signature of many (many!) methods will now be twice the size of before, unless the names of your types and variables were already considerably bigger than "Optional<...>" (10 chars).

I hope it's worth this cost.

<comment><USER38> Yeah, I hope I am interpreting this the wrong the way. But instead of doing

      X.getA().getB().getC().getD()

we have to

       X.flatMap(X::getA)
        .flatMap(X::getB)
        .map(X::getC)
        .orElse("UNKNOWN");  //[1]

Not sure why this is going to be better?

[1] [http://www.oracle.com/technetwork/articles/java/java8-option...](http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html)

<comment><USER39> That's not a fair comparison, as the flatMaps are eating nulls (really Optional.empty()s) while the naked calls will throw NPEs. The equivalent code for the first case is:

      String result = "UNKNOWN";
      T a = X.getA();
      if (a != null) {
        T b = a.getB();
        if (b != null) {
          String c = b.getC();
          if (c != null) {
            result = c;
          }
        }
      }

Optional (like Scala's Option or Haskell's Maybe) are useful because they force you to reason about "empty" cases. Whereas in typical java code there is no way for the compiler to force to you handle the possibility of nulls (thus leading to NPEs), Wrapping a type in Optional forces you to deal with the case where the result is not present, leading to more correct programs. Plus, it gives you handy tools for dealing with non-present values, like allowing a chain of computation--any step of which may fail--without needing failure checks on every step.

</comment></comment></comment><comment><USER40> > The difference between this and the old Atomics is that here, when a CAS > fails due to contention, instead of spinning the CPU, the Adder will store > the delta in an internal cell object allocated for that thread.

Wow man Java's still all in with it's terrible threading mechanism all the while C# has had async, await and parallelism for years, Go is well past version 1 to great acclaim, node.js and libuv are taking over, and Akka has gained enormous popularity and yet real coroutines in Java aren't even on the horizon. Even python 3 is getting coroutines.

Low level threads in Java are so goddamned awful and unavoidable that it makes me want to pull my hair out. And I otherwise love Java. Java would be so awesome with real, native coroutines. Like that should be only thing they should be working on right now.

Edit:

I'm guessing the people downvoting this have no idea what I'm talking about and don't know what coroutines are.

You know I'm starting to think there's maybe an entire generation of Java engineers who have no idea how much easier it is to write concurrent code with other tools and Java has ruined them. I love Java, but expand your horizons a bit.

<comment><USER30> > _C# has had async, await and parallelism for years_

For Scala developers, there's Scala Async, which is exactly what C# "async" is, implemented as a library: [https://github.com/scala/async](https://github.com/scala/async) \- plus Scala's `Future[T]` has a better design than C#'s Task.

> _node.js and libuv are taking over_

And both suck in comparison with Java's NIO and the libraries that have been built on top of it.

> _Low level threads in Java are so goddamned awful and unavoidable that it > makes me want to pull my hair out_

Low level concurrency primitives are necessary for building higher-level abstractions on top. For example I need low level concurrency primitives for implementing a Reactive Extensions (Rx) implementation that does back- pressure: [https://github.com/alexandru/monifu/](https://github.com/alexandru/monifu/)

> _the people downvoting this have no idea what I 'm talking about and don't > know what coroutines are_

You're assuming too much.

<comment><USER41> _plus Scala 's `Future[T]` has a better design than C#'s Task_

Why? The one issue I have with Task is the aggravating SynchronizationContext/continueOnCapturedContext. ConfigureAwait(false) really should have been the default. Otherwise, my experience with both seems about equivalent.</comment></comment></comment>


Living on the Plateau - <AUTHOR> http://blog.cleancoder.com/uncle-bob/2017/11/18/OnThePlateau.html <comment><USER2> Very thought-provoking article. Loved it. I think there are a couple of positive side effects to our functional programming fascination in preparation for a more parallel future (that may come much later than we thought).

1) Emerging languages tend to be safer, statically typed, and although not functional, they generously borrow from their functional siblings.

2) They tend to have more focus on performance. We didn't go from Python/Ruby to an even higher level and slower family of languages.</comment>


Striving for Simplicity in Off-Policy Deep Reinforcement Learning - <AUTHOR> https://arxiv.org/abs/1907.04543 <comment><USER2> I wrote a quick summary on /r/reinforcementlearning: [https://www.reddit.com/r/reinforcementlearning/comments/cc9g...](https://www.reddit.com/r/reinforcementlearning/comments/cc9gnh/striving_for_simplicity_in_offpolicy_deep/etlgebd/)

</comment><comment><USER3> This is a dense read, and I will have to spend a lot of time on it, but is it really surprising that Atari can be learned from 50m events? This isn't a real domain, and it's not a complex domain and it's not a domain that synthesises the challenges of real domains (for example noise between the control input and outputs, noise in the sensors, dynamism in the domain)

That's ok - but let's not conflate "learning Atari" and "reinforcement learning"</comment>


ZeniMax files lawsuit detailing claim to stake in Oculus VR technology - <AUTHOR> http://arstechnica.com/gaming/2014/05/zenimax-files-lawsuit-detailing-claim-to-stake-in-oculus-vr-technology/

<comment><USER2> So, Carmack (cofounder/CTO of Id Software, later acquired by Zenimax) is basically being used by Zenimax as the justification for raiding Oculus.

This is really troubling, least of all because a) Carmack _built_ the fucking 3D games industry nearly by himself and b) used the freedom of his position to work on interesting new technology.

There's got to be some way the rest of us can protest this, because this has really, really bad precedent for any of us that want to work on interesting projects for the hell of it. This is terrihorribad.

<comment><USER3> Stop buying ZeniMax games. There isn't any other great recourse in this situation (other than the much larger picture goal of fixing the patent & copyright systems).

Carmack should have known better, and should have been a lot more careful. That isn't to say he's to blame for the shitty context of our intellectual property system. Once he sold id to ZeniMax, he was then working for a standard issue big company (as far as the gaming industry goes). I think he failed to adjust his behavior to that reality.</comment></comment>


A rose by any other name would smell as sweet - <AUTHOR> https://vincentsanders.blogspot.com/2017/03/a-rose-by-any-other-name-would-smell-as.html <comment><USER2> All large code bases smell.. and some of them reek. I've never once in my life encountered a consistent code base and I reckon that I'm not alone here. The only pleasant code is the one you wrote yourself.

Everything goes down the drain once you get dozens or even hundreds of people involved. Ask any dev at Microsoft, Apple, etc.. they all push crap code, but it somehow does the job... and in the end it doesn't really matter.</comment>


Ask HN: isn't naming a company the same as its product a mistake today? - <AUTHOR> I mean, knowing the lifespan of products today, most companies will have to conceive other products to survive more than ten or twenty years, no? Remember Apple Computer. <comment><USER2> Ultimately it is the product you market, not the company. But consumer services can be OK with a common name if that helps a startup cut through the clutter. (and it will just be the product name anyway after you are acquired ...)

Relatedly, you can use the company name as part of product name for products (Company ProductA, Company productB), this can help you with trademarks and avoiding problems with others when you want your product name to be descriptive but it would be otherwise generic w/o your company name as part it.

</comment><comment><USER3> I think it's better to name the company differently from the product, but using the same idea. For instance: my startup is called SimplCloud and it is about creating products for DevOps. The first product is called SimplDS (for Deplyment Service) and I can continue with this scheme.

</comment><comment><USER4> If you don't have a viable product, it doesn't matter.

If you have a viable product, you can sort it out.

</comment><comment><USER5> no. Chock full of nuts sells lots of coffee these days and no nuts. <http://www.chockfullonuts.com/> (warning: flash heavy site)

</comment><comment><USER6> Doesn't seem to be a problem for Google.</comment>


Bye-Bye, Batteries -  Radio Waves as a Low-Power Source - <AUTHOR> http://www.nytimes.com/2010/07/18/business/18novel.html?_r=1&src=twr <comment><USER2> Should I be considering this differently from solar? They're both harvesting ambient EM radiation; and the energy density of solar is much higher. I guess that radio goes through walls and never sleeps, so that's a plus. Anyway, I thought that the mentioning of a solar calculator was quite appropriate and warranted further discussion.

<comment><USER3> It sounds like the device on the hard hat is more like a passive RFID chip; It's hard to be sure, but the article says all the dangerous equipment has transmitters of their own.

Of course, the effective difference between the passive RFID chip and a device that simply consumes ambient radio-spectrum EM radiation is small, mostly a paradigm change.

Your initial question begets an interesting question- since light is EM radiation, just like radio waves, shouldn't we be able to pick up light with an antenna? If we can figure that out, we can forget about solar cells with their sad efficiency levels.

edit: with some quick research, the answer is obvious; while it seems extremely weird to imagine, light can be absorbed by an antenna- and the first and foremost reason this isn't being done already is because the appropriate antenna would be ~700 nanometers long.

<comment><USER4> You can absorb EM radiation just fine with an antenna that's "too long". It's when it's too short that you run into problems.

500nm-wavelength light oscillates at about 600 terahertz, with a period of about 1.7 femtoseconds. If you want to rectify that and turn it into DC current so you can run current semiconductor devices, you need a diode that can switch on once and off once in that period of time. So your forward recovery time plus your reverse recovery time needs to total less than 1.7 femtoseconds. Among other things, I think this implies that the depletion region in the diode needs to be less than 0.9 femtoseconds in width --- at the electron drift velocity of the semiconductor, which I think is typically around 12 orders of magnitude less than c, although in silicon it can be as high as only three orders of magnitude less than c. Which means that your depletion region needs to be 3 orders of magnitude smaller than the wavelength. Unfortunately the wavelength we're talking about here, at around 1000nm, is only four orders of magnitude bigger than a smallish atom, at 0.1nm. So you're pushing up against the bounds of possibility here with an insulating depletion region of a few atoms in thickness.

Forward and reverse recovery times for silicon diodes vary widely. Typical values for discrete components are measured in the tens to hundreds of nanoseconds. Schottky diodes bring that down to tenths of nanoseconds. One nanosecond is one million femtoseconds, so that's still five orders of magnitude too slow.

Anyway, I don't know anything about this stuff, really.

<comment><USER3> Seems like it'd be easier to just drive a 600 terahertz motor, if such a motor can be made, and use that to drive a good old fashioned 60hz generator.

The silicon would be a much nicer solution though. Thank you for the details on the diodes, I forgot about that part. You're probably right on the diodes being the hold-up.

<comment><USER4> Now that's an interesting idea. The light contains an oscillating magnetic field that you could use directly to spin a permanent magnet, if you had one that was small enough. (Any atomic nucleus would do, but you can't connect a shaft to it.) Maybe you could build a multipole nanomotor so that the rotor itself doesn't have to spin at 600THz; if you have 100 poles, which is not that far out of what people commonly do with macroscopic stepper motors, then you could get the rotation down to only 6THz. (But then you're only potentially absorbing light at the rim of this rotor.)

Gearing that down to 60Hz at the nanoscale — without losing most of the energy to friction — could still be a significant challenge. I don't know of any hundred-billion-to-one gearboxes.

The basic difficulty with the nanomotor approach, I think, is that electrons are lighter than nuclei, so it's easier to get them to oscillate over useful distances in any particular frequency range, and this is especially tricky in the terahertz to petahertz frequency range. A nucleus, under the influence of the same electrical field as an electron, will accelerate about three or four orders of magnitude more slowly.

Ultimately this should be a scale advantage for mechanical computation, since it means you can localize an atom to a much smaller region, given a certain momentum uncertainty, than an electron. The atom can't tunnel as far, so it can store a bit reliably in a much smaller region. I don't think we're there yet.

<comment><USER3> Is it necessary to make it a nanomotor? Friction is not a concern once you have things suspended by magnets in a vacuum. If power is an issue for driving the larger rotor, instead of using just one antenna use an array. It's typically better to have one giant Engine than many small ones.

Forget gearboxes, a belt drive would be superior until you start cranking out huge power, and in that case you could try chains instead. Also, don't forget that a 60hz motor does not have to spin at 60rpm to generate 60hz.

<comment><USER4> The difficulty with making it larger than nanoscale is that the centripetal acceleration becomes very great, which makes holding a large rotor together tricky; you need very strong materials. Actually, I did the calculations, and for visible light, it isn't even feasible at the nanoscale.

The centripetal acceleration of the rim of a rotor of radius r is rω². Rotating at 600THz (i.e. 600 trillion rotations per second), ω = 600T2π/s ≈ 3.8 × 10¹⁵/s. If your radius is 1mm, then your acceleration is about 1.4 × 10²⁷ G. The smallest rotor you can make out of atoms is probably around 0.1nm, which reduces the acceleration to only about 1.4 × 10²⁰ G. If your rotor was, say, an orthohydrogen H₂ molecule, with a distance between the nuclei of about 62pm, and thus a radius of about 31pm, the acceleration is about 4.5 × 10¹⁹ G, which would be a weight of about 74 micrograms pulling on that single covalent bond. The nuclei would be whirling around the covalent electron cloud that bound them together at about 11.7 kilometers per second, and each of them would have about 1.13 × 10⁻¹⁷ J of kinetic energy. Unfortunately, hydrogen's ionization energy is about 2.2 × 10⁻¹⁸ J, so that's about five times as much energy as you'd need to rip the molecule apart. I think. It could work out in the infrared, maybe. You'd just need a way to get the molecule started spinning.

So I guess you'd have to make your rotor a lot smaller than a diatomic molecule, or a lot stronger than a mere covalent bond.

Generally a 60Hz generator must spin at 360rpm _or slower_ to generate 60Hz.

<comment><USER4> Um, 3600.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> important bit: simple processing & sound using _ambient_ radio waves in a construction hat. Which is _very_ cool. Other cited uses cover small temperature sensors and possibly replacing AAA battery powered devices.

Add in a healthy dose of sparkly-futurist-hope (devices that run FOR EVAR), and some actual data on another experimental device:

> _The device collects enough power to produce about 50 microwatts of DC > power, Dr. Smith said. That is enough for many sensing and computing jobs, > said Professor Otis. The power consumption of a typical solar-powered > calculator, for example, is only about 5 microwatts, he said, and that of a > typical digital thermometer with a liquid crystal display is one microwatt._

Didn't see anything on the size of the "device", but that's still pretty cool.

</comment><comment><USER6> Didn't Tesla claim to have developed wireless power a long time ago. Those more familiar with Tesla/Physics ... is this the same technology?

<comment><USER7> The technology in the linked article would appear, at least superficially, to be similar to RFID. Although one difference might be that RFID works at a fixed frequency (to match the harmonic frequency of the receiving radio circuit) whereas this apparently works with "ambient" radio, implying a broad spectrum of frequencies, which is quite clever.

Either way, the broadcast signal is losing power at a rate proportional 1/d^2. So these devices necessarily have to work at very low power. What Tesla did - or is supposed to have done - was to figure out how to transmit power without the 1/d^2 loss. I.e, much like a collimated laser beam, he could transmit power over large distances and power high current devices.

<comment><USER8> It is interesting, that we are only now scratching on the surface of what Tesla did 100 years ago.

<comment><USER9> There is no kidding that he was off the charts brilliant, but he was also - especially towards the end - insane.

That is why it is so hard to figure out what Tesla actually did or didn't do.</comment></comment></comment></comment>