4 ms·

In practice it’s totally inscrutable. I never remember or even feel comfortable guessing at anything more than the most basic. Meanwhile, any typed library in l

In practice it’s totally inscrutable. I never remember or even feel comfortable guessing at anything more than the most basic. Meanwhile, any typed library in language X usually works immediately with no docs given a decent IDE.

_bxg1 6y ago
I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems. But I also don't think there's anything wrong with that. There's a use-case for simple pieces that are easy to snap together, and I think that use-case has been greatly under-served because lots of things that aim for it end up as complicated, multi-faceted APIs. You could almost say that micro-services are trying to follow in the Unix tradition. But the problem is that a) they don't really get used in that ideal, small-scale use-case because they're almost always written and consumed internally, not exposed to the public, and b) they do get used in those huge, complex cases where their lego-ness stops being a virtue and starts being a liability.
- TAForObvReasons 6y ago
  > starts being a liability SaaS is all the rage now, and the business of SaaS is disincentivized from making "lego-like" software. The easier it is to interoperate, arguably the easier it is to replace or reimplement your service. Because a lot of the value of unix tools is derived from their interoperability, they play nice with each other.
  - _bxg1 6y ago
    Yeah, that is part of the problem too. Any for-profit corp would love to lock people in, and software megacorps no longer need to interoperate for their own survival. So we see increased lock-in across most of the (commercial) software world. An interesting inverse-example is Slack, which does lots of interop with other services, because it isn't a trillion-dollar company that can attempt to give you everything you need under a single roof.
- galaxyLogic 6y ago
  > I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems Right, just like LEGOS thrive in simple cases, are not suited for building complex systems. That is why the idea of "Software LEGOs" is not reality. Or you can say that Unix Pipes are "software LEGOs", with similar limitations.
jvanderbot 6y ago
In your practice you have favored an alternative. (not "in practice", implying absolute) In my practice I have used both with great success. For logging, parsing, and displaying playback data from field systems, UNIX and UNIX-like tools have been incredible. VNLog in particular is a wonderful way to interact with data if you need just a bit of structure on top of unix outputs. And anyway, getting from not-so-great data to something that a typed library in language X can parse is a great job for plain old Unix tools.
- nwienert 6y ago
  I’m saying in the sense of “time I put in to value I get out”, I’ve put quite a lot of time into bash, but even though I’ve done certain actions many times, I remember few. I recently picked up Swift and it was a dream. Never used it in nearly the same degree, but I was highly productive quickly. The thing is: I don’t think it’s a bad paradigm (everything a stream of text), it’s just the “IDE” sucks completely. If there was inline autocomplete, peek-ahead results, a “verbose mode” where the options are all more like typed full-English objects, instant fuzzy search of actions, multi line with an easy way to edit, etc, it would probably be fantastic and I’d be a 100x shell developer. It would also basically feel like an IDE at that point for a normal programming language!
amiga_500 6y ago
In practice it's been massively successful for decades.

_bxg1 6y ago

I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems. But I also don't think there's anything wrong with that. There's a use-case for simple pieces that are easy to snap together, and I think that use-case has been greatly under-served because lots of things that aim for it end up as complicated, multi-faceted APIs. You could almost say that micro-services are trying to follow in the Unix tradition. But the problem is that a) they don't really get used in that ideal, small-scale use-case because they're almost always written and consumed internally, not exposed to the public, and b) they do get used in those huge, complex cases where their lego-ness stops being a virtue and starts being a liability.

TAForObvReasons 6y ago
> starts being a liability SaaS is all the rage now, and the business of SaaS is disincentivized from making "lego-like" software. The easier it is to interoperate, arguably the easier it is to replace or reimplement your service. Because a lot of the value of unix tools is derived from their interoperability, they play nice with each other.
- _bxg1 6y ago
  Yeah, that is part of the problem too. Any for-profit corp would love to lock people in, and software megacorps no longer need to interoperate for their own survival. So we see increased lock-in across most of the (commercial) software world. An interesting inverse-example is Slack, which does lots of interop with other services, because it isn't a trillion-dollar company that can attempt to give you everything you need under a single roof.
galaxyLogic 6y ago
> I would argue that it thrives in those most basic cases, and isn't really suited to building truly complex systems Right, just like LEGOS thrive in simple cases, are not suited for building complex systems. That is why the idea of "Software LEGOs" is not reality. Or you can say that Unix Pipes are "software LEGOs", with similar limitations.

jvanderbot 6y ago

In your practice you have favored an alternative. (not "in practice", implying absolute) In my practice I have used both with great success. For logging, parsing, and displaying playback data from field systems, UNIX and UNIX-like tools have been incredible. VNLog in particular is a wonderful way to interact with data if you need just a bit of structure on top of unix outputs. And anyway, getting from not-so-great data to something that a typed library in language X can parse is a great job for plain old Unix tools.

nwienert 6y ago
I’m saying in the sense of “time I put in to value I get out”, I’ve put quite a lot of time into bash, but even though I’ve done certain actions many times, I remember few. I recently picked up Swift and it was a dream. Never used it in nearly the same degree, but I was highly productive quickly. The thing is: I don’t think it’s a bad paradigm (everything a stream of text), it’s just the “IDE” sucks completely. If there was inline autocomplete, peek-ahead results, a “verbose mode” where the options are all more like typed full-English objects, instant fuzzy search of actions, multi line with an easy way to edit, etc, it would probably be fantastic and I’d be a 100x shell developer. It would also basically feel like an IDE at that point for a normal programming language!

amiga_500 6y ago

In practice it's been massively successful for decades.