4 ms·

"...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 m

by delinka 10y ago

"...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.

astrange 10y ago
> 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.
- lozf 10y ago
  Fully open source and cross platform: mpv (or mplayer) + aalib in conjunction with ffmpeg.
  - astrange 10y ago
    It'd be hard to do more than cutting frames out with that. Wait, does anyone actually use the aalib output? I thought it was a joke.
Retra 10y ago
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.
- omribahumi 10y ago
  Bash completion is still pretty fast for most commands. If you need --help or man, it will slow you down considerably
  - chc 10y ago
    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.
    - lccarrasco 10y ago
      doesn't cp take -r,-R or --recursive? or is it OS specific? in Ubuntu or CentOS I believe they're all the same
      - greenshackle2 10y ago
        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
        phillipwills 10y ago
        chmod is that way because ambiguity... -r is take away read...
      - chc 10y ago
        POSIX only specifies -R. Actual implementations of cp can include whatever nonstandard arguments they want, such as -r in GNU cp.
        lccarrasco 10y ago
        thanks a lot, gotta read more about POSIX ^^
  - megous 10y ago
pksadiq 10y ago
> 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. :-)
_coldfire 10y ago
>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.

by delinka 10y ago

astrange 10y ago

> 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.

lozf 10y ago
Fully open source and cross platform: mpv (or mplayer) + aalib in conjunction with ffmpeg.
- astrange 10y ago
  It'd be hard to do more than cutting frames out with that. Wait, does anyone actually use the aalib output? I thought it was a joke.

Retra 10y ago

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.

omribahumi 10y ago
Bash completion is still pretty fast for most commands. If you need --help or man, it will slow you down considerably
- chc 10y ago
  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.
  - lccarrasco 10y ago
    doesn't cp take -r,-R or --recursive? or is it OS specific? in Ubuntu or CentOS I believe they're all the same
    - greenshackle2 10y ago
      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
      - phillipwills 10y ago
        chmod is that way because ambiguity... -r is take away read...
    - chc 10y ago
      POSIX only specifies -R. Actual implementations of cp can include whatever nonstandard arguments they want, such as -r in GNU cp.
      - lccarrasco 10y ago
        thanks a lot, gotta read more about POSIX ^^
- megous 10y ago

pksadiq 10y ago

> 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. :-)

_coldfire 10y ago

>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.