This Slashdot article



  • This Slashdot article is The Real WTF. (Although the first thread, at time-of-writing, is actually pretty good, I have to admit.)

    Some example comments:

    @spasm said:

    It took me a minute to realize the author thinks gui interfaces are Gay Paree and the command line is back on the farm. In my experience it's the other way around - once the kids have discovered the flexibility and utility of the command line it's a bit hard to keep them in the walled garden of gui interfaces.

    @rubycodez said:

    Don't pander to lazy, unmotivated fucks. we don't need any more windoze weenors trying to develop systems that run on real computers.

    @sjames said:

    The CLI is Turing complete. Anything computable can be expressed through CLI. No GUI can make that claim.

    (That doesn't even make fucking sense... on both counts. Wouldn't something like HyperCard be a Turing-complete GUI? Wouldn't something like CMD be a non-Turing-complete CLI? Edit: Hell Minecraft is a fucking Turing-complete GUI.)

    What really amazes me is the "obvious" conclusion that using the CLI is "smart", while using a GUI is "dumb". I can only hope none of these people actually write software they intend human beings to use, but, sadly, I know most of them do.



  • OMG read this one (but keep in mind the user name is troll-1):

    In many ways the GUI system of icons is similar to the pictograph system of ancient Mesopotamia. You have one symbol for everything you want to express. The Phoenicians had a much better idea, an alphabet. You have a finite number of letters and an infinite number of words and sentences (I believe I'm quoting Noam Chomsky on the infinite part).

    If you are limited to commands that contain only five lower case letters, then the number of possible commands is something like 26 to the power 5 which is over 10 million. It would be difficult to navigate through that many icons. The point-and-click method of using icons is just not as efficient as an alphabet with letters that make up words that make up a language.

    God I hope that's really a troll.



  • Slash dot is to Linux fanboys as reddits religion forum is to atheists: nothing but a pseudo intellectual circle jerk so they can all tell each other how smart they are.



  • @Master Chief said:

    Slash dot is to Linux fanboys as reddits religion forum is to atheists: nothing but a pseudo intellectual circle jerk so they can all tell each other how smart they are.

    meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta meta



  • @blakeyrat said:

    Wouldn't something like CMD be a non-Turing-complete CLI?

    "Turing-complete" and "pleasant and convenient" are two completely different attributes. The cmd interpreter is indeed Turing-complete; it has variables, conditional tests and looping. You could write a Turing machine emulator with it, if you wanted. With some effort it could probably even do functional programming and/or OO. That doesn't stop it being a butt-ugly pain in the arse whose only virtues are its instant availability on every Windows box and the fact that it starts quickly.


  • Java Dev

    @flabdablet said:

    @blakeyrat said:
    Wouldn't something like CMD be a non-Turing-complete CLI?

    "Turing-complete" and "pleasant and convenient" are two completely different attributes. The cmd interpreter is indeed Turing-complete; it has variables, conditional tests and looping. You could write a Turing machine emulator with it, if you wanted. With some effort it could probably even do functional programming and/or OO. That doesn't stop it being a butt-ugly pain in the arse whose only virtues are its instant availability on every Windows box and the fact that it starts quickly.

     

    I haven't checked, but aren't they including powershell by default since windows 7 or so? I usually go to cygwin bash myself cause that's what I'm used to, but powershell seems pretty powerful...

     



  • @blakeyrat said:

    God I hope that's really a troll.

    Do you see what I am holding up to the screen? Its called a mirror[1]. The bell curve applies just as much to comments on /. as to comments everywhere else, including here.

    1. In no way am I trying to imply that you are the troll.


  • @spasm said:

    It took me a minute to realize the author thinks gui interfaces are Gay Paree and the command line is back on the farm. In my experience it's the other way around - once the kids have discovered the flexibility and utility of the command line it's a bit hard to keep them in the walled garden of gui interfaces.

    If the "kids" in question are programmers, sure.  But this guy doesn't seem to understand basic human psychology, nor the history of computing for that matter.  There is a reason that GUIs have slowly but inexorably taken over the world ever since the year 1984: they make computing technology accessible to non-technical users.

    In fact, I would even go so far as to say that if there is any basic functionality on your system in which the user needs to know that a command line even exists in the first place, you have failed in your design.  CLIs are not for users to interact with; they're for scripting.  They're an excellent tool for working with scripts, but horrible for working with live users.  It's a "right tool for the right job" thing.

     



  • @Mason Wheeler said:

    If the "kids" in question are programmers, sure.  But this guy doesn't seem to understand basic human psychology, nor the history of computing for that matter.  There is a reason that GUIs have slowly but inexorably taken over the world ever since the year 1984: they make computing technology accessible to non-technical users.

    I wouldn't even say it makes things better only for technical users. The shell is powerful, to be sure, even on Windows you can do a lot of things much easier and faster in CMD than in Explorer, and of course Bash needs no introduction there. But to say that should be all we have is stupid. Would I rather type out a long cp command or just drag files between two filesystem windows? That's obvious, when you're doing garden variety tasks that don't require anything special, using the command line is like driving picture nails with a sledgehammer. It works, but it's stupid.

    The one thing I've learned over the years that no one ever teaches is that limiting yourself to anything, be it a specific OS or a specific way of using one (CLI versus GUI) is like taking a brand new toolset and throwing half the tools out because "only noobs use them." It's retarded. Use the tool suited for the job and move on, don't sit there trying to make yourself look impressive.



  • @Master Chief said:

    using the command line is like driving picture nails with a sledgehammer. It works, but it's stupid.
     

    To accuratize this interesting metaphor: it works in one go and that nail is never coming out again, but it takes more effort to set up, aim and swing-- and if you happen to miss, you're usually in deeper shit.



  • @PleegWat said:

    I haven't checked, but aren't they including powershell by default since windows 7 or so? I usually go to cygwin bash myself cause that's what I'm used to, but powershell seems pretty powerful...

    Powershell is installed in 7 and is available for XP via Windows Update, so it's easy to get, but cmd is just there in every version since NT. And if all you're going to write is a handful of lines, cmd is fine and it really does start faster than anything else.

    Personally I find Powershell wordy, noisy, overcomplicated and irritating. Why the fuck it wants me to jump through signing hoops before I can make a script that will just run anywhere with a double-click I will never understand, and the workarounds are ugly as fuck. Lots of people do seem to like it though.

    I do like bash as a shell, and consider it one of the great underrated programming languages even though ${name} is astoundingly ugly syntax for disambiguating access to an rvalue. I use it on my Debian boxes, but I'm not terribly fond of the Cygwin manifestation. The whole /cygdrive thing is a pain, the Cygwin installation process is weird and annoying, and the tools that work so well on Linux end up feeling kind of foreign and awkward in the Windows environment.

    If I have a scripting task to do on Windows that turns too ugly in cmd, I'll generally write the guts of it in Jscript and use cmd for glue. Jscript is close enough to Javascript to be treated as a proper programming language even though it's missing a heap of useful standard helper functions, and it's also available on every Windows box along with its inbred halfwit cousin VBScript, which I will also occasionally hold my nose and use just because a heap of Windows interfaces appear to have been built around it. In particular, Jscript doesn't do outparams.



  • PowerShell is pretty wordy and complicated which has kept me away from it. However from the couple times I've used it, I think its best feature is you can directly use .NET classes so it can save you from writing throw-away C# applications to do little system things.


  • Discourse touched me in a no-no place

    @flabdablet said:

    I do like bash as a shell, and consider it one of the great underrated programming languages even though ${name} is astoundingly ugly syntax for disambiguating access to an rvalue.
    It's not the worst feature. The default double expansion of variables, that's definitely worse when you're trying to write scripts with predictable behavior. Bash (and all the other bourne shell derivatives) only really work well when filenames typically don't have spaces (or other odd characters) in; works great on systems for techies, but has terrible problems with ordinary users.



  • @Mason Wheeler said:

    If the "kids" in question are programmers, sure.  But this guy doesn't seem to understand basic human psychology, nor the history of computing for that matter.  There is a reason that GUIs have slowly but inexorably taken over the world ever since the year 1984: they prevent non-technical users from killing the machine accidentally.

     

    FTFY

    Another nice one is UAC. I hear some users used to remove all the contents of their C drive to free up space for more games. And the one nice lady who cleaned the machine up by moving all INI-files to one folder, all DLLs to another and so on...

     



  • @dkf said:

    The default double expansion of variables, that's definitely worse when you're trying to write scripts with predictable behavior.

    Debatable, the opposing argument being total consistency, and thus ultimately predictability at the expense of extra keystrokes.

    But there's another thread for that argument.

    @dkf said:

    has terrible problems with ordinary users.
     

    What doesn't? The main reason browser-mail, Facebook and other web-services took off so well is that they absolutely can not break the computer if misused (unless you are on IE<=5 ).



  • @dhromed said:

    @Master Chief said:

    using the command line is like driving picture nails with a sledgehammer. It works, but it's stupid.
     

    To accuratize this interesting metaphor: it works in one go and that nail is never coming out again, but it takes more effort to set up, aim and swing-- and if you happen to miss, you're usually in deeper shit.

    dhromed, you just made my day! :-)



  • @Master Chief said:

    The shell is powerful, to be sure, even on Windows you can do a lot of things much easier and faster in CMD than in Explorer, and of course Bash needs no introduction there.

    Yeah but this is my big issue with the argument: I don't deny the CLI can do some tasks faster, but those tasks are all things nobody ever needs to do. So whenever someone is trying to demonstrate why you should use a CLI they always use ridiculous contrived examples: "rename every file in this folder of 200,000 files with the word 'dog' in it".

    And then you get into the *dis*advantages of the CLI: sure you renamed your dog files quickly, but what if you screwed up and need to go back? Well there's no Undo, sorry. What if you accidentally deleted a file? Well there's no Trash or Recycle Bin, sorry. What if you're dyslexic and you've typed the command 20 times and each time get a vague error about bad syntax? Well there's no accessibility tools, sorry.

    The only reasons you ever need to use a CLI (use-cases where the CLI is "better") are when using applications written by developers who only use the CLI. Until recently Git was a good example: you needed the CLI to use Git. Is that because a CLI is better when using source control? Hell no. In fact, source control is an obvious use where a GUI can shine and provide shitloads of added value. The only reason you needed a CLI is because Git was only half-built by morons who thought the CLI interface was "good enough".

    Personally, I try to avoid half-built software.

    @Master Chief said:

    The one thing I've learned over the years that no one ever teaches is that limiting yourself to anything, be it a specific OS or a specific way of using one (CLI versus GUI) is like taking a brand new toolset and throwing half the tools out because "only noobs use them." It's retarded. Use the tool suited for the job and move on, don't sit there trying to make yourself look impressive.

    Right but the CLI has drastically important flaws in ease-of-use, accessibility, and data safety that you can't just ignore when debating something like this.


  • ♿ (Parody)

    @blakeyrat said:

    And then you get into the disadvantages of the CLI: sure you renamed your dog files quickly, but what if you screwed up and need to go back? Well there's no Undo, sorry.

    Serious question: Do you use undo features in stuff like file managers a lot? I can't recall the last time I did.

    @blakeyrat said:

    In fact, source control is an obvious use where a GUI can shine and provide shitloads of added value.

    I find that I like both GUI and CLI source control. The CLI is hands down superior for looking at stuff like which files have changed in a large directory tree of a project. Of course, my CLI is usually in something like konsole, where I have easy selection and copy/paste of text (typically using the X primary selection and middle click to do so...Windows would be 1000% better if it had this). It's also nice to search through diffs or logs or whatever by piping it into something like less. It's easier to get nice cooperation between tools on the CLI than in a GUI.



  • @dkf said:

    @flabdablet said:
    I do like bash as a shell, and consider it one of the great underrated programming languages even though ${name} is astoundingly ugly syntax for disambiguating access to an rvalue.
    It's not the worst feature. The default double expansion of variables, that's definitely worse when you're trying to write scripts with predictable behavior. Bash (and all the other bourne shell derivatives) only really work well when filenames typically don't have spaces (or other odd characters) in; works great on systems for techies, but has terrible problems with ordinary users.

    If you don't quote your args, you're gonna have a bad time.

    Seriously, what happens if someone makes a folder named usr files backup in the root of the filesystem and tries to delete it?



  •  @blakeyrat said:

    @Master Chief said:
    The shell is powerful, to be sure, even on Windows you can do a lot of things much easier and faster in CMD than in Explorer, and of course Bash needs no introduction there.

    Yeah but this is my big issue with the argument: I don't deny the CLI can do some tasks faster, but those tasks are all things nobody ever needs to do. So whenever someone is trying to demonstrate why you should use a CLI they always use ridiculous contrived examples: "rename every file in this folder of 200,000 files with the word 'dog' in it".

    And then you get into the *dis*advantages of the CLI: sure you renamed your dog files quickly, but what if you screwed up and need to go back? Well there's no Undo, sorry. What if you accidentally deleted a file? Well there's no Trash or Recycle Bin, sorry. What if you're dyslexic and you've typed the command 20 times and each time get a vague error about bad syntax? Well there's no accessibility tools, sorry.

    The only reasons you ever need to use a CLI (use-cases where the CLI is "better") are when using applications written by developers who only use the CLI. Until recently Git was a good example: you needed the CLI to use Git. Is that because a CLI is better when using source control? Hell no. In fact, source control is an obvious use where a GUI can shine and provide shitloads of added value. The only reason you needed a CLI is because Git was only half-built by morons who thought the CLI interface was "good enough".

    Personally, I try to avoid half-built software.

    @Master Chief said:

    The one thing I've learned over the years that no one ever teaches is that limiting yourself to anything, be it a specific OS or a specific way of using one (CLI versus GUI) is like taking a brand new toolset and throwing half the tools out because "only noobs use them." It's retarded. Use the tool suited for the job and move on, don't sit there trying to make yourself look impressive.

    Right but the CLI has drastically important flaws in ease-of-use, accessibility, and data safety that you can't just ignore when debating something like this.

     Wow. I've been lurking on here for ages, but this Blakey post is so fantastically bad I had to make an account just to correct him.

     I have personally had to use a CLI to script up some kind of action on a number of occassions. Baking a subtitle file into a .mkv file, times the number of episodes in the series at hand was one of them. Getting a list of every library header file we were using in a project so I could add them to Visual Studio's precompiled header list was another. Remove all the .svn folders from a large folder hierarchy. Start a minecraft server with a particular set of Java arguments. Run a program with Visual Studio's built-in profiling tools and perform some transformations on the output. These aren't imaginary use-cases nobody ever runs into, and I'm amazed you have apparently never needed to do something like this. It might not be something the average user runs into on a regular basis - although I can imagine some scenarios involving things like naming or categorising pictures or mp3 files or videos or something - but it's an absolutely indispensable tool to have available. Haven't read the actual slashdot article this entire discussion started, and sure, talking about a GUI like it shouldn't exist at all is pretty dumb. But if the fundamental idea of the article was 'how do we teach average users to drive command-lines or other scripting tools to make their life easier when they need to do something scripty?' that's not a dumb question. Even if you're not talking raw CLI stuff, I'm pretty sure the average user's life would be improved by basic regex knowledge for Find & Replace windows.

     Accessibility issues? Sure. I'm not sure they're worse or better than the average webpage, but it's a flaw. Ease of use? I guess, although this is better or worse on some systems. CMD is pretty awful as far as these things go. But you could just as much say that GUIs suffer fundamental flaws when it comes to doing one task on multiple things, because they're only ever good at it if they've been specifically programmed to do that action on multiple things. GUIs suffer fundamental flaws when it comes to repeatable actions - say because tech support wants you to do some particular sequence of actions and don't want to guess whether you've done it right. It's almost like two different user interface paradigms have different tasks that they're good at! Fancy that.

     As for git, that's just you fundamentally misunderstanding UNIX design philosophy. git does source control. Why should it need a GUI? If you want a GUI for it, someone's probably written a shell over the top of it that makes calls to git to perform actions. I don't personally use git, but TortoiseSVN and friends are obvious analogies. Now of course you're going to come in and say they're all awful, but that's really beside the point - there's no fundamental reason why writing a GUI for a CLI program has to be awful. When a web browser has a seperate process to parse and render HTML - one for each tab even! - and another process for the overarching UI, it's doing the exact same thing, except it doesn't expose the individual bits to the user. In some cases the individual bits might actually be useful to a user - say, someone who wants to make Git do some scripted action his preferred GUI doesn't handle. So UNIX philosophy is that you do them seperately. One task for each bit of the system.

    Hell, there's no fundamental difference between scripting something up in a CLI and writing a program. Tools like autohotkey straddle the line. You may as well argue we should all use drag-and-drop programming tools to make stuff, and if we ever have to type in code we're obviously doing it wrong.

     


  • Discourse touched me in a no-no place

    @j_p said:

    You may as well argue we should all use drag-and-drop programming tools to make stuff, and if we ever have to type in code we're obviously doing it wrong.
    Funny thing is, I've spent a substantial part of my career working on tools to do that sort of thing; it's astonishingly hard to get right. While GUI tools can do simple programs quite easily, making them scale up to anything complex without typing in code is really very hard indeed. Language (even a cryptic, stilted one like a programming language) is good for complex ideas, even if not always so good for conveying the gist of those ideas to others.



  • @blakeyrat said:

    This Slashdot article is The Real WTF. (Although the first thread, at time-of-writing, is actually pretty good, I have to admit.)

    Some example comments:

    Oh, puh-leese. Stupid comments on a Slashdot thread? Who evar woulda thunk it?

    Next you'll probably discover that some Youtube comments are less than entirely well thought out.




  • @j_p said:

    I have personally had to use a CLI to script up some kind of action on a number of occassions. Baking a subtitle file into a .mkv file, times the number of episodes in the series at hand was one of them.

    Getting a list of every library header file we were using in a project so I could add them to Visual Studio's precompiled header list was another.

    I'm not even sure what you're doing here to respond to it properly.

    @j_p said:

    Run a program with Visual Studio's built-in profiling tools and perform some transformations on the output.

    I don't particularly see how it's so important that's done in a single step.

    @j_p said:

    Remove all the .svn folders from a large folder hierarchy.

    In windows explorer:
    Search: .svn
    Arrange by name, select all the folders called .svn then press delete.
    So very hard, I almost chipped a nail.

    @j_p said:

    Start a minecraft server with a particular set of Java arguments.

    I learned how to run a program with additional arguments about five years before I knew what a command line even was.
    It never has been specific to CLIs, it never will be specific to CLIs.

    @j_p said:

    I can imagine some scenarios involving things like naming or categorising pictures or mp3 files or videos or something - but it's an absolutely indispensable tool to have available.

    I've seen absolutely fantastic music organising programs on both Linux and Windows. They all used GUIs exclusively.

    @j_p said:

    But you could just as much say that GUIs suffer fundamental flaws when it comes to doing one task on multiple things, because they're only ever good at it if they've been specifically programmed to do that action on multiple things. GUIs suffer fundamental flaws when it comes to repeatable actions.

    If it's a task that you'd reasonably expect someone to do repeatably, a GUI not supporting it is a bad GUI. If it's not a task you'd expect to be performed repeatably, then perhaps you should question whether or not it's even worth the effort faffing about trying to do them all in one go and just do them individually. If it's one of the obscenely rare cases where you actually do need to do that task multiple times, then start looking around for some way of automating it.
    But I highly doubt you'll actually encounter such a situation.

    @j_p said:

    As for git, that's just you fundamentally misunderstanding UNIX design philosophy. git does source control. Why should it need a GUI? If you want a GUI for it, someone's probably written a shell over the top of it that makes calls to git to perform actions.

    ...

    there's no fundamental reason why writing a GUI for a CLI program has to be awful.

    You're fundamentally misunderstanding the point. There's no reason for git to be a command line program in the first place.


  • ♿ (Parody)

    @DaveK said:

    Next you'll probably discover that some Youtube comments are less than entirely well thought out.

    Sometimes they're just presented in the wrong medium.


  • ♿ (Parody)

    @Salamander said:

    There's no reason for git to be a command line program in the first place.

    There are certainly reasons for it to have a command line mode. I'm not sure what place they come in.



  • @j_p said:

    As for git, that's just you fundamentally misunderstanding UNIX design philosophy.

    No, that's the thing.  The UNIX folks fundamentally misunderstand human/computer interaction.

    git does source control. Why should it need a GUI?

    Even asking that question proves my point above: you do not understand human/computer interaction.  There is a reason GUIs have been taking over the world ever since 1984: because they are a far better (more intuitive, more usable) interface paradigm than CLIs.

    If you want a GUI for it, someone's probably written a shell over the top of it that makes calls to git to perform actions.

    A shell over the top.  Wow.  Almost ten years since Spray-On Usability, and some people still think that's a realistic design paradigm?

     



  • @Mason Wheeler said:

    @j_p said:

    As for git, that's just you fundamentally misunderstanding UNIX design philosophy.

    No, that's the thing.  The UNIX folks fundamentally misunderstand human/computer interaction.

    git does source control. Why should it need a GUI?

    Even asking that question proves my point above: you do not understand human/computer interaction.  There is a reason GUIs have been taking over the world ever since 1984: because they are a far better (more intuitive, more usable) interface paradigm than CLIs.

    If you want a GUI for it, someone's probably written a shell over the top of it that makes calls to git to perform actions.

    A shell over the top.  Wow.  Almost ten years since Spray-On Usability, and some people still think that's a realistic design paradigm?

     

     

     Sigh. In more depth then.

     What does git do? Source control. What is its core function? Source control. Where does UI come into that? Or anything other than source control? Git is a /service/. The specific /UI/ to that service is a different problem, one that git doesn't try to solve. You know, the same way that functions are supposed to do Just One Thing. Git is a /service/. It provides source control. It does it through a command-line program because that's readily scriptable for a specific git-ui program that might want to sit over the top of it. Your TCP/IP library doesn't have a GUI either, although you can use Telnet if you really want to talk to another computer at that level. The article you linked to even provides an example of someone writing a GUI wrapper around other tools to make things easy for a user (although oddly enough it's Mac OS, which I've always found awful to use. Their weird addiction to skeumorphism and 'simplicity' that amounts to removing everything you might want to do is kind of a pain).

     Unix philosophy: Programs should do one thing well. Unix programmers consider 'provide a GUI' a thing that something has to do well by being designed to do it from the start. You know, because they're supposed to value it and stuff instead of considering it just some kind of optional extra.

     


  • Discourse touched me in a no-no place

    @boomzilla said:

    @Salamander said:
    There's no reason for git to be a command line program in the first place.
    There are certainly reasons for it to have a command line mode. I'm not sure what place they come in.
    Command lines work better for complicated operations; assembling a non-trivial action in a GUI tends to take ridiculously more work. Well, unless someone goes to the effort to create the GUI for exactly that task for you beforehand, of course, but there's an infinite number of possible tasks so only some are going to have good GUI support. Of course, it also takes effort with a CLI, but they seem to compose better.



  • @j_p said:

    Sigh. In more depth then.

     What does git do? Source control. What is its core function? Source control. Where does UI come into that? Or anything other than source control?

    Seriously?

    What is source control?  What is its core function?  Have you even *used* source control?  Its core function is the versioning of source files as directed by a user.  Where does UI *not* come into that?

    Git is a /service/.

    A Git repository server, maybe.  (And even servers need some sort of UI for administrative purposes.)  But the Git client is a user application.

    Unix philosophy: Programs should do one thing well. Unix programmers consider 'provide a GUI' a thing that something has to do well by being designed to do it from the start.

    ...which is why Unix never caught on outside of highly technical users, because they still think that a good GUI is somehow separable from core functionality, whereas well-designed user applications are specifically designed, from the beginning, to be driven by the GUI.  It's not a coincidence that the only places where any form of Unix has found mainstream acceptance are in derivative OSes that have been heavily reworked by companies like Apple and Google with tons of experience in providing good, intuitive user interfaces.  If anything, the optional add-on should be the command-line interface, since it's only truly useful for scripting (a more advanced and less-common task), whereas a GUI is far more useful for the primary purpose of any user application: interacting directly with the users.

    You know, because they're supposed to value it and stuff instead of considering it just some kind of optional extra.

    My point exactly.

     



  • @Salamander said:

    @j_p said:

    I have personally had to use a CLI to script up some kind of action on a number of occassions. Baking a subtitle file into a .mkv file, times the number of episodes in the series at hand was one of them.
    Getting a list of every library header file we were using in a project so I could add them to Visual Studio's precompiled header list was another.

    I'm not even sure what you're doing here to respond to it properly.

    In the first case, I had a number of .mkv files and a number of .txt files associated with each of them. I wanted to run a program and pass it the .mkv file and associated .txt file, about 25 times. The program I was running is a general-purpose .mkv file muxer, and only had a command line interface.

    In the second case, Visual Studio's C++ compiler has a feature where you can give it a list of header files that it will pre-parse, and then any file in your project that references it gets built against the pre-parsed version. Improves compile times substantially if you give it header files that don't change very often, like library headers. We hadn't been using that feature from the start, and one of the biggest libraries we were using had a very standard header naming convention. So I wanted to turn a directory tree containing .h and .cpp files into a .h file containing every bit of text that matched a certain string. That is, I wanted grep.

    @j_p said:

    Run a program with Visual Studio's built-in profiling tools and perform some transformations on the output.

    I don't particularly see how it's so important that's done in a single step.[/quote]

     Built-in profiling tools are command-line and had a fair amount of information they had to be passed to them, so I made up a batch file to start up the profiling (and the program to profile), and another one to close down the profiling and construct the report. No reason it couldn't have been done as a GUI except that one wasn't provided to begin with and sometimes we have to operate with software like that.

    @Salamander said:


    @j_p said:

    Remove all the .svn folders from a large folder hierarchy.

    In windows explorer:
    Search: .svn
    Arrange by name, select all the folders called .svn then press delete.
    So very hard, I almost chipped a nail.

    This particular instance was on a linux box, which may or may not provide that kind of recursive search built into a search box in the file manager. I don't know, I've never really used that feature in Windows either. Isn't too hard to construct a situation where it starts to become a pain, though. ('all duplicate files in this directory').

     @Salamander said:

    @j_p said:

    Start a minecraft server with a particular set of Java arguments.

    I learned how to run a program with additional arguments about five years before I knew what a command line even was.
    It never has been specific to CLIs, it never will be specific to CLIs.

    Okay, I'll just got find the Java executable so I can make a shortcut to it in this folder. Instead of just making a batch file that does the exact same thing.

    And in both cases it's executing a CLI command. What, does entering '-jar whatever -xms blarg -emu' in a box not count as CLI-ish if you're doing it in a text entry box in a fancy window?

    @Salamander said:


    @j_p said:

    I can imagine some scenarios involving things like naming or categorising pictures or mp3 files or videos or something - but it's an absolutely indispensable tool to have available.

    I've seen absolutely fantastic music organising programs on both Linux and Windows. They all used GUIs exclusively.

     I can't speak for fantastic music organising programs, but iTune's 'smart playlists' would be faster and easier to create if they just came up with a simple textual representation for them you could type in instead of having to tab through a million combo boxes. I'm sure this kind of thing can be done well as a GUI, but I haven't seen it yet. In all seriousness, could you point me to one?

    @Salamander said:


    [quote user="j_p"]

    But you could just as much say that GUIs suffer fundamental flaws when it comes to doing one task on multiple things, because they're only ever good at it if they've been specifically programmed to do that action on multiple things. GUIs suffer fundamental flaws when it comes to repeatable actions.

    If it's a task that you'd reasonably expect someone to do repeatably, a GUI not supporting it is a bad GUI. If it's not a task you'd expect to be performed repeatably, then perhaps you should question whether or not it's even worth the effort faffing about trying to do them all in one go and just do them individually. If it's one of the obscenely rare cases where you actually do need to do that task multiple times, then start looking around for some way of automating it.
    But I highly doubt you'll actually encounter such a situation.

    @j_p said:

    No True Scotsman it is, I see. I've run into a number of tasks which I couldn't readily automate using the GUI tools I had on hand at the time, in a variety of situations, from a variety of developers. Are all GUIs bad, or do all /true/ users never need to use a CLI? I musn't have heard of the UI paradigm that if a user wants to do X and can't, doing X is a silly thing to do.

    As the article Mason Wheeler linked above helpfully explains, writing a good GUI is really hard, requires intensive design focus, and so on. Lots of tools can't afford that effort. The mkv demuxer I referred to above is a reference implementation created by the people who design the mkv standard. Writing good GUIs is not their core skill, not even really what they're aiming for. But the tool is good enough for the people who use it that a fancy-pants GUI implementation isn't going to get written. Turns out the CLI is perfectly usable for what people need it to do. Probably also helps that people who want to mux and demux mkv files probably are comfortable with typing a few characters into a scary blinking terminal. I would prefer that the developers of the mkv standard spend more time making mkv work than making the perfect GUI for batch-processing video files.

    Also worth keeping in mind that of course a GUI solution is possible for anything the CLI can do. It consists of a program named "Do This Specific Thing" with a big button that says "Do it". That doesn't necessarily say anything about whether or not GUIs are a good general solution to the wider class of problem.

     



  • @Mason Wheeler said:

    @j_p said:

    Sigh. In more depth then.

     What does git do? Source control. What is its core function? Source control. Where does UI come into that? Or anything other than source control?

    Seriously?

    What is source control?  What is its core function?  Have you even *used* source control?  Its core function is the versioning of source files as directed by a user.  Where does UI *not* come into that?

    Git is a /service/.

    A Git repository server, maybe.  (And even servers need some sort of UI for administrative purposes.)  But the Git client is a user application.

    Unix philosophy: Programs should do one thing well. Unix programmers consider 'provide a GUI' a thing that something has to do well by being designed to do it from the start.

    ...which is why Unix never caught on outside of highly technical users, because they still think that a good GUI is somehow separable from core functionality, whereas well-designed user applications are specifically designed, from the beginning, to be driven by the GUI.  It's not a coincidence that the only places where any form of Unix has found mainstream acceptance are in derivative OSes that have been heavily reworked by companies like Apple and Google with tons of experience in providing good, intuitive user interfaces.  If anything, the optional add-on should be the command-line interface, since it's only truly useful for scripting (a more advanced and less-common task), whereas a GUI is far more useful for the primary purpose of any user application: interacting directly with the users.

    You know, because they're supposed to value it and stuff instead of considering it just some kind of optional extra.

    My point exactly.

     

     

    You're caught up on assuming that services can't be driven by users. Consider the various compililation tools on a unix system. People used to run gcc by hand. Then someone came up with specifying how your software was built in a makefile, and using the tool make to get gcc to do things - gcc became a service to make. Then people decided that writing makefiles was a pain, so things like automake that would look at your source and generate a makefile came into being. And then IDEs started catching on, but most IDEs on unix systems still generate makefiles for make to read to run gcc (or whatever). Some live on top of automake or equivalents. That design lets you mix and match stuff in the layers underneath as you please, and it means that a tool designed to make it easy to edit code doesn't have to care about figuring out exactly how to invoke your compiler, because someone else is solving that problem. Encapsulation and abstraction.

    What is wrong with developing a git-ui program that sits on top of git and does something similar? tortoisehg and friends exist, I imagine similar things exist for git. The functionality that git provides doesn't constrain UI design much more than TCP/IP constrains your browser's design.

    The problem with layering scripting on top as an optional extra is that it completely destroys any kind of tool ecosystem like above. If gcc and make and automake were all GUI tools from the start, designed without a command line interface, they wouldn't have been able to build on each other nearly so easily. The most obvious solution there is to take the guts of gcc and make them a DLL that other tools can use, and then you get fun dependency resolution issues and if you want to drop down a level for some task you're not sure you're running the same version as the tool above is using and individual programs have to have specifically made the choice to set themselves up as scriptable. Either that or you set up the OS' UI facilities with scripting hooks and you get to spawn pretty make windows while doing /exactly the same thing/ as the command line solution, but with more rube-goldberg thrown in for good measure.

     



  • @j_p said:

    organising music files: the hardest computational problem of all
     

    Clearly, formatting your posts is slightly more difficult for you. ;)



  • @Salamander said:

    In windows explorer:

    Search: .svn

    Arrange by name, select all the folders called .svn then press delete.

    So very hard, I almost chipped a nail.

    Oh! But to select them all at once, you might have had to hit the Shift key to extend your selection and since you used the keyboard YOU WERE USING THE CLI! Dramatic music sting prarie dogs turning heads that weird buzzing horn noise from Inception!!!

    @Salamander said:

    I've seen absolutely fantastic music organising programs on both Linux and Windows. They all used GUIs exclusively.

    Right. I've organized my music using iTunes (back in the day before it was... AS big a piece of shit as it is now) and Windows Media Player. I've never seen a CLI program to do this task. Which is funny, because this use actually fits the CLI model better than any other example given. (I mean, you basically point it to a folder and say: organize this shit, knock yourself out. The only thing it's drawing is a status bar.)

    @Salamander said:

    You're fundamentally misunderstanding the point. There's no reason for git to be a command line program in the first place.

    Right. Source control is a perfect example of a program that's like... 92% user interaction. The reason Git doesn't have a GUI is because Git was written by idiots. There's no other reason.

    Add a GUI, like some friendly Microsoft developers did with their VS plugin, and it actually becomes quite tolerable. (Not *good*, but tolerable.)



  • @Mason Wheeler said:

    A shell over the top. Wow. Almost ten years since Spray-On Usability, and some people still think that's a realistic design paradigm?

    Linux people are still stuck on Dancing Bear-ware. They haven't even gotten to the Spray-On Usability stage yet. (Notice the difference between people arguing for the CLI and against? People arguing against are literate. Ziing!)



  • @j_p said:

    What does git do? Source control. What is its core function? Source control. Where does UI come into that?

    What does Git do? User checks-out a repo (user interaction). User examines diffs between two versions of a file (user interaction). User checks-in code (user interaction). User creates a branch (user interaction). User merges two branches (user interaction).

    It's nothing but UI.

    "Git" doesn't do anything it isn't directed to do by a user, interactively from the keyboard of the computer it's on. Compare that to a web server, for example, where the web server is a machine handling requests from other machines, and therefore has no interaction with users directly.

    Now you're going to come in and make some pedantic dickweed speech about client vs. server. Yawn. Yeah, but Git does like 92% of its work in the client, and the client is nothing BUT user interaction.

    @j_p said:

    Or anything other than source control? Git is a /service/. The specific /UI/ to that service is a different problem, one that git doesn't try to solve.

    Sure it does. It just does an amazingly piss-poor job of it. Or are you seriously trying to claim that if you go to Git's official repo and download it, you don't get the CLI UI? Because if so you're in Crazytowne. (We added the 'e' to make it look folksy.)

    If Git only provided the server software (no user interaction) and a shared code library that can be used to build a client (no user interaction), then:
    1) We wouldn't be having this discussion because that's exactly what Git *should* have done if they weren't interested in building a UI, and
    2) It's likely Git wouldn't have turned out as crap as it did.

    But they didn't. So Git is crap.

    @j_p said:

    It does it through a command-line program because that's readily scriptable for a specific git-ui program that might want to sit over the top of it.

    ... but you just said they didn't prov-- fuck it.

    @j_p said:

    Your TCP/IP library doesn't have a GUI either,

    The library doesn't, by definition. TCP/IP itself does. No matter where it appears. Even on a fucking Xbox or cellphone.

    @j_p said:

    The article you linked to even provides an example of someone writing a GUI wrapper around other tools to make things easy for a user

    Right, that's also what the Visual Studio Git plugin does. The problem is, that's a shitty solution. It's better than nothing, but it's worse than Git just providing a code library for performing its functions for a proper GUI to work from. (I'm not claiming Git doesn't do this, BTW... I have no idea if it does or does not. But the fact that all the Git GUIs I've seen are wrappers around it's stupid broken CLI leads me to believe it does not.)

    @j_p said:

    Unix philosophy: Programs should do one thing well.

    Here's a quiz for you: every time I ask this the Unix fan shrinks away and disappears without answering the question.

    What is the "one thing" a spreadsheet application should do well? And here's a bonus tip: the reason Excel took over this space ion the first place is it started to do things other than simulating a financial spreadsheet well, while its competitors did not.

    Jeopardy timer's ticking, buddy.

    ...

    Give up? The answer to the question is: a lot of the Unix philosophy is dumb and doesn't apply in the modern world. "One thing and do it well" doesn't work with applications users interact with. Spreadsheets are only the most obvious example. What's the "one thing" Windows Explorer does well? What's the "one thing" Google Chrome does well? I'd say a more useful piece of philosophy would be something like, "let the users of the application define the functionality of the application."

    The other piece of Unix philosophy you see posted often is, "release early, release often". This sums up to: give your initial users the buggiest, most broken piece of crap ever and say goodbye to them forever as they abandon your project in droves for greener pastures.



  • @dkf said:

    Command lines work better for complicated operations;

    Bullshit, and I'm even going to ignore the glorious beauty that was AppleScript for this one, folks! Next I juggle three chainsaws and an egg without breaking the egg!

    @dkf said:

    assembling a non-trivial action in a GUI tends to take ridiculously more work.

    Windows world, we have VBScript and JScript which are specifically designed to do what you're asking about (but which very few people know about for some strange reason.) The reason Microsoft didn't put that functionality into their CLI is because a CLI interface is a terrible place to put it... VBScript and JScript have an IDE. (Not a great one, but 20 times better than anything with a CLI intreface.)

    It's also quicker and easier to put together an app in C# than it is to wire all that Bash plumbing together. With less of a learning curve. And less possibility of error. And a debugger you can step-through your program with. And it's equally free if you're a cheap bastard, just use the "Express" version. Added bonus: works on Linux in Mono.

    @dkf said:

    Well, unless someone goes to the effort to create the GUI for exactly that task for you beforehand, of course, but there's an infinite number of possible tasks so only some are going to have good GUI support.

    The entire point of writing software is to identify (as you phrase it) "complicated operations" and simplify them so anybody can do them. Have you ever seen a elderly volunteer at a church do a mail-merge? Do you know how fucking complicated mail-merge was before office applications expended effort to make it simple? It's a thing of beauty that virtually anybody now can do one. It brings a tear to your eye. That kind of shit is why I got in the industry in the first place.

    @dkf said:

    Of course, it also takes effort with a CLI, but they seem to compose better.

    Bash is held together by string, chewed gum and unspoken-but-critical assumptions. (Example of one of those assumptions: you don't have a file named "-rf".)

    The only argument you're making here is that if you spend months or years learning a shitty system, you begin to like the shitty system. Guess what? If people spend weeks in a cell after being kidnapped, they start to like their kidnappers!



  • @blakeyrat said:

    Give up? The answer to the question is: a lot of the Unix philosophy is dumb and doesn't apply in the modern world. "One thing and do it well" doesn't work with applications users interact with. Spreadsheets are only the most obvious example. What's the "one thing" Windows Explorer does well? What's the "one thing" Google Chrome does well? I'd say a more useful piece of philosophy would be something like, "let the users of the application define the functionality of the application."
     

    This.  As Jamie Zawinski, one of the more enlightened Unix-heads, put it after experiencing the process of real-world software development for a serious customer base, Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

    The Unix philosophy is great for highly technical tools, but not so much so for end-user applications.  (It's worth noting that the shining example of how awesome it all is given above was... a C compiler, something which 99.99% of computer users are never going to touch--or probably even know exists--in their entire lives.)  Users demand programs that do many things and do them... at least tolerably well, and programs which cannot are replaced by ones which can.

     



  • @j_p said:

    The program I was running is a general-purpose .mkv file muxer, and only had a command line interface.

    ... you mean a CLI interface is good for working with a program that ONLY has a CLI interface!? MIND = BLOWN!!!

    @j_p said:

    In the second case, Visual Studio's C++ compiler has a feature where you can give it a list of header files that it will pre-parse, and then any file in your project that references it gets built against the pre-parsed version. Improves compile times substantially if you give it header files that don't change very often, like library headers. We hadn't been using that feature from the start, and one of the biggest libraries we were using had a very standard header naming convention. So I wanted to turn a directory tree containing .h and .cpp files into a .h file containing every bit of text that matched a certain string. That is, I wanted grep.

    a) If you're using C++, you're already in a world of shit.

    b) Explorer, type in your word in the search box, control-A to select all, drag-and-drop the files to VS. There's no way what you did was faster than that.

    All your arguments seem to sum up to: "I don't even fucking know how to use a GUI." Hm. Could it be... that... you're... an idiot? Hm!

    @j_p said:

    This particular instance was on a linux box, which may or may not provide that kind of recursive search built into a search box in the file manager. I don't know, I've never really used that feature in Windows either. Isn't too hard to construct a situation where it starts to become a pain, though. ('all duplicate files in this directory').

    Sort by (whatever duplication you care about). Resize window to be 2 columns wide. Rubber-band one of the two columns. Hit delete. Done.

    @j_p said:

    And in both cases it's executing a CLI command. What, does entering '-jar whatever -xms blarg -emu' in a box not count as CLI-ish if you're doing it in a text entry box in a fancy window?

    Since you're switching OSes every 10 seconds, I don't know which one you're referring to here, but Windows Explorer certainly is not running a CLI behind-the-scenes. It uses the CreateProcess() API call, as all other GUI apps are expected to do.

    Bonus trivia: the existence of a CLI isn't part of Windows' API contract. Microsoft *could* remove CMD tomorrow and they wouldn't be violating their contract. They don't, because of backwards-compatibility with idiot programmers like j_p here, but they *could*.



  • @blakeyrat said:

    @j_p said:
    This particular instance was on a linux box, which may or may not provide that kind of recursive search built into a search box in the file manager. I don't know, I've never really used that feature in Windows either. Isn't too hard to construct a situation where it starts to become a pain, though. ('all duplicate files in this directory').

    Sort by (whatever duplication you care about). Resize window to be 2 columns wide. Rubber-band one of the two columns. Hit delete. Done.

    To be fair, it's nowhere near that simple unless the contents of the folder is composed entirely of duplicates, and there are exactly two of each.  Something like this particular task would be a good candidate for a script.

    Bonus trivia: the existence of a CLI isn't part of Windows' API contract. Microsoft could remove CMD tomorrow and they wouldn't be violating their contract. They don't, because of backwards-compatibility with idiot programmers like j_p here, but they could.

    Are you saying there's nothing documented guaranteeing that .BAT/.CMD scripts are supposed to work as they do?

    I once had a conversation with a friend who needed to change the extension of a few hundred files.  (Don't ask why; it was a stupid reason brought on by the requirements of a poorly-designed piece of software.  The point is, he needed to change them.)  This would have taken him hours in Windows Explorer.  I told him, "go into Notepad, write out "mov *.EXT1 *.EXT2", and save the file with a .CMD extension in the folder where these files are, then run it from Explorer."  Took him less than a minute to complete the task.

     



  • @j_p said:

    And then IDEs started catching on, but most IDEs on unix systems still generate makefiles for make to read to run gcc (or whatever).

    That's because everything on Linux sucks. Good IDEs don't use Makefiles.

    @j_p said:

    That design lets you mix and match stuff in the layers underneath as you please, and it means that a tool designed to make it easy to edit code doesn't have to care about figuring out exactly how to invoke your compiler, because someone else is solving that problem.

    It also makes it impossible to improve Make, because if you make any change to how it functions, no matter how trivial, you break an unknown number of other pieces of software. Most of which you probably have never heard of.

    @j_p said:

    Encapsulation and abstraction.

    You've tied everything to a specific syntax used by a specific program that was written in 1975 and it can never, ever, ever change without breaking everything. Abstraction, maybe. But encapsulation? That's the exact opposite of encapsulation.

    Try it. Go grab your source code of Make. Make a trivial change. (For example, change -C for "change to directory" to -P for "specify path".) Replace the original copy. How well does your system work now? How many programs did you just break? How could you even find out how many programs you just broke? Encapsulation my hairy ass.

    @j_p said:

    What is wrong with developing a git-ui program that sits on top of git and does something similar?

    Nothing's "wrong" with it, per say, it's just a really lousy way of writing a GUI.

    @j_p said:

    The functionality that git provides doesn't constrain UI design much more than TCP/IP constrains your browser's design.

    Maybe, but part of that is because Git is a special case: it only works with text. And text is literally the only type of data that CLI systems are decent at handling.

    Say Git was written to provide diffs for, say, CAD drawings-- now do you believe the CLI would be "just as good" as a GUI? And moreover, since I'm on my soapbox, why *shouldn't* Git be able to handle CAD drawings, or CG animation descriptions, or audio filters? Why the fuck NOT?

    @j_p said:

    If gcc and make and automake were all GUI tools from the start, designed without a command line interface, they wouldn't have been able to build on each other nearly so easily.

    Right; but those aren't tools humans interact with, so (practically speaking) they already have no "user interface" at all. What's the difference between GCC provided in a .exe and GCC provided in a .dll? Jack shit.

    Again: you're giving examples from the dark ages. Those tools were made when there was no such thing as a "dynamically loaded shared code library". They haven't changed since fucking 1974.

    I don't want to use a computer from 1974. I want to use a computer from 2014. Fuck, I want to use a computer from 2050 or beyond. Don't you? The problem with the whole Unix/Linux philosophy you're espousing here is that it's completely stagnant. Why is GCC an application and not a DLL? Because it's always been a application. Why not change it to a DLL? Because that breaks an unknown number of programs. Why? Because those programs all expect it to be an application. Wow! How encapsulated!

    It really cheeses me off, man. Let's push things forward.



  • @Mason Wheeler said:

    To be fair, it's nowhere near that simple unless the contents of the folder is composed entirely of duplicates, and there are exactly two of each.  Something like this particular task would be a good candidate for a script.

    But what do you wanna bet j_p would never have thought of it in a million years? Because he doesn't even know how to use a GUI.

    @Mason Wheeler said:

    Are you saying there's nothing documented guaranteeing that .BAT/.CMD scripts are supposed to work as they do?

    What? No. I'm not even sure what you mean by that.

    I'm saying that the Windows API contract doesn't guarantee the presence of a CLI. The CLI isn't technically "part" of Windows, in the same way that (say) DirectX isn't technically "part" of Windows.

    @Mason Wheeler said:

    I once had a conversation with a friend who needed to change the extension of a few hundred files. (Don't ask why; it was a stupid reason brought on by the requirements of a poorly-designed piece of software. The point is, he needed to change them.) This would have taken him hours in Windows Explorer. I told him, "go into Notepad, write out "mov *.EXT1 *.EXT2", and save the file with a .CMD extension in the folder where these files are, then run it from Explorer." Took him less than a minute to complete the task.

    You get a cookie?

    He could have downloaded a bulk file rename utility and done it in a GUI almost as fast. So I don't see that as a compelling argument.


  • ♿ (Parody)

    @blakeyrat said:

    @j_p said:
    And in both cases it's executing a CLI command. What, does entering '-jar whatever -xms blarg -emu' in a box not count as CLI-ish if you're doing it in a text entry box in a fancy window?

    Since you're switching OSes every 10 seconds, I don't know which one you're referring to here, but Windows Explorer certainly is not running a CLI behind-the-scenes. It uses the CreateProcess() API call, as all other GUI apps are expected to do.

    If you're so literate, why does your response not address what he wrote?

    It's always amusing to watch the CLI-phobes and their spittle flecked arguments. blakeyrat at least has a disability that makes CLIs harder, and I sympathize with that, but I also don't use the wheelchair ramp when the stairs are quicker and more direct.

    Desktop environments at least have caught on and generally provide decent searching for applications. Windows could be better at finding stuff they've buried in control panels (or whatever they're calling it on 8), bless its heart. Tab completion beats clicking through a tree any day. It's also nice to be able to do stuff without having to go between keyboard and mouse (e.g., searching for something in a GUI and then doing something with it), though in some respects a good CLI can have some GUI aspects (I mentioned middle clicking for pasting primary selection text).

    I guess it's probably true that most "normal users" probably don't need a CLI for much of anything, but then that wasn't what TFA was talking about. But I don't expect the "literate" types like blakey to be able to pay attention long enough once they latch onto someone saying anything nice about a CLI.



  • @blakeyrat said:

    What does Git do? User checks-out a repo (user interaction). User examines diffs between two versions of a file (user interaction). User checks-in code (user interaction). User creates a branch (user interaction). User merges two branches (user interaction).

    It's nothing but UI.

    You know, I doubt you are really that dense, but you pretends quite well.

    My software that exports the head of the repositoty every hour, builds it and  if it finds an error mails the error to the development team uses git as much as you do at you console session, what is exactly as much as a tortoise does when directed by a user.

    The fact that you decided to go a level down and interact directly with a computer protocol (what the CLI is) gave you more power, but if you just didn't need it, thought it would make things harder, and decided to do it anyway, tht just makes you stupid. You being stupid is no reason from removing that extra power from the people that know when to use it, it's also no reason to stop teaching people how to use it.

     



  • @blakeyrat said:

    [Guess what? If people spend weeks in a cell after being kidnapped, they start to like their kidnappers!

     

    I spend years stuck with Windows and learned to hate Windows to the bones.

     

    Conclusion: Being stuck with Windows is much worse than being kidnapped.

     



  • @Mcoder said:

    My software that exports the head of the repositoty every hour, builds it and  if it finds an error mails the error to the development team uses git as much as you do at you console session, what is exactly as much as a tortoise does when directed by a user.

    Right; but that software is not a user so why is it using a User Interface to do so? It should be using an API (a.k.a. machine-to-machine interface).

    This confusion is endemic in the Linux world for some reason. The CLI is a *user* interface. It's for users. It's not for machines. Machines should have their own interface that better meets their needs. The machine interface should never change (or at least never break compatibility), but the CLI should change often-- to improve over time.

    Now I also used the word "should" in that last paragraph, which I know throws a lot of Linux users. "Should" doesn't mean that what I'm saying is what happens now, it means... uh... "should". It's stating an ideal.

    @Mcoder said:

    a computer protocol (what the CLI is)

    Aaa! You see? Where does this come from!?

    Look, I'm going to Google "git tutorial". Here's the first concrete task it "teaches" you to do:

    @git tutorial said:

    Assume you have a tarball project.tar.gz with your initial work. You can place it under Git revision control as follows.

    $ tar xzf project.tar.gz
    $ cd project
    $ git init

    It tells the person reading it (a human, I remind you) to use the CLI to perform the task. You're telling me the CLI is only intended as a computer protocol, but here it is, right from the horse's mouth that it is intended for humans. So you'll excuse me if I tell you you're full of shit.

    @Mcoder said:

    but if you just didn't need it, thought it would make things harder, and decided to do it anyway, tht just makes you stupid. You being stupid is no reason from removing that extra power from the people that know when to use it, it's also no reason to stop teaching people how to use it.

    How is my intelligence even slightly relevant here?



  •  @blakeyrat said:

    @Mcoder said:
    My software that exports the head of the repositoty every hour, builds it and  if it finds an error mails the error to the development team uses git as much as you do at you console session, what is exactly as much as a tortoise does when directed by a user.

    Right; but that software is not a user so why is it using a User Interface to do so? It should be using an API (a.k.a. machine-to-machine interface).

    This confusion is endemic in the Linux world for some reason. The CLI is a *user* interface. It's for users. It's not for machines. Machines should have their own interface that better meets their needs. The machine interface should never change (or at least never break compatibility), but the CLI should change often-- to improve over time.

    Now I also used the word "should" in that last paragraph, which I know throws a lot of Linux users. "Should" doesn't mean that what I'm saying is what happens now, it means... uh... "should". It's stating an ideal.

    @Mcoder said:

    a computer protocol (what the CLI is)

    Aaa! You see? Where does this come from!?

    Look, I'm going to Google "git tutorial". Here's the first concrete task it "teaches" you to do:

    @git tutorial said:

    Assume you have a tarball project.tar.gz with your initial work. You can place it under Git revision control as follows.

    $ tar xzf project.tar.gz
    $ cd project
    $ git init

    It tells the person reading it (a human, I remind you) to use the CLI to perform the task. You're telling me the CLI is only intended as a computer protocol, but here it is, right from the horse's mouth that it is intended for humans. So you'll excuse me if I tell you you're full of shit.

    @Mcoder said:

    but if you just didn't need it, thought it would make things harder, and decided to do it anyway, tht just makes you stupid. You being stupid is no reason from removing that extra power from the people that know when to use it, it's also no reason to stop teaching people how to use it.

    How is my intelligence even slightly relevant here?

    Ugh, went to bed and now there are too many dumb blakeyrat comments to reply to all of them individually. :(. (although I do like the CreateProcess() line. cmd, as we all know, starts processes by magic).

    There seems to be some semantic confusion going on here. Or some other form of confusion. When you say that people can just write a jscript script to automate tasks, you are not proving that a CLI isn't useful. Consider the properties of most CLIs:

    - Actions performed by entering 'commands' that consist of text arranged in meaningful ways

    - Commands usually take parameters and switches that tell them what to do

    - Facilities for directing output of commands in various ways (into other programs, into text files, whatever)

    - Usually some kind of variable expansion functionality or similar.

    - Simple looping features.

    What in that list can't be applied to jscript? "But jscript is a scripting language!" Okay but what's the difference between writing a file consisting of textual commands that ends in .bat and a file that ends in .js and double-clicking it? What's the difference between writing a bunch of commands in a terminal or writing a bunch of commands in a file that you then open with a terminal? Hell you can use Python's interpreter-mode as a shell if you really wanted to.

    CLIs are useful for the same reason programming languages are useful.

    As for this hangup about using the command line (or moral equivalents) as an API, don't you do web analytics for a living? You know, operating with programs that communicate with each other via a textual pipe? Sure, sometimes the DLL approach has merits, but if the library you're calling out to has other user-useful functionality you may as well make it user-visible. I'm particularly amused by the "OH NO IF YOU CHANGE THINGS IT BREAKS" problem. When you change a DLL, of course, everything is peachy-fine. DLL hell wasn't a real problem that ever happened (and has been fixed by carrying around every version of every DLL). Sometimes using IPC between two programs is a good solution.

     Miscellaneous one-liners:

    - Visual C++ comes with a version of make and builds using it. Guess it isn't a good IDE. Although I'm happy to concede that there aren't any good linux C++ IDEs - I've still yet to run into a good IDE for any OS. Visual C++ is okay, although a bit buggy and slow, and the compiler it uses is awful. Good debugging features though.

    - Seriously making a shortcut is different because that invokes CreateProcess()? Do you actually think before you say these thing

    - Okay, I want a list of every Qt library we're using in a project. I go to that project (which is of course an indexed search location) and type '#include <Q' in the search window. All the files that contain an include to a Qt library come up. Now how do I get the list of Qt headers out of that? I don't think you thought your solution through.

    - Oh of course release-early-release-often makes people not use your software. That would be why Apache (you know, 'a patchy') is the most common web server and why Linux is the most-installed operating system in the world (tiny desktop penetration, sure, but all those embedded devices add up). Free probably has something to do with that, yes, but there are technical reason why linux is an excellent OS to use for embedded devices, and LAMP is used by most of the world's largest websites, so its got something else going for it.

    - In what universe does blakey live in if searching for and downloading a bulk file name renamer is easier than typing 'move *.blah *.blah2'?

    - I'm not a git user, but I'd be very, very surprised if you couldn't tell it which diff program you wanted to use. If you wanted to source control CAD drawings, then simply provide a diff tool that works for them and you're set. Because it's modular and just does source control. Duh.

    - Did Excel even /have/ competitors?

     



  • Why are we arguing?

    This is like that argument over whether user interfaces were better than UIs.



  • @j_p said:

    (although I do like the CreateProcess() line. cmd, as we all know, starts processes by magic).

    It's not magic. It's an API, provided by the OS. It's well-documented, look it up.

    The assertion was that Explorer keeps a CLI open "behind the scenes" to do things like launching files. I was demonstrating that that assertion was complete bullshit. It's almost as if someone posting here doesn't know shit about how computers work, hmm!

    Pop quiz: Mac Classic had no CLI. None. Zip. Zero. And yet it could launch applications and files. How do you think that was possible? I guess "magic" is the answer?

    @j_p said:

    Okay but what's the difference between writing a file consisting of textual commands that ends in .bat and a file that ends in .js and double-clicking it?

    No difference. Neither is using a CLI.

    @j_p said:

    What's the difference between writing a bunch of commands in a terminal or writing a bunch of commands in a file that you then open with a terminal?

    "open with a terminal" is gibberish. What does that even mean?

    @j_p said:

    CLIs are useful for the same reason programming languages are useful.

    Programming languages are useful for writing software. CLIs are useful for kind of sort of connecting some other existing programs together, kind of, although the connections are super-fragile and the only type of data you can reliably pass around is text.

    @j_p said:

    As for this hangup about using the command line (or moral equivalents) as an API, don't you do web analytics for a living? You know, operating with programs that communicate with each other via a textual pipe?

    The HTTP protocol doesn't really give us a choice in the matter. We don't do it because we want to.

    @j_p said:

    Sure, sometimes the DLL approach has merits, but if the library you're calling out to has other user-useful functionality you may as well make it user-visible.

    Right; by providing a 500k DLL that programs can use and a 10k program that exposes the useful functionality. That's exactly what I'm proposing be done. The beauty of this system is that if your little program needs improved it can be-- without the risk of breaking other programs on the system!

    @j_p said:

    I'm particularly amused by the "OH NO IF YOU CHANGE THINGS IT BREAKS" problem. When you change a DLL, of course, everything is peachy-fine. DLL hell wasn't a real problem that ever happened (and has been fixed by carrying around every version of every DLL).

    Right, the difference is that the DLL Hell program has been worked-around (solved, in other words-- even you refer to it in the past-tense), and the "CLI-program-used-as-API" isn't solved, and the Linux community seems to dedicate zero resources to even attempting to solve it.

    @j_p said:

    - Visual C++ comes with a version of make and builds using it. Guess it isn't a good IDE. Although I'm happy to concede that there aren't any good linux C++ IDEs - I've still yet to run into a good IDE for any OS. Visual C++ is okay, although a bit buggy and slow, and the compiler it uses is awful. Good debugging features though.

    C++ is shit.

    @j_p said:

    - Seriously making a shortcut is different because that invokes CreateProcess()? Do you actually think before you say these thing

    Right. There's no CLI usage involved in making a shortcut in Windows Explorer and entering different launch parameters. If CMD didn't exist on the system at all, this process would work just fine.

    @j_p said:

    - Okay, I want a list of every Qt library we're using in a project. I go to that project (which is of course an indexed search location) and type '#include <Q' in the search window. All the files that contain an include to a Qt library come up. Now how do I get the list of Qt headers out of that? I don't think you thought your solution through.

    C++ is shit. So it's no surprise working with C++ is shit.

    @j_p said:

    - Oh of course release-early-release-often makes people not use your software. That would be why Apache (you know, 'a patchy') is the most common web server

    Apache is popular initially because when it was new there was no effective competition. Apache is popular now because it's cheap, and web serving is a "race-to-the-bottom" type software environment.

    Apache is passably good because, a few years ago, people shamed them into making it not such shit after showing how embarrassingly slow it was compared to IIS, and it was such a black eye on the open source community they expended a lot of effort into fixing it.

    @j_p said:

    why Linux is the most-installed operating system in the world (tiny desktop penetration, sure, but all those embedded devices add up).

    So? McDonalds is the most popular restaurant in the world, it's still no good. (Oh, and all of those non-computer devices? None of them have CLIs.)

    @j_p said:

    Free probably has something to do with that, yes,

    If you replace the word "something" with "everything", then yes, your statement is accurate.

    @j_p said:

    but there are technical reason why linux is an excellent OS to use for embedded devices, and LAMP is used by most of the world's largest websites, so its got something else going for it.

    You're seriously coming to DailyWTF and telling us there are reasons, technical reasons no less, that PHP is popular? You are so full of shit it's coming out your ears. Here's the reason PHP is popular, and you already know it: it's because it's free. In every other aspect it's a complete mess.

    @j_p said:

    - In what universe does blakey live in if searching for and downloading a bulk file name renamer is easier than typing 'move *.blah *.blah2'?

    What does it matter? It's a fucking contrived-as-hell example. And the only reason it even came up is because some other piece of software was broken. I want to see an example of how the CLI is better for a task that people actually perform commonly.

    @j_p said:

    - I'm not a git user, but I'd be very, very surprised if you couldn't tell it which diff program you wanted to use.

    You can, but why should you have to? Looking at diffs is like... 50% of what people do with source control programs. And Git basically skipped completely over implementing it. Because Git was written by idiots.

    @j_p said:

    If you wanted to source control CAD drawings, then simply provide a diff tool that works for them and you're set. Because it's modular and just does source control. Duh.

    Wouldn't it be great if Git worked with data other than text? I think one of the reasons Linux is so shitty is because Linux developers utterly lack any imagination whatsoever. (Which is probably why they have trouble with the word "should".)

    @j_p said:

    - Did Excel even /have/ competitors?

    Yes.



  • @blakeyrat said:

    You can, but why should you have to? Looking at diffs is like... 50% of what people do with source control programs. And Git basically skipped completely over implementing it. Because Git was written by idiots.

    So I guess the command git diff was never invented in the blakeyverse.

    @blakeyrat said:

    Wouldn't it be great if Git worked with data other than text? I think one of the reasons Linux is so shitty is because Linux developers utterly lack any imagination whatsoever. (Which is probably why they have trouble with the word "should".)

    Blakey, git DOES work with binary blobs. It just won't be able to produce diffs between arbitrary binary files that can be loaded into arbitrary programs.



  • Git was developed for working with text files and not CAD files just because git was developed to help with developing linux kernel, which source contains lot of text files, but none CAD files.

    So there was no reason to work with CAD files.

    Also there was no reason to make git in DLL, when it was ment to be used on linux  as CLI program.

     If you do not like that, you do not have use git at all - it was not developed to please some blakeye rats. (Unless your boss tell you, that you will use it, if you want be payd, because people more important for your company than you  decided, that the company will use it - but we all know, that you are in shitty position, where you cannot choose your tools, because nobody think, you are importatnt for your company enought to be allowed so)

     

    So git was developed for some particular reason (developing linux kernel) and proved to be usefull even in other areas, so authors allowed others to use it anywhere the others want.  I do not see, why they should add GUI, when they do not need it. All mentioned users (linux kernel developers) use it with CLI, so it is made with CLI in mind. 

     You got, what you paid for - if you are not satisfied, return git and ask for the money you paid for it. And simply download some GUI program, which can do the same with nice shiny buttons for clicking on. (As you recomended to do instead using the devil "move *.blah *.blah2")

     


Log in to reply