Live data from Hacker News

The power of the command-line as a programming environment

pindexis.github.io

11–20 of 35 posts

Re: The power of the command-line as a programming environment

#11
post #5
post #3

I find that after I discovered tmux, I was able to use the command line full-time much more easily. Now everything I do is command-line-unix-ey, from my coding (with Emacs) to my web browser (Elinks). It's kind of a pain in the butt to learn, but I feel that it helps me stay focused on my work; there are a lot less distractions in the command-line world.

I like the idea of text-mode browsing, but I find the translation of CSS causes practical problems whether its elinks link lynx etc. For example, Hacker News nested comments are displayed as being on one level. There is a hack to fix this, but per-site hacks is not a usable way to browse the web.

I'll agree there, but I feel that that is a fixable problem overall; if I knew anything about ncurses I'd fix it myself :D.

I still think using Elinks of w3m creates a more streamlined experience if your end goal is getting work done.

Re: The power of the command-line as a programming environment

#12
post #4

"Now why the command-line is not the main choice among developers?" It depends who you speak to. Where I work, almost everybody uses the command line.

And people using IDEs sometimes use the command line even if they think they are not. Example: a team I trained to Ruby on Rails recently was using Ruby Mine, an IDE for Ruby. Nearly all the advanced stuff (rake this, rake that) involved looking for some menu entry and typing in the rake arguments. If they had an open terminal in the project directory they'd get those tasks done much quickly. Obviously they resisted the idea.

Re: The power of the command-line as a programming environment

#13

The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line. For those writers who insist on using the term "command line" to mean avoiding…

The difference between a Command-Line Interface (argv-based) and a Textual User Interface (e.g. ncurses or fdisk-style interactive) is very important; the latter generally just means "a very bad but low-bandwidth GUI with no mouse support", but the former implies several attributes that allow for automation and programability: the course of interaction with a program (its command-line invocation) becomes an object trivially manipulable in its own right by users and programs.

We need to improve from the command-line by enabling even more expressive operations on programs invocations: programs should cooperate to enable perfect completion in a way that doesn't require writing custom completion scripts for every (shell, tool) combination, and they could describe their input and output formats to allow the shell to do "program search" in the space of command-lines. Given fairly rough user input, the shell can help guide the user to where they were trying to go with less work. Computers should be using some CPU time to actually help us figure out what we're trying to do, instead of everyone still hunting down syntax errors and reading man pages like it's the 1980's.

Re: The power of the command-line as a programming environment

#14

The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line. For those writers who insist on using the term "command line" to mean avoiding…

> What term should I use to refer to those conventions?

POSIX.

But note that using pure POSIX limits you because you don't get advantage of easy-to-use composability using pipes & substitution. It's a free world, of course.

Re: The power of the command-line as a programming environment

#15
post #5
post #3

I find that after I discovered tmux, I was able to use the command line full-time much more easily. Now everything I do is command-line-unix-ey, from my coding (with Emacs) to my web browser (Elinks). It's kind of a pain in the butt to learn, but I feel that it helps me stay focused on my work; there are a lot less distractions in the command-line world.

I like the idea of text-mode browsing, but I find the translation of CSS causes practical problems whether its elinks link lynx etc. For example, Hacker News nested comments are displayed as being on one level. There is a hack to fix this, but per-site hacks is not a usable way to browse the web.

> For example, Hacker News nested comments are displayed as being on one level.

I think that this is because syntactically they are on the same level. Assuming I'm reading the source correctly, they're all cells in a table, at the same level, rather than being nested.

So elinks et al. are correct; the site is using CSS to indicate something not in the structure.

Re: The power of the command-line as a programming environment

#16
post #6

Neal Stephenson's "In the Beginning was the Command Line" is a more in depth take on this topic: http://www.cryptonomicon.com/beginning.html

According to https://en.wikipedia.org/wiki/In_the_Beginning..._Was_the_Co... In a Slashdot interview in 2004, in response to the question: ... have you embraced the new UNIX based MacOS X as the OS you want to use when you "Just want to go to Disneyland"? he replied: I embraced OS X as soon as it was available and have never looked back. So a lot of In the Beginning...was the Command Line is now obsolete. I keep mean…

> I embraced OS X as soon as it was available and have never looked back.

I used the original Mac OS from 1984-2000. I've used Windows since before 1995 until earlier this year. I've used Linux since 1998. I've used Mac OS X every once in awhile when using other folks' computers.

I honestly don't know why someone who's comfortable on the command line (and doesn't need certain proprietary desktop-publishing programs) would use Mac OS X (or Windows). It doesn't give me a decent window manager. It doesn't let me keep my hands on my keyboard (right now, my mouse is almost two feet from my hand, and yet I'm completely happy and able to get around as I need). It doesn't use screen space very well. It's not free. Where having the menubar atop the screen was a good design decision in 1984 with a monitor a few inches tall, it's a horrible choice on a modern large screen: I spend so much time moving the mouse that I spend very little time actually using the computer, rather than moving-and-reading. It certainly doesn't feel like a well-designed, well-integrated whole: it feels like a colossal heap of mystery meat navigation, where nothing is obvious or intuitive, things bounce and slide for no apparent reason and I can't just get my work done.

I get that for certain desktop publishing tasks it's superior, and that if one wants proprietary software then it's a friendlier alternative to Windows (which is the obvious best choice if one wants proprietary software support). But other than that, why pay extra for a Mac? A modern Linux has terminals, web browsers and editors; sound and graphics are not the pain they were in the 90s; what else does one need than a command line, a web browser, a decent editor and some music?

Re: The power of the command-line as a programming environment

#17
post #5
post #3

I find that after I discovered tmux, I was able to use the command line full-time much more easily. Now everything I do is command-line-unix-ey, from my coding (with Emacs) to my web browser (Elinks). It's kind of a pain in the butt to learn, but I feel that it helps me stay focused on my work; there are a lot less distractions in the command-line world.

I like the idea of text-mode browsing, but I find the translation of CSS causes practical problems whether its elinks link lynx etc. For example, Hacker News nested comments are displayed as being on one level. There is a hack to fix this, but per-site hacks is not a usable way to browse the web.

> For example, Hacker News nested comments are displayed as being on one level.

That's probably because HN uses HTML rather poorly (from the point of view of HTML representing the semantics of the content.)

Re: The power of the command-line as a programming environment

#18
post #14

The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line. For those writers who insist on using the term "command line" to mean avoiding…

> What term should I use to refer to those conventions? POSIX. But note that using pure POSIX limits you because you don't get advantage of easy-to-use composability using pipes & substitution. It's a free world, of course.

Good answer to an excellent question. But I do not agree.

POSIX is the whole of a lot of utilities. Most of these utilities I never use, and there is a lot of utilities not part of POSIX that I would consider part of the "command line experience" (editor, tmux, some home grown tools, a REPL or debugger, ...), ssh, ...

Sometimes I refer to shell programs, or shell environments. This adapts to all that I actually use quite flexibly. Both to the tools, and with a special attention to the glue: the POSIX, Ba-, Da-, Z sh.

Interchageably, I also happen to use TTY (pronounced as Tee Tee Why ;) ), terminal, and Console .

I am not particularly happy with any of these, and also do not have a strong preference. I would like to be more consistent in my wording, so opiniated replies are most welcome :)

Re: The power of the command-line as a programming environment

#19
post #13

The exec system call in Unix has an argument named argv which is an array of strings. Each of these strings has traditionally been called a command-line argument. Also, when the user of a Unix shell hits the return key, a string or line of text is submitted to the shell for interpretation, and that string used to be called a command line. For those writers who insist on using the term "command line" to mean avoiding…

The difference between a Command-Line Interface (argv-based) and a Textual User Interface (e.g. ncurses or fdisk-style interactive) is very important; the latter generally just means "a very bad but low-bandwidth GUI with no mouse support", but the former implies several attributes that allow for automation and programability: the course of interaction with a program (its command-line invocation) becomes an object tr…

When it comes to a textual user interface, have you considered Rob Pike's Acme?

http://doc.cat-v.org/plan_9/4th_edition/papers/acme/

Re: The power of the command-line as a programming environment

#20
OK, wonderful. What text editor do you use in this environment? vim? emacs? ed? Where do you run your command line? A command line can run in a dedicated terminal emulator, or it can run...inside of an IDE, or inside of emacs, or tmux. How do you do compile/edit cycles--vim quickfix? Just run the compiler in a separate window and manually move to each error?

The post mentions composition, extensibility, and keyboard instead of mouse. Many IDEs can do that. Certainly emacs can. Then it says that the UNIX way has "consistency." If that were true I wouldn't spend so much time reading the bash man page when I'm trying to figure out all the ${parameter:?expansion} options.

This is not really a specific post. It's your usual paean to old-school UNIX but it does not say what it really means to use "the command-line as a programming environment".

Post reply on HN