13 ms·

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

by gavinpc 10y ago

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.

coldtea 10y ago
>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
- initram 10y ago
  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.
  - dozzie 10y ago
    > 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.
    - coldtea 10y ago
      >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.
paxcoder 10y ago
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.
ontouchstart 10y ago
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 http://www.dougengelbart.org/pubs/augment-3906.html

by gavinpc 10y ago

coldtea 10y ago

>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

initram 10y ago
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.
- dozzie 10y ago
  > 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.
  - coldtea 10y ago
    >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.

paxcoder 10y ago

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.

ontouchstart 10y ago

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 http://www.dougengelbart.org/pubs/augment-3906.html