10: Command-Line Superpowers: Connecting Simple Tools for Complex Solutions

Wolf hands you the keys to the old-world kingdom, which turn out to still be valuable, just much less used!

Most programmers are comfortable in their IDE but still click through file managers and manually handle repetitive tasks outside of it. You might know basic command line navigation, maybe even write the occasional script, but you're missing the real superpower: composition - the art of connecting existing tools to solve complex problems without writing any code. This episode reveals how thinking like a conductor rather than a programmer transforms your relationship with the command line. We'll show you how to orchestrate simple, specialized tools into powerful workflows that handle the tedious work you're doing manually right now. Whether you're a Python developer who reaches for scripts too quickly or someone who's been intimidated by the terminal, you'll walk away understanding how to compose solutions from tools that already exist on your computer. By the end, you'll have a clear path from GUI-dependent to composition master, with five practical takeaways you can implement this week to start building your personal superpower toolkit.

Takeaways

• You now have the conceptual framework: command line as composition and orchestration, not memorizing cryptic commands
• The specialist tools already exist on your computer right now - you're learning to conduct the orchestra
• Every composition you create becomes part of your growing personal capability
• Start this week: pick one repetitive task that annoys you and find its composition solution
• Your journey from GUI-dependent to composition master begins with connecting just two simple tools

Here's a link for the article about a VPN service that is doing screen captures of what you think are private pages:

https://www.csoonline.com/article/4044514/featured-chrome-extension-freevpn-one-caught-capturing-and-transmitting-user-data.html

Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm

Follow us on Mastodon: @RuntimeArguments@hachyderm.io

If you have feedback for us, please send it to feedback@RuntimeArguments.fm

Checkout our webpage at http://RuntimeArguments.fm

Theme music:
Dawn by nuer self, from the album Digital Sky

Transcript

Jim: 0:05

Welcome and thanks for tuning in to Runtime Arguments. We've got a great episode for you today on using the command line shells. I can hardly wait to get into it, but first let's take care of a few things. This is episode 10. Can you believe it, Wolf? Do you believe that? Uh that's I actually kind of don't. It's not our 10th episode. Uh we're programmers. We start counting at zero. So while it's labeled episode 10, it's actually our 11th episode. Um I want to thank you for for listening today, for tuning in. And um we we we like feedback uh and we get feedback. We just want more feedback. Um in a minute, I'm gonna go over a couple of items from from two of our previous episodes. Um but we're wondering if if you can give us some feedback. We're asking for some specific feedback here. We would like to know how long you would like our episodes to be. We've had some short episodes. The shortest was 27 minutes long, and we've had some long episodes. Our longest was the most recent episode on data types. That was an hour and 27 minutes. I think we're shooting for somewhere in between, but what do you want? Well if you want us to go more in depth, we'll do it. Wolf, do you have uh you want to elaborate a bit on that?

Wolf: 1:31

Yeah, that's uh that's my feeling. It's about depth. There are some topics that are valuable and we want to talk about, but the they're not just all that deep. And if there was a topic like that, I I wouldn't want it to run all that long. Uh to me, the the feedback I'd like to hear is if a topic does have some depth, should we dive in and spend a little more time to make sure we get all the parts that you might care about? Or should we cut it off so that it's short enough for you to consume? Um I I really think that the uh the whole point of our podcast is to give the listener, give you the information that you want. Do you want us to go longer and give you more? Or uh are we giving the right amount? Or maybe too much. Uh that's the feedback we'd like. Write us, tell us.

Jim: 2:35

Yeah, so please send us your feedback at feedback at runtimearguments.fm. I'll include that and more links uh in the show notes. Uh previous episode feedback. Uh uh last episode was about data types. And uh I made a comment about uh a 64-bit machine. Uh, I think both Wolf and I were surprised that uh an int, if you're programming in C, an int on a 64-bit machine is not 64 bits long. It's typically 32 bits, and that really surprised me, and I guess I should have thought about it more. Um it turns out that most of the time you don't need 64-bit integers. 32-bit is probably overkill a lot of times. You know, think about it. You're writing a uh a for loop in C, and you create a uh you do int i, and then you do this for i equals zero till i is less than some kind of small number, uh, i plus plus. It certainly doesn't need to be 64 bits. And a lot of the integers you declare in your program are like that. They don't need to be really large numbers. The reason why this is important is uh you can fit a lot more 32-bit integers in the same amount of memory as as uh a lot more than you can 64-bit integers. So the processor cache is more efficient if you're using shorter integers. Um if you're storing these things uh uh on the disk, uh shorter integers take less space. It just makes a lot of sense. Use the right size for what you're doing. So I think the compiler writers they decided uh let's make it into only 32 bits because that's suitable for almost anybody.

Wolf: 4:22

And you can always ask for more.

Jim: 4:25

Yeah, if you need 64 bits, ask for a long. If you need 128 bits, ask for a long, long. Uh there's ways to get the size you need. Uh and a and a processor, even a 64-bit processor, will process 32-bit integers very, very quickly. I suspect faster than it would process a 64-bit integer. Um anyway. Uh the other episode, quite a while back, we did an episode on VPNs uh connecting safely. Um and it came to my attention, somebody sent me a link about uh uh we we tried to make the distinction between VPNs and VPN services, where VPN is something like uh uh OpenVPN or WireGuard or one of those, and that's where you connect your machine to another machine or your machine to your network at work, something like that. Then there's VPN services. That's something I said that really should be more like an anonymizer service. You use that to connect out to the world, and you don't want people to know who you are. Maybe you're trying to watch TV when you're in a foreign country, but you want to access your local uh American uh content, so you use one of these VPN services. Well, it turns out that at least one of the VPN service companies is doing something I think is pretty nasty. They're taking screenshots, uh, screen captures uh of the web pages that you're browsing. They claim it's to uh feed into their AI analys an analyzer and uh protect you better. I I think that's pretty creepy. If they're actually grabbing your screenshots, it doesn't sit well with me. Um there's an article about it. Uh I'm gonna include the link to that article in the show notes uh in case you want to read more about it. I I think it's pretty icky. Um yeah. Uh that's all I'm gonna say about that.

Wolf: 6:27

Makes you want the other kind of VPN. Yeah.

Jim: 6:31

Yeah. Yeah. That's just uh, you know, they all could be doing that, especially the ones that are uh plugins to your browser that that claim they give you safe browsing. I don't know.

Wolf: 6:44

So a thing you just said having to do with the size of integers, and if this turns out to be completely uninteresting to people, you can edit it out. But I just have to say this thing because it bothers me all the time and has for decades. And that is this. Uh in C and C ⁇ , there is a difference between plus plus i and i plus plus. When you say plus plus i, you mean the easy thing. You mean increment the variable and then use the value. It's simple. When you say i plus plus, what you mean is take the value the variable has now so that you can use and test it, and then without revealing the result to anyone, increment that integer. And every single fricking loop in C and C is written uh for I get zero i less than n i plus plus. And that is wrong. That is absolutely backwards. They're not using the value, they're asking the compiler to do the harder thing, which means something different and doesn't do what they want or are asking for. So it turns out that most C and C compilers are smart enough to say, oh, you said the wrong thing. I'll do the right thing anyway. It still pisses me off. When you write code, you should say what you mean. That's my opinion.

Jim: 8:25

You know, I I write code like that, and I do the I plus plus. And to me, it makes perfect sense. It means use the value and then increment it for the next time around. I I I don't understand the the issue there. Um you know, one's prefix uh incrementing and one's postfix incrementing. Is that the right word for that?

Wolf: 8:47

That is the right word, and the question is how you have written your loop. Um is it less than n or is it less than n plus one? Or you know, you control, are you using that uh increment the right way? Okay. Um I just hate it when people don't think about it.

Jim: 9:05

Uh okay. All right. So uh today we're here to talk about command line shells. Wolf, let's get into it.

Wolf: 9:16

Um the world is changing. In the old days, um, we didn't have GUIs and all these crazy um interesting editors and whatnot. What we had were we had a whole bunch of independent little tools, and when you got a Unix and years later, Linux distribution, a big part of it was that collection of tools. A lot of them were standard, whatever. But most programmers today are comfortable in their IDE, their integrated development environment, but they still click through file managers and manually handle repetitive tasks outside of their IDE. Um you might know basic command line navigation within a shell. Uh maybe you even write the occasional script, but you are missing the real, actual superpower of command line shells. And it's less about the shell and the existence of all of these tools that it had taken decades to gather together. Um, and that is composition. The art of connecting existing tools to solve problems way harder than you are probably facing this very instant. Uh, and maybe you have faced some hard problems where this would have been the right answer, but solving the problem without writing any new code. Um this episode is about how thinking like a conductor, like an orchestra conductor, where each player in the orchestra, they know how to do their job. And as the conductor, you're not gonna play the song, you're gonna combine the skills of all those individual players who are absolute experts, and the result of combining them is gonna be something magnificent. Did you have to write something? Absolutely not. Um, so we're gonna show you how to orchestrate these simple, individual, specialized tools into powerful workflows that handle all this ridiculous, tedious work that right now you're doing by hand. Um, whether you're a Python developer who reaches for scripts too quickly, or someone who's been intimidated by the terminal, when we're done, you are gonna have an understanding, or the start of one, of how to compose solutions from tools that already exist on your computer. And and I mean whatever computer you use. I don't care if you're using Mac, Linux, Unix, Windows, uh I don't care. Uh every single computer that has made it to today is covered with these tiny tools that do just the right thing, just the right way. And when we're done, you're gonna walk away and know how to stick them together to solve your problem. Uh we've got five um, I don't want to say takeaways. We do have a takeaway, but uh I feel like we have five um specific uh courses of action, things you can do, things you can try this week to start building your personal superpower toolkit. Um this I've talked about a lot of things since I was Jim. Um Jim and I have uh specific goals for this podcast. For me, one of my goals is I want you, the listener, to be better. I want you to solve harder problems, I want you to solve them quicker and easier, I want you to get past the stupid stuff and into the part of your job that's interesting and unique. And this episode is a whole set of tools on how to do exactly that that have always been there, have always been available to you, and you just didn't know about. Um that's the plan. So, um anything uh specific you want to interject there, Jim?

Jim: 14:10

Well, you kind of covered the whole musical composition thing. I was gonna ask about that. Um I I I think your analogy there uh uh about a musical conductor uh conducting the the experts to to make the magic really, really fits what we're talking about here.

Wolf: 14:29

Uh yeah, we're gonna talk about specific tools, and uh I I I I want to say right up front, um everybody who's listening to this podcast, um, the fact that you're listening, I think, probably puts you in the category of a pretty damn good programmer. You want to learn stuff. Just wanting to learn raises you up in the echelon. But I'll bet, um you by yourself could not have written VS Code. You by yourself could not have written Vim or Pycharm or uh Helix. You can do lots of great things and you have specialized knowledge for the problem you're working on, but the fact is you've got tools that are better than you. And it turns out there's an entire set of tools on your machine that are better than you. You don't have to write them. All you have to do is connect them. Um so let me uh give you the and I'm I'm making air quotes that you can't see because this is an audio podcast. Someday maybe we'll fix that. I don't know. But here's a problem programmers comfortable with Python or maybe JavaScript or or whatever, uh, but doing repetitive tasks manually. Uh for instance, a thing that Jim and I do when we start a podcast. We're looking in our GUI recording app, uh, which happens to be audio hijack, and in audio hijack, there's a set of files that were the recordings from last time. We grab those files with the mouse and we throw them in the trash because we don't want them anymore. That's a manual action. Um if you're doing one manual action, maybe that's okay. Uh if you're doing something over and over again, let's fix that. Um so you're probably already a power user in your IDE. Uh you can use autocomplete, you can use refactoring, there's tons of integrated tools. Among the two most important things that your IDE almost certainly does for you is it provides good access to a source code control system. I happen to use Git, there are others, uh, but Git is a command line tool, it's just that your IDE really knows a lot about it and how to give you an interface onto it. Um but outside your IDE, you're clicking through file managers, manually renaming files, copying paths. Here's the promise of this episode. You are going to learn to conduct an orchestra of existing tools instead of writing new programs. Now I know you could write a new program. Uh I I'm working on a GUI app, and our team is small. A thing we do is build it, we turn it into an actual app. The thing that builds it for us is a script. Um one of the guys in our team wrote that script. It's a Python script that builds an application. That's nice. He wrote an answer in Python. But you don't always have to do that. Sometimes the solution to your problem is so simple that you can just connect together three existing things. So here's the core thesis of this entire episode. The command line isn't about learning another programming language, it's about composition.

Jim: 18:35

Tell me more. I want to get into this. This is this is really this is really neat stuff.

Wolf: 18:42

Um well, let me tell you the traditional view, because uh I think uh programmers fall along a scale, and I think most modern programmers um are very attuned to their GUI tools. They know how to use them very, very well. And sometimes uh they have to write some command on the command line. Sometimes you can't get away from saying awk or grep or something. Maybe you could, I don't know. But what I'm saying is you're normally a GUI programmer, and sometimes you have to type a single command on the command line. Some weird thing that Git can do, but your IDE doesn't give you any access to it. Uh a person like that isn't using composition at all. Yeah, they're using the command line, but they're just using it to execute one weird command. Um, and learning how to call that command is actually the hard thing. Making it act act on the right files. Um okay, that's the traditional view. The reality is that the command line. Is about connecting existing capabilities where each tool you mention, and it's not just going to be Git, it's gonna be five things, it's gonna be two things, it's gonna be eight things. Each one of those tools does one job, and it does that job perfectly. The reason we know it does it perfectly is because it's probably been around for 30 years, and every time it doesn't do it perfectly, somebody gets pissed off and it gets fixed. Um the Unix philosophy uh is do one thing and do it well. But the magic, and they don't put this in the quote, the magic is the connections. Um let me let me give you a simple story to start you out. Um this is one place where I'm a little sad that we're an audio-only podcast, because if I could show you pictures, um I think things would be easier to say. But let me tell it to you like a story. Um here's the story. I want to find, in whatever folder I'm in, maybe my project, I want to find all of the Python files that aren't tests. Um so here's how composition works. I tell the computer, find me all Python files in this project. It turns out there's a tool for that. Uh it's a built-in tool, it's available on every platform. The name of that tool is Find. There's open source alternatives, but what tool you use doesn't really matter at this moment. When you're starting in with this stuff, start with the with the basics, the things you have. Your shell doesn't matter, your terminal doesn't matter, the commands don't matter, as long as they do the thing you want. And find, in this case, does the thing you want. You can tell find, look at this directory hierarchy, and give me a list that includes every and only Python files. The thing it gives you back is a hunk of text. Um, and in that text, each line is a full path to a Python file. Um then say filter out any that have test in their name. This filter operation can be done with a tool named grep or several others. Um they can be run in reverse. When you say grep minus v sum pattern, it will repeat back to you the lines that you sent into it that don't match your pattern. So this is a simple uh command, it's grep minus v test. So you start with find. Uh if I'm remembering this correctly, it would be find minus e dot pi, or maybe it's pi. That's find all the files starting here that end with pi. Um and then you use the pipe symbol because what that produces is a hunk of text, and the pipe symbol goes into grep, you say grep minus v test. What you get out of that is that same list of files you found, but all the ones that had test in the name are gone. Uh there's no blank lines, it's still all squashed together. It's just the Python files that aren't tests. Um, and then I say, count how many are left. One of the most basic Unix commands or Linux is WC, word count. Uh WordCount uh does three jobs, it can do them all at once or one at a time. Uh word count can tell you the number of characters that you piped into it, the number of words you typed into it, or the number of lines you typed into it. Because the thing I just sent into it was one file per line. If I say WC minus L, the thing it's going to spit out is a single number. And that number is the number of non-test Python files. Three tools, three specialists, each perfect at their job, composed into something more powerful. The only thing you had to know, aside from that you wanted that information, was you had to know the name of the tool that did that job, and you can start with a pretty small group and have just the right tools to do what you need. And the character you wanted to connect those with, which I already said is the is the vertical bar. Um looks like you have a question on your mind, Jim.

Jim: 25:10

Yeah, yeah. This I'm thinking how simple it is what you just said, right? The the find command pipes through the grep command, pipes through the word count command. Boom, you're done. You got three three commands that are all great at their job. How would you even attempt to do something like that in Python? You know, you'd have to open a directory, you'd have to start reading the entries in the directory, and every entry that you read that is a directory, you'd have to recursively descend into that subdirectory and keep on going, looking for files that match a pattern and counting along the way. It's much harder to grasp. A lot of programmers don't even work on things like that. Um because it's it's clumsy. But what you just talked about doing in shell composition is is is beautiful. I I like it. It's a one-liner. Yeah. Or, you know, you could you could put a backslash after the pipe symbols if you want to spread it out into three lines, but it's it's it's you can grasp what each step is doing. It's beautiful.

Wolf: 26:15

Yeah, and um the so we're doing this all in a shell. Um, and the thing that shells specialize in, the problem that they address, is they know how to find and run programs. If you want to find and run a program uh from inside your Python script, um it's actually a lot of work. Uh you have to you have to start stuff up and launch them and connect it. It's terrible. I don't like it. Um anyway, uh a thing about this is that once you've got that pattern, um find uh grep wc. Once you know that, it's easy to change your mind about how you want to run that. Do you want to look at JavaScript files instead of Python? Do you want to look for backup files instead of test files? Uh you can add on more filters. Uh for instance, you can find all the files that are backups but aren't tests. Umce you know just a little bit, suddenly you have this new power to stick things together.

Jim: 27:41

It's real common to chain these filters together, too. You you talked about one filter, grep. You could pipe the output of grep into another grep looking for a different pattern, and then take that and pipe it through yet another grep. You you could have three or four greps in a row doing this this pattern matching for you. And each one is clearly doing one thing, uh and it it it's easy to follow.

Wolf: 28:04

And I have actually done that? That particular thing that you just said is so important to me. I have an alias. Um, my alias is the word did. So if I want to know the last time I did git add, I say um I use the special notation to grab arguments and stuff. But essentially, what I do is I call history. History gives me a list of every command I've ever issued. We'll talk more about that later. Then I pipe that into grep and find every place I used the phrase git add. And then I pipe the results of that into git, into uh grep, but this time with minus v, and I take out anything that started with the word did. Because I only care about places where I actually did a git add, not this command where I just happened to search for one. Um, and then what it spits out is a list of uh commands with command line numbers, because that's how I uh store my history, of places where I said git add. And because I know the number, and I'll talk about this later, there's special things I can do with the history, like re-execute or edit or all kinds of things like that. But let me move us on to a more complicated composition story. Um and this is something that is almost certainly going to impact people who are trying to run local web servers or processes that do things in the background, whatever. Um this is about finding and stopping runaway processes. So let's not worry about the exact command yet. Let's just talk about the thinking. Um, the first step is show me all the running processes. Take my word for it, there's a command that does this. Then filter for only the Python ones. It turns out that these running processes have a command line that says exactly what is running. Python is going to be in that command line if it's a Python program. Then extract just the process ID numbers. Then kill every one of the things that you had that were left. Um that's exactly the same kind of thing we just did. It's a sequence of individual commands good at the one thing they do that end up with the result you wanted, which for sure your IDE did not provide for you. Um there's a pattern. Notice the pattern. Each tool does its specialty and passes the results on to the next.

Jim: 31:08

Alright, so I I get it. You you you get a list of the processes that are running, you pipe it through grep to filter it, you pipe it through a few more things, and eventually you finally run kill on the process ID. Uh, that's kind of scary though, uh, kind of dangerous for people to be killing processes. Uh, do they need to learn how to do complex stuff like that right away?

Wolf: 31:30

My feeling is that you uh you probably want to crawl before you walk. I feel like uh you can build a pipeline, that's what we call these things, pipelines, whenever there's more than one command involved and you say them together in a row and you send the output from one into the input of another. That's a pipeline. I feel like there are simple commands, and you can start with a two-command long pipeline and still have something useful that solves a real problem you have. Yeah, I'm giving complicated examples to help you understand just the range of power, and believe me, I'm not even close to showing you what you can do, uh, but I want you to start one at a time, two at a time. Um, and we're gonna talk about a path to learning this stuff uh a little bit later. But the complexity is gonna build naturally as you get comfortable. Um, this is just like I I do an exercise program every other day or three times a week, whatever. And and a thing the guy on the fitness video says multiple times per session, every single time, is he says, do what feels right for you. Yeah, we're gonna say some complicated things, but for sure, start easy. This actually is easy stuff, and there actually are easy commands, and if you start there, you're going to feel confident and knowledgeable and ready to move on quickly. That's my feeling. Um, in fact, why don't I right now hit on the very most important. Remember, I said there's um, gosh, it might be in the hundreds of individual tools, not just the ones that come with your OS, but that you can download because they do new and interesting things, or because they do existing things better. Let me hit on just the five or six basics under each of the most important parts of you doing composition. First, let me talk about uh text processors and filters. We already talked about grep. Grep looks at individual lines, decides if it matches a pattern, and then, depending on what you've said, either lets that line go through or stops the line from going through. That's a simple explanation. Um we used the pattern test. That's simple. It turns out grep can do a lot more complicated things than that, but don't worry about it. Just worry about does it have test in it? Um there is a tool called sort. Um, you hand it messy data, uh, and it it does what you think. Uh you can it might be that the data you're giving it isn't just a list of individual words. They might be full-on lines, so you need to tell sort things like sort by the third column, treat it numerically. You know, sort can be complicated, but it's one of the basics. If you just use it with the word sort, it's gonna do what you want, and it's key to getting some things done. Unique. Uh it's spelled funny, U-N-I-Q. Uh unique does two interesting things. Um, it does the thing you think it does. If you've got a list of 20 items and seven of them are duplicates, uh the thing it prints out is a lit I don't I don't know if I'm getting the math right, but 13 items. Essentially, every item in the output is the only case of that item. Everything that was a duplicate is removed, but they don't remove enough that that whole thing is gone. So unique can be super useful. That's a thing I use with git all the time. Uh, git has several different commands that will list files that you care about. Umified and you need to fix, or who knows what. Um it turns out a couple of the different ways that you can ask for these files will say a particular file name multiple times. If I pipe that into unique, I can get rid of all the extras. Um and that turns out to be useful. There's a pair of commands that I use all the time. Um, head and tail. Um they are amazingly simple, as almost all of these commands are. Head, you pipe in a file, that file might be gigantic, three gigabytes, who cares? Head returns to you, prints out, um, just some number of the initial lines of the file, and it makes sure not to waste time worrying about the rest of the file. Tail is exactly the opposite. Send in some big file, tell it you want the last ten lines, or whatever, they take parameters, um, and get just the last ten lines. Um head and tail are super useful. Let me give you an example. Um if you want to know the three biggest files in a given directory, be in that directory and say ls. Ls lists the files there, and it takes an option that will list them by size. Uh the largest first, the thing it produces is a list in the form of text. You send that into head, and you say just the top three. And what you get back is the three biggest files in that directory. Um that's composition. It's simple composition. Um and finally, one we talked about using, WC. WC gets used all over the place. It counts lines, words, and characters. Um, it can do them all at once, it can do them one at a time.

Jim: 38:14

Uh you know what, there's two commands you missed that I I think are incredibly important. Uh the first one is diff. I use diff all the time. What that you feed it two files, and it gives you the difference. I I guess you can't really use that in a in a pipeline, though, right? I mean the output you could use in a pipeline. I'm not sure that you could use the input in a pipeline. Anyway, diff is an incredibly important tool to me.

Wolf: 38:41

There um just to look ahead, stuff I'm actually not going to discuss in this episode. It turns out that there are ways to uh use whatever shell you're using to uh specify a process, and that process has output, and the characters you put around calling that process turn the output that it produces into a parameter, an argument, a text file input into some other command. So the thing you want. That's right. The thing you pro actually process substitution, but the thing you want, you can have. Yes. And the output of diff, you can have. And you can do the right thing with it. It's complicated. That's the main reason I didn't.

Jim: 39:38

Yeah, diff in a pipeline would usually be the first thing in the pipeline that's going to get you the data that then you can filter. Uh the other command is more. Uh or or it's uh its friend less. They both do the same thing. I think less is an open source version, more is uh kind of a standard Unix command.

Wolf: 39:56

You should use the word. They are pagers. Page or whole job.

Jim: 40:01

It'll give you a page at a time. So you might have a command that spits out an awful lot of data. Maybe you're running this fine through grep and it's spitting out you know a thousand lines and you want to see it uh uh in a page at a time. Pipe that into page into uh more and it'll show you one page at a time. And it's got there's fancy stuff to it that you can search and and that kind of stuff, but uh just more is incredibly useful in a pipeline.

Wolf: 40:30

I totally agree. Um I tried to keep this list short because I want people to play with the easiest things. But though but the tools you named, 100% useful, 100% on my list. Um I absolutely use them and in exactly the way you just said. Um so those are the filters, but there's also the data sources. Um the things we just talked about always take something in and then spit something out. That's what I mean when I say filter. They make some change. Uh but there's also things that just produce data from scratch. For instance, find. When we used find in our example above, we didn't give it any we didn't pipe anything into it. All we said was tell us all the Python files. And then it produced something. It produced a list of full paths that ended with.py. Um so that's a producer. Um, it's a data source. Ls, we talked about that. Whatever directory you're in, or if you give it special parameters to make it look elsewhere, ls will give you a list of the files in that directory. Uh PS, that's the command we didn't name when we talked about handling runaway processes. PS lists running processes on your system. Uh you may need that, probably not right at the end of this episode, but but soon. Cat, um cat is a tool I use all the time. What cat does is you give it a file, and uh from that file name, which is almost always a parameter, you say cat foo.py, whatever, um, it prints the result to your screen. If you then piped that into more or less or whatever you wanted to use, or sent it into your editor, or uh made it be one of the things that you wanted to go into diff. Um cat has a super simple job, but that job is incredibly useful. And finally, something I am going to talk about later, because I think this is so important, and that is uh, and it's built into every shell that you might use. Uh and like I said earlier, what shell you start with um really doesn't matter all that much at this level. Later you'll have ideas about why you want one or the other, but for now it doesn't matter. They all provide a history command. Um history produces an ordered list from the oldest you have allowed it to remember. If you make it be that history stores everything in memory, then it's only the stuff you've done this session. If you tell history it's allowed to save things in a file, then it's every command you've ever issued up to some limit. Um history uh is another data source. It produces lists of commands you have executed. So that's the important thing for what I'm talking about right this minute. The thing I'm going to talk about is as you are learning about composition, you're going to say things to yourself like, what the hell did I do yesterday? I remember that I did a thing, and I history what you did. Yeah. Um, okay, and finally, so we talked about the processors and filters, we talked about the data sources, and finally, there's the things that connect all those things together. What you use to build a pipeline. Um, and there's a couple of things. I think of the three things I'm about to say, the most important things are pipes. A pipe is uh usually expressed as the vertical bar in some programming languages. That's the OR character, or half an OR character, or it's bitwise OR. It's the vertical or. Um and what the pipe does is it says take whatever the output of the thing on my left was and use it as the input to the thing on my right. Absolutely the most important uh for building a pipeline character. Uh and the second most important thing is redirection. When you run a command, um the default thing that that command does is it works on what we call standard in, whatever you've sent into it, maybe using that pipe command, and it prints stuff to the screen, and it mixes in with that anything that you've printed as an error. These three different possibilities are called standard in, that's the thing that went into the tool, standard out, that's what got printed to your terminal, and standard error. That's only things that you have expressed as errors, and without special handling, they just mix together on your screen. It turns out there are special characters using the greater than sign and the less than sign, and these specific files have magic numbers. Uh if you use those numbers and ampersand i I don't care. You don't need to do those things this minute. Um and when you do need to do them, um you'll know where to look. It'll be it'll be easy to figure out. So those three collections oh, I forgot to name the third thing in command composition. Um we were talking about diff um command substitution, um, where you can say, running this command produces output that should be considered a parameter to this function. It's advanced. Some shells suck at it. You're not going to use it in the next six months, but I'm telling you so you know it's there. Um so real composition stories um that exhibit this pattern because this is the change I want to make in you. I want you to stop thinking about the problem you're having as one of these two things. I don't want you to think, oh my GUI must do something for this in a menu. I don't want you to think that. And I also don't want you to think the thing on the other end. Oh, I could just write a Ruby program that solves this. Both of those are almost certainly wrong. What I want you to do is I want you to think about what tools you know and how you might combine them so the total amount of code you end up writing is zero or close to zero. Um for instance, finding some of the large files that are eating up disk space. Uh this is one I actually just talked about. Um find all the files in this directory tree. I said do that with ls. Then sort them by size, largest first, you could do that with sort. Then show me just the top ten. You can do that with head. Um you only need three tools to do this, and it answers your question, and it took you two minutes. Um that's gonna be in your history, if you care about it later. If you don't trust history yet, you can copy that one line of shell scripting and paste it into your uh text file of interesting saved pipelines. Um It's an easy answer. A hundred times easier than either of the two extremes I gave right before this.

unknown: 49:22

Uh-uh.

Jim: 49:24

Alright. How do I tell these tools what I want? You're talking about using find to uh uh to find largest files, to find big files, right? Um how do I tell it uh that I only want files over a certain size? How does that work?

Wolf: 49:41

Okay, the beauty of the command line and of these individual tools, so far I've I've talked about very simple ones where you don't have to tell them uh very much about how to do their job. But the beauty of these tools is something you don't get uh from a GUI. Uh and by GUI I mean VS Code or on the Mac the Finder or in Windows the Explorer or um Zolfin in KDE, whatever. Um in those you double-click on a program and the program runs, and that's all you got to tell it. But on the command line, there are lots of ways to fine-tune what you want a specific command to do. Uh you can tell you can use uh IO redirection, like we just talked about, and that almost doesn't involve the tool at all. But also many of these tools take arguments and options and parameters. For instance, when you say git add foo.py, uh foo.py is an argument to git add. You're telling it, I want you to do something to foo.py. Lots of the more and more interesting commands that are available to you take arguments or flags. It turns out that um the find command knows specifically about the notion of file size and it understands numbers, you can tell it, only show me files that are greater than a hundred megabytes. And by the way, um if you are using Git and you're building a Git repo and you have a file, and that file is a hundred megabytes, please do not add that uh file to your commit because even removing it later is not going to make your repo smaller.

Jim: 51:53

All right, everybody raise your hand if you've made that mistake before. I know I have.

Wolf: 52:01

Um anyway, uh find is a pretty complicated command. You can use it pretty easily, but it will do more and more and more sophisticated things. It'll find things by pattern, by size, by file type, by location, by um uh actual whether it's a directory or it is a file, uh, or that it's one of either, or that it's a link, that it's a symbolic link or a hard link. It it can know these things. Um, it can know how recently it was modified or created. It can get you only the ones that are older than that. There's a ton of things find can do. Do I want you to start with these? Absolutely not. Um I don't even know if I want you to start with find. Um, but I want you to know this. Um everybody uses find or FD or some tool that's not unlike these. And there are ways to know how to call these things and get what you want. Um there's a thing built into your shell called man, M-A-N. That's short for manual. Um man is just another tool, just like any of the ones I've talked about so far. Uh, but man uh prints out documentation. There's uh a a couple others like that info. That doesn't matter. Almost certainly what you're going to do is you're gonna Google for the find command. Or maybe you're gonna use ChatGPT or whatever particular AI you like. It turns out I have a thing that I really like. Um it is a command line tool, it's non-standard, um, but it's pretty easy to install, and there's multiple um implementations of it. The name that covers all of them is TLDR. That stands for too long, didn't read. And what TLDR does is it's like man the good parts. When you look at the man page for something, it might be 20 pages of dense text. But when you run TLDR about find, it will print one screenful, maybe a little more, that shows maybe six different ways to call find. And each way it shows the exact command with the exact arguments and file names, and then a short description, what does that mean? Um I TLDR solves most of my problems, and if they don't, then I'll I'll go to the AI. Um I feel like like that works for me. Um anyway, uh you you've got what looks like a question on your face, Jim.

Jim: 55:15

You know, you you're talking about a long chain of tools here. Uh for for somebody just getting into this, um, how how do they know how to make the distinction between what they should do as a as a uh composition or should they just break out Python or Perl or whatever? How do they know?

Wolf: 55:37

Um well I have a rule for myself. Uh let me tell you what my rule is. Maybe this works for you too. If the things you want to do already exist and all you have to do is connect them, then building a command pipeline is almost certainly the right thing. If it's something incredibly simple, like deleting a single file uh inside VS Code, maybe you just want to right-click on that file with the mouse uh and use your GUI. If it's editing a Photoshop file, yeah, that's a GUI task. If you have to make up new data structures, new algorithms, new things that don't exist right now, maybe you want to write a Python program or a Pro program or a Java program, whatever, whatever your forte is, that's what you want. Um a lot of problems can be solved with these uh pipelines, and the reason so many problems can be solved with them is because these tools have evolved as we've come along. That's all we had to start with. And nobody deletes them, they keep adding new ones as we come up with new tasks we want to solve. So my feeling is if you can understand what you want, and it's obviously not a simple GUI task, probably start with the command pipeline. I want you to succeed with that. If you can't, you can't give up and write a program or or do whatever you have to do. But I want you to start with the thing that is going to be the easiest for you. Maybe not right this minute, but it will be the easiest for you sooner or later.

Jim: 57:47

Um But this is um uh you're talking about a chain of uh programs, right? Um wouldn't you say that it's more maintainable? If you're gonna do it as a shell script or or a shell pipeline, it's more maintainable than a Python script uh because each piece is simple, testable, and you can modify individual steps easily.

Wolf: 58:17

Is that uh sound about right? Those words that you just said, I 100% agree with. I love Python, and in fact, um I have two major shells I use. I use bash and z shell. Uh those those things don't matter. Um but the thing I'm going to say is, I love Python more than I love bash and z shell. But it's just better to write a command pipeline at least half the time. Um it is the right answer. So often, you really ought to start with the right answer. Because the whole thing we do as programmers, this is our job. The first thing we have to understand is the problem, and the second thing we have to understand is what are the right tools to address that problem? And, you know, I love Python, but the fact is Python isn't always the right tool. Um, and there's just a ton of tasks that are part of our job where building a command pipeline is the right answer. Um yeah, I don't I don't think you sh you uh ship shell scripts to end users, but so much of our job is doing these specific things. Like for instance, I've got a thousand um ping files, and because I'm sending them to my validation team, they all need To be resized and turned into JPEGs and have better names. Um, I can write a Python script to do that. It's it's easy enough. It might it might take me three hours. I don't know. Um it turns out that there is a uh tool called ImageMagic that does every single one of those things. We'll do it instantly, and we'll do it to a list of files. All I have to do is build the right pipeline. Um I think um this this whole thing uh is it's a s it's an in-between place. Yeah, we are great at writing programs. That's why we do what we do. We're not just great at it, we love it. We want to do it. And we're good at using modern GUIs. Uh, you know, with the auto-predict and the refactoring and the complete and the look up the definition. Uh that stuff's so great it's it's almost fun to use. Here's a new level. Something in between. I promise you it works because old guys like us have been using it since before there were GUIs. This stuff works. Once you know how it works, how you can exploit it to get what you want, once you know those things, uh I'm gonna use the word from the from the intro. This will be a superpower for you. Your teammates will be writing a goddamn Python program that takes them two days, and you will have the answer in ten minutes, because you hooked together the commands in a pipeline that did exactly the right thing. Um, and once you understand the basics, once you understand how to connect things, each new tool that you learn, and and you can learn them as fast or as slow as you want, it multiplies with every other thing you already know. Um those five core tools I talked about, uh, just those can create potentially hundreds of useful combinations. Uh if you learn one more tool, suddenly all your existing knowledge becomes even more powerful. Um we've told you a lot about um what you're getting, what we're offering you. But let me give you a path. Um I feel like the most important thing, and I said the words before, is to crawl before you walk. I think this is all doable. I think this is all totally within your skills skill set, and I think this will give you superpowers. Um I think uh the things to know to start off is don't abandon your current tools. If you're a VS Code user, use VS Code. VS Code is your friend. If you use PyCharm, use PyCharm. I don't want you to make your life worse. I want you to add things that make your life better. Um a thing all of these tools will let you do is you can right-click in your file manager, um, and that might mean Windows Explorer, or it might mean the Finder, or it might mean Dolphin, or I I think it actually works in VS Code. Click there, right-click there, and say open terminal here. Um from that point, learn basic file navigation. Maybe you already know, maybe you know what C D does, and maybe you know what LS does, or in the case of Windows, uh dir. Um but that's where you start. It's it's the file system. Start there. Umce you're comfortable with that, you can get a terminal, you can type a command, you can hit return and see what that command does. The next thing to do is scratch an itch. Uh pick one thing that you do over and over again that annoys you. Uh for instance, finding files modified recently, checking what's using disk space, seeing what processes are consuming CPU. Uh, these are separate things. I'm just saying one of those probably annoys you. Um learn just the composition pattern that solves that specific problem. Um and then but keep using the GUI for everything else. Um I mean, the GUI works for you. You are a programmer, you're doing the right thing. Um and the goal for this is to experience your very first. Holy crap! This is so much faster. Um that's what I want you to feel. That's what I want you to try to suppress saying. Um Good things are gonna happen to you. I want them to happen to you. Uh the next thing to do is uh you've done one tool. Um, you've you've done the file system. Now start hooking things together. Uh chain a couple of the tools you already use. Uh use ls, or whatever it is on your machine, could be dir, uh, to find just the text files or log files, and then pick out just the first couple. Maybe they're the most interesting. Maybe you've arranged by date, so they're the most recent. Um that's a chain, that's uh a pipeline, that's useful. Uh practice taking some existing composition, something you've already written. Update the search terms, add more filters, try different sorting. Um, like I said, uh maybe you're building up a text file where you've pasted one of these commands on each new line, grab it out of there. Maybe you've advanced all the way into using history. Um if you use history, um your uh shell almost certainly supports the up arrow key to go back to previous commands, or maybe control R. Ctrl R lets you type a pattern to find a command. Uh I re excuse me, I recommend starting with a text file that you build yourself. That way you can keep the ones that work and not add the ones that don't work. Um modify, change the terms, add more filters, try different sorting. The whole goal of this is thinking. Thinking in terms of this tool, then that tool. Instead of individual commands.

Jim: 1:07:53

Uh how do you remember all of these combinations? There's there's an infinite number of possibilities.

Wolf: 1:08:02

So uh this is where I feel like history is your friend. And I all I already mentioned the notion that you take the ones that are particularly good for you, that you liked, you're proud of, that had the right results, and that you add those to a text file that you take care of. Maybe even check it into Git, I don't know. Um, but every single shell, no matter what you're using, has history. They will remember the commands that you've entered, and you can find the things you've done before. Um, it turns out once you get good at this particular facility, which is not what this episode is about, um, you can edit commands that you've already written straight out of history. Uh you can copy and paste them. Like I said, start with a text file. That's that's my feeling. Um I think we already talked about getting help with the individual commands, and I think that's pretty personal. Uh you might be a Google person and you want to use Google to find the answer. And believe me, Google knows the answer. Um, Google often knows the actual manual page for a specific tool. It'll take you right there. I don't really like manual pages because they're so long and dense. I really like that TLDR tool. Too long didn't read. On my machine, uh you have to install it, no matter what. On my machine, which is a Mac, I used Homebrew. You can use Homebrew on Linux also, or you could get it through apt. Uh and there's a bunch of different implementations. But TLDR is good. Um, whatever your favorite AI is good. Um so from solving problems with command pipelines to um building up a library that does things. Remember, I talked about adding them to a text file? Um, annotate that text file. Uh, you're going to end up with a lot of pipelines in there. Say what they do, say why you needed them in comments. Uh most shell comments start with the pound sign. Um and as you look at these, uh you're gonna start recognizing patterns. You're going to see how things you did two weeks ago or last week are like the problem you want to solve today. And that's gonna give you ideas. How am I gonna do this? You are on the path. Once you start seeing old things, understanding what they mean, and how that applies to the problem you're on right now, you have a whole new way of solving problems. A way the other people on your team don't have. You are better than them now. I wouldn't take that lightly. Um what's going to happen is you're going to stop thinking to yourself, how how did I do this? And start thinking, what have I done that's similar? Um. And I don't know how far in the future this is, because I feel like I've I've covered the topic of the thing I want you to know. Um, but these pipelines are really automation. But they're automation that happens right then. If you saved them into an executable script, um you could do things to them that made them be real, full-on, let's say you're using bash, bash scripts. Instead of just running them in a directory, you could make them have arguments and use them on hundreds of files and do all that. I think that's out of scope. But I am saying, once you have been working on that history, once you're thinking this way, once the default in your mind is what things already do this that I can just stick together, the next step for you is making the computer run scripts. Um you look like you've got questions on your mind, Jim.

Jim: 1:12:52

Yeah, there's a there's a lot to unpack there. Uh, a couple of things I wanted to ask. One is uh everything you're talking about just sounds like Unix in Linux. What do you do if you're a Windows developer? So help them out.

Wolf: 1:13:07

On Windows, um, I can name first of all, there's WSL. Uh that doesn't answer the question because WSL is typically just Linux or Unix, so that's not satisfying. But um there are at least three different shells available to you on Windows. There are some things that aren't the same. Um but uh the three things that you might care about are uh you might care about command.exe. That's the thing everybody gets by default. You might care about um PowerShell. Um if you don't have command.exe, it's probably because you specifically asked for PowerShell. And finally, um you can have bash. Um there's several different ways to get it. I have bash on my Windows machine, not under WSL, provided by uh get bash for Windows. Um bash is gonna be just like everything we've already talked about, but key to know is that the things I said, um command.exe and um PowerShell, the words are different. The names of the commands, but the idea of hooking them together into a pipeline, uh, that's the same. Um I they they might be different characters. I don't I don't use either of those all that much. But the point is, um whatever shell you're using, you can play with and grow into this superpower.

Jim: 1:14:56

You know, we we we talked about uh you run a command to produce some data, uh you pipe that into another command to filter the data, maybe a command to sort the data, uh, another command to unique it to you know get out duplicates. Uh each step along the way, you're not changing the original data, you're creating new data from the old data. That sounds like immutability to me. Right? Uh you've got separate steps that each one of them does something specific. Man, this is starting to sound like functional programming. Uh we covered that back in episode 100.

Wolf: 1:15:38

100% right.

Jim: 1:15:39

This is have we been doing functional programming all along?

Wolf: 1:15:44

You totally hit it on the nose. Um that's what it is? Yes. Uh command pipelines are almost always functional programming. Now it turns out there are some commands you can stick in there that sort of screw it up. Um there's a command called T T-E-E. Um that can make it different than what we're what we're discussing. I don't think we need to discuss T, but if you're interested in that, man T. Yeah. Uh the main thing to know is your observation right on target.

Jim: 1:16:21

See, I can be right once in a while. Oh, let's keep going. This is good stuff.

Wolf: 1:16:32

Um Okay. Uh I want I already talked about um when to use composition versus when to actually write a general purpose programming language program. Um and basically uh the thing to know is uh when you outgrow the functions available to you in these command line tools, um, if you need some kind of special uh data structure, uh most of these tools, these commands, uh don't they might have data structures inside them to help them do the thing they do. Diff in particular has some very interesting data structures. But most of them uh don't expose those data structures, you don't get to use them. Um a shell, like bash, um, does supply some some things you can use, like it has a hash table in uh recent versions of the shell of bash. Um but if you need advanced programming tools uh and you're going to do things that's less about executing some existing command and more about um using algorithms to figure out what to do, probably you've advanced into the territory of writing a full-on program. Um if you're ed and like I said before, if you're going to change the color of a pixel in Photoshop, probably you're just gonna use the mouse. So those are the two ends of the spectrum, and a very large fraction of what's in between is about building the right pipeline. Um I have no problem looking at a situation, looking at a task I want to accomplish, trying to solve it with l what looks like the easiest tools to me, which are often a pipeline, and then after getting a certain distance, saying to myself, yeah, maybe not. Maybe I can't do it with this. I guess I'll write a program. Um that's that's certainly possible. I'm now I'm gonna say something incredibly controversial. Um something that will absolutely get me yelled at. Um, and that is this. Um all these shells, bash and uh Z shell and all of them, um they are all full-on programming languages. Um just like Perl is uh uh has a lot in it that's about solving string problems. So strings and regular expressions are s are are a native thing to Perl. If you're working on string problems, Perl is your answer. It's a great language for that. Shells, all of them, um are are really about a couple of things. One of those things in particular is Is finding and running existing binaries. Like where is LS? Um, you know, it turns out that for sometimes ls might be built into the shell, but can't there are lots of things that aren't. And shells are about running those programs. There's a couple other things that shells are tuned for. Um your Python program, let's say, uh has to open up a library. It is in the standard library, it's about processes, um, and it has to open up a a sub-process to launch one of these commands, and there's a lot of boilerplate and syntax around it, and there's um stuff that's actually happening at execution time, um, it's harder and more costly to run an external program from a Python script than it is to run it from the shell. Probably that doesn't matter. Probably that difference is very small. But when you look at your problem, if your problem is fundamentally about running external programs, especially many, many times, especially many different things, and redirecting their I.O. probably bash is better than Python for writing that script. But if your program doesn't run that many external tools, does do things that Python is really good at, then maybe Python's the right answer. Um if you start with one, it's it's not that hard to move to the one that you have decided turns out to be the better answer. Um I don't know what the evidence will be for you that it's the better answer. Um if we go back to our performance and optimization episode, uh the way you would know is because you're measuring, because of course you're measuring. Um and sometimes you just like writing the Python better. Um I feel like, before I did work on this episode, my feeling like, my feeling was that if you're writing a bash script to do some task, first of all, if it's you, if you if it's an if it's a programming task, because like I said, if you're shipping it to a user, it's not gonna be a shell script. So if it's you, if it's for your job, if you're doing a programming task, if you're writing it in a shell script, my old feeling used to be if you had to have a hash table or you had to have a loop, just write it in Python. That was my old feeling. But after really thinking about and researching this topic, I feel like using uh pipelines to solve problems um extends way further into the range where old me would have just sss skipped on over to Python. I think I was wrong, and I think I have better answers now. Um that's what I feel. Um so I think the key insight here is most I should write a Python script for this moments are actually probably two or three shell tools composed together. So before you fire up your IDE, ask yourself, am I really creating a brand new capability here? Uh, or am I just connecting some things um that already exist? Um at this point I would talk about history. Um I think history is one of the most important things in your shell. I use it non-stop. In fact, I use history so much because I'm constantly taking commands I've recently run and fixing them just a little bit. Um I use it so much that I actually use a third-party tool called Atun.

Jim: 1:24:40

Um but the fact is that's uh A-T-U-I-N.

Wolf: 1:24:45

Yes. Um I'm gonna actually dive in a little bit. That's the name of the turtle in the Terry Pratchett books that supports the disc world on its back. Um it's an amazing tool. I can't live without it. There are changes I want to make to it. History is a complicated thing, there's a lot of things you can do with it. You'll get there. Um What I want is I want you to type things into a shell. I want you to connect some basic commands, and I want you to go forward from there. History's gonna help you later, um, but I don't I don't think you need that uh right this minute. Let me we're getting close to the end, and I think this is probably our absolutely new longest episode. But here is your call to action. First of all, just like everything else, don't switch everything at once. Don't abandon your current workflow. Um existing file managers, uh, and you can't see me, I'm using air quotes here. Open terminal here feature. Practice basic navigation, uh, especially in directories, locations that you already know. You know what's there, you know what you ought to see. Um, and your success metric is navigate to one of your project folders and list its content via command line. Okay, step two. Find one annoying repetitive thing you do. Something absolutely frustrating. Uh, and I don't know about you, but I'm constantly faced with frustrations. And a problem with me is that if something frustrates me, I will immediately focus all power on it. Probably that's not right. Um something that you normally do through the GUI. For example, finding all the files you modified this week, checking which folders are using the most disk space, seeing what's consuming CPU. Uh learn just the composition solution for that one specific problem. The things I just said are three specific problems. And your success metric for this is that whatever that annoying task is, you get the answer faster through composition than through clicking around. Um Step three, this is where I want you to adopt thinking about connections into your into how your brain works. Um this is it. This is the primary school uh skill. Um I want you to start thinking this tool, then that tool. Uh start simple, show me the files, then filter for the ones I want. Uh practice modifying. Change what you're searching for, add more filters, try different sorting. The success metric here is when you see output from a command, you naturally think, I could pipe this to something else. That should be the first thing in your mind. What else can I do with this? Um Step four. Uh start with the things your system gives you. There's so many options, and they so don't matter. Uh any terminal application, any shell, you want to focus on composition concepts before trying to pick the right tools. Don't get distracted by trying to find the best setup until you prove that this whole composition thing works for you at all. Uh the superpower thinking transfers between any tools you choose. Um for instance, on macOS, the default terminal shell that you will get is Z Shell. I don't care. Use Z Shell. Whatever you learn in Z Shell is gonna apply to Bash, it's gonna apply to PowerShell, it's gonna apply to CornShell, it doesn't matter. The shell does not matter. Worry about composition. Um the success metric here is that you're comfortable creating basic compositions regardless of which specific shell you're using. Um and finally, uh build your personal composition reference. Every time you do something that works, every time you do something you like, stick it in your text file. Make sure that text file has a good name. Write a nice clear description, like find Python files without tests, or shows biggest files in the project. This becomes your personal superpower reference manual. You are going to outgrow this in at least two ways. Um first, eventually, history is always gonna be your answer. And second, it won't be long before you don't need to look at the things you said before. You just know. Uh, and your success metric is that you find some old composition to solve a new but similar problem.

Jim: 1:30:43

There's a lot there. How long do you think this would typically take? Um when when should somebody expect to go from a complete beginner to uh they feel like they have superpowers?

Wolf: 1:30:57

I think this is quick. Um, the words I'm about to say might not sound quick, but I think, first of all, um we're talking about programmers. These are people who understand programs. Um, they've got knowledge, they know how to interact with their computer, things are happening. I feel like most of the people in this group hit their first real, and I'm making air quotes again. Wow, this is so much faster moment, uh, within a week, maybe two, uh, of focused practice. The genuine superpower feeling usually comes um in a month or two, uh, when you start automatically thinking in terms of composition uh when you encounter a new problem. But e everybody's different. Um some people get completely hooked after their first successful pipe, others need more time to see the value. The key is starting with the real problems that actually piss you off. Um and maybe this isn't for everyone. Uh maybe the GUI is exactly the thing that you want. Um I think these can help you. Um let me um uh give you a couple of takeaways. Um I have given you the conceptual framework, the command line as a composition uh and orchestration. It's not about memorizing cryptic commands. If you have to memorize a command, probably you're down the wrong path. The specialist tools already exist on your computer right now. Uh and we know they're there because these are the things experts have required and asked for and written themselves over the course of the last 30-40 years. Uh, all you're doing is learning to conduct the orchestra. Every composition you create becomes part of your growing personal capability. Start now, start this week. Pick one repetitive, annoying task and figure out the composition-based solution. Um, your journey from a GUI, dependent programmer to a composition master starts with connecting just two simple tools.

Jim: 1:33:44

Well, there you have it. Uh your keys for uh gaining a new superpower. And uh, you know, a lot of us old guys, Wolf and I have been doing this for a long time. We started out in this world doing uh uh command line programming, uh composition, stuff like that. Um, but I'm afraid a lot of the a lot of the younger developers, you know, they're using VS Code or they're using Xcode or they're using PyCharm or whatever, and they just don't get exposed to this. Follow uh what Wolf said, and you will elevate your skills. Uh that new superpower will really come in handy. So thanks for that, Wolf. Um I I I think it's time to wrap it up. Uh boy. Uh we've been talking for uh 95 minutes. Uh there's some pretty good information there. Uh this is our longest episode so far. And as I said back at the beginning, uh we really like some feedback. Uh any feedback is great, but we're particularly interested in feedback about uh episode length. We we want to give you guys the the the amount of content that you'd like, so tell us what that is. You can send that to feedback at runtimearguments.fm. Uh if you want to get a hold of us uh individually, I'm Jim McQuellen. Uh my email address is jam at uh runtimearguments.fm. And my partner here is Wolf. Talk to him at wolf at runtimearguments.fm. We're both on Mastodon. You can find us there. Um lots of ways. Uh we do have a website, runtimearguments.fm. Check us out there. Um until next time. Uh thanks for listening. Thanks for coming along. And uh and Wolf, uh, got anything to say?

Wolf: 1:35:43

I want to I I I know this is beyond my skill set, but I want people to be smarter. I want to be part of making them smarter, and I feel like maybe this episode helps.

Jim: 1:36:03

How do we top that, huh? All right. Thanks a lot, everybody. Until next time.