Apprentice comes into the workshop and the master carpenter performs mysterious steps to make things.

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.

>Is it the master's job to persuade the apprentices to stay?

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

Not to mention, when learning programming there's absolutely no reason to introduce the command line. Set them up with an IDE and GUI for source control. You can still use llvm or gcc and git or svn behind the scenes, but 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."

I think Apple's new playgrounds and the stuff they showed for kids at WWDC is the future, personally.

Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process. 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.

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.

>Except that IDEs and GUIs are buggy. They are finicky and they fail often and usually their failure can only be debugged by someone who understands what is actually going on, i.e. the command line and build process.

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.

Ha, don't even get me stated on infallibility of modern IDEs. Forgot to index? 90% functionality is off or broken. Want more than one project open? Better have 10 GB memory on the ready. Oh, did someone customizer their key bindings? Or window manager, and the binding now collides?

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.

Playground is just another form of REPL. For example, here are two forms of of the same exercise, the firt one running on iPad, the second in Docker/Linux:

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

> when learning programming there's absolutely no reason to introduce the command line

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.

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

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.

> Clicking a button in the IDE is not any different than writing: "foo -x".

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?

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

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.

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

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

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

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.

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

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

>There you go. The mechanics of how this works is non-trivial. I would say it seems quite complex at this point.

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.

>Clicking a button in the IDE is not any different than writing: "foo -x".

You can't automate clicking buttons nearly as easy as you can munging text streams.

That's just an accident of neglect though, not something inherent in GUIs.

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.

> That's just an accident of neglect though, not something inherent in GUIs.

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.

Yeah, it's not a lowest common denominator scriptability option that's offered as default as is the case with CLI commands and flags -- it takes actual effort and thinking.

And there you have the reason why so little programs with GUI allow for scripting.

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

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.

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

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.

> That's how you get better stuff though, with cycles.

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.

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

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.

> Any example?

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

Easier said than done. Some applications don't require the complexity of JSON/TOML, and it's best for them to use a simple and regular language to make tools like cut/sed easier to use. Others naturally lend themselves to scripted configurations, in which case a full-fledged scripting language makes sense. 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.

>Easier said than done. Some applications don't require the complexity of JSON/TOML, and it's best for them to use a simple and regular language to make tools like cut/sed easier to use.

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.

These are some excellent ideas, but I wonder, what would it take to get you to ditch Linux/BSD/Illumos for the new, modern *nix? How would you get corporate support?

Well, the best way would be for a corporation to create that. It would have the focus and the resources. Somebody like Apple, or Google, or MS etc.

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:

http://www.gobolinux.org/?page=at_a_glance

In HCI, there are several proficiency levels based on our 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.

http://www.dougengelbart.org/pubs/augment-3906.html

It's a teacher's job to motivate students and find ways to effectively communicate to them their knowledge.

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.

The problem I see is that it is very difficult to improve user tools when the users (such as myself) are stuck using the wrong abstractions. I'm a corporate lawyer, and the #1 and 2 tools of my trade are Word, followed by Acrobat. Typical process for negotiating a contract is to save new versions in .docx and run "legal compare" in some tool such as DeltaView or Workshare to show change dif between versions. This snapshot dif is then emailed to the people who need to see it. This is a relatively powerful abstraction for a limited field, but is hard to adapt. There is no feedback mechanism between users and developers of these tools. So they basically do not improve, and actually the experience of using them has only gotten worse with time for everyone involved. So the immediate benefit to switching philosophies is zero, though the long-term benefit is huge. But how do you overcome this initial starting friction?

Actually, going on my other post, this isn't as limited a use-case as you might think.

Anyone doing contracts, requirements documents, writing/editing cycles could use something like this with varying additional capabilities.

With no change to philosophy (still staying on the user side), a system could be made based off the principles of existing software.

You need some workflow management software + a document store. The document store needs to provide rich text editing, and the ability to edit only specific sections in parallel. "section" is a customizable unit depending on the type of contract. Could be paragraphs, or larger logical units. Part of the workflow management is kicking the contract back and forth between you and your collaborators and the other stakeholders. At various stages it's editable by different people, some stages are just for review (not edit), finally various sign-off stages.

It's pretty typical of requirements document databases. You'd need it exposable to third parties outside your company, and you'd also need confidence in privacy and security. Neither are trivial, but neither are impossible.

The software for your needs literally exists, but isn't marketed to you. It's too costly for smaller offices (both licensing costs and management costs), and would require a good sales pitch because, well, people don't like change.

No one has yet managed to build the workflow management that is needed for this. The best efforts I have seen to date are Docracy and Contractual.ly. But neither quite got it right. It is an interesting problem, and seemingly straight-forward to solve, yet it is a graveyard of failed attempts so far...

Is the workflow uniquely complex? It was never my job but I've seen (trying to remember what we used) some pretty complex workflows for handling requirements documentation, testing, and code development (reviews and such, specific tasks handled in JIRA) handled pretty effectively. Would've been one of the Telelogic (now Rational) tools.

I doubt the workflow could be any more complex than what you have seen. In many ways, it should be less so. There are some nuances, however. Partly the problem is the extreme egos involved in many business negotiations. Every communication sent has to help the sender to look good. There has to be a bias against publicizing changes before the author is done. There also has to be flexibility to override approvals. A lot of big deals would never close if someone had to take personal responsibility for waiving closing conditions that aren't satisfied at closing.

Regarding hiding changes until they're done, that shouldn't be in feasible except that you (or your counterpart) may not want to use a system owned by the other, because you lose that guarantee. A third party hosting it could offer that (naturally), but takes on extra liabilities with securing the documents in progress.

You should try putting the text into git, has all those tools built in... plus a lot more, and no emailing.

I have family who are lawyers.

They and a great many of their colleagues can barely type without looking at the keyboard. You're suggesting that the kind of person who still double-clicks on hyperlinks can learn git?

I'm an aerospace engineer and I can barely use git. Git's UI/UX is a fucking disaster that just happens to suck less than what came before it.

Git is not great UX wise, but it's probably not as big of an issue as people like to make out, especially if you are already comfortable in a shell. The reason people find git hard is that concepts of distributed version control are hard.

There are plenty of nice git native GUI's and web apps, and mercurial offers a more consistent command line UX, but that doesn't change the fact that people need to understand a crap load of higher-level concepts before they can find their DVCS useful. Such as:

file-system folder structures

diffs/patches

commits/uncommited changes

branching

merging and conflict resolution.

remote vs local repositories

To me it's like how people complain about mathematical notation being complicated and inconsistent, but that's just the first superficial "alien" looking stuff that tells you that you don't understand the new concept. Once you understand the underlying concepts, the notation doesn't get much further thought.

>The reason people find git hard is that concepts of distributed version control are hard.

Maybe. For me it was because the documentation is written like a comp sci whitepaper. I've ranted about this elsewhere on HN but the man pages are filled with stuff like "update remote refs" as if a person would have a fucking clue what a ref is and why you'd want to update a remote one.

Branching, merging, tagging, all of that sounds great. I've been using git for years, but the problem is that I don't use it every day, and so I still get a little wary when I want to run a merge. I can't tell you right now off the top of my head how to merge if there is a conflict. I always have to google around for "how to undo a commit". Etc. etc. etc.

Where the fuck do my files go when I switch to a different branch? Do they actually change in the working directory? Checkout vs fetch? Where exactly in the file system is this alleged "staging area"? I have no idea about any of these, mostly because the documentation is just so poorly written that it takes me too long to find out the answers and I have more important things to do than Greco-Roman wrestling matches with my software tooling, but I'm afraid that if I just try things at random I'll do something I can't undo because none of the options seem particularly intuitive.

It's just not a very good piece of software.

Software is good , your mental model of it is bad. Trying to put the squre peg of git into the round hole of filesystem is bound to produce frustration.

> The reason people find git hard is that concepts of distributed version control are hard.

Have you ever used Mercurial?

I think you would want to combine an open source toolset with a paid service with trained monkeys to bridge the gap. For instance let's say I send a draft out, and receive a PDF markup back. The trained monkey would make sure that the new version is accurately reflected in the repo. As long as I am working natively, then exporting my response back into whatever lame format is desired will be trivial. It's a bridge to a better world and more elegant system.

The engineer in me hates how inefficient that is. Also it smacks of a make-work project... paying someone to manually insert markup seems like a huge waste of money.

Surely it'd be cheaper in the long run to just spend the money on some UX designers?

I think you need a human to manage the import bc any OCR or conversion error could kill the whole experience. Hopefully rhe machines could get us 90 percent of the way there. You know law firms used to employ armies of typists to prepare manual (pencil) difs of paper docs, so there is a certain cultural willingness to pay for perfect results, particularly on larger transactions.

Which gets to the post (so I assume this is meant ironically/sarcastically?), steep learning curve of numerous tools.

What lawyers (specialists in their field) and others negotiating contracts could use is a subset of git, with better UI.

They need version control of the document.

They need to know who can edit it at this stage, or who needs to sign off (workflow management).

They need to know who did edit it.

Systems like this exist that are better than git, some people in the software industry use requirements tracking databases. These are almost literally what's needed once you (often included in them) add on the workflow management: collaborative document editing, ability to view diffs, knowledge of who edited it, restrictions on who may edit it and when, etc.

But if it's too small a field, or too disconnected from those of us who can make it, then software like this won't be made or widely used and they'll continue using the functional (but error-prone) method of copy/rename and email.

It started off a smug joke, but in all seriousness... git/github is the PERFECT tool to store legal documents. Pull requests have clear documented changes. Documents can be forked, different lawyers could work on the same document, and merge changesets whatever. Everything programmers do to source code, lawyers do to law documents.

I agree. But it still has the problem of:

They need to learn a new document markup (how well does word play with git for grabbing diffs?).

They need to learn git/github.

It needs to be secure (these are legal contracts, potentially containing detailed information that doesn't need to be out when it's in draft and not signed). This is fine, host your own git repos, but that's an additional technical cost to the company.

It is, ultimately, still an ad hoc process. Is the cost of learning and adapting to this, to only gain the version controlled document store, sufficient to justify the process? Across an industry?

It probably wouldn't diff terribly but the markup used in .docx is extremely verbose and not really designed to be human writable the way say markdown is. Most users don't see formatting as markup, because as far as they can tell it's WYSIWYG and stored that way. The idea that content and style can even be separate is very foreign for lots of folks, let alone that the representation on disk is text without style.

Ideally the markup would be limited to section numbering (need more levels of nesting than md or html offers) and definitions. Then once a contract is finalized you could apply fancy styles before printing a closing set.

You get together with a few others, and figure out what's wrong with the current tools, and how they could be better. Then you figure out if people would spend money for better tools. If so, you've got a niche startup.

I have some strong ideas about what's wrong w current tools. I would love to work on this as a side project but I think it needs to stay non-proprietary if it's going to be any different from current, reasonably usable enterprise tools.

These are not the most compelling tools to begin with. I know how to use Git and markdown, but I still use Google Docs for most things.

The key differentiating feature of programming is interactivity, and the most interactive programs are games, which is why they're so great for teaching. You can't make a game with Spotlight search.

I always tell people to start with HTML because it gives instant visual feedback, all you need is notepad, and it gets you used to typing words in a text file. Pretty soon they want interactivity, and suddenly they're learning Javascript.

The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people programming by bombarding them with 50 new tools (git, LaTEX, shells, piping, etc). Yes, those are extremely useful tools for engineers and serious programmers. However, they really aren't necessary or core to programming so much as they are core to engineering, sysadmin-ing, typesetting, etc. To be honest, using LaTEX for your resume is just a bad decision unless you happen to be very good at it and very incompetent with Word. Not only was the author teaching them irrelevant tools, he was stretching them to bizarre use-cases that conflict with how any productive human would approach an everyday task.

The essence of programming that needs to be taught is how to think about problems. Those are harder to grasp, but really they are just different ways of thinking. Programmatic thinking is clearly applicable to many things and enriches your life beyond just programming. Throwing tools at people is only important after you've learned how to reason about problems and begin tackling them.

Like 1t1337 said, HTML is a good place to start for the basic concept of writing plaintext to control the computer. Beyond that, Python is great for teaching programming as it has an easy, intuitive (relative) syntax and supports many concepts without being too demanding re: types.

Don't forget that people new to programming are really new to programming. Just the concepts of int, double, and string can be daunting because people just don't think that way.

The biggest challenge I've seen in teaching/coaching new programmers is the concept of assignment vs. equality and how that interacts with variables. Even very smart (young) math majors can get very caught up on the following:

number = 5

number = 6

In math (as everyday people understand it), that would clearly be incorrect. I suspect for math-oriented students, functional languages would be a better place to start. I personally learned about programming variables before algebra variables, so my experience was the opposite.

I truly believe an excellent introduction to programming course really doesn't even require a computer to be involved, although of course when used correctly computers and live demos add a lot of value. Rather, an excellent course will teach the concepts (variable, typing, what memory is, functions, recursion, iteration, and turning real-world problems into computable problems, and so on) which are completely tool agnostic.

Yes, the use of bare "=" for assignment is one of the Great Mistakes of Computing, right up there with null references and zero-terminated strings. There have certainly been languages that have used other operators for assignment, such as ":=" or my own favorite, "<-", but somehow they have never caught on. "=" was good enough for Fortran in 1956, by god -- it's still good enough 60 years later!

>...my own favorite, "<-", but somehow they have never caught on.

No doubt because "<-" is two characters and requires the shift key, whereas "=" is only one, unshifted character.

One more concept that I've seen people struggle with is the idea that programs/code don't convey meaning to computers - just behaviors.

For example, new students struggle with the idea that variable names can be changed at will. There's nothing special about a variable named 'personName' - it could be a street address, a function reference, or anything else and the computer just doesn't care.

The idea that there is no such thing as intent in the world of computing can be difficult to grasp. This is closely related with the concept that programs are just data. There are ways to teach this though - I personally love the examples of the programming languages where a bitmap is read, or where only whitespace characters are allowed. It can break students' conception that variable names have any meaning to the computer.

> The problem here isn't that there's two perspectives (in fact, there are many more than 'two cultures of programming'), it is that you tried to teach people programming by bombarding them with 50 new tools (git, LaTEX, shells, piping, etc). Yes, those are extremely useful tools for engineers and serious programmers. However, they really aren't necessary or core to programming so much as they are core to engineering, sysadmin-ing, typesetting, etc.

Yes and no. I agree that complex tooling should be kept to a minimum. I recently help run a small intro to programming bootcamp for my bio / bio E lab with another developer and we had great success using python on JupyterHub as our teaching tool. We were also able to introduce git via the GUI in our final session and people picked up the basics pretty quickly. Keeping things as simple as possible definitely helps with learning.

With that being said, we still had a lot of people questioning why you would want to use python over excel for data analysis, people asking why you would use git over dropbox, and just general confusion over why best practices matter.

I think part of the problem is that it's hard to motivate people to do more work than they have to until they suffer and then see the light: using python is more time consuming than using excel; using git is harder than using dropbox; employing best practices is harder than not employing best practices in the short term. For example, I didn't understand why source control mattered until I started collaborating on projects and got lost when changes were applied. I didn't understand why unit testing mattered until I started writing larger programs and getting owned by bugs etc.

It is not the programmer culture, rather the UNIX programmer culture.

The Mac OS programmer culture before Mac OS X was a thing and Windows programmer cultures, including the Xerox PARC ,Lisp Machines and ETHZ ones, have more to do with user culture than what the author is writing about.

I really dislike this hipster idea that the only programmer culture is the UNIX one.

I'm not sure anyone would be impressed by Python via command line and nano/pico, beginner or otherwise. An interactive notebook with graphics/animations would be the best introduction. Something like this: http://haskellformac.com

I agree. I would suggest making simple demos on IPython notebooks.

It seems like maybe you'd be better off teaching these users VBA or something.

The purpose of programming is to do things at scale, to automate them. Writing a one-off Python script to search for the string "widget" is insane when Spotlight exists. But a script that performs searches is useful when you need to search for a thousand strings. Using the Imagemagick CLI to resize a single image is ridiculously cumbersome when Photoshop exists, but vastly more useful when you need to resize a folder with 50,000 jpegs in it.

The reason newbies question the usefulness of trivial examples is because they're trivial problems. Programmer tools are only useful for big problems.

If programming were easier, why would coders make six figs? Doctors and lawyers have regulatory bodies that protect them. We just make make our jobs too frustrating for non-nerds.

I don't see any example of the two cultures here. Just an unprepared teacher who chooses bad examples to teach from.

The counter-arguments by hypothetical students actually make good points, and I feel are the best ways to solve that certain problem. They know to use the best tools available for their task. The problem is all their tasks are really simple, and the "developer tools" would be a slower solution, or at least not faster.

Why do you need to search for all uses of the word 'widget' in python files? Did you write a script, but you forgot the file name and which directory it was in? Any search tool will work for that. Do you want to replace all instance of "widget" with "module" but only within your python scripts? Now the shell commands seem more appropriate.

Why can't they just plot a graph with Excel? If you just want to view the line graph from some data points use whatever tool you know best. You can then share that Excel file with anyone else who owns Excel but doesn't understand programming, or export the charts it to a non Excel format I'm sure. But what's that? You want to serve the charts online? Well make them an image and host that. What's that? They need to be dynamic and based on the user? Okay, now we need to code something. What's that again? You just want a chart of some data points for yourself, but you need to compare it against data from an API call? Write something in Python to fetch from that API. You don't know how to use matplotlib? Well output it to a CSV and use Excel for your charting.

The "copy, rename, email" is a bit of an ugly system. But it works, especially for simple student projects. Pretty much any undergraduate I've tutored did this (I guess the ones that knew git didn't need tutoring), and it only starts to become a burden when you get to group projects. The other advantage of git, having a logged history of all your changes, possibly spread across branches for different purposes or features, isn't really apparent when your longest homework assignment is a 4 week project. Git is really valuable when you're working on a team, working on something large enough that you can't keep it's history in your head, or you need really quick access to that history ("I just got an alert that our registration page is giving 500 errors after the last update. What did we change?"). I don't see a reason to confuse students who are already trying to understand so many other new things at once.

I'm not a professional teacher, so you can take all this with a grain of salt. I think the best way to teach programming is for the students to actually be chasing after something they want to finish. Not just synthetic tasks. No one takes a programming course because "I want to learn Python!". They take it because "I want to make apps / websites / video games / do my math research more easily / automate parts of my job" and so on. And then they're not just learning about loops and control structures because "it's going to be on the exam". They're learning about them because otherwise, your game of blackjack ends after 1 deal, and that's no fun.

You really should be able to provide a reason why you're using a certain tool, and not another. Why are you using Python instead of Excel to plot a graph? You're just faster with Python? That's a valid reason. But "because my professor is faster with Python" is not.

I firmly dislike this style of writing. I call it ADD writing. It took 3x as many words to write and 5x as much time to read than if he had just gone straight to the point, instead of going off on some over-the-top rant or irrelevant tangent every other sentence.

I agree. This is a superficial and not very original or insightful piece. It doesn't take genius to describe the difference.

You can take almost any field - building, architecture, engineering, law - and explain the variation in approach between a user and a professional.

Different expectations? Yes

Different experience? Yes

Different culture? Yes

Different skills? Yes

Different tools? Yes

Why should computing be any different?

It worries me that someone who is an associate professor is making such a big deal out of this.

He may have a point that students who are used to a GUI are going to have some issues getting used to writing raw code. But it's not as if IDEs don't exist, or that you have to be an expert on the Bash shell to write an iPhone app.

I'm really not seeing the problem.

I really enjoyed the writing style. It was funny throughout, so the length doesn't matter. And it's for a general audience so some cushion is needed.