4 ms·

At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The

At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI, one just hadn't yet figured out how. The GUI, however, never delivered those last 10-20% that you need in automation or in a context that requires reproducibility. Windows NT was designed towards those promises, but eventually Microsoft realised their mistake and created - ten years ago - Powershell. The entire dev world has been catching on to the fact that you get reproducible procedures when you use a CLI. Data scientists are another group who know how much power they get from a CLI. Yet the myth of the obsolete CLI and the omnipotent GUI still is strong. Especially with those people who never really worked with a decent CLI.

coldtea 10y ago
>At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.
- bluejekyll 10y ago
  Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new build tools for new languages, which simply would not happen if you restrict your Dev experience to just the GUI. I keep going back to just creating Makefiles for simple automation tasks. Even the GUIs are starting to learn from this, which is why I think VSCode and Atom are becoming popular; they make it very simple to integrate new CLI tools into the GUIs workflow.
  - coldtea 10y ago
    >Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. No, I'm speaking from the perspective of someone that has worked in the old days with Sun OS (pre-Solaris) workstations and HP-UX machines, has used (for years) actual VT102 terminals, started using Linux distros around '97 and has been using the CLI in various forms since the mid-eighties or so. There's nothing limited about the GUI (in theory, and, for most things that matter, in practice too). For example a visual flow language (think Automator in OS X or Quartz Composer, etc) can achieve all the "configurable pipeline" stuff people like in the CLI in a more controlled and formal way. I also dislike the "dynamic typing" (everything is text/bytes) in the CLI, and would prefer something like PowerShell to have been the norm (with the accompanying toolset). Also note that there's nothing about the GUI that prevents someone from typing some commands too -- and in fact that's part of how lots of GUIs work. Also, I wouldn't point to "modern web development toolchains" as something to advertise CLIs -- what would that be, Gulp, Grunt, Webpack and the like? All crufty solutions to inadequacies in steering the underlying language properly. Even in theory, CLIs are not inherently more powerful, it's the other way around (they lack a dimension that GUIs offer (graphics) -- GUIs on the other hand don't lack any dimension -- they can incorporate text commands and text fields and pipelines just fine.
- JdeBP 10y ago
  I doubt that there is anyone at all in this entire discussion that can state with authority what "most Windows programmers" do. We can point to what we and the people we have met and talked to about this do, but to go from that comapratively scant few handsful of people to a statement the size of "most windows programmers" is an overgeneralization by several orders of magnitude.
  - coldtea 10y ago
    I doubt that discussion and insight can happen without generalising. I also doubt that we need to cover 100% or even 99.999% of Windows programmers to be able to speak about what "most Windows programmers do". Anybody who has experience from 2-5 different Windows shops and been to a few relevant conferences can make a quite accurate assessment of what "most Windows programmers" do.
- AnonymousPlanet 10y ago
  Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That most people you know never realised that many of their daily tasks can be easily automated if they wouldn't think that endless, tedious clickfests are the norm, and that this somehow proves that the CLI is obsolete?
  - coldtea 10y ago
    >Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That they don't miss it either, and that the "endless, tedious clickfests" are a myth of people who don't know the other side.
    - AnonymousPlanet 10y ago
      It's not a myth if you watch it happening nearly every day.
- deleted 10y ago
  [deleted]
- umanwizard 10y ago
  I write client-side code in Xcode but I use the terminal all day for various things.
JdeBP 10y ago
Microsoft didn't have a mistake to realize. From very early on, one of the must-have toolsets for Windows NT was the Windows NT Resource Kit, with a whole bunch of command-line tools -- provided by Microsoft. There was in fact a whole load of command-line tooling for Windows NT, well before PowerShell and back to version 3.1 . Far from this being the reversal that you propound, actual history is even more in favour of your argument. (-:
- AnonymousPlanet 10y ago
  Look at the design of NT. Every output is based on IPC and calls to the event logger. That something like a stdout exists is due to backwards compatibility and mostly the Posix subsystem. The entire OS was meant to be used and administrated by means of GUI. The existence of a bunch of CLI tools that deviate from the main paradigm doesn't prove anything to the contrary. Have a look at the literature on the design and concepts of NT.
  - kyberias 10y ago
    >"Every output is based on IPC and calls to the event logger." What does that even mean? I think you're painting an incorrect picture of the design goals of NT. The original NT was designed by a group of people (e.g. Cutler) with VMS background and they sure as hell didn't have any GUI in mind. In fact, Windows came to the picture much later. Whether NT is administered by a GUI or CLI is totally irrelevant to NT design. Today all the NT derivatives (Windows Server) can be administered with a rich variety of command line tools. Stdout exists because the original subsystems (OS/2, Windows, MS-DOS) required that. Same applies TODAY. Where is the NT bias to GUIs exactly?
    - dfox 10y ago
      To be fair, original Windows API didn't have any concept of stdin/out/err. In win16 days most development environments had something like that but it was emulated inside compiler vendor supplied runtime libraries. CLI as first class OS APIs come from NT.
    - deleted 10y ago

coldtea 10y ago

>At the end of the 80s and throughout the 90s, a common belief was that the CLI could be completely replaced by the GUI And it has, except for backend programmers. Most Windows programmers stay all day in Visual Studio and the like, for example. But as far as end users as concerned, that is the 99% of computer users, the CLI might as well not exist.

bluejekyll 10y ago
Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. The CLI offers an infinitely combinable and customizable development experience, where huge ammounts of innovation have been occuring. You can see this in modern web development toolchains and new build tools for new languages, which simply would not happen if you restrict your Dev experience to just the GUI. I keep going back to just creating Makefiles for simple automation tasks. Even the GUIs are starting to learn from this, which is why I think VSCode and Atom are becoming popular; they make it very simple to integrate new CLI tools into the GUIs workflow.
- coldtea 10y ago
  >Ok. I'll bite. You're speaking from the perspective of someone locked into a way of doing work through the GUI, limiting your development experience to that of what the GUI developer (MS in this case) has provided you. No, I'm speaking from the perspective of someone that has worked in the old days with Sun OS (pre-Solaris) workstations and HP-UX machines, has used (for years) actual VT102 terminals, started using Linux distros around '97 and has been using the CLI in various forms since the mid-eighties or so. There's nothing limited about the GUI (in theory, and, for most things that matter, in practice too). For example a visual flow language (think Automator in OS X or Quartz Composer, etc) can achieve all the "configurable pipeline" stuff people like in the CLI in a more controlled and formal way. I also dislike the "dynamic typing" (everything is text/bytes) in the CLI, and would prefer something like PowerShell to have been the norm (with the accompanying toolset). Also note that there's nothing about the GUI that prevents someone from typing some commands too -- and in fact that's part of how lots of GUIs work. Also, I wouldn't point to "modern web development toolchains" as something to advertise CLIs -- what would that be, Gulp, Grunt, Webpack and the like? All crufty solutions to inadequacies in steering the underlying language properly. Even in theory, CLIs are not inherently more powerful, it's the other way around (they lack a dimension that GUIs offer (graphics) -- GUIs on the other hand don't lack any dimension -- they can incorporate text commands and text fields and pipelines just fine.
JdeBP 10y ago
I doubt that there is anyone at all in this entire discussion that can state with authority what "most Windows programmers" do. We can point to what we and the people we have met and talked to about this do, but to go from that comapratively scant few handsful of people to a statement the size of "most windows programmers" is an overgeneralization by several orders of magnitude.
- coldtea 10y ago
  I doubt that discussion and insight can happen without generalising. I also doubt that we need to cover 100% or even 99.999% of Windows programmers to be able to speak about what "most Windows programmers do". Anybody who has experience from 2-5 different Windows shops and been to a few relevant conferences can make a quite accurate assessment of what "most Windows programmers" do.
AnonymousPlanet 10y ago
Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That most people you know never realised that many of their daily tasks can be easily automated if they wouldn't think that endless, tedious clickfests are the norm, and that this somehow proves that the CLI is obsolete?
- coldtea 10y ago
  >Most Windows programmers I know have never really used an environment that doesn't punish you for using the command line. So what's your point? That they don't miss it either, and that the "endless, tedious clickfests" are a myth of people who don't know the other side.
  - AnonymousPlanet 10y ago
    It's not a myth if you watch it happening nearly every day.
deleted 10y ago
[deleted]
umanwizard 10y ago
I write client-side code in Xcode but I use the terminal all day for various things.

JdeBP 10y ago

Microsoft didn't have a mistake to realize. From very early on, one of the must-have toolsets for Windows NT was the Windows NT Resource Kit, with a whole bunch of command-line tools -- provided by Microsoft. There was in fact a whole load of command-line tooling for Windows NT, well before PowerShell and back to version 3.1 . Far from this being the reversal that you propound, actual history is even more in favour of your argument. (-:

AnonymousPlanet 10y ago
Look at the design of NT. Every output is based on IPC and calls to the event logger. That something like a stdout exists is due to backwards compatibility and mostly the Posix subsystem. The entire OS was meant to be used and administrated by means of GUI. The existence of a bunch of CLI tools that deviate from the main paradigm doesn't prove anything to the contrary. Have a look at the literature on the design and concepts of NT.
- kyberias 10y ago
  >"Every output is based on IPC and calls to the event logger." What does that even mean? I think you're painting an incorrect picture of the design goals of NT. The original NT was designed by a group of people (e.g. Cutler) with VMS background and they sure as hell didn't have any GUI in mind. In fact, Windows came to the picture much later. Whether NT is administered by a GUI or CLI is totally irrelevant to NT design. Today all the NT derivatives (Windows Server) can be administered with a rich variety of command line tools. Stdout exists because the original subsystems (OS/2, Windows, MS-DOS) required that. Same applies TODAY. Where is the NT bias to GUIs exactly?
  - dfox 10y ago
    To be fair, original Windows API didn't have any concept of stdin/out/err. In win16 days most development environments had something like that but it was emulated inside compiler vendor supplied runtime libraries. CLI as first class OS APIs come from NT.
  - deleted 10y ago