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.

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.

Indeed, I do exactly that: 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.