4 ms·

A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such a

by dkarl 5y ago

A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl? I can see the advantages of standardizing on a complex, powerful tool for simple use cases. For one thing, it may be the only way to standardize: simple versions are too easy to write, and therefore you get dozens of competitors, none of whom are popular enough to shake out their edge case bugs. It's also nice not to have to find, install, and learn a new tool when you stray over that 90% boundary. With software dependencies, I think the advantages of small, simple libraries win out over generality. Supporting powerful use cases makes an API more complex and often means that simple, 90% use cases require weird incantations to make them work. Here I think of the times I've had to get into the guts of Jackson despite never doing anything remotely exotic with JSON. The 95% of your codebase that can be simple should be simple, so you can devote your attention to the things that need to be complex.

rad_gruchalski 5y ago
> A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl? But nobody is forced to use curl? People use it because it’s convenient, shoot them selves in the foot and then lash out at the author the tool for their own choices. Where’s the fault?
- throwaway894345 5y ago
  > But nobody is forced to use curl? I like curl, but this isn't true. When you're SSH-ing onto a box, you often don't have permissions to install your favorite CLI tool, and even if you do have said permissions it's inconvenient to have to install it each time you SSH onto the box (not a major inconvenience, mind you). Moreover, in many cases you need to run a script or some other software that depends directly on curl. In general the "nobody is forced to use it" arguments rarely pan out (I remember this was a canned argument from C++ folks circa 2011: "C++ is the best language because it has every feature and if you don't like some features, you aren't forced to use them!").
  - jethro_tell 5y ago
    Well, your distro choose to include one lib that can be used with most protocols out there. They include the multi tool and many of the apps also included on the box require the tool. If you want to use something else. You have to install it on the host. Every box comes with bash, but we still install other languages and frameworks on the host so we can run out applications with tools that make sense. If you want a different tool, make it part of your default install.
    - throwaway894345 5y ago
      The point is that you’re not always the person who gets to decide which distro, which tools to install atop the distro, or which dependencies your scripts will use. If you own those choices, of course you can add in your own tool, but you frequently don’t own those choices.
      - Alghranokk 5y ago
        But cannot this charge be levied upon all tools and utilities? If you do not have the permission to bring your own tools it stands to reason that you will have to use the tools already in place, be that curl or some other random assortment of literally anything else. I don't much see the moral basis behind showing up at the construction yard and then lamenting over your lack of choice simply because your employer only brought makita brand tools.
        jethro_tell 5y ago
        No one picks curl to be on a box, it a core library for everything else on the host. It's not a Makita drill, it's more like electrical power at the site and this guy is complaining this tool uses gas or propane. Doesn't stop anyone else from using a power saw or charging batteries. If you need propane, bring it.
      - mohbk 5y ago
        I feel the alternative is not better, a light weight bare minimum lib and no ability to install your own is definitely worse.
ordinaryperson 5y ago
Sometimes yes, sometimes no. Counter-example: Jenkins. It does what you ask of it, its base install is "naked" and only contains the minimum functionality in the core. Everything then becomes a plugin. Git. GitHub. Branch for multi-branch pipelines. Credentials management. And on and on and on. Now you have stay on top of maintaining the plugins in addition to the core. Also, many plugins require other plugins so just to do some basic stuff like set up a multi-branch pipeline from a GitHub repo you're suddenly staring down the barrel of dozens and dozens of bespoke plugins with varying levels of quality and support. A monolithic application like curl is a dream to me by comparison. Everything is tested in every release. Sub-components are kept up to date by the maintainer. No plugins fighting each other's plugins. From afar it's easy to see the praise simplicity and modularization but honestly monoliths can be undervalued too.
- dkarl 5y ago
  I can definitely see your point, having experienced the same thing with plugins for SBT, the Scala build tool. I didn't really consider the case of a small core with a multitude of plugins as a twist on the small, simple tool. I think you're right that a plugin architecture lets a thousand flowers bloom, but you don't get long-term stability, because people move on to other tools and stop maintaining the plugins they wrote. For example, VSCode plugins are great because VSCode is thriving, and Emacs packages are a crapshoot because many of the programmers who wrote them have moved on. Eventually VSCode plugins will be like Emacs packages.
- htrp 5y ago
  well written monoliths are the dream..... curl is a utility, like power. you don't worry about electricity not being able to power your TV because it was designed for light bulbs, it just works.
- seanp2k2 5y ago
  Also: node. Everything is a module, and every module requires a hundred more. Projects with thousands of dependencies become common. No one understands what is actually “under the hood” and hardly anyone cares. “It just works” most of the time. Good enough. Sad.
Y_Y 5y ago
I would be surprised if nobody had tried to make a mini-curl that could go in busybox. The idea of having a tiny version of the program which handles the 90% cases by itself but can call out to the real-deal bigger brother when necessary is a nice one. This sort-of happens already with lots of common tools which are shadowed by shell builtins, why not curl?
- tephra 5y ago
  Perhaps not exactly what you are looking for but there is: https://curl.se/tiny/ https://curl.se/tiny/
- jethro_tell 5y ago
  For embedded systems we'll usually make our own curl with the exact protocols features we need. No surprise but curl can do that too!
lenkite 5y ago
I agree. At any rare the System default curl is rarely compiled with all those features enabled, so finally one sticks to http/https/ftp/ftps subset for curl all the time.

by dkarl 5y ago

rad_gruchalski 5y ago

> A question that arises out of this is, should the 90% use cases be handled by a small, simple tool, or by the tip of the iceberg of a large, complex tool such as curl? But nobody is forced to use curl? People use it because it’s convenient, shoot them selves in the foot and then lash out at the author the tool for their own choices. Where’s the fault?

throwaway894345 5y ago
> But nobody is forced to use curl? I like curl, but this isn't true. When you're SSH-ing onto a box, you often don't have permissions to install your favorite CLI tool, and even if you do have said permissions it's inconvenient to have to install it each time you SSH onto the box (not a major inconvenience, mind you). Moreover, in many cases you need to run a script or some other software that depends directly on curl. In general the "nobody is forced to use it" arguments rarely pan out (I remember this was a canned argument from C++ folks circa 2011: "C++ is the best language because it has every feature and if you don't like some features, you aren't forced to use them!").
- jethro_tell 5y ago
  Well, your distro choose to include one lib that can be used with most protocols out there. They include the multi tool and many of the apps also included on the box require the tool. If you want to use something else. You have to install it on the host. Every box comes with bash, but we still install other languages and frameworks on the host so we can run out applications with tools that make sense. If you want a different tool, make it part of your default install.
  - throwaway894345 5y ago
    The point is that you’re not always the person who gets to decide which distro, which tools to install atop the distro, or which dependencies your scripts will use. If you own those choices, of course you can add in your own tool, but you frequently don’t own those choices.
    - Alghranokk 5y ago
      But cannot this charge be levied upon all tools and utilities? If you do not have the permission to bring your own tools it stands to reason that you will have to use the tools already in place, be that curl or some other random assortment of literally anything else. I don't much see the moral basis behind showing up at the construction yard and then lamenting over your lack of choice simply because your employer only brought makita brand tools.
      - jethro_tell 5y ago
        No one picks curl to be on a box, it a core library for everything else on the host. It's not a Makita drill, it's more like electrical power at the site and this guy is complaining this tool uses gas or propane. Doesn't stop anyone else from using a power saw or charging batteries. If you need propane, bring it.
    - mohbk 5y ago
      I feel the alternative is not better, a light weight bare minimum lib and no ability to install your own is definitely worse.

ordinaryperson 5y ago

Sometimes yes, sometimes no. Counter-example: Jenkins. It does what you ask of it, its base install is "naked" and only contains the minimum functionality in the core. Everything then becomes a plugin. Git. GitHub. Branch for multi-branch pipelines. Credentials management. And on and on and on. Now you have stay on top of maintaining the plugins in addition to the core. Also, many plugins require other plugins so just to do some basic stuff like set up a multi-branch pipeline from a GitHub repo you're suddenly staring down the barrel of dozens and dozens of bespoke plugins with varying levels of quality and support. A monolithic application like curl is a dream to me by comparison. Everything is tested in every release. Sub-components are kept up to date by the maintainer. No plugins fighting each other's plugins. From afar it's easy to see the praise simplicity and modularization but honestly monoliths can be undervalued too.

dkarl 5y ago
I can definitely see your point, having experienced the same thing with plugins for SBT, the Scala build tool. I didn't really consider the case of a small core with a multitude of plugins as a twist on the small, simple tool. I think you're right that a plugin architecture lets a thousand flowers bloom, but you don't get long-term stability, because people move on to other tools and stop maintaining the plugins they wrote. For example, VSCode plugins are great because VSCode is thriving, and Emacs packages are a crapshoot because many of the programmers who wrote them have moved on. Eventually VSCode plugins will be like Emacs packages.
htrp 5y ago
well written monoliths are the dream..... curl is a utility, like power. you don't worry about electricity not being able to power your TV because it was designed for light bulbs, it just works.
seanp2k2 5y ago
Also: node. Everything is a module, and every module requires a hundred more. Projects with thousands of dependencies become common. No one understands what is actually “under the hood” and hardly anyone cares. “It just works” most of the time. Good enough. Sad.

Y_Y 5y ago

I would be surprised if nobody had tried to make a mini-curl that could go in busybox. The idea of having a tiny version of the program which handles the 90% cases by itself but can call out to the real-deal bigger brother when necessary is a nice one. This sort-of happens already with lots of common tools which are shadowed by shell builtins, why not curl?

tephra 5y ago
Perhaps not exactly what you are looking for but there is: https://curl.se/tiny/ https://curl.se/tiny/
jethro_tell 5y ago
For embedded systems we'll usually make our own curl with the exact protocols features we need. No surprise but curl can do that too!

lenkite 5y ago

I agree. At any rare the System default curl is rarely compiled with all those features enabled, so finally one sticks to http/https/ftp/ftps subset for curl all the time.