1. 17
  1. 15

    But remember: the people eating your food still won’t care which knife you used.

    Oh they absolutely will care if there’s blood on it because you tried to use a dull knife.

    1. 2

      Or if they have to wait hours for their food because you chose to chop everything with a tiny paring knife.

    2. 12
      • If your dev environment lags massively.
      • If it makes it hard to do a full codebase search.
      • If it makes it hard to use tools which are familiar or comfortable.
      • If it increases the time you spend entering text.
      • If it increases the time you spend figuring out if your logic even works.

      Then YES, your dev environment really matters.

      I used to think I didn’t care if I was forced to use windows. I now know the folly of my ways.

      But of course there is no Best Dev Environment. The dev environment that is best is the one that works for you. Swap out pieces as you go, and get the parts would want.

      1. 2

        If it makes it hard to use tools which are familiar or comfortable.

        I find this really tends to limit me when I move from vi(m) to anything else. vi makes it so easy to filter text through external tools with ! that I’m lost when I can’t easily do that. I don’t love modal editing, but I haven’t found any good non-modal console text editor that integrates as well as vi into the UNIX ecosystem.

        1. 1

          I use joe to edit source code, and it can filter text through external tools. You can even run programs from within joe and capture the output.

          1. 2

            Thanks for the tip – just so that I can get an idea, how would one do something like !}fmt[Return] (run the following paragraph through fmt) in joe?

            1. 1

              For reflowing a paragraph, I would position the cursor anywhere in the paragraph and hit ^Kj (it can reflow paragraphs out of the box). But to filter the text through an external tool (say, tr) you hit ^K/ then the command line to pipe the text through. You can also select the text you want and only send the selected text through using the same command. And if you mess up, hit ^_ (Ctrl-underscore) to undo the filter.

              1. 1

                Thanks! That seems straight-forward. I am not very familiar with joe’s key bindings, but I’d like to give it a try.

          2. 1

            I don’t love modal editing, but I haven’t found any good non-modal console text editor that integrates as well as vi into the UNIX ecosystem.

            If you’re curious, Emacs is basically a fat shell. You can invoke commands (M-!), insert their content (C-u M-!), send a selected region to a process (C-|) and even replace the selected region with the output (C-u M-!). I also maintain a package that makes that easier.

            1. 1

              Wow, shell-command+ looks really interesting – thanks! I don’t know if I’ll go back to using Emacs as my main editor any time soon (the configuration, while fun, takes up too much of my time), but I’ll definitely check your package out.

              1. 1

                Maybe you’ll be able to help me - does emacs have something that I could use as an equivalent to :cexpr in Vim? I.e. load results of arbitrary shell pipeline, and be able to jump to files & lines listed in those results? Basically, “generalized parser of compilation error positions”.

                1. 1

                  Not a Vimmer, but if I read that right then the Emacs equivalent that I’d use for that would be M-x compile

                  It prompts for an arbitrary command to run (usually make or a compiler or something, though things like grep -n work just fine too), then runs it via your shell and displays the results in a new buffer. It syntax highlights ^file:lineno: type things and makes them hyperlinks (left click or hit return on them), and when the process finishes it gives you a line telling you the return code. Pressing g in the buffer reruns the command and refreshes the results (g is commonly the key to refresh things in Emacs).

          3. 4

            And that applies just as much to the users of your code: they don’t care which tools you used.

            It does it you’re opposed to the programmer-user split, and would like to be a programming user. Changing something in a suckless project is a lot easier than in Firefox, because the technical requirements are simple, easy to learn and to install. If a project requires ten different package managers to install each-other, I won’t care about what tools were used, because I’m not in a position to do so – which isn’t something I want.

            1. 4

              Maybe it doesn’t matter for web things, but it matters a lot if your software is a pain to build from source (especially for distribution packagers)

              1. 6

                I read the article as suggesting new programmers not worry about the development environment, not that it doesn’t matter at all. By the time someone is shipping source code for a major system, my assumption is they’ll be the chef who has figured out what knives are actually needed. But, having inherited some codebases that made a lot of assumptions about which IDE I would want to use, I would completely agree that at some point chefs need to seriously care about their knives.

                1. 2

                  Another thing I’ve seen quite few devs worry about is which language to use; and my usual advice is “just pick one and go with it, it doesn’t matter that much”. Once you know one language, the second is a lot easier to learn.

                  1. 1

                    One of the main reasons I love programming is it is taking a big problem (I need to do X) and breaking it into the discrete smaller problems to get there (X requires Y, Y needs Z, so let’s start with Z).

                    I have encouraged a few younger programmers who were coming from non-technical fields to do exactly what you said. For them the big problem was “I want to learn programming, and that is scary.” We broke that down into “To program, you need a language. There are so many to choose from, have you ever heard of one you’d like to try? If not, consider Javascript because as long as you can ctrl-shift-i, you have everything you need.” Once the first Big Decision is out of the way, the actual learning can begin.

                    By the time they realize Javascript isn’t the end-all-be-all for what they need, they have enough knowledge to not feel daunted by the second language. Incidentally, I’ve also seen this as an issue with Linux, where the sheer number of distros has caused analysis paralysis on the person that wants to break in and try it. Keep some spare LiveUSBs on hand and get them over that hump.

              2. 4

                The perfect dev environment doesn’t exist, but we should have high standards for them, and try to improve our workflows, not just accepting the given tools and configurations.

                Also whatever dev environment you choose, just provide scripts or instructions for getting dependencies, running tests and building for production.

                1. 2

                  True, for a given task there are generally multiple tools that could get the job done. But don’t take that idea too far: sometimes your dev environment, like a leaky abstraction, does matter to the user. Some reasons this can happen:

                  • Time to write. The time it takes to you write software can change depending on the environment. This affects what users see because they will never see a feature you don’t have time to to write. For example, if your app shows some handy statistics, your users won’t care whether they were generated by Python or Ruby, but they certainly would care if the reason you bothered to implement those statistics was the availability of the NumPy library for Python.
                  • Performance. Many users complain about apps whose dev environment included Electron, because those apps generally take up more disk space and memory. Similarly, it’s better that git status is implemented with C than if it were implemented with Java, because the JVM’s startup time would make it impractical to include a Git status in a shell prompt.
                  • Supported platforms. Writing a game might take a similar amount of effort whether you write it with LÖVE or Godot… but if you choose LÖVE, the resulting game will not run in web browsers, limiting your audience to some extent.