Programming by copying

Recently, I've seen a demo on programming by copying. It takes just few minutes to see it and it's really worth to do that. Although it might be seen as a funny plaything first, a much deeper idea is hidden behind that. Not many programmers would admit that programming by copying is a good idea. Nor do I. On the other hand, say frankly, how many times did you program by copying? I did many times. What's wrong on that? It shows a bad concept of your program. What's good on that? It's fast and accurate; the copy becomes an original piece of code immediately and you can adjust the copied code instantly without worrying about side-effects at another parts of your program. Shortly, copying is good when jotting down a prototype of your idea and you don't really bother about misconceptions – you know your program will need refactoring in the productize version, but all theory, dear friend, is gray, but the golden tree of life springs ever green (as a great German writer once said). We don't always have time to refactor it, do we? In such a case programs made by copying get to products. So, what's the hidden idea? Here it is – program is not only a piece of text and programming is not just typing of it. It shows that text editors are still a weak substitute of real program editors. If an editor tracked all changes made on the program and remembered which parts of the program were made by copies of another parts, the editor could refactor the program without programmer's help. Moreover, the editor would refactor program without making mistakes, it wouldn't forget any possible side-effects. The demo shows one way to do that in not real textual editor and in not really common way. Similar idea can be implemented into more sophisticated and common editor. Much in programming has been changed since time of Turing but not the way we program. It's like making cars with hammer and sickle only! I'm not saying – using primitive tools for making cutting edge technologies is impossible, I'm saying – let's do something with it!

Aspect limits

Aspect Oriented Programming (as most of people interested in LOP already know) enriches the world of languages with cross-cutting concerns. Although the idea is not new, it is still being heavily researched.
Typical use cases of AOP are logging, debugging and error handling, these examples can be found in every reference to AOP. But, isn't it too little? What are the other use cases of AOP? What are the real production use cases? Even though error handling is used in products, hardly can it be considered as the main feature of a product. Transaction handling, synchronization in multi-threaded environments, lazy initialization, security; all these fields are certainly other areas where AOP can be used appropriately, but what else?
The lack of AOP use cases may result from little usability of AOP features. Look at the logging - AOP can log any call or return of a method but it can't log other branch instructions (if/else, switch/case) - scarcely it can be used for full logging of a program flow.
Similar limitation exists for AOP usability in synchronization - AOP cannot handle monitor lock/unlock (entering into/leaving from a critical section) - this keeps automatic deadlock prevention tools from being implemented.
Although the main two AOP projects have joined recently to work on new releases together, many things still remain to improve.

Why we have used notations and why they are not necessary anymore

In this great article, I've read recently, is a very interesting belief: "We believe that next-generation programming systems will most likely store source code as XML, rather than as flat text. Programmers will not see or edit XML tags; instead, their editors will render these models to create human-friendly views, just like Web browsers and other WYSIWYG editors."
This is certainly true. As soon as I read the sentence above, it was clear why we have used notations in programming. Do you also ask, why there were invented such rules as Hungarian notation, indentation, firstLetterOfEveryMethodNameInCapitals, CONSTANT_NAMES_UPPER_CASED, etc? Here is the answer - we didn't have the right tools those days. We were lack of expressiveness and all the notations were merely poor escapes from that mud. Now, when any programmer may express his/her ideas in the proper way, these notations are not as important as they were before. I'm not saying, stop using them, but in case you do, it's much easier to refactor all the pile you wrote now than it has ever been before.

Create your jargon first

As has been posted by many smart men, Domain Specific Languages will drive the world of programming in the near future. As another great artist said: "Bad artists copy, great artists steal", the best of us try to be great. Actually, what we do is stealing ideas from native languages – the ones not to be as artificial as programming languages are.
What's going on in the native languages? They change, they adapt to the environment they are used in. People working in one environment tend to create their own jargon – to express ideas of that domain more easily, more accurately and more concisely.
Domain specific languages relates to general languages as well as different kinds of jargon relates to different native languages.
As an example of a domain we may know a lot about, look at creating the IT jargon. In English it is done in a fairly different way than doing the same in Czech. In English, old words get new meanings so words like computer, web, network, file, etc. having their original interpretation have suddenly a new meaning. In Czech, however, most of the IT jargon is created by borrowing words from English. Thus, just few jargon words stay originally Czech. Although creating a jargon may be done differently in various languages, the purpose is always the same – to be concise in that particular domain.
Jargon of native languages is the proof that DSL is the future of programming. To express your ideas properly - create your jargon first.

Welcome

This web will, hopefully, comment anything in subjects I'm keen on, especially in the domain of Language Oriented Programming and related areas. As I'm not a native English speaker, but a native of Bohemia and my mother tongue is Czech, please, respect my English.