6 ms·

> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should han

> And there are solutions. One solution, from those who don't code, seems to demand ("developers", paid or not) that every tool that deal with files should handle this additional complexity, regardless of their context and what they think. Users expect computers to work in a non-surprising ways. It isn't natural to use dashes or underscore in file names. Training users to be afraid of spaces is just teaching them one more way that computers are scary and unpredictable. Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years.

hzhou321 9y ago
> Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years. That is an excellent example that deserves a second look from a different aspect. ... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.
- coldtea 9y ago
  Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs). And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.
  - Chlorus 9y ago
    Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
    - hzhou321 9y ago
      > Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly ... Just to clarify on what we think as problem could differ: C:\Users\hzhou>ls *.txt new 2.txt C:\Users\hzhou>ls new 2.txt ls: new: No such file or directory ls: 2.txt: No such file or directory
      - com2kid 9y ago
        dir works fine for that. :) I actually didn't know that dir supported multiple globs for filenames! I've never had a need for that. Super cool.
        ratboy666 9y ago
        Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting. Directory of C:\Users\fred 12/14/2017 04:44 PM 1,556 new 2.txt 1 File(s) 1,556 bytes 0 Dir(s) 75,989,876,736 bytes free C:\Users\fred>dir new 2.txt Volume in drive C has no label. Volume Serial Number is BA05-C445 Directory of C:\Users\fred Directory of C:\Users\fred File Not Found C:\Users\fred>
        com2kid 9y ago
        > Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting. Ah I see, you have a file "new 2.txt", I was a bit confused. Not sure what you mean by only 1 level of quoting being a problem, sorry.
        grive 9y ago
  - hzhou321 9y ago
    > Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, A similar trend is happening in electronic communication: from letter to email, to text, to emoji's. The text is just one historical communication way and there's no reason it should be of any real interest to modern communicator as long as we have emojis ... wait, we've been there before.
    - coldtea 9y ago
      Only the text can express things that emojis cannot. This is not true to GUI vs command line. The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.
      - grive 9y ago
        This kind of interface is horrific for the use-case: https://www.powergrep.com/screens/replace.png https://www.powergrep.com/screens/replace.png There is such a thing as a cluttered graphical interface, and some complexity cannot just be abstracted away. > The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do. That would be like saying that because I am able to write "First open this app by clicking on the upper-left icon, then click File, new File", would mean that text is a superset of the GUI because it can describe visual cues. An abstraction can always replace another, it does not mean it is a superset of it. Take the source code for your GUI application, this is pure text. In the early days, there was shell code that would describe terminal GUI of sort to configure the linux kernel. This shell code is still commands read token per token with matching behavior. Because an abstraction can be traded for another (which could be argued to be a founding principle of computer science), does not mean that one is a superset of the other.
  - jancsika 9y ago
    To be fair to modern desktop users, a command line that doesn't redefine the word "command" to fit the constraints of the system would look something like this: $ take this list of transactions and for each group of duplicate names show me the name and total dollar amount spent, sorted from highest to lowest $ I think I have a SQL command for that. Are you feeling lucky? [y/n] y Foo $25 Bar $20 Blah $15 $ Was this what you were looking for? [y/n]
- com2kid 9y ago
  > it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. There is nothing beneath the Windows UI interface. The GUI is the primary subsystem of Windows, the command line is a separate subsystem. Windows has traditionally been built up around the Win32 API, which is GUI first. It is of course possible to do things from the command line, and some advanced stuff may need the command line, but users should never need to drop out of the UI unless something has gone horribly wrong. The Windows UI is incredibly powerful, with advanced diagnostic and logging capabilities, incredible performance monitoring tools, and system hooks everywhere that allow the entire UI to be modified and changed in almost any way imaginable. The way Services work on Windows is not some (hotly debated) config files. It is through a UI. Management of hardware takes place through a UI. Pretty much everything short of running Ping has a UI around it. I love the command line, if I am developing it is how I primarily work. And while doing so, younger devs look at me like I am crazy because they have customized the living daylights out of their UI tools (VS Code, Atom), to do amazing things that exceed what a command line can do, and of course those editors have a command line built in for when that is the best paradigm! > and having it heavily disguised as an appliance is mandatory. Something working so well that it becomes an appliance isn't a bad thing. It means the engineers who made it have put in so many fail safes and worked to make the code of high enough quality that it doesn't fall apart around itself all the time. Heaven forbid I can upgrade my installed software and not have some random package break my entire system.
  - hzhou321 9y ago
    > There is nothing beneath the Windows UI interface. To clarify, beneath the GUI interface is the actual code that implements that interface. > Something working so well that it becomes an appliance isn't a bad thing. Not at all. I don't attempt to call or think my phone as an computer. Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It is just that there are still a big camp of people who use a computer as computer. That causes some confusions in the communication between.
    - com2kid 9y ago
ajross 9y ago
> Users expect computers to work in a non-surprising ways. "Users" is a very broad category with a bunch of partitioning. The particular subgroup in question are authors of build automation systems for medium to large scale software projects. They (we) have a rather different perspective on "surprising".
- Const-me 9y ago
  > authors of build automation systems for medium to large scale software projects For desktop software, a build automation system needs to handle files that are included in the installer, installed on user’s machines, and in some cases be discoverable by end users of the software. I would be very surprised if my build system wouldn’t support spaces in file names.
hashkb 9y ago
Windows land also had https://en.m.wikipedia.org/wiki/8.3_filename https://en.m.wikipedia.org/wiki/8.3_filename which was never confusing.
sureaboutthis 9y ago
Users aren't programmers and programmers write things no user should ever see. Only the machines do.
nspattak 9y ago
"users" of Makefiles are actually developers, not secretaries, pensioners or architects. They should at least understand tradeoffs and choose accordingly. Developers are used to not using spaces: oneStupidClass or AnotherStillStupidClass or others_do_it_like_this or bIhatehungariannotation or daxpy . As you can see it is not that bad and it has been a widely used practice for decades. Since you are comparing specifically to windows land, perhaps it is their focus on using spaces in file names that made them always be worst than unix like systems in terms of stability, sequrity or performance.

hzhou321 9y ago

> Meanwhile over in Windows land, all tools have been expected to deal with spaces in them for what is approaching 20 years. That is an excellent example that deserves a second look from a different aspect. ... it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. They are scared of computers more than ever. They are very scared of it and having it heavily disguised as an appliance is mandatory.

coldtea 9y ago
Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, and there's no reason it should be of any real interest to modern desktop users (non devs). And I cut my teeth as a developer on DOS, Sun OS (pre-Solaris), and HP-UX, and early Linux back in the day.
- Chlorus 9y ago
  Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly why he's fixated on the GUI... But I had forgotten, computers aren't useful as tools to accomplish work, but as mechanisms to assuage intellectual inferiority complexes. He should advocate for punch cards again, since that would certainly stop morons from using computers.
  - hzhou321 9y ago
    > Almost every CLI program I've ever used in Windows has no problem with spaces in filenames, so I don't exactly ... Just to clarify on what we think as problem could differ: C:\Users\hzhou>ls *.txt new 2.txt C:\Users\hzhou>ls new 2.txt ls: new: No such file or directory ls: 2.txt: No such file or directory
    - com2kid 9y ago
      dir works fine for that. :) I actually didn't know that dir supported multiple globs for filenames! I've never had a need for that. Super cool.
      - ratboy666 9y ago
        Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting. Directory of C:\Users\fred 12/14/2017 04:44 PM 1,556 new 2.txt 1 File(s) 1,556 bytes 0 Dir(s) 75,989,876,736 bytes free C:\Users\fred>dir new 2.txt Volume in drive C has no label. Volume Serial Number is BA05-C445 Directory of C:\Users\fred Directory of C:\Users\fred File Not Found C:\Users\fred>
        com2kid 9y ago
        > Um... no it doesn't. It takes each space delimited name as a new name. You will need to add "" and quote the names -- but Windows shell only has one level of quoting, (") which means you can't easily type the command you need. Unix shell is a bit better. Unix only appears worse because people do attempt scripting. Ah I see, you have a file "new 2.txt", I was a bit confused. Not sure what you mean by only 1 level of quoting being a problem, sorry.
        grive 9y ago
- hzhou321 9y ago
  > Which is not a problem. The command line was only one, historical UI. Not the be-all end-all of UIs, A similar trend is happening in electronic communication: from letter to email, to text, to emoji's. The text is just one historical communication way and there's no reason it should be of any real interest to modern communicator as long as we have emojis ... wait, we've been there before.
  - coldtea 9y ago
    Only the text can express things that emojis cannot. This is not true to GUI vs command line. The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do.
    - grive 9y ago
      This kind of interface is horrific for the use-case: https://www.powergrep.com/screens/replace.png https://www.powergrep.com/screens/replace.png There is such a thing as a cluttered graphical interface, and some complexity cannot just be abstracted away. > The GUI, which can include arbitrary number of text boxes for command line style entry, is a superset of what the command line can do. That would be like saying that because I am able to write "First open this app by clicking on the upper-left icon, then click File, new File", would mean that text is a superset of the GUI because it can describe visual cues. An abstraction can always replace another, it does not mean it is a superset of it. Take the source code for your GUI application, this is pure text. In the early days, there was shell code that would describe terminal GUI of sort to configure the linux kernel. This shell code is still commands read token per token with matching behavior. Because an abstraction can be traded for another (which could be argued to be a founding principle of computer science), does not mean that one is a superset of the other.
- jancsika 9y ago
  To be fair to modern desktop users, a command line that doesn't redefine the word "command" to fit the constraints of the system would look something like this: $ take this list of transactions and for each group of duplicate names show me the name and total dollar amount spent, sorted from highest to lowest $ I think I have a SQL command for that. Are you feeling lucky? [y/n] y Foo $25 Bar $20 Blah $15 $ Was this what you were looking for? [y/n]
com2kid 9y ago
> it has trained a crop of computer users that are afraid of command lines and with an attitude of anything beneath the GUI interface is owned by and of someone else's problem. There is nothing beneath the Windows UI interface. The GUI is the primary subsystem of Windows, the command line is a separate subsystem. Windows has traditionally been built up around the Win32 API, which is GUI first. It is of course possible to do things from the command line, and some advanced stuff may need the command line, but users should never need to drop out of the UI unless something has gone horribly wrong. The Windows UI is incredibly powerful, with advanced diagnostic and logging capabilities, incredible performance monitoring tools, and system hooks everywhere that allow the entire UI to be modified and changed in almost any way imaginable. The way Services work on Windows is not some (hotly debated) config files. It is through a UI. Management of hardware takes place through a UI. Pretty much everything short of running Ping has a UI around it. I love the command line, if I am developing it is how I primarily work. And while doing so, younger devs look at me like I am crazy because they have customized the living daylights out of their UI tools (VS Code, Atom), to do amazing things that exceed what a command line can do, and of course those editors have a command line built in for when that is the best paradigm! > and having it heavily disguised as an appliance is mandatory. Something working so well that it becomes an appliance isn't a bad thing. It means the engineers who made it have put in so many fail safes and worked to make the code of high enough quality that it doesn't fall apart around itself all the time. Heaven forbid I can upgrade my installed software and not have some random package break my entire system.
- hzhou321 9y ago
  > There is nothing beneath the Windows UI interface. To clarify, beneath the GUI interface is the actual code that implements that interface. > Something working so well that it becomes an appliance isn't a bad thing. Not at all. I don't attempt to call or think my phone as an computer. Window's users, on the other hand, still call their PC computers. I guess that is ok if computers are appliances. It is just that there are still a big camp of people who use a computer as computer. That causes some confusions in the communication between.
  - com2kid 9y ago

ajross 9y ago

> Users expect computers to work in a non-surprising ways. "Users" is a very broad category with a bunch of partitioning. The particular subgroup in question are authors of build automation systems for medium to large scale software projects. They (we) have a rather different perspective on "surprising".

Const-me 9y ago
> authors of build automation systems for medium to large scale software projects For desktop software, a build automation system needs to handle files that are included in the installer, installed on user’s machines, and in some cases be discoverable by end users of the software. I would be very surprised if my build system wouldn’t support spaces in file names.

hashkb 9y ago

Windows land also had https://en.m.wikipedia.org/wiki/8.3_filename https://en.m.wikipedia.org/wiki/8.3_filename which was never confusing.

sureaboutthis 9y ago

Users aren't programmers and programmers write things no user should ever see. Only the machines do.

nspattak 9y ago

"users" of Makefiles are actually developers, not secretaries, pensioners or architects. They should at least understand tradeoffs and choose accordingly. Developers are used to not using spaces: oneStupidClass or AnotherStillStupidClass or others_do_it_like_this or bIhatehungariannotation or daxpy . As you can see it is not that bad and it has been a widely used practice for decades. Since you are comparing specifically to windows land, perhaps it is their focus on using spaces in file names that made them always be worst than unix like systems in terms of stability, sequrity or performance.