1. 10

    Why use powershell on Linux? Don’t get me wrong, I like a lot of the ideas behind PS, and on windows systems I imagine it is invaluable, as it exposes all of the Windows APIs that were previously behind GUIs, but on Linux we have bash, and if you need more complicated stuff, you can use Python, with it’s excellent subprocess module, or ruby, or another language that you’re familiar with. Then you don’t have to deal with PS’s insanely wordy syntax.

    1. 6

      I think the article adequately explains why to use pwsh over bash, especially if you’ve written much bash. On the other hand, I think the article also seems less compelling at first glance if you have written a lot of bash, as I have, and as I’m sure you have. Experienced bash users are necessarily experienced in dealing with piping text between programs in lieu of a richer data model.

      I personally find shell scripts invaluable, and prefer them for system-level tasks over Python or Ruby. And I disagree about Python’s subprocess module—I think it’s clunky and verbose. Sure, pwsh has long command names, but for shell-like tasks it’s still more concise and clear than equivalent Python. And for interactive use, pwsh has many built in aliases similar to common UNIX commands.

      That all said, I’m hardly an experienced pwsh user compared to my bash, Python, or Ruby. But every experience I’ve had with pwsh has been pleasant and resulted in readable code. There’s only one reason I haven’t switched: pure momentum. I’m so used to bashisms that I have little reason to invest time in anything else. But if I could go back and choose where to invest my time—and if pwsh were available on Linux much earlier—I would choose pwsh.

      1. 4

        pwsh has long command names

        I think long command names are better than shorter command names. There is absolutely no reason that in $current_year we should use, document in, and most importantly teach (whether schools or documentation or books or blogs) what look like incantations to summon the prince of darkness.

        There was a time when cd was better than Set-Location. That has not been the case for decades. I’d argue if we are writing something that will be run more than once, you MUST write it in as verbose language as possible.

        1. 3

          There was a time when cd was better than Set-Location. That has not been the case for decades.

          There is an important case for shorter names: interactive use. sls is a lot easier to type than Select-String!

          1. 2

            I hate the fact that PowerShell is verb-noun, but with tab completion typing a short name that you’re very familiar with is a bit faster than typing a long well-namespaced name (e.g. String-Select) but it’s a lot faster to type a long well-namespaced name that you aren’t familiar with than it is to type the short one.

            For example, there’s a standard UNIX tool with a two- or three-letter name for printing a specific column of a stream and I never remember what it’s called, so I either spend a few minutes in man pages or just use awk and type more. Typing something like Column-Select would be 4-5 characters with tab completion and would save me a lot of time.

            I mostly use PowerShell for Azure admin things and I do that sufficiently rarely that the commands are never in muscle memory for me. Tab-completion works pretty well for helping me find things (though with noun-verb it would be much better).

            1. 2

              For example, there’s a standard UNIX tool with a two- or three-letter name for printing a specific column of a stream and I never remember what it’s called

              cut? I suppose I understand what you mean - but it does have mnemonic name - it allows you to cut out fields and columns?

            2. 1

              When writing things that I’ll need to write again, like api endpoints, or shell scripts, I favor shorter names. When writing functions I’ll be reading more times than I’ll be writing, I favor longer names. Coupling this guidance with a soft goal of lines under 80 characters, and I get what seems like a nice result to me.

            3. 1

              Powershell also has a bevy of shorter name aliases, designed for interactive use.

            4. 2

              … And I disagree about Python’s subprocess module—I think it’s clunky and verbose.

              I find it to be clunky as well, fortunately Python has Xonsh shell, which is pretty amazing ;-)

              1. 2

                Agree about shellscripts, but

                And I disagree about Python’s subprocess module—I think it’s clunky and verbose.

                Have you tried subprocess.check_call and subprocess.check_output? I ask because I used Popen for a long time and only last year thought to check for simple synchronous versions that are what I need a good 90% of the time.

                I do agree that Popen can’t really compete with the ease of bash piping, though; for large volumes of data, you need to use a subprocess.PIPE to process it (which you get for free with bash) and i’m not familiar with any idioms that make that painless.

                1. 3

                  I kind of agree with the first response. subprocess is clunky, and frankly weird at times, but it’s really flexible, and for me, when I’m trying to structure data into arrays or dicts, I find bash even clunkier. Structured data is usually where I go from using bash to an actual programming language like python or ruby.

                  1. 2

                    Right, and IMO it’s not entirely a subprocess issue; python generally solves different problems, and Popen doesn’t get in my way when I need something more complex than a short bash script. But It’s pretty hard to beat |, 2>&1, >>foo, &, etc. for concision, and sometimes I just wish it were as mindlessly easy to do pipes in python as it is to strictly evaluate a generator ([*foo]) or unpack a nested iterable (x, (y, *z) = bar). I’d probably set the threshold lower for when to use python vs. bash if that were the case.

                    arp242 mentions below that libraries exist for this sort of thing, and I’ve used plumbum for this in one project, but then you have to worry about portability, version management, bloat, etc, which is again a hindrance.

                    1. 2

                      For me it’s just a matter of readability; something like grep foo file.txt | cut -d : -f 2 | tr -s ' ' is a lot more work in subprocess (or native Python).

                      This is like the old McIlroy vs. Knuth story, where Knuth had written a long Pascal program and McIlroy did the same with a fairly simple shell pipeline.

                      I think there was some library that tries to abstract a lot of the syntax around this, which might be a nice middle ground, and of course using Python brings many other advantages too.

              1. 1

                APL lets you pick, which provides the advantage of increased clarity based on problem domain and the disadvantage of having to figure out which one is being used in a given namespace.

                Half-open zero-based sequence indexing (as in python) usually imposes the lowest number-fiddling overhead in the types of problems I work on in array-based scientific computing. Having to get the N+1th term from a length-N list always feels impossibly wrong to me.

                1. 2

                  It’s pretty presumptuous to refer to a vague unpublished blog post as “this paper”. The terms used are ill-defined and the “conclusions” are just vague speculation.

                  1. 1

                    unpublished blog post as “this paper”

                    There’s also a PDF link at the top if you prefer.

                    Or how about LaTex? (https://github.com/treenotation/research/blob/master/papers/paper3/countingComplexity.tex)

                    Source code is there as well, as well as change history (between there and the “jtree” repo).

                    The terms used are ill-defined

                    Specifically what is ill defined?

                    There’s also reams of data and experimental tools available (https://jtree.treenotation.org/designer/) (https://jtree.treenotation.org/sandbox/).

                    and the “conclusions” are just vague speculation.

                    “The benefit of this system is that it is simple, practical, universal, and scale free”—are being put into use everyday. Not sure what is vague about that. Maybe you haven’t played around with it yet? I use TNC all. the. time. It is immensely simple, practical, universal and scale free. What complexity measurements are you using throughout your day?


                    I’m also told that having references pointing to SciHub is inappropriate. Frankly I disagree. I think it’s downright dishonorable to do things according to what is deemed “permitted”, if such things are plainly unjust (like restricting people from sharing science and information under the threat of violence). So I’ll put no effort into getting this “published”, unless it’s in a public domain journal. I did indeed “publish” all 3 papers to arxiv.org (the first is still up, but they went and removed the 2nd and 3rd ones for some reason).

                    I checked out some of your work. Looks interesting! But wait, when I go to see the source code I get this:

                    “(authentication required in all cases; reviewers will need to use the git.ligo.org or IceCube SVN links).”

                    My advice: don’t do what the field is doing, those things deemed “appropriate”, and do the right thing.

                  1. 4

                    Mac philosophy is about using the mouse to achieve everything.

                    This is of course subjective, but IMO the most important part of the “Mac philosophy” is that things work and keep working without you having to think about it (mostly).

                    I have a Mac and a PC, and I mostly use UNIX tools (Linux containers/VMs and the MacOS command line), but I have not switched to Linux (and I rarely use the PC) because the Mac is quite stable and has rarely required me to interrupt my actual job to get it working. I prefer Linux for most things and have been meaning to switch to some Linux distribution for years, but the fact is I’d be taking time away from work for little marginal benefit to install it and find workaround for missing non-linux apps; I’ll probably only really switch when I get a new laptop and can make sure a decent linux is preinstalled and functioning.

                    The reasons are varied (and not always attributable directly to the OS itself), but in my experience MacOS gets out of my way better than anyone else. I’m counting a few separate things together here:

                    • good drivers
                    • availability of desired applications (I know I can run photoshop, word, etc. if needed)
                    • good default config
                    • system stability with rare reboots
                    • easy backups
                    • many scientists have macs, so i can easily learn/teach new things that have any OS dependence
                    • durable hardware design (a little unfair, since Apple gets to control both hardware and OS)
                    • a proper UNIX terminal plus a proper modern GUI
                    1. 13

                      Lobsters doesn’t have an NTP tag, but if you run anything that depends on NTP, the end of this post should make you a little worried.

                      1. 4

                        An ntp tag would be too partisan. A time tag would work instead.

                        1. 3

                          This post is an excellent argument for abolishing leap seconds. Adding seconds regularly causes issues, subtracting them will only be worse. I’m in favor of ignoring them for the next 200 years or so, by then either civilization will have collapsed or AIs can take care of it.

                          1. 7

                            Or the industries that are negatively affected by leap seconds could use a time scale that’s not affected by them, like TAI or MJD. Then it’s just a matter of treating UTC like any other civil time (which it already is, de facto), by deriving it from TAI via a table of leap seconds.

                            1. 5

                              I agree with things not mattering much in practice due to civilization being done in the mid-term anyway, but c’mon, can’t people try to make an effort to get at least the basic things right? Where is the craftman’s pride?

                              There is no fundamental reason why software dealing with time has to be such a shitshow. And if you can’t deal with leap seconds, simply pick a time without them. Problem solved.

                              1. 5

                                I worked out a while ago that leap seconds will add up to something like half an hour over a millennium. Within a time zone, the difference between noon and the sun reaching its zenith varies by up to an hour. Ignoring leap seconds for a thousand years will mean that noon is off as a result of drift by less than it is off because of accidents of geography. There is no benefit from leap seconds for anyone other than astronomers and a huge amount of pain for everyone else.

                                If, in two thousand years, we’ve accumulated enough drift that time zones are one over from where they’d be, it’s a lot easier to adjust everyone’s time zone by one hour than it is to do a leap hour (assuming anyone actually cares about the relationship between the time and the position of the sun in 2,000 years).

                                1. 6

                                  Astrophysics grad student here. I’ve worked on enough of LIGO’s timing system and enough GPS/UTC/MJD conversions for multi-messenger searches to say that leap seconds are as much of a pain for astronomers as for anybody else!

                            2. 2

                              You weren’t kidding.

                            1. 12

                              Something tells me that neither of the authors has substnatial experience as software developers. But I think both of them have experience writing text, on macs perhaps? Perhaps even using Sublime Text, an editor that has a vim/emacs lookalike mode?

                              I’m an emacs user myself, FWIW, and my development screen has no animations in my field of vision, and no web browsers either. (The browser I’m using at this moment runs on a different host, outside my regular field of vision.) My big bottleneck is to melt into the code, and extra windows don’t help with that, magic or not. It helps when the code fills my field of vision, that way it’s easier enter the zone and have nothing except reliable computer input and feedback.

                              1. 4

                                Something tells me that neither of the authors has substnatial experience as software developers.

                                It was a little ridiculous to see them try to sell git as an IDE feature when knowing its CLI is universally useful. I get the sense that they don’t really understand how things work in a UNIX workflow.

                                1. 4

                                  They don’t – both of them are career content marketers.

                                  1. 6

                                    I suspect the stack overflow blog is also specifically designed to rile up a dev audience to increase engagement; make obviously absurd claims so armies of commenters on the internet spike up their numbers.

                                    And here I am commenting on it too. Mission accomplished :(

                                    1. 1

                                      Content marketing is a odd profession. People who do that for a living describe themselves using another term, such as “technical writer”, which makes it sound as if what they do is somehow dishonourable.

                                      I wrote “have experience writing text” precisely in order to avoid the phrase they themselves chose not to use. Maybe that was dishonest of me. Or politel

                                  1. 44

                                    Most IDEs create entire worlds where developers can create, but creating requires configuration. It takes time to adjust that world, to play god, to create shortcuts and hotkeys, to get used to different command structures and UI.

                                    The authors seem to be describing Emacs.

                                    With code completion, Git control, and even automatic deployment systems, modern IDEs are a Swiss Army Knife of features

                                    Do people just not know what can be done in Emacs? Git control???

                                    1. 6

                                      Emacs is amazing, but has a horrible issue with discoverability. “Distros” like Doom or Spacemacs have tried to address that, but, regardless of my personal feelings on them, they haven’t really broken into the mainstream enough to be noticed. (And as someone who used Emacs for years, I think the discoverability bit is very real.)

                                      1. 4


                                        I have used Spacemacs for a while, but as someone who frequently opens and closes the editor completely - it just boots way too slow, even IntelliJ is faster.

                                        1. 3

                                          emacsclient --alternate-editor=''

                                          Really, Emacs in daemon mode is faster than anything else. Even vim is slow to start in comparison. I don’t understand why Emacs is the only editor which does this. I guess, you need to be reeeealy slow for someone to actually implement this feature :-)

                                          1. 5

                                            I’ve tried emacs daemon mode, I never found it very pleasing. There were a number of papercuts I was running into… I need to figure out again what that was.

                                            1. 2

                                              Yeah, I actually have the same experience, getting useful setup of daemon mode took me several tries. Like, you need to pass an empty string as an argument to --alternate-editor to have it auto-spawn the daemon if it isn’t running yet. That’s right next to sending SIGUSR1 to du in my chart of horrible CLI interfaces :)

                                          2. 1

                                            People who aren’t used to having a fully-featured editor boot, over SSH, in the blink of an eye don’t really know what they’re missing. One less interruption in the flow of thought.

                                            Never really got used to emacs, but boot time is one reason i switched to vim.

                                          3. 2

                                            I think the discoverability bit is very real.

                                            Yes, this is the word I should have used. Good GUIs can really help with discoverability.

                                            1. 1

                                              What do you mean by discoverability? Shoudln’t the help-system address that? C-h m to see what commands are bounds, C-h f to see what they do, M-x customize-group to see what you can change.

                                              1. 3

                                                C-h and friends are great, but you kind of have to know what the options are to get the help you want. For example, you can do a lot of Git manipulation in dired, but you need to know that exists, or at least to think of maybe dired might have some stuff in that area, to even know what you should be asking for. Experienced users, sure, I think this is sufficiently discoverable, but new users (and I mean that fairly broadly), it’s trickier.

                                              2. 1

                                                Emacs is amazing, but has a horrible issue with discoverability.

                                                I do want to specifically point out that the parent comment emphasized the mention of “Git control”, when one of the aspects of the Emacs ecosystem a bystander is most likely to have heard praise for is magit (another being org-mode). So it’s not so much a matter of whether it’s possible to discover magit’s existence in a vacuum – it’s that having access to one of the best interfaces to Git, period, is something often evangelized to non-Emacs-users as a point in Emacs’ favor.

                                            1. 1

                                              I use and greatly appreciate IDEs sometimes. For my use cases and preferences, however, vim/unix ecosystem does the job better 90% of the time because:

                                              1. If I’m SSHed into some server, I want to edit files easily in a good editor. No IDE can compete with vim foo for convenience.
                                              2. Editing text should almost never cause my CPU fans to spin up or my computer to run out of memory. I shouldn’t have to close text files just to free up memory. (Corollary: I shouldn’t have to buy a high-end workstation just to edit multiple projects at the same time).
                                              3. UNIX tooling provides 90% of the IDE features I use, and since I need to work in UNIX environments anyway, I can learn those workflows with less overhead.
                                              4. I find it much easier to focus in the terminal thanks to the minimalist interface.
                                              5. I hate reaching for my mouse.
                                              6. Vim’s keybindings are the best fit for my brain and fingers that I’ve found. When I use an IDE, I have to put in effort to bring it up to the same basic level of functionality as I have in vim.
                                              7. Vim/emacs/UNIX/etc. aren’t going anywhere, whereas proprietary tech is subject to changes, OS incompatibility, and product cancellation. Time invested in UNIX tools feels like a longer term investment.
                                              8. Good IDEs often require you to have a lot of the same systems understanding. CLion uses the same PATH variables that my CLI tools do. You still need to learn a lot of stuff to really get what’s going on.
                                              9. Having functionality factored into smaller chunks means that you can often use some of your dev tooling in other places in creative ways, which is harder with monolithic dev tools. You can also add your own tools without having to learn some obscure IDE plugin interface.

                                              All that said, I’ve found that IDEs can be great for learning about new problem spaces, for abstracting away system concerns, or for working on complex projects (provided the IDE tooling can help you manage the complexity). The only one I actively use is CLion, since it “just works” on Windows and MacOS and gives me autocompletions that were a pain to configure in coc.vim. It’s a beautiful and thoughtfully-designed program.