5 ms·

Completely agree. Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults." It also doesn't make it easy to use, be

Completely agree. Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults." It also doesn't make it easy to use, because eventually the magic will guess wrong and it will go from magically the right thing even though I passed garbage arguments to completely the wrong thing at the drop of a hat. An example of a "sane default" where curl falls short might be to enable redirects by default, because that is usually what the user wants (and correct client behavior).

BoorishBears 7y ago
> Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults." Please explain how a well-defined key-value convention is equitable to "incomplete" or "plain wrong" arguments. In what way is any of this opaque when it's fully documented and quite easy to follow?: https://github.com/jakubroztocil/httpie#id16 https://github.com/jakubroztocil/httpie#id16
- detaro 7y ago
  Fairly sure I'd forget all the time that it thinks giving it a syntax that looks like form-encoded obviously means I want to send a JSON request.
  - BoorishBears 7y ago
    key=value is a convention used in so many places that have nothing to do with form encoding Would Java developers see this and imagine you're passing values for a .properties file? If you've never seen the tool before, you also wouldn't know how it works at all. Once you hit help for the first time (you know, to actually learn how to use it), knowing it defaults to JSON is pretty much a base truth. It's entire value proposition seems to be stongly tied to JSON support (2nd highest feature in the pitch at the top). This is like saying you'd forget jq takes JSON strings...
    - stephenr 7y ago
      How many key/value formats commonly used for http request/response transactions use = ?? The first feature pitch is “user-friendly curl alternative with intuitive UI”.
      - BoorishBears 7y ago
        I'll leave it at this, I'm glad they prioritized not having to escape JSON on the command line over people who have no idea about how the tool works being able to guess how to pass form inputs. That is probably the most user friendly difference they could make for working with JSON based APIs
    - insomniacity 7y ago
      Right, but this is HTTP, which has used form encoding since... 1998, if RFC 2388 is to be believed.
      - hinkley 7y ago
        That doesn’t sound right. I’m pretty sure it’s older than that. New RFCs tend to replace old ones and I don’t think they reliably make it painfully obvious this is what’s happening.
- mike_hock 7y ago
  A URL without a scheme is somewhere between "plain wrong" and "incomplete." The program switches around between HTTP methods, content types, query building, request serialization, etc, at every minor syntactic change to the command line arguments. The fact that a foo=bar implies that the request content type AND the accepted response content type will be set to application/json AND the foo=bar is POSTed as a JSON object isn't a "sane default." That is not to say it can't be a useful utility. The quirky syntax for query parameters, JSON-serialized request body, etc, can be learned and is quite concise, so after the initial learning curve, it can be used very efficiently. "Sane defaults" is false advertising, because it implies the least amount of surprise. This tool is the opposite. It is unintuitive but potentially very efficient once learned.
  - BoorishBears 7y ago
    The third feature listed after "syntax" and "formatting" is "Built-in JSON support" It's a JSON-centric tool made for people who work with APIs that use JSON in very compatible way, with JSON-centric defaults Changing the accepted type matches behavior of Js HTTP libraries like `request`, where accept and request content types are set in unison by default. This stuff is all sane defaults for the people who are usually in Postman firing off JSON data to APIs that all look very similar. "Sane defaults" don't exist in a vacuum, writing (and escaping) properly formatted JSON is a pain (see jq and how the 2nd paragraph in how to even invoke it is dedicated to escaping) The tool defaults to removing that pain point in a very easy to understand way.
Wowfunhappy 7y ago
Broadly curious, what would your thoughts be if the CLI printed it's guesses, alongside how they could be more explicit? "X is not valid, assuming: [more explicit version of argument goes here]" This strikes me as the best of both worlds--you're seamlessly educating the user on what is happening and what they could have done instead.
- mike_hock 7y ago
  Just to be clear (see my other comment), I'm not against tools that require a learning curve. I'm against dishonest advertising with loaded phrases like "sane defaults" (this term has its place, but it's not here) and "for humans" (this term is always a red flag) when the tool invents a load of unconventional, unintuitive syntax.
  - jkbr 7y ago
    > I'm against dishonest advertising with loaded phrases like "sane defaults" (this term has its place, but it's not here) and "for humans" (this term is always a red flag) when the tool invents a load of unconventional, unintuitive syntax. Author of the dishonest advertising here ;) I don't think the fact that the tool introduces a mini language for crafting HTTP requests on the command line contradicts with the statement that the tool also provides what the author believes are sensible defaults (e.g., default to POST when sending data vs. GET when not, default to "prettifying" HTTP messages for human consumptions on the terminal vs. not touching them when the output is redirected, etc.). "For humans" is meant to highlight the focus of this project on usability and interactive usage, as opposed to curl’s focus on feature-completeness across a number of protocols and non-interactive usage: > curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction. [1] [1] https://curl.haxx.se/docs/manpage.html https://curl.haxx.se/docs/manpage.html

BoorishBears 7y ago

> Opaque magic to "guess what you want" from incomplete or plain wrong arguments isn't "sane defaults." Please explain how a well-defined key-value convention is equitable to "incomplete" or "plain wrong" arguments. In what way is any of this opaque when it's fully documented and quite easy to follow?: https://github.com/jakubroztocil/httpie#id16 https://github.com/jakubroztocil/httpie#id16

detaro 7y ago
Fairly sure I'd forget all the time that it thinks giving it a syntax that looks like form-encoded obviously means I want to send a JSON request.
- BoorishBears 7y ago
  key=value is a convention used in so many places that have nothing to do with form encoding Would Java developers see this and imagine you're passing values for a .properties file? If you've never seen the tool before, you also wouldn't know how it works at all. Once you hit help for the first time (you know, to actually learn how to use it), knowing it defaults to JSON is pretty much a base truth. It's entire value proposition seems to be stongly tied to JSON support (2nd highest feature in the pitch at the top). This is like saying you'd forget jq takes JSON strings...
  - stephenr 7y ago
    How many key/value formats commonly used for http request/response transactions use = ?? The first feature pitch is “user-friendly curl alternative with intuitive UI”.
    - BoorishBears 7y ago
      I'll leave it at this, I'm glad they prioritized not having to escape JSON on the command line over people who have no idea about how the tool works being able to guess how to pass form inputs. That is probably the most user friendly difference they could make for working with JSON based APIs
  - insomniacity 7y ago
    Right, but this is HTTP, which has used form encoding since... 1998, if RFC 2388 is to be believed.
    - hinkley 7y ago
      That doesn’t sound right. I’m pretty sure it’s older than that. New RFCs tend to replace old ones and I don’t think they reliably make it painfully obvious this is what’s happening.
mike_hock 7y ago
A URL without a scheme is somewhere between "plain wrong" and "incomplete." The program switches around between HTTP methods, content types, query building, request serialization, etc, at every minor syntactic change to the command line arguments. The fact that a foo=bar implies that the request content type AND the accepted response content type will be set to application/json AND the foo=bar is POSTed as a JSON object isn't a "sane default." That is not to say it can't be a useful utility. The quirky syntax for query parameters, JSON-serialized request body, etc, can be learned and is quite concise, so after the initial learning curve, it can be used very efficiently. "Sane defaults" is false advertising, because it implies the least amount of surprise. This tool is the opposite. It is unintuitive but potentially very efficient once learned.
- BoorishBears 7y ago
  The third feature listed after "syntax" and "formatting" is "Built-in JSON support" It's a JSON-centric tool made for people who work with APIs that use JSON in very compatible way, with JSON-centric defaults Changing the accepted type matches behavior of Js HTTP libraries like `request`, where accept and request content types are set in unison by default. This stuff is all sane defaults for the people who are usually in Postman firing off JSON data to APIs that all look very similar. "Sane defaults" don't exist in a vacuum, writing (and escaping) properly formatted JSON is a pain (see jq and how the 2nd paragraph in how to even invoke it is dedicated to escaping) The tool defaults to removing that pain point in a very easy to understand way.

Wowfunhappy 7y ago

Broadly curious, what would your thoughts be if the CLI printed it's guesses, alongside how they could be more explicit? "X is not valid, assuming: [more explicit version of argument goes here]" This strikes me as the best of both worlds--you're seamlessly educating the user on what is happening and what they could have done instead.

mike_hock 7y ago
Just to be clear (see my other comment), I'm not against tools that require a learning curve. I'm against dishonest advertising with loaded phrases like "sane defaults" (this term has its place, but it's not here) and "for humans" (this term is always a red flag) when the tool invents a load of unconventional, unintuitive syntax.
- jkbr 7y ago
  > I'm against dishonest advertising with loaded phrases like "sane defaults" (this term has its place, but it's not here) and "for humans" (this term is always a red flag) when the tool invents a load of unconventional, unintuitive syntax. Author of the dishonest advertising here ;) I don't think the fact that the tool introduces a mini language for crafting HTTP requests on the command line contradicts with the statement that the tool also provides what the author believes are sensible defaults (e.g., default to POST when sending data vs. GET when not, default to "prettifying" HTTP messages for human consumptions on the terminal vs. not touching them when the output is redirected, etc.). "For humans" is meant to highlight the focus of this project on usability and interactive usage, as opposed to curl’s focus on feature-completeness across a number of protocols and non-interactive usage: > curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command is designed to work without user interaction. [1] [1] https://curl.haxx.se/docs/manpage.html https://curl.haxx.se/docs/manpage.html