Inventions that will change the world

I would bet my last dollar that any of these inventions will change the world the same as the Internet and mobile phones have already changed it.

Google glass will completely change the way we use computers today. Instead of sitting in front of a screen connected either to a computer, laptop, tablet or smartphone, we will wear the screen all the time just on our eyes. There will be dozens of new applications or improvements to the existing ones. This will concern not only practical applications for navigation, shopping, dating, running a job interview, tour guidance or gaming applications (adventures, RPGs, simulations, strategies, racing, adults; basically all of them) but also military, medical, educational and other applications. We will (finally!) stop using keyboard to command the computers and will (more naturally) use voice, hands and other kinetic sensors.  

Self-driving cars will wipe out most of car driver jobs, no matter if the drivers are driving trucks or cabs. It will lead to almost-zero number of accidents in the streets and also dramatically drop the car sales. People will stop buying cars and will share them instead. Why having my own car in a city where is no place to park if the car can pick me up any time I need?

3D printers will bring total customization to any product being sold. Wanna iPhone with your nickname written on the home button? Or with the name of your love? Just print the button out! For some products, it will also speed up their delivery. Instead of waiting for Amazon to send us a new toy, we will receive an e-mail with the toy's model and we will print it out on our own or a local store 3D printer.

Bitcoin brings not only freedom to financial markets and a new virtual commodity but many more revolutionary ideas. There is a person who already well summarized the *coin's benefits, see here.

Haptic touch screens with realistic tactile sensation will greatly improve the experience when running an app on a tablet or smartphone. This will not only open touch screens to blind people and improve the impression of existing applications but also bring completely new applications. One example from many of the existing technologies is here.

For many years already I've been convinced that the future IT co-workers writing end-user applications will not spend 3+ years getting their degree in IT, Math, Physics or whatever subject they've decided to get, but instead, briefly schooled apprentices will take over this role.

First of all, this seems to me inevitable as there is too high demand for programmers while there is too little number of colleges.

Next, these future programmers will not have to "waste" their time on theory when they can learn the same from practice.

And finally, as present-day programming will be served by mass, the future programming will be more about tooling and serving the future programmers (thus not writing the end-user applications).

When watching this Bret Victor's video I realized that my conviction is finally coming true.

DSL - good servant, bad master

I'm always happy to read, hear or watch anyone writing, talking or presenting about Language Oriented Programming and/or Domain Specific Languages as it is my favourite topic and I have a soft spot for it.
I dipped into Neal Ford's presentation he had at JavaOne conference entirely alike (I was not that lucky to hear the talk, however).
Neal goes through the classical examples of DSLs and explains the main benefits of LOP. Although it mostly describes nothing new, I did like reading it since it proofs more people is starting to be interested in it.
I liked the word context he mentioned when talking about the main feature of DSL. It is certainly true that every specific language has a domain that can also be called its context and that this context is always implicitly given for each single DSL.
But that is not the main thing I want to draw one's attention to.

One thing struck me. The simplicity with which he added new language constructs into this language. I was not struck positively, however.
I remember having similarly mixed feelings with overloaded operators in C++. Although it was contributing when used smartly for creating a completely new library (everyone is familiar with iostream library and << operator), it was disservicable when a programmer overloaded his/her operators recklessly (and headache to read such code). One could be sure with nothing.
I believe - it is good to create new languages as it is good to create tools to help design these new languages. But I do not believe that most people will be able to easily create new languages in the correct way where correct way means not to mess things up.
Not many SW developers are skilled enough to design good API and creating a new language is not an easier task either. Design of languages is a job for language designers -> simple way of adding new constructs to a language is not a feature intended for broad public. Moreover I believe that every non-trivial language should contain guidelines and design patterns to use this language. Again, to bring such patterns up is not a task for an ordinary programmer.

P.S. It is also worthy to see this video, an older Neal's presentation about DSL/LOP - some slides seem familiar.

Internal vs. External Domain Specific Languages

Martin Fowler mentioned at the end of his speech he had recently on JAOO conference, it is difficult to gauge the impact of Language Workbenches and inherently External Domain Specific Languages. Although neither Intentional Software nor JetBrains have revealed themselves yet what they are up to, I do not believe people will start creating external DSLs recklessly sooner or later. It is much too difficult to create a new language, its parser and teach this language other people, simpler the language can be.

What I believe more is that people start to realize their APIs and libraries in currently used general-purpose languages should resemble DSLs more so other people can use these as a new language with all properties a new language has. Thus the resulting application will be much better layered and different aspects of the project separated while keeping one (or few) programming language(s) with one syntax only within whole project.

The main difference will not be in programming, it will be in thinking about programming.

History lesson

At the end of 1997 I started my job in ICS (a small company, I was their 10th member) as a programmer. My main task was developing simple database applications for small bar-code readers (handy terminals in other words). These times, such a terminal was a computer with a numerical keyboard, a simple BW display, processor and most importantly with a laser or a CCD reader for reading bar codes. Pretty much it looked like a mobile phone. The usual project life I was participating on consisted of these steps:

1. Verbal agreement
2. Specification
3. Price estimation
4. Implementation
5. Documentation
6. Operator training
7. Maintenance

Documentation was usually a more detailed version of specification and the implementation was copied from sources of previous projects. At the time I was working on the third (very similar) project, I wrote a general library of common functions for storing, manipulating and searching data in a file, for drawing menus and input forms, even an implementation of AVL tree for fast search. Although these times I didn't suspect anyting about LOP, this library was an instance of DSL for writing these simple database applications.
Soon I realized that this policy must have been changed and offered my boss - director of this company - to develop a project for creating these applications. Thanks to his enthusiasm to new projects, the project really started and got financed.
First I supposed the tool would be a very simple source code generator using already mentioned libraries. Later, the company's management decided on possibility of selling this product (without re-selling the compiler) so it must not have only generated source code, it must have also run the code. This is the final idea that got also implemented:

1. Graphical IDE that helps the bar code expert to create an application
2. The application will be then downloaded into the bar code scanner
3. In the scanner runs an interpreter of this application.

Although we didn't have a single notion of terms like DSL or a domain expert we soon realized that more easy the tool would be, less general problems would it solve and less steep the learning curve of this tool would be. We were also aware of the opposite - a more complex tool would never be used by non-programmers. Balance these two opposite requirements was the most difficult task. Finally, we (me and three other university mates) made it happen. In the tool is possible to define several entities (data tables, menus, input forms, variables and procedures) while it checks if all references are correct; it supports easy refactoring and also allows debugging. From its very beginning it supported 4 different platforms (DOS, Windows, and 2 bar code readers) all programmed in C/C++.
From this description is clear, I hope, that the tool (named Karel after our parrot that shared a dormitory room with us these times; later it was renamed to a less poetic name ProGen) is nothing less than an instance of DSL provided with an editor exactly as it is described in this great Sergey's article.
Interestingly, I started participating in LOP/DSL area even before I realized this area will once exist. I noticed recently that the same idea - unintentional creation and use of DSL - is expressed in the new blog entry of Intentsoft. If one was interested, here are screenshots of the tool:

On the subject of SMS typing

Have you ever thought how different or how easy the life would be if we didn't use our bad habits from the past? Just imagine the disaster if scientists proposed new much safer rules of car driving and enlightened politicians tried to put it in use even though it was much easier than the way cars are driven now. The long-term advantages are indisputable, however, the immediate results will discourage any brave politicians. No wonder that Britons never changed their left-hand driving... As the old saying states - can't teach an old dog new tricks.
Similar thing happens, although with no such severe consequences, when typing an SMS (for those who never typed an SMS - sending text messages from mobile phones is fairly popular in Europe, especially in countries like Czech where calls are so expensive). Why are the letters shown in alphabetical order on the keypad? Wouldn't be the typing easier when all vowels and consonants were shuffled as they are on a computer keyboard? Certainly would. Let's do it! Is there any courageous mobile phone producer?
Isn't a similar thing happening now in computer programming? Aren't we learning new tricks? If only we could drop all old tricks and start learning the new ones easily.

Mother Nature

Many great human activities and inventions were inspired by nature in the history and computer science is no exception. In this contribution, Charles expresses an idea that is inspired by the Nature. He compares the program generation (a method that should bridge the wide gap between problem description and its solution and also a method that Intentional Software aims at) to DNA - a description (of a problem) that Nature uses to generate whole human being (the solution). This comparison is a good one, I believe. The only thing that remains is to find the right enzymes producing healthy individuals and no rejects.

Speaking of inspiration by Nature, there are other ideas concerning computer science. Although the Recapitulation theory is being abandoned lately, the connection between Ontogeny and Phylogeny undeniably remains.

If we compared the evolution of programming to Phylogeny and an evolution of one program to Ontogeny, we would get a simmilar connection. If the Ontogeny copies some steps of Phylogeny (as the Recapitulation theory claims), does it mean that in different stages of one program development, its authors should use different styles of programming? Should we start with very basic elements, then design fundamental procedures, create modules and finally use objects and find cross-cutting concerns? Or does it mean that in every well-written more complex program a different programming styles will inevitably appear?