3 ms·

Totally. Brocoli and Brunch are a bit better, but they all have the same fundamental problem: they require you to write plugins for things. The plugin model doe

Totally. Brocoli and Brunch are a bit better, but they all have the same fundamental problem: they require you to write plugins for things. The plugin model doesn't work here because writing plugins is so difficult, and you don't want to write this crap: you just want your project to build. In addition, all of the things you want to use in a build process expose a perfectly good shell interface, which probably streams, and doesn't require anybody to write hundred-line projects to integrate into the build system. Which just begs the question: Why aren't we using shell, and make, or npm run?

KirinDave 10y ago
Aside, I had a similar question when I learned PowerShell. It made me question even why I was writing so many script executables. If we rely are devoted to using reusable and small components then a shell that can directly wrap our standard libraries (and has a type system rich enough to express maps and tree types) is indispensable to truly reusable software. Then what a make system should be is a clear and smart way to express dependencies and workloads.
- qwertyuiop924 10y ago
  I disagree, for so many reasons. PS is clunky and verbose, and textual data is actually so common that the unix toolkit is incredibly useful. Ad-hoc parsing comes up a lot, and if I have to parse a format, I'd rather it be text. Maps and trees aren't as important as you make them out to be. You can do key:value stores in text at O(n) cost, which is often G ood Enough, and rarely needed. And when you really need the extra power, take your pick: Python, Perl, Ruby, SCSH, and countless others. A shell's primary job should be to support interactive use, and fast development of one-time-use scripts off the cuff, because those are what most of us do most commonly. PS doesn't support either all that well.
  - KirinDave 10y ago
    > Ad-hoc parsing comes up a lot, and if I have to parse a format, I'd rather it be text. People often offer that "plain text is superior..." but neglect to recognize that PowerShell's model actually offers as superset of the current functionality of Bash, and that when object streams are required they are utterly indispensable. It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. Text isn't as simple as it used to be when we didn't give a damn about half the world's population. > Maps and trees aren't as important as you make them out to be. You can do key:value stores in text at O(n) cost, which is often G ood Enough, and rarely needed. We live in a world where Curling JSON objects or (even more problematically) protobuffs objects is the de-facto way we interact with the vast majority of remote services. Feel free to try and fit every workflow you have into jq. Feel free to keep working in an environment where even functional return values are not allowed and you keep repeating the same commands over and over. > And when you really need the extra power, take your pick: Python, Perl, Ruby, SCSH, and countless others. Quick question though: how is it this any different from the plugin approach from gulp? :) > A shell's primary job should be to support interactive use, and fast development of one-time-use scripts off the cuff, because those are what most of us do most commonly. PS doesn't support either all that well. Besides the awkward subquotation escapes for passing to commands, what exactly are you saying it can't do? Verbosity isn't exactly its problem, its editors are competent, its commandlets are quite capable, it's trivial to author more (and in many ways faster, e.g., adding a cmdlet with arguments is MUCH easier than the handrolled way in bash), you can directly call into a massive stdlib and any code you've written in .NET in any language that is supported by that target (including C#, F#, Nemerle, VB, Clojure and more) with native transitioning for all object types, and a bunch of other good features. In essence that approach gives the shell a lot more room to do its work without calling out to black-box out-of-conceptual-model plugins, without sacrificing the power of being able to appeal to them when required.
    - qwertyuiop924 10y ago
      >It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. True, but how many of your text-processing utilities need to account for that? Most config file parsers will just continue to work if you insert UTF-8 into the stream, so long as you keep the markers it's working with the same. >We live in a world where Curling JSON objects or (even more problematically) protobuffs objects is the de-facto way we interact with the vast majority of remote services. Feel free to try and fit every workflow you have into jq. Feel free to keep working in an environment where even functional return values are not allowed and you keep repeating the same commands over and over. ...I don't. Protobufs might have a market share in some places, but JSON has decent shell tooling, and you can often convert JSON to DSV in a pinch. I don't understand what you mean by "functional return values not allowed." Sure, EIAS is in full effect, but Shell pipelines are as functional as they come. And I don't repeat the same commands over and over. If I did, I'd give that set of commands a name. >Quick question though: how is it this any different from the plugin approach from gulp? :) Primary difference: The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. Verobosity is a huge problem. Most of the time with a shell, you'll be writing one-off scripts, or doing something interactive. If you were going to write something more than about 50 lines, or more complex than a couple of pipelines or an execution wrapper, you wouldn't be writing shell. PS is trying to go in a different direction, be a language for even those things that you'd go to another language for, but we've got perfectly adequate languages for that, tons of them, and it fails at things that shell is good at.
      - KirinDave 10y ago
        > True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. > Verobosity is a huge problem. If you want a less verbose set of powershell commands, try the latest powershell. Nearly everything you type has a short analogue. Function syntax is shorter. It's easier to do things like automate opening of remote connections (e.g., no need for a shell script to open an ssh connection and toss many streaming outputs into it on an ongoing basis). > and it fails at things that shell is good at. You say this but my experience has been the opposite thus far. Making functions actually functions, for example. It's amazing to be able to make a complex jq query repeatable without being forced to pipe everything over an IO stream and collect into a file and then VAR=$(cat result.json).
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

KirinDave 10y ago

Aside, I had a similar question when I learned PowerShell. It made me question even why I was writing so many script executables. If we rely are devoted to using reusable and small components then a shell that can directly wrap our standard libraries (and has a type system rich enough to express maps and tree types) is indispensable to truly reusable software. Then what a make system should be is a clear and smart way to express dependencies and workloads.

qwertyuiop924 10y ago
I disagree, for so many reasons. PS is clunky and verbose, and textual data is actually so common that the unix toolkit is incredibly useful. Ad-hoc parsing comes up a lot, and if I have to parse a format, I'd rather it be text. Maps and trees aren't as important as you make them out to be. You can do key:value stores in text at O(n) cost, which is often G ood Enough, and rarely needed. And when you really need the extra power, take your pick: Python, Perl, Ruby, SCSH, and countless others. A shell's primary job should be to support interactive use, and fast development of one-time-use scripts off the cuff, because those are what most of us do most commonly. PS doesn't support either all that well.
- KirinDave 10y ago
  > Ad-hoc parsing comes up a lot, and if I have to parse a format, I'd rather it be text. People often offer that "plain text is superior..." but neglect to recognize that PowerShell's model actually offers as superset of the current functionality of Bash, and that when object streams are required they are utterly indispensable. It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. Text isn't as simple as it used to be when we didn't give a damn about half the world's population. > Maps and trees aren't as important as you make them out to be. You can do key:value stores in text at O(n) cost, which is often G ood Enough, and rarely needed. We live in a world where Curling JSON objects or (even more problematically) protobuffs objects is the de-facto way we interact with the vast majority of remote services. Feel free to try and fit every workflow you have into jq. Feel free to keep working in an environment where even functional return values are not allowed and you keep repeating the same commands over and over. > And when you really need the extra power, take your pick: Python, Perl, Ruby, SCSH, and countless others. Quick question though: how is it this any different from the plugin approach from gulp? :) > A shell's primary job should be to support interactive use, and fast development of one-time-use scripts off the cuff, because those are what most of us do most commonly. PS doesn't support either all that well. Besides the awkward subquotation escapes for passing to commands, what exactly are you saying it can't do? Verbosity isn't exactly its problem, its editors are competent, its commandlets are quite capable, it's trivial to author more (and in many ways faster, e.g., adding a cmdlet with arguments is MUCH easier than the handrolled way in bash), you can directly call into a massive stdlib and any code you've written in .NET in any language that is supported by that target (including C#, F#, Nemerle, VB, Clojure and more) with native transitioning for all object types, and a bunch of other good features. In essence that approach gives the shell a lot more room to do its work without calling out to black-box out-of-conceptual-model plugins, without sacrificing the power of being able to appeal to them when required.
  - qwertyuiop924 10y ago
    >It's also a uniquely eurocentric conceit that text is a simple stream of bytes. At the very least, it is a stream of bytes with an encoding label. Unicode is everywhere, and for some people is required to express their language. You can no more safely assume ISO-Latin-1 as you can UTF-8 or UTF-16. True, but how many of your text-processing utilities need to account for that? Most config file parsers will just continue to work if you insert UTF-8 into the stream, so long as you keep the markers it's working with the same. >We live in a world where Curling JSON objects or (even more problematically) protobuffs objects is the de-facto way we interact with the vast majority of remote services. Feel free to try and fit every workflow you have into jq. Feel free to keep working in an environment where even functional return values are not allowed and you keep repeating the same commands over and over. ...I don't. Protobufs might have a market share in some places, but JSON has decent shell tooling, and you can often convert JSON to DSV in a pinch. I don't understand what you mean by "functional return values not allowed." Sure, EIAS is in full effect, but Shell pipelines are as functional as they come. And I don't repeat the same commands over and over. If I did, I'd give that set of commands a name. >Quick question though: how is it this any different from the plugin approach from gulp? :) Primary difference: The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. Verobosity is a huge problem. Most of the time with a shell, you'll be writing one-off scripts, or doing something interactive. If you were going to write something more than about 50 lines, or more complex than a couple of pipelines or an execution wrapper, you wouldn't be writing shell. PS is trying to go in a different direction, be a language for even those things that you'd go to another language for, but we've got perfectly adequate languages for that, tons of them, and it fails at things that shell is good at.
    - KirinDave 10y ago
      > True, but how many of your text-processing utilities need to account for that? I'm not chinese, but I can have sympathy for people who are. Also who are you to tell me [UTF-8 character removed because of bad assumptions in server code] is not a valid bash variable? > The libraries are all already there, you don't have go get apt-get integration for the components you need, and it's often pretty quick to write what you need. This is an assumption that's very brittle though. For example, which version of Python did you target with this helper script? Do you know? And why is that diff for Powershell? It's just a shell with better affordances for automation than bash. > Verobosity is a huge problem. If you want a less verbose set of powershell commands, try the latest powershell. Nearly everything you type has a short analogue. Function syntax is shorter. It's easier to do things like automate opening of remote connections (e.g., no need for a shell script to open an ssh connection and toss many streaming outputs into it on an ongoing basis). > and it fails at things that shell is good at. You say this but my experience has been the opposite thus far. Making functions actually functions, for example. It's amazing to be able to make a complex jq query repeatable without being forced to pipe everything over an IO stream and collect into a file and then VAR=$(cat result.json).

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]