11 ms·

The command line is still king. Whenever I see new coders struggle, it usually is because they: - Don't know the context of what they are executing -

• pavlov 2y ago
  This is such generic advice about computing, it’s like saying: “To make a building, you need to have a foundation, something to keep the roof up, and a way for people to move inside.”
  • mg 2y ago
    The analogy I would make is that living in the command line is like using a CAD program while living in IDEs is like using CorelDraw to design houses. CorelDraw feels more efficient because one quickly has what looks like a beautiful, colorful house on the screen. And then one does not understand why the doors don't work correctly.
• dakiol 2y ago
  The more experience I accumulate, the more I rely on GUIs. Explanation: when I was younger I used exclusively the CLI and underestimated GUIs. Now I tend to appreciate GUIs and use them more.
  • lucianbr 2y ago
    If you're experienced with the command line, it's easy to use GUIs and get good results. If one starts with GUIs and doesn't really understand what is behind, then all kinds of trouble happen. So I guess, as with any tool, understanding is key.
    • lukan 2y ago
      Not all GUIs are just a graphical wrapper for a CLI. But in general sure, understanding the tech behind helps.
      • lucianbr 2y ago
        No doubt, if you're working in AutoCAD, there's no command line that you need to understand first. But then again, if you're working in AutoCAD, you'd never say "I used to work in CLI only, now I use GUIs more and more". Clearly they meant GUIs that have CLIs behind, or at least CLI alternatives.
        • kalleboo 2y ago
          AutoCAD is an unlucky choice of example here, because it's one of the few GUI drawing tools that actually does have a command line behind it that you have to understand sometimes! Look up a screenshot of AutoCAD and you can see the command prompt at the bottom of the window. And if you were using AutoCAD in the 80's you can say exactly that you used to use the CLI only!
          • lucianbr 2y ago
            CorelDraw? Word? Audacity? Or maybe it will turn out that all GUI software has command line somewhere inside. I think my original point stands even better in that case. Yay for hair-splitting, I guess.
            • lukan 2y ago
              "Or maybe it will turn out that all GUI software has command line somewhere inside" Not at all. Most maybe, but since I wrote GUIs without a CLI I can say for sure that not all have them.
              • lukan 2y ago
                I mean, every web GUI, which are now probably the majority of GUIs do not have a CLI anymore..
  • devjab 2y ago
    I used to sort of like the Azure GUI (yes I’m a total psychopath), but then they changed it 9 billion times and now I just use the CLI. It’s frankly often experiences like this which drives me back to the cli. I like Gitkraken, but the it does an update and forgets my SSO or it doesn’t support a specific thing I need to do and then I’m using their console. I’m not really religious about anything, but I often end up going back to the CLI for a lot of things because it’s just less of an annoyance.
  • the_duke 2y ago
    Can you give some examples? Which GUIs are you using?
    • dakiol 2y ago
      I have used git extensively in the terminal. But nowadays I see myself more and more relying on GUIs like the ones integrated in Intellij IDE, Source Tree, etc. Another example could be qemu and the GUIs that we have nowadays. One final example would be simply drag and dropping files via Finder instead of using cp/mv
• sandreas 2y ago
  This. And it does not even exclude having a (T)UI. Modern terminal tools like neovim, lazygit, zellij, btop++ or yazi can do many things as window management, image previews and colors as well as having mouse support.
  • galangalalgol 2y ago
    Are there any good tools to be able to ssh into a machine and preview images or render markdown directly in line with the cli?
    • fragmede 2y ago
      sixel support lets you display images to the command line, for terminal emulators that support it.
    • bas3l1ne 2y ago
      For rending markdown, I use https://github.com/charmbracelet/glow https://github.com/charmbracelet/glow
• xk3 2y ago
  > On the command line, the context is obvious. You are in the context While I share the opinion that the command line is _the one true way_ of computing, I don't think this is really all that true. Computers are alien. GUIs are alien. CLIs are alien. Everything is learned. Everything is experience. Everything is culture. Learning, experience, and culture blind us from the experience of the novice. This is "expert blindness". Why Western Designs Fail in Developing Countries https://youtu.be/CGRtyxEpoGg https://youtu.be/CGRtyxEpoGg https://scholarslab.lib.virginia.edu/blog/novice-struggles-and-expert-blindness-how-my-discomfort-with-php-will-make-me-a-better-instructor/ https://scholarslab.lib.virginia.edu/blog/novice-struggles-a...
  • copperx 2y ago
    More succinctly, "the only intuitive interface is the nipple."
    • lukan 2y ago
      Some babies actually do not have that intuition and rather bite and need time to learn.
    • fanf2 2y ago
      Not even that. Newborns have to learn how to suckle, and their mother has to learn how to hold everything in the right positions so it can work. It’s a tricky skill and many aren’t successful even if they want to breastfeed.
      • lamuswawir 2y ago
        Newborns don't have to learn how to suckle. It's a reflex, called a suckling reflex. Lacking a suckling reflex is an indicator of disease. Basically a newborn suckles everything that goes into the mouth, nipple or not.
        • rolisz 2y ago
          Yes they have a suckling reflex, but they might not latch on correctly and then breastfeeding is extremely painful.
• delusional 2y ago
  I agree with you, but I think there's a caveat. The command line is king in Linux, BSD, MacOS, AIX, and to a lesser extent Windows. These operating systems were crafted from the bottom up with the commandline as a foundational layer. The idea of the context, of the "working directory", the "environment", were concepts that were lifted from that commandline centric world, into what we run now. I think Windows very much wanted to be something different with COM. Instead of starting a shell in the context of the program, you'd connect some external "shell" into the very object graph if your program to inspect it. It turns out to be very difficult, and Windows has largely retreated to commandline centric architecture, but I think there was some essential attempt at foundational innovation there. I would argue that the commandline has very much proven to be the best trade-off between being useful and being simple, but there is no saying if there exists some alternative.
  • steve1977 2y ago
    > The command line is king in Linux, BSD, MacOS, AIX, and to a lesser extent Windows. These operating systems were crafted from the bottom up with the commandline as a foundational layer. This is definitively not true for macOS.
    • skydhash 2y ago
      MacOS is a very complete, very well funded desktop environment targeted towards the general user. You want anything extras and you land in applications using private apis and the command line.
      • steve1977 2y ago
        The command line is not a "foundational layer" in macOS, that was my point. It exists on the same layer as the GUI does.
        • thesuperbigfrog 2y ago
          The foundation of MacOS is a fully-compliant Unix: https://www.opengroup.org/openbrand/register/apple.htm https://www.opengroup.org/openbrand/register/apple.htm The GUI is built on top of the Unix foundation and does not stand alone or work without it. The 'FoxTrot' comic made a big deal about this not long after Mac OS X was released: https://www.gocomics.com/foxtrot/2002/02/25 https://www.gocomics.com/foxtrot/2002/02/25
• jasode 2y ago
  >On the command line, the context is obvious. But CLI contexts are only obvious if the computer user is already familiar with the CLI which biases the learned mind to perceive things as obvious when they really are not. A lot of CLI commands syntax are based on position instead of explicit argument names. E.g. creating file system links via CLI has opposite syntax positions in Linux vs Windows: - Linux: ln srcfile targetlink - Windows : mklink targetlink srcfile If one goes back & forth between the 2 operating systems, it's easy to mis-type the wrong syntax because the CLI doesn't make it obvious. On the other hand, using a GUI file browser like Ubuntu Nautlius or Windows Explorer lets a novice create links ("shortcuts") without memorizing CLI syntax. This gap of knowledge is also why there is copy&paste cargo-culting of inscrutable ffmpeg, git, rsync, etc commands. E.g. using ffmpeg to covert a DVD to mp4 by manually concatenating *.VOB files has very cumbersome and error-prone syntax. It's easier to use a visual GUI like Handbrake to click and choose the specific title/chapters to convert. CLI vs GUI superiority depends on the task and the knowledge level of the user.
  • tjoff 2y ago
    Context isn't the same as syntax? Yes, command line suffers from discoverability of which different applications (such as ln/mklink) may not be consistent. It is one of the bigger problems (imho) of the cli but it doesn't go against GPs point. The command line does have a learning curve (partly because of the above), but it is also quite rewarding.
    • sgc 2y ago
      When I start typing a formula in LibreOffice Calc, there is a popup showing possible matching functions, then when I choose the function, the popup shows the required syntax for the function and where I currently am within that syntax. A bash plugin that would do that would be an absolute game changer imho. The cli excels because it is extremely flexible, with far more options available than a set of buttons could ever display. But discoverability rounds down to 0, and there are footguns. It seems like spreadsheet software has found an almost drop in ui that would greatly enhance the cli.
• zoky 2y ago
  > On the command line, the context is obvious. You sound like someone who never tried to write a cronjob script…
• 1vuio0pswjnm7 2y ago
  "Don't know about the concept of input and output" Wow, that seems quite fundamental. Computing 101. I'm not a "coder" and I spend "99%" of time on the command line. Because I prefer it. Ever since the 80s when I first used a VAX.
• at_a_remove 2y ago
  The command line is king, but sometimes the king is mad. Which is to say, it can be difficult to work with the monarchy when the syntax is shit. And there's a lot of bad syntax out there: overly cute, so terse as to be cryptographic, the straight-up baffling ... Outside of the syntax (which seems to live forever), you have things like non-sane defaults, obscurantist man pages ... the list goes on.
  • fragmede 2y ago
    the ability to hit up and edit and retry is such a redeeming feature. repeating the same actions in a GUI with no keyboard shortcuts is an exercise in frustration.
    • jodrellblank 2y ago
      GUIs can have keyboard shortcuts. Have you honestly never pressed Alt+F, x to exit a GUI program or Ctrl+S to save a document in a GUI editor, or Ctrl+Tab to switch tabs in a GUI browser or Tab to move focus between fields, or the context-menu button next to Alt Gr and then a keyboard accelerator key for the menu, or Ctrl+C then Ctrl-P or anything? Repeating the same actions in a CLI with no readline is an exercise in frustration, but ... that's not what happens most of the time.
  • skydhash 2y ago
    > the syntax is shit When you’re typing a lot, you really don’t want to do a lot of typing for each step. And the shell scripts were for automating some process, not solving a particular problem (you use a programming language for that). The workflow is to have the references ready in case you forgot something. That brings up the man pages, which can varies in quality, but, for most software I’ve used, tend to be comprehensive. But they assume that you’re knowledgeable. If you’re not, take some time to read a book about system administration (users, processes, files permissions,…).
    • at_a_remove 2y ago
      I'm not sure if I have O'Reilly's System Administration book. I used to get pre-prints back in the early nineties when they were still quite new. In any case, yes, I have read and I have Been Around. And I still think that we can improve. More over, we ought to improve.
• steve1977 2y ago
  Oh believe me, I wish what you wrote was true, but it isn't. I've seen people think they have a specific Python environment active just because they were in their project's directory on the command line. I've seen people not understand that "python -m pip" is a command and even if they are in a directory which has "python" in its name, they still have to type "python" for that command. PS: The command line might even be an emperor. And the emperor could be naked...
  • fragmede 2y ago
    > I've seen people think they have a specific Python environment active just because they were in their project's directory on the command line. I wrote python-wool as a simple wrapper to python to make that true because it's just easier that way. Direnv can also be configured to do that as well. http://GitHub.com/fragmede/python-wool http://GitHub.com/fragmede/python-wool
• vegabook 2y ago
  Reductio ad absurdum: we should all just use an interactive assembler. Then you really are "in the context". There is a level of abstraction that makes sense. What level that is is dependent on your objectives.
  • skydhash 2y ago
    My first real programming experiences was done through the browser’s console (JavaScript) and IDLE’s REPL (Python). The short feedback cycle works wonder for understanding instead of struggling to the multistep process of C compilation or Java verbosity. I tried my hands at reverse engineering and using a dissassembler like IDA also gives the same immediacy feeling. Great DX for me is either a good debugger or a proper REPL whatever the abstraction level.
    • vegabook 2y ago
      Agreed. When writing the comment I returned seconds later and added the word "interactive".
    • richrichie 2y ago
      > the multistep process of C compilation it can be a single make command
  • teddyh 2y ago
    DDT, the shell for the ITS operating system, was also an assembly-level debugger.
• fragmede 2y ago
  its unsung strength is in having multiple terminal windows and a browser open, and the simplicity of being able to hit up and being able to edit and then retry a failed command. I can't do that in Photoshop.
• bloopernova 2y ago
  Yep, I ran a short "introduction to the command line" course for the devs in my team. Afterwards, I noticed that their usage of the vscode terminal was much higher, and folks were more comfortable exploring on their own. Quick outline of the course, in case anyone wants a starting point: * Introduction Quick history of Unix * When you log in Difference between login and interactive shells System shell files vs user shell files .zshenv for environment variables like PATH, EDITOR, and PAGER .zprofile for login shells, we don't use it .zshrc for interactive shells Your login files are scripts, and can have anything in them * Moving Around ** Where am I? pwd = "print working directory" stored in variable $PWD Confusingly, also called current working directory, so you may see CWD or cwd mentioned ** What is here? ls ls -al ls -alt . prefix to filenames makes them hidden . is also the current directory! .. means the parent directory file tells you what something is cat displays a file code opens it in vscode ** Finding my way around cd cd - dirs | sed -e $'s/ /\\\n/g' ** Getting Help From The Man man 1 zshbuiltins manpage sections ** PATH echo $PATH | sed -e $'s/:/\\\n/g' zshenv PATH setting which tells you what will be run ** Environment Variables env | sort EDITOR variable ** History ctrl-r vs up arrow ** Permissions Making something executable ** Prompts zsh promptinit zsh prompt -l ** Pipes and Redirection Iterate to show how pipes work cat ~/.zshrc | grep PATH ls -al > ~/.tmp/ls-output.txt ** Commands *** BSD vs GNU commands BSD are supplied by Apple, and Apple often uses old versions GNU are installed via homebrew, and match those commands available in Linux
• deleted 2y ago
  [deleted]
• samatman 2y ago
  > Input and output are also obvious. Input is what you type, output is what you see. Input maybe, although realizing that instead of typing, you can pipe, is a major conceptual breakthrough when new users are learning to work the command line. But output? The existence of stdout and stderr as two sources of text with no visible distinction is highly nonobvious and continues to trip me up in practical situations to this very day.
• whartung 2y ago
  On the command line, the context is obvious Hardly. If you’re lucky, you might know what your current directory is. More often than not, at any particular point, your command line is paused in the middle of some likely ad hoc multi-step process. A process with a bunch of state stored as opaque blobs of data scattered across the file system. More so exacerbated in my case as those files are likely cleverly named x, x1, x2. Modern systems benefit from things like command history, scroll back buffers, and similar constructs that can be leveraged to help you, as the user, restore the current context. But for a very long time, many simply returned to a $ and a soulless, cold, blinking cursor callously expecting that you recall you know where you are and what you’re doing. The tools are there to help you dig and perhaps restore the current context (current directory, latest files, etc.) but that’s a far cry from “obvious”. Lots of folks return, blow their internal call stack, and just start over when they come back from lunch (if practical).