HTTPie: A cURL-like tool for humans • Hacker News Board

Re: HTTPie: A cURL-like tool for humans

#41

Post by benatkin » Wed, Jul 18, 2012, 6:58 PM UTC

slurgfest wrote: post #36

benatkin wrote: post #20

Earlier quoted context omitted.

I don't think it's the most obvious kind of good UX, but rather good UX for people who value expressiveness, like ruby programmers. The items that change meaning based on symbols are quick to type, but it comes at the cost of clarity. curl's paramters aren't very clear either, and since it supports more than just HTTP, it's harder to go through the man page with all that it supports. I think there's still room for on…

It is UX with the inflection of Apple's Human Interface guidelines, which have always been a mix of technical guidance and branding/marketing guidance (as opposed to pure, wonky, research-based, specifically tailored ergonomics, which defines usability relative to specific tasks and audiences, some of which may be highly technical and appreciate complex tools). Apple discovered that words like "usability" and "human"…

You've done a wonderful job of expressing my sentiments on this issue. What annoys me even more is the degree to which projects like Gnome copy Apple's design decisions that make their tools less effective for "Power Users".

By the way, the "Power Users" term is used to marginalize people who are willing to learn to use their tools. The results of using this term in this way have IMHO slowed the growth of the computing industry.

Re: HTTPie: A cURL-like tool for humans

#42

Post by zeroonetwothree » Wed, Jul 18, 2012, 7:00 PM UTC

jkbr wrote: post #24

jcromartie wrote: post #12

If by "for humans" you mean "for programmers who mostly use JSON". I have to say I'm not sending JSON with cURL too often, compared to any other payload. And when I do send JSON it's more complex than a flat set of keys and values.

There is more to it than that. It provides an expressive syntax to construct all sorts of requests. You can submit forms, upload files and set headers without having to use flags. You also get syntax highlighting, ability to pipe in request data, etc. If you are sending complex JSON, it's probably stored in a file or it's the output of another program: http PUT httpbin.org/put @/data/test.json http -b localhost:8888/…

I don't really think curl is much harder, e.g.

curl -X PUT -d @data/test.json httpbin.org/put

It also has the advantage that it supports all the options you might ever need, for example http authentication and proxies are often useful.

Re: HTTPie: A cURL-like tool for humans

#43

Post by chernevik » Wed, Jul 18, 2012, 7:08 PM UTC

javajosh wrote: post #34

This is a nice curl and wget replacement that handles a bunch of modern use-cases without a lot of hard-to-remember command-line flags. That said, there is a broader problem of "hard-to-remember command-line flags" which I have personally solved using snippet management (I use notational velocity or command history, whichever is handiest). There is no doubt httpie's interface is a lot better, but it creates another p…

DELETED

This was a warning of a hazard to navigation, when a more diligent effort to remove the hazard is called for.

Re: HTTPie: A cURL-like tool for humans

#44

Post by slurgfest » Wed, Jul 18, 2012, 7:14 PM UTC

javajosh wrote: post #38

slurgfest wrote: post #33

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

Gosh, what a horrible comment! The simple fact is that curl and wget's interfaces are bad, and everyone who learns to use them spends that 10 minutes. And then, if you're like me, respends that 10 minutes when I need to do something fancy again. If a new tool were to save 5 minutes (which this one does), that's 5 minutes saved on every use, which is probably a total of a few hours for me personally, and spread over t…

All the competing tools are not "for humans." Who are they for, then? If you don't see the negativity in that sales pitch (and your own complaining about other people's creations, which were also the products of hard work) then I don't think you are being honest with yourself.

If this tool actually didn't require me to go to a man page and read lots of flags (.... exactly like every other tool) then I might be more enthusiastic about its advantages. But I don't see advantages. I just see yet another tool. Well, that's fine... use what you want. But I don't agree that it is superior in any clear way, and that's really all I said.

People who are really capable can handle and learn from critique and don't require constant sugarcoating because their minds are more at the level of problem solving than ego defense.

Re: HTTPie: A cURL-like tool for humans

#45

Post by TylerE » Wed, Jul 18, 2012, 7:19 PM UTC

maratd wrote: post #37

slurgfest wrote: post #33

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

> Most humans don't operate the command line or write scripts to begin with. I'm not a huge fan of cURL, but most people who use cURL don't use the command line either. They use the cURL library and access that functionality through a high level language (PHP, C, C++, whatever).

That's true, but it's no better there, either.

Here's some sample curl client code in PHP.

      $c = curl_init("https://someurl/some/api");
      $msg = /* some data here */
      $opts = array(
        CURLOPT_POST=>TRUE,
        CURLOPT_USERPWD=>"",
        CURLOPT_HTTPHEADER=>array("Content-type: application/json"),
        CURLOPT_POSTFIELDS=>$msg,
        CURLOPT_SSL_VERIFYPEER=>FALSE,
        CURLOPT_RETURNTRANSFER=>TRUE
      );
      curl_setopt_array($c, $opts);
      $d = curl_exec($c);
      curl_close($c);

Every option in that ugly argument array corresponds directly to a commandline option.

Re: HTTPie: A cURL-like tool for humans

#46

Post by javajosh » Wed, Jul 18, 2012, 7:22 PM UTC

chernevik wrote: post #43

javajosh wrote: post #34

This is a nice curl and wget replacement that handles a bunch of modern use-cases without a lot of hard-to-remember command-line flags. That said, there is a broader problem of "hard-to-remember command-line flags" which I have personally solved using snippet management (I use notational velocity or command history, whichever is handiest). There is no doubt httpie's interface is a lot better, but it creates another p…

DELETED This was a warning of a hazard to navigation, when a more diligent effort to remove the hazard is called for.

>on at least some occasions the Python client gets non-standard results, while curl and (Guido, forgive me) PHP do fine

Ok, young one, here's the thing. If you see a problem like this then file a bug. Ideally write a test case. And if you're an overachiever, dig into the code and fix it. Any bug in an http client that reposts data is incredibly serious, and needs to be fixed.

The other value in doing this is that you don't spread Fear, Uncertainty, and Doubt - or FUD as it is often referred to. FUD is usually ascribed to big companies trying to discourage using a competitors product, but it can also be spread by the ignorant or misinformed inadvertantly. No offense, but I think that's the case in this case, because Python is not a niche language, it's used (and it's http libraries are used) by a lot of people, and the error mode you describe is very, very serious.

Re: HTTPie: A cURL-like tool for humans

#47

Post by azinman2 » Wed, Jul 18, 2012, 7:24 PM UTC

slurgfest wrote: post #33

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

You're totally off here. curl,wget, etc are tools that make overly complicated the most common use cases. There are 900 million command line flag options, so figuring out how to do a post & set a particular header can be 10 minutes. 10 minutes is an awfully long time for learning how to perform an HTTP request! At least on the github page I can learn the 5 things I'd actually want to do in about 3 seconds. And it colorizes the json output to make it more legible? Sweet. That's called productivity.

Interestingly enough, people seem to search for curl tutorials much more than wget: http://www.google.com/trends/?q=curl+tutorial,+wget+tutorial...

Having something that makes life easier with less complication IS what tools are all about. That's called evolution. Why have the web when you could have gopher? Because it's _better_, even if you can 'accomplish the same things.'

Re: HTTPie: A cURL-like tool for humans

#48

Post by azinman2 » Wed, Jul 18, 2012, 7:25 PM UTC

javajosh wrote: post #46

chernevik wrote: post #43

Earlier quoted context omitted.

DELETED This was a warning of a hazard to navigation, when a more diligent effort to remove the hazard is called for.

>on at least some occasions the Python client gets non-standard results, while curl and (Guido, forgive me) PHP do fine Ok, young one, here's the thing. If you see a problem like this then file a bug. Ideally write a test case. And if you're an overachiever, dig into the code and fix it. Any bug in an http client that reposts data is incredibly serious, and needs to be fixed. The other value in doing this is that you…

+1. Probably curl also had bugs before (and still does). These get fixed over time, but that doesn't mean improving the interaction isn't worthwhile in the first place.

Re: HTTPie: A cURL-like tool for humans

#49

Post by benatkin » Wed, Jul 18, 2012, 7:25 PM UTC

javajosh wrote: post #38

slurgfest wrote: post #33

"for humans" seems to have no better meaning than "for the OS X sensibility". In other words: this is a style change rather than a productivity gain. And the superiority of the style is not obvious - unless you just HATE the style of existing tools and need to be set apart. Most humans don't operate the command line or write scripts to begin with. Those who do, usually can handle wget " http://foo/bar . It took me al…

Gosh, what a horrible comment! The simple fact is that curl and wget's interfaces are bad, and everyone who learns to use them spends that 10 minutes. And then, if you're like me, respends that 10 minutes when I need to do something fancy again. If a new tool were to save 5 minutes (which this one does), that's 5 minutes saved on every use, which is probably a total of a few hours for me personally, and spread over t…

Your comment is an ad hominem attack where you falsely accuse someone of making an ad hominem attack.

Re: HTTPie: A cURL-like tool for humans

#50

Post by chernevik » Wed, Jul 18, 2012, 7:34 PM UTC

javajosh wrote: post #46

chernevik wrote: post #43

Earlier quoted context omitted.

DELETED This was a warning of a hazard to navigation, when a more diligent effort to remove the hazard is called for.

>on at least some occasions the Python client gets non-standard results, while curl and (Guido, forgive me) PHP do fine Ok, young one, here's the thing. If you see a problem like this then file a bug. Ideally write a test case. And if you're an overachiever, dig into the code and fix it. Any bug in an http client that reposts data is incredibly serious, and needs to be fixed. The other value in doing this is that you…

No offense taken.

I did report this to the API maintainers, who couldn't make heads or tails of it. I didn't file a Python bug because I honestly don't think Python is the problem.

But you are right, it is more responsible to pursue this until fixed rather than raise warnings.