Not, but it's the master's job to understand that all of his old, hallowed and arcane practices are not necessarily beneficial. Some are just busy-work or cargo-cult.
And that because a tool is "tried and true" for decades, it doesn't mean it can't be made better.
The command line might be handy for what it does, but from a UX perspective it's a mess. Tons of things that could be done to make it better, and bring it to 2016.
Take for example all common UNIX userland programs and change them so that they all respond to the same flags for the same functionality.
Here -- instantly better, and we're still in the CLI realm.
Or make them understand SIGINFO and turn on verbose mode etc midway.
Color-coded output (under a switch) from all tools, not just ls, grep etc.
A common configuration format for all of them. There's nothing something like TOML or JSON+comments couldn't handle, instead of each fucking tool having their own bizarro format and parser, resulting in the bloody mess that is /etc/conf.
Nor is "man" formatting the best we can do in 2016.
I'd even appreciate a "trash mode" for rm as default. Then you do something like "rm purge" and only then it actually kills everything put in between calls. Tons of user documents would have saved that way, instead of "just be careful because that's how we always did things". And of course some --doitnow flag could just delete stuff immediately.
Just a few things out of the top of my head. There are tons of other things...
Edit: of course those things would never happen, because they require central vision and roadmap, and the unix cli userland is just a set of disparate apps from teams who don't speak to each other.
At least FSF could impose some of that roadmap to GNU stuff, but they really don't care, they prefer to pass their time with
I think Apple's new playgrounds and the stuff they showed for kids at WWDC is the future, personally.
Want to teach two languages? Great! Install two entirely different IDEs, teach each one all over again and their differences, or spend hours debugging weird compiler plugin errors every single one of your students will have.
Or in 3 seconds tell them to type 'python' instead of 'gcc' once they already understand what programming actually is.
In general I always think it's important to understand what's actually going on before you use fancy tools that automate it for you. Because when your fancy tools break because of some tiny misconfiguration or change you didn't notice, and they will, throwing your hands up and saying "welp, I guess I'm helpless" isn't good enough and you'll never be half decent, or have any kind of real confidence in your ability until you have at least some knowledge of what's going on under the hood. If someone wants to be a programmer, we are teaching them to be car mechanics, not car drivers. So why not start with the real stuff?
And if someone can't get over their fear of communicating with the computer using words and symbols (i.e. text) instead of point-and-click then they aren't ever going to be a programmer -- better to know and pass that hurdle early rather than later.
People having been coding years on end on modern IDEs like IntelliJ and Eclipse and VS without them "failing" for basic stuff.
And it's not like setting up e.g. Vim or whatever with just some of the niceties an IDE has not challenging.
>Consider teaching a CS class. Everyone has a different machine, of a different age, with a different operating system. Getting all of them on some posix type CLI where you can type 'make' or 'python' is fairly easy and once it's working, foolproof.
You'd be surprised. Try getting them to run Python on Windows and discover all the subtle changes, libs that only play on Linux etc, use the same Unix userland with slight OS X/Linux changes, run that terminal stuff on Windows etc.
Besides, tons of programming teaches classes, seminars, etc use or recommend an IDE.
Ah wait, the integrated debugger has crashed again, so I cannot figure things out. Hey, the thing cannot even open a text data file, because it is not part of the project, whatever that means.
Etc. Most "industrial" IDEs male quote a few simple things way unnecessarily complex.
1. https://github.com/ontouchstart/swift3-playground/blob/39331...
2. https://github.com/thinkswift/TS/blob/296775627b19c4d98eb7fd...
My point is that there is a difference between mastering the toolchains and understanding the deep concepts.
I totally agree that we have to start from somewhere concrete, quote Seymour Papart: "you cannot think about thinking without thinking about thinking about something". However, we should also "focus on the big picture and zero in on the powerful ideas ..."
- http://news.mit.edu/2016/seymour-papert-pioneer-of-construct...
You don't start learning woodworking with pantarouter or a lathe.
Command line (compiler or interpreter) is something that works everywhere and always, and understanding how the environment works prevents the student from thinking magically through clicking buttons in IDE.
> it's absolutely absurd to say, "Well before you can start learning to program, you have to learn these several other domain specific languages and you have to type them, and it has to look awful."
Why do you think `gcc myprogram.c' + `./a.out' or `gcc -o myprogram myprogram.c' + `./myprogram' is "several other domain specific languages"? Because, you know, it's all that is really necessary to start learning C. I don't see learning even a small part of a DSL (shell, I presume) here.
Clicking a button in the IDE is not any different than writing: "foo -x".
They both end up as code being executed. And no, it's not always the case that an IDE's button click ends up in some cli command being executed in the background. There are such things as programmatic APIs to compilers, linters and such.
So nothing more fundamental or magical about the CLI -- it's just another, text vs graphics, based representation.
>Because, you know, it's all that is really necessary to start learning C. I don't see learning even a small part of a DSL (shell, I presume) here.
And where you'd run that command? Wont you "cd" there? Maybe create some directories? Maybe delete some files you don't need? That's shell for you.
And what about build scripts, including libs, etc? An IDE can create those for you automatically, with the plain cli you need to learn to write e.g. a makefile.
And tons of other things besides. You want a debugger? gdb and then learn the flags to attach it, several commands to step around and inspect things, etc.
Oh, far from it. You said yourself later down the thread that IDE needs to anticipate an interaction beside the mouse-click (by exposing some programming interface). It needs work to have that, and that is far from being trivial mechanics. `foo -x' only needs to have this `-x' provided somehow, and it doesn't care where it came from and how it was derived.
Command line does much, much simpler job of exposing underlying concepts of an operating system. The two hard parts about the command line are learning those concepts and learning that most of the time, most of the options are optional and can be omitted. For GUI, many of the OS concepts are hidden, intentionally or incidentally, but they are still going to bite if one doesn't know them.
> And where you'd run that command? Wont you "cd" there?
This is part of the operating system's concepts a student needs to learn anyway. A working directory is still a necessary thing, except with GUI you have no fsckin' idea where your program is executed, so good luck opening any file (unless you use absolute path, of course).
> Maybe create some directories? Maybe delete some files you don't need? That's shell for you.
Oh, so you have just vanished file managers so many people use? Those suddenly stopped working for somebody who happened to started learning programming? Why do you think a student needs to manage his files with shell once he starts writing programs, instead of doing things as he always did, in GUI?
It can be really trivial through, which is the point. Defining OSA dictionaries, for example, was never something that took major effort. The fact that people don't care about those enough to make it a standard feature in GUI frameworks is a cultural thing, not a technological limitation inherent in the API.
That said, sure, CLI programs give scriptability for free.
But that stops when you need long-running session scriptability -- there you essentially have to pass messages to an already running cli program, and that's done the same way as you would have handled passing messages to a GUI program.
That's true whether you do it with a "telnet to the program" like interface, a "client" interactive style like e.g. psql, or even low level POSIX signals (which require a handler out of the program flow).
>This is part of the operating system's concepts a student needs to learn anyway.
No, it's not.
First, not all people studying a programming language are or care to be CS majors. A student could just use the GUI file manager for an eternity...
But as long as you drop them to cli for compiling etc, they also need to learn shell and other such stuff. An IDE would have handled all that for them.
> It can be really trivial through, which is the point.
No, it will not be trivial. It can be easy to use, but not trivial. Whenever you hit GUI, all the mechanics (i.e. internals) suddenly becomes complex. What the heck are "OSA dictionaries", what data is inside them, what remembers them and how does changing them from outside of the original process work?
> That said, sure, CLI programs give scriptability for free.
> But that stops when you need long-running session scriptability [...]
Command line tools rarely are long-running things you need to interact with.
>> This is part of the operating system's concepts a student needs to learn anyway.
> No, it's not.
How so? Suddenly one doesn't need to understand what the current working directory is? How to work with files then? Of course it is necessary to know those concepts. It's just that GUI hides a lot of them, so dropping to more basic tools hurts so much because of all complexity that was hidden springs suddenly.
> But as long as you drop them to cli for compiling etc, they also need to learn shell and other such stuff. An IDE would have handled all that for them.
But then they need to learn much about their IDE, which is as large area as basic proficiency with command line, except that knowledge can't be easily composed with anything other, and once they leave the IDE, the knowledge becomes next to useless.
The only thing that could be seen as benefit is when the student learns what icon to click when, without understanding what is done behind the scenes, but then you easily can have the same effect in command line.
It seems that you insist that it can't be trivial, but you're not familiar with OSA and how e.g. Cocoa handles scriptable GUI apps.
OSA is Apple's scripting architecture for Cocoa, and with "dictionaries" (e.g. XML definition files) you can expose to a scriptability layer (accessible from AppleScript, Javascript, Python and all kinds of apps) any class or element in your app, quite simply. You don't have to change the internals of your Classes even.
This is not available in all GUI frameworks, but what I'm getting at is that this is not some inherent limitation of writing GUI apps, it's a limitation of current frameworks and the lack of thought it was given to this.
> But that stops when you need long-running session scriptability [...]
> Command line tools rarely are long-running things you need to interact with.
All kinds of deamons and servers are command line too, not just things like ls and grep. And these you want to interact with over their long-running lives. Same goes for tools with heavy initial startup time (e.g. a statistics tool that needs to load some data set, etc).
It's due to a lack of foresight/coordination (and "worse is better" mentality) that we don't have a unified scripting method for short term cli-tools, long-running cli apps, and GUI apps (and if we had ones, it could easily be extended to Cloud apps for the ultimate in automating and pipelining!).
>How so? Suddenly one doesn't need to understand what the current working directory is? How to work with files then? Of course it is necessary to know those concepts.
You can know those concepts at the GUI level (including abstractly). No need to know "cp", "rm", "ls -la" and other such text-based interactions with them. In fact there are computers that don't have these at all (most smartphones, the iPad, etc), and tons of Windows and OS X users never care for them anyway.
>But then they need to learn much about their IDE, which is as large area as basic proficiency with command line
Yes, but that knowledge is specific to their task (which is to learn programming).
"cp" and "ls -lah" and "rm" are not -- they already know another way to perform those tasks.
> [...]with "dictionaries" (e.g. XML definition files) you can expose to a scriptability layer (accessible from AppleScript, Javascript, Python and all kinds of apps) any class or element in your app, quite simply.
There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point.
Trivial would be if all it was to this scripting was "just this simple thing", like executing a program exactly the same way as always, but with provided command line parameters this time. Now you say "Python", so it must be first implemented by the author of GUI program, then exposed in "e.g. XML definition files", and then something (Cocoa, as you say) must transport some messages/calls from user's code to scripted program's code (how? through some kernel way? user-space bus? something different?). How this is trivial mechanics?
>> Command line tools rarely are long-running things you need to interact with.
> All kinds of deamons and servers are command line too, not just things like ls and grep. And these you want to interact with over their long-running lives.
But daemons are not command line tools. Command line is just a way to start them under unices. Under Windows it's a totally separate type of programs ("Windows services"). Even aside from that, daemons are not normally called for one-off tasks, but to provide services. This means you already need a communication channel for such a daemon.
> Same goes for tools with heavy initial startup time (e.g. a statistics tool that needs to load some data set, etc).
And what do you need/want to script in this statistics tool that loads plenty of data while it loads this data at its startup?
> You can know those concepts at the GUI level (including abstractly).
Current working directory? ROTFL. The whole point of GUI is to hide this concept, and you tell me one can learn it from GUI?
> In fact there are computers that don't have these at all (most smartphones, the iPad, etc),
Sorry to break your little utopia apart, but "most smartphones" run Linux or generally work with hierarchic filesystems, which is totally opposite of "no current working directory".
>> But then they need to learn much about their IDE, which is as large area as basic proficiency with command line
> Yes, but that knowledge is specific to their task (which is to learn programming).
It's not specific to programming, it's specific to their tool for learning programming.
> "cp" and "ls -lah" and "rm" are not -- they already know another way to perform those tasks.
And that's why I don't insist to use them or even learn them. What I insist is to learn how the compiler is called, what to feed it with (text/plain, with any editor, not just heavyweight IDE), and how to execute freshly produced binary.
Well, if by trivial you mean "totally effortless and thoughtless" then not. But I don't think that's the correct mental mode to create CLI interfaces either.
>But daemons are not command line tools. Command line is just a way to start them under unices. Under Windows it's a totally separate type of programs ("Windows services").
Command line is any headless program. And you can start Windows servers from the command line too.
>Even aside from that, daemons are not normally called for one-off tasks, but to provide services. This means you already need a communication channel for such a daemon.
That's narrow thinking.
First, e.g. "grep" also provides a service of returning matching results. Whether it does it once-of or as a deamon (one could easily imagine a grep deamon, not unlike Solr or Spotlight) is irrelevant with respect to its scriptability.
It's only because we don't plan for it, that we have this artificial restrictions -- "that's a deamon, you can't script it like that".
Besides, regarding "This means you already need a communication channel for such a daemon.", that's a different channel than the scriptable one, because the latter would include stats, configuration etc.
A web server has a channel to do "GET / HTTP/1.0", but that's not the same as a chanel allowing you to e.g. "print current connected IPs", "reload X configuration file", etc.
>Current working directory? ROTFL. The whole point of GUI is to hide this concept, and you tell me one can learn it from GUI?
No, the whole point of the GUI is to give a graphic representation of those concepts, not to hide them. It hides absolutely nothing (except things that don't make sense in a GUI, like the CLI hides stuff that don't make sense in a terminal, eg. the graphical representation of an jpg file, which a GUI can immediately show in its listing).
In fact one can trivially create a restricted "ls" style program that shows (on the cli) far less info than what the Finder or Windows Explorer does.
You seem to conflate the CLI with the "canonical representation" of what actually happens in the OS/FS etc. But it's just a textual representation of it, nothing more.
What actually happens is a series of process starts, method calls, and system calls.
Whether you say it by printing stuff out (like early computers), in a cli (like UNIX systems), in a GUI, or even in VR or "PC-to-brain interface" in the future, it's the same underlying thing.
>Sorry to break your little utopia apart, but "most smartphones" run Linux or generally work with hierarchic filesystems, which is totally opposite of "no current working directory".
That's totally irrelevant to what I wrote.
My point is about those platforms not having a CLI as a user accessible object -- but only providing a GUI representation -- and users getting by just fine with that. Including the vast majority of OS X and Windows users who don't venture into the terminal at all.
>And that's why I don't insist to use them or even learn them. What I insist is to learn how the compiler is called
Again, you conflate the cli interface to the compiler to some canonical way about how "the compiler is called".
The compiler is called in many ways.
The cli is one, it's programmatic interface is another.
In fact both the gui window "run compiler with X, Y, Z options" and the cli command command "gcc -X -Y -Z" in the end just end at the same function, that starts the actual process.
You can't automate clicking buttons nearly as easy as you can munging text streams.
Many GUI apps have some embedded scripting capability (for extensions, batch processing, etc).
The same could be generalized to use and combine not just one through it's special language, but all of them from outside.
That's e.g. what Apple's OSA dictionaries do enabling you to script GUI apps (if its developers bothered to expose its commands as programmatic APIs).
And if Windows and OSX and Linux devs talked between them, the same commands could work in all platforms for the same app.
You could also use something like a visual pipeline (as in Automator) to combine functions and move results between arbitrary apps (think "GUI pipes"), do the whole scripting from the CLI in some scripting language, send messages to the app (a la Rest), etc.
This is also true for web apps of course -- they're GUI based (e.g. Gmail, Mailchip) but lots have programmatic interfaces, via REST and co.
Of course it is inherent. You need to actively fight it if you want it gone (i.e., if you want GUI scriptability). For shell, you automatically have the scripting capability.
That will break a large chunk of scripts that use rm. Say someone with sufficient clout implemented this, dumped the information into some release notes, even made it widely known via various internet forums.
Inevitably, what will happen is that we get a split: some who do not want to use the "improved" tool as they have other more pressing concerns, and others who view it as progress.
If anything, there is already a ton of fragmentation even in such basic utilities found in coreutils (BSD vs GNU differences, not immediately available on Windows, etc).
And the funny thing is that even if unity is practically achieved for some time, someone will want to scratch a new itch, repeating the cycle.
Sure, that's why I talk about compatibility etc lower.
As I wrote, the best way imho would be to create new versions of the old utils, with changed prefixes/names, and have people slowly migrate to them.
It's not impossible, people can and do adopt new cli utils.
The old ones could still be there for the compability layer (for old scripts etc), but new stuff could be written in the new ones.
And while we're at it, a new shell too. Even zsh is 1990's technology for 1990's needs.
>And the funny thing is that even if unity is practically achieved for some time, someone will want to scratch a new itch, repeating the cycle.
That's how you get better stuff though, with cycles.
Not with religious adherence to backwards combatibility.
The problem is most of those cli userland tools only had one major cycle, when the old UNIX/BSD userland got remade as GNU, and added new switches, options etc.
Contrast with how better OS X is compared to Mac OS circa 1988 or Windows 10 compared to Windows 3.1.
This is an assumption that is not necessarily true. In the short term, there are plenty of examples of places where it is not true. As for this being true "asymptotically", that is a hard to verify assumption.
What is true is that cycles result in something new. New does not necessarily mean better.
The examples you give below are examples where the cycles have worked; there are examples where it has not.
Any example?
Because cycles (and I could have said "iteration") is what got us from bone tools to spaceships...
>The examples you give below are examples where the cycles have worked; there are examples where it has not.
That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results.
E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.
Really depends on what means by better and what one values. Still, here are some relatively unambiguous ones: global warming/climate change, the fragile nature of the current equilibrium wrt nuclear weapons. Maybe long term we will solve them, but in the short term we are worse off.
> That doesn't mean much. Even if a process (e.g. iteration) doesn't always achieve the desire result, it can still be the only way to achieve those results.
> E.g. asking a person out. It might not always work, but it's still the only way to go on a date with them.
There are costs associated with each iteration, and in the context of dating, there is a threshold to the number of rejections. Obviously, at some level any work is an iteration on the existing body of work, in which case your point also does not mean much.
My point is that in certain cases it can be best to leave things as they are.
"Fixing" rm is one such thing for me: there are trivial workarounds via aliases (can be shipped by a distribution) for those who really care. I am sure your thoughts are not unique on this: people must have tried "fixing" rm in the past, and judged it not worth it.
One is completely free to work on "improving" something. However, there should be no expectations that others find it an improvement.
> A common configuration format for all of them
cut/sed are usually used for the program's output, not their configuration files.
And if there was that common configuration format, you wouldn't need cut/sed or any such crude tool for the configuration files either, you could have a universal conf-edit tool, that could read the raw config files and output the configuration in whatever formal (XML, JSON etc) and convert it back in, search for specific entries, set specific settings, etc.
>Others yet require rich object configuration specifications, in which case JSON/TOML/YAML makes sense. I don't think there can be one configuration file to rule them all.
Even so, there can be one configuration language for an awful lot of programs, that don't have those special needs, and there isn't one. Instead it's a mishmash of every kind of custom parser.
But modern FOSS corporations are mostly hands off -- they don't care for such things, they sell support and enterprise services (e.g. RedHat), and others (e.g. Canonical) do some stuff, but lack resources/motivation to dig deeper, and even when they do stuff, they alienate "hardcode" macho types who protest "this is not the way we've always done this".
It's sad, because there are great ideas for tons of things to improve on a "UNIX v2" and "POSIX NG", now that we know what 21st century computing environment and modern needs are (in 1980 when those tools where designed internet was rare and slow, mobile wasn't a thing, the terminal didn't have colors, utf-8 didn't exist, and tons more stuff besides).
E.g. adopting something like Nix for package managing.
Or this, which is a patently sanier file system structure for multi GB disks and modern needs:
1. Make computer do what we want.
2. Automate the tasks we want to achieve.
3. Understand our computing and communication environment.
4. Change our computing and commuincation environment.
5. Create new computing and communication environment.
Our hardware and bandwidth are orders of magnitude more powerful than 70s, but the fundamental verbal and visual ways humans learn and think are almost the same. It is time to move up the ladder, use computer to augment our collective intellect instead of being pure "consumer" of technology or just "tool masters".
> By "augmenting human intellect" we mean increasing the capability of a man to approach a complex problem situation, to gain comprehension to suit his particular needs, and to derive solutions to problems. Increased capability in this respect is taken to mean a mixture of the following: more-rapid comprehension, better comprehension, the possibility of gaining a useful degree of comprehension in a situation that previously was too complex, speedier solutions, better solutions, and the possibility of finding solutions to problems that before seemed insoluble. And by "complex situations" we include the professional problems of diplomats, executives, social scientists, life scientists, physical scientists, attorneys, designers--whether the problem situation exists for twenty minutes or twenty years. We do not speak of isolated clever tricks that help in particular situations. We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles, and the human "feel for a situation" usefully co-exist with powerful concepts, streamlined terminology and notation, sophisticated methods, and high-powered electronic aids.
A "master" may not be able to or want to be a teacher. I would urge such persons to refrain from appearing to teach, and to try and become teachers first.
Apprentice is baffled by what appears to be difficult and says, "I was wrong about wanting to do this, if this is what it is. I'm going to Ikea, who's with me?"
Is it the master's job to persuade the apprentices to stay?
This "wait, come back!" reflex is understandable. But even if we could make "conversing" with the computer look easy, it would still be difficult (since, as Alan Turing himself pointed out, anything routine should be automated). Would you feel differently if students were bolting (or merely appalled) when they hit those inevitable, real challenges?
I completely agree with the OP that interaction has not fundamentally advanced since the 1960's (edit, well, I'd say 70's, but still). As others have pointed out, the examples could have been better, but it doesn't change the point.
Improving interactivity is our problem, especially since we spend the most time with computers. And it's (still) one of the most interesting problems in computing. I would tell students that if you're not satisfied with the state of the art, you're not alone. And if you are satisfied with Ikea, then why are you here?
edit moved side comment to a different post.