Live data from Hacker News

Helping my students overcome command-line bullshittery (2014)

pgbovine.net

161–168 of 168 posts

Re: Helping my students overcome command-line bullshittery (2014)

#161
post #158

Earlier quoted context omitted.

And who is that exactly? For long established, regularly used tools, there is a case for funding this activity somehow. For the many specialized tools? I'm not sure how this would actually happen, unless the person who creates it decides to maintain it. When their career focus doesn't value that tool, we can't really expect anything. Worse, let's say some established systems exist. They have a barrier to entry in tha…

i meant, if there is an organisation (the OP's example involves a university department, but this holds for other places too) where the majority of people simply want to use computers to get their work done, it is well worth having one person (or a team, as things scale up) whose job is to automate all the incidental details of working with the operating system and environment, so that people don't have to context sw…

Seems to me those people, or person would also have to be pretty great generalists.

A lot of research type tools get written and then left laying a out. Just testing and packaging, integrating, etc... would be a considerable project.

Could be the basis of some sort of course or career though. I'm thinking of the sysadmin types who manage software and research teams outside academia. The really good ones I know used to hold a position, or have some personal interest sufficient to make these sorts of activities make sense.

Re: Helping my students overcome command-line bullshittery (2014)

#162
post #158

Earlier quoted context omitted.

i meant, if there is an organisation (the OP's example involves a university department, but this holds for other places too) where the majority of people simply want to use computers to get their work done, it is well worth having one person (or a team, as things scale up) whose job is to automate all the incidental details of working with the operating system and environment, so that people don't have to context sw…

Seems to me those people, or person would also have to be pretty great generalists. A lot of research type tools get written and then left laying a out. Just testing and packaging, integrating, etc... would be a considerable project. Could be the basis of some sort of course or career though. I'm thinking of the sysadmin types who manage software and research teams outside academia. The really good ones I know used t…

check out this post about twitter's "engineering effectiveness" team: http://www.gigamonkeys.com/flowers/

in general, it's a great productivity booster across the board to have a team doing this; the main problem is getting buy-in from orgs, because the time and effort wasted when you don't have one are so pervasive as to be largely invisible.

Re: Helping my students overcome command-line bullshittery (2014)

#163
post #104
post #83

Earlier quoted context omitted.

Okay, a trivial and meaningless nitpick but a technically accurate one. Every general purpose computing machine that you can interact with and reprogram can be done by command line. Sometimes you have to plug another machine and use ITS command line to send communications to the original machine. I'll agree with you that microwaves do not have command line interfaces but calling them "computers" is quite a stretch.

No, it's not a meaningless nitpick! Yes, general purpose computers need to be programmed, but the reason we do it with a command line is because we prefer keyboards for data entry. When we stop using keyboards we will stop using command lines, just as we've stopped using punch cards. Everything that's not manually and physically setting voltages on memory is an abstraction. It's important to note that the command lin…

We prefer keyboards for data entry because keyboards are what enter the actual data we need to enter: we prefer typing text over the 'point and grunt' method of GUIs, where some interface takes our clicks and tries to intelligently convert them to command line instructions using context and guesswork.

Once we've deleted the written word from human existence and no longer have need of text, have transcended proper known computational structure and can express computations soley by thought and avoid programming altogether certainly we will move beyond the command line.

The command line remains the simplest, cleanest, most leak-free abstraction we have to interact with a computer effectively. I'll agree with you that it's possible there's a better one, but we've been trying for 40 years and haven't even come close -- all we've done is written some translations which let people enter command line instructions by pointing and clicking and having the machine guess how to interpret it instead of typing what they actually mean. I think it's the best we're ever going to get though I'm happy to leave room for optimism if you have any. In the meantime, those of us who have to get work done (I assume you are one of our cohort) will live in the real world and use it without complaint.

The only reason the command line is complicated is because computers are complicated. If you want to use computers in a deep way you can't hide behind the GUI and run away from actually dealing with the machine forever.

Re: Helping my students overcome command-line bullshittery (2014)

#164
post #163
post #104

Earlier quoted context omitted.

No, it's not a meaningless nitpick! Yes, general purpose computers need to be programmed, but the reason we do it with a command line is because we prefer keyboards for data entry. When we stop using keyboards we will stop using command lines, just as we've stopped using punch cards. Everything that's not manually and physically setting voltages on memory is an abstraction. It's important to note that the command lin…

We prefer keyboards for data entry because keyboards are what enter the actual data we need to enter: we prefer typing text over the 'point and grunt' method of GUIs, where some interface takes our clicks and tries to intelligently convert them to command line instructions using context and guesswork. Once we've deleted the written word from human existence and no longer have need of text, have transcended proper kno…

I am honestly almost speechless at that. The command line is complicated, because people are terrible at designing console apps and parsers. They end up with two or three ways of expressing anything, and give little or no clue (usage? really?) as to what they mean or how they differ.

Clean? I could agree with 'concise' but not clean. Some apps take multiple switches behind a single cue character (is it '/'? is it '-'? '--'? something else?) and some can only parse one at a time. Some take switches before text and filenames, some after, some have a mix.

Command line apps are the sort that only a mother could love. They are ugly, opaque, have an enormous learning curve, and even experts tend to type them into files because they would hate to have to craft them all over again each time they need them. Macros; cheat sheets; scripts are all crutches to escape the tyranny of command lines.

Re: Helping my students overcome command-line bullshittery (2014)

#165
post #163

Earlier quoted context omitted.

We prefer keyboards for data entry because keyboards are what enter the actual data we need to enter: we prefer typing text over the 'point and grunt' method of GUIs, where some interface takes our clicks and tries to intelligently convert them to command line instructions using context and guesswork. Once we've deleted the written word from human existence and no longer have need of text, have transcended proper kno…

I am honestly almost speechless at that. The command line is complicated, because people are terrible at designing console apps and parsers. They end up with two or three ways of expressing anything, and give little or no clue (usage? really?) as to what they mean or how they differ. Clean? I could agree with 'concise' but not clean. Some apps take multiple switches behind a single cue character (is it '/'? is it '-'…

Shrug I'd agree you can definitely find fault with many of the programs that currently exist on the command line though every single one is still miles and miles better than a GUI -- if you're going to do something one time, it's great to click a checkbox like 'show hidden files'. If you're going to do it regularly, it's worth looking up '-a'. If you want to do something unusual it takes a minute or so looking up the command's help. Whereas on the GUI if you want to do something unusual, the answer is generally "whelp, sorry, learn CLI peasant you just can't do it since I didn't anticipate your weird need and spend time rendering a menu choice and 4 interface screens with click boxes so you wouldn't have to type anything".

If GUIs had as many options as command line programs did they would be completely unusable trash, with an enormous unintelligible control panel, and you'd be looking iconography up in a reference manual instead of switches (have fun designing all those icons and having different ones express different subtle alterations in how a command will execute)

There are a lot of options because the tools are flexible and capable of expressing MUCH more than a GUI. I'll give you there are some consistency issues, but they are historical not fundamental to the CLI. I'm honestly surprised someone hasn't written a wrapper to standardize every app in a shell so they all use the same format (ie have a 'one true format' for argument passing and just convert as necessary for every CLI app, parsing their manpages as they are installed if necessary), it wouldn't be very difficult. It never occured to me (or anyone else likely) because it just isn't a problem. You try to use a program one time, it doesn't work the way you expect, you look it up, it takes 4 seconds, if you use it a couple more times then you just know.

Scripts don't run away from the command line, they embrace it . Scripts are the reason you use the command line; it's just text, so once you can do something once you can do it as many times as you want and share it with others instantly. Have you seen a macro to automate a GUI process? That moves the mouse around and clicks on stuff? And breaks constantly? Probably not, because nobody uses them.

Once you get into a command that's long enough to type into a file you've already written a program and sure if it's worth saving people will save it. The CLI blends using a machine and programming it and IMO that's a good thing -- it promotes literacy instead of encouraging people to point and grunt at shiny menu boxes and to refuse to learn how their machine actually works. If you're doing research and your main tool is a computer, it pays to learn how it works. It's not exciting but it's the same in every field. If you want to become an expert you need to understand your tools on a deep level.

Re: Helping my students overcome command-line bullshittery (2014)

#166
post #165

Earlier quoted context omitted.

I am honestly almost speechless at that. The command line is complicated, because people are terrible at designing console apps and parsers. They end up with two or three ways of expressing anything, and give little or no clue (usage? really?) as to what they mean or how they differ. Clean? I could agree with 'concise' but not clean. Some apps take multiple switches behind a single cue character (is it '/'? is it '-'…

Shrug I'd agree you can definitely find fault with many of the programs that currently exist on the command line though every single one is still miles and miles better than a GUI -- if you're going to do something one time, it's great to click a checkbox like 'show hidden files'. If you're going to do it regularly, it's worth looking up '-a'. If you want to do something unusual it takes a minute or so looking up the…

Sure GUIs can be bad (just like clis). But GUIs can be good, which is pretty much impossible with command lines. You have wizards that take you step by step; you have tabbed control panels with profiles you can save for next time (just like scripts) e.g. Beyond Compare. Everything can be labeled in front of you, reminding you what's possible and grouped sensibly. All impossible with command line tools.

Re: Helping my students overcome command-line bullshittery (2014)

#167
post #58
post #54

Earlier quoted context omitted.

I think that's a poor interview question. You're bound to only get people who have a disposable income to throw a server in their closet, and certainly a computer attached to their TV. Maybe it'd be a better interview question to have them work on a project for a week, which requires using the command line, rather than asking this somewhat limited question set. I don't mean to tear into you -- I see the value in what…

Well, yes ... it's a leading question where we go into the real issue at hand: Are you a "lifer" ? Would you do this work for free, like I would (and did, for years) ? Can you, like me, not imagine doing anything else with your time ? That's who I want to work with.

I love my work and couldn't imagine doing anything else, but 'love' doesn't pay the rent. Fuck anyone who expects me to give away my time.

Re: Helping my students overcome command-line bullshittery (2014)

#168
post #159

Earlier quoted context omitted.

Sure you can do that, but strcspn only found the newline, it didn't delete it. After all, you can also do foo[strlen(foo)-1] = 0; But I don't think anyone would say strlen modifies the string.

You just chopped the last non-NUL character off that string whether it was a newline or not.

ok, you got me there
Post reply on HN