luque · April 1, 2016 13:33
diff --git a/gistfile1.txt b/gistfile1.txt
 Tool-oriented programming
 (My current view on how programming should look)

 1. Everyone should be able to program her own computer fluently, to create her own software (because of a whole lot of reasons: from increase in productivity and self-sustainability to better general education and creative thinking, more freedom and cooperation, etc). For this we need to “change programming — turn it from a difficult and obscure art into something that's understandable by [normal] people” (http://worrydream.com/LearnableProgramming/).

 2. When talking about programming technology from its user’s point of view, the “programming language” part of it is typically overemphasized: equally important parts are IDE (with various code and data visualization and  manipulation tools), and the way how you program, and perhaps also social infrastructure of this technology (how you interact with its community to learn from them and to solve problems). When trying to reinvent the programming with the user in mind, we should consider all these parts of the programming technology as a whole user interface thing.

 3. This interface should feel like natural extension of user’s mind, muscles and senses; it should be in full accordance with this user’s current way of thinking — such that the user can focus 100% of her attention on the problem she is solving with her current tool, without being distracted by the tool itself. And because different humans have different background and way of thinking, which is constantly evolving through experience, the only way to achieve such full accordance between human and her tool is by being able to constantly iteratively change that tool, each time updating it to fit the new version of user’s mindset. And unless we have some artificial intelligence thing which magically figures out what kind of interface is optimal for this user at this moment and gives it to the user, the user herself should be able to construct her tool on the fly, fluently iterating and experimenting with it. Generalizing the concept of “language-oriented programming” (where the programmer creates a domain-specific language for the problem first, and solves the problem in this language), we may call it “tool-oriented programming” — when you choose (or construct) the optimal tool for your problem, and then solve this problem with this tool. (Where tool = user interface, including programming languages, GUI controls, visualizations, etc.)
 So what we need is an environment specially designed for creating programming tools on the fly.

 4. The best starting point for this kind of programming is building your own interface for controlling a rich software system which you already use (like Facebook or Youtube) — to be able to automate and combine various functionalities of this system in your custom way, best suited for your current needs.

 5. The next step is to build a single control panel / user interface where you can combine in a cohesive way all the functionalities you need from whatever software systems, so you can easily exchange data between those systems in terms of your own language, abstracting away these systems’ own terminology, APIs, or any other idiosyncrasies, so that you can forget about them once you wrapped them up in your own module with names and interface which make perfect sense to you.
 Any time you want to add to your system some new functionality which you saw somewhere else, you just ask its practitioner “How do you do it?”, install all the needed software in your cloud server, reproduce this functionality (you can even use clicks/keystrokes automation software if the practitioner’s recipe includes some manual action which has no API analog) and wrap this functionality in your own module. From now on you can call this module any time you need it, forgetting about its implementation details. Of course you can later rewrite this implementation (for better performance, lower dependencies, or other reasons) without changing the module’s external behavior.
	Tool-oriented programming
	(My current view on how programming should look)

	1. Everyone should be able to program her own computer fluently, to create her own software (because of a whole lot of reasons: from increase in productivity and self-sustainability to better general education and creative thinking, more freedom and cooperation, etc). For this we need to “change programming — turn it from a difficult and obscure art into something that's understandable by [normal] people” (http://worrydream.com/LearnableProgramming/).

	2. When talking about programming technology from its user’s point of view, the “programming language” part of it is typically overemphasized: equally important parts are IDE (with various code and data visualization and manipulation tools), and the way how you program, and perhaps also social infrastructure of this technology (how you interact with its community to learn from them and to solve problems). When trying to reinvent the programming with the user in mind, we should consider all these parts of the programming technology as a whole user interface thing.

	3. This interface should feel like natural extension of user’s mind, muscles and senses; it should be in full accordance with this user’s current way of thinking — such that the user can focus 100% of her attention on the problem she is solving with her current tool, without being distracted by the tool itself. And because different humans have different background and way of thinking, which is constantly evolving through experience, the only way to achieve such full accordance between human and her tool is by being able to constantly iteratively change that tool, each time updating it to fit the new version of user’s mindset. And unless we have some artificial intelligence thing which magically figures out what kind of interface is optimal for this user at this moment and gives it to the user, the user herself should be able to construct her tool on the fly, fluently iterating and experimenting with it. Generalizing the concept of “language-oriented programming” (where the programmer creates a domain-specific language for the problem first, and solves the problem in this language), we may call it “tool-oriented programming” — when you choose (or construct) the optimal tool for your problem, and then solve this problem with this tool. (Where tool = user interface, including programming languages, GUI controls, visualizations, etc.)
	So what we need is an environment specially designed for creating programming tools on the fly.

	4. The best starting point for this kind of programming is building your own interface for controlling a rich software system which you already use (like Facebook or Youtube) — to be able to automate and combine various functionalities of this system in your custom way, best suited for your current needs.

	5. The next step is to build a single control panel / user interface where you can combine in a cohesive way all the functionalities you need from whatever software systems, so you can easily exchange data between those systems in terms of your own language, abstracting away these systems’ own terminology, APIs, or any other idiosyncrasies, so that you can forget about them once you wrapped them up in your own module with names and interface which make perfect sense to you.
	Any time you want to add to your system some new functionality which you saw somewhere else, you just ask its practitioner “How do you do it?”, install all the needed software in your cloud server, reproduce this functionality (you can even use clicks/keystrokes automation software if the practitioner’s recipe includes some manual action which has no API analog) and wrap this functionality in your own module. From now on you can call this module any time you need it, forgetting about its implementation details. Of course you can later rewrite this implementation (for better performance, lower dependencies, or other reasons) without changing the module’s external behavior.