5 ms·

"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 s

"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 http://foo/bar. It took me all of a few seconds to start using wget and all of 10 minutes to have access to fancier features. (But the truth is that a certain level of complexity really just wants a script rather than ad hoc commands). So here is a new tool, and it looks nice. But it doesn't at all relieve me from having to learn syntax and conventions - I still have to go to a doc/manpage and read that same kind of technical prose. So the only effective difference is that now I am using different punctuation, like @filename and -b. But the use of this "@" character is not really consistent with anything else. So the tool is fine and I am sure people will use it but the competitive advantage is incredibly thin and the project smacks of NIH. If curl and wget are not for humans then what are they for? People who do not have that magical design sensibility. Lame code-monkeys without vision, who are not creative and different. Soulless agents of the man. This emphasis on branding over substance irks me quite a bit.

maratd 14y ago
> 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).
- TylerE 14y ago
  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=>"<password string>", 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.
  - manuletroll 14y ago
    On the other hand I guess you could probably write a nice library that uses curl under the hood, here it's just a case of ugly design.
    - rmccue 14y ago
      Indeed, I do exactly that: http://requests.ryanmccue.info/ http://requests.ryanmccue.info/ I completely agree on cURL's design though. It's painfully obvious when working with the cURL bindings in PHP that it didn't have much thought put in to adapting it to PHP's constraints and is essentially just the command line client in a "nice" wrapper. It ends up being a huge pain to work with.
javajosh 14y ago
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 the population of future users, is a few lifetimes. Rather than admit that even incremental usability improvements are not only useful, but continue to pay dividends long after the tool is produced, you lambast the author and the effort. Not cool. P.S. You should watch Bret Victor again, talking about how much easier it is to crush an idea than to support it and nurture it. http://vimeo.com/36579366 http://vimeo.com/36579366
- slurgfest 14y ago
  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.
  - espeed 14y ago
    curl's interface is a PITA for testing JSON APIs. HTTPie's isn't: http POST http://localhost:3000/person/create name="James" The "for humans" bit signifies the author has taken care to simplify the interface for practical use, rather than for shell scripting.
    - jtheory 14y ago
      Yup, I was excited to see that. I have a text file with examples of testing different kinds of API calls w/ curl, and I have to refer to it all the time because the syntax is so easy to get wrong if I just type it out. I've also had to waste lots of time supporting other developers using our API, who got tangled up in the curl syntax in the examples I provide them.
azinman2 14y ago
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&ctab=0&geo=all&date=all&sort=2 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.'
pqdbr 14y ago
I couldn't disagree more. I wish I could disagree more, tough. Your comment shows a complete disregard for User Experience and User Interface, and this disregard is the reason why so much stuff simply "sucks" nowadays.
deleted 14y ago
[deleted]

maratd 14y ago

> 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).

TylerE 14y ago
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=>"<password string>", 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.
- manuletroll 14y ago
  On the other hand I guess you could probably write a nice library that uses curl under the hood, here it's just a case of ugly design.
  - rmccue 14y ago
    Indeed, I do exactly that: http://requests.ryanmccue.info/ http://requests.ryanmccue.info/ I completely agree on cURL's design though. It's painfully obvious when working with the cURL bindings in PHP that it didn't have much thought put in to adapting it to PHP's constraints and is essentially just the command line client in a "nice" wrapper. It ends up being a huge pain to work with.

javajosh 14y ago

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 the population of future users, is a few lifetimes. Rather than admit that even incremental usability improvements are not only useful, but continue to pay dividends long after the tool is produced, you lambast the author and the effort. Not cool. P.S. You should watch Bret Victor again, talking about how much easier it is to crush an idea than to support it and nurture it. http://vimeo.com/36579366 http://vimeo.com/36579366

slurgfest 14y ago
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.
- espeed 14y ago
  curl's interface is a PITA for testing JSON APIs. HTTPie's isn't: http POST http://localhost:3000/person/create name="James" The "for humans" bit signifies the author has taken care to simplify the interface for practical use, rather than for shell scripting.
  - jtheory 14y ago
    Yup, I was excited to see that. I have a text file with examples of testing different kinds of API calls w/ curl, and I have to refer to it all the time because the syntax is so easy to get wrong if I just type it out. I've also had to waste lots of time supporting other developers using our API, who got tangled up in the curl syntax in the examples I provide them.

azinman2 14y ago

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&ctab=0&geo=all&date=all&sort=2 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.'

pqdbr 14y ago

I couldn't disagree more. I wish I could disagree more, tough. Your comment shows a complete disregard for User Experience and User Interface, and this disregard is the reason why so much stuff simply "sucks" nowadays.

deleted 14y ago

[deleted]