javascriptlol

Caching at the architecture level has caused more problems than it has solved. How many times have you heard the phrase "empty your cache, then try again..". Utterly stupid. This is an optimisation that should be implemented by the application designer as needed, and if it is within their capabilities.

It will still be hideously slow on the first run due to overheads.

So what you're admitting is that REST doesn't add any new novelties in terms of being discoverable?

I am not interested in what Alan Kay has to say. I asserted that you specified a bunch of design constraints. You did. You tried to counter by pointing out that it's just OO design. However, I'm not interested in arguing over what categories things fit into. The point is that the network imposes limitations and you often need a domain-specific design to get around them. For example, HTTP is awful for soft real-time applications.

I don't see any reason why SOAP can't support dynamically changing sets of procedure calls. Furthermore, I think that is a bad idea since it will break backward compatibility. No amount of web-buzzwording will get around that problem.

Using REST over a real network is not equivalent to object-oriented programming. Don't be asinine.

You put XML and REST in different categories. So what? They are both attempts to provide systems interoperability for a huge domain. What we go out of XML: some ability to browse the format with standard tools, and some human-readability . That is all we will get out of REST. If that's the point, so be it. If you want to use it, so be it. I might use it for some projects. However, to put it forward as something new and special is being willfully ignorant of history.

>Similarly, to suggest that HTTP hasn't proven itself (compared to what?)

Compared to writing your own protocol that is appropriate for your application. The fact that people think HTTP is good enough has meant the browser has only recently acquired the ability to have a proper duplex channel without polling. Sorry, but that's just pathetic.

>or that "innovations" of the web existed decades ago (really!?) is nonsensical to me.

Name one thing that can't be constructed more efficiently and flexibly on the desktop, aside from web links.

>It's the most widely deployed application protocol on Earth. It handles billions of dollars of transactions.

So what? Because it's popular that means it's good? I used to be dismissed because as long as 7 years ago I was telling people we needed sockets and proper client/server in the browser. Now I'm getting the last laugh as I watch the browser vendors take decades to slowly do this stuff. At each step, it is labeled "innovative" and interesting and hyped up beyond all comprehension. The progression of this trend is retarded by the insistence of inventing stupid premature optimisations like caching as a basic architectural feature.

>You claim the web is unreliable. I think that's a layer error. The issue is that networks are unreliable. That's not something one can paper over.

Then you're ignorant of the potential of low-level protocol design. Sorry, but I absolutely can tailor my network protocol to my particular application. The web takes the position that everyone should use HTTP. It is a terrible protocol for many things. How are you going to design your soft real-time applications using HTTP? The answer is you can't, because it is impossible to get the right guarantees. HTTP has only "proven itself" in the same sense that Windows has; it was good enough at the time, so now it's blown up and everyone's using it. So what? I want more.

Are you saying SOAP won't tell you it doesn't understand if you send a bad message?

Except HTTP hasn't proven itself, except to a growing set of specialist programmers who don't know any better. The web is hideously unreliable. People have become accustomed to reclicking links and reloading pages. Aside from hyperlinks, the only "innovations" of the web already existed in a more efficient form in operating systems decades ago.

As for REST, I'm sure it's nice for some things. However, if you think interoperability is going to magically spring out of it you're ignoring the lessons of XML, which that having an (ostensibly) human-understandable format is not going to magically allow machines to become more interoperable. All it will do is allow people to make bad guesses about the meaning of documents instead of reading the documentation.

You just described a bunch of design constraints. The basic OS facilities and the design of the Internet already make some design decisions for you. REST is adding more. That is designing things up front. People said the same thing about XML, and of course it's only advantage is some level of self-documentation (that is going to break down pretty quickly when things get complicated).

This just sounds like a repeat of XML and similar debacles, where people tried to address design decisions outside the problem domain. XML is no more interoperable than a well-documented binary protocol. I'm sure REST is great for some applications, but this attitude that we can do all our design upfront is bad for the web. I mean, the browser just recently rediscovered interrupt-driven programming with the introduction of websockets. That's pretty embarrassing if you ask me.

EU bans claim that water can prevent dehydration:

http://www.telegraph.co.uk/news/worldnews/europe/eu/8897662/...

Let's not forget about the browser vendors who, instead of providing a sensible layered operating environment for web applications, foist a ridiculously high-level API for development upon programmers. Javascript and the DOM are not suitable bottom layers for real systems programming. These monoliths will never be secure. Take WebSockets: finally bringing non-polling networking to Javascript decades after it was obviously needed, and in a tragically "web-like" form (mandatory UTF8 encoding). HTML5 storage: a dictionary of strings. What? Who designs this bollocks?

You can assert that the government "has to" do these things, but I do not believe you can substantiate that point. I don't think NNT can prove that things would be better without government intervention, either. However, there is an important general point here about kinds of fragility that are being built into society. I think it will (sadly) go ignored while people argue about fiat currency, quantitative easing and other magic cures.

There is disagreement about what steps central banks and others should take to control the economy. NNT thinks the Federal Reserve is incompetent, for example. I don't know whether he's right or not, but the point of view being expressed is not against central banks, regulation or interventions. It's against the necessity (perceived or otherwise) of these things to keep things running.

You have misinterpreted this completely. The linked PDF doesn't mention fiat currency once. NNT says a lot of bullshit, but it's amazing how willing people are to comment without even reading the paper and taking some time to reflect upon it.

Taleb would call you a "nerd". I think he'd be right.

edit: FWIW he'd probably say the same about me.

You've missed his point. He's not arguing that people should not assess their confidence before investing. He's arguing that the government should not need to prop up confidence. The comparison to Ponzi schemes is because he believes (rightly or not) that many of these interventions are not sustainable.

The problem with JavaScript targets is not the terminology, but how bad the design of the whole web stack is. It's like watching people badly redesign operating systems in the browser, every so often catching up to something that was solved 20+ years ago on the desktop. Painful.