luque · April 1, 2016 13:26
diff --git a/gistfile1.txt b/gistfile1.txt
 From http://arstechnica.com/gadgets/2015/10/hp-and-sandisk-join-forces-to-finally-bring-memristor-like-tech-to-market/

 (This is a draft. Corrections are welcome.)

 In the term “programming language” the word “language” is probably very misleading, causing a lot of trouble when people apply to it what is specific to human languages. Examples are: 1) trying to understand what other human meant by reading her code; 2) the idea that in order to collaborate we must agree on which specific programming language we will use.

 Human language (like English) is a medium for conveying meaning between humans; we use it in daily life to communicate interactively and understand each other.
 Computer language is a medium for giving to computer a set of precise instructions by the programmer. This communication between programmer and computer is quite specific and unlike communication between humans: it goes one way (computer does not speak this language, it only listens to it), and it is unintelligently precise: computer will always run exactly what is written in the program (whatever complex and unreadable to human it might be), but it absolutely does not “understand” the meaning of what the programmer said in the sense how humans understand things (i.e. see connections between things, see the intentions of the speaker, etc).

 Do not waste time on deciphering code
 One often cited quote says “Programs must be written for people to read, and only incidentally for machines to execute”. Perhaps the opposite is true, at least for some programming domains: “People can write code, but because code is so bad a medium for conveying meaning to a human reader, people should not have to read other people’s code or their own old code”. Instead, they can understand a program through various human-readable computer-generated visualizations of what the program does, and through talking to other people who already understand this program. Everyday communication between humans works quite well for understanding each other; it is based on short and imprecise sentences, highly relies upon context (where we are, what we see now, what we talked about before, etc), together with intonation, facial expressions and eye movements, gestures, etc; and it is highly interactive. In contrast, when while reading code you stumble upon some fragment which you do not understand, the code will not notice it and tell you “Well, let me say it another way”. Communicating meaning via written words only is a defective self-restriction of the same kind as sitting at a desk looking through “tiny rectangles” (http://worrydream.com/SeeingSpaces/) or “sliding pictures under glass” with a numb finger (http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/).

 Changing the program without the need to decipher code
 So how can we change programs, collaborate with others, and create large programs without the need to precisely understand other’s code? This will be possible when the program is a set of independent components communicating with each other. To understand such a program means to understand what each component does, not how it does it. The implementation of a component is hidden inside it, and different components in one program can be implemented using different programming languages (you just need to indicate current language’s name to the compiler). Every component should do some concrete, easily describable thing (e.g. it can in some way combine outputs of several other components, without knowing their inner implementation details or even languages they are written in), so that it will not take long to rewrite this particular component from scratch using you current language of choice. Then, when you want to change the program, you can just rewrite one (or several) of its components from scratch with the new desired functionality.

 Unleashing the progress
 When any component of a single program can be implemented using any language (in particular, any version of a certain language, or e.g. some throwaway unnamed experimental language) and when we are free from the necessity of reading other’s code, then there is no longer need to maintain language’s backward compatibility with all its ugly compromises, inconsistencies, and artificial complications. Any language will be able to evolve as quickly as its user wants, staying always as clean and simple as it can be. There will be no qualitative difference between “different versions of a language” and “different languages”; the whole notion of a distinct programming language which saves its identity throughout consecutive versions will go away. There will be just various programming techniques (and language constructing techniques) which programmers will adopt from each other, looking at how this or that programmer does her stuff and talking to her about it. We learn from other people better interactively — looking at them in the process of doing (programming, or playing musical instrument, or solving a math problem) and asking questions; not just by looking at the result of their work (program’s code, or a problem’s solution written on a blackboard). Because the process of doing contains a lot of useful information not contained in the result (what was the intention of writing this block of code, which options did the programmer consider, why did she choose this option, etc).

 Convergence of programming techniques
 It may seem at first sight that when everyone uses her own programming languages, the variation between them would be so large, different people would program so differently, that they would hardly be able to understand each other and collaborate. But this is just another false analogy (in this case — to the Tower of Babel story) resulting from applying to programming “languages” what is true for human languages. Actually quite the opposite is likely to be true: I would expect some sort of convergence between programming techniques used by different people. Because when different people face the same kind of task repeatedly and try to handle it in the most convenient way, being free to try various solutions, being independent of each other and still able to look at each other’s tools and borrow interesting ideas and techniques, then the tools and techniques they eventually use tend to converge through time to some small number of polished solutions shared by everyone. For example, there is not a large variety of ways how people actually wash the dishes, or dig soil, or hammer nails into wood, although everyone is free to try alternative ways and it does not bother you whether your neighbor uses the same or different way. It is actually this freedom and independence that led to the outcome where everyone eventually uses a more or less optimal solution, which turned out to be uniform. This is what will likely happen with programming techniques if we give to individual programmer this kind of independence from her colleagues in choosing tools, by treating programming language as it should be treated — as a personal tool for operating the computer.
 Finally, not only programming techniques but also naming patterns are likely to become more uniform between programmers than they are today, because programmers will no longer have to be stuck with any weird name that the language author had come up with. And different programmers will name their stuff quite similarly as far as they program to solve the same real-life problems and talk to each other about them using the same English.
	From http://arstechnica.com/gadgets/2015/10/hp-and-sandisk-join-forces-to-finally-bring-memristor-like-tech-to-market/

	(This is a draft. Corrections are welcome.)

	In the term “programming language” the word “language” is probably very misleading, causing a lot of trouble when people apply to it what is specific to human languages. Examples are: 1) trying to understand what other human meant by reading her code; 2) the idea that in order to collaborate we must agree on which specific programming language we will use.

	Human language (like English) is a medium for conveying meaning between humans; we use it in daily life to communicate interactively and understand each other.
	Computer language is a medium for giving to computer a set of precise instructions by the programmer. This communication between programmer and computer is quite specific and unlike communication between humans: it goes one way (computer does not speak this language, it only listens to it), and it is unintelligently precise: computer will always run exactly what is written in the program (whatever complex and unreadable to human it might be), but it absolutely does not “understand” the meaning of what the programmer said in the sense how humans understand things (i.e. see connections between things, see the intentions of the speaker, etc).

	Do not waste time on deciphering code
	One often cited quote says “Programs must be written for people to read, and only incidentally for machines to execute”. Perhaps the opposite is true, at least for some programming domains: “People can write code, but because code is so bad a medium for conveying meaning to a human reader, people should not have to read other people’s code or their own old code”. Instead, they can understand a program through various human-readable computer-generated visualizations of what the program does, and through talking to other people who already understand this program. Everyday communication between humans works quite well for understanding each other; it is based on short and imprecise sentences, highly relies upon context (where we are, what we see now, what we talked about before, etc), together with intonation, facial expressions and eye movements, gestures, etc; and it is highly interactive. In contrast, when while reading code you stumble upon some fragment which you do not understand, the code will not notice it and tell you “Well, let me say it another way”. Communicating meaning via written words only is a defective self-restriction of the same kind as sitting at a desk looking through “tiny rectangles” (http://worrydream.com/SeeingSpaces/) or “sliding pictures under glass” with a numb finger (http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/).

	Changing the program without the need to decipher code
	So how can we change programs, collaborate with others, and create large programs without the need to precisely understand other’s code? This will be possible when the program is a set of independent components communicating with each other. To understand such a program means to understand what each component does, not how it does it. The implementation of a component is hidden inside it, and different components in one program can be implemented using different programming languages (you just need to indicate current language’s name to the compiler). Every component should do some concrete, easily describable thing (e.g. it can in some way combine outputs of several other components, without knowing their inner implementation details or even languages they are written in), so that it will not take long to rewrite this particular component from scratch using you current language of choice. Then, when you want to change the program, you can just rewrite one (or several) of its components from scratch with the new desired functionality.

	Unleashing the progress
	When any component of a single program can be implemented using any language (in particular, any version of a certain language, or e.g. some throwaway unnamed experimental language) and when we are free from the necessity of reading other’s code, then there is no longer need to maintain language’s backward compatibility with all its ugly compromises, inconsistencies, and artificial complications. Any language will be able to evolve as quickly as its user wants, staying always as clean and simple as it can be. There will be no qualitative difference between “different versions of a language” and “different languages”; the whole notion of a distinct programming language which saves its identity throughout consecutive versions will go away. There will be just various programming techniques (and language constructing techniques) which programmers will adopt from each other, looking at how this or that programmer does her stuff and talking to her about it. We learn from other people better interactively — looking at them in the process of doing (programming, or playing musical instrument, or solving a math problem) and asking questions; not just by looking at the result of their work (program’s code, or a problem’s solution written on a blackboard). Because the process of doing contains a lot of useful information not contained in the result (what was the intention of writing this block of code, which options did the programmer consider, why did she choose this option, etc).

	Convergence of programming techniques
	It may seem at first sight that when everyone uses her own programming languages, the variation between them would be so large, different people would program so differently, that they would hardly be able to understand each other and collaborate. But this is just another false analogy (in this case — to the Tower of Babel story) resulting from applying to programming “languages” what is true for human languages. Actually quite the opposite is likely to be true: I would expect some sort of convergence between programming techniques used by different people. Because when different people face the same kind of task repeatedly and try to handle it in the most convenient way, being free to try various solutions, being independent of each other and still able to look at each other’s tools and borrow interesting ideas and techniques, then the tools and techniques they eventually use tend to converge through time to some small number of polished solutions shared by everyone. For example, there is not a large variety of ways how people actually wash the dishes, or dig soil, or hammer nails into wood, although everyone is free to try alternative ways and it does not bother you whether your neighbor uses the same or different way. It is actually this freedom and independence that led to the outcome where everyone eventually uses a more or less optimal solution, which turned out to be uniform. This is what will likely happen with programming techniques if we give to individual programmer this kind of independence from her colleagues in choosing tools, by treating programming language as it should be treated — as a personal tool for operating the computer.
	Finally, not only programming techniques but also naming patterns are likely to become more uniform between programmers than they are today, because programmers will no longer have to be stuck with any weird name that the language author had come up with. And different programmers will name their stuff quite similarly as far as they program to solve the same real-life problems and talk to each other about them using the same English.