5 ms·

Right, let's take the human denomination away from people that use cURL...

by partycoder 10y ago

NegativeLatency 10y ago
This tool pops up every few months, not sure why anyone would use it over curl
- peterwwillis 10y ago
  If this had been made an interface to libcurl, or added to a separate tool in the curl distribution, most of the novel functionality could have been adopted 3 years ago without the need to support a separate project and HTTP library.
  - scrollaway 10y ago
    What do you mean? libcurl is as much a separate project/library as requests is, and this uses requests.
    - peterwwillis 10y ago
      Rephrase: If this was implemented with libcurl and bundled with cURL it would no longer need to exist as a separate project because cURL would develop and support it. Does that make more sense?
      - scrollaway 10y ago
        I think I understand what you're saying, but all it would be is a change of ownership/packaging. httpie is only an interface to lower level libraries which already exist (requests and therefore urllib3). Whether it's an interface to requests or to libcurl matters fairly little. It'd be quite a drag if it were to libcurl in fact because syntax highlighting would be a lot harder, for example.
        peterwwillis 10y ago
        "all it would be" is a gigantic wealth of new functionality that requests/urllib3 does not have (compare libcurl and urllib3 features), along with greater support, developer base, test coverage, user base, and lower tco. httpie gains a wealth of advantages and cURL gets syntax highlighting. It's hard to overstate how advantageous to httpie it would be.
        scrollaway 10y ago
        You are extremely confused at which level it is beneficial to merge projects. You don't simplify things by going from one popular lib to another, especially when they both have legitimate use cases. Requests is one of Python's most highly regarded libs and a very popular one at that. Httpie is not its only user. And what you are describing is not a simple process. Gaining tests and features (what features anyway?) is not good enough for it.
        peterwwillis 10y ago
        > You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.
        dimino 10y ago
        Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?
        peterwwillis 10y ago
        > they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting
      - dimino 10y ago
        By that logic, if Firefox were implemented with libcurl and bundled with cURL, it would no longer need to exist as a separate project. I'm not sure I understand your point.
      - detaro 10y ago
        What makes you assume that the cURL project wants to support features like syntax highlighting, a second style of command line arguments, ... and would accept such contributions?
- scrollaway 10y ago
  Because the syntax is easier to remember, it has syntax highlighting for js, html and more and it's super easy to send json, form data, headers etc. It's better and quicker for prototyping APIs for example. BTW, curl is great too but I hate these kinds of posts. I keep seeing people on HN saying "not sure why anyone would use Y over X" completely disingenuously as if they are expressely not acknowledging the legitimate use cases of Y. Not sure why anyone would use dropbox over a self-hosted sftp server, right?
  - molecule 10y ago
    > I keep seeing people on HN saying "not sure why anyone would use Y over X" completely disingenuously as if they are expressely not acknowledging the legitimate use cases of Y. Kind of like titling a project "X: a CLI, Y-like tool for humans"...
  - deleted 10y ago
    [deleted]
- sleepyhead 10y ago
  Why would you use curl over httpie?
- alayne 10y ago
  httpie works at a higher level of abstraction.
dimino 10y ago
A minor logical point, but no one said cURL was not for humans. More than one thing can be "for humans".
alayne 10y ago
That's not a charitable interpretation of the headline. They are saying that HTTPie is more user friendly.

Right, let's take the human denomination away from people that use cURL...

NegativeLatency 10y ago

This tool pops up every few months, not sure why anyone would use it over curl

peterwwillis 10y ago
If this had been made an interface to libcurl, or added to a separate tool in the curl distribution, most of the novel functionality could have been adopted 3 years ago without the need to support a separate project and HTTP library.
- scrollaway 10y ago
  What do you mean? libcurl is as much a separate project/library as requests is, and this uses requests.
  - peterwwillis 10y ago
    Rephrase: If this was implemented with libcurl and bundled with cURL it would no longer need to exist as a separate project because cURL would develop and support it. Does that make more sense?
    - scrollaway 10y ago
      I think I understand what you're saying, but all it would be is a change of ownership/packaging. httpie is only an interface to lower level libraries which already exist (requests and therefore urllib3). Whether it's an interface to requests or to libcurl matters fairly little. It'd be quite a drag if it were to libcurl in fact because syntax highlighting would be a lot harder, for example.
      - peterwwillis 10y ago
        "all it would be" is a gigantic wealth of new functionality that requests/urllib3 does not have (compare libcurl and urllib3 features), along with greater support, developer base, test coverage, user base, and lower tco. httpie gains a wealth of advantages and cURL gets syntax highlighting. It's hard to overstate how advantageous to httpie it would be.
        scrollaway 10y ago
        You are extremely confused at which level it is beneficial to merge projects. You don't simplify things by going from one popular lib to another, especially when they both have legitimate use cases. Requests is one of Python's most highly regarded libs and a very popular one at that. Httpie is not its only user. And what you are describing is not a simple process. Gaining tests and features (what features anyway?) is not good enough for it.
        peterwwillis 10y ago
        > You are extremely confused at which level it is beneficial to merge projects. Not really, since if you read my comments I suggested they could have been merged into cURL three years ago (after starting four years ago). It wouldn't even be a new project, it would simply be an add-on tool. And that's the point.
        dimino 10y ago
        Can you restate your thesis? Is is that HTTPie should be merged into the cURL project?
        peterwwillis 10y ago
        > they could have been merged into cURL three years ago (after starting four years ago) > If this was implemented with libcurl and bundled with cURL > httpie gains a wealth of advantages > along with greater support, developer base, test coverage, user base, and lower tco > and cURL gets syntax highlighting
    - dimino 10y ago
      By that logic, if Firefox were implemented with libcurl and bundled with cURL, it would no longer need to exist as a separate project. I'm not sure I understand your point.
    - detaro 10y ago
      What makes you assume that the cURL project wants to support features like syntax highlighting, a second style of command line arguments, ... and would accept such contributions?
scrollaway 10y ago
Because the syntax is easier to remember, it has syntax highlighting for js, html and more and it's super easy to send json, form data, headers etc. It's better and quicker for prototyping APIs for example. BTW, curl is great too but I hate these kinds of posts. I keep seeing people on HN saying "not sure why anyone would use Y over X" completely disingenuously as if they are expressely not acknowledging the legitimate use cases of Y. Not sure why anyone would use dropbox over a self-hosted sftp server, right?
- molecule 10y ago
  > I keep seeing people on HN saying "not sure why anyone would use Y over X" completely disingenuously as if they are expressely not acknowledging the legitimate use cases of Y. Kind of like titling a project "X: a CLI, Y-like tool for humans"...
- deleted 10y ago
  [deleted]
sleepyhead 10y ago
Why would you use curl over httpie?
alayne 10y ago
httpie works at a higher level of abstraction.

dimino 10y ago

A minor logical point, but no one said cURL was not for humans. More than one thing can be "for humans".

alayne 10y ago

That's not a charitable interpretation of the headline. They are saying that HTTPie is more user friendly.