You Don't Need(github.com)
github.com
You Don't Need
https://github.com/you-dont-need
152 comments
Heh, the "you don't need GUI" one is extremely underwhelming. Anybody who knows what terminal is already knows about all those commands and none of them is easier than a GUI. It could make more impact if it actually explained tasks that are harder to do in GUI than in the command line, such as massive renaming of the files, filtering files depending on content and so on.
I use both CLI and GUI, but here's an area where I think the CLI just rocks: Instructions for installing and configuring software. Typical instructions for Linux:
In fact, I've seen an increasing number of Windows installation tips being given in CLI terms:
sudo apt-get install foo
sudo apt-get install bar
cd ~/somewhere
sudo nano something, change these lines
In fact, I've seen an increasing number of Windows installation tips being given in CLI terms:
windows+R cmd
enter this command
I'd argue that has more to do with a unified package manager and installation process than GUI vs. CLI.
And I argue it has more to with the fact that *nix applications are traditionally configured via static configuration files as opposed to interactive process.
The real benefit is that they are configured with text files, not a monolithic inscrutable system "registry."
This is about how the user interacts with the configuration process, not where the configuration variables are stored.
Indeed. For the built in installation process that Microsoft wishes everyone would use in Windows 10, it could be this simple:
- Open the Store - Search for "Name of App" - Click Install
Bonus, this works for GUI software managers in Linux distributions which use them. Unifying the process simplifies most instructions greatly. I think the simple existence of Linux package managers, and the push to use them by the community, helps tremendously with this perceived ease. The installation complexity is largely solved by the package repository maintainers.
On the flip side, software which is not distributed with the OS can have very complex installation requirements even with command line instructions. Sometimes it's as easy as:
- ./configure - make install
But more often than not, you need to manually hunt down dependencies, and if the system uses automake / cmake and requires you to satisfy conditions for a build, those can get hairy and cryptic fast. I've gotten better at it over the years, but I wouldn't call this process any easier than a step-by-step installation wizard in a GUI.
- Open the Store - Search for "Name of App" - Click Install
Bonus, this works for GUI software managers in Linux distributions which use them. Unifying the process simplifies most instructions greatly. I think the simple existence of Linux package managers, and the push to use them by the community, helps tremendously with this perceived ease. The installation complexity is largely solved by the package repository maintainers.
On the flip side, software which is not distributed with the OS can have very complex installation requirements even with command line instructions. Sometimes it's as easy as:
- ./configure - make install
But more often than not, you need to manually hunt down dependencies, and if the system uses automake / cmake and requires you to satisfy conditions for a build, those can get hairy and cryptic fast. I've gotten better at it over the years, but I wouldn't call this process any easier than a step-by-step installation wizard in a GUI.
> But more often than not
Simply not true. More often than not you'll get static binaries. And if the software is supported by a commercial team, any dependencies on your supported platform are already tested and working.
Simply not true. More often than not you'll get static binaries. And if the software is supported by a commercial team, any dependencies on your supported platform are already tested and working.
I'd argue it's because it's a lot simpler to to explain than "start synaptic, got to the search box and type x, click the install button, etc".
On the other hand, on mobile platform it is perfectly accepted to say "install foo via app/play/whatever store", which is essentially the same process, isn't it?
Tip: in recent Ubuntu (not sure about upstream Debian but I'd bet it's the same) this is now the recommended way:
sudo apt install fooI use `apt` in Debian, not sure if that's what they recommend, but the interface is better.
`apt search`/`apt-cache search`
`apt install` /`apt-get install`
Though, I prefer pacman/pacaur interface, even if it is less intuitive at first, but I won't use Arch on servers.
`apt search`/`apt-cache search`
`apt install` /`apt-get install`
Though, I prefer pacman/pacaur interface, even if it is less intuitive at first, but I won't use Arch on servers.
"apt" is meant to be the user facing version. No concerns about backwards compatibility or anything. It's purely user experience focused. If they want to change to "apt get" for installing because they feel its good UX, they will (they probably wont, because that sounds awfully confusing)
"apt-get" is meant to be used in scripts/automation. "apt-get install foo" will always behave the same way with the same params.
"apt-get" is meant to be used in scripts/automation. "apt-get install foo" will always behave the same way with the same params.
For the longest time I used a script that basically unified my most common apt-get/apt-cache/dpkg commands into a single frontend, so it's about time.
Some site like this? http://explainshell.com/explain?cmd=rm+-rf+--no-preserve-roo...
> The same instructions for Windows involves screen after screen of text interspersed with annotated pictures of dialogs, which become obsolete when the OS is revised.
Is it an MSI? If not it should be...
To install:
Admittedly we're missing a good online universal repository system on Windows, but hopefully one day that'll change.
Is it an MSI? If not it should be...
To install:
C:\> MSIEXEC /I /QB software-name.MSI
C:\> MSIEXEC /X /QB software-name.MSI
Admittedly we're missing a good online universal repository system on Windows, but hopefully one day that'll change.
Chocolatey???
That's exactly what I did [1], with a word of warning about "Command-Line-Fu". Experience has shown that this is by far the preferred way my customers do IIS installation.
1: https://hglabhq.com/documentation/installation/installing-hg...
1: https://hglabhq.com/documentation/installation/installing-hg...
On the other hand, someone with little to no experience with the command line might struggle to figure out how to start the terminal, why nothing happens when they try to type their password, how the path system works, and so on.
CLI is great for advanced users, but I think GUI is probably best for the vast majority of computer users.
CLI is great for advanced users, but I think GUI is probably best for the vast majority of computer users.
I use chocolatey on my Windows system at work and at home.
> The same instructions for Windows involves screen after screen of text interspersed with annotated pictures of dialogs, which become obsolete when the OS is revised.
In Windows 10: Windows Key + type name of app + click Install button. No dialogs.
In Windows 10: Windows Key + type name of app + click Install button. No dialogs.
I pasted that into cmd.exe and it does not work. Can you create a bat script, please?
Interesting to see that style of Windows installation making a return. I remember it being how almost everything was installed for 3.1 and 95.
Do you know about https://chocolatey.org/ ?
I am trying to normalize some of this between different operating system shells: https://github.com/prettydiff/biddle
tl-dr might be what you're looking for
https://github.com/tldr-pages/tldr
https://github.com/tldr-pages/tldr
Disagree. One of the most generally applicable practices to learn as a developer is the ability to use CLIs effectively, for tasks to which they area best suited. Which is the great bulk of them (version control, database admin, most filesys manipulation, etc).
Or to address your point more directly: for many tasks the GUI may seem easier at first, but a modest investment in CLI techniques can yield far greater dividends, over time.
And then there's all the conceptual and dependency bloat that GUIs impose on a project, over time.
Or to address your point more directly: for many tasks the GUI may seem easier at first, but a modest investment in CLI techniques can yield far greater dividends, over time.
And then there's all the conceptual and dependency bloat that GUIs impose on a project, over time.
I don't think you and the parent are in disagreement if you take their last sentence seriously:
"It could make more impact if it actually explained tasks that are harder to do in GUI than in the command line, such as massive renaming of the files, filtering files depending on content and so on."
It seemed to me his assertion wasn't "the CLI is bad and we shouldn't use it," but rather that the linked "You Don't Need the GUI" piece doesn't make a particularly good case.
And, I admit I agree. There are things that a CLI is much better at, especially if you're a developer, but there are other things that a GUI is arguably better at, sometimes even if you're a developer. If I have a bunch of files that need to be committed to a git repository and I want to commit the changes in multiple commits so they're related by topic, it's faster to select and commit each set of files with GitUp than it is using git's CLI. I find myself switching between the terminal and Finder on a fairly routine basis depending on what the task is.
tl;dr: GUI aficionados really should learn the CLI, but the reverse is also true. I can't speak for every GUI out there, but there's a lot you can do in macOS's that I think people don't really take advantage of.
"It could make more impact if it actually explained tasks that are harder to do in GUI than in the command line, such as massive renaming of the files, filtering files depending on content and so on."
It seemed to me his assertion wasn't "the CLI is bad and we shouldn't use it," but rather that the linked "You Don't Need the GUI" piece doesn't make a particularly good case.
And, I admit I agree. There are things that a CLI is much better at, especially if you're a developer, but there are other things that a GUI is arguably better at, sometimes even if you're a developer. If I have a bunch of files that need to be committed to a git repository and I want to commit the changes in multiple commits so they're related by topic, it's faster to select and commit each set of files with GitUp than it is using git's CLI. I find myself switching between the terminal and Finder on a fairly routine basis depending on what the task is.
tl;dr: GUI aficionados really should learn the CLI, but the reverse is also true. I can't speak for every GUI out there, but there's a lot you can do in macOS's that I think people don't really take advantage of.
True, it would be nice to join both (though I'm fine with only cli). One example is vim's :set guifont=(star char here), where star is a special value that modal-calls system font selection dialog. It would be great if shell also had something like @ wildcard, which would expand into file selector gui, unlike other wildcards. So you could 'svn commit ./path/to/@' and select what you want (or press cancel/esc).
It is partially possible via svn commit `select-files ./path/to`, except cancel part.
It is partially possible via svn commit `select-files ./path/to`, except cancel part.
Fzf (https://github.com/junegunn/fzf) kind of does what you want.
If you type svn commit ./path/to/<Star><Star><tab> It launches a fuzzy Finder (within the terminal) that you can use to recursively search through `to`. You can use the arrow keys and enter to navigate and select. Imo it's faster than a gui would be.
If you type svn commit ./path/to/<Star><Star><tab> It launches a fuzzy Finder (within the terminal) that you can use to recursively search through `to`. You can use the arrow keys and enter to navigate and select. Imo it's faster than a gui would be.
I agree with you in general, but the first two examples you cited are all more comfortable on the GUI for me.
TortoiseSVN was a breakthrough for me. After switching to git, it was painful to try to remember all the different commands, wade through commit logs and find the hashes of commits. I see TortoiseGit exists, but since my org is still on SVN i haven't really given it a try.
Database admin, same thing. CLI clients such as sqlplus or pgsql are ok, but I'll never be able to commit to memory the various commands to show tables, show all databases, describe a table, etc. The one exception is the mysql client which has sane defaults and easy-to-remember commands. I frequently switch dbs, so this is a must. Pgadmin, sql developer and even the buggy MySql Workbench are all more pleasant to work with than CLI, in most cases.
But this are just my preferences. If the CLI works better for everyone else, then great. Maybe I'm missing something, and maybe someone would give me a pointer to unlock the magic of CLI in these scenarios that would make me more productive
TortoiseSVN was a breakthrough for me. After switching to git, it was painful to try to remember all the different commands, wade through commit logs and find the hashes of commits. I see TortoiseGit exists, but since my org is still on SVN i haven't really given it a try.
Database admin, same thing. CLI clients such as sqlplus or pgsql are ok, but I'll never be able to commit to memory the various commands to show tables, show all databases, describe a table, etc. The one exception is the mysql client which has sane defaults and easy-to-remember commands. I frequently switch dbs, so this is a must. Pgadmin, sql developer and even the buggy MySql Workbench are all more pleasant to work with than CLI, in most cases.
But this are just my preferences. If the CLI works better for everyone else, then great. Maybe I'm missing something, and maybe someone would give me a pointer to unlock the magic of CLI in these scenarios that would make me more productive
MySQL/MariaDB also has really good built-in help. If you can't remember how to re-order columns or add a constraint, it's just a `help alter table` away. `psql` also has decent built-in help, but sqlplus is practically unusable without the manual on your desk.
Totally agree. I frequently find myself googling things like "postgres equivalent of describe table" and the like. I didn't know you could get operation reference in MySQL. Thanks for the tip!
I don't understand why version control is easier using the command line? I use perforce daily, and struggle with the command line interface. The GUI gives me lots of vital information at a glance without having to query it, and for the most part can do everything I ever want to do in 2-3 clicks.
Aside from large integrates, everything that the people working on my project do is drom the GUI.
Aside from large integrates, everything that the people working on my project do is drom the GUI.
I agree with you general point, but I think for your specific examples you may just not have used the best GUIs.
Magit https://github.com/magit/magit is definitely the best user interface I've tried for version control. I still drop to the command line occasionally, but it's not as productive unless I'm doing something unusual.
SQL Server Management Studio is also much better than any command line database tool I've used. For any action you can do in it, you can hit a 'generate script' button which you can use to automate what you just did. This is a fantastic feature, because using the GUI becomes a better way to discover and understand the CLI underlying it.
Magit https://github.com/magit/magit is definitely the best user interface I've tried for version control. I still drop to the command line occasionally, but it's not as productive unless I'm doing something unusual.
SQL Server Management Studio is also much better than any command line database tool I've used. For any action you can do in it, you can hit a 'generate script' button which you can use to automate what you just did. This is a fantastic feature, because using the GUI becomes a better way to discover and understand the CLI underlying it.
I agree that CLIs have advantages over GUIs in many cases (but the GUIs have advantages over CLIs in many other cases).
However, the linked repo in the original article simply presents a few commands for copying, moving and zipping files. This is useless and will not convince anybody that they do not _need_ a GUI. It makes a very poor case. If you know what terminal is and how to launch it you already know way more than that article shows, if you don't then there is no way it will convince you that you do not need something like Finder.
However, the linked repo in the original article simply presents a few commands for copying, moving and zipping files. This is useless and will not convince anybody that they do not _need_ a GUI. It makes a very poor case. If you know what terminal is and how to launch it you already know way more than that article shows, if you don't then there is no way it will convince you that you do not need something like Finder.
I always have a problem with not dog fooding. If we're building UIs and such then we should use them, learn from them, etc. Yes. Absolutely. They sometimes have limits. But scarcity breeds innovation. It's hard to imagine in 2017 that we're accepting CLI as innovation. That's just feels too silly to me.
GUIs are about showing what you can do.
CLIs are about memorizing what you can do.
One suits computers and the tiny amount of population with aspergers, the other suits normal people.
CLIs are about memorizing what you can do.
One suits computers and the tiny amount of population with aspergers, the other suits normal people.
CLI's are automatable and scriptable in ways we still haven't achieved with GUIs.
They are also usually easier to write and to maintain.
There are many, many more reasons too.
[deleted]
[deleted]
FLAC developer Josh Coalson made the point well:
[QUOTE] ... to me, GUIs are like a caveman language where you have to grunt (click) and wave your hands (mouse) at the computer until it does what you want. (imagine the mouse pointer as your hand, then say "ugh" every time you click to mean "ME WANT THAT".) if whoever wrote the gui didn't add a feature that you can specifically communicate with an exact grunt and wave sequence, you're out of luck and have to ask the developer to add that.
Shell scripting is like spoken language, a much more natural and powerful way to communicate what you want to do. instead of every developer having to reimplement functionality for crawling a tree and doing something, one guy just writes the 'find' command and it's usable in conjunctions with other commands. [/QUOTE]
source: https://hydrogenaud.io/index.php?PHPSESSID=ae25885agmimsrj76...
[QUOTE] ... to me, GUIs are like a caveman language where you have to grunt (click) and wave your hands (mouse) at the computer until it does what you want. (imagine the mouse pointer as your hand, then say "ugh" every time you click to mean "ME WANT THAT".) if whoever wrote the gui didn't add a feature that you can specifically communicate with an exact grunt and wave sequence, you're out of luck and have to ask the developer to add that.
Shell scripting is like spoken language, a much more natural and powerful way to communicate what you want to do. instead of every developer having to reimplement functionality for crawling a tree and doing something, one guy just writes the 'find' command and it's usable in conjunctions with other commands. [/QUOTE]
source: https://hydrogenaud.io/index.php?PHPSESSID=ae25885agmimsrj76...
I'm not sure where the "point and grunt" analogy came from, but I first read it from Eben Moglen. I can't remember where, but there are lots of examples floating around, e.g. at http://www.cabinetmagazine.org/issues/1/i_moglen_1.php
> In 1979, when I was working at IBM, I wrote an internal memo lambasting the Apple Lisa, which was Apple`s first attempt to adapt Xerox PARC technology, the graphical user interface, into a desktop PC. I was then working on the development of APL2, a nested array, algorithmic, symbolic language, and I was committed to the idea that what we were doing with computers was making languages that were better than natural languages for procedural thought. The idea was to do for whole ranges of human thinking what mathematics has been doing for thousands of years in the quantitative arrangement of knowledge, and to help people think in more precise and clear ways. What I saw in the Xerox PARC technology was the caveman interface, you point and you grunt. A massive winding down, regressing away from language, in order to address the technological nervousness of the user. Users wanted to be infantilized, to return to a pre-linguistic condition in the using of computers, and the Xerox PARC technology`s primary advantage was that it allowed users to address computers in a pre-linguistic way. This was to my mind a terribly socially retrograde thing to do, and I have not changed my mind about that. I lost that war in the early 1980s, went to law school, got a history PHD, did other things, because the fundamental turn in the technology - which we see represented in its most technologically degenerate form, which is Windows, the really crippled version. I mean, I use Xwindows every day on my free-software PCs; I have nothing against a windowing environment, but it`s a windowing environment which is network transparent and which is based around the fact that inside every window there`s some dialogue to have with some linguistic entity.
> In 1979, when I was working at IBM, I wrote an internal memo lambasting the Apple Lisa, which was Apple`s first attempt to adapt Xerox PARC technology, the graphical user interface, into a desktop PC. I was then working on the development of APL2, a nested array, algorithmic, symbolic language, and I was committed to the idea that what we were doing with computers was making languages that were better than natural languages for procedural thought. The idea was to do for whole ranges of human thinking what mathematics has been doing for thousands of years in the quantitative arrangement of knowledge, and to help people think in more precise and clear ways. What I saw in the Xerox PARC technology was the caveman interface, you point and you grunt. A massive winding down, regressing away from language, in order to address the technological nervousness of the user. Users wanted to be infantilized, to return to a pre-linguistic condition in the using of computers, and the Xerox PARC technology`s primary advantage was that it allowed users to address computers in a pre-linguistic way. This was to my mind a terribly socially retrograde thing to do, and I have not changed my mind about that. I lost that war in the early 1980s, went to law school, got a history PHD, did other things, because the fundamental turn in the technology - which we see represented in its most technologically degenerate form, which is Windows, the really crippled version. I mean, I use Xwindows every day on my free-software PCs; I have nothing against a windowing environment, but it`s a windowing environment which is network transparent and which is based around the fact that inside every window there`s some dialogue to have with some linguistic entity.
Thanks for the reference to that interview -- it's also an interesting resource for the crypto wars.
Edit: it's also apparently one source for Eben's idea that I read a while ago but couldn't find again, about the switch from fighting over crypto for privacy to fighting over crypto for DRM (though it seems like in past few years we've gone back to fighting over crypto for privacy again).
Edit: it's also apparently one source for Eben's idea that I read a while ago but couldn't find again, about the switch from fighting over crypto for privacy to fighting over crypto for DRM (though it seems like in past few years we've gone back to fighting over crypto for privacy again).
The tasks I was referring to are clearly developer-centric tasks. Applications for "normal people" are an entirely different animal of course.
Kind of funny that we have initiatives like "everyone should be a programmer" but then we don't even trust "normal people" to learn how to use a CLI.
I think the key distinction is between different kinds of tasks (and importantly, the scale on which those tasks are done) rather than different kinds of people.
I'm a developer and a normal person.
CLIs are idiotic. Why can't you just click a button and be done, certainly not sit there and spend 20 minutes figuring out what the fuck -g means or if knockut-sortable is missing an o.
It's utterly ridiculous that you're discussing this and just shows how many of you are utterly brainwashed by utterly useless trivia that your computer should be memorising for you but your fellow programmers are too lazy to implement GUIs for.
I honestly can't comprehend that you so gleefully spend your time so pointlessly, you should be spending your brains on solving actual life and business problems, not memorising the syntax of CLIs you'll use once every 3 months, or worse still, never again, or virtually useless regex syntax.
CLIs are idiotic. Why can't you just click a button and be done, certainly not sit there and spend 20 minutes figuring out what the fuck -g means or if knockut-sortable is missing an o.
It's utterly ridiculous that you're discussing this and just shows how many of you are utterly brainwashed by utterly useless trivia that your computer should be memorising for you but your fellow programmers are too lazy to implement GUIs for.
I honestly can't comprehend that you so gleefully spend your time so pointlessly, you should be spending your brains on solving actual life and business problems, not memorising the syntax of CLIs you'll use once every 3 months, or worse still, never again, or virtually useless regex syntax.
The day when gui applications have anywhere near the composability of cli applications, I'll think about it.
> I'm a developer
> useless regex
I don't know what kind of developing you do but regexes are massively useful if you do any sort of string handling or input checking.
> CLIs you'll use once every 3 months
Funny, I spend 90% of my time in a CLI. I don't spend my time memorizing stuff, the commands I use frequently are committed to muscle memory, the rest I look up. If you spend time with the CLI you learn to look stuff up not too inefficiently. Looking for a menu entry in a GUI is more painful to me than reading/grepping a man page.
Sounds like you really hate CLIs, I hope you don't have to use them too often, there's no reason why everyone has to use them, but I promise you, there are hundreds of thousands if not millions of productive CLI users out there.
> I'm a developer
> useless regex
I don't know what kind of developing you do but regexes are massively useful if you do any sort of string handling or input checking.
> CLIs you'll use once every 3 months
Funny, I spend 90% of my time in a CLI. I don't spend my time memorizing stuff, the commands I use frequently are committed to muscle memory, the rest I look up. If you spend time with the CLI you learn to look stuff up not too inefficiently. Looking for a menu entry in a GUI is more painful to me than reading/grepping a man page.
Sounds like you really hate CLIs, I hope you don't have to use them too often, there's no reason why everyone has to use them, but I promise you, there are hundreds of thousands if not millions of productive CLI users out there.
I'm a developer, and an ex-sysadmin. Using the CLI makes my life much simpler. I greatly prefer being able to write scripts, and use things like PDSH to run commands across many boxes. For example, go through every web server, search their logs for occurrences of IP X and then count the number the number of requests per second. Is this something I do every day, nope, but the basics of doing it are the same as the basics of so many other things that I do that there is no issue memorizing the commands.
Using guis and managing a server without a CLI is a very annoying situation.
There are other things where using a GUI is way nicer, like complicated partial git commits.
Also thanks for informing me that I have aspergers, guess I'll have to go have a doctor check that out ;)
Using guis and managing a server without a CLI is a very annoying situation.
There are other things where using a GUI is way nicer, like complicated partial git commits.
Also thanks for informing me that I have aspergers, guess I'll have to go have a doctor check that out ;)
How you can tell someone is perfectly normal: they will tell you they are normal.
On the topic, some GUIs are idiotic. A command takes a second to type, but a complicated GUI may take multiple buttons, menus, etc. that take almost forever to navigate.
On the topic, some GUIs are idiotic. A command takes a second to type, but a complicated GUI may take multiple buttons, menus, etc. that take almost forever to navigate.
> Why can't you just click a button and be done
Because there isn't a button to just do everything I want to do and if there was I'd have to find it amongst a million buttons.
Because there isn't a button to just do everything I want to do and if there was I'd have to find it amongst a million buttons.
> I honestly can't comprehend that you so gleefully spend your time so pointlessly, you should be spending your brains on solving actual life and business problems, not memorising the syntax of CLIs you'll use once every 3 months, or worse still, never again, or virtually useless regex syntax.
This makes me skeptical that you're a programmer, because you just described programming. CLIs are everywhere in programming, and if you haven't written a script you prototyped on a command line, you can't be very experienced as programmer.
This makes me skeptical that you're a programmer, because you just described programming. CLIs are everywhere in programming, and if you haven't written a script you prototyped on a command line, you can't be very experienced as programmer.
Eh, beware overgeneralization from your specific context. I've been working in the Rails/OSS world for the last 5 years or so, and I agree that in this context, someone claiming dislike of CLIs would give me pause.
However, I spent a decade working in .NET on Windows – mostly before PowerShell became popular/usable. A lot of good, experienced programmers in that space rarely used a CLI. I personally had some batch scripts that I used often, but for most people on my team, the CLI was just used for infrequent admin tasks, e.g., debugging a networking issue, restarting IIS, etc. No part of the daily programming workflow depended on a CLI.
I've also worked around some iOS developers, and their workflow seemed similar in that most of them rarely used the terminal for anything beyond infrequent admin tasks or maybe version control.
So yeah, I live in the shell, and it's hard to imagine anyone working in Ruby (or Python or server-side JS) for long without heavy CLI usage. I love the power and composability of the command line, but I also understand that not everyone does and not everyone needs to.
Edit: This might be a flawed analogy, but my feelings on this are similar to my feelings on an IDE vs a text editor. I've become a somewhat passionate vim user, but I wouldn't negatively judge a .NET developer for using Visual Studio nor an iOS developer for using Xcode.
However, I spent a decade working in .NET on Windows – mostly before PowerShell became popular/usable. A lot of good, experienced programmers in that space rarely used a CLI. I personally had some batch scripts that I used often, but for most people on my team, the CLI was just used for infrequent admin tasks, e.g., debugging a networking issue, restarting IIS, etc. No part of the daily programming workflow depended on a CLI.
I've also worked around some iOS developers, and their workflow seemed similar in that most of them rarely used the terminal for anything beyond infrequent admin tasks or maybe version control.
So yeah, I live in the shell, and it's hard to imagine anyone working in Ruby (or Python or server-side JS) for long without heavy CLI usage. I love the power and composability of the command line, but I also understand that not everyone does and not everyone needs to.
Edit: This might be a flawed analogy, but my feelings on this are similar to my feelings on an IDE vs a text editor. I've become a somewhat passionate vim user, but I wouldn't negatively judge a .NET developer for using Visual Studio nor an iOS developer for using Xcode.
.NET has shifted significantly towards command lines with PowerShell, Windows Nano Server, and the nuget shell.
>Why can't you just click a button and be done
Dump 150 table database, both schema and data. Except two tables, for which you need only schema. Then compress, encrypt & email.
With CLI I can spend 10 minutes looking up documentation, shove command into shell, start it and go to lunch. If I need to something like that again, I can Ctrl-R it, tune and launch again in couple minutes.
But maybe there is a button I can just click?
Dump 150 table database, both schema and data. Except two tables, for which you need only schema. Then compress, encrypt & email.
With CLI I can spend 10 minutes looking up documentation, shove command into shell, start it and go to lunch. If I need to something like that again, I can Ctrl-R it, tune and launch again in couple minutes.
But maybe there is a button I can just click?
I think that's exactly the kind of workflow we should be able to create a graphical interface for.
I sometimes wonder if our ability to imagine what visual interfaces can do is limited by our experience with current GUIs. Right now, as other have pointed out, we're limited by the fact that GUI interfaces aren't really composable the way CLI commands are.
But what if we had something that is composable -- maybe something like Smalltalk on steroids -- where every program is a living object that can describe in detail what it does? Then, you'd be able to ask the program what inputs it requires, what its abilities are, and what outputs it can provide.
With something like that, it would be possible to visually put together interesting combinations of programs that we might not have created otherwise. Sort of the like what Bret Victor describes in 'Inventing on Principle'[1] where certain solutions to problems become much more apparent when you can manipulate things and try out new combinations quickly. I'm certain things like this exist (and have existed) in various forms, but I don't think we've explored the concept as fully as we can.
On the other hand, though, I agree with a quote from Eben Moglen earlier in this thread where he talked about 'point and grunt' interfaces. We've been iterating on the same paradigm for a long time. Touchscreens are better in some ways, and worse in others. We gain more physical interactivity with our devices, but we lose a lot of precision because we're now just smacking meat sticks against a pane of glass.
But you know, it's easy for me to sit here and complain about this on the internet. Actually doing something about it is much harder. Maybe it's time for me to fire up Smalltalk and give it a try. :)
[1] https://vimeo.com/36579366
I sometimes wonder if our ability to imagine what visual interfaces can do is limited by our experience with current GUIs. Right now, as other have pointed out, we're limited by the fact that GUI interfaces aren't really composable the way CLI commands are.
But what if we had something that is composable -- maybe something like Smalltalk on steroids -- where every program is a living object that can describe in detail what it does? Then, you'd be able to ask the program what inputs it requires, what its abilities are, and what outputs it can provide.
With something like that, it would be possible to visually put together interesting combinations of programs that we might not have created otherwise. Sort of the like what Bret Victor describes in 'Inventing on Principle'[1] where certain solutions to problems become much more apparent when you can manipulate things and try out new combinations quickly. I'm certain things like this exist (and have existed) in various forms, but I don't think we've explored the concept as fully as we can.
On the other hand, though, I agree with a quote from Eben Moglen earlier in this thread where he talked about 'point and grunt' interfaces. We've been iterating on the same paradigm for a long time. Touchscreens are better in some ways, and worse in others. We gain more physical interactivity with our devices, but we lose a lot of precision because we're now just smacking meat sticks against a pane of glass.
But you know, it's easy for me to sit here and complain about this on the internet. Actually doing something about it is much harder. Maybe it's time for me to fire up Smalltalk and give it a try. :)
[1] https://vimeo.com/36579366
[deleted]
>CLIs are about memorizing
CMD --help
man CMD
Tab competition
Command line history search
CMD --help
man CMD
Tab competition
Command line history search
"...none of them is easier..."
Subjective. However, if you can type at a reasonable speed, the terminal is faster than moving a mouse around.
Now, GUI makes more sense for many things. Kinda hard to edit video without a GUI (but if someone has a command-line-driven video rendering editor, let me know - I want to explore this.) Visual programming wouldn't be 'visual' without GUI.
Subjective. However, if you can type at a reasonable speed, the terminal is faster than moving a mouse around.
Now, GUI makes more sense for many things. Kinda hard to edit video without a GUI (but if someone has a command-line-driven video rendering editor, let me know - I want to explore this.) Visual programming wouldn't be 'visual' without GUI.
Nah, it's (type + remember) speed that makes command lines frustrating. They're only fast if you use them constantly or write scripts. As soon as you have to look up an argument order or a command flag, you've lost all that efficiency.
Bash completion is still pretty fast for most commands. If you need --help or man, it will slow you down considerably
Slowdown will turn fairly quickly into a major speedup if you're trying to do operations on multiple files.
Most of the speedup of automating repetative flows can be recovered using a program like AutoHotKey.
You can also configure zsh to show you all the autocomplete options (files/directories, flags, command-specific arguments like git tags, etc.) and tab/arrow key through them visually: http://i47.tinypic.com/2qtwxnn.gif
(The gif is a little slow, but you can obviously move through them a fast as you can hit the keys)
(The gif is a little slow, but you can obviously move through them a fast as you can hit the keys)
In my experience, the slowdown is usually not remembering the command, but remembering, say, whether you want -f, -F, --force, --hard or some other option for this particular command.
Even common commands have this problem — for example, I don't copy files all that much, so when I do, I frequently forget that cp takes -R instead of -r.
Even common commands have this problem — for example, I don't copy files all that much, so when I do, I frequently forget that cp takes -R instead of -r.
doesn't cp take -r,-R or --recursive? or is it OS specific? in Ubuntu or CentOS I believe they're all the same
It's program specific. The vast majority of linux distros come with GNU cp, which takes either. BSD's version of cp only takes -R, Mac's too I suppose since it's BSD-based.
The annoying ones on linux are chmod/chown, they take -R only.
EDIT: it's OS specific in the sense that these programs follow the OS's convention, I expect BusyBox cp, a lightweight Linux version of cp, has the same options as GNU cp
The annoying ones on linux are chmod/chown, they take -R only.
EDIT: it's OS specific in the sense that these programs follow the OS's convention, I expect BusyBox cp, a lightweight Linux version of cp, has the same options as GNU cp
chmod is that way because ambiguity... -r is take away read...
POSIX only specifies -R. Actual implementations of cp can include whatever nonstandard arguments they want, such as -r in GNU cp.
thanks a lot, gotta read more about POSIX ^^
> Visual programming wouldn't be 'visual' without GUI.
Have you heard of one of the most popular visual editor called 'vi' (short form of 'visual')?
But of couse I don't use it. Once you know Emacs well, you won't either. :-)
Have you heard of one of the most popular visual editor called 'vi' (short form of 'visual')?
But of couse I don't use it. Once you know Emacs well, you won't either. :-)
> if someone has a command-line-driven video rendering editor, let me know - I want to explore this.
There is a linear editor called AviSynth that's relatively popular and very Windows-based.
There is a linear editor called AviSynth that's relatively popular and very Windows-based.
>Subjective
Straight up.
apt-get /pip /equivalents are all astonishingly efficient methods of installing programs. Have seen many non-tech inclined people change their mind quickly once being exposed to it.
Perhaps we should be asking people to try first? A gui is a necessity in certain situations, but it shouldn't be lore.
Demand more and you will get more.
Straight up.
apt-get /pip /equivalents are all astonishingly efficient methods of installing programs. Have seen many non-tech inclined people change their mind quickly once being exposed to it.
Perhaps we should be asking people to try first? A gui is a necessity in certain situations, but it shouldn't be lore.
Demand more and you will get more.
So is the "You Don't Need Javascript (css is powerful enough)" one. Most of those were cool proof of concept demos made in CSS with no JS. One of them was just a straight up game... I don't see how any of that is actually useful, other than being kinda cool.
I was hoping for actual small common cases where people use JS to do something that's super easy with CSS, like animations.
I was hoping for actual small common cases where people use JS to do something that's super easy with CSS, like animations.
I'm greatly underwhelmed on that one because there is zero information about the compatibility of those solutions, the pros and cons, the most appropriate use cases, etc. They're just demos without context.
Or it could just have a last item of "all of these commands are combinable, scriptable and repeatable".
I have always dream of hybrid software, meaning GUIs which show in real time the CLI equivalent of each one of your actions on the GUI, so later on everything you did in the GUI is combinable/scriptable, etc
I've seen a few ffmpeg GUIs that show you the exact command that will be executed. nmap's Zenmap also shows you the command it's using.
I think AutoCAD does this?
I actually built one of these hybrids for a piece of chip design software, where scripting is very much expected. Architectural bonuses were that it was almost like having a GUI microservice; it could iterate separately, be written in a different language, and crash separately too.
I actually built one of these hybrids for a piece of chip design software, where scripting is very much expected. Architectural bonuses were that it was almost like having a GUI microservice; it could iterate separately, be written in a different language, and crash separately too.
It does. I don't know any professional user that doesn't use the CLI. (I'm an architect). I still dream with the day that Photoshop gets one also..
Is macro recording (and editing) still a thing? I haven't used MS Office in a while...
Doesn't apple have something like that?
Either way, I think log files of actions taken are much more debuggable than watching a computer control the gui.
Either way, I think log files of actions taken are much more debuggable than watching a computer control the gui.
Yes, AppleScript did this way back in the pre-OS X days -- but only if you added Apple Events support to your app, which was extremely fiddly and tedious.
Their current tool Automator is supposed to do this, but I don't know how widely it's supported. I suspect just like everything else, it has niche of users who love it and depend on it. It's not something your typical Mac user would think to reach for.
Their current tool Automator is supposed to do this, but I don't know how widely it's supported. I suspect just like everything else, it has niche of users who love it and depend on it. It's not something your typical Mac user would think to reach for.
I am not criticising then CLI, but the actual repo which feels like the first class in first year of CS. cp, ls, stat, zip... nom much you can repeat or compose there.
I have enjoyed spending hours removing libraries full of bootstrap and angular and replacing them with a simple CSS page and a JavaScript one-liner in my current work project.
You've enjoyed it, but those hours cost your business, and is that really worth it?
Some beliefs which are frequently displayed in these parts:
> Money on chairs / desks / PCs are no object because developers cost money, not those things
> Ship quickly and iterate
> Make it, make it work, make it fast
> Write code your successor can maintain
And then HN goes ahead and upvotes a boast about spending their (expensive) time unpicking libraries from code.
The point of "you might not need X" is to encourage package maintainers to keep their sub-package footprint small, not that end-users shouldn't use X.
I'm sure you'll be back to suggest that you've delivered "500% speed-up" or some other nonsense metric and I look forward to that.
Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.
If you really replaced angular with a "javascript one-liner" I'd like to see that line!
Some beliefs which are frequently displayed in these parts:
> Money on chairs / desks / PCs are no object because developers cost money, not those things
> Ship quickly and iterate
> Make it, make it work, make it fast
> Write code your successor can maintain
And then HN goes ahead and upvotes a boast about spending their (expensive) time unpicking libraries from code.
The point of "you might not need X" is to encourage package maintainers to keep their sub-package footprint small, not that end-users shouldn't use X.
I'm sure you'll be back to suggest that you've delivered "500% speed-up" or some other nonsense metric and I look forward to that.
Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.
If you really replaced angular with a "javascript one-liner" I'd like to see that line!
I'm going to take a guess and say he won big in maintainability and performance on low-end devices.
If it will operate with no js at all, then it is also more compatible with some security requirements I have.
Don't get me wrong, I've always been a big fan of JavaScript, warts and all. However, in this particular instance, what should have been a simple server rendered login page was written with a full SPA application development mindset.
I see where you are coming from, there rarely is any reason to reinvent the wheel, but at some point reducing libraries is beneficial for the long run when and if you can afford it.
I think the "enjoyed" part was definitely meant facetiously.
Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.
I suspect the problem the commenter is hinting at concerns situations where people think they need the "value of {angular,react,bootstrap,whatever}" when really they don't.
Ultimately, custom business owned code which attempts to deliver the value of angular is just a future maintenance nightmare, and I say that as someone who really doesn't like angular.
I suspect the problem the commenter is hinting at concerns situations where people think they need the "value of {angular,react,bootstrap,whatever}" when really they don't.
Just because you can't give a $ amount for the costs saved by reducing complexity, doesn't mean it doesn't have value. Simple is good.
We all do things that aren't objectively "worth it". Was the time you took to type this post really worth it?
I wouldn't think someone's livelihood depends on worthiness of this post. In businesses, however, that often is a case.
Depends if they are on HN at work...
What about the money lost because people don't wanna use your app because it's bloated and slow?
I wonder what the % of people in HN would be unemployed if more businesses relied on small, static or server rendered web apps instead of huge SPAs.
I strongly believe that the big line of business app I worked on for a number of years would have employed fewer people if we had designed it as an SPA backed by APIs instead of a traditional Rails app. Path dependency is real, and by the time we realized that people wanted a lot more web application behavior than we originally thought, it was time consuming to make it happen.
To be sure, lots of projects have the opposite problem, but SPAs aren't some make-work conspiracy, they have real use.
To be sure, lots of projects have the opposite problem, but SPAs aren't some make-work conspiracy, they have real use.
Isn't increased complexity as codebase grows a basic rule of all computer programs? And don't say microservices are exempt - you'll have the same complexity on the tooling side.
Yes, but my conclusion in this case is that the way we started building the application - traditional full-page-load Rails with custom javascript - resulted in more complexity than if we had started with a "single page app" using a framework like Backbone (which, in fairness, was very new at the time).
I didn't actually say anything about microservices. I think that may have also been a win, but it is much less clear-cut. Backing the front-end with a single monolithic API server would have been an improvement over the hybrid page generation / API approach we ended up with.
These are all just my own personal conclusions, and others who also worked on the project may not agree with me, but I'm just not convinced by the backlash against js-heavy web apps, because I believe I've felt the pain of going the opposite route in the wrong case.
I didn't actually say anything about microservices. I think that may have also been a win, but it is much less clear-cut. Backing the front-end with a single monolithic API server would have been an improvement over the hybrid page generation / API approach we ended up with.
These are all just my own personal conclusions, and others who also worked on the project may not agree with me, but I'm just not convinced by the backlash against js-heavy web apps, because I believe I've felt the pain of going the opposite route in the wrong case.
In my experience the clean separation between UI and backend code that a SPA enforces is an enormous maintainability boost.
Add to that, that you then have by necessity an API you can use for other systems to interact with yours (or just to build some quick one off scripts) and the advantages are even clearer.
Add to that, that you then have by necessity an API you can use for other systems to interact with yours (or just to build some quick one off scripts) and the advantages are even clearer.
That's a false dichotomy. Business apps become huge codebases due to lack of engineering discipline and cutting corners to make deadlines. It happens regardless of whether the code is written for the browser or the server because there is no environment that will substitute for the skill that is necessary to control complexity in businesses which are inherently unpredictable.
I feel a strong need for You-Dont-Need-Windows
Try verifying authenticode signatures in exes correctly without Windows.
> Try verifying authenticode signatures in exes correctly without Windows.
When You-Dont-Need-Windows, You don't need this either. Do you?
When You-Dont-Need-Windows, You don't need this either. Do you?
If you want to compile to windows, you absolutely do.
I think the argument/joke he's trying to make is that he'd be happier without anyone using Windows (which would conveniently solve the problem of having to compile to Windows)
I get the joke and I've been aggressively trying to avoid it. But you can't, unless you only deal with phones or server backend.
Coming from a Linux user, for most people, Windows is the only usable non-Apple-hardware OS, unfortunately.
Coming from a Linux user, for most people, Windows is the only usable non-Apple-hardware OS, unfortunately.
I was able to convince several people to move from windows to GNU/Linux. In some cases, it didn't took more than 2 minutes!
Case 1: Religious/moral people: If you are using unauthorized (pirated?) copies of windows, isn't it like stealing? Think of the amount you are stealing just by installing M$-something, Adobe something, etc.
How can you wish that your money/wealth shouldn't be stealed when you steals somebody else's money?
Case 2: Business people: Have you ever contacted M$ for support? Then why would you pay them, just for something that runs viruses smoothly, and occasionally having blue screen of death?
Case 3: Personal: I came to know that I was like a frog in a well when I was introduced to GNU/Linux. Thanks to Microsoft for wasting my 10 years of time. Now I know about windows, may be more than some windows admin would do, just because I don't use windows anymore!
Serious GNU/Linux users may not have a solution known for an immediate problem. But they know how to find a solution or where to look for it.
Case 1: Religious/moral people: If you are using unauthorized (pirated?) copies of windows, isn't it like stealing? Think of the amount you are stealing just by installing M$-something, Adobe something, etc.
How can you wish that your money/wealth shouldn't be stealed when you steals somebody else's money?
Case 2: Business people: Have you ever contacted M$ for support? Then why would you pay them, just for something that runs viruses smoothly, and occasionally having blue screen of death?
Case 3: Personal: I came to know that I was like a frog in a well when I was introduced to GNU/Linux. Thanks to Microsoft for wasting my 10 years of time. Now I know about windows, may be more than some windows admin would do, just because I don't use windows anymore!
Serious GNU/Linux users may not have a solution known for an immediate problem. But they know how to find a solution or where to look for it.
I generally tend to shy away from trying to convince people that they should change their operating system. I find it quite annoying in the (thankfully rare) occasions that some overzealous Mac user tries to tell me that my choice of machine/operating system is inferior, so I find it hard to believe that other people wouldn't feel the same way if I tried to someone else that their choice is incorrect (even if I feel strongly that it is).
Of course, if someone is interested in learning more about Linux, I'll happily teach them as much as they want to know and give them my opinions of the advantages of using Linux. But unless the person is already open to hearing my opinions on the topic, it tends to be a waste of both of our time.
Of course, if someone is interested in learning more about Linux, I'll happily teach them as much as they want to know and give them my opinions of the advantages of using Linux. But unless the person is already open to hearing my opinions on the topic, it tends to be a waste of both of our time.
`chktrust` in Mono can apparently do this. I'm not sure if `osslsigncode` can, but if so, it has less dependencies.
I would have been extremely happy if that worked.
It doesn't check everything and has some bugs. osslsigncode goes most of the way there but you have to write a lot of the remaining parts yourself using a combination of openssl C API and add a ton of extra C code.
And this is the kind of crypto that is challenging to get exactly right with no vulns especially in C/C++.
It doesn't check everything and has some bugs. osslsigncode goes most of the way there but you have to write a lot of the remaining parts yourself using a combination of openssl C API and add a ton of extra C code.
And this is the kind of crypto that is challenging to get exactly right with no vulns especially in C/C++.
Can we have "You Don't Need Electron" too?
Can we expand that to node and the entire ecosystem?
Electron.js: Run Electron apps in any browser.
~~No external dependencies~~ Builds a statically linked Chrome, so just `npm install` and you're good to go
~~No external dependencies~~ Builds a statically linked Chrome, so just `npm install` and you're good to go
eye twitch
There's a lesson there - making software easier to build and install goes a long way. Go has that advantage too.
joshmanders(2)
Some of these things are actually pretty cool IMO, like http://keithclark.co.uk/articles/pure-css-parallax-websites/... from https://github.com/you-dont-need/You-Dont-Need-Javascript#Pa...
In theory css parallax is brilliant and should replace all bloated js versions. In practice, it's unusable. We spent 40 hours as two experienced frontend engineers trying to get the example to work on a relatively simple example but it requires such a specific markup that it became too convoluted. Eventually I gave in and looked for a js solution but those were much larger and slower than we wanted. Ultimately, ended up writing a short 100-line open source vanilla js lib, and a bunch of folks seemed to be having our same issues: https://github.com/dixonandmoe/rellax. That said I still love to explore the extents of css' capabilities but this is one time where it fell short.
Exact same problem, actually tried making this example mentioned here to work on other browsers besides Chrome and failed to do so.
Your rellax library looks really useful i just hope i won't have to build parallax websites anymore.
I am looking forward to "you don't need Git" :D
It would be nice if the examples would have a browser compatibility table.
Without it is is just a waste of time.
The first one I tried (CSS only accordion) takes you to a site where the author himself says that this is an experiment and was not meant for use in production (no IE support).
Without it is is just a waste of time.
The first one I tried (CSS only accordion) takes you to a site where the author himself says that this is an experiment and was not meant for use in production (no IE support).
This is great but as the author points out - outside of primitives you might as well use lodash.
Also, compatibility for these noon lodash methods are chrome and Firefox.
Also, compatibility for these noon lodash methods are chrome and Firefox.
Some of these CSS ones have to be a joke. Using CSS based font creation? Seriously?
[deleted]
Someone should create one for jQuery and Bootstrap
There's this: http://youmightnotneedjquery.com/
Or, say, for us 95% of programmers who never use javascript at all, or program for the web for that matter.
In the case of lodash, those functions exist mostly to interoperate with other lodash functions, like chain.
_.get() is the killer feature of lodash.
[deleted]
You don't need web apps would be nice as well :)
You don't need javascript is really cool~
[deleted]