Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

HTTP is a truly messy protocol, and from what i have seen the proposals for HTTP2 aren't going to make it much simpler, quite the contrary (as the author of Varnish explained here: http://news.ycombinator.com/item?id=4253538 ) and don't address some of its fundamental flaws.

I have been thinking for a while about writing down a simple and small subset of HTTP plus some conventions and call it HTTP 0.2, I even got a pre-draft (hah) of what the goals for such a spec would be, maybe i should start to work on it again: http://http02.cat-v.org



HTTP has its problems, but implementing it is a walk in the park compared to many other telecom protocols. Try SIP and its dozens of add-on RFCs, or tracing a H.323 call flow, or even making sense of something like Megaco from the ITU/IETF spec.


Cool idea. Less is more. People have done cool things, e.g., with C by retsricting themselves to a subset of it.

It seems counterintuitive but I think reducing the number of features in a spec, a language, etc., actually gives way to _more_ creativity.

Indeed, it seems "too much freedom/lack of limitations" in the HTTP spec appears to be the underlying condition that fuels Antill's rant.

(And, funnily enough, an article about the "tyranny of choice" serendipitously appears on the HN simulatneous with this one. I didn't notice it until _after_ I typed this comment.)


There is also Rob Pike's excellent post titled "Less is Exponentially More":

http://commandcenter.blogspot.nl/2012/06/less-is-exponential...


It's not counter-intuitive at all. What is architecture if not a set of constraints?


So how do we convince programmers (architects?) to use languages and programs that are small, which due to lack of features appear to have lots of restraints? (really they don't; but one needs to be creative) How do we produce specs that are not the result of committees and packed with everyone's favorite feature? (and thereby masochistic for any mortal to try to implement)

See the 1999 interview with Ken Thompson that luriel posted earlier. It has some great comments about these dynamics.

When I say "counterintuitive", I am referring to most programmers, judging by what's said in forums like this one, will _not_ be receptive to perceived restraints. They will believe it limits what they can do. Instead, they will see a langauge where there are multiple ways to do the same thing with the same effectiveness as somehow more flexible, making them more productive. They want hundreds of libraries. They want IDE's. They do not want to write things in Scheme. Some even hate the command line. I say these things about "most" programmers. Not all. (thankfully)

Again, Thompson's comments are insightful here. Many programmers are cogs in a corporate wheel. They have little opportunity to be creative. They want to save time and effort in any way possible.

But some people, the increasingly rare few, will see things differently. I side with Thompson's preference in that I cannot understand large languages where I have to work from the top down and read a 500 page manual to try to understand all the components. I cannot manage that degree of complexity as easily as I can I can work with something simple and build things from the bottom up. (Alas, the things I can build do not amount to a UNIX kernel! :)

So, yeah, it's not counterintuitive to me. It makes perfect sense. But I don't find myself agreeing with most comments about these issues I see in forums. I can't even read StackOverflow. The herd mentality is overbearing.


Perhaps that's why he said "It seems counterintuitive..."

If he thought it was counterintuitive, then he would have said "It is counterintuitive..."


lol.. just saw this. I would modify my statement for your pedantic approval if I was able.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: