4 ms·
Learning command line options is like learning hundreds of DSLs. It gets worse when you have to learn more, or different, sets for different platforms, like Li
by efitz 2y ago
Learning command line options is like learning hundreds of DSLs. It gets worse when you have to learn more, or different, sets for different platforms, like Linux vs MacOS.
Unices, by design, intend for you to compose many of these, so you not only need to learn the DSLs but you also have to learn the input and output formats, and learn even more DSLs to “glue” the commands together.
Finally, you need to learn yet another language (typically bash) to compose these together.
So using the CLI either slows productivity greatly as you have to look up everything, or requires years and years of time investment to become proficient, much of which investment is non-transferable.
I think that Microsoft PowerShell makes many of these problems much better, but aliasing for brevity re-introduces some of the toil involved, and afaict psh has not gained traction anywhere but Windows.
- xerox13ster 2y agoPowershell is so asinine I don’t know why you would bring it up unless you’re a blue badge crypto posting for Microsoft. Do you want to talk about portability and transferability? It is the epitome of non-transferable and non-portable. It is a domain specific shell language built for the Windows operating system win32 only. It does not work on Mac. It does not work on Linux. If you somehow managed to replace the Win32 shell with something else, it doesn’t work. Bash or at least the shell script in UNIX has been going for 50 years. Power shell was shit out of Microsoft’s ass in 2007 and reached “usability” in 2013. It broke compatibility with batch scripting, you have to call cmd to get batch scripts to behave. It broke compatibility with W scripting, or rather, justified to MS that abandoning script host was a worthy goal. It does not follow any of the same conventions as the Shell scripts and terminal commands that windows had used for decades at that point. If I want to accomplish something in powershell, I have to go look it up or I have to trust some command that somebody’s written on stack overflow will do what they say it does because I don’t have the time or the energy to go through and look up every single aspect of the command for a domain specific shell language that only works for a single operating system & that is worthless with any other system. I spent probably about a decade of my life from 11 years old to 21 years old learning to use the Windows command line and W script. To the degree that I literally automated myself out of my first tech job. So therefore, my decade of time investment to become proficient with Windows scripting is non-transferable and Microsoft decided to throw it out. If I had spent that time learning UNIX I would have been able to immediately go and use any other UNIX system and probably would’ve been able to get a much higher paying job at the start of my career.
- zokier 2y agohttps://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/insta... https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/insta...
- jcranmer 2y agoThe problem with shell scripts are that they are objectively badly designed. And I do mean objective--there is no reason to accept that "accidentally delete your home directory" is a sane default behavior for "oops I forgot to set a variable". Any project that attempts to make shell scripts not broken is, by design, going to have break compatibility, because compatibility is insane. Powershell is interesting because it's attempting to introduce a different modality into shell scripts--rather than marshalling data as streams of bytes, you can actually represent the output as, well, data. So that a producer program can say "I'm outputting a list of files" and the consumer can actually handle it as a list of files and easily deal with the fact that maybe files have weird names like " ". A task that, for all the 50 years of experience on UNIX, still requires you to jump through hoops in every other shell script.
- Reasoning 2y ago> If I had spent that time learning UNIX I would have been able to immediately go and use any other UNIX system and probably would’ve been able to get a much higher paying job at the start of my career. You'd probably be on here complaining about systemd and iproute2.
- xerox13ster 2y agoI spent the last 10 years learning Unix and I’m certainly complaining about systemd.
- gregjor 2y agoNot transferable? In the context of the most widely-used server operating system? I have transferred Unix skills for decades, from one job and project to the next. Even Windows can run a Linux subsystem now. Having learned Unix/Linux and many of the tools myself I challenge the "requires years and years of time investment to become proficient." You missed that the knowledge and skills grow incrementally, so while you get to proficiency your skills constantly improve at the same time. You don't have to stop everything, study Unix for years, and then go back to doing something "productive" once you've memorized it all. Unix has one file format: plain text. The tools all compose around that. You can of course find exceptions -- you can't express everything in plain text -- but you can get remarkably far with simple single-purpose tools redirecting their output to the input of another tool. The core tools have more consistency than you give them credit for, describing them as hundreds of DSLs. They all have man pages, they more or less follow the same conventions with I/O and flag names. Plenty of exceptions, sure, but no more than you find in any large legacy system that has grown and adapted over time.